フレームワーク活用ガイドひとことで言うと#
システム障害が発生したとき、誰に・何を・いつ・どのチャネルで伝えるかを体系化したコミュニケーションフレームワーク。技術的な復旧作業と同じくらい、ステークホルダーへの情報発信が信頼維持に直結する。「何が起きているかわからない」状態が顧客の不満を最大化する。
押さえておきたい用語#
- インシデントコマンダー（Incident Commander / IC）
- 障害対応全体の指揮を取る役割。技術的な復旧はエンジニアに任せ、ICは状況把握・意思決定・コミュニケーションに集中する。
- ステータスページ（Status Page）
- サービスの稼働状況を外部に公開するWebページ。Statuspage（Atlassian）、Instatus、BetterUptimeなどのツールで運用される。
- エスカレーション（Escalation）
- 障害の影響範囲や復旧見込みに応じて、より上位の意思決定者に報告を上げるプロセス。
- 初報・続報・終報（Initial / Update / Final Report）
- インシデント発生時に発信する3段階の通知。初報は「何が起きているか」、続報は「進捗と見込み」、終報は「解決と再発防止」を伝える。
- ポストモーテム（Postmortem）
- 障害の原因・影響・タイムライン・再発防止策を事後にまとめるドキュメント。blame-free（個人を責めない）の原則で書かれる。
インシデント・コミュニケーションの全体像#
こんな悩みに効く#
- 障害発生時にエンジニアが復旧作業に集中し、顧客や営業への連絡が後回しになる
- 「いつ直るのか」という問い合わせがCSに殺到し、対応工数が復旧作業を上回る
- 障害報告の内容と粒度が担当者によってバラバラで、社内の混乱が拡大する
- 障害後に「知らされていなかった」と経営層やパートナーからクレームが来る
基本の使い方#
障害が起きてから考えるのでは遅い。平時にテンプレートと連絡フローを準備する。
- 通知先リスト: 社内（経営層、CS、営業、広報）と社外（顧客、パートナー）を重要度で分類
- テンプレート: 初報・続報・終報の文面ひな形を作成しておく
- チャネル: Slack（社内）、ステータスページ（社外）、メール（重要顧客）の使い分けを定義
障害を検知したら、不完全でもいいから15分以内に初報を発信する。
- 「何が起きているか」「どの機能が影響を受けているか」「現在調査中」の3点があれば十分
- 原因がわからない段階で「原因は○○です」と断定しない
- 次回更新のタイミング（「30分後に続報します」）を必ず記載する
新しい情報がなくても、定期的に続報を出す。沈黙が最も不安を増幅させる。
- 進捗がなければ「引き続き調査中、次回更新は○○時」と伝えるだけでよい
- 復旧見込みが立った時点で「○○時までに復旧予定」と具体的な時間を共有する
- 暫定的な回避策がある場合は積極的に案内する
復旧後24時間以内に終報を出し、1週間以内にポストモーテムを公開する。
- 終報: 根本原因、影響範囲の最終集計、再発防止策、お詫びを記載
- ポストモーテム: タイムライン、5 Whys分析、具体的な改善アクションと期限を明記
- blame-free（個人を責めない）の原則を守り、システムとプロセスの改善に焦点を当てる
具体例#
顧客1,200社のBtoB SaaS企業。月に1〜2回の障害が発生するたび、CS宛の問い合わせが平均120件に達していた。CSチーム4名は障害中ずっと「現在調査中です」の同じ返信を繰り返しており、対応工数は1障害あたり約20人時。
導入前の課題:
- 障害の初報がCS向けSlackに流れるまで平均45分
- 顧客への通知手段がメールのみで、リアルタイム性がなかった
- エンジニアが復旧作業中にCSから「いつ直りますか」と何度も聞かれていた
取り組み:
- Statuspageを導入し、サービスごとの稼働状況をリアルタイム公開
- 初報テンプレート・続報テンプレート・終報テンプレートを3パターン整備
- インシデントコマンダーがステータスページを更新する運用ルールを策定
結果:
- 初報の発信時間: 45分 → 12分
- 障害中のCS問い合わせ: 平均120件 → 平均24件（80%減）
- CS対応工数: 1障害あたり20人時 → 4人時
- 顧客NPS: 障害後アンケートで「情報提供が適切だった」の回答が28% → 76%
200名規模のフィンテック企業。重大障害時に「CEOが障害をTwitterで知った」という事態が2回発生し、エンジニアリング組織への信頼が揺らいでいた。
課題:
- 障害の重大度判定が担当者の主観に依存していた
- 経営層への報告基準が明文化されておらず、「報告すべきか迷って報告しなかった」ケースが多発
取り組み: エスカレーションマトリクスを策定。
| 重大度 | 基準 | 社内通知先 | 社外通知 | 報告タイミング |
|---|---|---|---|---|
| SEV1 | サービス全体停止 | CEO・CTO・全マネージャー | ステータスページ＋メール | 即時 |
| SEV2 | 主要機能の部分障害 | CTO・関連マネージャー | ステータスページ | 15分以内 |
| SEV3 | 軽微な機能障害 | エンジニアリングマネージャー | なし（長引けばSEV2に昇格） | 30分以内 |
結果:
- 経営層への報告漏れ: 年4〜5回 → 0回
- SEV1障害の初報速度: 平均38分 → 平均8分
- 「過剰報告」も当初は増えたが、3か月で判定精度が安定し、誤判定は月1件以下に
顧客500社のプロジェクト管理SaaS。4時間のサービス停止が発生し、ビジネスタイム中だったため影響が大きかった。
従来の対応:
- 復旧後に「ご迷惑をおかけしました。再発防止に努めます」とだけメール送信
- 顧客から「何が原因だったのか」「本当に再発しないのか」と追加質問が殺到
今回の対応:
- 復旧3時間後に終報メールを送信（根本原因、影響ユーザー数、暫定対処を記載）
- 復旧5日後にポストモーテムをブログで公開
- 分単位のタイムライン
- 根本原因（DBマイグレーションスクリプトのバグ）の技術的な説明
- 再発防止策5項目と各項目の完了予定日
- CTO名義での謝罪メッセージ
結果:
- 障害後の解約率: 前回の同規模障害では3.2%だったが、今回は0.8%
- ポストモーテム公開後にSNSで「誠実な対応」と好意的な反応が複数
- 営業チームから「ポストモーテムを見せたら逆に信頼してもらえた」という報告が3件
- 以降、ポストモーテムの社外公開を標準プラクティスとして制度化
やりがちな失敗パターン#
- 初報が遅い — 「原因が特定できてから報告しよう」と待つと、その間に顧客の不満と問い合わせが爆発する。不完全でも15分以内に第一報を出すほうが信頼を守れる
- 沈黙の時間が長い — 新しい情報がないからと続報を出さないと、「放置されているのでは」と不安が増幅する。進捗がなくても「調査中」と伝えるだけで不安は下がる
- 技術用語で社外に説明する — 「DBのレプリケーション遅延が原因で…」と書いても顧客には伝わらない。社外向けには「データの同期処理に問題が生じ」のように平易な表現を使う
- ポストモーテムを書かない — 振り返りをしないと同じ失敗を繰り返す。また、ポストモーテムを共有しないと「結局何だったのか」が組織に蓄積されない
まとめ#
インシデント・コミュニケーションは、障害時にステークホルダーへ「初報・続報・終報」の3段階で体系的に情報を発信するフレームワークである。インシデントコマンダーが発信の司令塔を務め、エスカレーションマトリクスで誰にいつ伝えるかを明確にする。大事なのは完璧な情報を待つことではなく、不完全でも素早く・定期的に発信し続けること。沈黙が信頼を最も毀損する。復旧後のポストモーテム公開まで含めて一連のコミュニケーションと捉えることで、障害を「信頼回復の機会」に変えることもできる。