サーバ200台の現場で学んだ「通る報告書」の鉄則〜マネージャーが本当に求めている3つの情報〜

「復旧作業でヘトヘトなのに、やっと出した報告書が『これじゃわからない』と突き返された……」 「結局、何が悪かったの？と聞かれて言葉に詰まってしまった……」

インフラエンジニアなら、一度はこんな経験があるのではないでしょうか。

こんにちは、もっちです。私は現在、大手SIerで約200台のサーバを支えるインフラ運用リーダーをしています。18年のキャリアの中で、数えきれないほどの障害報告書を書き、そして現在はマネージャーとして、多くの報告書を「チェックする側」にいます。

その経験から断言できることがあります。 報告書で苦労する理由は、文章力ではなく「情報の整理の仕方」にあります。

今回は、管理職が一発で「わかった、ありがとう」と頷く、プロの報告書の書き分け術を公開します。

報告書の目的を「再定義」しよう

多くのエンジニアは、報告書を「起きたことの記録（または反省文）」だと思っています。しかし、それは大きな誤解です。

マネージャーにとっての報告書は、「その上の役員や顧客に、あなたの代わりに説明し、判断するための武器」です。

私が報告書を受け取るとき、実は最初の5秒で以下の3点（BLUF: Bottom Line Up Front）を探しています。

• 復旧の有無： 今、システムは動いているのか？（RTOとの乖離）
• 影響の範囲： 誰が、何に困っているのか？（ビジネスへの実損）
• 再発の懸念： 今夜、私は安心して寝ていいのか？

これらが冒頭に「概要」としてまとまっていない報告書は、どれだけ技術的に正しくても、マネージャーにとっては「使い物にならない武器」なのです。

最重要：「事実」と「原因」を徹底的に分ける

報告書を突き返される最大の原因は、「事実」と「推測（原因）」が混ざっていることです。

「事実」は誰が見ても疑いようのないデータ

事実は、ログ、エラー画面、発生時刻などです。

例： 10:00にDBサーバーのCPU使用率が100%に達し、サービスが5分間停止した。

「原因」はそこから導き出される論理

原因は、事実を元にした分析です。

例： 特定の集計バッチが無限ループし、リソースを枯渇させた。

なぜ分けるのか？ 事実と推測が混ざると、上司は「それはあなたの思い込みじゃないのか？」と疑念を持ちます。まず「事実」で外堀を埋め、その後に「原因」を置く。この順番が、信頼を勝ち取る鉄則です。

「トリガー」と「ルート原因」を混同しない

200台規模の運用現場で特に重視されるのが、「なぜそれが起きたか」の深掘りです。

• トリガー（引き金）： 「コマンドの打ち間違い」「設定ミス」
• ルート原因（根本原因）： 「本番環境へのアクセス制限が不十分だった」「作業手順書にダブルチェックの項目がなかった」

「担当者がミスをしました」という報告は、マネージャーからすれば「また同じことが起きるな」という恐怖でしかありません。「仕組みのどこに穴があったのか」まで踏み込むのが、プロのインフラエンジニアの仕事です。

【詳細版】そのまま使える！障害報告の基本テンプレートと徹底解説

私が現場で実際に使用し、メンバーにも推奨しているテンプレートの構成です。各項目には、マネージャー視点での「チェックポイント」を添えました。

① 概要（BLUF：結論を最優先）

マネージャーが最初に知りたいのは「今、どういう状況か」だけです。

• 内容： 発生日時、復旧状況、事象を一言で。
• 書き方のコツ： 3行以内でまとめます。例： 2026年1月10日 10:00〜10:15（15分間）、DBサーバの応答遅延により全サービスが停止。現在は暫定対処により完全復旧済み。

② 影響範囲（ビジネスインパクト）

サーバ200台規模になると、1つの障害がどこまで波及したかの特定が最重要です。

• 内容： 影響を受けたシステム名、ユーザー数、停止した機能。
• マネージャーの視点： 「お客様への補償や謝罪が必要なレベルか？」を判断します。「影響は調査中」が最も嫌われるため、不明な場合は「最大で〇〇名の可能性」と、最悪のケースを提示しましょう。

③ 発生経緯（タイムライン：事実に徹する）

ここでは一切の推測を排除し、ログに基づいた「事実」だけを並べます。

• 内容： アラート検知 → 調査開始 → 原因特定 → 復旧作業 → 復旧確認。
• 書き方のコツ： 「〇〇だと思われる」は厳禁です。「〇〇ログに××の記録あり」と、証拠をベースに書きます。

④ 原因分析（トリガーとルート原因）

ここが報告書の「心臓部」です。

• 直接原因（トリガー）： 何が引き金になったか。（例：設定ファイルの記述ミス）
• 根本原因（ルート原因）： なぜそのミスが起きたか。（例：ダブルチェックの項目が不足していた、作業環境の識別が困難だった）
• 解説： 「担当者の不注意」で終わらせず、「仕組みの欠陥」を見つけることがプロの仕事です。

⑤ 対応内容（暫定対処と恒久対策）

