初のZero To Oneに挑む ~振り返りと今後に活かすこと~

【はじめに】このポストを書くきっかけ

２０１９年４月から社会人として４年目（のはず）。

ほぼ未経験のエンジニアとして今の会社のインターンとして入り、そのまま正社員に。

３年目まではエンジニアの領域でフォーカスしてやってきたが、２０１８年の上半期くらいから徐々にエンジニアリング以外のことにもチャレンジしたいという願望と、エンジニアリング以外のスキルも伸ばしていきたい欲求が強まってきていた。

結果、事業開発チームのメンバーにアサインしてもらえることに。

新しいことにチャレンジすることは刺激的だが、苦しいことなど、いいこともあれば悪いこともある。

そんな生活を続けてだいたい１年が経ち、諸々キリの良いタイミングだったので、この１年のことを（記憶を頼りに書いているので、内容が前後したり、内容の若干のズレがあると思うが）振り返ってみることにした。

（※これはあくまで個人的な感想と今後の思いである。会社やチームメンバーの見解とは異なる点もあるはずなので、生暖かい目で読んでもらえますと。）

【５ ~ ７月】始動！

1. スタートアップ界隈の仲間入り

事業開発チームにメンバーとしてアサイン。

今まではエンジニアとしての仕事がほとんどだったのが、一転した。

それがきっかけだったと思うんだけど、前々から読もう読もうとリーンスタートアップを読むことに。

そこから立て続けに「実践リーンスタートアップ」や「起業の科学」などの関連書籍を漁った気がする🧐

MVPやBuild-Mesure-Learnといったスタートアップにおけるプロダクト開発に関するキーワードは聞いたこともあったが、それまで実際そういった概念を意識して仕事をしていたわけではなかった。

そしてそれらを仕事に取り入れることに対して、ある種の高揚感があったのを覚えている笑

（使うことが目的ではないのはわかっているが）きっとその時は、スタートアップ界隈の仲間入りができた気がしたんだと思う。

2. 無思考人間

最初はアサイン前に検討された資料などをベースにしつつ、業界の市場規模やトレンド、人々の生活習慣などを調査会社の調査資料やこれまでのユーザーインタビューなどを見返したりした。

まずここで、知らないことに対して、頭を捻らずに、すぐにググって答えを探してしまっていた今までの無思考生活が仇となった😖

「〇〇（業界名）市場規模」とググれば、どんな業界でも市場規模が検索結果に出てくるわけではない。

結局はある程度の仮説を持って、それらを裏付けしていく。ということが必要になってくるわけだ。（あとでも列挙するが、「イシューからはじめよ」「仮説思考」「論点思考」あたりは読んでおくべき。）

（似たような話だが）この頃は、初めてやることばっかりで何していいかよくわからず、ただただ手を動かす。みたいなことが（今以上に）多かった。

….これは本当によくない。

「〇〇という仮説を裏付けするために、□□という情報が必要。だから、△△を調べよう。」とか「〇〇という意思決定をするために、□□という情報が不足している。だから、△△を調べよう。」みたいに、「なぜそれをやるのか」を自分の中で明確化できていない状態で、いきなり情報収集などの手を動かすと、地獄だ😈

立ち返る場所がない（つまり、目的が明確化してない）と、作業中に不必要な情報収集ばかりしてしまったり、全然違う方向に進んでしまったりしてしまう。

手を動かしていると進捗感があるので、安心してしまう。

でも終わってみるとほとんど意味をなさなかった。みたいなことにならないようにしたい。

この「段取り」という点に関しては、今でも課題感がある。

今まで目先のことばかりに捕らわれてしまい、先を見越さない行動をしてばかりいたツケだろう😩

この辺に苦手意識がある人は、論理思考系の本や段取り系のは役立つと思うのでおすすめ。

思考系だと

イシューからはじめよ

仮説思考

論点思考

問題解決プロフェッショナル

外資コンサル知的生産術

段取り系だと

トヨタ公式ダンドリの教科書

いちばん大切なのに誰も教えてくれない段取りの教科書

