ステージゲートという言葉を、「節目のレビュー」という意味で使っている現場は多いと思います。設計が終わったら確認、開発が終わったら確認、という具合です。

ただ、本来のゲートは確認の場ではありません。ここから先も続けるかどうかを決める場です。この違いは大きいです。

■ 進捗確認とゲートは別物

3行目が重要です。止める権限がない人だけで集まっても、ゲートにはなりません。止められない会議では、「進む」以外の結論が出ないからです。

■ ゲートで問う4つのこと

図の4つを、毎回同じ順番で確認します。

問1：まだ価値があるか。これが最初に来るのがゲートの特徴です。半年前に立てた前提が、今も生きているとは限りません。市場が変わった、法制度が変わった、別のシステムが入った。前提が崩れていれば、どれだけ順調でも続ける意味がありません。

問2：実現できそうか。技術的な見通し、体制、そして業務部門が受け入れられるか。ここで「やってみないと分からない」が続くなら、次の段階に小さく試す作業を入れます。

問3：資源は確保できるか。次の段階に必要な人が、実際に空いているか。ここは楽観的になりがちです。「4月から2人増やす予定」ではなく、「誰と誰が、何月何日から」まで確認します。

問4：条件は満たしたか。前の段階の終了条件です。これは事前に決めておくものです。

■ 終了条件は前の段階で決めておく

ゲートがうまくいかない最大の理由は、判定基準がその場で作られることです。会議の場で「これで十分と言えるか」を議論し始めると、結論は出ません。

だから、各段階の開始時に、終了条件を書いておきます。

書き方のコツは、できあがった文書の名前ではなく、確認できた事実で書くことです。「設計書が完成している」ではなく「1拠点で試行して動いた」。後者のほうが、ごまかしが効きません。

■ 「条件付きで進む」を使う

実務では、全部そろってからゲートを通ることはまれです。だいたい何かが残っています。ここで「進む」か「止める」の二択にすると、無理に進めるほうに寄ります。

そこで「条件付きで進む」という判定を用意します。

• 残っている宿題を明記する

• いつまでに、誰が終わらせるかを決める

• その期限までに終わらなければ、どうするかも決めておく

3つ目がないと、条件付きは「なんとなく進む」と同じになります。

■ 中止も判断のひとつ

日本の現場で一番使われないのが「中止」です。ここまで投資したのだから、という気持ちが働きます。

ただ、プログラムの良さは構成を組み替えられることにあります。効果が見込めなくなった構成要素を止めて、その資源を効く場所に回せる。これはプロジェクト単体ではできません。

中止の判断をしやすくするために、2つ準備しておきます。

• 企画の段階で、「どうなったら止めるか」の条件を書いておく

• 中止した場合でも、そこまでに得た学びを記録して次に渡す

1つ目があると、中止が「失敗」ではなく「あらかじめ決めていたルールの適用」になります。心理的なハードルがかなり下がります。

■ まとめ

ステージゲートは進捗確認ではなく、続けるかどうかを決める場です。問うのは、価値・実現性・資源・条件の4つ。終了条件は前の段階で決めておき、判定は4択にする。

いま関わっているプログラムで、次のゲートの判定基準が文書になっているか確かめてみてください。なければ、次の段階が始まる前に書いておくと、後の議論がずっと楽になります。