事前の死後検証（プレモーテム）
すでに失敗したと仮定して、原因を逆算する
[プロジェクト/計画] が半年後に完全に失敗したと仮定してください。事後振り返りを書いてください：1）失敗した最も可能性の高い理由 5 つを確率順に；2）各理由について、今の早期シグナルは何か；3）今から予防できる原因はどれか；4）失敗確率を下げるために 1 つだけできるなら何か。
使い方
失敗した日付と「失敗」の定義を 1 行で渡す。でないと原因が一般論になる。
向いている場面
- プロジェクトが承認され、予算も通り、スケジュールも配られたあと。方向転換はまだ間に合うのに、チームの誰も水を差さなくなっているとき。
- リリース前の最終レビューで、全員が「どう良くするか」を話していて、「完全に失敗したらどんな状態か」を誰も問うていないとき。
向いていない場面
- まだ形になっておらず、アイデアの段階のとき。半年後の失敗理由は「ニーズが本物でなかった」のような漠然としたものになります。検証できる選択をまだ何もしていないからです。
- 実際の失敗の直後で、事故の振り返りをしているとき。ここは証拠から逆算する場で、仮定の失敗理由は本当の原因を覆い隠します。
例
入力
6 か月後に有料メンバーシップ（月 39 元）を出す計画です。無料ユーザーは 8,000 人、月間アクティブは 2,600 人。
得られるもの
ほしいのは確率順に並んだ 5 つの原因で、それぞれが今日見られる信号と結びついていること。たとえば「30 日留存が 11% なので習慣ができておらず、課金の接点がない」。最後は、今週やれてコストが最小の予防 1 つに収束しているべきで、保管用のリスク一覧ではありません。
よくある誤用
- 失敗理由の一覧をリスク台帳として保存し、各項目に確認時期を付けないこと。半年後には、自分の一覧にチェックを入れただけだと気づきます。
- 「なぜ失敗したか」だけを聞き、「失敗は最初にどんな姿で現れるか」を聞かないこと。正しいが観測できない原因（「競合が強い」）が並び、1 つも使えません。
こう変えると効く
- 「半年後に完全に失敗」を「半年後にかろうじて生きているが苦しい」に変える。多くのプロジェクトは急死ではなく慢性消耗で、この聞き方のほうが本当の原因が出ます。
- 「この失敗原因のうち、最初の 2 週間で私たち自身が作ってしまうものはどれか」を足す。外部への帰属が、自分で制御できる行動に引き戻されます。