ド文系出身の未経験新卒エンジニアがいちからサービス作った話

突然ですが、皆さん「ルネサンス」と言われたら何を真っ先に思い浮かべるでしょうか。

「ルネッサ〜ンス」・・・？それとも「髭男爵」・・・？

・・・一般的に、世界史の教科書においてルネサンスといえば、だいたい次のような出来事を指すと言われています。

ルネサンス（仏: Renaissance）は「再生」「復活」を意味するフランス語であり、一義的には、古典古代（ギリシア、ローマ）の文化を復興しようとする文化運動であり、14世紀にイタリアで始まり、やがて西欧各国に広まった（文化運動としてのルネサンス）。また、これらの時代（14世紀 – 16世紀）を指すこともある（時代区分としてのルネサンス）。

引用：Wikipedia

なぜ私がこんな話をいきなり冒頭でするのかというと、それは私が大学で西洋史を専攻するかなりマニアックな歴女であり、超ド文系出身かつ未経験にも関わらず、新卒エンジニアとしてある社内向けのWebサービスを開発したからです。

そんな私ですが、自分がシステム開発という未開の地に配属された時は正直内心「マジか（驚き）」という気持ちでした。入社当初はコードを書きたくても書けない自分に苛立ちと悔しさを感じて毎日ビービー泣いていました。

それでも周りの先輩方に支えられ、何とか無事にエンジニアとしての基本研修を終えた時は、一つの達成感を覚えたと同時に、これからもやってやるぞという強い気持ちになっていました。

しかし！！！そんなやる気に満ちた私の思いもこの後ジェンガのごとく崩れ落ちます。この直後に私に待ち受けていたのは、

「さあ、これからの3ヶ月でサービスを一つ考えて、実際に作って見よう」

という上司の一言でした。

私に待ち受けていたのは、ユーザーに価値を届けられるサービスを考え、実際に開発して提供するという「サービス開発」でした。

今回は、そのサービス開発での私の失敗談やそこから得た経験をお伝えし、新人エンジニアの方や、これからエンジニアを目指す未経験の学生の方の参考になればと思います。

サービス開発をやる目的

今回新卒に課せられた「サービス開発」の大枠はこのような感じでした。

まずは課題定義からスタート。社内外の人を1人ターゲットにし、その人が抱えている課題を解決する必要があります。なぜなら、「n=1」の課題を解決できないと多くの人の課題なんて解決できないからです。1人で考えた何かを作っている訳では決してありません。ユーザーの対象になる「誰か」がいることで、サービス作りはスタートすることができます。

ですが、この上の図のような流れに沿って、綺麗に行けたかというと、結論、いけませんでした！それらの理由は後ほど説明するとして、まずはこのサービス開発をやる目的についてお話させてください。

新卒教育の一貫として行われた3ヶ月のサービス開発ですが、これを行う目的は単に初めの基本研修で学んだことをブラッシュアップするためではありません。真の目的は、PLAN-Bという会社が最も大事にするユーザーにとっての「価値」をちゃんと考え、作り上げ、そして届けきることです。

こんなん作りました

今回私は、部署内外で起きるコミュニケーション不足を解決する社内向けの、「PLANー♡」というサービスを作りました。社員の間で起きる、業務上のあらゆる勘違いや誤解などのもやもやに悩んでいる人が、少しでも風通しよく働けるようにするために生まれたものです。そこで業務に支障が出ないように、Chatwork対応にして、業務中のふとした時に気軽に感謝のメッセージを送れる以下のようなコミュニケーションツールを作りました。

このPLAN-♡を使うことでまだ関係値の浅いメンバーや上司の人となりや考え方を知り、お互いを認め合うことができます。まだベータ版のリリースではありますが、現在自分の部署の中で運用を開始しており、改善を繰り返して来年の頭には本格的に他事業部への展開を考えています！

このサービス、完成させるまでに長い道のりがありました。未経験だったからこそ起きた失敗の数々を経て、改めて課題を見つけて解決するエンジニアになることの大変さを知りました。これからサービスを作る上で忘れてはいけない「価値」の話をしますので、どうぞエンジニアになりたい誰かのところに届けられたら幸いです！

私の失敗と学び

手段を目的にしちゃってた（その1）

ユーザーにとっての価値を届けるにはまずユーザーが何に困っているのかの「課題」を知る必要があります。「課題」はユーザーに教えてもらうものではなければ、ユーザー自身も気づいていない深層的な部分の可能性が高いので、自分で見つける必要があります。

私はヒアリングをした後、しばらく考えこむと、ぽんぽん案が湧き上がりました。「これじゃん！」「もう見えたな」みたいな感じになり、その案が通るように資料をしたためて上司に報告に行ったところ、バッサリ一言。

