pre-mortem

pre-mortem skill の概要

pre-mortem skill は、PRD、ローンチ計画、製品提案を出す前に、失敗を起点にした構造的なレビューを行うための skill です。一般的なブレストではなく、実際のリリース判断に役立つ形で「本当に危ないリスク」と「ノイズ」を切り分け、アクションリストに落とし込みたいプロダクトマネージャー、創業者、ストラテジスト、AI 支援の意思決定者に向いています。

pre-mortem skill の価値は、意思決定の構造にあります。単に懸念点を並べるのではなく、Tigers（信ぴょう性の高い問題）、Paper Tigers（過大評価されている、または発生確率が低い不安）、Elephants（チームが避けている未言及の論点）に分類し、さらにローンチへの影響度で優先順位づけします。そのため、リリース前レビュー、ロードマップのリスク点検、Decision Support 向けの pre-mortem で特に有効です。「何がリリースを止めうるのか」を知りたい場面に向いています。

pre-mortem skill は、最終的には不確実性の中での明確化を担います。つまり、リリース後にコストが大きくなる前に、失敗モードを早めに見つけて計画を変えることが主目的です。

pre-mortem skill が実際にやること

この skill は、製品の文脈を読み取り、「ローンチは失敗した」と仮定して原因を逆算します。出力は、リスク、根拠、各論点の緊急度がそのまま実務で使える形になるよう設計されています。

どんな人に向いているか

すでに現実的な提案があり、それを強く検証したいときに使ってください。たとえば PRD、ローンチブリーフ、機能展開計画、Go-to-Market プランなどです。経験豊富なプロダクトレビュー担当者のように推論してほしいときには、一般的なアイデア出しツールより、この pre-mortem ガイドが適しています。

向いていないケース

軽いブレストだけが欲しいなら、シンプルなプロンプトで十分なこともあります。具体的な計画がない場合は、リスクをうまく分類するための情報が足りません。入力に、前提条件、対象ユーザー、タイミング、成功基準が含まれているときに最も強みを発揮します。

pre-mortem skill の使い方

インストールして skill の場所を確認する

プロジェクトの手順にあるリポジトリのインストールフローを使い、そのあとでまず pm-execution/skills/pre-mortem/SKILL.md を開いてください。この repo では SKILL.md が唯一のソースファイルなので、追加のルール、スクリプト、参考資料を探すためのサポートフォルダはありません。

実際のローンチ資料を渡す

pre-mortem のインストールは、具体的な計画を入力して初めて意味があります。強い入力の例は次のとおりです。

• ターゲットユーザー、価値提案、非目標を含む PRD
• 日程、チャネル、依存関係、担当者が入ったローンチ計画
• 既知のリスク、制約、成功指標を含む機能ブリーフ

弱い入力は「この startup idea を分析して」のようなものです。これでは、失敗が実際に何を意味するのか判断できず、有用な pre-mortem になりません。

ざっくりした依頼を、使えるプロンプトに変える

「リスクを挙げて」と聞くのではなく、文脈と出力の形を指定して失敗レビューを依頼してください。たとえば、次のように書けます。
「このローンチ計画について pre-mortem を実施してください。ローンチは14日後に行われ、失敗したと仮定します。Tigers、Paper Tigers、Elephants を特定し、それぞれを launch-blocking、fast-follow、track に分類してください。adoption、messaging、product readiness、operational dependencies を重視してください。」

この言い回しは、何を最適化するのか、どの時間軸で考えるのか、見つかった論点をどう分類するのかを model に伝えるため、pre-mortem の使い勝手が大きく上がります。

出力は実行可能かどうかで確認する

良い出力は、リスクの長い一覧ではなく、確度の高い阻害要因を短くまとめたものです。次のような点を確認してください。

• チームがまだ検証していない前提条件
• ずれ込む可能性のあるローンチ依存関係
• adoption を止める顧客の反発
• 深刻そうに見えても、実際にはローンチ可否を変えない問題

回答が広すぎる場合は、不足している計画詳細を追加して、pre-mortem をもう一度実行してください。

pre-mortem skill の FAQ

通常のプロンプトより優れていますか？

意思決定の質を重視するなら、多くの場合は yes です。通常のプロンプトでもリスクは出せますが、pre-mortem skill なら、それらを順位づけし、見落としを拾い上げるための再現性ある構造が使えます。特に Decision Support 向けの pre-mortem では有用です。

プロダクトマネージャーでなくても使えますか？

はい。明確な計画を提示できて、「失敗」が何を意味するか説明できるなら、pre-mortem skill は初心者でも使えます。品質を左右するのは肩書きより、入力の具体性です。

製品ローンチ以外にも使えますか？

はい。社内ツールの展開、価格改定、実験、プロセス変更のように、実際のリスクがあり具体的な計画があるタスクなら使えます。自由なアイデア出しや、純粋に創造的な作業にはあまり向きません。

いちばんの制約は何ですか？

この skill は、与えられた文脈以上には鋭くなれません。PRD が薄いと、出力が目立つリスクに偏り、本当の阻害要因を見逃すことがあります。pre-mortem ガイドは、そもそもストレステストに値する前提がソース資料に入っているときに最も効果的です。

pre-mortem skill の改善方法

入力をもっと具体的にする

品質を最も大きく上げるのは、分析を頼む前に具体情報を足すことです。ローンチ日、対象顧客、成功指標、配信計画、依存関係、既知の弱点を含めてください。pre-mortem skill は、具体的なリリース経路と比べながらリスクを評価できるときに、格段に役立ちます。

アイデアだけで終わらせず、分類まで依頼する

「何が起きるか」だけで止めないでください。Tigers と Paper Tigers を分け、Elephants を明示的に指摘するよう依頼しましょう。この構造があると、曖昧な出力が減り、計画、体制、エスカレーション判断に使いやすくなります。

制約条件とトレードオフを含める

予算上限、エンジニアリングの制約、法務レビュー、絶対に動かせないローンチ日があるなら、最初に伝えてください。制約によって、本当に重要なリスクは変わります。これらを無視した pre-mortem は、もっともらしく見えても計画改善にはつながりません。

1回目の結果をもとに反復する

最初の出力を使って、次のプロンプトを絞り込んでください。モデルが起こりそうな失敗モードを外したなら、そのギャップを示したうえで、adoption、implementation、launch operations など特定領域に絞った 2 回目の pre-mortem を依頼します。pre-mortem の使い方として最も良いのは、広く当ててから、狭く深掘りし、最後に実行可能な形にする反復運用です。