AI時代のプロダクト失敗を防ぐ戦略：AT&Tプロダクトリーダー、Anu Jagga Narangが語る「プレモーテム」の全貌

プロダクト開発の世界では、成功への熱意が先行し、失敗の可能性が語られにくいという心理的な障壁が存在します。しかし、予測可能な失敗の兆候を見過ごすことは、企業にとって計り知れない損失をもたらしかねません。特にAIの進化がプロダクト開発の速度を劇的に加速させる現代において、このリスクは増大の一途を辿っています。

本記事では、AT&TのプロダクトリーダーであるAnu Jagga Narang氏が提唱する、プロダクト失敗を未然に防ぐための強力な手法「プレモーテム（Pre-mortem）」について、その本質、具体的な実践方法、ビジネスへの影響、そしてAI時代におけるその重要性を深く掘り下げていきます。Anu氏の豊富な経験と洞察を通じて、プロダクトリーダーや開発チームが直面する課題に対し、いかにして効果的なリスク管理を行い、持続的な成功を収めることができるのかを詳細に解説します。

Anu Jagga Narang氏の背景とプロダクトリーダーとしての視点

AT&Tのプロダクトリーダーとして活躍するAnu Jagga Narang氏は、プロダクト戦略の強化、プロダクトマネージャー（PM）のコーチング、そしてフィーチャーベースのデリバリーからアウトカムベースのリードへの転換に深く貢献しています。彼女のキャリアは、プロダクト開発の多岐にわたる側面を経験してきた豊かな道のりを物語っています。

多様な経験が育んだプロダクトへの洞察

Anu氏は元々ソフトウェアエンジニアとしてキャリアをスタートさせましたが、自身の創造性への強い志向から、ユーザーエクスペリエンス（UX）デザイン、ビジュアルデザイン、ブランドマネジメントへと活動の場を広げていきました。その後、情報アーキテクチャ（IA）やビジネスアナリスト（BA）の経験を経て、プロダクトマネジメントの世界へと辿り着きます。この非伝統的でありながらも、多角的な視点を持つキャリアパスが、彼女の今日のプロダクトリーダーシップに深みを与えています。

特に注目すべきは、消費者心理学への深い関心です。Anu氏は、情報アーキテクチャの仕事に従事していた頃から、人々がどのように行動し、どのように考えるのかを熱心に研究してきました。この消費者心理への理解が、彼女のプロダクト意思決定の多くの部分を形成し、ユーザー中心のプロダクト開発において不可欠な視点を提供しています。

AIとプロダクト開発の最前線

現在の役割に就く前、Anu氏はAT&Tの検索およびバーチャルアシスタント体験を構築するチームを5年間率いていました。これは、チャットボット体験を想像すると分かりやすいでしょう。このチームはAIに深く焦点を当て、顧客が適切な回答を得られるような多くの機能を開発し、AT&Tのプロダクトやサービスに関するサポートを提供していました。この経験は、AIがプロダクト開発に与える影響と可能性を肌で感じる貴重な機会となりました。

新しい役割に就いて間もないAnu氏は、プロダクト戦略の強化、プロダクトの構築方法、問題の定義、意思決定のプロセス、そしてPMが成果を主導する方法に焦点を当てています。彼女は、まだ「海の足を探している（finding my sea legs）」状態だと語りつつも、様々なチームと協力して問題提起を深く考え、実験を構築し、戦略に取り組む機会を楽しんでいます。

さらに、Anu氏は個人的にもAIプロダクト開発に積極的に取り組んでいます。これにより、様々なAIツールを試用し、自らプロダクトを構築することで、常に「プロダクトを構築する筋肉」を失わないように努めています。彼女は、自身のような「あまり上手ではないソフトウェアエンジニア」でさえ、今日のAIツールを使えばより良い開発ができるようになったと語っており、AIが開発プロセスに与える変革を深く理解しています。

このAIに対する深い理解と実践経験が、後に述べるプレモーテムとAIの関連性に関する彼女の洞察の根拠となっています。

プレモーテムとは何か？その起源と心理学的基盤

