ステージゲート法が機能しない本当の理由

ステージゲート法とは

ステージゲート法とは、開発プロジェクトを複数のステージに分割し、各ステージの終わりにゲートと呼ばれる審査を設けるプロセス管理のフレームワークである。カナダの経営学者ロバート・クーパーが1980年代に提唱し、製造業を中心に広く普及した。

典型的なステージ構成は以下の通りである。

アイデア発掘
概念定義
開発
テスト・検証
市場投入

各ゲートでは、あらかじめ定めた評価基準に基づいてGo・Kill・Holdのいずれかを判断する。Goであれば次のステージへ進む。Killであればプロジェクトを中止し、リソースを解放する。Holdであれば一時停止し、条件が整うまで待機する。

ここまでは多くの技術者・管理職が知っている。しかし次の一点を知っている人は、驚くほど少ない。

ステージゲート法の主目的はKillである

クーパーが本来意図したのは「早期撤退」の仕組みである。ゲートの主目的はGoではなくKillであると、クーパー自身も明言している。問題が小さいうちに発見してKillすれば、無駄な投資を防ぎ、リソースをより有望なプロジェクトへ再配分できる。ステージゲート法はプロジェクトポートフォリオ全体の質を高めるための選別装置として設計されたフレームワークである。

GoのためではなくKillのための仕組みである——この認識を持ってステージゲートを運用している組織を、私はほとんど見たことがない。

実務においてステージゲートは、開発品質の標準化ツールとして機能していることが多い。各ゲートはマネジメント層が技術・事業の両観点からレビューし、決裁を行う場となっている。それ自体は悪いことではない。しかし「Killするための場」という認識が抜け落ちた瞬間に、ゲートの性質は根本から変わる。

目的が共有されていないと何が起きるか

Killが主目的であるという認識がなければ、ゲートは自然と「通過するための場」になる。

担当者はGoを取るために資料を整える。懸念点は小さく見せ、リスクは楽観的に評価し、レビュアーを説得することに全力を注ぐ。採算が合わないことが見えてきても、解像度の低い別マーケットへの売上予測を追加して数字を作ろうとする。ゲートに持ち込まれる時点で、プロジェクトはすでに「通すこと」を目的として準備されている。

レビュアー側も同様である。自分が承認したプロジェクトをKillすることは、自らの判断ミスを認めることになる。担当者が長期間取り組んできた仕事を潰すことへの心理的抵抗もある。結果として上役がやるのは「やり直し」の指示だけであり、プロジェクトは延命し続ける。

こうしてゲートは、選別の場ではなく承認を得るための儀式になる。そしてKillされるべきプロジェクトは、そもそもゲートの場に来ない。担当者が「通せない」と判断した時点で、ゲートに持ち込む前に修正・延命工作が始まるからである。

私の二十数年の開発者人生で、チームが自ら止める前提で議論しているのを見たことがない。唯一の例外は、とある社内一の開発プロジェクトを急激な円高による収益悪化を理由にばっさりと切った人物だけだった。私はその判断と覚悟に感銘を受け、自分が開発責任者を務めたプロジェクトで、2度、開発中止を宣言したことがある。それがいかに例外的な行為であるかは、自分自身がよくわかっている。

「進めること」が正義になっている

なぜここまで止まらないのか。権限の問題ではない。

担当者に中止を提案する権限を与えたとしても、それだけでは解決しない。「進めること」が、構造上も精神上も、どちらの観点からも正義になっているからである。構造上は、開発テーマ数や売上への貢献が評価される。精神上は、止めることは敗北であり、諦めであるという認識が根付いている。権限があっても、その構造の中では止まりようがない。

個人のモラルやモチベーションに期待する設計は間違いである。人間はそれほど強くない。必要なのは、Killが言える・言わざるを得ない構造をつくることである。

構造を変えるとはどういうことか

構造を変えるためには、評価の設計を変える必要がある。「文化を変えよう」という号令では何も変わらない。文化は評価設計の結果として生まれるものだからである。

担当者側の評価軸を、開発テーマ数や売上貢献ではなく、提案数やアイデアの独自性——すなわちステージゲートのスタート地点までの活動——に置く。そうすることで、早期に中止を提案することが損失ではなくなる。失敗を恐れずに多くのアイデアを出し、早期に選別することが評価される構造になれば、担当者の行動原理は変わる。

レビュアー側の評価軸は、通したプロジェクトの打率にする。通した数ではなく、通したプロジェクトが実際に成果を出した割合で評価される構造であれば、レビュアーは安易にGoを出せなくなる。打率の測定には時間がかかるが、少なくとも「何を根拠にGoを出したか」を記録し、後から検証できる仕組みを作るだけでも、レビュアーの意識は変わる。

全社的な評価制度の変更が難しい場合でも、自分のチームの中だけで始められることはある。担当者が早期撤退を提案したときにそれを明示的に評価する、レビューの場で「このプロジェクトを今始めるか？」という問いを必ず立てる——こうした小さな設計変更の積み重ねが、構造を少しずつ動かす。

ステージゲート法は目的から再設計する必要がある

これはステージゲート法に限った話ではない。フロントローディングやWBSなど、開発プロセス系のフレームワークに共通する形骸化の構造である。フレームワークは人間の行動原理を変えない。

ステージゲート法を導入している組織に問いたいことがある。そのゲートは、Killするために設計されているか。

フレームワークの名前を知っていても、その主目的がKillであるという認識がなければ、ゲートはGoのための儀式に成り下がる。評価設計が「進めること」を正義にしている限り、どれほど精緻なフレームワークを導入しても機能しない。

ステージゲート法は意思決定のフレームワークではなく、Killが構造的に発生する評価設計とセットで初めて機能する。フレームワークだけを導入して「なぜKillが出ないのか」と嘆く組織は、仕組みではなく人間に期待しているに過ぎない。

所属組織の見解ではなく、個人の意見・考察です。