こんにちは、新たにROXXのCOOとなりました、植木です。

COOになる前は新規事業責任者として新規事業の立ち上げにコミットしていたことから、今回は事業づくりをテーマとしたnoteを書きます。

コンセプトは、”合理の先にあった葛藤の昇華"です。フレームワークやセオリーに溢れた世の中ですが、事業づくりはフレームワークやセオリーのように美しく進むものではなく、毎日が葛藤だらけでした。その葛藤の中にこそ、これから事業をつくる方にとって少しでもお役に立てることがあるのではないかと思い、実際の葛藤をベースにnoteを書きました。起業家・経営者・新規事業責任者など、事業立ち上げに関わる方々にとって、少しでもお役に立てますと幸いです。(以下常体で失礼します)

合理性だけで事業をつくれるのか

まず最初の葛藤は、合理性だけで事業はつくれるのか、という葛藤である。

今までは合理性を大事に仕事をしてきた。ファクトをもとにフラットに判断する、課題を特定し要因仮説をもとに施策を実行・検証しながら、PDCAサイクルを回す。

新規事業に向き合った期間も同様に、フレームワークやセオリーを活用しながら可能な限り合理的に事業立ち上げを試みた。しかし、どれだけ美しく整理されたフレームワークやセオリーも、その事業ドメインや会社独自の制約条件などを加味すれば、そのまま実行し想定通りの結果が得られることは少なかった。

また、偉大な諸先輩方の事業立ち上げの振り返り情報を聞けば聞くほど、事業を成功に導いた重要な要素を構築したのは、意思決定時点の情報である意味では合理的に(正しく)意思決定をした結果とは言い難いものが多かった。(結果論として、現マーケットの勝者の状況や競争環境の変化などを加味して合理的だ、と説明するのは難しくないかもしれないが、当時の状況及び情報量で、自分は同じ意思決定をできたか？という問いにYESと答えられることは少ないと感じた、自分の不足として)

新しい事業をつくろうとした時、その事業が存在しない理由が存在する。そもそもユーザーに課題が存在しないケースもあるが、N1のユーザー課題が特定できている場合には、当該課題を継続的に(事業として利益を創出しながら)解決することが困難な理由があるはずである。
つまり新規事業をつくることを決めた瞬間に、誰かが過去にアイディアを考えたが実現できなかったことを実現する必要があり、それは誰かが解けなかった課題を解く必要があることを意味する。基本的には合理的な判断をしながらも、ポイントごとに非合理に見える意思決定を意図して行い(もしくはがむしゃらに事業に向き合った結果、半ば気合いで勝ち筋が見えるetc)、合理的な意思決定だけでは解くのが困難な課題を突破できるかが、事業立ち上げにおける成否を分けるのではないか、と考えるようになった。

特にバリュープロポジションを構築するにあたり、競合他社にはつくれない価値を構築するポイントにおいては、一見非合理な意思決定による"突破"が必要だと整理した。その突破には調査をもとにしたデータやユーザーヒアリングなどのファクトというよりも、自分たちが信じる未来からの逆算によるある意味で狂気的な意思決定が必要なのではないかと。いわゆる「普通はそんな意思決定できない…」「そのタイミングでよくそこにはれる…」と偉大な企業たちのストーリーで出てくるような打ち手が必要になるのではないか。つまりは、合理的に事業を立ち上げようとしていた自分には、偉大な事業はつくれないのではないか、という葛藤が常にあった。

とはいえ、未来から見れば合理的で・現時点では非合理な意思決定とはどのようなもので、どのようなタイミングでどのような思考プロセスで行なっていくべきか、を言語化・説明できるレベルに残念ながら今の自分はない。"正解はない"という前提の中で、どのイシューについて非合理な意思決定での突破を試みるのか、その共通認識をチームでどのように取るのか、この辺りが重要になると理解している。

そして何よりも大事だと言えるのは、美しく綺麗にやる、ではなく、自分たちが信じる未来や事業に(特にユーザーや顧客に)がむしゃらに向き合うこと。そして、仮説検証による積み上げを大事にしてやってきたからこそ言えるのは、検証という言葉に逃げない"意思"が必要だということだった。

事業立ち上げ前に何を整理すべきか

