プロジェクト・プレモーテム

英語名 Project Premortem
読み方 プロジェクト プレモーテム
難易度
所要時間 60〜90分(チームワークショップ)
提唱者 Gary Klein(認知心理学者)/ 2007年
目次

ひとことで言うと
#

プロジェクト開始前に「このプロジェクトは大失敗した」という未来を仮定し、チーム全員で失敗の原因を逆算して洗い出すリスク分析手法。通常のリスク分析とは異なり、「すでに失敗した」前提で考えることで楽観バイアスを打ち破る。

押さえておきたい用語
#

押さえておきたい用語
プレモーテム(Premortem)
ラテン語で「死の前」を意味する。プロジェクトが「死んだ」後の検死(ポストモーテム)ではなく、死ぬ前に原因を予測する手法。
楽観バイアス(Optimism Bias)
人間が自分のプロジェクトの成功確率を過大評価する認知の歪み。プレモーテムはこれを意図的に崩す。
プロスペクティブ・ヒンドサイト
「将来の出来事がすでに起きた」と仮定して振り返る思考法。通常の予測より 30%多くのリスク を特定できるとされる。
キルクライテリア(Kill Criteria)
プロジェクトを中止する明確な基準のこと。プレモーテムで特定したリスクから逆算して設定する。

プロジェクト・プレモーテムの全体像
#

プレモーテム:失敗の未来から逆算してリスクを洗い出す
このPJは大失敗した「なぜ失敗したのか?」逆算して原因を書き出す技術・実行リスク技術的な見積もりが甘かったテスト期間を削りすぎた外部依存が解消できなかった組織・人的リスクキーパーソンが途中離脱したスポンサーの関心が薄れたチーム間の連携が崩れたスコープ・環境リスク要件が途中で大幅に変わった市場環境が前提と違った予算が凍結された── 発生確率×影響度で優先順位をつける ──全員がドット投票でTop 3リスクを選定予防策・トリガー条件を設計各リスクに対して「予防アクション」と「発動条件」を決める→ プロジェクト計画に組み込んで運用する── 失敗を想像できれば、失敗を防げる ──
プレモーテムの進め方フロー
1
失敗を宣言する
「このPJは壮大に失敗した」とチーム全員に伝える
2
原因を書き出す
各自が「なぜ失敗したか」を個人ワークで書き出す
3
共有・優先順位づけ
全員の意見を共有し投票でTop 3リスクを選定する
予防策を計画に組み込む
各リスクの予防アクションとトリガー条件を設計する

こんな悩みに効く
#

  • プロジェクト計画が楽観的すぎると感じるが、言い出しづらい
  • 「リスクは何ですか?」と聞いても具体的な意見が出ない
  • 過去のプロジェクトで同じような失敗を繰り返している

基本の使い方
#

チームを集めて『失敗した未来』を宣言する
プロジェクトキックオフ後、チーム全員(5〜15名が適正)を集める。ファシリテーターが「このプロジェクトは半年後に壮大に失敗しました。なぜ失敗したのか、その原因を考えてください」と宣言する。
個人ワークで失敗原因を書き出す
5〜10分間、各自が無言で「失敗した原因」を付箋に書き出す。1枚に1原因。「すでに失敗した」前提なので、遠慮なく書ける。最低 3枚以上 を目標にする。
全員で共有し、分類・投票する
付箋をボードに貼り出し、似た原因をグルーピングする。全員がドット投票(1人3票)で「最も起きそうで、最もダメージが大きい」原因に投票。上位3〜5件を重点リスクとして特定する。
予防策とトリガー条件を設計する
重点リスクごとに「予防アクション(今から何をするか)」と「トリガー条件(この兆候が出たら対策を発動する)」を決める。これをプロジェクト計画書のリスク一覧に組み込み、定期的にモニタリングする。

具体例
#

例1:Web制作会社がリニューアル案件のプレモーテムを実施する

