Pre-Mortem分析：プロジェクト開始前に「失敗を想定」して防ぐ技術

ポストモーテムは失敗した後に行う振り返りだ。しかし「失敗してから学ぶ」のは遅すぎる場合もある。Pre-Mortem（プリモーテム）は、プロジェクトが始まる前に「このプロジェクトは失敗した——なぜか？」を想像することで、リスクを事前に特定する手法だ。

Pre-Mortemとは

Pre-Mortemは心理学者Gary Kleinが提唱した手法で、「未来の視点から失敗を想像する」というユニークなアプローチを取る。

通常のリスク分析では「何が失敗するかもしれないか？」と問う。これは予防的な視点だが、楽観バイアスの影響を受けやすい。人は「自分が関わるプロジェクトは成功する」と思いたいからだ。

Pre-Mortemでは「プロジェクトは完全に失敗した。6ヶ月後のあなたは廃墟の中にいる。なぜこうなったのか？」と問う。「失敗した事実」から逆算することで、楽観バイアスが外れて本音のリスクが出てくる。

Pre-Mortemセッションの進め方

所要時間： 60〜90分 参加者： プロジェクト主要メンバー全員（5〜10名が理想） 実施タイミング： キックオフの直前か直後

ステップ1：シナリオ設定（5分）

ファシリテーター（PM）が次のシナリオを読み上げる。

「今から1年後（or プロジェクト完了予定の3ヶ月後）のことを想像してください。
このプロジェクトは完全に失敗しました。目標は達成できず、
クライアントは失望し、チームは疲弊しています。

これは最悪のシナリオです。
さて——なぜこうなったのでしょうか？」

ステップ2：個人記述（10分）

参加者全員が、このプロジェクトが失敗した理由を個人で付箋（または共有ドキュメント）に書き出す。他の人の意見を見ずに、思いつく限り書く。

重要なのは「個人で書く」フェーズを設けることだ。グループ討議から始めると、声の大きい人の意見に引っ張られて本音のリスクが出ない。

ステップ3：共有・グルーピング（20分）

各自が書いた失敗理由を全員に共有する。Miroやボードに貼り出して、似たものをグルーピングする。

ステップ4：深掘り（20分）

グループ化したリスクの中で、特に「本当に起きそう」なものに投票する（ドット投票が有効）。上位3〜5つについて深掘り討議する。

ステップ5：アクション策定（20分）

特定されたリスクに対して、予防・軽減アクションを決める。

実際のPre-Mortemで出てきやすいリスク

PMが経験から見ると、Pre-Mortemで繰り返し出てくるリスクパターンがある。

人・チーム系：

• 「キーパーソンがプロジェクト途中で退職」
• 「チームの技術スキルが要件に対して不足」
• 「リモートワークで認識齟齬が溜まった」

スコープ・要件系：

• 「要件定義が曖昧なまま開発を開始した」
• 「クライアントの要求が途中で変わった」
• 「MVP定義が決まらずに機能が膨らんだ」

外部依存系：

• 「外部ベンダーの納品が遅延した」
• 「API・ライブラリのバージョン変更で対応が発生した」
• 「法改正・規制変更で対応が必要になった」

コミュニケーション系：

• 「ステークホルダーへの報告が後手に回った」
• 「エスカレーションが遅くて手の打ちどころを失った」

Pre-Mortemをリスクログに転換する

Pre-Mortemで特定したリスクはリスクログに記録する。フォーマット例は以下の通り。

リスク	発生確率	影響度	予防策	発生時対応	オーナー
キーパーソン退職	低	高	ドキュメント化・バックアップ育成	採用・外注手配	PM
要件変更	高	中	変更管理プロセス整備	スコープ交渉	PM+クライアント

このリスクログは毎週のレビューで更新する。Pre-Mortemで「想定済み」にしておくことで、実際にリスクが顕在化したときに「準備していた対応」を実行できる。

まとめ

Pre-Mortemは「失敗を想像する」という心理的に少し不快な作業だが、だからこそ価値がある。楽観バイアスを意図的に外して本音のリスクを引き出すこの手法は、プロジェクト開始時の1〜2時間で炎上リスクを大幅に下げる高コスパな投資だ。