「本番環境で障害が発生した。原因を調べて報告書を書かなければならない」

ITエンジニアなら誰もが経験するこの状況。しかし、障害報告が「犯人探し」になっていないだろうか？

SRE（Site Reliability Engineering）の世界では、障害後の振り返りを「ポストモーテム（Postmortem）」と呼び、Blameless（非難のない）文化を重視する。本記事では、Googleをはじめとするテック企業が実践するポストモーテムの手法と、なぜなぜ分析との統合方法を解説する。

ポストモーテムとは

ポストモーテム（Postmortem）は、直訳すると「死後検査」を意味する医学用語である。IT業界では、システム障害やインシデント発生後に行う振り返り分析を指す。

ポストモーテムの目的

根本原因の特定：なぜ障害が発生したのかを明らかにする
再発防止：同じ問題を繰り返さないための対策を立てる
組織学習：障害から得た知見を組織全体で共有する
プロセス改善：検知・対応・復旧のプロセスを改善する

従来の障害報告との違い

観点	従来の障害報告	SREポストモーテム
目的	責任の所在を明確化	再発防止と組織学習
焦点	誰がミスをしたか	なぜシステムが防げなかったか
文化	責任追及（Blame）	非難のない（Blameless）
成果物	謝罪と再発防止策	アクションアイテムと学び
共有範囲	関係者のみ	組織全体（時に外部にも）

Blameless文化とは

Blameless（ブレームレス）文化とは、障害分析において個人を責めず、システムやプロセスの問題に焦点を当てるアプローチである。

なぜBlamelessが重要なのか

Googleの「Site Reliability Engineering」書籍では、Blameless文化の重要性を次のように説明している：

「人は間違いを犯す。しかし、間違いを報告することを恐れる文化では、問題は隠蔽され、学習の機会が失われる」

Blamelessの3原則

人ではなくシステムを責める
- 「担当者がミスをした」→「システムがミスを防げなかった」
- 「確認を怠った」→「確認プロセスが不十分だった」
心理的安全性を確保する
- 正直に報告しても罰せられない
- 失敗を共有することが推奨される
改善にフォーカスする
- 過去を責めるのではなく、未来を改善する
- すべてのインシデントは学習の機会

Blamelessの限界

Blamelessは万能ではない。以下のケースでは、個人の責任を問う必要がある場合もある：

意図的な悪意ある行為
繰り返される同じミス（教育や配置転換が必要）
セキュリティポリシーの意図的な無視

ポストモーテムの構成要素

効果的なポストモーテムには、以下の要素が含まれる。

1. インシデント概要

## インシデント概要

- **発生日時**: 2026年1月15日 14:30 JST
- **検知時刻**: 2026年1月15日 14:35 JST
- **復旧時刻**: 2026年1月15日 15:45 JST
- **影響時間**: 1時間15分
- **影響範囲**: 決済サービス全体（約10,000ユーザー）
- **重大度**: SEV1（重大）

2. タイムライン

時系列で何が起きたかを記録する。

## タイムライン

| 時刻 | イベント |
|------|----------|
| 14:30 | デプロイ完了 |
| 14:32 | エラーログ増加開始 |
| 14:35 | アラート発報、オンコール担当が対応開始 |
| 14:45 | 原因調査中、決済処理が停止していることを確認 |
| 15:00 | ロールバック決定 |
| 15:30 | ロールバック完了 |
| 15:45 | 正常稼働確認、インシデントクローズ |

3. 根本原因分析

なぜなぜ分析を活用して根本原因を特定する。

## 根本原因分析（5 Whys）

**問題**: 決済処理が1時間15分停止した

1. なぜ停止した？
   → 新しいデプロイでデータベース接続が失敗した

2. なぜDB接続が失敗した？
   → 接続文字列の設定が本番環境用ではなかった

3. なぜ本番用でなかった？
   → 環境変数の設定が開発環境のままだった

4. なぜ開発環境のままだった？
   → デプロイスクリプトで環境変数の検証がなかった

5. なぜ検証がなかった？
   → **デプロイパイプラインに環境変数チェックが組み込まれていなかった**

**根本原因**: デプロイパイプラインにおける環境設定の検証不足

4. 検知・対応の評価

何がうまくいったか、何が改善できるかを評価する。

## 検知・対応の評価

### うまくいったこと
- アラートが5分以内に発報された
- オンコール担当が迅速に対応を開始した
- ロールバック手順が明確で、実行時間が短かった

### 改善が必要なこと
- 原因特定に時間がかかった（15分）
- 影響範囲の確認に手間取った
- ステークホルダーへの連絡が遅れた

5. アクションアイテム

具体的な改善アクションを、担当者と期限付きで記載する。

## アクションアイテム

| # | アクション | 担当 | 期限 | 優先度 |
|---|-----------|------|------|--------|
| 1 | デプロイパイプラインに環境変数検証を追加 | 田中 | 1/22 | P0 |
| 2 | ステージング環境でのE2Eテスト強化 | 佐藤 | 1/29 | P1 |
| 3 | インシデント対応手順書の更新 | 鈴木 | 1/25 | P1 |
| 4 | 影響範囲確認のダッシュボード作成 | 高橋 | 2/5 | P2 |