とか読んだりした。（読んだだけではほとんど意味をなさないので、実践していくしかないわけだが。）

3. インタビューは難しい

….話を戻そう。

資料を読むだけではなく、インタビューもスタート。

インタビューは、社内の人に対してのから始まり、徐々に社内の人からの紹介経由でのインタビューに。

まだこのときには、「こういう人たちがこういう課題を抱えていそう」みたいな大きな仮説（イシュー）は立てられていなかったので、仮説検証にフォーカスしたインタビューというよりも、「どういうところに課題感がありそうか？」みたいな課題抽出を目的としたインタビューだった。

ほとんど書記としてインタビューには入って、何回かインタビュアーもやった。

….インタビューは難しい😖

沈黙してしまったり、あまり本筋でないようなところを突っ込んで話してしまったり、こちらの意図を十分に伝えることができなかったりしてしまう。

反省しないといけないところや、学ばないといけないところばかりだ。

インタビューや情報収集するにつれて、どういう人がどういうことに困っていそうか、みたいなことがぼんやりと浮かんできた。

この時期くらいから「ペルソナ」を作った。

僕自身、自分を想像力がない人間だと思っているためか「実際に存在しないけど、リアルな人の生活を想像なんてできないよー😭」なんて思ったりしてた。

しかし、これまでの調査や社内インタビューなどを通して、得られた知見があったので、それっぽいペルソナを作ることはできたのではないかなと思う。

（だた、よく聞く話のような気もするが、このペルソナが今後活用されることはなかった…。）

4. 💩ドキュメント

他にもドキュメントの書き方はめちゃくちゃフィードバックされた。

「誰に向けたドキュメントになっているのか」を考えた粒度の内容になっているのか。

エンジニアだとコードを書く時に、他のエンジニアがメンテナンスすることを考えて、可読性の高いコードや理解しやすい形で抽象化されたクラス設計をしていくと思うのだが、ドキュメントを書くことにおいても、本質は一緒。

聞いてみれば当たり前のことだが、その時の自分には当たり前ではなかった。

内容がなんであれ、書くからには、その先には相手がいるのだ🤔（この「相手」というのは将来の自分も含まれる。）

「誰に向けたドキュメントになっているのか」が考えられていない粒度のドキュメントは自己満の💩ドキュメントだ

自分自身も完璧ではないので、💩から脱却できるように意識してドキュメントを書いていかないといけない。ちょっとでも油断すると、💩に降格だ。

ドキュメントの書き方にお悩みなら「考える技術・書く技術」などが有名どころだろう。

次のnoteのポストもおすすめ。

ドキュメントなどで何かを伝えるときに大事だと思っているもの

相手の視点に立って考える

5. 手段の目的化

この時期の他の失敗談としては、知らない知識を埋めようと本やネットでけっこうな量の情報をインプットした結果として、リーンキャンバスやジャベリンボードなどのフレームワークとなるツールばかりを仮にも手に入れてしまった。

手に入れたツールはとりあえず使いたくなってしまう性分はこういう時は悪いばかりだ。

ツールを使うことが目的となってしまって混乱状態にあったのがこの時期。

手段の目的化とは、まさにこのことだなーと🤔

目的を明確化し、その目的達成に必要な手段を検討し、実行プランを立て、実行する。

これができないと、まじで詰む👿

ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー

７月後半になると、これまで得られた知見等をもとにして、どういう人にどういう課題がありそうかを取りまとめて、その課題を解決できそうなサービス案を練っていった。

【８ ~ １２月】課題仮説（イシュー）の構築 ~ β版開発スタート

6. はじめてのプロトタイピング

７月後半で議論したサービス案などをもとにして、１つのサービス案に絞った。

このサービス案を実際に検証するためのプロトタイプ開発が８月にスタート。

プロトタイプ開発は、枠をデザイナーがXDを使ってゴリゴリ作って、それをチーム内でレビューするというフローを採った。

このプロトタイプでは、複数の課題仮説するために複数の機能を用意した。

「〇〇という課題を解決するためには、こういう使い方ができて、□□という課題を解決するためには、こういう使い方ができるよ！」といったイメージ。

