thinking-pre-mortem

事前検死分析

基本ルール： 将来を振り返る視点は、「何がうまくいかないだろう？」と考えるより効果的です。計画はすでに失敗した（過去形）と仮定し、具体的な失敗経路を挙げ、それを反転させて予防要件にし、最も重要な経路ごとに検証可能な計画変更を結び付けます。

使用するタイミング

• キックオフ、大きな技術的決定、リスクの高いスプリント作業、ローンチ、リリースの前。
• 計画が確かなものに見えてから実行に移る前。特に、楽観や過信が起きやすい場合。
• 決定を覆すコストが高く、リスクがまだ明示的な対策として組み込まれていない場合。

使用しないタイミング

• 作業が小規模で局所的であり、簡単に元に戻せる場合は、形式的な手順を省略します。
• 時間に追われるインシデントの最中である場合は、すぐに対処します（OODA／科学的方法）。事前検死は実行前に行うものです。
• 「スコープクリープ」や「要件が不明確」といった一般論しか出せず、それらをこの計画に結び付けられない場合。
• CI、カナリア、ロールバック、アラートなどの稼働中のゲートですでにリスクが抑制されており、未記載の経路が残っていない場合。
• 成熟したリスク登録簿ですでに、同じ具体的な失敗経路が担当者や確認項目とともに管理されている場合。

手順

1. 失敗の状況を過去形で設定します： 「締め切り後の日付です。計画は失敗しました：[ロールバック／データ損失／利用者が定着しない／SLA 違反]。」起きた失敗を説明する必要があります。予測するだけでは不十分です。
2. 絞り込む前に失敗理由を挙げます： 技術、プロセス、前提、依存関係／外部要因、人にわたって洗い出します。二度目の確認を行い、「計画が何よりも真実である必要があったのに、そうではなかったことは何か？」と問いかけます。まず幅広く集め（異なる理由を多数挙げることを目指します）、洗い出しの途中で順位付けはしません。
3. 優先順位を付けます： テーマごとにまとめ、発生可能性 × 影響度で評価し、具体的なリスクの上位3～5件を残します（計画に結び付かない一般論は除外します）。
4. 失敗起点の逆分析（逆経路を取り込む）： 上位リスクごとに、(a) 失敗した結果を過去形で言い直し、(b) その失敗に必要だった、または失敗を可能にした条件を列挙し、(c) 各条件を反転して検証可能な予防要件（回避／必須ルール＋確認）にし、(d) 担当者、検証チェックポイント、リリース／段階移行ゲートを結び付けます。
5. リスクを軽減し、計画を更新します： 上位リスクごとに軽減策を追加し、必要に応じてスパイクやコンティンジェンシーを設け、逆分析で導いた予防要件を明示的な計画上のゲートとして組み込みます。計画を変更しない事前検死は不完全です。
6. 次の条件で終了します： 上位リスクごとに、対応する軽減策または予防ゲートが設定されている、あるいは追加の理由が一般論の言い換えにすぎなくなったら終了し、更新した計画を実行します。ブレインストーミングを続けないでください。

出力

1. 失敗シナリオ — 日付と失敗した結果を含む、過去形で示した災害の状況。
2. 失敗理由 — 絞り込み前の一覧と、発生可能性 × 影響度で優先順位を付けた上位3～5件。
3. 逆経路 — 上位リスクごとに、必要条件 → 反転して導いた予防要件。
4. 軽減策 — 上位リスクごとに、担当者、検証チェックポイント、リリース／段階移行ゲート。
5. 計画の差分 — 計画に追加された具体的なタスク、スパイク、コンティンジェンシー、ゲート。

検証

• 反証／停止： 必要条件を伴う、計画固有の失敗経路を過去形で示せない場合は停止します。リスク対策をしているふりをしているにすぎません。「軽減策」に検証チェックポイントがなければ、完了とはみなしません。
• 過剰適用の防止： 元に戻せる雑務、インシデント対応の最中、または同じ失敗経路をすでに抑制しているシステムに対して事前検死を行わないでください。抽象的なリスクを「後で軽減する」として残さないでください。ゲートに反転させるか、実行可能な対策ではないものとして除外してください。