立ち上げる事業を決めるタイミングにも、非常に多くの葛藤が存在した。この事業で事業立ち上げの目的は達成できるのであろうか、現状のソリューション仮説でユーザーや顧客の課題は解決できるのであろうか、などの葛藤がないと言ったら嘘になるが、そこは前に進めることでしか解は得られない。特に葛藤があったのは、早く実行するに越したことはないと理解しながらも、事前に何を整理しておけば、手戻りが少ないのか？という葛藤である。分析からバリュープロポジション・ビジネスモデルなど多くのフレームワークが存在するが、事業立ち上げ前の段階でどこまで事前に整理しておくべきか、また調査やリサーチなどはどこまで行うべきなのか、など葛藤は尽きない。特にステークホルダーが多い場合には、共通認識のために可視化する項目が過度に増え、変わる可能性が高い情報の可視化にコストがかかる。

事前に抑えておくべきだと整理したのは以下である。下記要素を現状の仮説ベースでドキュメントに書き起こし、事前準備に時間をかけずに最短でアクションしていくのが良いと整理した。仮説構築に必要な最低限の調査などは行う。それ以外は特にスタートアップにおいては、悪手となる。(事前に決めたアイディアや仮説がそのまま綺麗に当てはまり、そのまま事業となることは、ほとんどないという前提に立って、とにかく早く検証を進める)

PMFの定義とPMFまでのステップをどのように描くべきか

事業を立ち上げた後は「まずはPMF状態を目指す」のがセオリーだが、PMFの状態をどのように定義すべきか、またPMFまでのステップをどのように設計すべきか、についても多くの葛藤があった。

そもそもPMFは、"プロダクトとマーケットがFITした状態"という抽象的な定義であり、その中でどのような状態を目指すべきかは、事業ドメインや会社の状況や制約によって最適な定義は異なる。あらゆる先行事例の定義を見ても、"市場から求められている状態"というのが抽象化された共通定義であった。("坂道から下り坂に変わるような変化が現れる状態"という表現がわかりやすかった)　つまり、多くのケースが、"結果的にわかる状態"としてPMFを表現していたからこそ、事前に定義する目標としてPMFの状態を定義するのが難しい。

では、事業を立ち上げる際に、PMFという状態を設定して何がしたいのか、から考えるべきだと捉えた。それは、PMFとは追加投資すべきかの判断を明確にするための状態目標と言えるのではないか。つまり、検証フェーズから拡大フェーズへの移行タイミングの分岐点である。その上で、PMFの抽象的な状態定義は下記の要素が満たされた状態だと整理した。これをマーケットや事業ドメインなどに照らし合わせ、各事業の指標で定義するのが良いのではないか。

また、PMFまでの検証ステップについては、セオリー通りにFITジャーニーをもとに進めるのが良いと考えている。明確にステップを区切ることで、仮説が棄却されたときに、不要な手戻りが少なくなることが利点である。

しかし、あくまでもFITジャーニーは検証におけるステップであって、アイディアがない状態で、顧客は誰でどんな課題があるだろう？と1つずつ検証しながら進めていてはおそらく事業は立ち上がらない。顧客セグメント・顧客課題・解決策・プロダクト提供方法が、仮説ベースで言語化されており、検証の結果、どのフェーズで仮説が棄却されたとしても、次に取り組むべき仮説が明確な状態を常に作り続ける必要がある。つまり、FITジャーニーはあくまでも検証ステップやチームでの共通認識を取るための手段であり、事業立ち上げに責任を持つ人の頭の中では、常にPMFまでの仮説上での分解を考え続ける必要がある。この仮説が間違っていたら、このセグメントのこの課題にこのソリューションが良いのではないか？などの思考の具体と抽象の往復を常にし続けるイメージである。仮説が棄却されることを前提として、複数のFITパターンを頭の中で用意しておく必要がある。

PMFまで最短で進めるチームはどのようなチームか

PMFまでの道筋が見えた際には、とにかく早くその状態に達したいが故の葛藤が生まれる。どのようなチームで進めるべきか、いつ人数を増加すべきか、という葛藤である。

事業づくりは、常に期限との勝負である。無限にリソースをかけ続けられる事業はほとんどないはずである。だから、不安は尽きないし、常に焦りが伴い、とにかく最短最速で検証を進めたいと考え、リソース投下については葛藤する。少しでも勝ち筋になりそうな兆しが見えた瞬間に、リソースを増やして検証や拡大の速度を速めたくなる。