プロダクト開発におけるリスク管理の古典的かつ強力な手法として、Anu氏が特に強調するのが「プレモーテム」です。これは単なるリスクアセスメントを超え、人間の心理に深く根ざしたバイアスを克服するための、巧妙に設計された意思決定品質ツールです。

プレモーテムの定義と起源

プレモーテムは「仮想的な災害防止演習」と定義されます。具体的には、プロダクトのローンチが既に完了し、それが「徹底的な失敗」に終わったと仮定することから始まります。そして、その失敗の原因が何であったのかを遡って分析し、どのような意思決定をしていれば異なる結果になったのかを検討します。これは、未来に起こりうる失敗を事前に体験し、そこから学ぶことで、現実の失敗を防ぐことを目的とした手法です。

この方法は約30年前、認知心理学者のゲイリー・クライン（Gary Klein）によって考案されました。彼の目的は、プロジェクトが引き起こす可能性のある潜在的なリスク、問題、失敗を「プロアクティブ」に特定することにありました。従来の事後的な振り返り（ポストモーテム）とは異なり、事前の段階で未来の失敗シナリオを描くことで、リスクへの対処を前倒しで行うことを可能にします。

プロスペクティブ・ハインドサイト：過信と楽観主義バイアスを打ち破る心理学的トリック

プレモーテムの核心にある心理学的なトリックは、「プロスペクティブ・ハインドサイト（Prospective Hindsight）」、つまり「予見的後知恵」と呼ばれます。通常、私たちはプロジェクトの成功を強く信じ、楽観主義バイアスや過信に陥りがちです。これは、無意識のうちにリスクを軽視し、問題を見過ごしてしまう原因となります。

しかし、プレモーテムでは、あえて未来の「失敗」を既成事実として受け入れ、その原因を「過去を振り返るように」分析します。この思考プロセスは、人間の脳が過去の出来事に対してより合理的に原因を特定しようとする傾向を利用しています。「すでに失敗した」という前提に立つことで、参加者は「もし失敗したらどうしよう」という不安ではなく、「なぜ失敗したのか」という問いに対し、より客観的かつ自由に思考を巡らせることができるようになります。これにより、通常では声に出しにくい、あるいは見過ごされがちな潜在的なリスクや弱い仮説、隠れた依存関係が表面化しやすくなります。

なぜプレモーテムは現代において重要なのか？

プレモーテムの重要性は、以下の点に集約されます。

心理的安全性の創出: 失敗を予測したり、懸念を表明したりすることは、特に組織文化によっては「否定的な発言」と見なされ、困難を伴う場合があります。プレモーテムは、「失敗を前提とする」という明確なフレームワークを提供することで、チームメンバーが安心してリスクや懸念を声に出せる心理的な安全性を生み出します。これは、建設的な批判や異なる意見が歓迎される環境を育む上で不可欠です。
弱い仮説・隠れた依存関係の表面化: プロダクト開発では、多くの仮説の上に計画が構築されます。しかし、これらの仮説の中には、検証が不十分であったり、暗黙のうちに受け入れられていたりするものも少なくありません。プレモーテムは、これらの「弱い仮説」が失敗の原因となるシナリオを具体的に考えることを促します。また、複数のチームやシステム間に存在する「隠れた依存関係」も、失敗の物語を紡ぐ中で明らかになることがあります。
マインドセットのシフト: 従来のプロダクトチームは、「プロジェクト計画を立てたから、何をすべきか分かっている」という「実行の自信」に傾倒しがちです。しかしプレモーテムは、この自信を一時的に脇に置き、「私たちは本当に正しい道を歩んでいるのか？」という本質的な問いかけに焦点を当てさせます。このマインドセットのシフトは、単なるタスク遂行に留まらない、より戦略的かつ批判的な思考をチームにもたらします。

これらの要素は、現代の複雑で高速なプロダクト開発において、見過ごされがちな潜在的リスクを早期に特定し、対処するための強力なフレームワークとして機能します。

「失敗」の多面性：成功のリスクとフレーミング

