postmortem-document

name	postmortem-document
description	作成手順「postmortem-document」（self-evolving-agent から自動同期）: ポストモーテム文書作成手順

ポストモーテム文書作成手順

用途: 本番障害・インシデントのポストモーテムを workspace/postmortem.md（または指定先）に作成するとき。

1. メタデータ冒頭セクション

以下の項目を最初の表にまとめる。実データがない場合は [ラベル付き角括弧] プレースホルダーを使い、Result 冒頭に「埋める項目リスト」を置く。

項目	値
インシデントID	[INC-XXXX]
重大度	[Sev-X]
発生日時	[YYYY-MM-DD HH:MM JST]
復旧日時	[YYYY-MM-DD HH:MM JST]
影響時間	[X 時間 Y 分]
作成者	[氏名]
レビュー者	[氏名]
レビュー実施日	[YYYY-MM-DD]

2. blameless 宣言を冒頭と末尾の両方に配置

• 冒頭: 「このポストモーテムはシステムと組織的要因を改善するためのものであり、個人を責めることを目的としない。関わった全員が当時入手可能な情報の中で最善を尽くした。」（または同趣旨の文言）
• 末尾: 同趣旨の一文で締める。チームレビュー時の心理的安全性を確保するため、どちらも省略しない。

3. 時系列（タイムライン）

• HH:MM 形式のタイムスタンプ + 一行の事実記述（誰が何をしたか）
• 「検知 → 初動対応 → 原因特定 → 暫定対応 → 復旧確認」のフェーズが分かるように記述する。
• 実データがない場合は [HH:MM] プレースホルダーを使う。

4. 根本原因を 3 層で分解する

「外部 API のレート制限が変わったから」のような一行で終わらせない。

層	説明
直接原因	何が引き金になったか（例: 外部 API のレート制限値変更）
根本原因（設計）	なぜシステムがそれに耐えられなかったか（例: 指数バックオフ未実装）
寄与因子	検知や対応を遅らせた組織・プロセス上の問題（例: 監視アラート未整備）

5. 影響範囲

• ユーザー影響（件数・期間・機能範囲）
• 内部システム影響
• 推定ビジネス影響（KPI への影響があれば）

6. 暫定対応（初動）と恒久対策を分けて記述

• 暫定対応: 復旧のために実施した即時アクション
• 恒久対策: 優先度順（最優先 → 中 → 長期）に並べる。具体的な技術仕様（例: 初期待機 1 秒、倍率 2.0、最大 120 秒）があれば記述し、開発者がそのまま着手できる粒度にする。

7. 再発防止アクション表（担当 / 期日 / 状態）

#	アクション	担当	期日	状態
1	…	[担当者名]	[YYYY-MM-DD]	未着手

• 最低 4〜7 件を目安に列挙。「監視」「設計改善」「プロセス・コミュニケーション」「チームレビュー」の軸でカバーする。
• スプリント計画にそのまま転用できる粒度にする。

8. Lessons Learned / Open Questions セクション

• 学んだこと: 今後の設計レビューやチェックリストに転用できる教訓を箇条書き。
• 未解決の問い: 今回のポストモーテムで答えが出なかった問いを列挙し、次の議論の起点にする。

9. 文書の日付（lessons 原則 C に従う）

• 作成日 = 文書を今日作っているので今日の日付を入れる（プレースホルダーにしない）。
• インシデント発生日・復旧日・レビュー実施日 などイベント日付 = 素材・文脈から読み取れればその日付、不明なら [レビュー実施日: YYYY-MM-DD] 等のプレースホルダーを残す。