本番障害が起きたとき、顧客への報告で信頼を失いやすいパターンは2つあります。「事実よりも謝罪が先に来る」と「原因が曖昧なまま再発防止策が並ぶ」です。
障害報告は「謝罪文」ではなく「事実の整理と再発防止の意思表明」です。構成がしっかりしていれば、障害が起きたこと自体よりも「対応と報告の丁寧さ」が評価される場面が多くあります。本記事では、顧客に伝える障害報告書の基本構成と、各パートで意識すべきことを整理します。
障害報告で信頼を落とすパターン
顧客への障害報告でよく見かける失敗例を先に整理します。
謝罪だけで事実が薄い。「この度は多大なるご迷惑をおかけしました」から始まる報告書が、謝罪の文章で埋まっていて「何が起きたのか」が後回しになっています。顧客は謝罪より事実を求めています。
原因が「調査中」のまま提出。速報として「調査中」にすることはあっても、正式な報告書でも原因が「詳細は引き続き調査中」のままでは、顧客は再発防止の見通しを立てられません。
再発防止策が「対応を強化します」だけ。具体性のない再発防止策は、「同じことが起きそうだ」という印象を与えます。何を、いつまでに、誰が対応するのかを書いてください。
影響範囲が曖昧。「一部のユーザーに影響がありました」では、顧客は影響の規模を把握できません。
構成1：発生事象と影響範囲
最初に「何が起きたのか」と「何に影響したのか」を書きます。
事象の記述は、発生日時・発生した機能・現象の内容をできる限り具体的に書きます。「ログイン画面でエラーが発生した」ではなく「5/9 14:32〜15:48 の間、〇〇機能でエラーコード500が返され、ログインが不可能な状態になりました」という形です。
影響範囲は、影響を受けたユーザー数・期間・業務範囲を書きます。「全ユーザー」なのか「特定条件のユーザーのみ」なのか、影響を受けた業務プロセスが何かを明確にしてください。
構成2：暫定対応と現状
次に「現在の状態」を書きます。
障害が復旧しているのであれば、復旧日時と復旧を確認した方法を記載します。まだ暫定対応中であれば、「〇〇の回避策により、主要機能は利用可能な状態です。恒久対応は〇日に完了予定」という形で現状を明確にします。
「現在は正常に動作しています」だけでは、再発リスクへの対応状況が伝わりません。
構成3：原因と再発防止
ここが報告書の核心です。
原因は「直接原因」と「根本原因」を分けて書くのが理想です。直接原因は「〇〇の設定値が誤っていた」「〇〇の処理でNullエラーが発生した」など、技術的な事実です。根本原因は「設定変更時のレビュープロセスがなかった」「リリース前の動作確認で〇〇の条件が検証されていなかった」など、プロセス上の問題です。
再発防止策は、根本原因に対応する形で書きます。「〇〇の設定変更は2名でのレビューを必須とします。完了期限：〇月〇日、担当：〇〇」という形で、具体的な対応内容・期限・担当者を記載してください。
構成4：今後の連絡予定
最後に「この後どうするか」を書きます。
恒久対応が完了した時点での報告、再発防止策の実施確認報告など、次の連絡タイミングを明示します。「引き続き対応に努めます」で終わると、顧客は次にいつ何の連絡が来るかを把握できません。
「〇月〇日に恒久対応完了の報告と、再発防止策の実施状況をご報告します」という一行が、顧客の不安を和らげます。
障害報告書の送付タイミング
障害報告書は、顧客から尋ねられる前に発送するのが原則です。顧客から「報告書はいつ来るのか」と訊かれる状態は、次の展開への不信感を高めます。
報告書の送付期限の目安は、障害発生から24時間以内に初報、72時間以内に続報です。初報は「発生・影響・現在対応中」の3点のみの展開で構いません。続報で原因・再発防止策・次の連絡タイミングを記載する流れが基本です。
報告書の提出が遅れる場合は、必ず事前に顧客へ「現在調査中で、報告書は〇日までに提出します」と伝えてください。何も連絡せずに待たせるより、期限を示してから遅らせる方が、顧客の不安を抑えられます。
障害報告書を送る前のチェックリスト
障害報告書を送る前に、以下の5点を確認してください。
- 発生事象と影響範囲が明確か: 「何が起きて、誰が影響を受けたか」が1〜2文で分かるか
- 直接原因と根本原因が分かれているか: 技術的事実とプロセス問題を混在させていないか
- 再発防止策に期限と担当者が付いているか: 「対応します」で終わっていないか
- 次の連絡タイミングが書いてあるか: 「〇月〇日に恒久対応完了を報告します」という一文があるか
- 顧客側に必要なアクションが書いてあるか: パスワードリセットや特定操作が必要な場合、明記しているか
この5点が揃っていれば、顧客は「状況を把握して対応している」という信頼を持てます。逆に1つでも欠けると、追加質問が届く可能性が高まります。報告書を送る前の5分間のチェックが、その後の信頼回復速度を左右します。
報告時の注意点
障害報告書を作成するときのいくつかの注意点を挙げます。
原因を断定できない段階で断定的な表現を使わない。調査が続いている場合は「〇〇が原因と推定されます。詳細は〇日までに追報します」という表現を使います。断定した後に「調査の結果、原因は別のものでした」となると信頼は二段階落ちます。
顧客側で対応が必要なことがある場合は明記する。パスワードリセットが必要、特定の操作が必要など、顧客側でアクションが必要な場合は明確に記載します。
法的責任に関わる表現は慎重に。障害報告書はビジネス上の信頼回復を目的とするものです。補償や免責に関わる文言は、法務や上司の確認を経てから記載してください。
障害報告後の信頼回復フォロー
障害報告書を送付したあとも、信頼回復には継続的なフォローが必要です。
報告書に記載した再発防止策の実施状況を、完了したタイミングで顧客に報告してください。「言ったままで何もしていない」という印象をなくすことが、障害後の信頼回復の核心です。「〇月〇日に再発防止策のレビュープロセスを導入し、本日から運用を開始しました」という一文の報告が、顧客の安心感につながります。
障害はプロジェクトとして避けられない場合があります。しかし、障害が起きたときの対応の速さ・正直さ・その後のフォローの質が、長期的な顧客との関係を決めます。障害を「失点」として終わらせず、「対応で信頼を上げる機会」として捉えることが、PMとしての成長につながります。
障害報告書を経験するたびに、PMとしての報告スキルは確実に上がります。最初の1通は書くのに苦労するかもしれませんが、2通目からは「構成の型」が使えるようになります。本番障害は避けたい経験ですが、起きてしまったときの対応力こそが、受託開発PMとしての実力差を生む場面です。
障害報告書を作成する際は、「顧客が読んで、次に何が起きるかが分かる」ことを目標に書いてください。事実を羅列するだけでなく、「次の連絡はいつ来るか」「自分は何をすればよいか」が伝わる構成が、顧客の不安を最も減らします。
顧客の立場から見ると、障害発生時に最も不安なのは「この先どうなるか分からない」という状態です。報告書の中に「次の連絡は○月○日です」という一文があるだけで、その不安は大きく下がります。構成の4番目（今後の連絡予定）をどの報告書でも省略しないことが、顧客との信頼維持で最も確実な習慣です。
障害報告の構成と顧客対応のスキルは、炎上予防・立て直しパックの中でまとめて学べます。本番障害から信頼を回復する実務的な進め方を体系的に理解できます。