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

「先月直してもらったのと同じエラーが、また別の画面で出たんですが」──保守しているシステムでこう言われたとき、返す言葉に詰まった経験はないでしょうか。

障害対応そのもの、つまり検知して、原因箇所を特定して、直して、リリースして、謝る。ここまでは多くのチームがきちんとやります。問題はその後です。復旧した瞬間に全員が日常業務へ戻り、障害の記録は誰かのメールボックスとチャットログに散らばったまま風化する。半年後、同じ構造の障害が別の箇所で再発し、また同じ調査を最初からやり直す。「直して謝って終わり」の障害対応は、同じ授業料を何度も払う運用です。

当ブログでは、障害調査の技術面として「Windowsクラッシュダンプ収集入門」や「例外のcatch・ログ・エラー処理の実務」で「原因にたどり着く方法」を解説してきました。この記事はその次の工程、原因が分かった後に、同じ障害を二度と起こさないための振り返り(ポストモーテム)をどう回すかを扱います。大規模Webサービスの話ではなく、2〜5人で業務アプリ・Windowsソフトを保守する小さなチームで実際に続けられる型に絞ります。

1. まず結論

• 復旧・原因究明・再発防止は別の作業です。復旧は「今日の業務を戻す」、原因究明は「なぜ起きたかを説明できるようにする」、再発防止は「仕組みを変える」。混ぜると全部が中途半端になります。
• 犯人探しをしない(blameless)のは倫理ではなく実利です。個人を責める場では情報が出てこなくなり、原因にたどり着けません。「関係者は持っていた情報の範囲で正しく行動した」と仮定して仕組みの穴を探すのが、SREで定着したblameless postmortemの原則です。¹
• 再発防止策は「気をつける」ではなく仕組み(コード・テスト・監視・手順)に落とします。人の注意力に依存する対策は担当者の交代で消えます。対策の強度を判定する判断表を6章に示します。
• 原因は「直接原因」と「寄与要因」に分けます。直せるのはたいてい寄与要因の方で、「なぜなぜ分析」を人の行動で止めずに仕組みまで掘るのがコツです。
• 全部の障害にフルのポストモーテムはやりません。影響度×再発可能性でトリアージし(7章)、軽微なものは1段落の記録だけ残します。続けられる分量に抑えることが制度を殺さない最大の条件です。
• ポストモーテムは1時間で書ける分量にします。4章に最小テンプレートを示します。立派な文書を月に0本書くより、粗い記録を毎回残す方が価値があります。
• 受託開発では、顧客向け障害報告書とは目的を分けつつ、内容はポストモーテムから転用します(8章)。責任追及の文書と再発防止の文書を混ぜないことが、双方の品質を守ります。

この記事の知識マップ

この記事は、障害対応を復旧で終わらせず仕組みを変えるためのポストモーテムの実務を、概念どうしの関係として整理します。ポストモーテムは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件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. なぜ同じ障害が繰り返されるのか

再発する障害には、技術ではなく運用のパターンがあります。

復旧した瞬間に「終わった」ことになる。障害対応は緊急割り込みなので、復旧すると全員が溜まった通常業務へ戻ります。振り返りの時間は誰のカレンダーにも入っておらず、「落ち着いたらやろう」は永遠に来ません。

報告書が「今後は十分に注意します」で終わる。顧客や上司に出す報告書の再発防止欄に「確認を徹底します」「ダブルチェックを行います」と書いて締める。この文言は何の仕組みも変えていないので、注意力が薄れる数か月後に同じ穴に落ちます。

個人の責任にして構造を直さない。「あの人がテストを飛ばしたから」で片付けると、テストが飛ばせてしまう構造(リリース手順にテストのゲートがない、締め切り圧力で省略が黙認される)はそのまま残ります。次は別の人が同じ省略をします。

記録が残らず、数年後に同じ穴に落ちる。小規模チームの保守は「同じ人がずっと対応する」からこそ、記録がなくても当面は回ってしまいます。しかしその人の記憶は数年で薄れ、退職や交代で消えます。「このエラー、前にも見た気がするが対処を思い出せない」は、記録があれば10分で済んだ調査を丸一日に変えます。

いずれも能力の問題ではなく、振り返りが業務として定義されていないことの帰結です。だからこそ、型(テンプレートと実施基準)を先に決めておく価値があります。

