プレモーテム: Gary Klein が提唱するプロジェクト失敗の早期発見手法

著者: Tara Minh · 更新日: 2026年10月10日

プレモーテムとは、プロジェクトの開始前に行うリスクの演習です。チームはプロジェクトがすでに失敗したと想定し、各メンバーがうまくいかなかった理由を書き出します。心理学者の Gary Klein が、2007年に Harvard Business Review でこの手法を紹介しました。人が普段は胸にしまっている疑念を引き出してくれます。

重要な事実

• Gary Klein は、Harvard Business Review の2007年9月号の記事「Performing a Project Premortem」でプレモーテムを紹介しました。チームメンバーは、プロジェクトがたった今失敗したと想定し、その理由としてもっともらしいものを挙げていきます。
• この考え方は、Mitchell、Russo、Pennington が1989年に研究した「プロスペクティブ・ハインドサイト（予期的後知恵）」に基づいています。その研究では、出来事がすでに起きたと想像すると、その結果に対して人が挙げる理由の数が約30%増えたとされています（この研究レビューによる）。
• 178人の大学生を対象とした2010年の研究（Veinott ら）では、計画がすでに失敗したと想像するほうが、長所と短所を挙げる方法よりも、計画への自信を大きく下げることが分かりました（同じレビューによる）。
• プレモーテムが最も効果を発揮するのは、計画ができた後で、資金、人員、対外的な約束が確定する前です。1回のセッションは通常30〜60分かかります。

プレモーテムとは

多くのリスクセッションは「何がうまくいかない可能性があるか」と問います。プレモーテムの問いは違います。「今は12か月後です。プロジェクトは大失敗に終わりました。何が起きたのでしょうか」。この小さな問い方の違いが重要です。人は計画を擁護するのをやめて、演習の中ではすでに事実となっている失敗を説明し始めます。

この名前は、患者が亡くなった後でその原因を調べる医学の検死（ポストモーテム）をもじったものです。プレモーテムは、結果を変える時間がまだあるうちに、その検死を前もって行います。

Klein の HBR の記事は、その設定をわかりやすく説明しています。チームメンバーは、自分たちが計画しているプロジェクトがたった今失敗したと想定し、その失敗のもっともらしい理由を挙げていきます。彼はまた、この演習によって、事情をよく知る人が、そのままでは不忠実に思えてしまう懸念を安心して口にできるようになると論じました。全員がうなずいたキックオフで、3人が内心では日程を疑っていた、という経験があれば、この演習が埋めるギャップがお分かりでしょう。

プロスペクティブ・ハインドサイトが機能する理由

研究者は、この根底にある効果をプロスペクティブ・ハインドサイトと呼びます。将来の出来事を、すでに起きたかのように思い描くことです。結果が確実なものとして扱われると、頭は「もし」を問うのをやめ、「どのように」という物語を組み立て始めます。

これについてよく引用される研究が、Deborah Mitchell、Jay Russo、Nancy Pennington による1989年の論文です。その研究のレビューによれば、出来事がすでに起きたものとして扱うと、人が挙げる理由の数が約30%増えました。また、著者らがそれらの理由の質を評価していないことも指摘されています。したがって、安全な結論は「30%正確になる」ではなく、「より多くの理由が、より速く出てくる」です。それでも価値はあります。名前を付けられなかったリスクには、計画の立てようがないからです。

ほかにも、2つの力が働いています。

• 社会的な許可。 通常の計画ミーティングでは、欠陥を指摘すると、計画を書いた人への批判に聞こえかねません。プレモーテムでは、欠陥を見つけることが課題です。
• 自信過剰の低減。 前述の2010年の研究は、失敗を想像すると、長所と短所を挙げるよりも計画への自信が下がることを明らかにしました。自信がより低く、より現実的になることが目的です。それが、チームにバッファや緊急時の対策を追加させるからです。

プレモーテムとその他のプロジェクトリスク手法の比較

プレモーテムは、他のツールに取って代わるものではなく、それらに情報を供給します。最も混同されやすい手法との違いは次のとおりです。

よい目安があります。リスクの発見にはプレモーテム、順位付けにはリスクマトリクス、追跡にはリスク登録簿を使うことです。これらのツールが属する、より広い領域については、プロジェクトリスクマネジメントを参照してください。

プレモーテムを実施するタイミング

計画が批評できるほど具体的になっていて、なおかつ変更のコストが小さいうちに実施します。よくあるタイミングは次のとおりです。

• プロジェクト憲章が承認された直後、キックオフの前
• プロジェクトキックオフミーティングでの定例アジェンダとして
• 大きな購入、移行、ローンチについて Go か No-go を判断する前
• 計画が大きく変わった新しいフェーズの開始時

ごく小さなタスクでは省略してください。また、意思決定が取り消せなくなった後には実施しないでください。チームがそれを形式的なものとして扱ってしまいます。

プレモーテムの実施手順

5〜12人のチームなら、多くの場合45分のセッションで足ります。より大きなグループは、小さなテーブルに分かれて、後でリストを統合できます。

ステップ1: 計画をチームに説明する

計画、スコープ、タイムライン、成功の定義を共有します。全員が同じものを批評できなければなりません。時間は5〜10分にとどめ、説明しながら計画を擁護しないでください。

