ステージゲートを導入している新規事業の組織は、いまや珍しくありません。ステージを刻み、審査の会議体を置き、提出資料のフォーマットも整えた。それでも現場からは、「ゲートのたびに言われることが違う」「審査が形骸化している」という声が聞こえてきます。
企画チームはフォーマットを埋めて上申したのに、フォーマットにない指摘を受けて持ち帰る。審査する側に悪意があるわけでも、制度の設計が雑だったわけでもない。それなのに、どのステークホルダーから見てもゲートがうまく回っていないように感じられる。私たちが新規事業の組織を支援する中でも、たびたび出会う状況です。
何が起きているのでしょうか。本コラムでは、ステージゲートの正体を論点の分解として捉え直すところから始めて、抽象化されたフォーマットが持つ限界と、それでもゲートを機能させるための考え方を整理します。
ステージゲートの正体は、超大論点の分解である
ステージゲート法は、1980年代にロバート・クーパー氏が体系化した手法で、開発のプロセスをステージとゲートに区切り、節目ごとに案件を評価しながら投資を段階的に配分していく、と一般には説明されます。
この説明を、ハンドブックの事業開発の進め方で整理した「事業開発とは検証の連続である」という見方に重ねてみます。
どんな企画にも、いちばん上に置かれる問いがあります。「この企画は事業化できるか？」です。本コラムではこれを超大論点と呼びます。この問いはそのままでは大きすぎて、確かめようがありません。だから分解します。
- この企画は、自社でやる必要があるのか
- 顧客は本当に困っているのか
- その困りごとを解決できるソリューションになっているのか
- 事業として継続的に提供できるのか
分解して出てくるこれらの大論点が、そのままステージの並びに対応します。序盤のステージは「顧客は本当に困っているのか」を確からしくする段階で、後半のステージは「継続的に提供できるのか」を確からしくする段階です。つまりステージゲートの設計とは、超大論点をどう大論点に分解するかの設計にほかなりません。
各大論点も、粒度はまだかなり大きいままです。「顧客は本当に困っているのか」を確かめるには、誰のどの業務の困りごとなのか、いまの代替手段でなぜ我慢できないのか、解決の優先順位は高いのか、とさらに分解が要ります。ツリーとして分解していくと、各ステージの下に、その段階で確からしくすべき論点ツリーがぶら下がっている構図が見えてきます。
そして一番望ましいのは、この大論点のレベルと、各ステージの提出フォーマットが一致していることです。ゲートで審査されるのは「この大論点がどこまで確からしくなったか」であり、フォーマットは論点ツリーの検証結果を並べる器になる。ここまで揃うと、同じ検証結果に対して誰が審査しても近い判断が返る「判断の装置」に、ゲートは近づきます。
抽象化されたフォーマットは、あらゆる企画を検査できない
ところが、ここに構造的な限界があります。考えるべき論点は、業界・業種・企画の内容ごとに少しずつ違うからです。
規制の強い業界向けの企画なら、法規制への対応そのものが序盤の大きな論点になります。ハードウェアを伴う企画なら、供給体制や在庫リスクの論点が早い段階から外せません。社内のアセットを転用する企画なら、権利関係や既存事業との調整が固有の論点として立ちます。全企画に共通のフォーマットは、こうした個別の論点をあらかじめ書き込んでおけません。抽象化された制度設計として項目は機能しますが、抽象化されたフォーマットを埋めれば、あらゆる企画の検査ができるのかというと、そんなことはないのです。
このズレは、提出する側と審査する側の両方で症状になって現れます。
企画を出す側から見ると、フォーマットを埋めて上申したのに、フォーマット外の指摘を受けることになります。指摘の中身自体は妥当でも、事前に示されていなかった論点である以上、受け取る側には後出しに感じられます。
審査する側にも問題が残ります。フォーマット外の論点は、審査する人が頭の中から都度引き出すしかありません。すると、まったく同じ案件でも、日によってレビューの内容を同質にできない可能性が出てきます。先週は供給体制を突いた指摘が、今週は出ない、ということが普通に起こります。
結果として、フォーマットや論点をきちんと設計している組織でも、ステークホルダーの間では「基準がぶれている」「形骸化している」ように感じられることがあります。制度は設計した通りに運用されているのに、そう見えてしまうのです。
フォーマットの側が、論点ベースになっていないこともある
運用だけの問題でもありません。ステージゲートのフォーマット設計そのものが、論点ベースになっていないケースもあります。
典型例が、何一つ検証していない段階の企画に、精緻な財務計画の提出を求める様式です。この段階では売上も原価も、その前提となる顧客の困りごとさえ、すべてが仮説です。完全な仮説を積み上げたバランスシートを作り込んでも、どの論点の検証にもなりません。数字の見栄えは整っていきますが、根拠は少しも確からしくなっていないからです。
意味がある場合もあります。投資の桁感をチームで揃えたり、どの変数が事業性を左右するかの当たりをつけたりする使い方です。ただ基本的には、掛けた時間の割に企画の解像度を上げる役目を果たしていないことが多い、というのが支援の現場での実感です。
フォーマットの各項目は、「このステージでどの論点を確からしくすべきか」から逆算されているか。制度を設計する側が、最初に検査すべき点です。
基準を言語化しておけば済む、でもない
ここまでの話は、「では論点と基準を言語化して、事前に共有しよう」という結論に向かいます。方向としては正しいと考えています。言語化された判断基準の価値は、AI時代の新規事業に必要不可欠な「ポリシー」とはなにかに書いた通りです。ただし、基準を言語化しておけばOK、とまでは言えません。
まず、ポリシーはアップデートされ続けるものだからです。検証が進んで学びが増えれば、重く見るべき論点も判定のラインも変わります。一度書いた基準を固定して金科玉条にすれば、その文書は先ほどの「抽象化されたフォーマット」と同じ限界を抱え込みます。
もうひとつは、受け取る側の認識の問題です。基準が文書になった結果、「ステージゲートのフォーマットに従ってやっておけば企画は進む」という認識だけをメンバーが持ってしまうと、別の症状が出ます。フォーマットを埋めることが目的になり、検証がフォーマットの項目に限定され、項目の外に潜んでいる最大の不確実性が放置されます。ゲートの通過率は高いのに、事業が生まれない。この状態がむしろ危険信号でありうることは、「形だけうまくいっている」新規事業チームの特徴にまとめています。
「なぜこの設計なのか」を全員が理解している状態をつくる
では、何を目指せばよいのでしょうか。
ステージゲートが本来どうあるべきものか。いまのフォーマットは、どんな背景があって今の設計になっているのか。そもそも、なぜゲートをやるべきなのか。これらを、制度の設計者だけでなく、提出する側・審査する側を含めた全員が理解できる状態にしておくことだと考えています。
その理解には、設計そのものは完全ではないこと、あらゆる企画に共通させた抽象化されたものでしかないことも含まれます。ここまで認識が揃うと、企画によってはフォーマット外の別の論点、つまり別の検証を求められることが、当たり前のこととして受け止められるようになります。フォーマット外の論点を求められても、「この企画固有の論点が見つかった」という検証の前進として扱えるからです。
逆にこの認識を全体で持てていないと、フォーマット外の指摘が出るたびに、「ステージゲートというもの自体が機能していない」ように見えてしまいます。冒頭の「言われることが違う」「形骸化している」という声は、制度の欠陥そのものより、この認識の不揃いから生まれていることが多いのです。
この見立てには、裏づけになるデータもあります。PwCコンサルティング『新規事業開発の取り組みに関する実態調査2025』によれば、新規事業の推進プロセスを整備「できている」企業は15%にとどまりますが、「ややできている」まで含めると66%に達します。プロセスの形は、多くの組織にすでにあります。それでも、案件が投資回収フェーズ以降に達した「成功企業」とそれ以外の「挑戦企業」で回答差が最も大きかった成功要因は、プロセスの中身の検討よりも「プロセスを管理する人材の確保、体制の確立」でした（成功企業26%、挑戦企業9%）。設計図の出来より、設計を理解して運用しつづける体制が成否を分けている、と読める結果です。調査全体の読み解きはPwC実態調査2025のレビューに書いています。
必要最低限の共通論点として、フォーマットを設計する
その認識を全体で揃えた上で、フォーマットはどう設計すべきでしょうか。あらゆる論点を網羅した完全な様式を目指すのではなく、「どんな企画でも、これだけは押さえておくべき」という必要最低限の共通論点として設計することです。
共通部分は薄く保ち、残りは企画ごとの論点ツリーに委ねます。ゲートのレビューでは、共通論点の検証結果に加えて、「この企画固有の論点は何か。それはどこまで確からしくなったか」を確かめる。フォーマットは合否を機械的に判定するチェックリストから、議論の出発点に変わります。
この設計思想は、ポリシーの話に通じます。ポリシーもまた、チームが共通して立ち返る基準を言語化し、使いながら更新していくものでした。ステージゲートのフォーマットは、企画の検査という場面に特化したポリシーの一形態と言えます。
共通論点を選び出すにも、企画固有の論点ツリーを立てるにも、要る技術は同じです。問いを状態と成立条件に分解していく手順は、ハンドブックのすべての根本となるスキルに動作として落としています。ゲートの様式を見直す前に、まず自社の各ステージが「どの大論点に答える段階なのか」を言葉にするところから始めてみてください。フォーマットの項目が論点から逆算されているかどうかは、そこで初めて検査できるようになります。