3. ポストモーテムとは ── SREの型を小規模保守に翻訳する

ポストモーテム(postmortem)は、インシデントの記録として、影響・根本原因・対応の時系列・再発防止アクションを文書化する振り返りの型で、GoogleのSRE(Site Reliability Engineering)の実践を通じて広く定着しました。その中核がblameless(非難しない)の原則です。「非難なく書かれたポストモーテムは、関係者全員が善意で、その時点で持っていた情報に基づいて正しく行動したと仮定する」──人を罰する代わりに、正しい行動を妨げた仕組みの側を直します。¹

この考え方はGoogle固有のものではなく、Microsoftのアーキテクチャガイダンス(Azure Well-Architected Framework)でも、ポストモーテムは「関係チーム全員が参加する、構造化された非難なきレビュー」と定義され、根本原因分析(RCA)の結果を対応プロセスの改善・検知(可観測性)の強化・設計の改善という形でシステムに還元することが推奨されています。²

「うちは大規模Webじゃないから関係ない」と思われがちですが、筆者は逆だと考えています。客先常駐なしの少人数でデスクトップアプリを保守する体制にこそ、ポストモーテムは効きます。理由は3つあります。

1. 同じ人が対応し続けるため、記録がないと完全に属人化する。大きな組織なら誰かが覚えていますが、2〜3人のチームでは「覚えている人」が唯一のデータベースです。ポストモーテムはその外部記憶になります。
2. 障害の間隔が長い。Webサービスと違い、業務アプリの重大障害は年に数回です。前回の対応の記憶が薄れた頃に次が来るので、記録の価値が相対的に高くなります。
3. 現場に行けない分、証拠と記録が生命線になる。リモート保守では「そのとき何が起きていたか」を後から再構成する能力がすべてで、これはポストモーテムの時系列記録と地続きです。

なお、ポストモーテムを書く対象の目安として、SRE本ではユーザーに見える停止やデータ損失、オンコール(緊急対応)の介入があった場合などが実施基準の例として挙げられています。¹小規模チーム向けの基準は7章で改めて整理します。

4. 最小のポストモーテム・テンプレート

続けるための最重要条件は分量です。初版を1時間で書き切れることを上限に設計した、Markdownのテンプレートを示します。リポジトリの docs/postmortem/ などに日付付きファイルで置き、コードと同じ場所でバージョン管理することを推奨します。

# ポストモーテム: 受注一覧で日付跨ぎのデータが二重表示 (2026-07-15)

- 状態: 完了 / アクション実施中 / 起票のみ
- 作成者: 小村
- 深刻度: 中 (業務は継続できたが手作業の突合が発生)

## 概要 (3行以内)
月次締め処理の実行中に受注一覧を開くと、前日分の伝票が
二重に表示された。表示のみの問題でDB上のデータは正常。

## 影響 (誰が・何が・どれくらい)
- 影響者: 営業事務 3名
- 影響内容: 一覧画面の二重表示。誤って二重出荷しかけた事例 1件
- 期間: 7/15 9:10 ごろ 〜 11:40 (約2時間半)

## 時系列
- 09:10 利用者から「同じ伝票が2行出る」と電話 (検知)
- 09:30 リモートで画面共有、再現条件を確認
- 10:15 暫定対応: 締め処理中は一覧を開かないよう依頼
- 11:40 修正版を配布し復旧を確認

## 直接原因
締め処理が一時テーブルへコピーした行を、一覧クエリが
本テーブルと UNION ALL していた (排他制御なし)。

## 寄与要因
- 締め処理と画面参照の同時実行がテストシナリオになかった
- 一時テーブルの存在が設計書に書かれておらず、画面側の
  改修時に考慮されなかった
- 二重表示を検知する仕組みがなく、発見が利用者頼みだった

## うまくいったこと
- 利用者が操作ログの時刻をメモしていて再現条件の特定が早かった
- 配布の仕組みが自動化されており修正版を即日展開できた

## 再発防止アクション (担当と期限)
- [ ] 一覧クエリに重複検知アサーションを追加 (小村, 7/22)
- [ ] 締め処理と参照系の同時実行テストを追加 (小村, 7/29)
- [ ] 一時テーブル方式を廃止しスナップショット分離を検討 (小村, 8月末に方針)