しかし、PMFを達成して拡大するフェーズまではとにかく最小人数で進めるべきである。多くても2.3人で進め、検証速度は人数の増加で速くならないという認識を持つべきである。特に初期検証は、ユーザーの声や母数の少ないサンプルを正として、仮説構築、検証を繰り返していく作業であり、このフェーズにおいては、多様性すらも検証速度を阻害するリスクがある。検証する前の仮説に疑念が生まれ、検証実行までに無駄な時間を要したり、仮説自体が合議で形成されることによりシャープな仮説が構築できないことから得られる検証結果の学びの総量が減少したりする恐れがある。

また、このフェーズにおける説明責任は、合理により過ぎた意思決定を推進する圧力になる可能性があり、非合理な突破を阻害することがある。事業には、「論理的には説明が難しいが、実際に数字としてそうなっているorユーザーは〜という行動をしている」という説明が"突破の事後証左"としてなされているケースは散見される。大きなチームでの探索や、経営陣や関係部署などの関係者の関わり方次第では、実行前の合理によりその可能性を紡ぐこともあるかもしれない。

とにかく小さなチームで、仮説構築〜検証においての実行精度に変数が最小で、相互の信頼関係が深いチームが必要である。

ユーザー課題の解像度をどのようにあげ続けるか

ユーザー課題の解像度をどのようにあげ続けるか、についても、非常に多くの葛藤があった。ユーザーや顧客課題の解像度の重要性については議論の余地がないが、ヒアリングでユーザーや顧客の声は得られたが、「この発言を正として事業を推進しても良いのか？」「ユーザーは本当のことを言ってくれているのか？」などの葛藤がある。

まずはユーザーに最短で直接ヒアリングする。しかし1度きりのインタビューで、ジョブを実行する背景・状況、"真の理由"まで捉え切るのは難しいと感じた。そこで、事業立ち上げにおいての深いユーザー理解を目的とし、いかに継続的にソリューション仮説やプロダクトにフィードバックをいただける関係性を構築できるかを、ユーザー理解における重要イシューに設定した。将来的にどのようなサービスをなぜ提供したいのか、あなたのような境遇の方に少しでも価値を提供したいという想いを率直に伝えて、その場で次のヒアリングを設定するようにした。(初回でそこまで実行するのが大事)　もちろん貴重なお時間をいただく以上、謝礼はあった方が良いが、対象となるユーザー属性によっては、一緒にサービスを作ること自体をインセンティブとしてご協力いただけるケースもあるので、ユーザーにとって最適な謝礼を考え抜く。継続的にプロダクトにフィードバックをいただける対象ユーザーが何名いるかは、チームにおけるユーザー課題の解像度に大きく影響する。

そしてユーザーのヒアリング情報は、すべてドキュメント化し、チーム内で共有する。その際には、"誰が" "どのような発言をしたか"を、必ずセットで共有する。また、ヒアリングしたユーザーが、初期セグメントの対象ユーザーなのかを"切り分けて"共有する必要がある。ユーザーの声が大事なのは間違えないが、対象となるセグメント以外のユーザーの声は、PMFまではノイズになりうる。「ユーザーが〜と言ってました」と情報は非常に強力な判断要素となるからこそである。しかし、対象のユーザーの声だけを共有すべきかというと、対象となるセグメント以外のユーザー情報も含めて共有するのが良い。なぜなら、対象以外のユーザーのヒアリング情報自体が、解決したいユーザーの解像度を上げるからである。

スケール可能性をどう見極めるか

上述の通り、ユーザー課題やPMFまでの仮説検証に向き合えば向き合うほど、事業としてのスケール可能性についても、常に葛藤がある。時には、現在特定している課題は、特定少数のユーザーセグメントにしか存在せず、早々に成長が止まってしまう(スケールしない)事業となのではないか、という恐怖と対峙することとなる。

では、スケール可能性をどのように見極めるべきかというと、ウルトラCのような方法はなく、やはりユーザーの課題を正しく把握し、当該課題の既存ソリューションの市場規模などのマクロデータを参照するしかない。もしくは現在そのような市場が存在していなかった場合でも、"当該課題を抱えているがソリューションが存在していないが故に行動(課題解決)に至っていないユーザー"がどれくらいいるのか、のマクロデータからの類推をするしかないのではないかと考えている。上記を正しく把握できていれば、ユーザー課題に深く入り込んだり、検証の解像度を上げたとしても、常にその先にあるスケール可能性を信じながら前に進むことができる。

