Blameless postmortem の運用詳細 ─ trigger を書く勇気、評価との分離、action item 追跡

• 想定読者： インシデント対応・運用責任者、postmortem を制度化したい SRE・EM、儀式化を打破したい経営層
• 前提知識： 「組織のコンテキスト供給能力を整える実装ガイド」STEP 1-A の概要
• 所要時間： 通読 約18分／要点把握 約6分

概要

Blameless postmortem は2012年の John Allspaw / Etsy¹ による提唱、Google SRE² による標準化を経て、業界共通言語になった。だが現実には「次から気をつけます」が並ぶ儀式化、postmortem を人事評価の証拠に使われる失敗、action item の半分以上が放置される——多くの組織で形骸化している。

本記事は、テンプレート提示で終わらず、実装で躓きやすい4論点——trigger を書く勇気、評価制度との分離、action item 追跡、公開範囲の段階拡大——を扱う。Allspaw / Google SRE の原典と、Sidney Dekker の human factors 研究、James Reason の Swiss Cheese Model を踏まえた運用詳細だ。

Postmortem テンプレート（推奨アジェンダ）

# Postmortem: <インシデント名>

## Status
- Owner / Reviewers / Status (draft / review / done)

## Summary
- インシデントの一行サマリー
- 検出時刻・解決時刻・継続時間

## Impact
- 影響を受けたユーザー数 / 売上 / SLO 違反
- 内部コスト（対応工数、機会損失）

## Timeline (UTC / JST)
- 事実のみ。「思った」「感じた」は別欄
- 各イベントに「誰が」「何を観測して」「何をしたか」

## Detection
- 何が異常を最初に検知したか（アラート / ユーザー通報 / 偶然）
- 検知から認識までのラグ

## Response
- 誰がオンコールで、どう動いたか
- 一次対応の選択肢と、選んだ理由

## Contributing factors（寄与要因）
- プロセス：レビュー / デプロイ / 承認の弱点
- 組織：情報共有 / 役割定義の弱点
- 技術：依存関係 / 監視 / フォールバックの弱点
- 環境：外部要因 / 想定外の負荷

## What went well
- うまく機能した検知 / 連携 / 復旧手順

## Lessons learned
- 個人への帰責なし。「もっと注意して」は禁則
- 構造的な学びだけ書く

## Action items
| ID | Action | Owner | Due | Type | Status |
|----|--------|-------|-----|------|--------|
| 1  | xxx    | @yyy  | MM/DD | prevent / mitigate / detect | open |

## Trigger（オプション）
- このインシデントを引き起こした直接トリガー

論点 1：trigger を書く勇気

「Trigger」欄を書くか書かないかで postmortem の質が決まる。書かないと再発防止策が抽象化し、書くと個人攻撃のリスクが生じる。

なぜ trigger が必要か

抽象的な再発防止策（「レビューを強化する」「監視を改善する」）だけでは、同じ条件で同じ人が同じことをしないシステム を設計できない。具体的なトリガー（誰が・どんな状況で・何を引き金に）が分からないと、防御層（Reason の Swiss Cheese Model³）の穴を特定できない。

個人攻撃にしないための運用

trigger を書く目的が「責めるため」ではなく「同じ条件で同じことをしないシステムを作るため」だと全員が信じられる状態を維持する。具体的には：

• trigger の文章主語を「人」ではなく「プロセス・状況」にする：「○○さんがミス」ではなく「△△の手順で確認ステップが省略可能だった」
• trigger を書く前に Lessons learned で「人ではなく構造を見る」と全員で再確認する
• 公開範囲を初期は限定（次節）して心理的安全を確保する
• Sidney Dekker の “second story” の考え方⁴：表面的な「ヒューマンエラー」の下にある構造的要因を必ず探す

Allspaw の原則：知識を引き出す

Allspaw の Etsy 記事¹ の核心：「ミスをした人を罰すると、次に同じミスがあったとき隠蔽される。罰しないと、知識が組織に残る」。Postmortem は知識抽出のプロセスであり、評価判定の場ではない。

論点 2：評価制度との分離

Postmortem 文書を 「ミスした証拠」として人事評価に使う と、即座に隠蔽インセンティブが復活する。これは形骸化の最大要因だ。

明示的なルール

• postmortem 文書は 人事評価のインプットに使わない と明文化する
• 評価対象は postmortem の内容ではなく「postmortem に協力的に参加し、構造的学びを提示したか」のような プロセス参加 に限定
• 経営層・上位マネージャーが postmortem を「読む」が「評価判断には使わない」を体現する
• 例外：法的・規制要件で評価に使う必要がある場合は、その範囲を事前に明示

Just Culture の系譜

これは Sidney Dekker の “Just Culture”⁴ の系譜にある考え方だ。航空業界・医療業界で長く議論されてきた：

• 100% blame-free（無責任体制）にも、100% blame-full（責任追及）にもしない
• ガイドラインに従った行動は罰しない
• 意図的な違反・重大過失とそうでないものを構造的に区別する