従業員18名のWeb制作会社。大手食品メーカーのコーポレートサイトリニューアル(予算 1,500万円、期間6か月)を受注。PM含め5名のチームでプレモーテムを実施した。

個人ワークで出た失敗原因は合計 23件。投票の結果、上位3件は以下の通り。

順位失敗原因票数予防策
1クライアント側の承認者が多すぎてフィードバックが遅延5票承認フローと返答期限を契約書に明記
2デザイン方向性の合意が曖昧なまま実装に入る4票デザインコンセプト承認をマイルストーンに設定
3テスト期間が圧縮される3票テスト開始日を固定し、スコープ調整で吸収する

結果的に、1位のリスクは実際に発生しかけたが、契約書に返答期限 3営業日 を明記していたことでクライアント側も意識が変わり、承認遅延は平均 1.2日 に収まった。プロジェクトは予定通り6か月で完了。

例2:製薬企業が新薬開発プロジェクトでプレモーテムを導入する

従業員2,800名の製薬企業。Phase II臨床試験(予算 12億円、期間3年)の開始前にプレモーテムを実施。プロジェクトチーム12名と外部CRO担当者3名が参加した。

「3年後、この治験は失敗した」と宣言し、個人ワークで合計 38件 の失敗原因が出た。上位5件のうち、通常のリスク分析では出てこなかった2件が注目された。

  • 「治験実施施設の医師が途中で異動し、症例登録が停滞した」( 6票
  • 「規制当局の審査基準が途中で変わり、追加データが必要になった」( 5票

前者への対策として、主要施設にバックアップ医師を事前に指名し、引き継ぎマニュアルを作成。後者への対策として、規制動向の四半期レビューをプロジェクト計画に組み込んだ。

3年間で主要施設の医師異動は実際に 2件 発生したが、バックアップ体制のおかげで症例登録の遅延は 2週間以内 に収まっている。

例3:地方自治体がDXプロジェクトの失敗リスクを事前に洗い出す

人口8万人の地方自治体。住民向けオンライン申請システムの導入(予算 4,800万円、期間18か月)にあたり、庁内横断チーム8名とベンダー担当者4名でプレモーテムを実施。

「18か月後、このシステムは誰にも使われていない」と宣言したところ、従来のリスク分析では出てこなかった意見が続出した。

投票上位は「高齢者がスマホで申請できず窓口に殺到した」( 7票)と「職員が新旧システムの二重運用に疲弊して旧システムに戻した」( 6票)。技術的な課題よりも、利用者と運用者の「行動変容」に関するリスクが圧倒的に多かった。

対策として、65歳以上向けの操作説明会を月2回設定し、職員向けには旧システムの段階的廃止スケジュール(3か月で切り替え→6か月の並行運用に変更)を決定。導入1年後のオンライン申請利用率は 47% に到達し、当初目標の40%を超えた。

やりがちな失敗パターン
#

パターン何が起きるか対策
「失敗した」と本気で想像しない通常のリスク分析と変わらない薄い内容になるファシリテーターが具体的な失敗シナリオを描写して臨場感を出す
声の大きい人の意見が通る本当のリスクが埋もれる必ず個人ワーク→投票の順で進め、発言力の差を無効化する
原因は出すが予防策を決めない「リスクを出して終わり」のイベントになるTop 3リスクに対して必ず担当者・期限・トリガー条件を決めてから解散する
プロジェクト途中で実施するすでに方針が固まっており「今さら言えない」空気になるキックオフ直後、計画が柔軟に変えられるタイミングで実施する

まとめ
#

プロジェクト・プレモーテムは、「このプロジェクトは大失敗した」という未来を仮定し、失敗原因を逆算で洗い出すリスク分析手法。通常の「リスクは何ですか?」という問いかけでは出てこない懸念が、「失敗した前提」にするだけで大量に出てくる。キックオフ直後に60〜90分で実施し、上位リスクの予防策をプロジェクト計画に組み込むことで、想定外の失敗を未然に防ぐ。