「失敗した未来」から逆算する — プレモータムと「まあ大丈夫だろう」の壊し方

「まあ大丈夫だろう」

外部向けのサービス提供で、セキュリティインシデントが起きた。

冷静に考えれば、インシデントが起きても問題ない環境にすべきだった。でも、相手先のシステムの制約があり、本来の方法が使えなかった。時間的なプレッシャーもあり、やむを得ず理想的ではない方法を採択した。

リスクがあることは、頭のどこかではわかっていたと思う。でも、「まあ大丈夫だろう」と思っていた。楽観バイアスが入っていた。

インシデント後、ログを全て確認して影響範囲を調べる必要があった。結果として、最初から正攻法でやっていたよりもはるかに時間がかかった。省いたはずの手間が、何倍にもなって返ってきた。

もし事前に「このプロジェクトでセキュリティインシデントが起きました。なぜですか？」と問われていたら、この方法のリスクに気づけていた。気づけていたどころか、やめよう、となっていたと思う。

知識が足りなかったわけではない。問いの立て方が足りなかった。

プレモータムという手法

心理学者のゲイリー・クラインが提唱した「プレモータム」という手法がある。ポストモーテム（事後検証）の逆だ。

ポストモーテムは、プロジェクトが終わった後に「なぜ失敗したか」を振り返る。プレモータムは、プロジェクトが始まる前に「もし失敗したとしたら、なぜか」を考える。

やり方はシンプルだ。プロジェクト開始前にチームで集まり、「このプロジェクトは失敗しました」と宣言する。各自が「なぜ失敗したか」の原因を書き出し、共有して対策を考える。

ダニエル・カーネマンは「自分が知っている中で、プロジェクトの意思決定を改善する最も簡単な方法」とプレモータムを評価している。

なぜ普通のリスク洗い出しでは出てこないのか

リスクを洗い出す場は、多くのプロジェクトにある。でも、「リスクは何ですか？」と聞いても、出てこないことが多い。

理由は2つある。

一つは楽観バイアスだ。「まあ大丈夫だろう」が前提にあるので、リスクを深刻に考えない。自分のプロジェクトは例外だと思ってしまう。

もう一つは心理的なハードルだ。チーム内で不安を口にすると、「ネガティブな人」に見られるかもしれない。特にプロジェクトの初期段階では、前向きな空気を壊したくないという気持ちが働く。

プレモータムは、この2つの問題を同時に解決する。「失敗しました」と仮定すると、楽観バイアスの前提が反転する。そして、失敗の原因を考えることが「正しい行動」になるから、不安を語る心理的ハードルが下がる。

事例分析との違い

製造業や建設業では、過去の事故事例を分析してリスクを学ぶ安全活動が広く行われている。事前にリスクを考えるという点ではプレモータムと似ている。ただ、事例分析は答えがあるものがほとんどだ。「この事例ではこういうリスクがありました」と示されると、そこに誘導されやすい。

プレモータムは自分たちの案件でやる。答えがない。だからこそ、事例分析では出てこないリスクが出てくる。自分たちのプロジェクト固有の文脈、人間関係、時間的制約。そういうものは事例分析の教材には載っていない。

悪魔の代弁者との違い

リスクを事前に洗い出す手法として、「悪魔の代弁者」もある。あえて反対意見を述べる役割を指名する方法だ。

プレモータムとの違いは構図にある。悪魔の代弁者は、反対する人と賛成する人の対立構造になる。一人が「本当にこれでいいのか」と問いかける。有効な手法だが、反対役を引き受ける心理的負担がある。

プレモータムは、全員が「失敗した前提」で考える。反対役はいない。全員が同じ方向を向いて、失敗の原因を探している。対立構造にならないから、チーム内の関係性を壊しにくい。

どちらが優れているということではない。悪魔の代弁者は意思決定の直前に効く。プレモータムはプロジェクトの初期に効く。場面に応じて使い分ければいい。

「失敗しました」とだけ言うと、あらゆる方向に発散する。現実的に使うには、いくつかのコツがある。

