プレモーテム（Pre-mortem）

まず知る

• 「失敗するかも」ではなく「もう失敗した。なぜ？」と問い、各自が静かに理由を書く（出典: Klein, HBR 2007）。（出典: https://hbr.org/2007/09/performing-a-project-premortem）
• 狙いは、計画段階で言いにくい懸念に発言の許可を与えること。（出典: https://hbr.org/2007/09/performing-a-project-premortem）
• 根拠は中〜弱。実務報告は多いが、比較実験やメタ分析は見つかっていない。「30%向上」は Klein の引用で、原論文では未確認。（出典: https://www.safaribooksonline.com/library/view/hbr-guide-to/9781422187319/14-chap5.xhtml）
• 出た懸念を担当・期限つきのアクション（多くても3つ程度）に落とさないと意味がない。小さい決定や即戻せる変更には不要（GitLab ハンドブック）。（出典: https://handbook.gitlab.com/handbook/engineering/data-engineering/pre-mortems/）

根拠の強さと限界

評価: 中〜弱（実務での支持は厚いが、実験的な裏付けは小さい）。

• 理論面: 失敗を前提にすると理由を挙げやすい、という考えは1989年研究に由来するとされる。ただし上記のとおり、原論文の要旨は「時間視点の効果は小さい」とも読める。引用の仕方に注意が必要。（出典: https://colab.ws/articles/10.1002%2Fbdm.3960020103）
• 直接の検証: 検索で確認できたのは、Veinott, Klein & Wiggins (2010, ISCRAM 会議論文) の実験（ブログ要約経由で178人、H1N1 対応計画の評価課題。計画への自信がプレモーテム群で大きく下がったとされる。論文本体は未開封、数値は未確認）と、フィールド/実験室での評価を扱った学位論文（core.ac.uk の抄録経由）。後者は結果が混在していて、ある実験では理由の数に有意差がなく、別の実験ではプレモーテムが優位。（出典: https://core.ac.uk/works/49608374。Veinott ほか 2010 の出典URL: 未確認）
• メタ分析・大規模再現: 見つからなかった。既存解説の「事例報告は多いが大規模な比較実験は少ない」は妥当。
• 限界: 想定できる範囲の失敗しか出ない。出た懸念が計画に反映されなければ意味がない。GitLab のハンドブックは「プレモーテムが事故を防いだことは証明できない」と明記している（下記）。（出典: https://handbook.gitlab.com/handbook/engineering/data-engineering/pre-mortems/）

使われた例（組織自身の公表と、研究・参考・手引きを分けて）

① 組織自身が使ったと公表した例（数えるのはここだけ）

1. PayPal（エンジニアリングチーム）／2021年7月（Seema Thapar 氏の自社ブログ）／原文 https://medium.com/paypal-tech/pre-mortem-technically-working-backwards-1724eafbba02 ／ソフト設計の通常プロセスにプレモーテムを組み込み（設計を1ページにまとめ、失敗理由を出し合い、設計に反映）。／結果: 早期の問題発見、死角の顕在化、若手の育成、参加意識の向上を報告。数値は無い。原文は Medium が403で開けなかったため、内容は InfoQ（https://www.infoq.com/news/2021/07/paypal-premortem-analysis）の要約経由で、要確認。

• 日本の事例: 企業が自社実施を公言した公式ブログ・資料を検索で見つけられなかった（未確認）。見つかったのは個人 note（2025年12月、自社実施の記述なし）と、ツール会社の解説のみ。

② 研究・評価として公表された試行／研究報告における実施例

• なし（確認できた範囲で）。

③ 近縁実践・参考例（原典との対応未確認）

• なし（確認できた範囲で）。

④ 手引き・解説（使用実績ではない）

1. （採用方針・使用実績の公表ではない） GitLab（データエンジニアリング／Monetization チーム）／2026年（ページ更新表示 2026-09-16）／公式ハンドブック https://handbook.gitlab.com/handbook/engineering/data-engineering/pre-mortems/ ／ローンチ前のリスク抽出に45分のプレモーテム（事前に24時間の非同期記述、30分の読み上げ、上位3アクションまで）。使うのは任意で、フラグ付きで即停止できる変更や定常作業では不要としている。／結果: 効果の数値は無い。「事故を防いだ証明はできない」とし、四半期ごとに「事故の原因がリスク一覧に載っていたか」だけ見るとしている。
2. Atlassian／ページ年は未確認／公式 Team Playbook https://www.atlassian.com/team-playbook/plays/pre-mortem ／「プレモーテム」の進め方を無料公開（準備、各自が静かに記入、投票、上位3つを議論、担当と期限を決める。合計約60〜65分）。／結果: 成果の記載なし。ページは社内利用を明言しておらず、Klein への帰属表示もない。公開手順であって、社内での使用実績ではない。

• Kahneman がプレモーテムを高く評価しているとの記述（fs.blog）は、本人の発言の出所が示されておらず採用しない。

まとめ: 組織自身が使ったと公表した例は PayPal の1件（内容は InfoQ の要約経由で要確認）。GitLab のハンドブックはチームの進め方を方針として書いたもの、Atlassian は公開手順で、どちらも④に置いた。

うまくいかなかった例と批判

• GitLab ハンドブックは「効果は証明できない」「繰り返し当たらないなら手法を変えるか、やめる」と自ら書いている（上記URL）。使わない場面（フラグ付き変更、定常作業、1人の既知の懸念を公式化するだけの場合）も明記。（出典: https://handbook.gitlab.com/handbook/engineering/data-engineering/pre-mortems/）
• 「やめた」と公言する例は見つからなかった。

原典を読む

• 原典: Gary Klein, "Performing a Project Premortem", HBR, 2007年9月（https://hbr.org/2007/09/performing-a-project-premortem）。短い記事で、英語。
• 邦訳書: ダニエル・カーネマン『ファスト&スロー（上・下）』村井章子訳、早川書房、2012年（ハヤカワ文庫NF 上下は2014年）。書誌は確認済み（紀伊國屋書店ページ）。プレモーテムの記述箇所は本文未確認。
• Klein 自身の邦訳書は今回確認できなかった。