プレモーテムの核心は「失敗」を深く掘り下げることにありますが、Anu氏はその「失敗」という概念を、単なるネガティブな結果として捉えるのではなく、より多角的な視点から考察しています。特に、「大成功」がもたらすリスクという逆説的な側面にも注目することは、リスク管理の奥行きを深めます。

大成功がもたらす予期せぬ「失敗」

多くのチームは、プロダクトが「大成功」することを目標に掲げます。しかし、Anu氏は「もしこれが大成功したらどうなるか」という問いかけもまた、プレモーテムの議論に含めることができると指摘します。これは一見、失敗を想定するプレモーテムの目的と矛盾するように見えますが、実は深い洞察に基づいています。

もしプロダクトや機能が予想をはるかに超える「大成功」を収めた場合、それに伴う「スケーリングリスク」や「組織的準備不足」が浮上する可能性があります。例えば、以下のようなシナリオが考えられます。

技術的スケーリングリスク: 想定以上のユーザーが殺到し、システムが負荷に耐えきれずダウンする。これはプロダクト自体は成功しているにもかかわらず、その成功が「処理できない失敗」となって現れるケースです。
組織的準備不足: 顧客サポートの体制が追いつかず、ユーザーからの問い合わせがパンク状態になり、顧客満足度が低下する。これも、プロダクトの人気は高いのに、運用体制の不備によって全体としては失敗と見なされかねません。
サプライチェーンの破綻: 物理的なプロダクトの場合、予期せぬ需要の急増に対応できず、部品調達や製造、物流が滞り、機会損失を招く。

Anu氏は、このようなケースもまた「失敗」の一種であると捉えます。「プロダクトは成功したのに、それに対する準備ができていなかったために結果として失敗した」という視点です。この考え方は、プレモーテムが単なる悲観的なリスク評価ではなく、あらゆる種類の予期せぬ事態への「レジリエンス（回復力）」を高めるための演習であることを示唆しています。

「終末論的」にならずに失敗をフレームする

プレモーテムで失敗を議論する際、チームが「ああ、もう全部ダメだ！」といった終末論的な思考に陥らないように、Anu氏は「失敗をどのようにフレームするか」が非常に重要であると説きます。

彼女が提案するのは、「ローンチから6ヶ月後、このプロダクト／機能は徹底的な大災害となった」と仮定することです。重要なのは「ローンチ直後」ではなく「6ヶ月後」という時間軸を設定することです。これにより、単なる初期バグや軽微な問題ではなく、プロダクトの長期的な影響や市場での受容、目標達成の状況に焦点を当てることができます。

このフレーミングが特に強力なのは、以下の要素を強制的に明確にする点です。

プロダクト目標の明確化: 「大災害」のシナリオを考えるためには、まず「何をもって成功とするのか」というプロダクトの明確な目標がチーム内で共有されている必要があります。「このプロダクトは、6ヶ月後に〇〇という目標を達成しているはずだったが、それは完全に失敗した」という議論は、自然と目標が何であるかを再確認させ、その目標が適切であったか、そして計測可能であったかを見直す機会を与えます。Anu氏自身も、プレモーテムが「チームが目標について合意していることを保証する、強制的な機能」であると述べており、この点は多くのチームが見過ごしがちな落とし穴であると警鐘を鳴らしています。
客観的な指標に基づいた評価: 「利用者が期待通りに使っていない」「採用が進んでいない」「望んでいた収益を生み出していない」といった、具体的な目標未達の指標を想像することで、失敗の原因をより具体的に深掘りすることができます。これにより、感情論ではなく、事実に基づいた分析を促します。

この「6ヶ月後の大災害」というフレームは、チームが心理的に失敗を受け入れやすくなるだけでなく、プロダクト開発の最も初期段階で、目標設定の甘さや測定方法の不明確さといった根本的な課題に気づく機会を与えます。失敗を単なるネガティブな結果ではなく、学びと改善の機会として捉えるための強力な思考ツールとなるのです。

プレモーテムの実践：効果的な実施ステップとツール

プレモーテムは単なる概念的な思考訓練ではなく、具体的なステップと適切なツールを用いて実行することで、その真価を発揮します。Anu氏の経験に基づき、効果的なプレモーテムの実施方法を詳細に見ていきましょう。

