mcpField
P
postmortem

postmortem

github.com/alirezarezvani生産性29.0k1.5k 回インストール今日更新
リポジトリ

postmortem について

postmortemは、失敗を個人の責任に帰さず、原因を分析するスキルです。事象の特定から根本原因の分析、担当者付きの変更策、効果検証までを導きます。

主な機能

  1. 01事象の明確な定義
  2. 025 Whysによる根本原因分析
  3. 03根本原因と要因の区別
  4. 04見過ごされた兆候の確認
  5. 05制御可能性の切り分け
  6. 06担当者・期限・検証日の設定

活用シーン

  1. 01売上目標未達の振り返り
  2. 02製品リリース失敗の分析
  3. 03採用ミスマッチの調査
  4. 04改善策の効果検証

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/alirezarezvani/claude-skills --skill postmortem

インストール後、Claude Code で/postmortemを入力して読み込まれたか確認します。

詳細

/em:postmortem — 何がうまくいかなかったのかを率直に分析する

コマンド： /em:postmortem <event>

責任追及ではなく、理解するためのものです。失敗した商談、達成できなかった四半期目標、うまくいかなかった機能、期待どおりにいかなかった採用。実際に何が起きたのか、なぜ起きたのか、その結果として何を変えるのかを明らかにします。

ほとんどの事後検証が失敗する理由

事後検証は、次のどちらかになってしまいます。

責任追及の場 — 誰かがスケープゴートにされ、防御的な姿勢が強まり、実際の原因は調べられず、同じ問題が別の形で再発します。

隠蔽 — 「多くを学びました。今後は改善し、曖昧なアクションアイテムを12個挙げます」。何も変わりません。同じ問題が、別の四半期に起きるだけです。

本当の事後検証は、そのどちらでもありません。システムの失敗を厳密に調査するものです。「誰のせいか」ではなく、「振り返ってみると、この結果が予測できたのはどのような条件がそろっていたからか」を問います。

目的： 失敗から最大限の学びを引き出し、再発を防いでシステムを改善することです。

フレームワーク

ステップ 1：事象を正確に定義する

分析の前に、何が起きたのかを正確に説明します。

  • 期待していた結果は何ですか？
  • 実際の結果は何でしたか？
  • 期待と実際の差が初めて明らかになったのはいつですか？
  • どのような影響がありましたか（金銭面、業務面、評判面）？

正確さが重要です。「第3四半期の売上目標を達成できなかった」では十分に正確とは言えません。「新規 ARR は目標の 680K ドルに対して 420K ドルにとどまり、260K ドル未達となった。主な要因は、3件の商談が第4四半期にずれ込み、1件が競合に負けたことだった」であれば正確です。

ステップ 2：5つのなぜを適切に行う

目標は、何が起きたのか（症状）から、なぜ起きたのか（根本原因）にたどり着くことです。

よくある悪い「5つのなぜ」：

  • なぜ売上目標を達成できなかったのですか？ 商談がずれ込んだからです。
  • なぜ商談がずれ込んだのですか？ 営業サイクルが予想より長かったからです。
  • なぜですか？ 顧客の購買プロセスが複雑だからです。
  • なぜですか？ エンタープライズ企業に販売しているからです。
  • なぜですか？ エンタープライズ営業とはそういうものだからです。

→ 結論：対策はありません。エンタープライズ企業とはそういうものです。

本当の「5つのなぜ」：

  • なぜ売上目標を達成できなかったのですか？ 3件の商談が四半期内に成立しなかったからです。
  • なぜその商談がずれ込んだのですか？ 予算決定権を持つ社内推進者を特定できていなかったからです。
  • なぜ社内推進者がいないまま商談を進めたのですか？ 案件の選定基準で、その特定を必須にしていなかったからです。
  • なぜ案件の選定基準で必須にしていなかったのですか？ 8か月前に基準を作ったときは、エンタープライズではなく SMB を対象としていたからです。
  • ICP が変化したのに、なぜ案件の選定基準を更新しなかったのですか？ 担当者がおらず、基準を見直すプロセスもなかったからです。

→ 根本原因：案件の選定基準が古く、担当者も見直しプロセスもありませんでした。
→ 対策：基準を更新し、担当者を割り当て、四半期ごとの見直しを加えます。

根本原因を正しく特定できたかの判断基準： 具体的で明確な変更によって、再発を防げますか？ 防げるなら、実質的な原因を見つけています。

ステップ 3：寄与要因と根本原因を区別する

ほとんどの事象には、複数の寄与要因があります。ただし、すべてが根本原因とは限りません。

寄与要因： 事態を悪化させたものの、中心的な理由ではありません。取り除けば結果が変わった可能性はありますが、同じ種類の問題は再発するでしょう。

根本原因： その結果が起きる可能性を高めた根本的な条件です。これを解決すれば、同じ種類の問題は再発しません。

採用の失敗の例：

  • 寄与要因：採用プロセスを急いだ、リファレンスチェックを省略した、チームが人員増強を急いでいた
  • 根本原因：能力要件のフレームワークが定義されていなかったため、面接プロセスが面接担当者によって異なっていた