組織が Just Culture を体現できているかを測る一つの指標：postmortem の数が増えているか減っているか。健全な組織ほど postmortem が増える（隠蔽が減る）。

論点 3：Action item 追跡

「Action item を出して終わり」が多くの組織の現実だ。完了率を追わない postmortem は儀式化の入口。

Type ラベルで戦略性を持たせる

Action item を3つの type に分類：

• prevent：原因そのものを取り除く（再発させない）
• mitigate：起きたときの影響を小さくする
• detect：起きたとき早く気づく

3つのバランスが偏っていないかを postmortem ごとに見る。すべて prevent だけだと現実的に実装困難で形骸化する。すべて detect だけだと根本原因が放置される。

完了率の月次トラッキング

• Action item の30日完了率・60日完了率・90日完了率を月次で可視化
• 半分以上が放置される組織では、postmortem 自体が儀式化していく
• 放置の理由が「優先順位低下」なら明示的に close（理由付き）。「忘れていた」なら追跡プロセスの問題

経営層レビュー

四半期に1度、経営層が action item の完了率と未完了の理由を見る会議を持つ。これがないと action item は ROI を生まない。

論点 4：公開範囲の段階拡大

「全社公開が透明性」は単純化しすぎ。最初から全社公開すると萎縮し、postmortem の数が減る（隠蔽方向）。

推奨の段階拡大

Phase 1: チーム内のみ（最初の3〜6ヶ月）
   ↓ 心理的安全が確保される
Phase 2: 関係部門に展開
   ↓ blameless culture が定着
Phase 3: 全社公開（要約版）
   ↓ 業界共有
Phase 4: 業界外部公開（Etsy / GitHub / Cloudflare 流）

各 Phase に進む条件は時間経過ではなく「前 Phase で blameless が機能している」だ。早すぎる全社公開は逆効果になる。

例外：規制産業

金融・医療・政府関連など、規制要件で外部開示が必要な産業では、内部限定文書と外部開示用要約を 最初から分離設計 する。詳細は姉妹記事「discovery risk vs 知識蓄積」を参照。

アンチパターン

パターン	何が起きるか	対処
「次から気をつけます」が並ぶ	構造的学びゼロ	Action item に prevent/mitigate/detect ラベル必須化
trigger を書かない	再発防止策が抽象化	trigger を「プロセス・状況」主語で書く規律
postmortem 文書を評価に使う	隠蔽復活	評価との分離を明文化
Action item 放置	学習が成果に繋がらない	30日完了率を月次可視化
最初から全社公開	萎縮で postmortem 数減少	段階的拡大
経営層が postmortem を読まない	構造改善が経営判断に繋がらない	四半期経営レビュー
インシデント数を KPI 化	隠蔽インセンティブ	postmortem 数（透明性）を見る、インシデント数は内部参照のみ

まとめ

• Allspaw / Google SRE の blameless postmortem は2010年代以降の業界標準だが、形骸化が頻発する
• trigger を書く勇気：「責めるため」ではなく「同じ条件で同じことをしないシステムを作るため」
• 評価制度との分離：postmortem を「ミスの証拠」に使わない明文化
• Action item 追跡：prevent/mitigate/detect の type ラベル、月次完了率、四半期経営レビュー
• 公開範囲の段階拡大：チーム → 関係部門 → 全社 → 業界
• インシデント数 KPI 化は隠蔽インセンティブを生む（Goodhart 暴走）
• 健全な組織ほど postmortem が増える（隠蔽が減る）

関連記事

• 組織のコンテキスト供給能力を整える実装ガイド ─ 直視から、修復へ - 本記事の親記事
• ペアネガティブの設計 ─ 単独ネガティブと何が違い、なぜ組織を動かすか - postmortem 文化の上位概念
• Goodhart の法則 ─ 文書化を KPI 化した瞬間に空洞化する - インシデント数 KPI 化の暴走
• discovery risk vs 知識蓄積 ─ 法務が文書化を止める産業での解法 - 規制産業での postmortem 公開設計

参考資料

1. Blameless PostMortems and a Just Culture - John Allspaw, Etsy Code as Craft (2012-05). 業界標準的提唱。【信頼性: 高】 ↩︎ ↩︎²

2. Postmortem Culture: Learning from Failure - Beyer, Jones, Petoff, Murphy (eds.), Site Reliability Engineering, O’Reilly / Google (2016). 【信頼性: 高】 ↩︎

3. Human Error - James Reason, Cambridge University Press (1990). ISBN: 9780521314190。Swiss Cheese Model の原典。【信頼性: 高】 ↩︎

4. The Field Guide to Understanding ‘Human Error’ - Sidney Dekker, Ashgate (3rd ed. 2014). ISBN: 9781472439055。Just Culture の系譜。【信頼性: 高】 ↩︎ ↩︎²