プレモーテムPre-mortem

• 「失敗するかも」ではなく「もう失敗した。なぜ？」と問い、各自が静かに理由を書く。⁷
• 狙いは、計画段階で言いにくい懸念に発言の許可を与えること。⁷
• 根拠は中〜弱。実務報告は多いが、比較実験やメタ分析は見つかっていない。「30%向上」は Klein の引用で、原論文では未確認。⁸
• 出た懸念を担当・期限つきのアクション（多くても3つ程度）に落とさないと意味がない。小さい決定や即戻せる変更には不要（GitLab ハンドブック）。³

手順と記入例は準備中です。上の「どう使うか」と、「要点」をご覧ください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

原典で確かめたこと

• 提唱者・年: Gary Klein、2007年9月。HBR の記事ページ（hbr.org/2007/09/performing-a-project-premortem）を開いて、著者・掲載月・題名「Performing a Project Premortem」・再録番号 F0709A を確認した。書誌の巻号頁（85(9), 18-19）は検索結果の引用リスト経由で、一次ページでは未確認。⁷
• 原典の主張（自分の言葉で）: プロジェクトは高い確率で失敗するが、計画段階では懸念を持つ人ほど口に出しにくい。そこで「このプロジェクトはすでに失敗した」と仮定し、その理由を各自が挙げる。失敗を前提にすることで、事情に詳しい人が弱点を言う許可が得られ、成功確率を上げられる、という主張。⁷
• 土台の研究: Mitchell, Russo & Pennington (1989) "Back to the future: Temporal perspective in the explanation of events", *Journal of Behavioral Decision Making* 2(1), 25-38, DOI 10.1002/bdm.3960020103。書誌と要旨は colab.ws のページで確認（Wiley 本体は403で未開封、全文も未確認）。¹
• 要旨で確認できた内容: 「prospective hindsight（未来の出来事を既に起きたものとして説明する）」を扱う2実験。実験1では時間視点（未来か過去か）の効果は小さく、結果の確実性（起きると確定しているか）のほうが説明の性質を大きく変えた。確実な出来事の説明は長く、エピソード的な理由の割合が高く、過去形で語られた。¹
• 30%の数字: 検索で得た HBR 本文の引用では、Klein は「この1989年研究で prospective hindsight により将来の結果の理由を正しく特定する力が30%上がった」と書いている（HBR Guide 転載ページ経由。本文ページそのものは未開封）。1989年論文の要旨にはこの数字が出てこないので、論文本体で確認できるまでは「Klein が引用している数字」としか書けない。¹⁸