LASSIC Media らしくメディア
ポストモーテム文化を外注支援で定着させる進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- ポストモーテムとは、障害後にタイムラインと根本原因、是正アクションを記録し再発防止につなげる振り返りの仕組みです。
- ブレームレスの前提を欠くと担当者が問題を報告しなくなり、組織の学習が止まるリスクがあります。
- 外部ファシリテーションを活用する場合は、委託範囲の切り分けとアクションアイテムの追跡体制が定着を左右します。
目次
ポストモーテムとは — 障害を記録し学習に変える振り返り
ポストモーテムとは、インシデントの影響・対応内容・根本原因・再発防止のための後続アクションを記録した文書を指します*1。Google SREの解説では、ポストモーテムの目的は「インシデントが文書化され、すべての根本原因が十分に理解され、特に効果的な予防措置が講じられること」にあるとされています*1。障害対応そのものを終えた後に、その経緯を振り返り学習として組織に残す活動です。
ポストモーテムを書く対象は、障害が起きたら何でも作成するわけではありません。Google SREの解説は、ユーザーに見える影響が生じたインシデント、データ損失を伴うインシデント、オンコール対応者の介入が必要になったインシデント、解決時間が一定の閾値を超えたインシデント、監視の失敗などを作成対象の目安として挙げています*1。障害対応そのものと、その後の振り返りを別工程として明確に分けている点が特徴です。
ブレームレスの意味 — 非難ではなく貢献要因を特定する
ブレームレス（非難しない）とは、ポストモーテムにおいて個人やチームを不適切な行動で非難するのではなく、インシデントにつながった貢献要因を特定することに焦点を当てる姿勢を指します*1。Google SREの解説では「ブレームレスなポストモーテムであるためには、個人やチームを不適切な行動で非難することなく、インシデントの貢献原因を特定することに焦点を当てる必要がある」とされています*1。
この姿勢の前提となっているのが「インシデントに関わる全員が良い意図を持ち、彼らが持っていた情報で正しいことをした」という仮定です*1。誰かが不注意だった、判断を誤ったという個人の資質を出発点にするのではなく、その時点で持っていた情報・手順・仕組みのどこに問題があったかを探る姿勢だといえます。
ブレームレスは、原因を追及しないという意味ではありません。むしろ根本原因を正確に特定するための前提です。個人への非難を排除することで、当事者が経緯を正確に話せる状態を作り、結果として原因分析の精度が上がるという関係にあります。
人を責めると学習が止まる理由
個人やチームを非難する文化がポストモーテムに持ち込まれると、組織の学習機能そのものが損なわれます。Google SREの解説は「指を指す文化と個人やチームを『間違った』ことで恥じる文化が支配的であれば、人々は罰を恐れて問題を明らかにしない」と指摘しています*1。
この状態が続くと、組織にとってより大きなリスクが生じます。同解説は、非難の文化のもとでは「インシデントや問題が隠蔽される」可能性が高まると述べています*1。担当者が自分の関与を最小限に見せようとする、あるいは問題そのものを報告しないという行動が生じれば、根本原因の把握自体ができなくなります。
率直に意見を言える環境（対人関係のリスクを取っても罰されないと感じられる状態）が失われた場では、率直な事実共有が起こりにくくなります。ポストモーテムの価値は、関係者が経緯を隠さず話せることで初めて成立します。非難が先行する場では、この前提条件そのものが崩れます。
ポストモーテムのフォーマットと書く基準
Google SREの解説によると、ポストモーテムのテンプレートには、インシデントデータとタイムライン、影響評価、根本原因分析、アクションプラン、バグ修正の優先度判定といった要素を含みます*1。タイムラインは検知から解決までの経緯を時系列で記録するものであり、影響評価は誰にどの程度の影響が生じたかを整理する部分です。
根本原因分析では、単一の原因に絞り込まず、複数の貢献要因を列挙する形が実務的です。1つの障害には設定ミス・監視の抜け・レビュー体制の不備など複数の要因が重なっていることが多いため、根本原因を1つに矯正すると学習の機会を狭めてしまいます。
アクションプランには、再発防止のために実施する具体的な対応と、それぞれの優先度を記載します。ここで挙げたアクションが実際に実行されなければポストモーテムを書いた意味が薄れるため、次章で述べる追跡の仕組みとセットで運用する必要があります。
作成・レビューの運用面では、Google SREの解説は「各完成ドラフトがレビューされる状態を保つよう、ポストモーテムの定期的なレビューセッションを奨励する」としています*1。また共有については「利益を受けうる範囲の広いオーディエンスと共有すること」を目標に挙げ、組織のリポジトリに保管してアクセス可能にする運用を紹介しています*1。1人が書いて終わりにせず、関係者がレビューし、書かれた内容が他チームにも共有される仕組みを組み込むことが定着の前提になります。
アクションアイテムの追跡とSLO・エラーバジェットとの接続
ポストモーテムで挙げたアクションアイテムは、issueトラッカーなどで追跡し、担当者と期限を明確にした上で完了状況を定期的に確認する運用が欠かせません。アクションアイテムが記録されるだけで実行されない状態が続くと、ポストモーテム自体が形式的な儀式になり、再発防止の効果を持たなくなります。
アクションアイテムの優先度付けにおいては、SLO（サービスレベル目標）とエラーバジェットとの接続が判断材料になります。Google SREの解説では、SLOはプロダクトマネジメントが定義し「サービスが四半期あたりどの程度のアップタイムを持つべきかという期待値を設定する」ものであり、実際のアップタイムは監視システムという中立的な第三者によって計測されるとしています*2。
エラーバジェットは、この目標値と実際の値の差分として定義されます*2。同解説は「これら2つの数値の差が、その四半期に残っている『信頼性の低さ』の予算である」と説明し*2、具体例としてSLOが四半期のクエリの99.999%を正常に処理することであれば、エラーバジェットはその四半期における0.001%の失敗率になるとしています*2。
ポストモーテムで特定した根本原因がエラーバジェットの消費にどの程度つながったかを紐づけると、複数のアクションアイテムのうちどれを優先すべきかを客観的な指標で判断できます。感覚的な重大さではなく、SLOに対する実際の影響度でアクションの優先順位を決める運用が、限られたエンジニアリングリソースを再発防止に振り分ける上で実務的です。
ブレームレス文化が定着しない典型的な理由
ブレームレスの考え方を理解していても、組織に定着させることは容易ではありません。典型的には、経営層やマネジメント層がインシデント発生時に担当者個人の責任を追及する言動を取ると、現場は「実際には非難される」と学習し、以後の報告を控えるようになります。制度としてブレームレスを掲げていても、実際の言動が伴わなければ形式だけのルールになります。
また、人事評価にインシデントの発生件数や担当者名が直接紐づく仕組みが残っていると、ブレームレスの原則と評価制度が矛盾します。担当者は評価への影響を避けるために事実を曖昧にする動機を持ってしまい、正確なタイムラインの記録が難しくなります。
ファシリテーションの技術不足も定着を妨げる要因です。ポストモーテムの会議を主導する役割の担当者が、意図せず「なぜあなたは気づかなかったのか」という個人への問いかけをしてしまうと、参加者は防御的になります。進行役には、貢献要因を問う質問（「その時点でどのような情報があったか」「どの手順が想定と異なっていたか」）へ言い換える技術が求められます。この技術は経験によって蓄積される部分が大きく、社内に定着した進行役がいない状態では、同じような失敗が繰り返されやすくなります。
外注・外部ファシリテーションの委託範囲と発注準備
ポストモーテム文化の定着を外部に委託する場合、委託範囲は主に4つの工程に分けられます。第一にポストモーテムのテンプレート・運用ルールの設計、第二にレビュー会議のファシリテーション、第三にアクションアイテムの追跡体制の構築、第四に定着状況の評価と改善提案です。
外部ファシリテーターを起用する利点は、社内の人間関係から一定の距離を保ちながら議事を進行できる点にあります。上司と部下という関係が会議に持ち込まれると、部下は率直に話しにくくなることがあります。第三者が進行役を務めることで、貢献要因への質問と個人への追及を切り分けやすくなります。
| 委託工程 | 委託先が担う作業 | 発注側が準備する情報 |
|---|---|---|
| テンプレート・運用ルール設計 | 記録項目・作成基準・共有範囲の設計 | 既存のインシデント対応フローの現状 |
| レビュー会議のファシリテーション | 貢献要因を問う進行と記録の整理 | 参加すべき関係者・体制の情報 |
| アクションアイテムの追跡体制構築 | issueトラッカー連携・進捗確認の仕組み化 | 既存の課題管理ツールの利用状況 |
| 定着状況の評価・改善提案 | 運用状況の確認とルールの見直し提案 | SLO・エラーバジェットの設定状況 |
発注側が準備しておくべき情報としては、既存のインシデント対応フローの現状、ポストモーテムの作成基準を適用すべき過去のインシデント事例、参加すべき関係者の範囲、SLO・エラーバジェットの設定状況が挙げられます。これらが整理されているほど、委託先はテンプレート設計とファシリテーションの方針を早く固められます。
委託範囲を決める際は、初期のテンプレート設計とファシリテーションの立ち上げ支援のみを外部に依頼し、定着後の運用は社内で回す形にすることもできます。立ち上げ期に専門的な進行技術を借りることで、社内にファシリテーションの型を移植しながら初期の失敗を避けられます。
まとめ — ポストモーテム文化を定着させる3つの軸
本稿では、ポストモーテムの定義とブレームレスの考え方、フォーマット・運用の要点、外部ファシリテーションを活用する際の委託範囲・発注準備を整理しました。要点を3つに集約すると次の通りです。第一に、ポストモーテムは障害対応そのものとは別の工程として、タイムライン・根本原因・アクションプランを記録し組織学習につなげる仕組みです。第二に、ブレームレスは非難を排除することで当事者が経緯を正確に話せる状態を作り、根本原因分析の精度を上げるための前提であり、これを欠くと問題が隠蔽されるリスクが高まります。第三に、外注する場合はテンプレート設計からアクションアイテムの追跡体制まで委託範囲を切り分け、SLO・エラーバジェットの設定状況を発注前に整理しておくことが定着を左右します。
よくある質問
ポストモーテムはすべての障害で作成する必要がありますか。
すべてではありません。Google SREの解説は、ユーザーに見える影響・データ損失・オンコール対応者の介入・解決時間の閾値超過・監視の失敗などを作成対象の目安として挙げています*1。自社の基準をあらかじめ定めておくことが実務的です。
ブレームレスとは誰も責任を取らないという意味ですか。
異なります。ブレームレスは個人の非難を避けつつ、インシデントにつながった貢献要因を特定することに焦点を当てる姿勢です*1。原因追及そのものをやめるわけではなく、非難を排除することで正確な事実共有を可能にする考え方です。
アクションアイテムはどのように優先順位をつけますか。
感覚的な重大さだけで決めるのではなく、SLOとエラーバジェットへの影響度を踏まえて優先順位を判断する方法があります*2。エラーバジェットの消費に大きく関わったアクションを優先することで、限られたリソースを再発防止に振り分けやすくなります。
外部にファシリテーションを依頼する利点は何ですか。
社内の人間関係から一定の距離を保ちながら議事を進行できる点が利点です。上司と部下という関係が会議に持ち込まれると率直に話しにくくなることがあり、第三者の進行役が貢献要因への質問と個人への追及を切り分けやすくします。
ポストモーテムを書いても再発防止につながらないのはなぜですか。
アクションアイテムが記録されるだけで追跡・実行されない状態が主な原因です。issueトラッカーで担当者と期限を明確にし、完了状況を定期的に確認する運用をセットで整えることが必要です。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Google SRE Book「Postmortem Culture: Learning from Failure」（John Lunney, Sue Lueder 著、Gary O’Connor 編）（https://sre.google/sre-book/postmortem-culture/）
- *2 出典：Google SRE Book「Embracing Risk」（https://sre.google/sre-book/embracing-risk/）
