ステージ・ゲートのローカライズ——大企業カスタマイズ失敗パターン

「日本に合わせる」という名の骨抜き

ステージ・ゲートの導入プロジェクトで最も多く聞く言葉が、「日本の企業文化に合わせてカスタマイズする」だ。

その言葉が発せられる文脈は、ほぼ決まっている。Kill判断を出しにくい組織文化（プロジェクトを中止することへの抵抗感）、コンセンサス重視の意思決定慣行（ゲートキーパーが単独で判断しにくい）、「承認申請」としてのゲート認識（評価される側と評価する側の非対称な関係）。

これらの課題に対応するため、導入担当者はゲートの設計を「柔軟化」する。その結果、ゲートは機能不全に陥る。

問題は、「日本の組織文化に合わせる」こと自体ではない。何を変え、何を変えてはならないかを区別しないまま調整を行うことが失敗の本質だ。

ステージ・ゲートが解決しようとしている問題

カスタマイズの失敗を理解するには、そもそもステージ・ゲートが何の問題を解決するために設計されたのかを確認する必要がある。

クーパーが1980年代の産業研究を通じて発見した問題は、新製品開発における「後期フェーズでの失敗コスト」だった。開発の後期（製品化・量産化フェーズ）で問題が発見されると、修正コストは初期フェーズの10〜100倍に膨らむ。早期に「このプロジェクトは問題がある」と判断し、リソースを引き上げる意思決定が、組織全体の開発効率を決定的に左右する。

言い換えると、ステージ・ゲートの核心は「早期の中止判断を組織として実行できるようにする」ことだ。そして、日本企業がカスタマイズで骨抜きにするのは、ほぼ例外なくこの「早期中止判断の実行能力」の部分だ。

詳しい実装設計についてはステージ・ゲートモデル実装プレイブックを参照してほしい。

日本企業が陥る3つのカスタマイズ・トラップ

トラップ1：「Kill」を「再検討」に言い換える

最初に観察されるトラップは、ゲートの判断選択肢の言語的変換だ。Go/Kill/Hold/Recycleという4択のうち、「Kill（中止）」という言葉が社内に定着しないという理由で、「プロジェクトの棚卸し」「方向性の再検討」「一時的な凍結」といった言葉に置き換えられる。

言葉の置き換えは、判断の実態を変える。「Killと判断されたプロジェクト」は事実として終了するが、「再検討と判断されたプロジェクト」は誰も責任を持って終了させない。担当チームは「まだ続いている」と認識し、消えかけた炎に少しずつリソースを投入し続ける。組織のポートフォリオは「ゾンビプロジェクト（公式には生きているが実質的に機能していないプロジェクト）」で満たされていく。

この問題を解決するには、Kill判断の後に必ず「プロジェクトのクローズアクション（リソースの再配置、担当メンバーの次アサインの確定、知的資産のドキュメント化）」を実行するプロセスをセットで設計する。Kill判断は終わりではなく、「学習の収穫」の始まりとして再フレーミングすることも有効だ。

トラップ2：ゲートキーパーに「調整者」を置く

2つ目のトラップは、ゲートキーパーの選定基準の変質だ。意思決定の場に多数のステークホルダーが参加することを好む日本の組織文化の中で、ゲートレビューに「関係者全員を揃える」傾向が生まれる。その結果、ゲートキーパーの中に「この場の空気を読んで合意をとりまとめる調整者」が事実上の中心人物として機能するようになる。

調整者が場を支配するゲートでは、判断の質は「最も声の大きい人の直感」ではなく「この場での合意形成のしやすさ」によって決まる。有望だが説明が難しいプロジェクトはKillされ、凡庸だが説明しやすいプロジェクトがGoとなる逆選択が生じる。

ゲートの機能を守るためには、ゲートキーパーに「判断の権限と責任を持つ人」と「専門的な情報提供者」の役割を明確に分離する設計が必要だ。調整者をゲートキーパーに含めることは原則として避け、判断者は少人数（3〜5名）に絞る。

トラップ3：評価基準を「事後」に設定する

3つ目のトラップは最も気づきにくい。ゲートの評価基準を「事前に定義する」というルールが、実際には機能しないケースだ。