プレモーテムを実施する最適なタイミング

プレモーテムは、プロダクト開発プロセスの特定の段階に限定されるものではなく、様々なタイミングでその価値を発揮します。

主要なローンチ前、または不可逆な意思決定の前: 最も一般的なのは、プロダクトや機能の大きなローンチを控えている段階です。これは、まだ引き返せる段階で潜在的な問題を特定し、対処するための最後の機会となります。同様に、戦略的な方向性を決定するような、不可逆的な意思決定の前に行うことも非常に有効です。
プロジェクトのキックオフ時（グリーンフィールド開発の場合）: 新規のプロダクトや戦略、完全に新しい分野（グリーンフィールド）での開発の場合、要件定義や発見フェーズが完了し、問題提起と目標設定が明確になった段階でプレモーテムを実施します。これにより、初期段階で潜在的なリスクを洗い出し、成功への土台を固めることができます。
開発途中での軌道修正: 開発が進行している中で、「何かおかしい」「チーム間に不協和音がある」「タイムラインが合わない」「異なる認識で話している」といったシグナルを感じた場合も、プレモーテムを実施する絶好の機会です。これは、スプリントの振り返り（レトロスペクティブ）とは異なり、より広範な戦略的、組織的な問題を浮き彫りにする可能性があります。
スコープ、仮説、または情報が変化した時: プロジェクトのスコープが変更されたり、当初の仮説が新しい情報によって揺らいだりした場合も、リスクテイクを最小限に抑えるためにプレモーテムを再実施することが推奨されます。

プレモーテムは「一度やったら終わり」のものではなく、必要に応じて定期的に、あるいは特定のトリガーイベントに応じて再実施することで、継続的なリスク管理と改善のループを形成します。Anu氏は、もし何もせず失敗したとしたら何が起こるか、なぜ失敗したかを問いかけることで、2回目のセッションをフレームすることも可能だと指摘します。

誰を巻き込むべきか、そしてセッションの長さ

参加者: プレモーテムの「we（私たち）」は、プロダクトマネージャー、エンジニア、デザイナー、QAなど、プロダクトや機能の開発に直接関わる「コアチーム」のメンバーが中心となります。これは、彼らが日々の業務の中で最も具体的なリスクや問題点に気づきやすいためです。
- ステークホルダーの参加: ステークホルダーを巻き込むかどうかは、慎重な判断が必要です。彼らを参加させることで、より戦略的な視点や異なる部門からのリスクを特定できるメリットがある一方で、チームの心理的安全性が損なわれるリスクも存在します。チームとステークホルダー間の信頼関係や、リーダーシップが心理的安全性をどの程度確保できるかに依存します。
セッションの長さ: プレモーテムの議論自体は、30分以内が理想的だとAnu氏は語ります。これは、参加者の集中力を維持し、効率的に主要なリスクを特定するためです。しかし、特定されたリスクに対する具体的な「アクションプランニング」には、もう少し時間をかける必要があるでしょう。

効果的な実践ステップ

プレモーテムを成功させるための具体的なステップは以下の通りです。