7. はじめての社外の人とのやりとり（相変わらずインタビューは難しい）

そうしてできあがったプロトタイプを使って、もう一度ユーザーインタビューを始めた。

今回のインタビューでは、外部の調査会社？を経由して、インタビュイーを集めた。

調査会社とのやり取りは初で、自分宛に電話がかかってきたりするのはちょっと新鮮😄

電話だけでなく、他社の方とのメールのやりとりも初。

メールのやりとりは、Slackのようにカジュアルなやりとりはできないし、相手が社内にいるわけではないので、直接話しにいって意思疎通を図るわけにはいかない。

カジュアルでない分、不必要なやり取りが発生しないように、内容に過不足がないかだったりと、こちらの意図を確実に相手に伝えることに、いつも以上に気を使わないといけないのは、慣れていない分大変だった。

調査会社に集めてもらったインタビュイー候補から、実際にインタビューする人を決めた。

１０数人を２，３日でインタビューしたので、１日３，４人ほどのインタビューをする必要があり、１日終わるとぐったりしていた気がする笑

５，６月のインタビューと違い、プロトタイプではあるが、実際にモノがあるインタビューだと、筋がよさそう。筋が悪そう。みたいなところがより表面化してくるので、その点に関してはよかったかなと思う。

結果として、想定していた複数の課題仮説のうち、１番筋が良さそう１つの課題仮説に絞ることになった。

8. どういう人のどういう課題を解決するのか

……..今振り返ると最初のプロトタイプ作成に時点で「誰のどういう課題をどうやって解決するのか」をもっと尖らせるべきだったと思う。

「こういうときには、こういう使い方ができるよ。なんでもできるよ。便利でしょ！」みたいなのは一般論としてあまり推奨されていないだろうし🤔

また、「こういう人たちが、”たぶん”使ってくれると思うなー。」くらいの確信しか持てていなかったような気がする。（今になって思えば。という話なので、当時はもっと確信を持っていたかもしれない。）

もっとペルソナをブラッシュアップするべきだったし、もっと課題仮説をブラッシュアップするべきだった。

誰にとっても便利そうなサービスは、誰も使ってくれない😇

とは言いつつも、議論や調査、インタビューばかりしていても前に進めないという側面もあると思うので、（検証スピードを早めることが前提だろうが）どこかのタイミングでプロトタイプやMVPなどを使って、実際に検証するのは必要だったのかなと思う。

ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー

１番筋の良さそうな課題仮説に絞り、この約半年間の知見の整理や、課題を解決するためのサービス案、今後の戦略構想を作成するなどを１０月末から１１月あたりにやっていた気がする。

9. β版開発スタート

サービス案の作成では、プロトタイプをページイメージもベースにしつつ、必要なページと、そのページの要件をスライドに落としていった。

それに伴って、プロダクトとして実際に動作するものとしてシステムの大枠を徐々に詰めていった。

プロダクトの設計とは別で、リリース時のチャネルやKPI、計測要件なども検討を進めていった。

サービス名もあーでもない。こーでもないと議論して、なんとか決定。

初期段階で、仮のサービス名をチーム内で呼んでいると、それが徐々に馴染んできて、結局それ１番しっくり来るよね。みたいな経験を以前していた。

今回も似たような空気感があったが、今回は「サービスコンセプト」や「ユーザーとサービスの位置付け」などをもう一度チーム内で話し合うことで、初期に呼んでいたサービス名とは違う名前になった。

１１月末から検討していた内容が固まってきて、１２月には実際に開発がスタートする。

僕自身、エンジニアとしてアサインされたものの、これまではエンジニアリング以外のことがメインで、ディレクターの手伝い、デザイナーの手伝いみたいな立ち回りがほとんどだったので、遂に自分のバリューを出しやすい領域に。

他エンジニアと相談し、「開発スピード」と「社内の知見」を中心に技術選定し、Nuxt.js + Railsの構成に決定。

インフラまわりの知見がほぼないので、インフラや開発環境構築まわりは他のエンジニアにお願いする形に。