そのまま複製して使えるよう、記入前の空テンプレートも置いておきます。リポジトリに docs/postmortem/_template.md として置き、障害が起きたら日付付きの名前でコピーするのが手軽です。

# ポストモーテム: 一行で現象 (YYYY-MM-DD)

- 状態: 起票のみ / アクション実施中 / 完了
- 作成者:
- 深刻度: 高 / 中 / 低 (そう判断した理由を一言)

## 概要 (3行以内)

## 影響 (誰が・何が・どれくらい)
- 影響者:
- 影響内容:
- 期間: MM/DD HH:MM 〜 HH:MM (約  時間)

## 時系列
- HH:MM  (検知: 誰が・何で気づいたか)
- HH:MM
- HH:MM  (暫定対応)
- HH:MM  (復旧確認)

## 直接原因

## 寄与要因
- (混入を許した条件)
- (見逃した条件)
- (被害を広げた条件)

## うまくいったこと
-

## 再発防止アクション (担当と期限)
- [ ]  (担当, MM/DD)
- [ ]  (担当, MM/DD)

書き方の注意点をいくつか挙げます。

• 「概要」は3行以内。後日この文書を探すのは未来の自分です。検索で見つけたとき3行で内容が分かることが、章立ての美しさより重要です。
• 時系列は事実だけを時刻付きで書く。解釈(〜のはずだった、〜すべきだった)は原因の節に分離します。時系列に解釈が混ざると、後から読んだとき何が起きたのか再構成できなくなります。
• 「うまくいったこと」を必ず書く。振り返りが反省会になるのを防ぎ、偶然うまくいったこと(たまたまログがあった、など)を仕組みに昇格させる入口になります。
• アクションには必ず担当と期限を付ける。担当と期限のないアクションは実行されません。ポストモーテムの実効性は、レビューされること・アクションが追跡されることで決まります。¹

5. 原因分析の実務 ── 直接原因と寄与要因を分ける

テンプレートで原因欄を2つに分けているのには理由があります。

直接原因(direct cause)は、その障害を直接引き起こした技術的な事象です。「NULLチェック漏れで例外」「排他制御のないUNION ALL」。修正パッチが直すのはここです。

寄与要因(contributing factors)は、直接原因の混入・見逃し・被害拡大を許した条件です。「そのケースのテストがなかった」「設計書に書かれていなかった」「検知が利用者頼みだった」。再発防止策の主戦場はこちらで、通常は複数あります。

分ける理由は単純で、直接原因だけ直しても寄与要因が残っていれば、別の直接原因が同じ経路で入ってくるからです。冒頭の「同じエラーが別の画面で」はまさにこれです。

5.1 なぜなぜ分析は「人の行動」で止めない

原因を掘る道具として「なぜなぜ分析(5 Whys)」は有効ですが、掘る方向を誤ると犯人探しの道具になります。典型的な失敗は、「なぜ→担当者が確認を忘れたから」で止めてしまうことです。そこで止めず、もう一段掘ります。

• なぜ確認を忘れられたのか → 確認が手順書にもチェックリストにもなく、記憶頼みだったから
• なぜ記憶頼みだったのか → リリース手順が文書化されておらず、毎回その場で組み立てていたから

人の行動が答えに出てきたら、それは終点ではなく「仕組みを問う次の質問」の入口です。人は必ず間違えるという前提に立つと、掘るべき質問は「なぜ間違えたか」ではなく「なぜ間違いがそのまま本番に届いたか」に変わります。

5.2 証拠がなければ分析は始まらない

原因分析の質は、障害発生時に残っていた証拠の質で上限が決まります。時系列を再構成できないポストモーテムは推測の作文になります。Windowsアプリの保守なら、最低限の布陣は次の3つです。

• クラッシュダンプ: WER LocalDumpsを仕込んでおけば、利用者に操作してもらわなくても異常終了時のダンプが残ります。設定方法は「Windowsクラッシュダンプ収集入門」、読み方は「WinDbg + SOSでクラッシュダンプを読む」で解説しています。
• アプリログ: 時刻・相関できるID・クリティカルイベントの同期書き込み。クラッシュ時にもログを確実に残す設計は「Windowsアプリのクラッシュ時にログとダンプを残す設計」を参照してください。
• イベントログ: 自前ログが壊れていても、OS標準のイベントログにはアプリのクラッシュ記録(Application Error)が残ります。活用方法は「Windowsイベントログ・ETW入門」にまとめています。