キックオフと目的の明確化:
- セッションの冒頭で、プロダクトが解決しようとしている問題、全体戦略、具体的な目標を明確に再確認し、チーム全員が同じ認識を持つようにします。
- プレモーテムが「なぜ」行われるのか、その目的（失敗を未然に防ぎ、意思決定の品質を高めること）を説明します。
心理的安全性の確立:
- 「プロダクトは失敗したと仮定する」という前提を強調し、誰もが自由に、恐れることなく意見を述べられる安全な場であることを保証します。匿名ツールを使用することも、この心理的安全性を高める上で非常に有効です。
失敗のストーリー記述:
- チームメンバーに「このプロダクトが完全に失敗したとしたら、その理由は何か？」という問いに対して、具体的なストーリー形式で記述するよう促します。キーワードや箇条書きではなく、「まるでそれが実際に起こったかのように、何が起こり、なぜ起こったのか」を詳細に記述することが重要です。これにより、単なる思いつきではなく、具体的な状況や因果関係に基づいたリスクが表面化しやすくなります。
- 多文化のチームの場合、言語の壁や表現の違いがあるため、より詳細な記述を求めることで、意図が正確に伝わるようにします。
リスクのアップ投票と分類（タイガー、ペーパータイガー、エレファント）:
- 全員が自分の失敗ストーリーを提出した後、それらを共有し、全員でレビューします。
- 投票ルール: Anu氏の経験では、投票を制限しないと、自分の意見や特定の意見に票が集中しすぎる傾向があるため、厳格なルールを設定しています。例えば、「1アイデアにつき1票」といった制限を設けることで、多様なリスクに目が向けられるようにします。
- リスクの分類: Sha Stoshi氏のフレームワークを借用し、リスクを以下の3つのカテゴリに分類します。事前にこれらの定義をチームに説明することが重要です。
  - タイガー（Tiger）： 明確で差し迫った脅威。もし対処しなければ、プロジェクトを「殺す」ことになる致命的なリスク。最優先で解決策を講じる必要があります。
  - ペーパータイガー（Paper Tiger）： 他のメンバーはリスクだと感じるかもしれないが、そのリスクの「オーナー」が既にコントロール下に置いており、対処済みであると考えるリスク。この場合、リスクそのものよりも、適切な「コミュニケーション」と「安心感の提供」が重要になります。
  - エレファント（Elephant）： 「部屋の中の象」のことわざのように、誰もが認識しているが、声に出して議論されていない未解決の問題や懸念。これらのリスクを可視化し、公に議論の俎上に載せることが重要です。
- チームは、それぞれの問題やリスクがどのカテゴリに属するかを分類し、その後、決められたルールに従って投票を行います。例えば、タイガーとペーパータイガーには2票、エレファントには1票といった配分で投票させることで、優先度の高いリスクに注目を集めます。（※原文では「one vote per idea. Um and two votes for uh tigers, paper, two votes for paper tigers and one for elephant.」とあるため、個々のアイデアに1票を割り当てた上で、リスクカテゴリ別にタイガー、ペーパータイガーには2票、エレファントには1票を投票するという解釈が妥当です。これは、特定のカテゴリのリスクに対する「重み付け」や「注目度」を高めるための工夫と考えられます。）
- この投票プロセスにより、チーム全体として最も懸念されている、あるいは対処すべきだと考えられているリスクが明確になります。例えば、Anu氏の経験では、ある大規模ローンチのプレモーテムで、多くのチームメンバーがアプリケーションのパフォーマンス問題に直面していたにもかかわらず、それが共有されていなかったケースがありました。誰かがそのフィードバックを共有すると、それが最も多くアップ投票され、結果的にチームはローンチ前にパフォーマンス改善に注力し、成功を収めることができました。
アクションの割り当てと計画:
- 最も多くアップ投票された、または最も重要だと特定されたリスクに対し、具体的な「責任者（オーナー）」と「次のステップ（アクションアイテム）」を割り当てます。
- 「いつまでに修正されるのか」「解決策はあるのか、ないならどう見つけるか」といった問いに答え、明確な実行計画を策定します。これは、単なる議論で終わらせず、具体的な改善行動につなげるための重要なステップです。

使用すべきツール

プレモーテムは、物理的な場所でもリモートでも実施可能です。

対面の場合: 付箋とホワイトボードがあれば十分に実施できます。
リモートの場合: KOD、Product Board、Idea Boardsといったデジタルツールが利用できます。Anu氏は特に「Idea Boards」を推奨しており、その「匿名性」がチームの心理的安全性を高め、本音の意見を引き出すのに役立つと述べています。他のツールでは、フィードバックに発言者の名前が紐づくことが多く、匿名性が損なわれる場合があります。

これらのステップとツールの活用により、プレモーテムはチームが潜在的なリスクを深く掘り下げ、それらをプロアクティブに対処するための、実践的かつ効果的なフレームワークとなります。

よくある間違いとアンチパターン

プレモーテムは強力なツールですが、その効果を最大限に引き出すためには、よくある間違いやアンチパターンを理解し、避ける必要があります。Anu氏の経験から、以下に主要な注意点を挙げます。

