ぷれもーてむ
プレモーテム (Pre-mortem)
UIXHERO Definition
「事前の検死」。まだ始まっていないプロジェクトを"もう失敗した"と仮定して、原因を洗い出すリスク発見法。
概要
心理学者ゲイリー・クライン（Gary Klein）が考案し、2007年にHarvard Business Reviewで広く知られるようになった手法。「ポストモーテム（事後検証）」の反対で、プロジェクトが始まる前に「すでに失敗した」と仮定し、その原因を参加者全員で洗い出す。
人間には楽観性バイアス（Optimism Bias）——「たぶん上手くいくだろう」と見積もる傾向——がある。通常のリスク議論では「大丈夫でしょう」で流されがちな懸念も、「もう失敗した」という前提を置くことで、心理的安全性が高まり言い出しやすくなる。行動経済学者ダニエル・カーネマンも、プレモーテムをバイアス対策の中で「最も気に入っている手法」として推奨している。
タップして拡大表示クリックして拡大表示
なぜ重要か
プロダクト開発やUXプロジェクトでは、スケジュール楽観、技術的リスクの過小評価、ユーザー不在の仮説設計など、さまざまな「見えにくい失敗原因」が存在する。これらは通常の計画会議ではなかなか表面化しない。プレモーテムは「失敗した」という仮定を共有するだけで、批判的な意見を出しやすい場を作れるため、特別なファシリテーション技術がなくても導入しやすい。
また、リスクが事前に言語化されていれば対策を打てるが、誰も口にしなければ対策のしようがない。プレモーテムは「言えなかったリスク」を引き出すための構造化された仕組みである。
UXでの活用
リリース前のUI/UXリスク洗い出し
「ユーザーが登録フォームで全員離脱しました。なぜ？」のように、具体的な失敗シナリオをUIの観点で想像する。ボタンの視認性、導線の複雑さ、エラーメッセージの不備など、設計レビューだけでは見落としがちなリスクが出てくる。
チーム内の懸念を安全に共有する
「失敗の原因解明」という設定のおかげで、批判的な意見が個人攻撃にならない。「スケジュールが厳しすぎる」「ユーザーリサーチが足りない」「この仕様は技術的に無理がある」といった言い出しにくい懸念を、角が立たずに共有できる。
計画の質を上げる
洗い出されたリスクに優先度をつけ、高リスク項目に対して具体的な予防策を計画に組み込む。「チュートリアルを追加する」「負荷テストを実施する」「ユーザーテストの回数を増やす」など、設計や体制にフィードバックすることで、計画の精度が上がる。
タップして拡大表示クリックして拡大表示
💡 使いどころ
プロジェクトのキックオフや新機能リリースの直前。 「もしこのプロジェクトが失敗したとしたら、原因は何だろう？」と未来視点で振り返る会議を行う。 楽観ムードが強く、リスクの議論が出にくいチームに特に有効。
⚠️ 注意点・誤用
単なるリスクのブレインストーミングとは異なり、「すでに失敗した」前提で語らせることがポイント。 この設定を省くと通常のリスク議論と変わらず、楽観性バイアスが残る。 また、出てきたリスクに対策を立てずに終わると形骸化する。
具体例
- 「リリース1週間後にユーザーからクレームが殺到しました。何が起きた？」と問いかける
- 「誰もこの機能を使っていません。なぜ？」でUI設計のリスクを発見する
- 「サーバーがダウンして大炎上しました。原因は？」でインフラの弱点を洗い出す
- 「競合に先を越されました。何が遅かった？」で開発プロセスのボトルネックを特定する
- Klein, G. (2007). Performing a Project Premortem. Harvard Business Review, September 2007.
- Kahneman, D. (2011). Thinking, Fast and Slow. Farrar, Straus and Giroux.
関連する解説記事
楽観バイアス (Optimism Bias)
- •UIXHEROでは、楽観バイアスを「ユーザーの『自分だけは大丈夫』という根拠なき自信」と捉える。
- •本記事では、警告文が読まれないことを前提とし、エラーを未然に防ぐ「システム的な保護」と、最悪の事態を想定した「悲観的な設計」による安全網を整理する。
防衛的デザインとエラー回避：ユーザーはあなたの説明を読まない
- •UIXHEROでは、防衛的デザインを「不完全な人間が使うことを前提とした、システムの優しさ」と捉える。
- •本記事では、エラーを未然に防ぎ、発生時のストレスを最小化する具体的なUIパターンを整理する。