新規事業のプロセス｜4フェーズの構造と各段階で残す成果物

新規事業のプロセスという言葉は、実務では二通りの意味で使われています。ひとつは担当者が日々こなす作業の順序、もうひとつは組織が事業案を段階に区切って扱うための構造です。前者は個々の案件で変わりますが、後者は組織として一度設計すれば、複数の案件に繰り返し適用できます。

多くの企業で問題になるのは後者の不在です。フェーズという言葉は使われていても、各段階の境界がどこにあるのか、どの状態になれば次へ進んだといえるのかが定義されていません。結果として、進捗報告は「調査中」「検討中」の繰り返しになり、案件同士を並べて比べることもできなくなります。

本記事では、新規事業のプロセスをフェーズ構造の設計という視点から整理します。フェーズを区切るのは時間でも作業でもなく、その段階で確定した情報であるという前提に立ち、4つのフェーズの定義、各段階で残す成果物、自社のプロセスを組み立てる手順を順に解説します。

新規事業のプロセスとは何を指すか

新規事業のプロセスとは、着想から事業化までを複数の段階に分け、各段階で「何が確定していれば次へ進めるか」を定義した構造を指します。作業の一覧ではありません。作業は状況に応じて変わりますが、確定させるべき情報の順序は事業案が変わっても大きくは変わりません。

この違いは実務上の扱いに直結します。作業の順序として定義したプロセスは、案件ごとに事情が違うという理由で簡単に例外を生みます。一方、確定情報の順序として定義したプロセスは、どの案件にも同じ問いを投げかけられるため、例外が生まれにくくなります。

もうひとつの要点は、プロセスが不確実性を段階的に減らすための装置だということです。初期の事業案は仮説の塊であり、確度の低い情報しか手元にありません。段階を追って確度の高い情報に置き換えていくからこそ、投じる資源を段階的に増やしても安全になります。

この順序を飛ばすと、確認不足のまま資源を投じることになります。顧客課題の確認を省いて開発を先行させ、完成後に需要がないと判明すれば、投資の大半は回収できません。プロセスは、こうした手戻りを構造として防ぐ役割を担います。

フェーズを区切る基準は「成果物」に置く

フェーズの境界を何で定めるかは、プロセス設計の中心的な論点です。期間で区切ると、進捗にかかわらず時間の経過だけで次へ進んでしまいます。作業で区切ると、作業が終わっただけで何も確定していない状態が「完了」と扱われます。

現実的な基準になるのが、その段階の終わりに残す成果物です。成果物とは資料そのものではなく、資料に書かれた確定情報を指します。顧客インタビューを何件実施したかではなく、その結果として「誰のどの課題が実在すると確認できたか」が成果物です。

この置き方には副次的な効果もあります。担当者は次に何を作ればよいかが明確になり、報告のための資料づくりと本来の検証が混ざりません。評価する側も、資料の厚さではなく確定情報の中身で進捗を測れるようになります。

一方で、成果物の様式を細かく規定しすぎると、書式を埋めること自体が目的化します。定めるのは「何が書かれていれば足りるか」という要件までとし、体裁は各案件に委ねる運用が現実的です。

新規事業プロセスの4フェーズと成果物

段階の数は事業の性質によって変わりますが、探索から事業化まで4つに区切る構成が扱いやすい単位になります。以下は各フェーズの問いと成果物の対応です。自社の領域に合わせて名称や項目を読み替えてご活用ください。

探索フェーズ

探索フェーズで確定させるのは、どこを見るかという範囲です。市場の変化や自社の資源を手がかりに対象領域を絞り、なぜ自社が取り組むのかを言語化します。この段階では解決策を考える必要はありません。

成果物として重要なのは、選んだ理由と同時に扱わない範囲を明記することです。対象外が書かれていないと、後続のフェーズで案が際限なく広がり、検証の焦点が定まりません。課題仮説はまだ複数あって構わず、この時点で一つに絞る必要はありません。

課題検証フェーズ

課題検証フェーズの成果物は、課題が実在するという一次情報です。対象となる顧客に直接あたり、過去に実際どう行動したかを聞き取ります。「あったら使う」という回答は成果物になりません。既に別の手段に時間や費用を割いているという事実が、課題の切実さを示します。

このフェーズを通過したといえるのは、対象顧客の輪郭と、その顧客が現在どう困りどう対処しているかが具体的に記述できる状態です。記述できなければ、対象を変えるか、課題仮説を置き直して探索へ戻ります。

解決策検証フェーズ

解決策検証フェーズでは、課題に対する解決策が実際に機能するかを確かめます。完成品を作る必要はなく、試作や限定的な提供で足ります。成果物は、顧客が実際に使ったという記録と、対価を払う意向がどの価格帯で現れたかという情報です。

好意的な感想は成果物に含めません。継続して使われたか、再度求められたかという行動の事実を残します。数値が伸びない場合は、解決策の修正か対象顧客の見直しを検討します。

事業化フェーズ

事業化フェーズで確定させるのは、事業として回る構造です。収益と費用の関係、提供を続けられる体制、顧客を獲得し続ける経路の三点が中心になります。単発の受注が取れたことと、事業が成立することは別の話です。

成果物には、投資を拡大したときの採算見通しと、撤退の条件を含めます。この段階まで来ると投じた資源が大きく、判断が感情に引きずられやすくなります。拡大の前に条件を書き残しておくことが、後の判断を支えます。

