s4h-decision-premortem-analysis

意思決定のプレモーテム分析

方向性が決まると、コミットメント・バイアスによって、リスクを率直に評価することがほぼ不可能になります。思考が意思決定を評価するのではなく、擁護し始めるからです。このスキルでは、特定の仮定を必須にすることで、その状態を打破します。プロジェクトはすでに失敗したと想定し、その理由を尋ねます。この悲観的な見方は任意ではありません。これこそが仕組みなのです。

---

プロセス

ステップ 1：意思決定と意図する成果を明確にする 意思決定の内容と、それによって実現するはずの具体的な成果を明確に記述します。期間と、成功を測定可能な形で定義した内容も含めます。

フレーミングの確認： 続行する前に、具体的な意思決定を確認します。特定した内容、つまりストレステストの対象となる実際の意思決定と意図する成果を一文で示し、その後 AskUserQuestion を使用します。

• 質問：「私は次のように理解しています：[意思決定と意図する成果を一文で示した内容]。この理解で合っていますか？」
• ヘッダー：「フレーミング」
• 選択肢：
  • はい — 続行 — フレーミングは正しい
  • 調整 — 1つの要素が違っている。続行する前にユーザーが修正する
  • 再フレーミング — 読み取った内容とは状況が異なる。続行する前に修正内容を反映する

ステップ 2：失敗した状況を想定する 失敗を前提とする枠組みに入ります。次のように述べます。「[プロジェクト名] は [日付] にローンチし、[成果] の達成に失敗しました。何が問題だったのでしょうか。」リスクをブレインストーミングするのではなく、事後分析を報告するように記述します。過去形の仮定によって、防衛的なフィルタリングを抑えられます。

ステップ 3：あらゆる失敗モードを洗い出す 発生確率で絞り込まずに、失敗モードを洗い出します。悲観的に考えるよう促します。それぞれの失敗モードについて、実際にはどのように進行するか、最初の兆候は何か、何が事態を悪化させるかを尋ねます。

ステップ 4：失敗を種類ごとに分類する

• 実行上の失敗：世界の捉え方は正しかったものの、実行を誤りました。タイミング、リソース配分、連携、品質などが該当します。
• 前提の失敗：実行は正しく行ったものの、世界の捉え方が誤っていました。市場、ユーザー、テクノロジー、依存関係などが該当します。
• 未知の失敗：この種の問題が起こることをまったく予想していませんでした。

ステップ 5：上位の失敗モードごとに先手を打つ 絞り込む前に： まず、洗い出した項目をすべてユーザーに提示します。AskUserQuestion を使用します。

• 質問：「[N] 件の失敗モードを特定しました。発生確率 × 深刻度で特に重要なものを選ぶ前に、特に重要だと思うものや、見落としているものはありますか？」
• ヘッダー：「優先順位付け」
• 選択肢：
  • この選定で進める — 洗い出した項目に問題はない
  • 1つ指摘する — ユーザーが含めるべき特定の失敗モードを挙げる
  • 不足分を追加する — ユーザーが見落としている失敗モードを説明する

最も重大な失敗モードを 3～5 件特定します（発生確率 × 深刻度が最も高いもの）。それぞれについて、この失敗の発生確率または深刻度を最も大きく下げるために、今すぐ実行できる単一の行動は何かを考えます。

---

ユーザーへの確認

続行する前に、AskUserQuestion ツールを使用します。状況についての解釈、つまり何を分析しているか、中心となる問いは何かを 1～2 文で示した後、次のように尋ねます。

• 質問：「私の理解は次のとおりです：[1～2 文で状況を解釈した内容]。どのように進めますか？」
• ヘッダー：「範囲」
• 選択肢：
  • 全体を分析 — すべてのステップを完了し、全過程で推論を示す
  • 主な結果のみ — 手順ごとの詳細を省略し、結論を出す
  • 上位 3 件の失敗モードのみ — 発生確率 × 深刻度の組み合わせが最も高いものに絞り、全項目の洗い出しは省略する
  • 再フレーミング — 理解が異なる。ユーザーが修正し、その内容に沿って分析する

選択に基づいて進めます。ユーザーがフレーミングを修正した場合は、分析を始める前に修正内容を反映します。

出力形式

決定と意図する成果：

[説明＋タイムライン＋測定可能な成功の定義]

失敗モード（すべて生成）：

失敗モード	種類（実行／前提／未知）	確率	重大度

事前対策を講じるべき、上位3〜5件の失敗モード：

失敗モード	重要である理由	事前対策

前提条件の一覧（これが機能するために真である必要があること）：

[箇条書き — 早期に検証すべき、最も影響の大きい未知の事項です]

---

メモ

前提条件の失敗は、何かが壊れるまで表面化しないため、最も危険なカテゴリーです。プレモーテムで最も長く役立つ成果となるのは、多くの場合、前提条件の一覧です。つまり、どの前提が間違っていれば、方針全体が無効になるのでしょうか？

---

次のステップ

この出力を提示した後、AskUserQuestion を使用して次のアクションを提案します。

• 質問：「失敗モードを整理しました。次はどうしますか？」
• ヘッダー：「次へ」
• 選択肢：
  • /s4h-constraint-workaround-mapping — 上位の失敗モードに、具体的な回避策で対処する
  • /s4h-decision-criteria-weighting — 失敗モードの分析結果に基づいて、決定基準を見直す
  • /s4h-strategy-positioning — 最も深刻な失敗の確率を下げるように、戦略を調整する
  • 完了 — ここまでの内容をまとめて終了する