具体的な失敗シナリオを設定する。 「失敗しました」ではなく、「半年後に大幅に遅延しました。なぜ？」「セキュリティインシデントが起きました。なぜ？」のように、失敗の種類を具体的にする。ただし、シナリオを設定する時点でバイアスがかかる可能性はある。複数のシナリオを設定することで、偏りを減らせる。

個人で書き出してから共有する。 いきなり議論すると、声の大きい人に引っ張られる。まず各自が黙って書き出し、それから共有する。

時間を区切る。 10〜15分で書き出し、その後共有・議論。長くすると薄まる。

洗い出したリスクを全部潰す必要はない

プレモータムで出てきたリスクを、全部対策する必要はない。現実にはコストも時間も限られている。

大事なのは、リスクを認識した上で、どこまで対応してどこから受容するかを、チームとして、あるいはリーダーが意思決定することだ。

「まあ大丈夫だろう」でリスクを流すのと、「このリスクはあるが、対応コストを考えて受容する」と決めるのは全然違う。前者は思考停止だ。後者は意思決定だ。結果として同じ判断になったとしても、意識してリスクを受容した場合は、何かが起きたときの対応が早い。想定していたことが起きただけだからだ。

セキュリティインシデントの件も、もし事前に「このリスクはあるが受容する」と決めていたら、少なくとも対応の初動は変わっていたと思う。

振り返ると、セキュリティインシデントの件は、漠然とした不安はあった。でも、「まあ大丈夫だろう」で流してしまった。時間的プレッシャーの中で、不安よりも目の前の制約を優先した。結果として、省いた手間が何倍にもなって返ってきた。

プレモータムは、この漠然とした不安に言語化の機会を与える手法だとも言える。不安を感じていても、形にしないと対策は打てない。「なんとなく不安」のままでは、時間的プレッシャーに負けて楽観的な判断をしてしまう。

「もし失敗したら？」という問いが、不安を言葉にする許可を出す。言葉になれば、対策が打てる。対策が打てれば、不安のまま進むよりはるかにいい。

プロジェクトで、「まあ大丈夫だろう」と思っていることはないだろうか。

チームで「もし失敗したとしたら、なぜか？」と問いかけてみてほしい。

もう少し深く知りたい人へ

プレモータムは、心理学者ゲイリー・クラインが1989年に考案した手法だ。クラインは自然主義的意思決定論の研究者で、消防士やパイロットなど、時間的プレッシャーの中で判断を下す専門家の意思決定を研究してきた。プレモータムは、彼の研究から生まれた実践的なツールの一つだ。

プレモータムが効く理由は、心理学では「予測的後知恵（prospective hindsight）」として説明される。1989年のMitchellらの研究では、「ある出来事が起きた」と仮定してから原因を考えると、単に「起きるかもしれない」と考えるよりも、原因を30%多く挙げられることが示された。「起きた」と確定させることで、人の想像力が解放される。

ダニエル・カーネマンがプレモータムを高く評価した理由は、楽観バイアスと集団浅慮の両方に対処できるからだ。カーネマンは著書『ファスト＆スロー』で、人は計画段階で楽観的になりすぎる傾向（計画の錯誤）があると指摘している。プレモータムは、この楽観バイアスに対する具体的な対策として機能する。

本文で触れた「シナリオ設定時のバイアス」は、プレモータムの限界として認識されている。設定者の視野の外にあるリスクは出てこない。これを補うために、参加者の多様性を確保すること、複数のシナリオを設定すること、そして「自分たちが見落としているとしたら何か」というメタ的な問いを加えることが推奨されている。

参考文献

• Gary Klein (2007). Performing a Project Premortem. Harvard Business Review, 85(9), 18-19.
• ダニエル・カーネマン 『ファスト＆スロー』
• Mitchell, D. J., Russo, J. E., & Pennington, N. (1989). Back to the future: Temporal perspective in the explanation of events. Journal of Behavioral Decision Making, 2(1), 25-38.