成果物を先に定めると何が変わるか

フェーズごとの成果物を先に定義すると、プロセスの運用は三つの点で変わります。いずれも、担当者と評価者の双方に効く変化です。

第一に、何を作ればよいかが明確になります。成果物が定義されていないと、担当者は「評価者が納得しそうな資料」を推測して作ることになります。推測に費やす時間は検証の時間を削ります。

第二に、案件同士を並べて比較できるようになります。同じフェーズにある案件は同じ確定情報を持つため、どちらに資源を寄せるかを同じ物差しで判断できます。比較できない状態では、資源配分は声の大きさで決まります。

第三に、組織に情報が蓄積されます。成果物の項目が統一されていれば、中止になった案件の記録も後から参照できます。撤退した案件の確定情報こそ、次の探索の出発点になります。項目がばらばらだと、記録は残っても再利用できません。

自社のプロセスを設計する手順

プロセスは他社の型をそのまま持ち込んでも機能しません。自社の意思決定の速度や案件の規模に合わせて組み立てる必要があります。設計は次の順序で進めると迷いが少なくなります。

まず、フェーズの数を決めます。少なすぎると判断の間隔が空いて見直しが遅れ、多すぎると事務局と担当者の負荷が増えて運用が滞ります。4つ前後から始め、運用しながら調整するのが現実的です。

次に、各フェーズで答える問いを一文で書きます。作業ではなく問いで定義することが要点です。問いが書けないフェーズは、そもそも段階として分ける必要がない可能性があります。

続いて、その問いに答えたといえる成果物の要件を列挙します。ここで「何件のインタビュー」といった量の基準ではなく、「何が記述できていれば足りるか」という状態の基準で書きます。量の基準は形式的な達成を招きやすいためです。

最後に、成果物を確認する場と、確認する人を決めます。場が定期的に開かれないと、成果物の定義だけがあって運用されない状態になります。日程と参加者を先に固定し、案件の進捗に合わせて開催するのではなく、決まった周期で開く形にします。

プロセス設計で外しやすい点

設計段階で見落とされやすい点を、実務でよく見られる順に挙げます。

• 後戻りを想定していない：検証の結果によっては前のフェーズへ戻ります。戻ることを失敗と扱う設計にすると、担当者は都合の悪い事実を報告しなくなります
• 成果物の様式を細かく決めすぎる：書式を埋める作業が検証の時間を圧迫します。定めるのは要件までにとどめます
• フェーズの粒度が案件規模に合っていない：小規模な案件に大企業向けの重い構造を当てると、事務負荷だけが残ります
• 確認する場が形骸化する：全案件が自動的に通過している状態は、確認が機能していない兆候です
• 中止した案件の成果物を捨てる：確定情報を残さなければ、同じ検証を別の担当者が繰り返します

とくに一点目は、プロセスの実効性を大きく左右します。前進だけを前提とした構造は、実態と合わないため必ず形骸化します。後戻りを正規の経路として設計に組み込んでおくことが、運用を続ける前提になります。

まとめ

新規事業のプロセスは、作業の順序ではなく、確定情報の順序を定めた構造です。フェーズの境界を期間や作業ではなく成果物に置くことで、進捗は測れるようになり、案件同士の比較も可能になります。

探索・課題検証・解決策検証・事業化という4つの段階には、それぞれ答えるべき問いと残すべき成果物があります。探索では対象領域と扱わない範囲、課題検証では課題の実在を示す一次情報、解決策検証では利用と価格の事実、事業化では収支構造と撤退条件です。

設計の手順は、フェーズ数を決め、各段階の問いを一文で書き、成果物の要件を状態の基準で列挙し、確認する場と人を固定する順です。後戻りを正規の経路として組み込むことが、プロセスを形骸化させずに運用し続けるための条件になります。

よくある質問

フェーズはいくつに分けるのが適切ですか

4つ前後から始めることをおすすめします。段階が少なすぎると判断の間隔が空いて見直しが遅れ、多すぎると事務局と担当者の負荷が増えて運用そのものが滞ります。重要なのは数ではなく、各段階で答える問いが明確に書き分けられているかどうかです。問いが書けない段階は分ける必要がない可能性があります。運用しながら、自社の意思決定の速度に合う粒度へ調整していく進め方が現実的です。

案件ごとにプロセスを変えてもよいですか

フェーズの構造は共通にし、成果物の要件だけを案件の性質に応じて調整する形をおすすめします。構造まで案件ごとに変えると、案件同士を同じ物差しで比較できなくなり、資源配分の判断が難しくなります。一方で、要件を一律に固定すると実態に合わない項目が生まれます。共通の骨格と、調整可能な要件という二層で設計すると、比較可能性と実務への適合を両立できます。

前のフェーズに戻るのはプロセスの失敗ですか

失敗ではありません。検証の結果として前提が覆れば、課題仮説や対象顧客を置き直して探索へ戻るのは正しい動きです。むしろ、後戻りを想定していないプロセスのほうが問題を抱えています。戻ることが失敗として扱われる環境では、担当者は都合の悪い事実を報告しなくなり、判断の材料が組織に上がってこなくなります。後戻りを正規の経路として設計に含めておくことが重要です。