知識マップ: 障害対応は復旧で終わらない ── 小さな開発チームのためのポストモーテム(再発防止)の型

記事「障害対応は復旧で終わらない ── 小さな開発チームのためのポストモーテム(再発防止)の型」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

この記事は、障害対応を復旧で終わらせず仕組みを変えるためのポストモーテムの実務を、概念どうしの関係として整理します。ポストモーテムはblamelessの原則のもとで直接原因と寄与要因を分けて記録し、なぜなぜ分析で人の行動を終点にせず仕組みの不備まで掘ることで寄与要因を見つけます。寄与要因への対応は、効果が消えやすい弱い注意喚起ではなく、手順書を中間段階に据えつつ自動テストや監視のような機械的な対策へ引き上げることが推奨されます。寄与要因を放置すると障害は再発するため、全障害にフル実施はせず影響度と再発可能性でトリアージし、軽微なものも障害管理簿に記録します。顧客向け障害報告書は内容の多くをポストモーテムから転用しますが、責任追及と再発防止の議論が歪まないよう目的を分けて運用します。

flowchart LR
    accTitle: ポストモーテムによる再発防止の知識マップ
    accDescr: ポストモーテムがblameless原則のもとで直接原因と寄与要因を分けて記録し、寄与要因への対策を弱い注意喚起ではなく手順書を経て機械的な対策へ引き上げること、影響度と再発可能性でトリアージして障害管理簿と使い分けること、責任追及を扱う顧客向け障害報告書とは目的を分けつつ内容を転用することを示す図
    postmortem["ポストモーテム"]
    blameless_principle["blameless(非難しない)原則"]
    direct_cause["直接原因"]
    contributing_factor["寄与要因"]
    five_whys_analysis["なぜなぜ分析(5 Whys)"]
    mechanical_countermeasure["強い再発防止策(機械的に防ぐ・検知する)"]
    weak_countermeasure["弱い再発防止策(気をつける・周知する)"]
    procedural_countermeasure["中程度の再発防止策(手順書・チェックリスト)"]
    postmortem_triage["ポストモーテム実施のトリアージ"]
    incident_log["障害管理簿"]
    incident_review_meeting["ポストモーテムのレビュー会"]
    customer_incident_report["顧客向け障害報告書"]
    code_repository["コードリポジトリ"]
    blame_culture_info_withholding["非難する文化での情報隠蔽"]
    azure_well_architected_framework["Azure Well-Architected Framework"]
    recurring_incident["障害の再発"]
    blameless_principle -->|"推奨される対応"| postmortem
    postmortem -->|"利用する"| direct_cause
    postmortem -->|"利用する"| contributing_factor
    contributing_factor -->|"で確認できる"| five_whys_analysis
    mechanical_countermeasure -->|"推奨される対応"| contributing_factor
    weak_countermeasure -->|"用いるのは非推奨"| contributing_factor
    procedural_countermeasure -.->|"より先に行うべき"| mechanical_countermeasure
    postmortem -.->|"前提とする"| postmortem_triage
    incident_log -->|"推奨される対応"| postmortem_triage
    incident_review_meeting -.->|"前提とする"| postmortem_triage
    incident_review_meeting -->|"実装を担う"| blameless_principle
    customer_incident_report -->|"内容を継承する"| postmortem
    code_repository -->|"推奨される対応"| postmortem
    blameless_principle -->|"防止する"| blame_culture_info_withholding
    azure_well_architected_framework -->|"推奨される対応"| mechanical_countermeasure
    contributing_factor -.->|"原因になり得る"| recurring_incident

概念間の関係(全16件)

図と同じ関係を文章でも列挙します。表示している文と機械可読な意味データ(RDFa)は同じ要素に載っています。確度が「確立した関係」のものは直接の関係として、「条件付きの関係」のものは成立条件つきの言明(rdf:Statement)として表現しています。

