pre-mortem

事前検死

プロジェクトが大失敗したと想像し、その原因を特定するためにさかのぼって考えます。Gary Klein の「予見的後知恵」の手法を用いて、失敗が起こる前に見つけましょう。

このスキルを使う場面

• 製品、キャンペーン、または大規模な取り組みを開始する前
• 重要な決定（採用、投資、パートナーシップ）を行う前
• チームが考慮していないリスクを特定するためにプロジェクトを始めるとき
• 自信過剰になり、全員が計画は素晴らしいと同意しているとき
• 重要な取り組みにリソースを投入する前
• 人々がためらわずに懸念を共有できるよう、チームで計画を立てるとき

方法論の基盤

項目	詳細
出典	Gary Klein（1989年）、認知心理学者、自然主義的意思決定研究の先駆者
専門家	Klein の研究によると、事前検死によって結果の理由を特定する精度が30％向上します
基本原則	「予見的後知恵」—出来事がすでに起きたと想像すると、その説明能力が大幅に高まります。未来は遠く感じられますが、過去は現実味を帯びています。

Claude が行うことと、あなたが決めること

Claude が行うこと	あなたが決めること
制作ワークフローを構成します	最終的なクリエイティブの方向性
技術的なアプローチを提案します	機材とツールの選択
テンプレートとチェックリストを作成します	品質基準
ベストプラクティスを特定します	ブランドや語調に関する決定
台本の概要を作成します	台本の最終承認

このスキルでできること

1. 隠れたリスクを明らかにします — 前向きな計画では見えない危険を見つけます
2. 批判しやすくします — チームメンバーが安心して懸念を口にできます
3. 自信過剰を抑えます — 計画錯誤や楽観バイアスに対処します
4. 実行前に計画を改善します — 修正が容易なうちに問題を解決します
5. 心理的安全性を高めます — 「失敗を想像してみましょう」は「これは失敗すると思います」よりも安心して口にできます

使い方

事前検死を行う

Run a Pre-Mortem on this project:
[describe the project, product, or decision]

It's one year from now and this has failed completely. What happened?

決定事項をストレステストする