ポストモーテムを書いてみて時系列が埋まらなかったら、それ自体が「検知と記録の仕組みが足りない」という寄与要因であり、再発防止アクションの候補です。

6. 再発防止策の質 ── 強度の判断表

再発防止アクションを書き出したら、その強度を判定します。判断の軸は「人の注意力にどれだけ依存しているか」です。

このとき現実的なルールは、「弱い対策を禁止する」ではなく「弱い対策で終わらせない」ことです。周知は即日できる暫定対応として意味がありますが、恒久対策の欄に書いてよいのは中以上、可能なら強の対策です。

弱い対策しか出てこないときは、次の問いで問い直します。

• 「新しく入った人が同じ状況に置かれても、この障害は起きないか?」──ノーなら仕組みになっていません。
• 「この間違いを、コンパイラ・テスト・CIのどれかに検知させられないか?」──たとえば「終了時に例外を握りつぶしていた」なら、周知ではなく「想定外の例外で終了するか継続するかの判断表」で整理したような方針をコードの共通例外ハンドラとして実装する、が強い対策です。
• 「間違えられないようにできないか? 間違いに早く気づけるようにできないか?」──防止が高コストなら検知(監視・アラート・突合バッチ)に倒すのも立派な強い対策です。障害の教訓を検知の強化と設計の改善に還元するという整理は、Microsoftのガイダンスでも同じ構図で推奨されています。²

強い対策は工数がかかるため、「今週やる中程度の対策」と「来月やる強い対策」を両方アクションに載せ、期限で管理するのが実務的です。

7. どの障害にやるか ── 実施のトリアージ

フルのポストモーテムを全障害に義務付けると、3か月で誰も書かなくなります。影響度×再発可能性で実施レベルを決めます。

運用のポイントは3つです。

• 「同種の障害の再発」は影響度に関係なく1ランク上げる。再発した時点で、前回の対策が仕組みになっていなかった証拠だからです。
• 軽微でも記録だけは必ず残す。1段落でかまいません。「日付・現象・原因・対処」の4点があれば、数年後の自分が検索で救われます。小さな障害の記録が溜まると「この画面だけ障害が多い」という構造的な偏りも見えてきます。
• 迷ったら書く側に倒す、ただし分量は落とす。フルか否かで迷う時間があったら、簡易版を書き始めた方が早く終わります。

7.1 「構造的」をどう判定するか

表の横軸「再発しやすい/構造的」は、判断基準を決めておかないと使えません。次のどれか1つでも当てはまったら構造的として扱う、というくらい単純な目安にしておくのが実務的です。

• 同じ画面・同じモジュールで2回目。時期が離れていても、同じ場所で2回起きたら偶然ではありません。
• 原因の「型」が過去の障害と同じ。NULLチェック漏れ、排他制御の抜け、日付境界の扱い。場所が違っても同型なら、その型がまだ塞がれていない証拠です。
• その障害を再現するテストが書けない/書いても回っていない。検知の網に構造的な穴がある状態なので、次も素通りします。
• 「決められた順番で操作すれば起きない」類の障害。運用手順に依存しているものは、人が変われば再発します。
• 同じコードが他の顧客・他の環境でも動いている。影響範囲が今回の1件で終わらないため、扱いを1段上げます。

逆に「一過性」と言い切ってよいのは、原因が外部要因(特定のハードウェア故障、依存サービスの一時的な障害)に閉じていて、かつ自社側の設計・手順に穴が見つからなかった場合だけです。迷ったら構造的に倒します。過剰に書いて困ることはほとんどありません。

7.2 レビュー会(30分)の進め方

影響大の障害で行うレビュー会は、時間を決めて型どおりに回すのがコツです。