その後、時間をたくさん使って、何度もユーザーが漠然と抱えている悩みを頭の中で復唱しながら、「そもそも何故この人はこう思ったんだろう？」などといった分析をはじめました。「何故？」を繰り返し考えていくうちに私が解決したい「誤解や勘違い」を生み出す根本の原因が、「社内に思いやりの風土が足りていない」ことに気づいたのです。

元々物事を「なぜ？なぜ？」と考えることが苦手な超情緒派の私は初っ端から苦労しました。皆さんにここでお伝えしたいのは、解決したい「課題」を見つけることは時間をかけてでもしっかり考え抜くべきところだということです。

手段を目的にしちゃってた（その2）

MVP開発に進みましたが、基本のプログラミング研修の技術レベルのままでは作りたいものが作れないという現実の壁にぶち当たりました。スケジュールが何度も後ろ倒しになり、そろそろ本当に「間に合わないかも知れない」という危機感が顔に出始めた頃、様子を見かねた先輩方から言われてしまいました。

先輩方のおっしゃる通りでした。自分ではできたと思っていたのですが、ユーザーテストをした結果、反応はイマイチ。作りたいものは理解してもらえるけど、「この機能っているかな？」と言われてしまいました。

私は完全にユーザーにとって価値の低いものを開発してしまっていたのです。そう言われるのもそのはず、私自身がMVP開発がどういう意味なのかをしっかり理解できていませんでした。

MVP（Minimum Viable Product）とは簡単に言うと「効果を検証できる最小の動くもの」のことです。このMVPを開発しておけば、早い段階でユーザーの反応やフィードバックを集めることができ、現在のリソースで実装できる機能や不要な機能を予測できるのです。

このMVPと言われるものに対して、私が作っていたのが「ウォーターフォール型開発」。

このウォーターフォール型開発、全体を把握して、工程別にタスクを分配し、プロジェクト全体の進捗管理をスムーズにできるメリットがある一方で、進行中に変更が生じたときの負担が大きいデメリットがありました。

となると、変更が発生するかも知れないのに、いくら完成していても、またやり直し。結果的に、最終完成までの期間も長期化してしまうのです。私の場合、小さいウォーターフォールを反復的にやれていれば良かったのですが、「1回のウォーターフォールで作りきろうとしていた」ことがここでの重大なミスでした。

それに気づいた時は残り1ヶ月を切ろうとしていました。3ヶ月というタイムリミットに強い焦りを感じ、「早く、一気に作り上げなければならない」という思いに囚われた結果、私は無意識ながらも「とりあえず完成させること」を目的にしてしまっていました。

まるで森の中に迷った赤ずきんのように、このサービス開発を行う目的をいつの間にか見失っていたのです。(下図は当時の私の様子…上司による傑作です…)

じゃあどうすればよかったのか？

大事なのは一気に作ろうとしないこと。

当初の私のように最初からいきなり完成形を作ろうとすると、途中でモチベーションが続かなかったり、無意識のうちに手段が目的化してしまったり、結果的にユーザーが本当に求めているものから遠ざかる一方になります。

そうではなくて、一つ一つのパーツを作って効果検証をし、新たな課題が見つかったら、その都度ブラッシュアップしていく。

つまり、ベータ版でも小規模でもいいから最小単位でリリースをし、ユーザーテストを行い、その結果改善できるところに磨きをかけていく手法の方がはるかに効率的で作り手もユーザーも求めている「価値あるもの」に近づくのです。

まとめ

私がこの3ヶ月のサービス開発を介して学んだ点をまとめると…

実際運用を開始してみて、いきなりバグが出たり、「ここちょっと使いにくい」と言った意見が日々寄せられます。厳しいようですが、どんなに頑張って作っても、課題が解決しなければユーザーにとって意味の無いものになる可能性があるのも事実です。

私の場合、一番に解決したい「業務上の誤解や勘違いを無くす」課題が、開発したプロダクトを通して解決されなければ作った意味はほぼ無くなってしまいます。だからこそ、本当の意味でのサービス開発は「作った後」。

意味のあるものにするために、ユーザーの意見を大事にし、改善していくことが、ユーザーに「価値」を届けきることだと思います。それでもこの3ヶ月間、自分の手を動かして作り上げ、失敗した「Scrap & Build」の経験は必ず意味のあるものだと信じています。

そんな笑いあり涙ありの3ヶ月のサービス開発でしたが、価値を作るためのプロセスを3ヶ月間実施した結果、現在は業務に生かされています！

そして今回私がやった上流工程（要件定義や設計）から下流工程（開発やテスト）まで一連のスパンは、なかなか経験できないことかもしれません。自分の力でサービスを作り、プロダクトを開発した経験は自分にとって必ず財産となるはずです！

実はこのサービス開発と似たようなことを学生向けの長期インターンシップで実施しております。是非「ユーザーに価値を届ける」経験を積みたいという方はふるってご応募ください！

ちなみに倍率は超高いのですが（倍率約20倍）、それだけの価値はあると思います！