表面上は事前に評価基準を設けている。しかし、その基準が「顧客ニーズの確認」「市場機会の存在」「技術的実現可能性」といった抽象的な文言で書かれている場合、基準は実質的に「事後」に決まる。ゲートキーパーが結果を見てから「基準を満たしているか」を判断するため、基準は判断の根拠として機能せず、判断の合理化として機能するようになる。

評価基準は数値とアクションで具体化する必要がある。「顧客ニーズの確認」ではなく「インタビュー対象者の属性（役職・企業規模・業種）を事前定義した顧客プロファイルに合致する20名以上への半構造化インタビュー完了、かつ課題の深刻度スコア（10段階）平均6.5以上」。このレベルの具体性があって初めて、事前定義された評価基準として機能する。

変えていい部分と変えてはならない部分

ステージ・ゲートのカスタマイズには、「変えてよい部分」と「変えてはならない部分」がある。この区別を持つことが、失敗パターンを回避する出発点だ。

変えてよい部分：

• ゲートの間隔と頻度（週次・月次・四半期など組織リズムに合わせる）
• デリバラブルのフォーマットと提出様式（社内の報告慣行に合わせる）
• ゲートキーパーの具体的な役職構成（組織の意思決定構造に合わせる）
• ゲート実施の場の形式（対面・オンライン、会議の長さなど）
• ステージ名とゲート名の呼称（社内用語に合わせた言い換え）

変えてはならない部分：

• Go/Kill/Hold/Recycleの4択判断の存在（「Kill」を実質的に廃止することは禁止）
• Must-Meet基準の事前定義（評価基準の事後化は機能不全を確定させる）
• デリバラブルの先渡し（ステージ開始時に「何を検証すれば通過できるか」をチームに渡す）
• ゲートキーパーの判断権限の明確化（調整者が場を支配する構造は変えない）
• ゲートキーパーとチームの「同じチームとしての判断」という関係性

失敗のサインを早期に検出する

ゲートプロセスが機能不全に向かっているサインは、以下の観察で検出できる。

サイン1：ゲートレビュー直前の「仕上げ作業」期間の発生。 チームがゲートの2〜3週間前から、実質的な検証作業をやめて資料の整備に集中し始めたら、ゲートが「審査の場」として機能している証拠だ。

サイン2：全プロジェクトのゲート通過率が90%以上。 健全なゲートプロセスでは、早期ステージで20〜30%のプロジェクトがKillまたはRecycleとなる。全プロジェクトがGoとなる状況は、ゲートが機能していない。

サイン3：ゲートでの議論が「仮説の質」ではなく「資料の完成度」に向かう。 「この仮説は検証できたか」「次の仮説は何か」ではなく、「この資料の数字の根拠は何か」「フォントが統一されていない」という議論が中心になっていれば、ゲートは形式審査の場になっている。

サイン4：Kill判断の後にプロジェクトのクローズが実行されない。 中止判断が出たにもかかわらず、担当チームの次アサインが決まらず、プロジェクトが「フェードアウト」する形で消滅していくなら、Kill判断のプロセスが未設計だ。

これらのサインを検出したら、ゲートプロセスの設計に戻る必要がある。デザイン思考のローカル最大値問題と同様、ステージ・ゲートも「ローカル最適」に陥ることがある——部分的な改善を積み重ねても、根本的な設計の誤りは解消されない。

プロセスの改善より先にやること

ステージ・ゲートの機能不全を修正しようとする多くの組織が、「プロセスの改善」から始める。ゲートの頻度を変える、評価基準を見直す、ゲートキーパーを入れ替える。

しかし、プロセスの改善より先にやるべきことがある。ゲートでのKill判断が「担当者の失敗」ではないという組織的な合意を作ることだ。

Kill判断が担当者の評価を下げる文化の中では、どんなに精巧なゲートプロセスを設計しても、チームはゲートで正直な情報を開示しない。プロセスの設計は、組織文化という土台の上でしか機能しない。

ゲートでKillされたプロジェクトの担当チームが、学習の実績として評価され、すみやかに次のプロジェクトにアサインされる——この「Killが安全な選択肢である」という環境の整備が、ステージ・ゲートのローカライズで最初にやるべきことだ。

詳細な実装ガイドはステージゲート・プロセス実装ガイドも参照してほしい。