基礎編では、ゴールの状態を成立条件に分解し、反事実で検査して計画に落とすという手順を扱ってきました。
ここからは、その手順を事業開発のプロセス全体に当てはめていきます。
本章は、プロセス編の地図です。
事業開発の流れは、次の3区間でできています。
- 入口（セットアップ）: テーマを決め、アイデアを出して選び、コンセプトに固める。1人でも進められる工程で、コンセプトが固まって初めて最初のステージに入れます（事業開発の始め方）。
- 推進（ステージ）: 事業が成立するための条件を、1つずつ確かめていく。成立条件ごとにステージがあり、CCF から Growth まで順に走ります（本章の後半と、各ステージの章）。
- 出口（撤退・ピボット・移譲）: どのステージにいても、撤退基準に触れれば止め、方向を変えるなら手前のステージに戻り、事業になったら既存の組織へ移す。最後にだけ来るのではなく、途中のどこでも起こり得ます（事業開発の閉じ方）。
本章では、この3区間のうち推進の区間、つまり成立条件をどう並べるとステージになるのかを説明し、そのうえで各ステージの中で繰り返す工程と、出口との関係を扱います。
成立条件を検証の順に並べるとステージになる
「この案件が事業として成立している」という究極のゴールを据え、すべての根本となるスキルで使ったのと同じ問いを投げかけます。
その状態を成立させるのに1つでも欠けてはならない条件はなにか？
業界やビジネスモデルによって細部は異なりますが、構造をたどっていくと、おおむね7つの成立条件に行き着きます。
これらを確かめる順序は、事業開発の進め方の三原則「最大の不確実性から順に潰す」が基本です。そこへもう一つ「検証コストの安い順に並べる」という鉄則を加えて決めます。
机上のリサーチから始め、顧客へのインタビュー、簡易なプロトタイプ、実際の製品、本格的なマーケティング投資へと、徐々にコストをかけていきます。
こうして並べた成立条件の列が、そのままステージの列になります。右端が、各条件を確かめるステージ（の章）です。
| 成立条件 | 達成のイメージ | 対応するステージ |
|---|---|---|
| 自社が今やる意義がある | 自社の資産や立場で強みが説明でき、なぜ今着手すべきかを言えて、顧客に聞きに行けるだけ仮説が具体的になっている | CCF（Concept Company Fit / 自社適合検証） |
| 顧客がその課題を持ち、対価を払ってでも解決したい | 課題の実在性と対価支払い意思が、顧客インタビューで再現して確認できている | CPF（Customer Problem Fit / 課題検証） |
| 解決策を体験すると依存する | プロトタイプやトライアル営業で、リリース後の契約意向と最初に狙う顧客層の反応が確認できている | PSF（Problem Solution Fit / 解決策検証） |
| 提供可能な形で価値を届けられる | 品質保証・料金・自走可能性・チャネル経済性の初期セットが揃っている | SPF（Solution Product Fit / プロダクト検証） |
| 投資すれば儲かるファクターがある | マストバイ・競合優位・経済合理性が KPI 体系で説明できる | PMF（Product Market Fit / 市場検証） |
| 選ばれ続けるチャネルを再現できる | 最初の数社だけでなく、再現性のある売り先が確立されている | GTM（Go-to-Market / 市場投入） |
| 規模が拡大しても価値が劣化しない | 組織が大きくなっても顧客体験が維持される体制ができている | Growth（成長性確立） |
7つすべてが成立した世界を想像してみます。自社の強みが活き、顧客がお金を払ってでも解決したい課題があり、解決策に依存する。利益が出て、規模も拡大できる。確かに事業が成立しています（十分性の検査）。
逆に1つでも欠けたまま事業になる世界は描けません。「顧客はお金を払ってくれるが、自社の強みが活きない」なら他社に負け、「解決策は素晴らしいが、提供コストが赤字」なら長続きしません（必要性の検査）。
安い検証で落とせる案件を高い検証まで運ばないことが、成功に至るための基本の方程式でいう「案件リソースを減らす」ことに直結します。
ある製造業の保全部門では、顧客が本当に困っているかを確かめないまま、数百万円をかけてシステムのプロトタイプを作りました。数ヶ月後、現場の誰もその機能を欲しがっていなかったと判明したのです。
画面イメージを持ってインタビューに行っていれば、数日で、ほぼ無料で同じ事実が分かったはずです。
恐ろしいのは成功しないことではありません。撤退でもピボットでも、なぜ成立しないのか論拠ができていれば学びになり、次に進めます。恐ろしいのは、検証が進まないままリソースを使い続けてしまうことです。
一般的なステージゲートとの違い
これは広義ではステージゲートと呼べる仕組みですが、一般的な運用とは異なる点が大きく4つあります。
- 審査ではなく確認である：ゲートは合格をもらうためのセレモニーではなく、「次の検証に進んで投資が無駄にならない状態か」の確認です。
- 最初に自社適合（CCF）がある：アイデアの良し悪しより先に、自社が今やる意義から確かめます。ここが抜けていると、後になって「儲かるかもしれないが、うちがやる事業ではない」とひっくり返る事故が起きます。
- ステージの仕事を先取りしない：インタビューの依頼はCPFに入ってからとし、実用最小限の製品（MVP）の計画はSPFで立てます。先の仕事に手を出してしまうと、手前の検証が不十分なままリソースがロックされ、出戻りが発生したときのダメージが大きくなります。
- 前に戻ることができる：ピボットをする場合は、保持した検証結果に応じたステージへ戻って探索を再開します。たとえば、ターゲット顧客は同じまま解決策だけを変えるのであれば、CPFで確認した課題の実在性は持ち越せるため、PSFから再開できます。
CPF、PSF、PMF といった名前は、リーンスタートアップの周辺で広まった一般的な語彙をそのまま使っています。名前を覚えることに意味はなく、大事なのは「どの成立条件を、どの順で確かめるか」です。名前は、その順序を指すためのラベルとして使ってください。
ステージの中の工程
どのステージにいても、繰り返す工程は「実行」「評価」「計画」「申請」の4つです。検証を実行し、結果を評価し、次を計画して、申請します。
ここでいう計画とは、常に「次のステージの準備」を指します。たとえば、CCFにおける計画は、次のCPFでインタビューに進むための準備のことです。最初のステージであるCCFに進むための準備は、ステージに入る前のセットアップの段階で進めます。
また、評価は審査の日だけの特別なイベントではありません。ゾンビ化とは何かで触れたように、評価は日常の営みです。検証結果が出るたびに期待値の分布を更新し、撤退基準と突き合わせます。
「10社中8社から断られた。これは撤退基準に抵触するのではないか」と、定例ミーティングのたびに自分たちで評価します。これを続けているチームにとって、ゲートの審査は準備のいらない状況共有になります。
ステージが進むほど、見込みの幅が狭まる
ステージが進むとは、その案件が「どれくらいの事業になりそうか」という見込みの幅が狭まることです。
ゾンビ化とは何かでは、これを期待値の分布と呼びました。
CCF に入ったばかりの案件は、大化けする可能性もあれば、ゼロで終わる可能性もあります。見込みの幅が最も広い状態です。
CPF で「10社中7社がお金を払ってでも解決したいと言った」事実が得られれば、ゼロに近いシナリオが消えます。
PSF でプロトタイプへの依存が確認できると、確からしさはさらに一段階上がります。
検証結果が出るたびに幅を狭めていき、見込みが十分に立った案件だけが、次の大きな投資に進めるのです。
だから事業開発は、確かな手応えが出てくるほど投じる額を増やせる、段階的な投資であるべきです。
CPF の段階で大きな予算はつきませんが、PSF で顧客の強い依存が確認できれば、その後の製品開発に大きく投資できます。
裏を返せば、幅が狭まらないうちは、投資を抑えなければなりません。手応えがないのに活動量だけを増やし、検証コストばかりが高騰していく状態は危険です。
撤退の根拠には、検証コストが高すぎるという理由も含まれます。幅を狭めるために次に必要な検証のコストが、得られる確信に見合わないと判断できれば、それはリソースを別の有望な案件に回すための前進です。
止める・戻る・移すの手順は、事業開発の閉じ方（撤退・ピボット・移譲）で扱います。出口は最後のステージの先にあるのではなく、どのステージからも出られる扉だと考えてください。
プロセス編の読み方
本章以降は、事業開発のプロセスを入口、推進、出口の順に解説します。
次章の始め方の章と、最後の閉じ方の章は、全体像を把握するために通読をおすすめします。
間の各ステージの章は、ご自身の案件の現在地に合わせて辞書のように引いてください。どの章も、メインの問いとゴール、成立条件と達成条件、進め方、通過の目安と出口、落とし穴という共通の型で整理しています。今自分が取り組むべき論点に迷ったとき、立ち止まって確認するためのリファレンスとして活用いただければ幸いです。
それでは、ステージに入る前のセットアップとなる事業開発の始め方（テーマ設定・アイデア創出・コンセプト化）へ進みましょう。