postmortem

postmortem skillの概要

postmortem skillでできること

postmortem skillは、ローンチ失敗、目標未達、採用ミス、失注、オペレーション上の不具合などを、責任追及ではない根本原因分析へ落とし込むための、経営メンター型ワークフローです。エージェントに対して、出来事の定義を明確にし、5 Whysを規律立てて問い、変更管理用のレジスターを作るよう促します。そのため、出力は単なる「学び」ではなく、具体的なシステム変更の一覧になります。

リーダーシップとQuality Managementに向いているケース

このpostmortem skillは、計画と実際の結果がなぜずれたのかを理解したい創業者、経営陣、オペレーター、プロダクトリーダー、エンジニアリングマネージャー、Quality Managementチームに特に有用です。目的が処罰ではなく、再発防止とプロセス改善である場面に適しています。Quality Management用途でpostmortemを使う場合、失敗をコントロール、担当者、測定可能なフォローアップアクションへ変換できる点が大きな価値です。

汎用プロンプトとの違い

「何が悪かったのか分析して」といった汎用プロンプトでは、広く浅いコメントになりがちです。このskillはより絞り込まれており、実務向きです。明確に定義された出来事を起点にし、症状と原因を分け、スケープゴート化を避け、どのような条件が失敗を起こりやすくしたのかを問います。中核となる差別化要素はchange registerで、洞察を担当者、期限、システムレベルの修正へ変換しやすくします。

導入前に知っておきたい注意点

リポジトリパスには単一のSKILL.mdのみがあり、補助スクリプト、参照資料、メタデータファイルはありません。そのためpostmortemのインストールは軽量ですが、同時に、出力品質は提供するコンテキストの質に大きく依存します。十分な事実関係を共有でき、本格的な振り返りに耐える状況で使うのが適しています。一方で、出来事がまだ政治的に扱いづらい、法的にセンシティブである、または噂だけに基づいている場合は避けるべきです。

postmortem skillの使い方

postmortemのインストールと確認すべきファイル

GitHubのskillソースから、次のコマンドでインストールします。

npx skills add alirezarezvani/claude-skills --skill postmortem

ソースは次の場所にあります。

c-level-advisor/executive-mentor/skills/postmortem/SKILL.md

まずSKILL.mdを読んでください。完全な運用モデルがここに記載されています。照合すべき追加のrules/、resources/、references/、scripts/フォルダはありません。そのため、主な導入判断は、この単一ファイルのワークフローが自社の振り返りスタイルに合うかどうかです。

実務でのskillの呼び出し方

このskillは、次のコマンドパターンを前提に設計されています。

/em:postmortem <event>

弱い呼び出し例は次のようなものです。

/em:postmortem Q3 release slipped

より良い呼び出しでは、エージェントが事実、仮説、原因を切り分けられるだけの材料を渡します。

/em:postmortem The Q3 enterprise release shipped six weeks late. Expected: public launch by Sep 15 with SOC2-ready audit logging. Actual: launch moved to Oct 27, two pilot customers delayed contracts, and support handled 43 escalation tickets. Timeline: scope expanded Aug 8, QA found permission bugs Sep 3, final security review failed Sep 12. Please run a blameless 5-Whys analysis and produce a change register with owners, preventive controls, and follow-up metrics.

postmortemの精度を高める入力情報

postmortemを最も効果的に使うには、期待していた結果、実際の結果、時系列、最初の警告サイン、影響、主要な意思決定、制約、その時点で分かっていたことを提供します。定量的な証拠と人間的な文脈の両方を含めてください。たとえば、売上ギャップ、不具合件数、採用タイムライン、未達のマイルストーン、顧客影響、意思決定者、承認のボトルネック、競合する優先事項などです。

「誰がこれを引き起こしたのかを見つけて」と依頼するのは避けましょう。代わりに、システム上の条件を特定するよう依頼してください。たとえば、オーナーシップの不明確さ、弱いエスカレーション経路、非現実的な計画前提、品質ゲートの欠落、インセンティブの衝突、リスクの可視化の遅れなどです。

有用な出力を得るための進め方