そうして実際に開発が始まったのは、１２月末。

すぐに年末の休みに入ってしまった。

10. 一方プライベートでは

（話が変わるが）プライベートでは１１月に入籍した。

自分が想定していたよりも早いタイミング、まさか２６歳で結婚することになるとは笑

今までは自分のことだけ考えて生きていればよかったが、そうもいかなくなった。

ただ、今まではかなり自己中心的な生活をしていたので、いいきっかけだと思っている。

プライベートだけでなく、相手のことを考えた言動は、この頃から徐々に意識するようになっていったと思う。

自分ができないこと、苦手なことを、相手は上手にこなせる（本人曰く「自分も得意じゃない」らしいが）ので、プライベートでも勉強になることばかりだ。

先のことがどうなるかはわかんないけど、互いの長短を活かして、なんとかやっていこうかと笑

【１, ２月】 β版リリース!

11. まさかの後ろ倒し（それとフィンランド旅行）

年も明けて2019年になり、開発が本格スタート。

ほぼ０からWebサービスを開発するのは大学生のとき以来（４,５年ぶり？）だったので、ちょっとワクワクした🤩

Nuxt触るのは初めてだったので、どうなることかと思ったが、想定以上に早く慣れた。

僕自身、ただ内部の挙動がどうなっているか等をあまり気にしないで、とりあえずやっていきながら学習していく派であるため、なんかよくわからないけど、変な挙動してる。みたいなケースはちょこちょこあった気がするが。

....ドキュメントはちゃんと読もう😇

要件ががっちりと決まっているわけではないので、手戻りを想定しつつ、開発を進めていく。

１，２回ほど手戻りがあったが、許容範囲だと思っている。

少人数のチームなので、密なコミュニケーションができた結果ではなかろうかと。

１月末リリースの予定だったが、なんと１月末にインフルエンザ👾になってしまって、１週間動けず。

更に次週の２月１週目には旅行でフィンランドに行ったので、結果的に２週間なにもできなかった......😩

話が逸れるが、フィンランドはちょーよかったので、みんな行ってみてほしい。

お金貯めて近いうちにまた行きたい。

次はフィンランドだけではなく、その他の北欧の国にも行こうと思う。

12. β版リリース

で、旅行から帰ってきたら開発を再スタート。

なんとか２月の中旬にはβ版としてリリースすることができた！

バグが大量に出ないか不安だったが、なんとかサービスが止まるレベルの障害を出さずに済んだのは一安心😊（難しいことしているわけではないので、そもそもサービス止まるレベルの障害が起こる可能性って限りなく０なわけだが。）

年末年始やインフルエンザ、旅行などの休みも含めると２ヶ月半ほどかかってしまったのは反省点としては残る。

結局その間は、検証できないので、Build-Measure-Learnのサイクルが止まってしまっているわけだ。

もっとミニマムな実装はきっとできたはず。

単機能プロダクトでの検証や、LPのみでの検証の可能性をもっと模索するべきだったのではないかと思う。

２月以降の検証フェーズにも関わってくる話ではあるが、程度に差があれどプロダクトを作り過ぎてしまうと、捨てることに対する心理的ハードルも上がるし、（本来やるべきフェーズではない）機能のブラッシュアップにリソースが割かれてしまう可能性がでてくる。

作る側の人間は、自分の領域について神経質になりがちだと思うが、自分の成果物が捨てられたり、おろそかにされたりすることが、自分のスキルや人間性を否定されることとイコールでないことを定期的に言い聞かせないといけないなと思った。

検証フェーズにおいて、チームが求めるべきことは「学習速度を上げること」である。

「自分たちが信じる仮説は正しいのか？」「正しくないとしたら、それはなぜか？」「その仮説を検証するための最速な方法とはなんなのか？」にフォーカスすべき🧐

精度の高いアルゴリズムを書くことや、メンテナンス性のあるクラスの設計にこだわってる暇があるなら、さっさとコード書いてリリースすべきだ。

Done is better than perfect.だ。

【３ ~ ５月】検証スタート

13. 課題の抽出