ステップ2: 失敗のシナリオを設定する

具体的な日付と、鮮明な結果を選びます。「今は2027年3月です。ローンチは4か月遅れ、予算は底をつき、スポンサーは支援を打ち切りました」といった具合です。曖昧より具体的なほうが優れています。失敗が具体的であるほど、人々が挙げる原因も具体的になります。

ステップ3: 一人で静かに理由を書く

全員に5〜10分を与え、会話なしでプロジェクトが失敗した理由を書き出してもらいます。個人で書くことが重要なのは、グループ討議だと、声の大きい人や最も上位の人の意見に引きずられるからです。付箋1枚、または1行につき、原因を1つにするよう求めます。

ステップ4: ラウンドロビンで理由を共有する

部屋を一巡して、リストが尽きるまで1人ずつ理由を1つずつ読み上げます。まだ議論はしません。すべてを共有ボードに記録します。若手や新参者は、他の全員がもう気づかなくなったリスクを挙げることがよくあります。

ステップ5: グループ化して投票する

似た原因をまとめます。人、スコープ、技術、予算、依存関係、外部要因などです。そして各自が、最も起こりやすい、または最も被害が大きいと思う原因に投票します。ドット投票なら5分で済み、声の大きいリスクが自動的に勝つことを防げます。

ステップ6: 上位のリスクをアクションに変える

上位5〜8つのクラスターについて、今何をするかを決めます。それぞれについて、次の4つの対応のいずれかが必要です。

1. 計画を変更して防ぐ
2. バッファ、テスト、2社目のサプライヤーで軽減する
3. 緊急時の発動条件を準備する（「ベンダーが最初のマイルストーンを逃したら、切り替える」）
4. 担当者を決めたうえで、承知の上で受け入れる

ステップ7: 記録して見直す

リスクを、担当者と期日とともにリスク登録簿またはRAID ログに移します。プロジェクトの中間地点に、15分のプレモーテムの確認をカレンダーに入れておきます。最初のセッションで出たリスクは、作業が始まると形を変えることがよくあります。

プレモーテムのテンプレート

これをドキュメントやスプレッドシートにコピーしてください。最初のブロックはセッションの前に、表はセッション中に記入します。

セッションヘッダー

失敗の原因と対応

フォローアップ

ビジネス機能別のプレモーテムの事例

この手法はプロジェクトマネージャーだけのものではありません。機能ごとに失敗の記述がどうなるかを紹介します。

どの行も、平易な一文の失敗から始まります。原因は特別なものではありません。廊下での雑談では人が気づいているのに、会議では誰も口にしない、ごく普通の問題です。

プレモーテムの Do と Don't

Do

• 失敗を事実として述べる。 「プロジェクトは失敗した」が有効です。「プロジェクトは失敗するかもしれない」では、防御的な考え方が戻ってきます。
• 最初は各自が一人で書く。 静かに書くことで、最初に発言した人に引きずられる（アンカリング）ことを防げます。
• コアチーム以外の人を招く。 サポート、財務、顧客対応の担当者などです。プロジェクトチームには見えない依存関係が見えます。
• セッションが終わるまでに、上位のリスクに担当者を割り当てる。 担当者のいないリストは、不満のリストにすぎません。
• 言いにくいリスクを挙げた人に感謝する。 次のセッションは、最初のセッションがどう扱われたかにかかっています。

Don't

• スポンサーやマネージャーに最初に発言させない。 その見解が他の全員の見方を方向づけてしまいます。
• 共有のラウンド中に、原因に反論しない。 議論はリストが完成した後です。
• 儀式として実施しない。 計画を変えられないなら、この演習は冷笑を生むだけです。
• リストで終わらせない。 処理されないリスクは、守りを加えずに不安だけを増やします。
• 責任追及と混同しない。 目的は、チームの弱い人ではなく、計画の弱い部分を見つけることです。

よくある間違い

ファシリテーターは、いつも同じいくつかの点でつまずきます。1つは、計画があまりに曖昧で、あらゆる原因が「定義されていなかった」になってしまう状態でセッションを行うことです。もう1つは、遅すぎて何も変えられない時期に実施することです。3つ目は、40個の原因を集めておきながら、どれにも対処しないことです。成果物は短くしてください。誰も読まない長いリストよりも、担当者の付いた5〜8個のリスクのほうが優れています。

また、チームがプレモーテムを、過去のプロジェクトへの古い不満を蒸し返すために使うこともあります。優れたファシリテーターは、「そのうち、この計画に起こりうるものはどれですか」と軌道を戻します。そうすれば、演習は未来志向を保ち、まだ下せる意思決定に結びつきます。Agile チームは、リリースや大きなエピックの開始時にもっと軽い版を実施し、そのアクションを Backlog の項目に組み込むことができます。

まとめ

プレモーテムは、チームがすでに疑っていることを聞き出す、低コストな方法です。Klein の洞察は、問い方そのものが効くということでした。失敗が前提になると、人は不忠実だと感じることなくそれを語れます。計画ができた後に実施し、短く保ち、上位のリスクを担当者の付いたアクションに変えてください。その後はリスク登録簿で追跡し、中間地点で見直しましょう。