• 参加者は3〜5人。対応した本人、同じコードを触る可能性のある他のメンバー、顧客窓口を担当する人。責任の判断をする立場の人は入れません。入れた瞬間に発言が防御的になり、寄与要因が出てこなくなります。必要なら結果の共有で足ります。
• 初版を事前に配る。その場で書き始めないこと。とはいえ全員が読んでくる前提は崩れるので、冒頭に読む時間を組み込んでおきます。
• 30分の配分。(1) 0〜5分: 各自が黙って読む (2) 5〜10分: 時系列の事実確認。認識のずれや抜けている時刻を埋める (3) 10〜20分: 寄与要因の追加。ここが本番 (4) 20〜28分: アクションの強度判定(6章の表)と担当・期限の確定 (5) 28〜30分: 次に進捗を確認する日を決める。
• 確認する観点は2つだけ。「他にどこで気づけたか」と「同じ穴が他の場所にないか」。この2問を全員に振ると、対応した本人だけでは出てこない寄与要因が出ます。
• 進行役は対応した本人以外が務める。個人名が主語の発言が出たら、進行役が仕組みの主語に置き換えます。「Aさんが確認を忘れた」→「確認が手順に入っていなかった」。この言い換えを機械的にやるだけで、場の空気は変わります。
• 未確定のアクションを残さない。その場で決められないものは、「◯月◯日までに方針を決める」というアクションに変えて期限を付けて閉じます。

7.3 障害管理簿をどこに置くか

ここまで何度か出てきた「障害管理簿」は、専用ツールを買う話ではありません。満たすべき要件は3つだけです。数年後に全文検索できること、障害1件が1行として増えること、チーム全員が書けること。これを満たせば形式は問いません。

列は「日付 / システム・画面 / 現象 / 影響度 / 直接原因 / 対処 / ポストモーテムへのリンク / 再発かどうか」があれば十分です。大事なのはツールではなく、軽微な障害でも必ず1行増えることと、数年後に「同じ現象」で検索できることの2点です。チャットのスレッドとメールだけで済ませている状態は、この2つをどちらも満たしません。

8. 受託開発での扱い ── 顧客向け障害報告書との関係

受託や保守契約では、障害の後に顧客から「障害報告書」を求められます。このときポストモーテムと報告書の関係を整理しておくと、二度手間を防げます。

内容の8割は転用できます。概要・影響・時系列・直接原因・再発防止策は、顧客向け報告書の構成要素そのものです。先に内部用ポストモーテムを書き、そこから顧客向けに編集する順序にすると、報告書のためだけの作文がなくなります。

ただし、目的が違う2つの文書であることは意識して分けます。

8.1 実際にどう書き換わるか

抽象的だと分かりにくいので、4章のテンプレート例をそのまま使って、内部の記述が顧客向けにどう変わるかを並べます。

書き換えの原則は3つです。

• 技術用語は業務の言葉に翻訳する。ただし事実は薄めない。「UNION ALL」「アサーション」は、顧客の担当者がその上司に説明できる言葉に置き換えます。一方で「表示のみでデータは正常」のような、影響範囲を確定させる情報は必ず残します。ここを曖昧にすると、かえって問い合わせが増えます。
• 社内の手順不備も、事実としては書く。「設計書に記載がなかった」を消すと、再発防止策の理由が消え、「なぜそれで直るのか」が伝わらなくなります。表現を丁寧にするのであって、なかったことにはしません。
• 担当者名は落とし、期日は残す。社内の担当者名は顧客向けには不要です。逆に実施予定日は約束として残し、完了したら報告します。

分ける最大の理由は、責任追及・補償の議論と、再発防止の議論を混ぜると両方が歪むからです。責任問題が絡む文書では、関係者はどうしても防御的に書きます。防御的な文書からは寄与要因が消え、再発防止が「注意します」に退化します。逆に、率直な内部ポストモーテムをそのまま顧客に出すと、文脈のない箇所が独り歩きすることがあります。「率直に書く内部文書」と「正確に伝える外部文書」を分け、前者から後者を作る一方通行にするのが安全です。

なお、顧客向け報告書に実施予定の再発防止策を書いたら、それは顧客との約束です。ポストモーテムのアクション欄と同じ仕組みで期限管理し、完了したら報告する。この一往復が、障害をむしろ信頼を積む機会に変えます。

9. まとめ