β版リリース後はPDCAを回して、サービスグロースの可能性を検証していくフェーズに移った。

ユーザーがランディングしてから、目的の情報までに到達し、最終的に定義したコンバージョンするまでをファネルにし、各ファネルのフェーズに対応するページで、ユーザーが遭遇するである問題（離脱の原因）を抽出していく。

ここで抽出した問題は、表層的な問題であることもあるので、「なぜ？」を積み重ねて、本質的な課題にブラッシュアップする必要がある。

なぜか🧐？

例えば、ボタンをタップしない原因が「テキストを読んでいないからではないか？」という問題があったとする。

この問題に安直に飛びついてしまうと、読みやすいテキストにするという対策を入れることになる。つまり、文字サイズを大きくする。文字に色を付ける。などの修正を入れるということになるだろう。

しかし、「なぜテキストを読んでいないのか？」をもう一度落ち着いて考えてみると、例えば、そのページでユーザーがテキストを読みたいと思ったときには、すでにページからテキストが外れているかもしれない。

そうなってくると、文字のサイズや色の問題ではなく、情報設計という観点からページを見直す必要性が出てくるというわけだ。

僕のように、とりあえず手を動かしてみようよタイプの人間だとあまり深く考えずに表面的な事象に飛びついてしまう。

現象や観察事実を論点と間違えないこと。一般的に問題点と呼ばれるものの多くは、現象や観察事実であって、論点でないことが多い。現象を論点ととらえて問題解決を図ろうとしても、多くの場合、成果はあがらない。論点思考より

常に「なんでだろう？🤔」を問う姿勢は本当に重要。

特に３，４月とかは、これ関連でうまく取りませなかった施策があるなと反省。

５月あたりから徐々に改善の兆しが見えてきた。

いったん腰を据えて、時間がかかってもいいので、じっくりと考えることが重要だが慣れの問題でもあるかなと思うので、（イシューを見極めるんだ。という意識のもとで）反復練習をやっていくしかないなというのが現時点の考え。

今後も無意識レベルに昇華するまでは、反復練習していくつもりだ。

14. 施策への落とし込み

ブラッシュアップした課題に対して、それを解決するためのHowの部分が実際の施策として落とし込まれる。

最小限の工数で、最大限の検証効果を出すことをベースとして、有効そうな施策を考える。

有効そうな施策が決まると、ページイメージをモックレベルで作成する。

場合によっては、そのページを成立させるための機能についても検討する必要があるだろう。

振り返えってみると、↓のような内容を明確にできていると、チーム内での共通認識が取りやすいなーと思ったので、今後に活かしたい🧐

誰のためのものなのか？

（そのページ・機能がない）現状で、その人たちはどうやっているのか？

（そのページ・機能を提供したら）その人たちの今後を取り巻く状況がどう変わっていくのか- ユーザーストーリーマッピング

15. プロジェクトを回す

施策についてチーム内で整合を取り、デザインが必要な場合は、デザイナーに依頼する。

詳細なデザインができあがるまでに、エンジニア（僕）が大枠のフロント、サーバサイドを先行開発し、最終的に出来上がったデザインを反映するフローに。

デザインが上がってくるまで、エンジニアの工数を使えないという事象が起こる頻度は、極力抑えられたと思う。

これは、人数が少ないチームだったというのが大きい。

エンジニア１人、デザイナー１人だったので、２人の口頭レベルで整合を取ってしまえばよかったからだ。

逆に言うと、少しでも人数が増えると、通用しない可能性もあるので、そのことだけは念頭に入れておくことにする。

今まではプロジェクトを回した経験がなかったので、考慮漏れがあったり、スケジュールの進行が遅れたりと、うまくできなかったことばかり😫

失敗は徐々に修正していくしかないので、愚直にやっていくしかないかなと思っている。

16. 結果から示唆を得る

そうして、実際に施策を実行した結果が、数値に表れる。

この数ヶ月で、Google Analyticsで数値をゴニョゴニョすることがだいぶできるようになった。