1. 実際のローンチや具体的な目標に紐付けない

プレモーテムは、特定のプロダクトや機能の「ローンチ」または「具体的な目標達成」を想定した仮想的な失敗シナリオに焦点を当てることで、その効果を発揮します。しかし、これを「漠然としたプラットフォーム開発」や「単なるバックログの多さ」といった、包括的で定義の曖昧な問題に適用しようとすると、結果は散漫なものになりがちです。

Anu氏の経験では、具体的なローンチに紐付けずにプレモーテムを実施した際、チームのダイナミクスや不満に関する「ノイズ」が多く発生しました。これらはリーダーにとって有益なシグナルではあるものの、プレモーテムの本来の目的（特定のプロダクト失敗リスクの特定と対処）からは外れてしまいます。プレモーテムは「何を解決しようとしているのか」が明確な場合に最も有効です。

2. 投票に制限を設けない

リスクやアイデアに対する投票に明確なガイドラインがない場合、参加者は自分のアイデアや特定のアイデアに過度に投票してしまう傾向があります。これにより、本当に重要で多様なリスクではなく、一部の声の大きいリスクや、人気投票のような結果に偏ってしまう可能性があります。

Anu氏は、この問題に対処するために「1アイデアにつき1票」といった制限を設けることの重要性を強調しています。また、リスクのカテゴリ（タイガー、ペーパータイガー、エレファント）に応じて投票の重み付けを変えるなど、意図的に焦点が絞られるような工夫も有効です。

3. 反応や不満のはけ口にする

プレモーテムは、チームメンバーが率直な意見を述べるための心理的に安全な場であるべきですが、それが「不満の吐き出し口」や「反応を provoke するため」の場と化してはなりません。アジャイルのセレモニーを「武器化」するような形で、建設的ではない批判や感情的な意見が支配的になると、本来の目的であるリスクの特定と解決策の模索が困難になります。リーダーは、議論が建設的な方向に進むようファシリテーションし、無意味な対立や不満の表明に終始させないよう注意が必要です。

4. すべてのリスクを平等に扱う

プレモーテムでは多くの潜在的リスクが表面化しますが、それらをすべて同じレベルで扱うことは非効率的であり、チームの焦点がぼやける原因となります。タイガー、ペーパータイガー、エレファントといったリスク分類は、この問題に対処するためのものです。

タイガーは最優先で対処すべき致命的なリスクです。
エレファントは議論すべきですが、即座の行動が必要ない場合もあります。
ペーパータイガーはコミュニケーションで解決できる可能性があります。

これらの違いを認識し、それぞれのリスクの「規模、重要度、優先度」を評価した上で、焦点を当てるべき課題を明確にすることが重要です。そうでなければ、チームはどの問題に取り組むべきか分からなくなり、効果的なアクションが取れません。

5. 一度実行して忘れ去る、または行動を起こさない

プレモーテムの最も大きな失敗は、議論が行われ、リスクが特定されたにもかかわらず、その後の「行動」が伴わないことです。プレモーテムは単なる診断ツールではなく、改善行動を促すためのものです。

アクションの欠如: 特定されたリスクに対する責任者が割り当てられず、具体的な行動計画が策定されない場合、プレモーテムは単なる時間の無駄になります。チームは、自分たちの意見が聞き入れられ、具体的な変化につながることを期待しています。アクションが伴わないと、チームのエンゲージメントや心理的安全性は著しく低下し、将来のプレモーテムへの参加意欲も失われます。
継続的な見直しを怠る: プロダクト開発はダイナミックなプロセスであり、状況は常に変化します。一度プレモーテムを実施したからといって、すべてのリスクが解決されたわけではありません。Anu氏が指摘するように、プロダクトやプロジェクトの進化に合わせて定期的に見直しを行うことが不可欠です。例えば、初期のプレモーテムで「要件の不明確さ」が問題として浮上し、それが改善されたとしても、次のラウンドでは「スコープクリープ」や「責任の欠如」といった新たな問題が表面化することもあります。

6. 心理的安全性の欠如