• 障害対応は復旧で終わりではありません。復旧・原因究明・再発防止は別の作業として、振り返り(ポストモーテム)を業務に組み込みます。
• ポストモーテムはblameless(非難しない)が原則です。人を責めると情報が出なくなり、原因にたどり着けません。人の行動で分析を止めず、仕組みの穴(寄与要因)まで掘ります。¹
• 文書は1時間で書ける最小テンプレート(概要・影響・時系列・直接原因・寄与要因・うまくいったこと・担当と期限付きアクション)で十分です。時系列を埋める前提として、クラッシュダンプ・ログ・イベントログの証拠保全を先に仕込みます。
• 再発防止策は「気をつける」(弱)ではなく、手順書(中)、できればテスト・アサーション・監視・設計変更で機械的に防ぐ(強)へ引き上げます。教訓を検知と設計に還元する構図は、SRE・Microsoft双方のガイダンスに共通しています。¹²
• 全障害にフル実施はしない。影響度×再発可能性でトリアージし、軽微なものも1段落の記録だけは必ず残します。
• 受託開発では、内部ポストモーテムを先に書き、顧客向け障害報告書はそこから編集します。責任・補償の文書と再発防止の文書を分けることが、双方の品質を守ります。

関連記事

• Windowsクラッシュダンプ収集入門 - WER/ProcDump/WinDbg
• WinDbg + SOSでクラッシュダンプを読む ── 収集した後の実務解析入門
• Windowsアプリのクラッシュ時にログとダンプを残す設計
• Windowsイベントログ・ETW入門 ── 業務アプリのログをOS標準の仕組みに乗せる
• 例外のcatch・ログ・エラー処理の実務
• 想定外の例外で終了するか継続するかの判断表

関連する相談領域

合同会社小村ソフトでは、再現困難な不具合の調査・原因解析から、証拠保全(ログ・ダンプ収集)の仕組みづくり、再発防止を含む保守運用体制の整理までを扱っています。「同じ障害が繰り返されている」「障害報告書の再発防止策が形骸化している」といった段階からのご相談も歓迎します。

• 不具合調査・原因解析
• 既存Windowsソフトの改修・保守
• 技術相談・設計レビュー
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

ポストモーテムとは何ですか？障害報告書とは違うのですか？

ポストモーテムは、障害の復旧後に行う構造化された振り返りの文書と活動のことで、SRE(Site Reliability Engineering)の分野で定着した手法です。個人を責めない(blameless)ことを前提に、時系列・直接原因・寄与要因・再発防止アクションを記録します。顧客向けの障害報告書が「何が起きて、どう対処したか」の説明責任を果たす文書であるのに対し、ポストモーテムは「次に同じことを起こさないために仕組みをどう変えるか」を決めるための内部文書です。ただし内容の大部分は重なるため、ポストモーテムを先に書き、そこから顧客向け報告書を編集して作る運用が効率的です。

再発防止策が「今後は十分に注意します」ばかりになってしまいます。どうすればよいですか？

「注意する・周知する」は人の記憶と善意に依存するため、時間経過と担当者交代で確実に効果が消えます。対策を考えるときは「新しく入った人が同じ状況に置かれても、この障害は起きないか」と問い直してください。答えがノーなら仕組みになっていません。強い対策は、テスト・アサーション・型や設計による制約・監視アラートなど、人が注意しなくても機械的に検知・防止されるものです。すぐに強い対策が打てない場合は、チェックリストや手順書を中間段階として置き、恒久対策を期限付きのアクションとして記録します。

少人数の受託開発で、全部の障害にポストモーテムを書く余裕がありません。

全障害にフルのポストモーテムを書く必要はありませんし、書こうとすると制度自体が続きません。影響度と再発可能性で実施をトリアージし、業務停止やデータ破損を伴う障害、同種の障害の再発時にはフル実施、軽微なものは障害管理簿に1段落の記録だけ残す、という濃淡を付けます。重要なのは「軽微でも記録は必ず残す」ことで、数年後に同じ現象が起きたとき、過去の記録が検索できるかどうかで調査時間が大きく変わります。

犯人探しをしない(blameless)というのは、責任をうやむやにすることではないのですか？

違います。blamelessは「誰がミスしたか」ではなく「なぜその人がミスできてしまう仕組みだったか」に焦点を移すための原則です。オペレーターが操作を間違えたなら、間違えられるUIや手順に寄与要因があります。個人を処罰する組織では、次の障害で情報が隠され、原因にたどり着けなくなります。一方で、顧客への説明責任(何が起き、どう補償するか)は別の文書・別のプロセスとして果たすべきもので、blamelessな振り返りと矛盾しません。責任追及の文書と再発防止の文書を分けることが実務上のポイントです。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。