母数を十分ではないことの方が大半だったため、統計的に確からしい数値にはなっていないかもしれないが、施策前後で、離脱率やコンバージョン率などをマクロに観察し、「実行した施策によってどういうことが言えそうか」の検証結果を作成していく。

時には、ユーザーひとりひとりの行動ログを追って、どういう行動をしているのかをミクロに観察したりもした。

「もしかすると、このユーザーはこういうことを思っているかもしれない。」「だとすると、こういう施策で、このユーザーの問題を解決できるかもしれない。」といった仮説が立てられたりするのでおすすめ。

あと、「計測」はチームが学習するために必要不可欠な要素であるので、いくらスピード優先だからといって、あまり雑に計測要件を設計してしまうと、逆に学習速度を落としてしまう結果になる可能性があることを念頭に入れておいた方がよい。

今後は「イベント名はどういう命名にしたほうが、後から分析しやすいのか。」「Google Analytics上のこの変数定義は、どういう意味があるのか。」などを１つ１つ丁寧に処理していこうと思う。

17. 検証終了

そうこうしているうちに検証期間は終了した。

結果として、β版はいったんクローズすることになった。

リリース当初からβ版のクローズは想定していたことなので、単純に結果が悪かったからというわけではない。

β版をブラッシュアップするのか、ピボットするのかはまだわからないが、これでおしまいではないだろう。

２回目のZero To Oneも楽しみつつ、苦しむことにする。

【おわりに】

機能を作る、はたまたサービスを作るためには、自分１人の力だけではうまくいかないことが多いのだなと身をもって改めて知れたことは非常に大きい資産になったなと思う。

今までは、どちらかというとエンジニアという１００％プレイヤーの領域からでしか見えてないものばかりだったが、他領域でプレーすることを通して、より高い視点に自分を置けた経験は今後に活かせることがたくさんあるだろう。

ちょっと長くなってしまったが、こんな１年。

最後にもう一度言っておくと、これはあくまで個人的な感想と今後の思いなので、会社やチームメンバーの見解とは異なる点はもちろんあると思っている。

ただ、また半年後か１年後か、もっと後に見返して、「何言ってんだ、こいつは😒」という感情になりたいがために、セーブポイントとして設置しておきたかっただけ。

おわり。

（こんな長い文章を書いたのは生まれて初めてかもしれない。）

参考図書

この１年で事業開発関連で読んだ本を載せておく。参考になれば。

リーンスタートアップ・サービスグロース系

リーン・スタートアップ

Running Lean

起業の科学

ジョブ理論

実践ジョブ理論

トラクション

アントレプレナーの教科書

グロースハック完全読本

グロースハックの教本

逆説のスタートアップ思考

７日間起業

思考系

ロジカル・プレゼンテーション

問題解決プロフェッショナル―思考と技術

イシューから始めよ

考える技術・書く技術

戦略シナリオ思考と技術

戦略思考コンプリートブック

「誰のため？」「なんのため？」から考えよう

仮説思考

論点思考

外資コンサル知的生産術

アナロジー思考

メタ思考トレーニング

具体と抽象

頭がよくなる「図解思考」の技術

早く正しく決める技術

意思決定入門

ビジネスモデル系

ブルーオーシャンシフト

マンガでやさしくわかるブルー・オーシャン戦略

プラットフォームの教科書

ビジネスモデル

ジェネレーションビジネスモデル設計書

新事業開発スタートブック

HotPepper ミラクルストーリー

ビジネスモデル全史

ITビジネスの原理

リクルートすごい構創力

マーケティング系

トラクション

エッセンシャル

デジタルマーケティング

USJを劇的に変えた、たった１つの考え方

ネットで「女性」に売る

マーケット感覚を身に着けよう

プロダクト開発手法系

Inspired

SCRUM BOOT CAMP

SPRINT

ストーリーマッピング

プロジェクトマネジメント系

トヨタ公式段取りの教科書

いちばん大切なのに誰も教えてくれない段取りの教科書

ユーザーインサイト・UX系

欲しい」の本質・仕掛学・考具・予想通りの不合理

SEO系

10年使えるSEOの教科書

数値分析系

新しいアナリティクスの教科書