ひとことで言うと#
プロジェクト開始前に「このプロジェクトは大失敗した」という未来を仮定し、チーム全員で失敗の原因を逆算して洗い出すリスク分析手法。通常のリスク分析とは異なり、「すでに失敗した」前提で考えることで楽観バイアスを打ち破る。
押さえておきたい用語#
- プレモーテム(Premortem)
- ラテン語で「死の前」を意味する。プロジェクトが「死んだ」後の検死(ポストモーテム)ではなく、死ぬ前に原因を予測する手法。
- 楽観バイアス(Optimism Bias)
- 人間が自分のプロジェクトの成功確率を過大評価する認知の歪み。プレモーテムはこれを意図的に崩す。
- プロスペクティブ・ヒンドサイト
- 「将来の出来事がすでに起きた」と仮定して振り返る思考法。通常の予測より 30%多くのリスク を特定できるとされる。
- キルクライテリア(Kill Criteria)
- プロジェクトを中止する明確な基準のこと。プレモーテムで特定したリスクから逆算して設定する。
プロジェクト・プレモーテムの全体像#
こんな悩みに効く#
- プロジェクト計画が楽観的すぎると感じるが、言い出しづらい
- 「リスクは何ですか?」と聞いても具体的な意見が出ない
- 過去のプロジェクトで同じような失敗を繰り返している
基本の使い方#
具体例#
従業員18名のWeb制作会社。大手食品メーカーのコーポレートサイトリニューアル(予算 1,500万円、期間6か月)を受注。PM含め5名のチームでプレモーテムを実施した。
個人ワークで出た失敗原因は合計 23件。投票の結果、上位3件は以下の通り。
| 順位 | 失敗原因 | 票数 | 予防策 |
|---|---|---|---|
| 1 | クライアント側の承認者が多すぎてフィードバックが遅延 | 5票 | 承認フローと返答期限を契約書に明記 |
| 2 | デザイン方向性の合意が曖昧なまま実装に入る | 4票 | デザインコンセプト承認をマイルストーンに設定 |
| 3 | テスト期間が圧縮される | 3票 | テスト開始日を固定し、スコープ調整で吸収する |
結果的に、1位のリスクは実際に発生しかけたが、契約書に返答期限 3営業日 を明記していたことでクライアント側も意識が変わり、承認遅延は平均 1.2日 に収まった。プロジェクトは予定通り6か月で完了。
従業員2,800名の製薬企業。Phase II臨床試験(予算 12億円、期間3年)の開始前にプレモーテムを実施。プロジェクトチーム12名と外部CRO担当者3名が参加した。
「3年後、この治験は失敗した」と宣言し、個人ワークで合計 38件 の失敗原因が出た。上位5件のうち、通常のリスク分析では出てこなかった2件が注目された。
- 「治験実施施設の医師が途中で異動し、症例登録が停滞した」( 6票)
- 「規制当局の審査基準が途中で変わり、追加データが必要になった」( 5票)
前者への対策として、主要施設にバックアップ医師を事前に指名し、引き継ぎマニュアルを作成。後者への対策として、規制動向の四半期レビューをプロジェクト計画に組み込んだ。
3年間で主要施設の医師異動は実際に 2件 発生したが、バックアップ体制のおかげで症例登録の遅延は 2週間以内 に収まっている。
人口8万人の地方自治体。住民向けオンライン申請システムの導入(予算 4,800万円、期間18か月)にあたり、庁内横断チーム8名とベンダー担当者4名でプレモーテムを実施。
「18か月後、このシステムは誰にも使われていない」と宣言したところ、従来のリスク分析では出てこなかった意見が続出した。
投票上位は「高齢者がスマホで申請できず窓口に殺到した」( 7票)と「職員が新旧システムの二重運用に疲弊して旧システムに戻した」( 6票)。技術的な課題よりも、利用者と運用者の「行動変容」に関するリスクが圧倒的に多かった。
対策として、65歳以上向けの操作説明会を月2回設定し、職員向けには旧システムの段階的廃止スケジュール(3か月で切り替え→6か月の並行運用に変更)を決定。導入1年後のオンライン申請利用率は 47% に到達し、当初目標の40%を超えた。
やりがちな失敗パターン#
| パターン | 何が起きるか | 対策 |
|---|---|---|
| 「失敗した」と本気で想像しない | 通常のリスク分析と変わらない薄い内容になる | ファシリテーターが具体的な失敗シナリオを描写して臨場感を出す |
| 声の大きい人の意見が通る | 本当のリスクが埋もれる | 必ず個人ワーク→投票の順で進め、発言力の差を無効化する |
| 原因は出すが予防策を決めない | 「リスクを出して終わり」のイベントになる | Top 3リスクに対して必ず担当者・期限・トリガー条件を決めてから解散する |
| プロジェクト途中で実施する | すでに方針が固まっており「今さら言えない」空気になる | キックオフ直後、計画が柔軟に変えられるタイミングで実施する |
まとめ#
プロジェクト・プレモーテムは、「このプロジェクトは大失敗した」という未来を仮定し、失敗原因を逆算で洗い出すリスク分析手法。通常の「リスクは何ですか?」という問いかけでは出てこない懸念が、「失敗した前提」にするだけで大量に出てくる。キックオフ直後に60〜90分で実施し、上位リスクの予防策をプロジェクト計画に組み込むことで、想定外の失敗を未然に防ぐ。