「とりあえず直した」だけで終わらせないのが、200台を支えるリーダーの流儀です。

• 暫定対処（止血）： サービスを再開させるために何をしたか。（例：プロセス再起動）
• 恒久対策（根治）： 二度と起こさないために何をするか。（例：設定変更の自動化プログラム導入、監視しきい値の見直し）
• アドバイス： 恒久対策に期限（いつまでに完了するか）を入れると、管理職からの信頼度が格段に上がります。

【比較表】報告書の質を分けるポイント

項目	修正前のよくある書き方	修正後の「通る」書き方
原因	設定を間違えました	手順書に記載がなく、個人の判断で作業した
対策	今後は気をつけます	手順書を修正し、指差し確認の工程を追加する
影響	多くの人に影響が出ました	決済機能を利用中のユーザー約50名に影響
トーン	申し訳ありません（謝罪中心）	次の再発防止は〇〇です（改善中心）

【コピペOK】障害報告書・基本テンプレート

💡 使い方のヒント 各項目の [ ] 内を書き換えて使用してください。不要な項目は削除してOKです。 マネージャーが見るのは「結論」と「仕組みとしての再発防止」です。

1. Markdown形式（GitHub, Backlog, Notion等に）

Markdown

## 1. 障害概要（BLUF）
- **発生日時:** 202X年[ ]月[ ]日 [ ]時[ ]分 〜 [ ]時[ ]分（継続時間: [ ]分）
- **現在の状況:** [完全復旧 / 暫定復旧（監視継続） / 調査中]
- **事象:** [例：DB接続遅延により、サービス画面がタイムアウトした]

## 2. 影響範囲
- **対象システム:** [ ]
- **影響機能:** [例：ログイン、新規登録]
- **推定影響ユーザー数:** 約[ ]名（[ ]％のユーザー）

## 3. 発生経緯（タイムライン）
- [XX:XX] アラート検知（[ ]監視より）
- [XX:XX] 一次調査開始
- [XX:XX] 原因特定（[ ]ログの××を確認）
- [XX:XX] 暫定対処実施（[ ]の再起動）
- [XX:XX] 正常稼働を確認（復旧完了）

## 4. 原因分析
- **直接原因（トリガー）:** [例：手動パッチ適用時のコマンド入力ミス]
- **根本原因（ルート原因）:** [例：手順書にダブルチェックの工程がなかった / 検証環境との識別が困難なターミナル設定だった]

## 5. 対応内容
- **暫定対処（止血）:** [例：プロセスの再起動、旧Verへの切り戻し]
- **恒久対策（根治）:** [例：手順書の改訂(XX/XX締切)、設定変更の自動化プログラムの作成]

2. プレーンテキスト形式（メール、Slack、Teams等に）

Plaintext

【障害報告】[件名を簡潔に記入]

■1. 概要
・発生時刻：202X/XX/XX XX:XX 〜 XX:XX
・復旧状況：復旧済み
・事象：[ここに簡潔に記入]

■2. 影響範囲
・対象：[システム名]
・内容：[サービス停止、一部機能制限など]
・規模：約[ ]件 / [ ]名

■3. 発生経緯
XX:XX アラート検知
XX:XX 調査開始
XX:XX 原因特定、復旧作業開始
XX:XX 復旧確認完了

■4. 原因
・直接原因：[何が起きたか]
・根本原因：[なぜ起きたか（仕組みの不備）]

■5. 今後の対策
・暫定策：[実施済みの内容]
・恒久策：[いつまでに、何をするか]

「テンプレートはあくまで『型』です。大切なのは、これを使って『上司の時間を奪わず、チームの安心を作る』という意識です。最初は時間がかかるかもしれませんが、この型を守ることで、あなたの信頼は着実に積み上がっていきます。」

報告書を「個人の反省文」にしない

2026年現在の運用現場では、「Blameless Post-mortem（非難なき事後検証）」が主流です。

「誰がミスをしたか」を責めるのではなく、「なぜ防げなかったか」をチームで考える。報告書はそのための資料です。むしろ、報告書を通じて「今のチームにはこれだけの技術的負債がある」「リソースが足りない」という現実を上層部に可視化し、改善予算を勝ち取るチャンスに変えてしまいましょう。

まとめ：報告書が書けるエンジニアは「重宝」される

技術力は素晴らしいのに、報告が苦手なために評価を落としている人は本当に多いです。

「事象を正しく、ビジネスの言葉で伝える力」。 これができるようになると、上司からの信頼は劇的に変わり、結果として自分自身の仕事の裁量権（やりやすさ）が増えていきます。

ぜひ、次の障害対応（起きないのが一番ですが！）の際には、この「書き分け術」を試してみてください。

あとがき： 実は私自身、かつては「技術的に正しい説明さえすればいい」と慢心していた時期がありました。そのせいで、大きな障害の際、報告書が書けずに逃げ出したくなったことがあります……。

私の「院卒のプライド」がズタズタになり、そこからどうやってこの考え方に至ったのか。そんな泥臭い裏話は、Noteの方に綴ってみました。

https://note.com/infra_mocchi/n/nc9c249dbe6e0