また、ユーザーセグメントの広がり方や順序を正しく知っておくことも、スケール可能性に関連する重要な変数となる。対象となる市場のユーザーセグメントは、どのような軸でどれくらいの規模の塊が、どれくらいの数存在するのかを、可能な限り正しく把握・整理する。そして、初期セグメントに対してPMFした後には、次にどのようなセグメントに対して、どのようにソリューションをアップデートすること価値提供をしていくのか、について解像度高く整理できていればいるほど、スケール可能性について懐疑的になることは少ない。(しかし、実態としては初期セグメントに向き合っていればいるほど、次のセグメントのことを考える余裕はほとんどない&論理的にセグメント毎のFITを描くことは難しいのが実態であるが)

探索とコミットをどのように切り分けるべきか

本noteで取り上げる最後の葛藤は、探索とコミットをどのように切り分けるべきか、である。「営業を頑張ることで売れちゃっているけどなんか手応えがない」という状態などは、コミットを重視して進めた結果、事業成長が止まる日がやってくる可能性を否定できない。「事業立ち上げなんだから、コミットすべき、だけど、ここは自分たちを変えるべき？」と疑心暗鬼になることは少なくない。

探索は、ユーザーや顧客を常に正として、自分たちの課題の捉え方やソリューション仮説を修正する活動であり、自分を変えるという内向きのベクトルの活動である。一方でコミットは、自分たちの課題の捉え方やソリューションを正として、ユーザーや顧客に態度変容を促す活動(いわゆる営業活動はこの活動をしていることが多い)で、態度変容を促すというベクトルである。最初の章にも記載したが、事業にはコミットによる突破が必要なのは疑う余地はない。しかし、初期のコミットは、正しい顧客理解や検証を阻害する可能性があり、その突破によりその場の状況はクリアできたとしても、未来の事業成長速度を阻害する可能性がある。一方で、初期の限られたリソースや時間で、完璧なPMF状態を構築できることは少ない。だからこそ、探索とコミットの切り分けが非常に難しく悩ましい。

現状の見解としては、可能な限りPMFまでは探索というスタンスを貫くべきであると考える。期限は、常に行動に対する期限を設定し、状態目標に期限を設定するようなことはすべきではない(撤退ラインの設定の議論とのバランスが難しいが)。一方で、検証に母数が必要なタイミングや、一定探索から強く信じられる仮説が見つかったタイミングでは、探索からコミットにスタンスを切り替え、状態に期限をセットした上でコミットすべきである。

これを切り分けなければ、コミットすべきタイミングで、ユーザーの声をもとに何度も何度も仮説を修正し続け、前に進まない状況に陥ったり、コミットすべきでないタイミングで顧客の声を無視して初期トラクションができて、仮説の修正が行われないまま後戻りが難しい状況に陥ってしまう。
正しい切り替えができなかったとしても、そもそもこの切り替えをすべきだとチームで共通見解をとる、切り替えたタイミングで目標設計を状態か行動かを切り分けるべきだという認識を持つだけで、立ち上げの進めやすさは大きく変わる。

最後に

成功確率は数%と言われる事業立ち上げだからこそ、不確実性に対峙し続けられるチームは尊い。事業の立ち上げで失敗した時に、「やっぱり難しい」と土俵から降りてしまうのか、(難しいことはやる前からわかっていたはずで)得られた学びをもとにそれでもチャレンジし続けるのか、それが事業をつくれるチームとそうではないチームを分けるのではないか。
そして、何度もチャレンジできる&したいと思えるカルチャーと仕組みをつくれる会社こそが、連続的に事業を立ち上げられる会社になるのではないか。

今後もそんなチームや会社でありたいと思いながら、同様に暗闇の中で邁進し続ける世の中の0→1に向き合うチームや個人に最大のリスペクトを送りつつ、少しでも多くの価値を世の中に流通させるべくこれからも頑張りたい所存です、一緒に頑張りましょう。

約1年ぶりのnoteなので、乱文となり申し訳ありませんでした。もはや、何を書きたいのかも分からなくなってしまいましたが、いくつかの整理や言語化がエッセンスとなり、事業立ち上げに向き合っている方々に、少しでも何かしらの価値を提供できると嬉しいなと思っています。

リアクションがあれば、「また書こう」という気持ちになれるので、少しでも面白いと思っていただければ、ぜひX(旧Twitter)などのSNSでのシェア、スキやコメントを何卒お願いいたします。(Xシェアが一番嬉しいです)

最近は事業立ち上げに向き合ってきた2年間だったので、外部での学びを増やしていきたいと思っているので、新規事業や事業関連で情報交換したい方などがいらっしゃれば、ぜひX(旧Twitter)でお気軽にDMいただけますと幸いです。　勉強させてください！

最後までお読みいただき、ありがとうございました。