プレモーテム分析
概要
事後にプロジェクトが失敗した理由を分析する「ポストモーテム(事後検証)」とは異なり、 「プレモーテム(事前検証)」 はプロジェクトの開始時に行われる予防的な戦略である。プロジェクトがすでに失敗したと想像し、その原因を逆算して突き止めることで、チームは楽観主義バイアスを回避し、リスクが顕在化する前に隠れたリスクを特定することができる。
評価 (1–5)
- 適用性: 5
- 有効性: 4
- 複雑さ: 3
- 誤用のリスク: 2
評価コメント
プロジェクトのリスクを可視化し、実行可能なものにする上で非常に有効である。しかし、対策を講じることなく悲観的なシナリオばかりに過度に偏ると、「分析麻痺」や勢いの喪失につながる可能性がある。
最初の問い
「1年後の未来を想像してほしい。このプロジェクトは完全に大失敗に終わった。一体何が間違っていたのか?」
目的
- プロジェクトの「ハネムーン期間(初期の熱狂期)」に抑圧されがちな、潜在的なリスクを表面化させること。
- 「楽観主義バイアス」 や集団浅慮(グループシンク)を解体すること。
- 懸念を表明することが成功への貢献と見なされる文化を醸成すること。
質の低い問い
- 「とりあえず、すべてが計画通りに進むと仮定しよう。」 (不確実性という現実を無視しているため)
- 「何がうまくいかない可能性があるだろうか?」 (問いとして弱すぎ、失敗がすでに起こったと仮定するほどの創造的な「後知恵」を引き出せないため)
使い方
- 計画を定義する: 現在の計画や仮説を簡単に振り返る。
- 失敗を想像する: 「プロジェクトは壮大に失敗した」と明確に述べる。大惨事が確実であるという精神的な空間を作り出す。
- 失敗の理由を洗い出す: 参加者にブレインストーミングを行わせ、プロジェクトが失敗した考えうるすべての理由をリストアップさせる。具体的に記述する(例:「競合他社が2ヶ月早く同様の機能をリリースした」など)。
- 対策を立案する: 理由のリストを見直し、これらのシナリオを防ぐか、あるいはその影響を軽減するための具体的なアクションを設計する。
アウトプット例
- リスク軽減ログ:
- 想像上の失敗 A: コアなターゲット層にとって、ユーザーインターフェースが複雑すぎた。
- 対策: 開発フェーズにおいて、2週間ごとにユーザビリティテストのセッションをスケジュールする。
- 想像上の失敗 B: 主要なチームメンバーがプロジェクトの途中で離脱した。
- 対策: チームメンバーをクロストレーニング(多能工化)し、ドキュメントを改善して個人への依存度を下げる。
- 想像上の失敗 A: コアなターゲット層にとって、ユーザーインターフェースが複雑すぎた。
- 視覚化:
- リスクツリー: 最上部に主要な失敗を置き、その下に寄与する様々な原因を枝分かれさせた分岐図。
- 予防的アクションマップ: 「潜在的な失敗ポイント」と「現在の防御策」をマッピングした表。
ユースケース
- ビジネス: 主要なプロジェクトの立ち上げ前、新市場への参入前、または大規模な組織再編の実施前。
- 日常生活: 人生を左右するような決定(例:新しい都市への引っ越し、起業など)を下す前。
- 意思決定 / 思考: 計画に対して、危険なレベルの「過信」を感じたとき。
典型的な誤用
- 純粋な悲観主義: リスクをリストアップするだけで実行可能な対策を作成せず、準備ではなく単なる恐怖を煽ってしまうこと。
- リスクを事実として扱うこと: 想像上のすべてのリスクが確実に起こると思い込み、不必要なオーバーエンジニアリング(過剰な作り込み)を招いてしまうこと。
- 表面的なブレインストーミング: 「不都合な」構造的盲点を掘り下げるのではなく、明白なリスクだけをリストアップしてしまうこと。
他のモデルとの関係
- 補完的: リスク・リターン思考、認知バイアスの認識(楽観主義バイアスへの対抗)
- 関連: 二次思考(結果の考慮)、ベイズ思考(新しいシナリオに基づく更新)