この区別は重要です。 寄与要因だけに対処すると、次回は見た目が異なるだけで、構造的には同じ失敗が起きます。

ステップ 4：見過ごされた警告サインを特定する

あらゆる失敗には前兆があります。振り返れば、それは明らかです。このステップの価値は、事前にも明らかにすることにあります。

次の点を確認します。

  • どの時点で、望ましくない結果を予測できましたか？
  • その時点で、どのような兆候が見えていましたか？
  • 誰がそれに気づきましたか？ その人が指摘したとき、何が起きましたか？
  • なぜ対処されなかったのですか？

よくあるパターン：

  • 兆候は指摘されたが、上位の立場にある人に退けられた
  • 誰も安心して発言できず、兆候が指摘されなかった
  • 兆候は認識されていたが、対処する明確な責任者がいなかった
  • データはあったが、誰も確認していなかった
  • チームが楽観的すぎて、否定的な兆候を真剣に受け止めなかった

このステップは、組織的な問題において特に重要です。「懸念を安心して伝えられなかった」は、「案件の見極めが不適切だった」よりも根深い根本原因です。

ステップ 5：制御できることと、制御できないことを区別する

正しい判断をしていても起きる失敗があります。誤った判断が原因で起きる失敗もあります。この違いを理解することで、過剰な修正も修正不足も防げます。

  • 制御できること： プロセス、基準、チームの能力、リソース配分、下した判断
  • 制御できないこと： 市場環境、顧客の判断、競合他社の動き、マクロな出来事

制御できないことについては、同様の出来事に対するレジリエンスを高めるために何ができるでしょうか？ 制御できることについては、具体的に何を変える必要があるでしょうか？

警告： 「自分たちには制御できないことでした」は、責任を回避するために使われることがあります。厳密に検討してください。

ステップ 6：変更登録簿を作成する

あらゆるポストモーテムは、担当者と期限を明確にした具体的な約束をまとめる変更登録簿で締めくくります。

悪いアクションアイテム：

  • 「案件の見極めプロセスを改善します」
  • 「コミュニケーションを改善します」
  • 「予測をもっと厳密に行います」

良いアクションアイテム：

  • 「Ravi は 3 月 15 日までに、チャンピオンの特定を必須要件として含めるよう案件の見極め基準を書き直します。新しい基準は 3 月 22 日から毎週の営業スタンドアップで確認します。」
  • 「Elena は 3 月 10 日までに、製品デモがなく 60 日を超えている未完了の商談に対し、CRM に案件遅延リスクのフラグを追加します。」
  • 「Maria は 4 月 1 日から 6 週間ごとに、エンタープライズ営業チームと 30 分の振り返りを実施し、勝敗データを確認します。」

各アクションについて：

  • 具体的に何を変えますか？
  • 誰が担当しますか？
  • いつまでに行いますか？
  • 効果があったことをどう確認しますか？
ステップ 7：検証日

最もよく省略されるステップです。変更が実際に行われ、実際に効果があったかどうかを誰も確認しないのであれば、ポストモーテムは役に立ちません。

検証日を設定します。「6 月の取締役会で、案件の見極め基準が更新されたか、また案件遅延率が改善したかを確認します。」

これがなければ、ポストモーテムは形だけのものです。

ポストモーテムの出力形式

EVENT: [Name and date]
EXPECTED: [What was supposed to happen]
ACTUAL: [What happened]
IMPACT: [Quantified]

TIMELINE
[Date]: [What happened or was visible]
[Date]: ...

5 WHYS
1. [Why did X happen?] → Because [Y]
2. [Why did Y happen?] → Because [Z]
3. [Why did Z happen?] → Because [A]
4. [Why did A happen?] → Because [B]
5. [Why did B happen?] → Because [ROOT CAUSE]

ROOT CAUSE: [One clear sentence]

CONTRIBUTING FACTORS
• [Factor] — how it contributed
• [Factor] — how it contributed

WARNING SIGNS MISSED
• [Signal visible at what date] — why it wasn't acted on

WHAT WAS IN CONTROL: [List]
WHAT WASN'T: [List]

CHANGE REGISTER
| Action | Owner | Due Date | Verification |
|--------|-------|----------|-------------|
| [Specific change] | [Name] | [Date] | [How to verify] |

VERIFICATION DATE: [Date of check-in]

優れたポストモーテムのトーン

非難するのは簡単です。理解するのは困難です。

目標は、誰かが間違いを犯したと立証することではありません。システムがなぜその結果を生み出したのかを理解し、システムを改善することです。

「営業担当者が案件を適切に見極めなかった」は非難です。 「上位市場へ移行したときに案件の見極めフレームワークが更新されておらず、最新の状態に保つ責任者もいなかった」は理解です。

最初の言い方では、誰かを解雇したり、恥をかかせたりします。2 つ目の言い方では、よりレジリエンスの高い組織を築けます。

両方が同時に真実である可能性もあります。違いは、どちらが再発を実際に防ぐかです。

コメント

Markdown 対応