6. 学びと教訓

組織として共有すべき学びを記録する。

## 学びと教訓

1. **デプロイ前の検証は自動化すべき**
   環境設定のミスは人間のチェックでは防げない

2. **ロールバック手順の明確化が迅速な復旧につながった**
   定期的な訓練が効果を発揮した

3. **アラートの閾値が適切だった**
   エラー率1%で発報する設定が早期検知に貢献

なぜなぜ分析とポストモーテムの統合

SREポストモーテムの核心部分は、なぜなぜ分析そのものである。ただし、IT特有の観点を加える必要がある。

ITシステムにおける5つの視点

なぜなぜ分析を行う際、以下の5つの視点で深掘りする：

コード/設計
- バグはなぜ混入したか
- 設計上の考慮漏れはなかったか
テスト/検証
- なぜテストで検出できなかったか
- テストカバレッジは十分だったか
デプロイ/リリース
- デプロイプロセスに問題はなかったか
- 段階的ロールアウトはできていたか
監視/検知
- なぜ早期に検知できなかったか
- アラート設定は適切だったか
対応/復旧
- 対応手順は明確だったか
- エスカレーションは適切だったか

分岐する原因への対応

ITシステムの障害は、複数の原因が絡み合っていることが多い。

障害発生
    │
    ├─ なぜコードにバグがあった？
    │       └─ レビューで見落とした → レビュー観点の追加
    │
    ├─ なぜテストで検出できなかった？
    │       └─ 該当パスのテストがなかった → テスト追加
    │
    └─ なぜ本番で検知が遅れた？
            └─ アラート閾値が高すぎた → 閾値調整

このように、複数の原因経路を並行して分析し、それぞれに対策を講じることが重要である。

ポストモーテム実施のベストプラクティス

1. 48時間以内に開催

記憶が新しいうちに振り返りを行う。時間が経つと詳細が失われる。

2. 関係者全員を招集

インシデント対応者
関連システムの担当者
マネージャー（オブザーバーとして）
必要に応じてステークホルダー

3. ファシリテーターを設ける

中立的な立場で議論を進行する役割。Blameless文化を維持する上で重要。

4. ドキュメントを公開する

社内Wiki等で広く共有
他チームの学習材料にする
一部企業は外部にも公開（Google、Atlassian等）

5. アクションアイテムを追跡する

担当者と期限を明確に
定期的に進捗を確認
完了しなければ同じ障害が再発する

ポストモーテムテンプレート

以下は、すぐに使えるポストモーテムテンプレートである。

# ポストモーテム: [インシデント名]

## 概要
- **発生日時**:
- **検知時刻**:
- **復旧時刻**:
- **影響時間**:
- **影響範囲**:
- **重大度**: SEV1 / SEV2 / SEV3

## サマリー
[1-2文でインシデントを要約]

## タイムライン
| 時刻 | イベント |
|------|----------|
| | |

## 根本原因分析
### 5 Whys
1. なぜ？ →
2. なぜ？ →
3. なぜ？ →
4. なぜ？ →
5. なぜ？ →

### 根本原因
[特定された根本原因を記載]

## 検知・対応の評価
### うまくいったこと
-

### 改善が必要なこと
-

## アクションアイテム
| # | アクション | 担当 | 期限 | 優先度 |
|---|-----------|------|------|--------|
| 1 | | | | |

## 学びと教訓
1.
2.

## 参加者
- ファシリテーター:
- 参加者:

AIを活用した効率化

ポストモーテムの根本原因分析には、なぜなぜ分析が不可欠である。しかし、以下の課題がある：

複数の原因経路の管理が複雑
ファシリテーターのスキルに依存
時間がかかる（特に複雑な障害）

こうした課題を解決するのが、AI支援ツールである。

📱 WhyTrace Connect - AIなぜなぜ分析ツール

業種と問題を入力するだけで、AIが自動的になぜなぜ分析ツリーを生成。IT業界にも対応した専門フレームワークで、SREポストモーテムの根本原因分析を効率化する。

IT/ソフトウェア業界対応フレームワーク
複数原因の分岐を自動管理
対策案の自動生成機能

👉 無料でAI自動分析を試す

まとめ

SREポストモーテムは、障害を「失敗」ではなく「学習の機会」として捉える文化的なアプローチである。

Blameless文化の3原則

人ではなくシステムを責める
心理的安全性を確保する
改善にフォーカスする

効果的なポストモーテムの構成

インシデント概要
タイムライン
根本原因分析（なぜなぜ分析）
検知・対応の評価
アクションアイテム
学びと教訓

障害は起きる。重要なのは、そこから何を学び、どう改善するかである。Blameless文化とポストモーテムを通じて、より信頼性の高いシステムを構築しよう。

SREポストモーテム実践ガイド - Blameless文化で障害を学びに変える