# ポストモーテム ## 定義 ポストモーテム（Postmortem）は、インシデント発生後に行う**非難なき事後振り返り**。何が起きたか・なぜ起きたか・どう対応したか・再発をどう防ぐかを構造化して記録し、個人でなくシステムの欠陥に焦点を当てる。[[インシデント管理]] ライフサイクルの最終段「学習（Learn）」を担い、[[FRACAS]]（Failure Reporting, Analysis and Corrective Action System）と同型の閉ループフィードバック機構をソフトウェア運用に適用したものである。 - **TLA+ フォーマルモデリングはインシデントレポートを設計レベルの洞察へ変換する**: インシデントレポートは「何が起きたか・なぜ緩和したか」を文書化するが、「なぜ設計がその動作を許したか」という設計レベルの問いに答えにくい。[[Finn Hackett]] と [[Markus A. Kuppe]] は Azure CosmosDB の 28 日間インシデントを事例として、TLA+ モデルチェッカーを使ってインシデントレポートを「カウンター例を生成する形式モデル」に変換するワークフローを提示した。カウンター例は問題をより簡潔に表現し、エンジニアが疑っていたが証明できなかった根本原因を確定できた（[[@2023__SREcon23Americas__Turning an Incident Report into a Design Issue with TLA+]]）。このアプローチはとくに「小規模再現が困難・設計の深い理解が必要・複数ソースにわたるシステム」の案件に有効。 ## 三つの柱 | 柱 | 内容 | 代表ソース | | --------------- | -------------------------------------------------- | --------------------------- | | **ブレームレス文化** | 人でなくシステムの欠陥に焦点を当てる。書いた人を賞賛する。広く共有する | SRE Book Ch15、mixi、Hatena | | **構造化プロセス** | タイムライン中心の文書、SEV 別の会議スケジュール、ステータスワークフロー、アクションアイテム追跡 | PagerDuty、SRE Workbook Ch10 | | **ツーリングと発見可能性** | データ一元化、自動生成テンプレート、リビングドキュメント、タグベース検索 | Datadog、Google SRE AI | ## 横断的知見 - **ポストモーテムは「変化への論拠」であり、修復項目を Incident Response 軸とシステム軸の 2 軸で分類することで実行可能性が高まる**: Hidalgo（SREcon19 EMEA）は Nida Farrukh (Monitorama 2019) の言葉 "A postmortem is an argument for change." を引用し、ポストモーテムの目的が変化の正当化にあることを強調した。修復項目の分類として (1) インシデントレスポンス軸: タイムライン分析・TT Detect・TT Engage・TT Mitigate と (2) システム軸: 予防的/緩和的対応・「なぜこんな仕組みが存在するのか（Why do we even X?）」という自問 の 2 軸を示した。また「多様なバックグラウンドと専門性が鍵」と強調し、技術的修復項目とプロセス的修復項目を区別しない混成チームでのポストモーテムを推奨した。Gallego の「修復を定義から外す」と表面上は矛盾するが、Hidalgo は「変化へのアクション」として修復を位置づけており、「形式的な義務としての修復」ではなく「変化の道具としての修復」という点で整合する。(Source: [[@2019__SREcon19EMEA__How to SRE When Everything is Already on Fire]]) - **「ブレームレス」と「ブレーム・アウェア（非難認識）」の違い**: [[@2018__SREcon18 Americas__Architecting a Technical Post Mortem]]（[[Will Gallego]] / [[Etsy]]）は、「ブレームレス（非難なし）」という表現が「責任の否定」と誤解されやすく、必要な情報（誰がどのような判断をしたか）の隠蔽を招くと指摘する。「ブレームレス」の代わりに「ブレーム・アウェア」——バイアスや非難感情が存在することを認めつつ、それを指差しの形で表出させない——を提唱する。SRE Book・mixi・Hatena がともに「ブレームレス」を使う中、Gallego の refinement は実践者として遭遇した「責任の所在を誰も語らない」問題を解消しようとする工夫として位置づけられる。 - **ポストモーテムの定義から「修復」を意図的に外す**: Gallego の定義 "The application of a learning culture through shared discussion of our beliefs on what transpired over an agreed upon limited number of events" には修復項目・再発防止の保証・「二度と起こさない」という誓約が意図的に含まれていない([[@2018__SREcon18 Americas__Architecting a Technical Post Mortem]] p.8–9)。Larson の「Incident Legalism」([[@ReadME__Will Larson__Move Past Incident Response to Reliability]])も形骸化の原因として「実行不可能な修復提案」を挙げており、二つのソースが異なる角度から同じ病理を指摘している。 - **ポストモーテムでの「根本原因」用語の否定**: [[@2018__SREcon18 Americas__Architecting a Technical Post Mortem]]（p.22）は PM の中で root cause・primary cause などの用語を使わないことを強く推奨する。根拠は「イベントはほぼ必ず複数の絡み合った要因によって起き、単一の原因を見つけたと宣言することは浅い答えに満足することを意味する」。[[根本原因分析]] の技術的文脈とは対照的に、ポストモーテムの文化的文脈では「根本原因を探す姿勢」そのものが深掘りを阻害する。 - **ローカル合理性（Local Rationality）とポストモーテムの感情管理**: Gallego は "People act in accordance with what they believe was the best course of action given the information at the time." を「ローカル合理性」と呼び、誰かの判断を却下したくなる瞬間にこの原則を思い出すことを推奨する([[@2018__SREcon18 Americas__Architecting a Technical Post Mortem]] p.25)。これは mixi・Hatena の「賞賛文化」「ブレームレス」の実装方法の一つでもあり、参加者が強い感情を抱えてPMに入る場合のファシリテーション前の準備（1:1 でのヒアリング・自分自身の失敗を語る・困難な点を後回しにする提案）と組み合わせて機能する。 - **修復的正義の枠組みをポストモーテムに適用する**: 報復的正義（規則・違反・制裁）と修復的正義（癒し・複数の物語の受容・関係の回復）の対比を PM に当てはめると、ブレームレス/ブレーム・アウェアのポストモーテムは**修復的正義の実践**である([[@2018__SREcon18 Americas__Architecting a Technical Post Mortem]] p.26)。この枠組みは「Google SRE Book のポストモーテム文化」を社会学・法学の概念と接続する視点を提供する。 - **ポストモーテムの形骸化メカニズム（Incident Legalism）**: [[@ReadME__Will Larson__Move Past Incident Response to Reliability]] は、プロセスが信頼性でなくコンプライアンスに焦点を移す病理パターンを「インシデント法律主義」と名付けた。繰り返しのレビュー質問、過度な重篤度分類の議論、メタデータ収集への過度の注力、実行不可能な修復提案が特徴。対策は手続きの増加でなく、対応・分析・修復の三段への投資バランスである。ポストモーテムの数を増やしても、アクションアイテムの実行率が上がらなければ信頼性は改善しない。 - **再発防止策の構造化フレームワーク**: 再発防止策を場当たり的に列挙するのでなく、**予防・検出・緩和・修正**の 4 分類で整理する手法が [[@mixi developers__インフラ障害対応とポストモーテム]] に見られる。この 4 分類は [[インシデント管理]] の「検知→トリアージ→診断→緩和」の各段に対応し、アクションアイテムのカバレッジを網羅的に検証する枠組みとして機能する。Google SRE Book のポストモーテムテンプレートも類似の項目を持つが、mixi の 4 分類は各カテゴリを「問い」の形で定式化している点が特徴。 - **ポストモーテムは静的文書でなくリビングドキュメントであるべき**: [[@2021__Datadog Blog__Best Practices for Writing Incident Postmortems]] は、ポストモーテムをインタラクティブグラフやコメント機能を備えた**継続的な調査ツール**として運用することを提案する。これは「書き終えたら棚に置く」従来のアプローチに対する転換で、[[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]] が Slack タイムラインを AI 評価の一次データに昇格させた流れと通底する——インシデント調査中に蓄積される対話データが最も価値の高い学習資源である。 - **障害共有の射程は「再発防止」を超えて「知識の横展開」にある**: [[@2018__Hatena Developer Blog__社内障害情報共有のススメ]] は、全社エンジニアへの障害共有を通じて「同じ障害を繰り返さない」再発防止だけでなく「類似の構造を持つ別の障害を予防する」横方向の学習を実現した。ニアミスも共有対象に含め、チーム横断のアドバイスと協調的問題解決が自然に生まれる仕組みを整えている。SRE Workbook Ch10 が強調する「広い共有」原則の日本企業での純粋な実装例。 - **ポストモーテムの自動化と AI 支援は「下書き生成」と「品質改善」の二方向で進行中**: [[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]] では、Google SRE AI がインシデント対応中の情報を自動集約してポストモーテム下書きを生成するエージェントを運用している。これは [[agentic SRE]] の判断支援入口の一つ（ポストモーテム下書き作成→品質向上 + SRE 工数削減 + 必要情報の網羅性確保）として位置づけられる。Datadog のテンプレート自動生成はツーリングレベルでの同方向の取り組み。 - **デブリーフィングの 7 カテゴリ問いかけ手法**: [[@2016__SREcon16Europe__Accident Models in Post Mortems]]（[[Will Gallego]] / [[Etsy]]）は、デブリーフィング中の問いかけをCues（何を見ていたか）/ Interpretation（状況をどう理解していたか）/ History（この状況は見覚えがあるか）/ Goals（何を達成しようとしていたか）/ Action（どう行動を選んだか）/ Communications（どのコミュニケーション手段を使ったか）/ Help（誰かに助けを求めたか）の 7 カテゴリに分類し、当事者の目に「その時点で世界がどう見えたか」を段階的に再構築する手法を提示した(p.82-95)。これは [[@2018__SREcon18 Americas__Architecting a Technical Post Mortem]] の「ローカル合理性」原則を問いかけ設計に落とした実装と見なせる。 - **2016 年チュートリアルから 2018 年講演への発展**: [[@2016__SREcon16Europe__Accident Models in Post Mortems]] と [[@2018__SREcon18 Americas__Architecting a Technical Post Mortem]] を並べると、[[Will Gallego]] の思想が 2 年間でどう深化したかが分かる。2016 年版は事故モデルの理論（Bad Apples → ドミノ → スイスチーズ）とデブリーフィング実技（7 カテゴリ）の提示に重点を置き、2018 年版は「学習文化の適用」としてのポストモーテム定義・根本原因の否定・修復的正義の枠組みをより体系的に展開した。同一実践者による時系列の思想進化を追える希少なデータポイント。 - **デブリーフィング前の個別インタビューがグループダイナミクスの歪みを防ぐ**: Lund は Postmortem #2 でグループ会議の前に 5〜10 分の個別インタビューを実施することを示した(口頭)。目的は「グループ設定で誰かの意見や記憶が他者に上書きされることを防ぐ」こと。インタビューはインシデント当日ではなく前週から問い起こし、当時の疲労・プレッシャー・文脈を引き出す。Etsy の「Debriefing Facilitation Guide」(Allspaw ほか)を手法の基礎とし、Gallego の「ローカル合理性」も同ガイドが出典元の一つ。ライブデモで実際に「オンコールツールが 2 ヶ月間スマートフォンにインストールできなかった」「前週ずっと手動作業で疲弊していた」という重要文脈がインタビューで初めて表面化した([[@2019__SREcon19 Asia__A Tale of Two Postmortems - A Human Factors View]])。 - **ファシリテーション言語: 「Why/You」を「How」に変換する**: Lund が示したデブリーフィングの言語規律は、「なぜあなたは…したのか」という問い方を「…が行われていたようですが、もう少し詳しく聞かせてもらえますか」に変換すること(口頭)。「Why」は後知恵バイアスを招き「You」は個人を責める。「How」は状況の再現と学習に向く。これは Gallego が "use terms like 'how', not terms like 'why' wherever possible" と提唱するのと同一の技法であり、複数のソースが言語選択の重要性を収束して強調する([[@2019__SREcon19 Asia__A Tale of Two Postmortems - A Human Factors View]], [[@2018__SREcon18 Americas__Architecting a Technical Post Mortem]])。 - **「この特定インシデントの再発防止」を会議目標から外すことで学習の射程が広がる**: Lund は Postmortem #2 のデブリーフィング冒頭でこう明言した: 「この会議の目標は、このインシデントを二度と起こさないことではない。学ぶことだ。アクションアイテムがゼロで終わっても、価値のある議論だったと感じられるべきだ」(口頭)。この設定により、参加者は特定の修復を急いで定義することを求められず、システムの弱点・強み・専門家の依存関係・作業を困難にする要因などより広い問いに注意を向けられる。アクションアイテムは会議末尾にまとめて出す。 - **Dekker の4目的枠組みがポストモーテムの機能を体系化する**: [[Tanner Lund]]（SREcon19 APAC）は Sidney Dekker (2015) の「The psychology of accident investigation」から、ポストモーテムには (1) 認識論的（何が起きたかを確立する）、(2) 予防的（回避への経路を特定する）、(3) 道徳的（逸脱を跡付け境界を強化する）、(4) 実存的（発生した苦痛への説明を見つける）の4目的があると提示した([[@2019__SREcon19 Asia__A Tale of Two Postmortems - A Human Factors View]])。従来の SRE ポストモーテムは (1)(2) に集中し、(3)(4) を「非難文化になるから避ける」として抑制する傾向がある。しかし Lund は道徳的目的を全否定せず、「逸脱の跡付け」と「境界の再確認」という機能があることを認めたうえで、それを「非難」でなく学習に向けることを示唆する。この視点は Gallego の「ブレーム・アウェア」とも通底する([[ポストモーテム]]の横断的知見参照)。 - **「ヒューマンエラー」という結論がポストモーテムを形骸化させる**: Lund は「Human Error」という言葉を「分析の行き止まり（analytical dead end）」と呼ぶ。これは Gallego の「ローカル合理性」、Larson の「Incident Legalism」と同じ病理——表面的な結論で深掘りを止める——を別角度から照射する([[@2019__SREcon19 Asia__A Tale of Two Postmortems - A Human Factors View]])。3つのソースが「表面的な原因帰属がポストモーテムの価値を失わせる」という観察で収束している。 - **修復の完了率・効果に関する懐疑**: Lund は「提案された修復のうち、完了するものはいくつか？」「実際に差異を生むものはいくつか？」と問いかける(p.12–13)。Larson も Incident Legalism として「実行不可能な修復提案の積み上げ」を批判しており、二つのソースが「修復リストを増やすことがイコール信頼性向上ではない」という観察で収束する([[@2019__SREcon19 Asia__A Tale of Two Postmortems - A Human Factors View]], [[@ReadME__Will Larson__Move Past Incident Response to Reliability]])。 - **成功するポストモーテムの実践的6要素**: [[Ashar Rizqi]]（[[Blameless]]、300 社以上の事例から）は、(1) Ownership（所有権）、(2) Context & Key Details（コンテキストと詳細情報）、(3) On Time Completion（期日内完了）、(4) Follow-up Action Items Tracked to Completion（アクションアイテムの完了追跡）、(5) Blameless Language（ブレームレス言語）、(6) Referenceability（再参照性）を成功要件として体系化した([[@2019__SREcon19Asia__Getting More out of Postmortems and Making Them Less Painful to Do]] p.23)。これは PagerDuty・Datadog・Google SRE の手法論を実践企業の視点から再整理したものであり、要素自体は既存の議論と重なるが「各要素がなぜ難しいか・どうすれば容易になるか」をケーススタディ形式で提示した点に価値がある。 - **再参照性(Referenceability)はポストモーテムの未解決問題**: Rizqi は6要素の中でも「再参照性は正直まだ難しい」と認める([[@2019__SREcon19Asia__Getting More out of Postmortems and Making Them Less Painful to Do]] p.43–45)。障壁は「構造化データの記録場所がない・ポストモーテムデータが別システムに散在・チームごとにテンプレートや手法が異なる・うまくやるインセンティブがない」の4点。暫定対策として Google テンプレートを起点とした統一テンプレート・Google Drive / Confluence への集約・ログファイル形式でのインデックス化ハックを提示するが、スケールするソリューションはまだ存在しないと述べる。[[@2021__Datadog Blog__Best Practices for Writing Incident Postmortems]] の「インタラクティブなリビングドキュメント」提案も同じ課題への別アプローチであり、2 つのソースが異なる角度から「ポストモーテムデータの発見可能性スケール問題」を共通の未解決課題として認識している。 - **所有権(Ownership)問題の構造: Hot Potato Blame とトイル**: Rizqi は所有権が困難な理由として「役割・責任が未定義」「Hot Potato Blame（責任のたらい回し）」「ポストモーテム自体がトイル化」を挙げる([[@2019__SREcon19Asia__Getting More out of Postmortems and Making Them Less Painful to Do]] p.25)。解決策として「1 サービスオーナー = 1 PM オーナー」の単純モデル・マネージャー/VP による時間確保の責任・チケットによる所有権追跡・Postmortem Guild（社内横断の有志グループ）を提案する。Postmortem Guild のコンセプトは他のソースに見られない実践知であり、ポストモーテム文化を「SRE チームだけの責任」から「組織横断の取り組み」に昇華する手段として注目できる。 - **ポストモーテムを Slack/Teams 上で実施する軽量アプローチ**: Rizqi は期日内完了を促すための戦術として「Slack や MSFT Teams 上でそのままポストモーテムを実施する」ことを提案し、インシデント専用チャンネル(`#inc-XXXX-postmortem`)での非同期情報収集のデモを示した([[@2019__SREcon19Asia__Getting More out of Postmortems and Making Them Less Painful to Do]] p.30)。これは [[@2021__Datadog Blog__Best Practices for Writing Incident Postmortems]] の「チャットシステムへの統合」と共鳴し、「会議を設定する」負荷を下げることでトイルを削減しながら期日内完了率を高める実用的な解法である。 - **GQM フィードバックモデルは「1 件から学ぶ」ポストモーテムの上位レイヤーとして「複数障害横断分析プログラム」を体系化した最初の公開事例**: [[Sue Lueder]]（[[Google]] SRE PM）は SREcon 2015 で、Goal Question Metric→Collect→Organize→Analyze→Socialize の 5 段サイクルを Google 全プロダクション障害に適用するプログラムを報告した。単一ポストモーテムが「この障害から何を学ぶか」を問うのに対し、GQM フィードバックモデルは「障害群から組織として何を変えるか」という問いを立てる。Socialize フェーズ（開発・製品・法務など非 SRE 層への継続的還流）が後期に最大工数を占めることも観察されており、[[@2018__Hatena Developer Blog__社内障害情報共有のススメ]] の全社共有・Larson のアクションアイテム実行重視と同方向の知見である。タイムライン上 Retrospect（Postmortem）フェーズは Resolve 直後に位置し、Action Items フォローアップが続く構造は PagerDuty・Datadog のライフサイクルと整合する。(Source: [[@2015__SREcon15__What Brought Us Down - Outage Trend Analysis at Google]], p.4, p.12) - **クラウド三社 354 件の実測データがポストモーテムの定量的根拠を提供する**: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]] は AWS・Azure・Google Cloud の公開ポストモーテムから TTX 値（MTTD=16.9 分・MTTI=77.8 分・MTTM=304.2 分・MTTR=572.8 分）を実測し、緩和フェーズが TTR の 53% を占めることを示した。設定ミスが最多根本原因（31.6%）、9 種の緩和手段分布も定量化。ポストモーテムを**データソースとして系統分析に使う**応用は、個別の事後学習を超えた組織横断の知識に昇華させる。[[@2018__Google SRE Workbook__Appendix C Results of Postmortem Analysis]] も同様にポストモーテムの集計分析を行い、変更起因障害やプロセス失敗の傾向を抽出している。 - **日本のウェブ企業のポストモーテム実践は Google SRE の影響下で独自進化している**: mixi と Hatena の事例は、Google SRE Book のブレームレスポストモーテム文化を前提にしつつ、日本のウェブ企業の文脈に適応させている。mixi の「ポストモーテムを書いた人を賞賛する」文化と、Hatena の全社日記ベースの障害共有は、SRE Book の原則を異なる形で具現化した。両社とも Slack 連携による非同期議論を取り入れ、形式化された会議体でなく日常のコミュニケーションチャネルに障害学習を埋め込む傾向が見られる。[[面白法人カヤック]]（[[藤原俊一郎]]）の「月刊ポストモーテム」（Slack 月次投稿＋一言コメント）も同方向の実践であり、加えて「ポストモーテムの知見をコード化する」という発展形（sre-advisor）を示した点が独自である。(Source: [[@2022__SRENEXT2022__1年間のポストモーテム運用とそこから生まれたツール sre-advisor]]) - **ポストモーテムの知見をコード化する循環ループ——知見をガードレールへ昇華**: [[藤原俊一郎]]（カヤック）は「インシデント → ポストモーテム → sre-advisor → 事前検出 → インシデント予防」という閉ループを提唱した。ポストモーテムの振り返りから「クラウドインフラ/ミドルウェアの設定不備が発生要因として多い」という傾向を発見し、その知見を AWS リソース設定の静的チェック CLI ツール（sre-advisor）に書き込むことで、次のインシデントを事前に防ぐ仕組みを作った。Ruppe の「Insights from the Past = Options in the Future」（[[@2022__SREcon22EMEA__The Repeat Incident Fallacy - What Jurassic Park Can Teach Us about Incidents]]）が目標定式として提唱したものを、ツール化によって具体的に実装した事例と見なせる。(Source: [[@2022__SRENEXT2022__1年間のポストモーテム運用とそこから生まれたツール sre-advisor]]) - **チェックシートはトイルであり、SRE はエンジニアリングで設定不備を自動検出すべきである**: カヤックの経験では、ポストモーテムで得た設定ベストプラクティスを「リリース前チェックシート」として運用すると、インフラリソースやミドルウェアが増えるたびにチェックシートを埋めるトイルが発生する。SRE Book 5章のトイル定義（手作業・反復・自動化可能・作業量がサービス成長に比例）に合致するとして、エンジニアリングによる自動化（sre-advisor）に切り替えた。(Source: [[@2022__SRENEXT2022__1年間のポストモーテム運用とそこから生まれたツール sre-advisor]]) - **「プロダクト消滅後の知識保持」はポストモーテム横断統一運用の見落とされがちな効果**: カヤックのような多数のプロダクトが誕生・終了する組織では、プロダクト内に閉じた障害ドキュメントはそのプロダクトの終了とともに参照されなくなる。横断的なポストモーテム集約によって消滅したプロダクトの事例が永続化される。この観点は Hatena の「全社障害共有」（[[@2018__Hatena Developer Blog__社内障害情報共有のススメ]]）や Byrum の「インシデント考古学」（[[@2023__SREcon23Americas__Incident Archeology - Finding Value in the Paperwork and Narratives of the past]]）と同方向だが、「組織の代謝（プロダクトの誕生・消滅）」という切り口は独自である。(Source: [[@2022__SRENEXT2022__1年間のポストモーテム運用とそこから生まれたツール sre-advisor]]) - **ニアミスはポストモーテムと同等かそれ以上の学習価値を持つ**: Carl Macrae（"Close Calls"）によれば、ニアミスは「知識のギャップ・誤ったメンタルモデル・実務家がシステムについて持つ前提の幅」を、本番インシデントより先に顕在化させる。Fred Hebert（Honeycomb）は「ニアミスはポストモーテムの後処理プレッシャーがない分、何が起きたかにより集中できる」と述べる。VOID の公開インシデントレポート分析でも、ニアミスを組織的に研究する価値が強調された。この観点は[[@2018__Hatena Developer Blog__社内障害情報共有のススメ]]の「ニアミスも共有対象に含める」実践と収束する。(Source: [[@2022__SREcon22Americas__Tales from the VOID - The Scary Truth About Incident Metrics]]) - **「contributing factor discovery」は「根本原因分析」の代替概念として機能する**: [[Courtney Eckhardt]]（[[Heroku]]）は SREcon19 Asia/Pacific で「Heroku では root cause analysis でなく contributing factor discovery と呼ぶ」と述べた。理由は「複合システムは複合的に障害するため、単一の根本原因を宣言することが思考を制約する」から（[[@2019__SREcon19 Asia__Retrospectives for Humans (a crash course)]] / transcript）。1990 年シアトル湖上橋崩壊事例（5 因子すべてが揃って初めて崩壊）を根拠として示し、Gallego の「根本原因用語の排除」推奨（[[@2018__SREcon18 Americas__Architecting a Technical Post Mortem]]）と同方向の実践知が別のソースからも独立に出てくることで収束が確認できる。 - **ファシリテーター言語が学習の深さを規定する**: Eckhardt は言語学の implication・presupposition 理論を応用し、ポストモーテム会議で避けるべき語（"you", "why", always, never, just, should）と代替する良い問い方（how, what, what if, could we）を体系化した（[[@2019__SREcon19 Asia__Retrospectives for Humans (a crash course)]] p.19-24）。「なぜ前回直さなかったのか」という一文には「以前に起きた・容易に直せた・あなたが直す人間だった・正当な理由がなかった」という4つの後知恵バイアスの前提が埋め込まれている。問いの文法構造そのものが学習を浅くする機制として機能するという観察は、Gallego（ローカル合理性）・Lund（Why→How 変換）とともに三者収束を形成する。 - **根本原因・アクションアイテム・MTTx を全て除外しても高度規制産業で再発がまれ**: [[Tom Partington]]（[[ANZx]]）は SREcon22 APAC で、根本原因の特定・アクションアイテムの作成・MTTx 指標の追跡を意図的に除外した PIR プロセスを高度規制産業（金融）・1000人超組織で実践し、「再発インシデントがまれ」と報告した（[[@2022__SREcon22APAC__A Post Incident Review Review]]）。これは「アクションアイテムなしでは再発する」「根本原因を特定しなければ意味がない」という従来の前提を直接反証する実例であり、Gallego の「修復をポストモーテム定義に含めない」（[[@2018__SREcon18 Americas__Architecting a Technical Post Mortem]]）や Lund の「アクションアイテムがゼロで終わっても価値がある」（[[@2019__SREcon19 Asia__A Tale of Two Postmortems - A Human Factors View]]）が 1 組織の実績値として裏付けられた。 - **「learning > fixing」—— PIR の優先目標の転換**: Partington は「学習 > 修復（learning > fixing）」をスライドに明記し、J Paul Reed の調査データで PIR の 90.5% が修復アイテムを含む現状を「学習に必要な要素が欠落しがちな証拠」として提示した（[[@2022__SREcon22APAC__A Post Incident Review Review]] p.43–44）。Lesson セクションの5問（What surprised us? / What went well? / What was difficult? / Where did we get lucky? / What don't we understand?）は修復を問わず経験的知識の抽出を促す設問設計であり、これは Allspaw の「How learning is different from fixing」と同一テーゼを設問構造レベルで具現化したものと見なせる。複数のソースが「学習と修復は別物であり、学習を優先すべき」という観察で収束する。 - **SRE主導の執筆会議は「当事者が書く」ポストモーテムの構造的品質問題への解法である**: [[KATO Toshiya]]（[[LINE株式会社]]）が実践した手法は、ポストモーテムを「教材」とするために「書き手プロセスに非専門家を組み込む」という逆転の発想をとる。当事者のみで執筆・共有する既存プロセスは(1)ドメインエキスパートのみの参加、(2)議論中の質問しにくさ、(3)当事者の再発防止優先、(4)記述品質への指摘困難、(5)質問が口頭補足で消える、という5つの構造的問題を抱える。解法は全体共有前の30分執筆専用会議をSREが主導し、SREが担当する他チームを招いて黙読→質問→提案→Kudo wall→会議後編集の流れを実施すること。これは[[Hatena]]の全社障害共有([[@2018__Hatena Developer Blog__社内障害情報共有のススメ]])が「広範な受け手を設定することで品質インセンティブを生む」のとは逆向きのアプローチ——「書き手プロセスに非専門家を組み込むことで品質を生む」——として対比できる。副次効果として共有会議が爆速で終わるようになった。(Source: [[@2023__SpeakerDeck__Postmortem as a textbook]]) ## プロセスの比較 | 側面 | PagerDuty | Datadog | mixi | Hatena | | ----------- | ------------------------------- | ----------- | ----------------- | ------------- | | **文書の中核** | タイムライン | インタラクティブグラフ | テンプレート 5 項目 | 報告 5 項目 | | **再発防止策** | フォローアップチケット | タグベース検索 | 4 分類（予防/検出/緩和/修正） | 予防策 + 備考 | | **会議体** | 15-30 分（SEV 別スケジュール） | 明示なし | 明示なし | 明示なし（社内日記ベース） | | **ステータス管理** | Draft→In Review→Reviewed→Closed | 明示なし | 明示なし | キーワードアーカイブ | | **共有範囲** | IC + 対応者 + オーナー | チーム | 関係者 | **全社エンジニア** | | **文化的強調点** | ブレームレス | 効率化 | 賞賛文化 | 横展開学習 | - **テンプレート形式が IR の学習価値を根本的に損なう**: [[Laura Nolan]]（[[Stanza Systems]]、SREcon22 EMEA 2022）は、多くの IR が「テンプレートを機械的に埋める」形式で書かれ、関係者以外に読まれないまま学習機会が失われると指摘する。テンプレートはプロセス遵守には有効だが、**ナラティブ（謎→調査→解決の 3 部構成）を失わせる**という根本的欠陥がある。IR の価値は「プロセスの完遂」ではなく「学習の生成」にあり、ナラティブ形式で書かれた IR こそが年単位で語り継がれる知識になる。この観点は Larson の「Incident Legalism」批判（形式遵守がコンプライアンスに焦点を移す）と同方向だが、Nolan はより具体的に「どう書くか」の実践論を提供している点で補完的。(Source: [[@2022__SREcon22 EMEA__Ditch the Template - How to Write Incident Reports They Want To Read]]) - **「専門知識の継続的損失」としての IR の必要性**: Nolan は Richard I. Cook 命題 13「複雑なシステムの人的専門知識は常に変化し続ける」を受けて、IR を**失われ続ける専門知識を再構築・伝承する手段**として位置づける。この視点は [[インシデント管理]] の「学習（Learn）」フェーズを「情報の記録」から「知識の創造・伝承」へと昇格させるものであり、GQM フィードバックモデル（[[Sue Lueder]])・Hatena の全社共有と同じ方向でより個々の IR 品質に焦点を当てた知見である。(Source: [[@2022__SREcon22 EMEA__Ditch the Template - How to Write Incident Reports They Want To Read]]) - **「Repeat Incident Fallacy」——「再発防止」の誓約そのものが誤った前提に立つ**: [[Emily Ruppe]]（[[Jeli|Jeli.io]]、SREcon22 EMEA）は、公開インシデントレポートの定型結語「このインシデントが二度と起こらないよう…」が根本的に誤った前提に立つと論じる。[[Laura Maguire]] の命題「CI/CD = 継続的変化ゆえに同じインシデントは二度と起きない」を根拠として、規模のある複雑社会技術システム（sociotechnical systems）において「同一インシデントの再発」はジュラシックパーク式の恐竜再生と同程度に起こりえないと主張する([[@2022__SREcon22EMEA__The Repeat Incident Fallacy - What Jurassic Park Can Teach Us about Incidents]] p.4–6)。この主張は Gallego の「修復をポストモーテム定義に含めない」・Lund の「このインシデントを再び起こさないことを会議の目標にしない」と同一の病理——「再発防止の誓約がポストモーテムの射程を歪める」——を別角度から照射する三者収束として位置づけられる。(Source: [[@2022__SREcon22EMEA__The Repeat Incident Fallacy - What Jurassic Park Can Teach Us about Incidents]], [[@2018__SREcon18 Americas__Architecting a Technical Post Mortem]], [[@2019__SREcon19 Asia__A Tale of Two Postmortems - A Human Factors View]]) - **「過去の洞察=未来の選択肢」——「再発防止」に代わる目標定式**: Ruppe は「二度と起こさない」の代わりに "Insights from the Past = Options in the Future" という枠組みを提案する([[@2022__SREcon22EMEA__The Repeat Incident Fallacy - What Jurassic Park Can Teach Us about Incidents]] p.21–22)。この定式は「修復の保証」でなく「選択肢の蓄積」を目標にすることで、Gallego が定義したポストモーテムの「学習文化の適用」・Lund の「アクションアイテムがゼロでも価値ある議論」・Partington の「learning > fixing」と同型の転換を、より一般化した命題として提示する。4 者が独立に同じ目標転換（「修復」→「学習・選択肢」）に収束することは、SRE ポストモーテム実践のパラダイムシフトとして評価できる。(Source: [[@2022__SREcon22EMEA__The Repeat Incident Fallacy - What Jurassic Park Can Teach Us about Incidents]], [[@2018__SREcon18 Americas__Architecting a Technical Post Mortem]], [[@2022__SREcon22APAC__A Post Incident Review Review]], [[@2019__SREcon19 Asia__A Tale of Two Postmortems - A Human Factors View]]) - **ポストモーテム完了率の実測値と「重大性バイアス」**: [[Clint Byrum]]（[[Spotify]]）は 2020 年のポストモーテム完了率を 55%（Had PM）と測定し、2021 年の改善努力後も 62% にとどまると報告した（[[@2023__SREcon23Americas__Incident Archeology - Finding Value in the Paperwork and Narratives of the past]] p.15, p.18）。さらに Fig 1.3 が示す通り、ポストモーテム完了率は生産性影響度（Productivity Impact）に強く相関し、影響度 5 では 100%、影響度 1 では 50% に過ぎない。「重大インシデントほど丁寧に振り返られ、軽微なインシデントは野放しになる」という構造的バイアスは、Rizqi が指摘した「所有権問題」（[[@2019__SREcon19Asia__Getting More out of Postmortems and Making Them Less Painful to Do]]）や Larson の「Incident Legalism」（[[@ReadME__Will Larson__Move Past Incident Response to Reliability]]）と同型の問題を定量データで裏付ける。 - **部門横断の関係者招待が「学習コミュニティ」を形成する**: [[Vanessa Huerta Granda]]（[[Enova]]）は 10 年の実践から「エンジニアリングだけでなくオペレーション・マーケティング・法務・コンプライアンスをレビューに招く」が最も重要な単一変革と結論づける。理由は (1) インシデントのインパクトが組織全体に伝わり、(2) 異なる部門が「同じチームにいる感覚」を共有し、(3) エンジニアが知らないビジネス文脈が浮上するため。これは [[ブレームレス]] 文化の「賞賛と広い共有」（SRE Book）を組織設計レベルで実装した形であり、Gallego の「ブレーム・アウェア」・Lund の「インタビュー段階での多視点収集」と同方向の知見が、組織の境界を横断する形で現れている（Source: [[@2025__SREcon25 Americas__Learning from Incidents at Scale - Actually Doing Cross-Incident Analysis]]）。 - **アクションアイテムと推奨事項の分離が信頼を守る**: Granda は個別インシデント後に優先できる「アクションアイテム（列1・2）」とクロスインシデント分析後に見えてくる大きな取り組み「推奨事項（列3・4）」の分離を提唱する。アクションアイテムばかりを量産する「アクションアイテムファクトリー（anti-pattern）」はアイテムが実行されないまま積み上がりプログラムへの信頼を損なう。これは Larson の「Incident Legalism」（形式的なアクションアイテムが積まれて信頼性が上がらない）・Gallego の「修復保証をポストモーテムに含めない」の実践的帰結と同方向であり、Partington の「learning > fixing」とも収束する（Source: [[@2025__SREcon25 Americas__Learning from Incidents at Scale - Actually Doing Cross-Incident Analysis]], [[@ReadME__Will Larson__Move Past Incident Response to Reliability]]）。 - **障害パターンプロファイリングの自動化がポストモーテム分析の対象範囲を拡大する**: Huawei Cloud では手動ポストモーテムの対象が深刻度 S1/S2/S3 のインシデントに偏り、S4/S5 の軽微インシデントが放置されていた。FaultProfIT（ICSE-SEIP 2024）が自動プロファイリングを導入した結果、30 以上のサービスにわたる全インシデント（10,000 件以上）の障害パターンが可視化され、手動分析では捕捉できなかったメモリ過負荷傾向が第 10〜15 週の上昇として検知できた。ポストモーテムの「深刻度バイアス」を自動化で補完するアプローチは、SRE コミュニティが議論する「アクションアイテム完了率」問題とは異なる切り口で、ポストモーテム全体のカバレッジ問題を扱う。(Source: [[@2024__ICSE-SEIP__FaultProfIT - Hierarchical Fault Profiling of Incident Tickets in Large-scale Cloud Systems]]) - **「過去の記録から学ぶ」という第三の活用法——インシデント考古学**: 多くのポストモーテム議論は個別インシデントの振り返り（Gallego・Lund・Eckhardt 等）か、ポストモーテムデータの横断集計（Lueder の GQM フィードバックモデル・ISSRE 2022 のクラウド三社分析）に二極化している。Byrum が提唱する[[インシデント考古学]]は、過去記録を「アーティファクト」として仮説検証に用いる第三の活用法を開く。探していなかった知見（起動・終了時刻の 75% デフォルト放置・業務時間中に 80% 宣言・変更起因は 30% のみ）が仮説から得た知見より有価値だったという経験は、Lueder の「Socialize フェーズ」で初めて意味を持つ知見が生まれる構図と通底する。（Source: [[@2023__SREcon23Americas__Incident Archeology - Finding Value in the Paperwork and Narratives of the past]] p.24） - **「FIX MORE, WHINE LESS」——ブレームレス文化をスローガンとして物理的に可視化した実践**: [[Pedro Canahuati]]（Facebook Production Engineering）は週次金曜の SEV レビューを「毎週インフラ全体のブレームレスポストモーテムを行う場」として制度化し、「FIX MORE, WHINE LESS」をTシャツに印刷してインフラ全員に配布した。スローガン戦略は Gallego の「ブレーム・アウェア」（語るのを止める文化）・Lund の「会議の目標を変える」という認知アプローチとは対照的で、言語・ロゴ・物品という有形物を通じて文化をインストールする手法である。[[Jay Parikh]]（エンジニアリング責任者）が毎週同席し、リソース不足が判明した際に即座に追加エンジニアをアサインする権限を持って動いた。これは [[Ben Treynor Sloss]] が 2014 年 SREcon14 で述べた「システム・環境・プロセスを修正する」という原則を、上位リーダーが毎週の意思決定で体現する構造的な実装例である。（Source: [[@2015__SREcon15__Notes from Production Engineering]]） - **無責非難のポストモーテムが SRE の文化的基盤として 2014 年に公言された**: [[Ben Treynor Sloss]] は 2014 年の SREcon14 で「全員が善意で、その時点で正しいと信じることを行った」という前提からポストモーテムを開始し、「人でなくシステム・環境・プロセスを修正する」原則を提示した。この 2014 年の公言は SRE Book（2016 年 Ch15 Postmortem Culture）より 2 年早く、Gallego（SREcon16 Europe, SREcon18 Americas）が提唱した「ブレーム・アウェア（非難認識）」や「ローカル合理性」の理論的基盤を先取りしている。ただし 2014 年の言語化は「全員善意・システム修正・バグ追跡」というシンプルな原則記述に留まるのに対し、Gallego の 2016〜2018 年の発展は「根本原因用語の排除・修復の定義外し・修復的正義の枠組み」という組織文化の精緻化へと深化している。両者を並べると、2014 年の実践的原則記述から 10 年かけて理論的文化論へ昇格していくポストモーテム文化の知的系譜が見える。(Source: [[@2014__SREcon14__Keys to SRE]], [[@2016__OReilly__SRE Book - Chapter 15 Postmortem Culture - Learning from Failure]], [[@2018__SREcon18 Americas__Architecting a Technical Post Mortem]]) - **「エンゲージングなポストモーテム」の5段階構成は、ナラティブ重視派と learning > fixing 派を橋渡しする具体的な執筆手順を提供する**: [[Laura de Vesine]] は「舞台設定→ドラマの追加→出来事の連鎖→対応の説明→修正計画」という5段階でポストモーテムを構成し、修正計画(action item)を意図的に最終段階に置くことで、性急な修復への飛躍を防ぐ執筆順序を提案する([[@2024__SREcon24Americas__Storytelling as an Incident Management Skill]] p.12-18)。これは [[Laura Nolan]] が主張する「テンプレートはナラティブ(謎→調査→解決の3部構成)を失わせる」批判([[@2022__SREcon22 EMEA__Ditch the Template - How to Write Incident Reports They Want To Read]])に対する実務的回答になっている——de Vesine の5段階は固定フォーマットでありながら、出来事を因果論理で連鎖させる narrative 構造を明示的に組み込んでいるため、「テンプレート」と「ナラティブ」は必ずしも対立しない。また「トラブルシューティングの経緯より出来事の連鎖を残すことを選ぶ、なぜなら人間は直せないがシステムは直せるかもしれないから」という de Vesine の理由づけは、Partington の「learning > fixing」・Ruppe の「Insights from the Past = Options in the Future」と同型の、修復よりも学習可能な構造(出来事の連鎖)を残すことを優先する思想に位置づけられる。(Source: [[@2024__SREcon24Americas__Storytelling as an Incident Management Skill]], [[@2022__SREcon22 EMEA__Ditch the Template - How to Write Incident Reports They Want To Read]], [[@2022__SREcon22APAC__A Post Incident Review Review]], [[@2022__SREcon22EMEA__The Repeat Incident Fallacy - What Jurassic Park Can Teach Us about Incidents]]) ## 未解決の問い - TLA+ などのフォーマルモデルをポストモーテムに活用するワークフローは、モデル構築に数ヶ月のコストがかかる。「ドメインエキスパートが事前に構築した再利用可能モデルがある組織」でしか実用的でない可能性がある。このコストを正当化するには何件以上のインシデントでモデルが使われる必要があるか（[[@2023__SREcon23Americas__Turning an Incident Report into a Design Issue with TLA+]]）。 - Human Factors アプローチ (個別インタビュー→デブリーフィング) は時間・コストに対してどれだけ付加価値をもたらすか。Lund が示した Postmortem #2 の手法は定量的に検証されているか。 - Dekker の4目的のうち「実存的目的(苦痛への説明)」はソフトウェア障害に有意義に適用できるか。ユーザー影響の大きいインシデントではこの目的が看過されているか。 - ポストモーテムのアクションアイテム完了率はどの程度か。Larson が指摘する Incident Legalism のもとでは、アクションアイテムの列挙が増えても完了率は下がるのか。完了率と信頼性改善の相関を定量的に検証した研究は未見。 - 障害パターンプロファイリングの自動化（FaultProfIT）は Huawei Cloud の単一ドメインでしか評価されていない。他クラウド事業者（AWS・Azure・GCP）でも同様の障害パターンタクソノミが存在するか、また階層誘導型対照学習はタクソノミ構造の違いに対してロバストか（[[@2024__ICSE-SEIP__FaultProfIT - Hierarchical Fault Profiling of Incident Tickets in Large-scale Cloud Systems]]）。 - LLM によるポストモーテム下書き自動生成（Google SRE AI）は、人間が書くポストモーテムと比較してどの程度の品質を達成するか。特に「非難なき記述」の維持と「根本原因の正確な特定」の両立は自動化でどこまで可能か。 - ポストモーテムの発見可能性（Datadog の 4 番目の実践）は、組織が成長しポストモーテムが蓄積するほど検索コストが増大する。タグ付けとテンプレート化だけでスケールするのか、それとも知識グラフやセマンティック検索が必要になるか。 - 日本のウェブ企業のポストモーテム実践（mixi・Hatena）は中小規模組織の事例。数千人規模の日本企業でブレームレス文化が定着する条件は何か。組織文化との適合性に関する実証研究は不足している。 - ナラティブ型 IR（Nolan 提唱）とテンプレート型 IR では「実際に読まれた率」「組織学習への貢献」にどの程度の差があるか。定量的な比較研究はあるか。 - ナラティブ IR を書くコスト（時間・ライティングスキル）と学習効果のトレードオフをどう評価するか。公開 IR（GitLab・Cloudflare 等）の品質が高いのは外部公開インセンティブによるもので、社内専用 IR では達成困難か。 - ポストモーテムは非同期（Slack/Teams 上での記述）と同期（ミーティング）のどちらが効果的か。Rizqi は非同期を軽量化手段として提案し Lund は事前個別インタビュー→同期デブリーフィングを推奨する。両アプローチの適用条件（インシデントの重大度・チームの規模・心理的安全性の成熟度）は何か([[@2019__SREcon19Asia__Getting More out of Postmortems and Making Them Less Painful to Do]] p.46)。 - ポストモーテムギルド（Rizqi 提案）は実際に機能するか。組織内でポストモーテム実践をスケールさせる横断組織の成功・失敗事例を調べたい。 - Spotify の 62% という完了率は業界平均と比べて高いか低いか。他社の比較可能なデータはあるか。また、完了率 100% を目指すべきか、それとも「重大なものだけ完了」という重篤度バイアスは許容できるか（[[@2023__SREcon23Americas__Incident Archeology - Finding Value in the Paperwork and Narratives of the past]]）。 - [[クロスインシデント分析]] プログラムを「自走」させる 3 要素（専任チーム・構造化アーティファクト・組織計画との連動）は、標準的な SRE 組織でどれだけ再現性があるか。Enova の 4 名専任チームは何件/年のインシデントを処理しているか（[[@2025__SREcon25 Americas__Learning from Incidents at Scale - Actually Doing Cross-Incident Analysis]]）。 - sre-advisor のようなポストモーテム知見のツール化（設定静的チェック）と、AIOps や LLM による動的な根本原因分析はどのように組み合わせられるか。静的チェックは「既知の設定不備」を防ぐが、未知のパターンに対してどこまで拡張できるか（[[@2022__SRENEXT2022__1年間のポストモーテム運用とそこから生まれたツール sre-advisor]]）。 - Embedded SRE 組織でのポストモーテム横断統一運用は、中央集権型 SRE 組織より難しいか。カヤックの場合は SRE チームが取りまとめ役を担ったが、各チームへの浸透コストや参加者のモチベーション維持の方法は何か。 - de Vesine の「エンゲージングなポストモーテム」5段階構成(舞台設定→ドラマの追加→出来事の連鎖→対応の説明→修正計画)は、Nolan のナラティブ型 IR や Eckhardt のファシリテーター言語論と比べてどの程度実際に読者を惹きつける効果があるか。定量的な読了率・エンゲージメント比較は未見([[@2024__SREcon24Americas__Storytelling as an Incident Management Skill]])。