これはおそらく最も根本的な失敗要因です。リーダーがチームにとって心理的に安全な環境を構築できていない場合、チームメンバーは本当に懸念している「深いレベルの問題」や「組織的な機能不全」について発言することをためらいます。その結果、表面的な問題しか浮上せず、プロジェクトの本質的なリスクは見過ごされ、プレモーテムの価値は大幅に損なわれます。

心理的安全性を確保するためには、リーダーが率先して弱さを見せたり、批判を受け入れたり、建設的な対立を奨励したりする姿勢が不可欠です。また、匿名ツールの利用や、意見の多様性を尊重する文化の醸成も重要です。

これらのアンチパターンを避けることで、プレモーテムはプロダクト開発チームにとって真に価値ある、持続的な改善を促すツールとなるでしょう。

AIがプレモーテムに与える影響と役割

現代のプロダクト開発において、AIはあらゆる側面に影響を及ぼしています。プレモーテムも例外ではありませんが、Anu氏の洞察は、AIがこの手法の必要性を「減らすのではなく、むしろ増大させる」という逆説的な結論を導き出しています。

AIがリスクを増大させる側面：高速な「間違った」プロダクト開発

AIツールの台頭は、プロダクト開発の速度と効率性を劇的に向上させました。しかし、Anu氏はこれに付随する大きなリスクを指摘します。

「AIによって、私たちは間違った問題に対する機能を、ただより速く出荷できるようになった。」

これは、AIが「より良い判断」をもたらすのではなく、「より速いアウトプット」をもたらすという本質的な違いを示しています。AIは、与えられたタスクを効率的に実行できますが、そのタスク自体が「やるべきこと」であったか、あるいは「正しい問題」を解決しているかどうかの判断は、依然として人間が行うべき領域です。

AIが提供する「高速なアウトプット」は、チームに「誤った自信」を与えかねません。「これだけ速く開発できるのだから、きっとうまくいくはずだ」という過信が生まれやすくなります。この過信は、プレモーテムが打ち破ろうとする楽観主義バイアスをさらに強化する可能性さえあります。

したがって、AIベースの開発への移行が進むにつれて、「作れるから作るべきか（Can we build it?）」という問いから、「作るべきか（Should we build this?）」という、倫理的・戦略的な問いへのシフトがこれまで以上に重要になります。プレモーテムは、この「作るべきか」という問いを深く掘り下げるための人間中心のプロセスとして、その重要性を増しているのです。

AIがプレモーテムを支援できる側面：事務作業の効率化

AIは、プレモーテムの管理面や事務的なオーバーヘッドを削減することで、その効果的な実施を支援できます。

テーマの要約: プレモーテムのセッションで多くの意見やリスクが提出された場合、AIはその膨大な情報を分析し、主要なテーマやパターンを迅速に要約することができます。これにより、人間が手作業で分析する時間を大幅に節約し、より本質的な議論に集中できるようになります。
重複リスクの特定と統合: 多くのチームメンバーから類似のリスクが異なる表現で提出されることがあります。AIは、これらの重複するリスクを特定し、本質的に同じ根を持つものを統合するのに役立ちます。これにより、リスクリストが整理され、焦点を絞りやすくなります。
緩和計画の追跡: 特定されたリスクに対する緩和策やアクションプランは、長期にわたって追跡する必要があります。AIツールは、これらの計画の進捗をモニタリングし、責任者にリマインダーを送るなど、追跡プロセスの管理を支援することができます。

AIができないこと：人間的要素の代替不可能性

AIがプレモーテムの管理を効率化できる一方で、Anu氏はAIには代替できないプレモーテムの「人間的」な側面を明確に指摘しています。