• blameless(非難しない)原則はポストモーテムに対する本記事の推奨です。ポストモーテムでは、関係者が持っていた情報の範囲で正しく行動したと仮定し、個人ではなく仕組みの穴を探すblamelessの原則を採ることが推奨される / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• ポストモーテムは直接原因を利用します。ポストモーテムは、障害を直接引き起こした技術的な事象である直接原因を記録する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• ポストモーテムは寄与要因を利用します。ポストモーテムは、直接原因の混入・見逃し・被害拡大を許した条件である寄与要因を記録し、再発防止策の主戦場とする / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 寄与要因はなぜなぜ分析(5 Whys)で確認できます。寄与要因は、なぜなぜ分析で「人の行動」を終点にせず、なぜ間違いがそのまま本番に届いたかまで掘ることで見つけられる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 強い再発防止策(機械的に防ぐ・検知する)は寄与要因に対する本記事の推奨です。寄与要因への対応は、気をつける・周知するではなく自動テスト・アサーション・監視のように機械的に防止・検知する対策へ引き上げることが推奨される / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 弱い再発防止策(気をつける・周知する)を寄与要因に用いることは推奨されません。「気をつける・周知する」対策は人の記憶と善意に依存し、時間経過と担当者交代で効果が消えるため、寄与要因への恒久対策としては推奨されない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 中程度の再発防止策(手順書・チェックリスト)は強い再発防止策(機械的に防ぐ・検知する)より先に行うべきです。強い対策がすぐに打てない場合は、手順書やチェックリストを中間段階として先に置き、恒久対策である機械的な対策を期限付きのアクションとして後から実施する / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• ポストモーテムはポストモーテム実施のトリアージを前提とします。個々のポストモーテムの成立に必須ではないが、チームで継続的にポストモーテムの実践を回す場合は、全障害にフル実施を義務付けると続かないため、影響度×再発可能性でのトリアージによって実施レベルを決めることが前提になる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• 障害管理簿はポストモーテム実施のトリアージに対する本記事の推奨です。影響が軽微でトリアージ上フル実施としない障害でも、障害管理簿への記録だけは必ず残すことが推奨される / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• ポストモーテムのレビュー会はポストモーテム実施のトリアージを前提とします。責任判断者を入れない30分のレビュー会は、影響度×再発可能性のトリアージで「影響大・構造的」と判定されたフル実施の障害についてのみ開かれる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• ポストモーテムのレビュー会はblameless(非難しない)原則の実装を担います。レビュー会は責任の判断をする立場の人を参加者に入れず、個人名が主語の発言を仕組みの主語に置き換えることでblamelessの原則を運用に落とし込む / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 顧客向け障害報告書はポストモーテムの内容を継承して表示します。顧客向け障害報告書は、概要・影響・時系列・直接原因・再発防止策という内容の8割を内部ポストモーテムから転用して作られる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• コードリポジトリはポストモーテムに対する本記事の推奨です。続けるための最小テンプレートは、docs/postmortem/などリポジトリ内に日付付きファイルとして置き、コードと同じ場所でバージョン管理することが推奨される / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• blameless(非難しない)原則は非難する文化での情報隠蔽を防ぎます。個人を責めない原則は、責める場で情報が出てこなくなり原因究明が止まるという問題を防ぐためのものである / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Azure Well-Architected Frameworkは強い再発防止策(機械的に防ぐ・検知する)に対する本記事の推奨です。Azure WAFは、根本原因分析の教訓を対応プロセスの改善・可観測性の強化・設計の改善というシステムへの還元として推奨しており、機械的な対策への引き上げと同じ構図を示す / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 寄与要因は障害の再発の原因になることがあります。直接原因だけを直しても寄与要因が残っていれば、別の直接原因が同じ経路で入り込み障害が再発する / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典

主要概念の定義

ポストモーテム

インシデントの影響・根本原因・対応の時系列・再発防止アクションを文書化する、復旧後に行う構造化された振り返りの型。

blameless(非難しない)原則

関係者は持っていた情報の範囲で善意に基づき正しく行動したと仮定し、個人ではなく仕組みの穴を探すポストモーテムの中核原則。

寄与要因

直接原因の混入・見逃し・被害拡大を許した条件。再発防止策の主な対象になる。

強い再発防止策(機械的に防ぐ・検知する)

自動テスト・アサーション・型や設計による制約・CIのゲート・監視アラートのように、人の状態に依存せず仕組みが動く限り持続する再発防止策。

弱い再発防止策(気をつける・周知する)

「確認を徹底する」「注意喚起する」のように人の記憶と善意に依存し、時間経過と担当者交代で効果が消えやすい再発防止策。

中程度の再発防止策(手順書・チェックリスト)

リリースチェックリストや障害対応手順書のように、手順が守られる限り持続するが形骸化のリスクもある再発防止策。

障害管理簿

軽微な障害も含め、日付・現象・原因・対処を1行または1段落で必ず記録し、数年後も全文検索できるようにする記録簿。

ポストモーテムのレビュー会

初版を事前に配布し、責任判断者を参加者から外して30分程度の時間配分で寄与要因とアクションを確定する会議。

顧客向け障害報告書

何が起きて、どう対処したかという説明責任を果たすために顧客へ提出する文書。内容の多くはポストモーテムから編集して作られる。

コードリポジトリ

ソースコードをバージョン管理するリポジトリで、ADRはこの中にコードと同じ場所で保管される。

Azure Well-Architected Framework

Microsoftが提供する、クラウドワークロードの設計品質を高めるためのアーキテクチャガイダンス群である。

機械可読データ

• JSON-LD / Turtle ── この記事の知識グラフ全体
• 概念一覧 / 語彙(述語)の定義

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。