まず事実ベースのイベント概要を渡し、最初のpostmortemドラフトを依頼します。次に、5 Whysの連鎖が早すぎる段階で止まっていないか、都合のよい説明へ飛びついていないかを確認します。そのうえで、証拠を使って反復します。たとえば、「時系列に照らして根本原因を検証して」「コントロール可能な原因と外部ショックを分けて」「これらの学びを次回の経営レビューに使えるchange registerへ変換して」といった依頼です。

最終成果物として望ましいのは、通常、出来事の定義、影響の要約、寄与要因、根本原因、原因ではなかったもの、当時は合理的に見えた意思決定、推奨されるシステム変更、担当者、期限、検証指標を含むものです。

postmortem skill FAQ

postmortemは初心者にも向いていますか？

はい。ユーザーが明確な出来事の説明を提供できるなら向いています。このskillの構造により、正式な振り返り手法を事前に知っている必要性は下がります。初心者は、呼び出す前に短い時系列と期待結果との差分を準備しておくとよいでしょう。そうしないと、モデルが不足している文脈を、もっともらしいが未検証の仮定で補ってしまう可能性があります。

このskillを使うべきではないのはどんな場合ですか？

人によるレビューなしに、人事評価、懲戒ツール、法的調査、公開インシデント声明として使うべきではありません。また、リーダー層が不都合な因果分析ではなく、整ったストーリーだけを求めている場合にも適していません。組織が発見事項に基づいて行動できない場合、postmortemは改善ではなく不満を生む可能性があります。

インシデントレビューとは何が違いますか？

インシデントレビューは、多くの場合、技術的なサービス障害と運用復旧に焦点を当てます。このpostmortem skillはより広く、四半期目標の未達、ローンチ失敗、採用ミス、失注、プロダクトの不振、リーダーシップ上の意思決定まで対象に含みます。Quality Managementを支援することはできますが、資格あるレビュー担当者が適切に調整しない限り、規制対象のCAPA、監査、コンプライアンス文書の代替にはなりません。

特定のエコシステムが必要ですか？

いいえ。このskillはプレーンなmarkdownであり、上記のコマンドを使って互換性のあるskillsワークフローにインストールできます。スクリプトや外部アセットがないため、ビジネス、プロダクト、エンジニアリング、オペレーションの各文脈に持ち込みやすい構成です。一方で、ダッシュボード、チケットシステム、インシデントログを自動で取り込むわけではありません。関連する証拠は、自分で要約するか貼り付ける必要があります。

postmortem skillを改善する方法

postmortemに質の高い一次情報を渡す

postmortemの結果を最も早く改善する方法は、コンパクトな証拠パックを用意することです。含めるべきものは、目標、実際の結果、時系列、意思決定ポイント、見逃したシグナル、制約、ステークホルダー、影響、既存の仮説です。不確かな主張には明確にラベルを付けてください。例: “Confirmed: QA blocked release on Sep 12. Hypothesis: sales pressure caused scope expansion. Unknown: whether engineering estimated the new scope.”

よくある失敗パターンに注意する

最もよくある失敗は、「コミュニケーション不足」や「オーナーシップの欠如」のような浅い根本原因で止まってしまうことです。エージェントにもう一段深掘りさせましょう。どのような構造がコミュニケーション不全を生んだのか。なぜオーナーシップが曖昧だったのか。なぜ計画プロセスがその曖昧さを許したのか。もう一つの失敗パターンは、対策を増やしすぎて過剰修正することです。担当者が明確で、観測可能で、再発防止につながる可能性が高い、少数の変更に絞るよう促してください。

発見事項をchange registerに変換する

強いchange registerには、変更内容、その変更が対処する根本原因、担当者、期限、成功指標、レビュー頻度を明記するべきです。Quality Management用途では、コントロール種別、検証方法、必要な証拠も追加します。これにより、skillの出力を、経営レビュー、四半期計画、リリースガバナンス、採用プロセス変更、継続的改善プログラムで運用しやすくなります。

最初の回答後に反復する

最初のドラフトを受け取ったら、狙いを絞って追加質問します。たとえば、「どの結論が証拠に基づいていて、どれが推論か？」「チームを不必要に遅くせずに、これを防ぐには何が必要だったか？」「どの早期警告指標を追加すべきか？」「経営責任が明確になるようにchange registerを書き直して」といった依頼です。postmortem skillは、一回限りのレポート生成ツールではなく、構造化された調査パートナーとして扱うと最も効果を発揮します。