心理的安全性の創出: AIは、チームメンバー間に信頼関係を築き、恐れることなく意見を述べられる「心理的な安全な空間」を創り出すことはできません。これは、リーダーシップが人間関係を構築し、共感を呼び起こし、脆弱性を許容する文化を醸成する、人間ならではの役割です。
チーム間の勇気の醸成: 困難な真実や不都合な事実を声に出すには、「勇気」が必要です。AIは、チームメンバーにこの勇気を与えることはできません。これは、チームの結束と、率直なコミュニケーションを奨励するリーダーシップによってのみ育まれるものです。
「エレファント」の表面化: 誰もが知っているが、誰も口にしない「部屋の中の象」のような問題は、AIが自然言語処理で検出できるものではありません。これは、人間の直感、共感、そして非言語的なシグナルを読み取る能力によってのみ、表面化し、議論の俎上に載せることができます。
トレードオフの意思決定と結果への責任: プレモーテムで特定されたリスクに基づいて、トレードオフの意思決定を行うのは人間です。どのリスクを優先し、どの機能を諦めるか、あるいはどのリソースを投入するかといった判断は、複雑な価値判断と戦略的思考を要します。そして、失敗したプロダクトローンチの結果に対する「責任」を負うことができるのも、人間だけです。AIは、そのような責任を負うことはできません。

結論：人間的判断が中心のAI時代のリスク管理

Anu氏の結論は明快です。プレモーテムは依然として「人間による判断に基づく演習」であり、その本質は変わらない。AIは、そのプロセスにおける「事務的および管理的なオーバーヘッド」を削減する強力な支援ツールとして機能するが、プレモーテムが求める本質的な洞察、勇気、人間関係の構築といった核心的な要素は、引き続き人間が担うべき役割である。

AIがプロダクト開発の速度を上げるほど、私たちはより深く、より頻繁に「何が間違っている可能性があるか」「本当にこれを作るべきか」という問いに向き合う必要があります。プレモーテムは、このAI時代において、人間の知恵と慎重さをプロダクト開発に組み込むための、不可欠な戦略的ツールとして位置づけられるのです。

結論：AI時代の持続可能なプロダクト成功へ向けて「プレモーテム」を実装する

Anu Jagga Narang氏の深い洞察を通じて、「プレモーテム」という手法が、現代のプロダクト開発、特にAIが急速に進化する時代において、いかに不可欠であるかが明確になりました。プロダクトの失敗は、単なる機能不全に留まらず、準備不足による成功さえも含む多面的なリスクとして捉えられます。そして、その失敗を未然に防ぐためには、単なる楽観主義や過信に流されることなく、意図的に「失敗」を想定し、そこから学ぶという逆説的なアプローチが求められるのです。

プレモーテムは、単にリスクを特定するツールではありません。それは、心理的安全性を確保し、チームメンバーが建設的な批判や潜在的な懸念を自由に表現できる文化を醸成するためのプロセスです。明確な目標設定から始まり、仮想的な失敗ストーリーの記述、そして「タイガー」「ペーパータイガー」「エレファント」という分類を通じたリスクの優先順位付け、そして最終的には具体的なアクションプランの策定へと繋がる一連のステップは、チームの意思決定品質を飛躍的に向上させます。

AIの進化は、プロダクト開発の速度を劇的に高めましたが、それは同時に「間違ったプロダクトをより速く開発してしまう」リスクも増大させました。AIが管理タスクを効率化できる一方で、心理的安全性の構築、勇気の醸成、そしてトレードオフの意思決定といった人間ならではの役割は、決して代替されません。むしろ、AI時代において、私たちはこれまで以上に人間の知恵と批判的思考をプロダクト開発の中心に据える必要があり、プレモーテムはそのための強力なフレームワークとして機能します。

Anu氏の経験が示すように、プレモーテムは一度実施して終わりではありません。プロジェクトのライフサイクルや状況の変化に応じて定期的に見直し、特定されたアクションを確実に実行し、その結果から学ぶことこそが、持続的なプロダクトの成功へと繋がる道です。リーダーは、このプレモーテムを単なるツールとしてではなく、組織文化の一部として根付かせ、心理的安全性を常に育むことにコミットする必要があります。

プロダクト開発の世界は常に進化しています。今日、AIがもたらす変革の波の中で、Anu Jagga Narang氏が語る「プレモーテム」は、未来の失敗を未然に防ぎ、イノベーションを持続可能な成功へと導くための、最も重要な戦略の一つとなるでしょう。あなたのチームも、今日からこの強力な手法を試してみてはいかがでしょうか。