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

ファシリテーター	参加者	不具合チケット

ポストモーテムは、問題の責任追及よりも、組織としての学びと改善を重視する文化を醸成するための重要な機会です。
問題が起きた際の対応や判断を冷静に分析し、次に向けての改善策を見出すことが、組織の成長に繋がります。

障害の概要

• 概要
  • ざっくりとした障害の説明を記載
• 発生日時
  • 2025年1月1日 0:00
• 障害の発見方法
  • どのように障害が発見・通知されたか
• 通知のタイミング
  • リリース直後やユーザが利用した際などの通知契機

タイムライン

以下の工程を記載

• 障害発生から解決までの時系列
• 重要なイベントとそのタイミング
• 障害対応の際に行われたアクション

一因の特定・分析

• 事象が発生してしまった要因について記述する
• 具体的にソースコードのどこでというのを示しても良い
• ただしアプリケーションの実装内容を知らない人にも伝わる粒度で記載すること
• 一つの根本原因に固執するとその他の因果関係の特定を辞めてしまうため、一つの根本原因と分析に執着せずに、多くの観点から本件の一因となり得るものを特定していく

混入原因分析

• 実際にそのバグを作ってしまった原因
• 当事者がいればヒアリングすることでわかることが多いが、古いバグなどで当事者がいない場合は、当時の状況を整理して記述する必要がある

摘出すべき工程・摘出遅延理由

• 混入されたバグを本来であればどの工程で摘出されるべきだったか
• どのようにしてその工程をすり抜けたのか

水平展開

• 「混入原因分析」「摘出遅延理由」が当てはまる箇所が他にある場合、同様のバグが潜んでいないか確認する必要があるため、その範囲を記述する
• ただ、愚直にやろうとすると範囲が膨大になることが多いため、「同じコンポーネントに限る」や「同じ設計箇所に限る」など現実的に対応可能な範囲に落とし込む必要がある
• 慣れないうちは範囲の大きさについては気にせず記述し、上司等と相談して現実的なラインに落とし込む方針でも良い

対応策の評価

• 障害対応のプロセスとその有効性
• 迅速な解決のために行ったアクションの評価
• 反省点と改善点の特定

再発防止策

• 技術的な改善策（コード修正、インフラの改善など）
• プロセスの改善（モニタリング、アラートの設定、手順書の更新）
• チームのトレーニングやドキュメントの改善

ネクストアクション

• 今後のアクションアイテムと担当者の確認
• 改善策の実行計画とスケジュール

フィードバックとQ&A

• 参加者からのフィードバック
• 質疑応答とディスカッション