====== ポストモーテム ======

===== ポストモーテム（Post-mortem）の概要 =====

　ポストモーテムは、重大なインシデントやプロジェクトの終了後に行われる**振り返りの記録**です。

　その目的は、誰かを責めることではなく、「システムやプロセスのどこに弱点があったのか」を特定し、学習することにあります。



===== 1. ポストモーテムの主要構成要素 =====

　効果的なポストモーテム報告書には、通常以下のセクションが含まれます。

  * **インシデント概要 (Incident Summary):** 
    * 何が起きたのか、どの程度の深刻度だったのかを簡潔にまとめます。

  * **影響範囲 (Impact):** 
    * ユーザー数、サービス停止時間、損失したデータなど、具体的な影響を記載します。

  * **タイムライン (Timeline):** 
    * 発生から検知、対応、解決までの出来事を時系列で記録します。

  * **根本原因 (Root Cause):** 
    * 「なぜ」を繰り返す（5 Whys）などの手法を用い、表面的なミスではなく、その背後にあるシステム上の問題を特定します。

  * **アクションアイテム (Action Items):** 
    * 再発を防止するための具体的で期限のあるタスクを定義します。

  * **教訓 (Lessons Learned):** 
    * うまくいった点、改善が必要な点を抽出します。

===== 2. 「非難なし（Blameless）」の文化 =====

　ポストモーテムにおいて最も重要なのは、**心理的安全性**を確保することです。

> 「インシデントは、個人が悪いのではなく、個人がミスを犯すことを許容してしまったシステムに問題がある」と捉えます。

  * **目的:** 
    * 失敗を隠さず報告できる文化を築き、組織全体の回復力（レジリエンス）を高めること。

  * **方法:** 
    * 質問を「誰が（Who）」ではなく「何が（What）」「どのように（How）」という視点に変えて分析します。



===== 3. ポストモーテムを実施するメリット =====

^ メリット ^ 内容 ^
| **信頼の回復** | ユーザーに対して透明性のある報告を行うことで、信頼関係を再構築できる。 |
| **レジリエンスの向上** | 同じ失敗を繰り返さないための具体的なガードレール（自動テスト、監視の強化など）が整備される。 |
| **ナレッジの共有** | 特定の担当者だけでなく、チーム全体で技術的な知見を共有できる。 |

===== 4. 実施のトリガー =====

　以下のような状況が発生した場合、ポストモーテムを作成することが推奨されます。

  - ユーザーに影響を与えるダウンタイムやサービスの劣化。
  - データの損失。
  - 監視システムの不備によるインシデント検知の遅れ。
  - 手動による緊急介入が必要だったケース。


===== "ポストモーテム" Related Articles =====

{{topic>ポストモーテム }}


===== "事件" Related Articles =====

{{topic>事件 }}


{{tag>ポストモーテム セキュリティ }}