障害対応が終わって、ほっとしたのも束の間。
「報告書、明日までにお願いします」
このやり取り、運用保守をやっていれば何度も経験すると思います。
正直に告白します。私も若いころは、障害報告書が苦手でした。
何を書けばいいかわからない。書いても顧客から質問が返ってくる。書き直しになる。そのたびに「対応は完璧だったのに、なぜ報告書でつまずくんだ」と思っていました。
でも、19年やってきて気づいたことがあります。
障害報告書は、技術文書ではありません。信頼を回復するための文書です。
ここを理解してから、書き方が変わりました。今回は、現場リーダーとして100件以上の報告書を書き、レビューしてきた立場から、実務で使える書き方をまとめます。
そもそも、障害報告書は誰のために書くのか
書き方の前に、これを押さえておく必要があります。
障害報告書を読むのは、たいてい顧客の情報システム部門の担当者です。でも、本当の読み手はその先にいます。
その担当者は、報告書を受け取ったあと、自分の上長や事業部門に説明しなければならないからです。
つまり報告書は、「担当者が社内で説明するための材料」でもあります。
ここに気づくと、書くべきことが変わります。
技術的に正確なだけの報告書は、担当者が社内で説明できません。専門用語だらけの原因分析を渡されても、上長には伝わらない。結果、「これ、どういうことですか」と質問が返ってくる。
質問が返ってくる報告書は、読み手が説明できない報告書です。
障害報告書に必要な6つの項目
構成は、この6つを押さえておけば大きく外しません。
1. 障害の概要
いつ、何が、どうなったか。3〜4行で完結させます。
ここだけ読めば全体がわかる、というレベルにするのがポイントです。忙しい人は、ここしか読みません。
2. 影響範囲
これが顧客にとって一番知りたい部分です。
- どのシステム・サービスが止まったか
- 何人・どの部署が影響を受けたか
- 業務にどんな支障が出たか
- データの欠損はあったか
「影響なし」で済ませないこと。影響がなかったなら、なぜなかったのかまで書きます。
3. 時系列（タイムライン）
発生から復旧までを、時刻付きで並べます。
14:32 監視アラート検知
14:35 一次対応開始、事象を確認
14:50 原因を特定
15:10 復旧作業を実施
15:25 サービス復旧を確認
15:40 顧客へ復旧報告検知から対応開始までの時間は、必ず見られます。ここが空いていると「なぜすぐ動かなかったのか」と聞かれるので、待機時間があったならその理由も書きます。
4. 原因
直接的な原因と、その背景を分けて書きます。
- 直接原因：何が引き金になったか
- 根本原因：なぜそれが起きたのか、なぜ防げなかったのか
ここを混同すると、再発防止策がずれます。
5. 復旧措置
実際にやったことを、事実として書きます。
6. 再発防止策
一番重視される項目です。詳しくは後述します。
書き方のコツ①：事実と推測を、はっきり分ける
これが一番大事かもしれません。
障害報告書では、確定していることと、していないことを混ぜてはいけません。
やりがちなのが、原因が完全には特定できていないのに、断定的に書いてしまうこと。あとで違うことがわかったとき、報告書ごと信頼を失います。
書き分け方
- 確定：「〜が原因でした」
- 推定：「〜が原因と推定されます。現在、〜の観点から調査を継続しています」
- 不明：「現時点では原因を特定できていません。〜の手順で調査を進めます」
わからないことを「わからない」と書くのは、逃げではありません。むしろ誠実さとして伝わります。
私の経験上、顧客が本当に怒るのは「わからない」と言われたときではなく、あとから話が変わったときです。
書き方のコツ②：再発防止策は「実行できること」だけ書く
再発防止策で、よくある失敗があります。
「監視を強化します」「手順を見直します」
これでは通りません。曖昧すぎて、何をするのかわからないからです。
そして、もう一つの落とし穴があります。書いた再発防止策は、実行を確認されます。
つまり、その場をしのぐために大げさなことを書くと、あとで自分の首が締まります。
書くべき再発防止策の条件
- 具体的である（誰が、いつまでに、何をするか）
- 実行可能である（コスト・工数・体制的に本当にできるか）
- 原因に対応している（根本原因を潰せているか）
良い例
監視設定に〇〇のしきい値アラートを追加する（担当：〇〇／〇月〇日まで）
作業手順書に事前確認項目として〇〇を追加し、次回作業から適用する（担当：〇〇／完了済み）
避けたい例
監視を強化します 再発しないよう、注意して作業します
「注意します」は再発防止策ではありません。人の注意力に頼る対策は、必ず再発します。
書き方のコツ③：謝罪と原因説明を、混ぜない
これは書き方の技術というより、心構えの話です。
障害を起こしたときは、当然、申し訳ない気持ちになります。でもその気持ちが強すぎると、報告書が謝罪文になってしまいます。
謝罪ばかりの報告書は、実は顧客にとって役に立ちません。**顧客が知りたいのは、謝罪ではなく「次は大丈夫なのか」**だからです。
構成としては
- 冒頭で、簡潔に謝罪する（数行）
- 本文は、事実と分析に徹する
- 再発防止策で、「次は大丈夫」を示す
謝罪は最初に一度。あとは淡々と書く。これが結果的に、一番信頼を回復します。
やりがちな失敗3つ
レビューしていて、よく見かけるパターンです。
1. 専門用語をそのまま使う
「NICのリンクダウンによりクラスタのフェイルオーバーが発生」——これ、情シス担当者は理解できても、その上長には伝わりません。
技術的な正確さは保ちつつ、一文添えるだけで変わります。「（サーバー間の通信が切れ、待機系への切り替えが発生しました）」
2. 時系列が粗すぎる
「14時ごろ発生、15時ごろ復旧」では、対応の妥当性が評価できません。
分単位で書く。それが記録として残っていない場合は、次回から記録する仕組みを作る必要があります。
3. 自社に都合よく書く
これは絶対にやめたほうがいいです。
対応が遅れたなら、遅れたと書く。判断を誤ったなら、誤ったと書く。隠したことは、たいてい後でバレます。そしてバレたときの損失は、正直に書いた場合よりはるかに大きい。
正直に書いて怒られるのは一度きり。隠して発覚したら、信頼は戻りません。
リーダーとして、レビューで見ているところ
メンバーが書いた報告書をレビューするとき、私が見ているのは主に3点です。
1. 顧客の担当者が、そのまま社内展開できるか
読み手のさらに先を想像できているか。ここが一番重要です。
2. 再発防止策が、本当に実行できるか
書いた本人が実行するとは限りません。チームとして回せる内容になっているかを見ます。
3. 事実と推測が分かれているか
断定しすぎていないか、逆に曖昧にしすぎていないか。ここのバランスを確認します。
まとめ
障害報告書の書き方をまとめます。
必要な6項目
- 障害の概要（3〜4行で完結）
- 影響範囲（顧客が一番知りたい）
- 時系列（分単位で、検知から復旧まで）
- 原因（直接原因と根本原因を分ける）
- 復旧措置
- 再発防止策
書き方のコツ
- 事実と推測を、はっきり分ける
- 再発防止策は「実行できること」だけ書く
- 謝罪と原因説明を、混ぜない
やりがちな失敗
- 専門用語をそのまま使う
- 時系列が粗すぎる
- 自社に都合よく書く
障害報告書は、面倒な事務作業に見えるかもしれません。
でも実際は、障害で下がった信頼を、もう一度積み直すための文書です。ここを丁寧にやるかどうかで、その後の関係がまったく変わります。
次に報告書を書くとき、まずは「この報告書を受け取った担当者は、これで社内に説明できるか」と考えてみてください。それだけで、書く内容が変わってくるはずです。
コメント