障害報告書の書き方【経営者向け】技術ログをそのまま出すと信頼を失う理由
TL;DR
システム障害の後で経営者や顧客の信頼を左右するのは、復旧の速さより「報告書の質」です。技術者がやりがちな失敗は、生のログやエラーメッセージをそのまま貼り付けてしまうこと ―― 読む側は技術用語を判断できず、不安だけが残ります。
- 報告書のゴールは「技術の説明」ではなく「相手の不安を消すこと」。読み手は原因の詳細でなく「もう大丈夫か」「いくら損したか」「次は防げるか」を知りたい
- 必須は6要素：①発生〜復旧の日時 ②影響範囲 ③原因 ④実施した対応 ⑤再発防止策 ⑥謝辞・お詫び
- 原因は「誰のせい」でなく「仕組みのどこが弱かったか」で書く（非難なしポストモーテム）。個人を責める報告書は再発を防げない
- 顧客向けと社内向けは別物。顧客向けは影響と再発防止に寄せ、社内向けは原因の深掘りと改善タスクに寄せる
なぜ技術ログをそのまま出すと信頼を失うのか
障害対応を終えた直後、エンジニアの手元には大量の一次情報があります。エラーログ、スタックトレース、監視のアラート履歴、復旧コマンドの記録。これをそのまま整形して「報告書です」と提出してしまう ―― これが信頼を失う典型パターンです。
理由は3つあります。
- 読み手が判断できない：経営者は
OOMKilledやconnection pool exhaustedを見ても、それが「致命的」なのか「よくあること」なのか判断できません。情報量が多いのに、肝心の「で、ヤバいの？」が伝わらない - 不安だけが増幅する：理解できない専門用語が並ぶほど、読む側は「何かとんでもないことが起きた」と感じます。事実は同じでも、伝え方で不安は何倍にもなる
- 再発防止が見えない：ログは「何が起きたか」を語りますが、「次は防げるのか」を語りません。経営者が一番知りたいのはここです
報告書は技術の正しさを証明する文書ではなく、相手の意思決定と安心のための文書です。読み手が誰で、その人が何を判断したいのかを起点に書き直す必要があります。
障害報告書の必須6要素
媒体や規模が違っても、押さえるべき骨格は共通です。次の6つが揃っていれば、報告書として最低限機能します。
| 要素 | 書く内容 | 読み手が知りたいこと |
|---|---|---|
| ①発生・復旧日時 | 検知時刻／影響開始〜復旧の時刻 | いつ・どれくらい止まったか |
| ②影響範囲 | 影響を受けた機能・ユーザー・件数 | 自分（顧客）は影響を受けたか |
| ③原因 | 直接原因と背景要因（仕組みの言葉で） | なぜ起きたか |
| ④実施した対応 | 検知から復旧までにやったこと | ちゃんと対処されたか |
| ⑤再発防止策 | 具体的な改善とその期限 | 次は防げるのか |
| ⑥謝辞・お詫び | 影響への謝意・お詫び | 誠実に向き合っているか |
このうち、技術者が薄くしがちなのが ②影響範囲 と ⑤再発防止策 です。原因（③）と対応（④）は書けるのに、「で、誰にどれだけ迷惑がかかって、次どう防ぐのか」が一行で終わってしまう。読み手の関心はむしろ②と⑤にあります。
タイムラインの書き方
障害報告書の核は時系列（タイムライン）です。「いつ検知し、いつ何をして、いつ復旧したか」を時刻つきで並べると、対応が後手だったのか適切だったのかが一目で伝わります。
書き方のルール
- 時刻は具体的に：「夕方ごろ」ではなく「18:42」。曖昧な時刻は対応の遅れを隠しているように見える
- 検知のきっかけを書く：監視アラートで気づいたのか、顧客からの連絡で気づいたのか。後者が多いと「監視が機能していない」というサインになる
- 判断と行動を分けて書く：「原因をAと推定し（判断）、設定をBに戻した（行動）」のように、なぜその対応をしたのかが追えるようにする
- 復旧の定義を明示する：「サービス再開」と「完全復旧」は違うことがある。部分復旧→全復旧の段階があれば分けて書く
タイムラインの例
| 時刻 | 出来事 |
|---|---|
| 18:42 | 監視アラートでレスポンス遅延を検知 |
| 18:50 | 一次調査開始。特定機能でエラー率上昇を確認 |
| 19:05 | 直近の設定変更が原因と推定 |
| 19:12 | 設定を変更前の状態へ戻す |
| 19:20 | エラー率が正常域に回復。経過観察開始 |
| 19:45 | 全機能の正常動作を確認し、復旧を宣言 |
検知から復旧まで何分かかったか、その間に何をしていたかが、表だけで伝わります。これが文章だけだと「だいぶ頑張った」程度の印象しか残りません。
原因は「誰のせい」でなく「仕組み」で書く
障害報告で最もやってはいけないのが、個人を犯人にすることです。「担当者が誤った設定を投入したため」と書いた瞬間、報告書は再発防止の文書から責任追及の文書に変わります。
なぜ非難を避けるのか（非難なしポストモーテム）
人を責める報告書には2つの害があります。
- 再発を防げない：「Aさんが間違えた」が結論だと、対策は「気をつける」しかなくなります。同じミスは別の人が必ずまたやります
- 次から事実が隠れる：個人が罰せられる文化だと、現場は障害や失敗を報告しなくなります。情報が上がらなくなれば、もっと大きな事故につながる
代わりに問うべきは 「なぜ一人のミスがサービス停止まで通ってしまったのか」 です。原因はたいてい個人でなく仕組みにあります。
| 個人を責める書き方（NG） | 仕組みで書く（OK） |
|---|---|
| 担当者が誤った設定を投入した | 設定変更を検証する仕組み（レビュー・検証環境）が無く、誤りが本番に直接反映された |
| 確認を怠った | 変更前に第三者が確認する手順が定義されていなかった |
| 気づくのが遅れた | 該当の異常を検知する監視項目が設定されていなかった |
右側で書けば、対策は「設定変更にレビューを必須化する」「検証環境を用意する」「監視項目を追加する」と、具体的な改善に直結します。
再発防止策は「具体性」がすべて
再発防止策が「再発防止に努めます」「チェック体制を強化します」で終わっている報告書は、何も約束していないのと同じです。読み手はそこに誠実さの欠如を読み取ります。
具体的な再発防止策には、次の3つが入っています。
- 何をするか（行動）：抽象語でなく、実際に変える手順・設定・仕組み
- いつまでにやるか（期限）：「速やかに」ではなく日付。期限のない対策は実行されない
- 誰が確認するか（責任）：実施したかを誰がいつ確認するか
| 弱い再発防止策 | 強い再発防止策 |
|---|---|
| チェック体制を強化します | 本番への設定変更時に、第三者レビューを必須とする運用ルールを定める（◯月末まで） |
| 監視を改善します | 今回検知できなかった指標の監視アラートを追加し、閾値を設定する（◯月◯日まで） |
| 再発防止に努めます | 設定変更を検証環境で事前テストする手順を整備し、手順書に明記する（◯月末まで） |
すべての項目に期限を入れることを強くおすすめします。期限のない約束は、読み手にも「結局やらないのでは」と伝わります。
顧客向けと社内向けの書き分け
同じ障害でも、読み手が違えば報告書は別物になります。1枚で兼用しようとすると、どちらの読み手にも刺さらない中途半端な文書になります。
| 項目 | 顧客向け | 社内向け |
|---|---|---|
| 主目的 | 不安の解消・信頼の維持 | 原因の深掘り・改善の実行 |
| 原因の粒度 | 概要レベル（仕組みの言葉で簡潔に） | 技術的な詳細・背景要因まで |
| 強調する箇所 | ②影響範囲・⑤再発防止・⑥お詫び | ③原因・⑤改善タスクと担当・期限 |
| トーン | 丁寧・誠実・簡潔 | 率直・非難なし・事実ベース |
| 技術用語 | 最小限（必要なら平易に言い換え） | そのまま使ってよい |
顧客向けで気をつけること
- 過度に詳細な原因を書かない：「設定の不備」程度で十分。内部構造を細かく出すとセキュリティ上の懸念にもなる
- 影響を正直に書く：影響を小さく見せようとすると、後から発覚したときに二重に信頼を失う
- お詫びと再発防止をセットにする：謝るだけ、対策を述べるだけ、ではなく両方を揃える
社内向けで気をつけること
- 改善タスクを担当・期限つきで残す：報告書を「振り返り」で終わらせず、実行可能なタスクに変換する
- 非難なしの原則を社内でも守る：社内向けこそ個人攻撃に流れやすい。仕組みの言葉で書く文化を作る
穴埋めテンプレート（顧客向け）
そのまま埋めれば形になる骨格です。読み手が顧客であることを意識し、簡潔に書きます。
件名：【障害のご報告とお詫び】◯◯サービスの一時的なご利用障害について
平素より◯◯をご利用いただきありがとうございます。
下記のとおりサービス障害が発生いたしましたので、ご報告いたします。
■ 発生状況
発生日時：YYYY年MM月DD日 HH:MM 〜 HH:MM（約◯分間）
影響範囲：[影響を受けた機能・対象ユーザー]
事象：[利用者から見て何ができなかったか]
■ 原因
[仕組みの言葉で簡潔に。個人を犯人にしない]
■ 対応
[検知から復旧までに実施したことを簡潔に]
現在は正常に復旧しており、サービスは通常どおりご利用いただけます。
■ 再発防止策
[具体的な改善内容]（◯月末までに実施予定）
このたびはご迷惑をおかけし、深くお詫び申し上げます。
再発防止に努めてまいりますので、引き続きよろしくお願いいたします。まとめ
| 場面 | やること | 理由 |
|---|---|---|
| 報告書の起点 | 読み手が何を判断したいかから書く | ログの整形は報告書ではない |
| 必須要素 | 日時・影響・原因・対応・再発防止・お詫びの6点 | 抜けると「で、どうなの？」が残る |
| タイムライン | 時刻つきで判断と行動を並べる | 対応の適切さが一目で伝わる |
| 原因の書き方 | 個人でなく仕組みの弱さで書く | 非難は再発を防げず事実を隠す |
| 再発防止策 | 行動・期限・責任を入れる | 期限のない約束は実行されない |
| 書き分け | 顧客向けと社内向けを分ける | 兼用はどちらにも刺さらない |
障害報告書は技術力でなく報告の作法で評価されます。生のログを出さず、読み手の不安を起点に、仕組みの言葉で原因を語り、期限つきの再発防止を約束する ―― これだけで、同じ障害でも「任せて大丈夫」と思われる報告に変わります。