フレームワーク活用ガイドひとことで言うと#
プレモーテムは「このプロジェクトは大失敗に終わりました。なぜでしょう？」という問いから始める逆転のリスク分析法。通常のリスク分析が「何が起きるかもしれないか」を聞くのに対し、プレモーテムは「すでに失敗した」前提を置く。この違いが重要で、「失敗した未来」を想像する方が、人は30%多くのリスク要因を挙げられるという研究結果がある。心理学者ゲイリー・クラインが提唱した手法。
押さえておきたい用語#
- プレモーテム（Pre-Mortem）
- プロジェクト開始前に「失敗した」と仮定してリスクを洗い出す手法。医学の「ポストモーテム（死後解剖）」をもじった造語。
- 前向きヒンドサイト（Prospective Hindsight）
- 未来の出来事をすでに起きたこととして振り返る認知的技法。「もしかしたら失敗するかも」より「失敗した。なぜか」の方が、具体的な原因を想像しやすくなる。
- 楽観バイアス（Optimism Bias）
- 計画段階ではうまくいく前提で考えてしまう人間の傾向。プレモーテムはこのバイアスを意図的に打ち消す。
- 計画の誤謬（Planning Fallacy）
- プロジェクトの所要時間やコストを過小に見積もる傾向。楽観バイアスの一種で、プレモーテムによって現実的な見積もりに近づけられる。
プレモーテム分析の全体像#
こんな悩みに効く#
- プロジェクト計画段階で「リスクは？」と聞いても何も出てこない
- いつも同じパターンの失敗を繰り返すが、計画時には誰も指摘しなかった
- チームメンバーが上司の前で懸念を言い出せない雰囲気がある
基本の使い方#
プレモーテムの鍵は「失敗した」という前提を全員で共有するところにある。
- プロジェクトキックオフまたは計画レビューの場で実施する
- ファシリテーターが宣言する：「1年後の今日、このプロジェクトは完全に失敗しました。予算超過、納期遅延、顧客からのクレーム殺到。最悪の結果です」
- この宣言が「リスクを語ること＝ネガティブではない」という空気を作る
- 笑いが起きることもあるが、それは心理的安全性のサイン
声に出さず黙って書くのがポイント。他人の意見に引きずられない。
- 付箋またはノートに、思いつく限りの失敗原因を書く
- 「人手が足りなかった」「スコープが膨らんだ」「キーパーソンが退職した」「競合が先に出した」など
- 技術的なリスクだけでなく、組織・人・政治的なリスクも含める
- 「言いにくいこと」ほど価値がある。プレモーテムはそれを引き出す仕組み
書き出した原因を1人ずつ発表し、分類→優先順位→対策のステップで処理する。
- 発表は1人1項目ずつラウンドロビンで回す（全員が発言する機会を確保）
- 似た原因をグルーピングし、「発生確率×影響度」で優先順位をつける
- 上位3〜5項目に対して、具体的な予防策をプロジェクト計画に追加する
- 「このリスクが顕在化したら誰が何をするか」まで決めておく
具体例#
状況: スタートアップの新サービスローンチまで3ヶ月。チーム7名。計画は順調に見えるが、PM（プロジェクトマネージャー）は「何か見落としている」という漠然とした不安を感じている
プレモーテムの実施: キックオフ会議の最後30分で実施。「3ヶ月後、ローンチは大失敗でした。なぜ？」と宣言
挙がった失敗原因（抜粋）:
- 「決済APIの審査が間に合わなかった」（エンジニア）— 計画に審査期間が含まれていなかった
- 「デザインのリテイクが3回以上発生し、開発着手が遅れた」（デザイナー）
- 「ローンチ直後にサーバーが落ちて、初期ユーザーが離脱した」（インフラ担当）
- 「共同創業者が途中でピボットを言い出し、スコープが変わった」（PMが書いたが口に出せなかった内容）
対策: 決済API審査を即日申請（1ヶ月のバッファ確保）、デザインレビューの回数を2回に制限、負荷テスト実施日を計画に追加、スコープ凍結の合意を共同創業者と文書化
結果: ローンチは計画通り実施。特に決済API審査は実際に3週間かかり、「プレモーテムで先に動いていなければ間に合わなかった」とPMは振り返っている。
状況: 従業員500名のメーカー。20年使った基幹システムのクラウド移行。プロジェクト期間12ヶ月、予算1.5億円。過去2回の類似プロジェクトがいずれも予算超過で炎上した経験がある
プレモーテムの実施: プロジェクト計画承認前に、関係部門（IT、経理、営業、製造）の代表者12名で1時間のプレモーテムセッションを実施
挙がった失敗原因（上位5つ）:
- 現行システムの仕様が文書化されておらず、移行漏れが発生
- 製造部門が新システムの操作に慣れず、生産が一時停止
- データ移行でマスターデータの不整合が発覚し、手動修正に3ヶ月
- 経営層が途中で追加要件を出し、スコープが1.5倍に膨張
- ベンダーの主要担当者が途中で交代し、引き継ぎに2ヶ月
対策: 現行システムの仕様書作成を移行作業に先行して実施（3ヶ月前倒し）、製造部門向け研修を本番3ヶ月前から開始、データクレンジングを独立したフェーズとして計画に追加、スコープ変更委員会を設置
結果: 12ヶ月の計画を13ヶ月で完了（1ヶ月の超過のみ）。予算は1.58億円で着地。過去2回の炎上と比較して大幅に改善。「プレモーテムで出た項目の6割は実際に発生したが、備えがあったので致命傷にならなかった」とPMは評価している。
状況: 4人家族（夫婦＋小学生2人）で沖縄旅行を計画。過去の家族旅行では「渋滞で予定が崩壊」「子どもが疲れて不機嫌」「行きたい場所の定休日」などでストレスが溜まった経験あり
プレモーテムの実施: 夕食後に家族4人で「この旅行、最悪でした。何が起きた？」と10分間のプレモーテム
挙がった失敗原因:
- 「雨で海に行けなかった」（長男）
- 「車の中が暑くて弟が泣いた」（長女）
- 「レストランが予約いっぱいだった」（妻）
- 「レンタカーの渋滞で2時間ロスした」（夫）
対策: 雨の日プランBを2つ用意（水族館＋室内アクティビティ）、移動は午前中に集中させ午後は近場で遊ぶ構成に変更、レストランは3日前に全て予約、車内にタブレットとお菓子を準備
結果: 実際に2日目が雨だったが、プランBの水族館が大好評。子どもたちは「プレモーテムやってよかったね」と覚えていた。旅行中のケンカはゼロだった。
やりがちな失敗パターン#
- リスクを出しただけで対策を決めない — プレモーテムの価値はリスクの列挙ではなく、その対策をプロジェクト計画に組み込むところにある。ワークショップで終わりにしない
- 上司の前だとリスクが出てこない — プレモーテムは匿名性を確保すると効果が上がる。付箋に書いて回収する、オンラインフォームを使うなどの工夫が有効
- 楽観バイアスを取り除けていない — 「失敗した前提」のフレーミングを省略して「リスクは何かある？」と聞くだけだと、通常のリスク分析と変わらない。宣言のプロセスが本質
- プロジェクト開始後に初めてやる — プレモーテムは計画段階で実施してこそ効果がある。進行中に行っても対策の組み込みが遅れる
まとめ#
プレモーテムは「30分でできる最高のリスク対策」だ。必要なのはチーム、付箋、そして「このプロジェクトは失敗しました」という一言。この宣言が楽観バイアスを解除し、「言いにくいリスク」を表に出す。通常のリスク分析より30%多くのリスク要因が挙がるという研究結果は、この手法の有効性を裏付けている。次のプロジェクトのキックオフで、最後の30分を「プレモーテム」に使ってみてほしい。