Pre-Mortem this decision:
[describe the decision you're considering]

Assume we made this choice and it went badly. What went wrong?

チームで事前検死を進行する

Help me facilitate a Pre-Mortem session for my team.
Project: [description]
Team size: [number]
Time available: [duration]

Provide the agenda, questions to ask, and how to synthesize findings.

手順

事前検死を進行する際は、次の体系的な手順に従います。

ステップ 1：準備する

## Pre-Mortem Setup

**Project/Decision:** ________________________________

**Timeline:** [Imagine we're looking back from X months/years]

**The Scenario:**
"It is [future date]. This project has failed—not just underperformed,
but failed spectacularly. The results are in and they're bad.

We're now conducting a post-mortem to understand what went wrong.
Looking back, it's obvious why this failed..."

**Rules:**
1. Failure has ALREADY happened (this is a fact in this exercise)
2. Everyone must contribute at least one reason
3. No defending the plan (we're explaining failure, not preventing it)
4. Be specific, not vague
5. "I had a bad feeling" is valid (hindsight makes it concrete)

---

ステップ 2：個人で失敗要因を挙げる（無言で）

## Individual Brainstorm (5-10 minutes)

Each person silently writes answers to:

"Looking back, this project failed because..."

1. ________________________________________________
2. ________________________________________________
3. ________________________________________________
4. ________________________________________________
5. ________________________________________________

**Prompt Questions:**
- What did we overlook?
- What assumption proved wrong?
- What external event derailed us?
- Who let us down (vendor, team member, partner)?
- What resource ran out?
- What competitor move hurt us?
- What customer behavior surprised us?
- What technical problem emerged?
- What communication failure occurred?
- What timeline assumption was wrong?

最初に無言で行う理由：

• 集団思考を防ぎます
• 内向的な人も平等に発言できます
• 話し合いによって焦点が狭まる前に、多様な懸念を集められます

---

ステップ 3：共有して分類する

## Round Robin Sharing

**Process:**
1. Each person shares ONE reason (no discussion yet)
2. Continue rounds until all reasons shared
3. Capture on whiteboard/doc as shared

**Clustering:**
Group similar failure reasons into categories:

### EXECUTION FAILURES
- ________________________________
- ________________________________

### EXTERNAL FACTORS
- ________________________________
- ________________________________

### RESOURCE CONSTRAINTS
- ________________________________
- ________________________________

### ASSUMPTION FAILURES
- ________________________________
- ________________________________

### PEOPLE/TEAM ISSUES
- ________________________________
- ________________________________

### TIMING/MARKET
- ________________________________
- ________________________________

---

ステップ 4：分析して優先順位を付ける

## Risk Assessment Matrix

For each failure reason, assess:

| Failure Reason | Likelihood | Impact | Detectability | Risk Score |
|----------------|------------|--------|---------------|------------|
| [Reason 1] | H/M/L | H/M/L | Early/Late/Never | ___ |
| [Reason 2] | H/M/L | H/M/L | Early/Late/Never | ___ |
| [Reason 3] | H/M/L | H/M/L | Early/Late/Never | ___ |

**Scoring:**
- High Likelihood + High Impact + Late/Never Detection = CRITICAL
- Medium/Medium/Early = MANAGEABLE
- Low/Any/Early = MONITOR

## Priority Failures

**CRITICAL (Must Address):**
1. ________________________________
2. ________________________________
3. ________________________________

**MONITOR (Watch Closely):**
1. ________________________________
2. ________________________________

---

ステップ 5：予防・軽減策を作成する

## Prevention Strategies

For each critical risk:

### Risk: [Failure Reason 1]

**Early Warning Signs:**
- ________________________________
- ________________________________

**Prevention Actions:**
- ________________________________
- ________________________________

**If It Happens Anyway (Mitigation):**
- ________________________________
- ________________________________

**Owner:** ____________
**Review Date:** ____________

---

### Risk: [Failure Reason 2]

[Repeat structure]

---

## Tripwires (Automatic Triggers)

"If we see [sign], we immediately [action]"

1. If ______________, then ______________
2. If ______________, then ______________
3. If ______________, then ______________

---

ステップ 6：計画に反映する

## Updated Project Plan

### Original Assumptions (Now Questioned)
| Assumption | Pre-Mortem Concern | Validation Plan |
|------------|-------------------|-----------------|
| [Assumption] | [Risk raised] | [How to test] |
| [Assumption] | [Risk raised] | [How to test] |

### New Safeguards Added
- [ ] ________________________________
- [ ] ________________________________
- [ ] ________________________________

### Monitoring Dashboard
Track these metrics as early warning system:
1. ________________________________
2. ________________________________
3. ________________________________

### Scheduled Check-ins
- Week 2: Review assumption #1
- Week 4: Check metric #2
- Month 2: Full pre-mortem review

---

例

例 1：製品ローンチのプレモーテム

背景： 3 か月後に新しいエンタープライズ製品をローンチする SaaS 企業です。

入力：

「Q2 にエンタープライズ製品をローンチします。みんな期待しています。プレモーテムを実施して、何が失敗の原因になったのか考えてください。」

出力：

シナリオ： 「9 月です。Q2 のエンタープライズ製品のローンチは失敗しました。資金を使い果たし、製品はまったく普及せず、ピボットを検討しています。何が問題だったのでしょうか？」

生成された失敗要因：

実行上の失敗：

1. エンタープライズの営業サイクルを過小評価していた（2 か月ではなく 6〜12 か月）
2. 想定していなかったセキュリティ審査要件があった（SOC2 など）
3. 製品は実際にはエンタープライズ対応ではなかった（監査ログ、SSO が不足）
4. サポートがエンタープライズ顧客の期待に対応できなかった

市場／タイミング： 5. 経済状況によりエンタープライズの予算が凍結された 6. Q1 に競合 2 社が類似製品をローンチした 7. ターゲット企業が「様子見」の状態だった

社内／チーム： 8. 営業チームにエンタープライズの経験がなかった 9. エンジニアリングのリソースがローンチとバグ修正に分散していた 10. マーケティングメッセージがエンタープライズの購入担当者に響かなかった

リソース： 11. 十分な契約を獲得する前に資金が尽きた 12. エンタープライズ営業担当者を十分な速さで採用できなかった

リスク評価：

失敗要因	可能性	影響	優先度
エンタープライズの営業サイクルの過小評価	高	高	重大
製品がエンタープライズ対応ではない	高	高	重大
予算凍結	中	高	注視
競合のローンチ	中	中	監視
営業チームの経験不足	高	高	重大

防止計画：

リスク 1：営業サイクルの過小評価

• 防止策：エンタープライズとの商談を今すぐ（3 か月前倒しで）始める
• 検証：ローンチ前に「関心がある」という電話を 5 件受けるのではなく、LOI を 5 件獲得する
• トリップワイヤー：第 4 週までに LOI がなければ、ローンチを一時停止する

リスク 2：製品がエンタープライズ対応ではない

• 防止策：要件を監査するエンタープライズアドバイザーを採用する
• 対応：ローンチ前に SSO、監査ログ、SLA を優先する
• トリップワイヤー：セキュリティ質問票の審査に通らなければ、ローンチを延期する

リスク 3：営業チームの経験不足

• 防止策：エンタープライズ経験のあるシニア営業担当者またはコンサルタントを 1 名採用する
• 代替策：エンタープライズに特化した再販業者と提携する
• 検証：本格的なローンチ前にパイロットを 1 件獲得する

更新後の計画：

• ローンチを Q3 に延期する（現実的なスケジュール）
• SOC2 認証をロードマップに追加する
• Q1 にエンタープライズ営業責任者を採用する
• 一般公開前にデザインパートナーを 3 社確保する

---

例2：採用決定のプレモーテム

背景： スタートアップが、重要なシニア人材を採用しようとしています。

入力：

「エンジニアリング担当VPを採用しようとしています。給与は30万ドルで、株式報酬もあり、大きな決断です。この決定についてプレモーテムをしてください。この採用はどのように失敗しましたか？」

出力：

シナリオ： 「12か月後です。エンジニアリング担当VPの採用は大失敗でした。多額の費用をかけて別れることになり、チームの士気は下がり、進捗が6か月分失われました。何が起きたのでしょうか？」

失敗の理由：

適性の不一致：

1. 大企業の業務プロセスには精通していましたが、スタートアップ特有の曖昧さに対応できませんでした
2. 企業文化が合いませんでした。フラットな組織には階層的すぎました
3. 技術スキルが時代遅れでした（レガシースタックの経験）
4. 製品をリリースするより、組織を大きくすることを望んでいました

不十分な採用プロセス： 5. 私たちは採用を急いでおり、プロセスを急ぎすぎました 6. リファレンス先は実際の部下ではなく、友人でした 7. 実際の業務を試してもらいませんでした（トライアルプロジェクトなし） 8. 面接で創業者のカリスマ性が危険信号を覆い隠しました

期待の不一致： 9. 「VP」と伝えていましたが、必要だったのは「プレイングマネージャー」でした 10. 報酬への期待が膨らみ続けました 11. 私たちが用意できる以上のチームや予算を期待していました

外部要因： 12. カウンターオファーによって、本人の気持ちが引き戻されました 13. 配偶者が転居を嫌がりました 14. 「踏み台」としてこの仕事を引き受けました

リスク評価：

失敗の理由	発生可能性	影響	優先度
スタートアップの段階に合わない	高	致命的	致命的
リファレンス確認の不備	中	高	致命的
期待の不一致	高	高	致命的
トライアル期間なし	中	高	対応

予防計画：

リスク1：スタートアップの段階に合わない

• 予防策：面接でスタートアップ特有の混乱について明確に話し合います
• テスト：「仕様が不完全な状態でリリースした経験を教えてください」
• 危険信号：大企業での事例しか出てこない

リスク2：リファレンス確認の不備

• 予防策：本人が挙げなかった人にも話を聞きます
• 最低限：元部下2人（友人以外）
• 質問：「ぜひまた一緒に働きたいと思いますか？」

リスク3：期待の不一致

• 予防策：期待事項を文書化し、署名してもらいます
• 含める内容：予算、チームの規模、初年度の目標
• 話し合う内容：「予算が半分になった場合はどうしますか？」

リスク4：トライアル期間なし

• 予防策：オファー前に、報酬を支払う2週間のトライアルプロジェクトを実施します
• 代替案：まずアドバイザーとして一定期間働いてもらいます
• 最低限：実際の課題に半日、一緒に取り組みます

更新後の採用プロセス：

1. 面接に「スタートアップ特有の混乱」に関するシナリオを追加
2. リファレンス確認では、LinkedInを通じて本人が挙げていない人にも連絡
3. 期待事項を文書化
4. 最終オファーの前に、報酬を支払う2週間のトライアルを実施
5. 90日目にマイルストーンの確認

---

チェックリストとテンプレート

プレモーテム・キャンバス

┌─────────────────────────────────────────────────────────────────┐
│                     PRE-MORTEM CANVAS                           │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  PROJECT: _________________________________________________    │
│                                                                 │
│  DATE OF "FAILURE": _________________                          │
│                                                                 │
│  "It is [date]. This project has failed completely."           │
│                                                                 │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  WHY IT FAILED:                                                 │
│                                                                 │
│  1. _______________________________________________________    │
│  2. _______________________________________________________    │
│  3. _______________________________________________________    │
│  4. _______________________________________________________    │
│  5. _______________________________________________________    │
│                                                                 │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  TOP 3 RISKS TO ADDRESS:                                        │
│                                                                 │
│  1. _________________ Prevention: _______________________      │
│  2. _________________ Prevention: _______________________      │
│  3. _________________ Prevention: _______________________      │
│                                                                 │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  TRIPWIRES:                                                     │
│                                                                 │
│  If ___________________ → Then ___________________             │
│  If ___________________ → Then ___________________             │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

---

チームでのプレモーテム進行ガイド

## Pre-Mortem Meeting Agenda

**Duration:** 45-60 minutes
**Attendees:** Full project team
**Materials:** Sticky notes, timer, whiteboard

### 1. SETUP (5 min)
"It's [future date]. This project has failed—not just missed
targets, but failed spectacularly. We're doing a post-mortem.
With the benefit of hindsight, why did this fail?"

### 2. SILENT BRAINSTORM (7 min)
- Everyone writes failure reasons on sticky notes
- One reason per note
- Minimum 5 per person
- No talking

### 3. ROUND ROBIN (15 min)
- Each person shares one note at a time
- Post to wall, no discussion yet
- Continue until all shared
- Cluster similar items

### 4. DISCUSS & PRIORITIZE (15 min)
- Which risks are most likely?
- Which would be most damaging?
- Dot vote: everyone gets 3 dots

### 5. ACTION PLANNING (15 min)
- Top 3 risks get prevention plans
- Assign owners
- Set tripwires

### 6. CLOSE (3 min)
- Capture in doc
- Schedule follow-up
- Thank team for honesty

---

プレモーテムの質問集

## Pre-Mortem Prompts

Use these to stimulate thinking about different failure modes:

### EXECUTION
- What part of the plan was unrealistic?
- Where did quality suffer?
- What dependency let us down?

### PEOPLE
- Who underperformed or left?
- What conflict derailed us?
- What communication failed?

### RESOURCES
- What resource ran out?
- What was more expensive than planned?
- What took longer than expected?

### MARKET/EXTERNAL
- What changed in the market?
- What competitor move hurt us?
- What customer behavior surprised us?

### ASSUMPTIONS
- What "fact" proved wrong?
- What did we overlook?
- What seemed obvious in hindsight?

### TIMING
- What should we have done sooner?
- What external event affected us?
- What deadline was unrealistic?

---

プレモーテムとポストモーテムの比較

## When to Use Each

### PRE-MORTEM (Before)
✓ Project hasn't started yet
✓ Major decision pending
✓ Team is overconfident
✓ High-stakes initiative
✓ Want to find problems early

### POST-MORTEM (After)
✓ Project has completed (success or failure)
✓ Want to capture lessons learned
✓ Building institutional knowledge
✓ Improving future processes

### KEY DIFFERENCE

Post-Mortem: "What happened?" (Limited by actual events)
Pre-Mortem: "What COULD happen?" (Unlimited imagination)

Research shows Pre-Mortem generates 30% more failure reasons.
Why? "Prospective hindsight" makes imagined failure feel real.

スキルの適用範囲

このスキルが得意なこと

• 音声制作のワークフローを構成する
• 技術的なガイダンスを提供する
• 品質チェックリストを作成する
• 創造的なアプローチを提案する

このスキルではできないこと

• 音響エンジニアリングの専門知識に代わること
• 主観的な創作上の判断を下すこと
• 音声ファイルに直接アクセスしたり、編集したりすること
• 商業的な成功を保証すること

参考文献

• Klein, Gary. 「プロジェクト・プレモーテムの実施」Harvard Business Review（2007）
• Klein, Gary. 「権力の源泉：人はいかに意思決定するか」（1998）
• Kahneman, Daniel. 「ファスト＆スロー」（2011）— Kleinの研究を含む
• Heath, Chip & Dan. 「決定力」（2013）— プレモーテムの活用

関連スキル

• inversion - プレモーテム思考を含む、より広範なフレームワーク
• first-principles - プレモーテムで明らかになった前提に疑問を投げかける
• eisenhower-matrix - 緊急度と重要度に基づいてリスクに優先順位を付ける
• six-thinking-hats - ブラックハットが同様にリスクに焦点を当てる

---

スキルのメタデータ（内部使用）

name: pre-mortem
category: strategy
subcategory: risk-analysis
version: 1.0
author: MKTG Skills
source_expert: Gary Klein
source_work: "Performing a Project Premortem" (HBR 2007)
difficulty: beginner
estimated_value: $1,000 risk assessment consultation
tags: [risk-management, planning, decision-making, Klein, prospective-hindsight]
created: 2026-01-25
updated: 2026-01-25