このユニットの結論
障害のとき、技術的な対応と同じくらい時間を使うのが「連絡」です。
誰が、誰に、いつ、何を伝えるかを、障害が起きる前に決めておく。当番と呼び出しの順番、上に上げる基準、社外（ベンダー、顧客、経営層）への連絡の窓口と文面の雛形。これらが決まっていれば、対応する人は対応に集中できます。
1. 何の話か
このユニットは、障害対応の連絡の体制と、それを支える役割の話です。
13-03 障害対応を誰が指揮するのか で、指揮役と、調査・作業、連絡、記録の役割を学びました。このユニットは、そのうちの「連絡」を掘り下げます。誰が最初に気づき、誰を呼び、誰に伝え、どの基準で上に上げるか。マルチベンダーの案件では、会社をまたぐ連絡が特に難しくなります。
2. なぜ必要か
連絡の体制がないと、
- 夜間に監視が検知したが、誰を呼ぶかが決まっておらず、朝まで誰も動かない
- 対応している人に、経営層や業務部門から直接「どうなっているか」の問い合わせが集中し、対応が止まる
- ベンダーの担当に連絡したいが、窓口も連絡先も分からず、営業の担当を経由して時間が過ぎる
- 顧客への説明が、担当者ごとに違う内容で行われる
- 重大な障害なのに経営層に伝わるのが遅れ、会社としての判断（業務の停止、顧客への公表）が遅れる
ということが起きます。
3. このユニットで分かること
- 当番と呼び出しの設計
- 上に上げる基準（エスカレーション）
- 社内・社外への連絡の決まり
4. 当番と呼び出し、上に上げる基準
当番（オンコール）は、時間帯ごとに「最初に呼ばれる人」を決めておく仕組みです。1 人目がつながらないときの 2 人目、技術の領域（基盤、アプリ、連携、データ）ごとの担当、ベンダーごとの窓口を、一覧にしておきます。連絡先は定期的に確かめます（異動と退職で古くなります）。
上に上げる基準は、重大度（13-02 障害の重大度を判断する）と経過時間で決めます。
| 基準（一般的な例） | 誰に上げるか | 期待すること |
|---|---|---|
| 重大度が最も高いと判断した時点 | 運用の責任者、プログラム責任者、業務部門の責任者 | 会社としての判断（業務の停止、代替手段、顧客への説明）の準備 |
| 重大度が中で、30 分たっても見通しが立たない | 運用の責任者 | 人と権限の追加。ベンダーへの正式な依頼 |
| 会社をまたぐ原因の可能性が出た時点 | 関係するベンダーの窓口と、契約の責任者 | 責任の所在の議論ではなく、対応の協力 |
| 顧客や外部に影響が及ぶ可能性が出た時点 | 広報・顧客対応の責任者 | 説明の文面と時期の準備 |
基準は「〜したら上げる」と機械的に書きます。対応している本人は、上げるかどうかを迷う余裕がありません。
5. 連絡の決まり
連絡役を 1 人置きます。 対応している人に問い合わせが直接届かないようにし、連絡役が決めた時刻（たとえば 30 分ごと）に状況をまとめて伝えます。状況が変わらなくても「変わっていない」と伝えます。沈黙は、不安と直接の問い合わせを生みます。
伝える内容の雛形を用意します。何が起きているか（分かっている事実）、誰に影響があるか、今何をしているか、次の連絡はいつか。原因や見通しは、分かっていなければ「分かっていない」と書きます。
社外への連絡は、ベンダーへの依頼（窓口、連絡先、依頼の形式、契約上の対応時間）と、顧客への説明（誰が、どの経路で、どの文面で）を分けて決めます。顧客への説明は、担当者の判断で行わず、決めた人が決めた文面で行います。
これらは OPS-004 障害対応計画 に書き、実際の障害での連絡の記録を OPS-005 障害報告書 に残します。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件の体制に関する記載
- マルチベンダー（Vendor 4社）。Vendor A / ネクサスシステムズ — 新基幹アプリケーション、Vendor B / クラウドブリッジ — クラウド基盤、ネットワーク、IAM、連携、CI/CD、監視、Vendor C / ファイナンスシステムサービス — FIN-CORE、会計連携、Vendor D / タイムリンク — 勤怠・工数管理SaaS
- システムに SYS-11 監視・ログ基盤 がある
- 成果物に OPS-004 障害対応計画、OPS-005 障害報告書、PRG-003 プロジェクト体制図 がある
- P-011 山下 恵 — 本番移行・運用リーダー、P-A01 井上 健一 — Vendor A PM、P-B01 吉田 圭介 — Vendor B PM、P-C01 大森 裕 — Vendor C PM
- 重大障害判断は、AIへ最終委任しない事項
アステリア案件の当番の体制、上に上げる基準、ベンダーへの連絡の窓口、顧客への連絡の決まりは、正本に記録がありません。記録なし
6. THINK — 「原因がどこの会社か分かるまで、連絡できない」
夜間に連携の処理が止まり、当番の担当者が対応しています。基盤の問題か、アプリの問題か、まだ分かりません。担当者は次のように考えました。
「原因が基盤なら Vendor B、アプリなら Vendor A に連絡すべきだ。どちらか分からないうちに連絡すると、『うちではない』と言われて終わる。原因を絞ってから連絡しよう。」
問題
この考えで進めてよいでしょうか。
判断例を開く
判断
「原因を絞ってから連絡する」は、原因が絞れるまで誰も来ないということです。夜間に 1 人で絞るのは、最も遅い進め方です。
確認すること:
- 障害対応計画に、「会社をまたぐ可能性がある場合は、関係する会社に同時に連絡する」と書いてあるか。書いていなければ、それが計画の抜け
- 各ベンダーの夜間の窓口と、契約上の対応時間は分かっているか
- 連絡の文面は「原因はあなたの会社だ」ではなく「連携が止まっている。基盤とアプリの両方の確認を依頼したい」にできているか
- 責任の所在の議論は、対応が終わってから行うと、あらかじめ各社と合意できているか（契約と役割分担の文書）
- 上に上げる基準（30 分たって見通しが立たない）に、もう達していないか
連絡は、原因を特定してから行うものではありません。原因を特定するために行うものです。
7. よくある失敗
- 当番の連絡先が古く、夜間に誰にもつながらない
- 対応している人に問い合わせが集中し、対応が止まる
- 上に上げる基準がなく、対応している本人が「まだ大丈夫」と抱え込む
- 原因の会社を絞ってから連絡しようとして、時間が過ぎる
- 顧客への説明が担当者ごとに違う
8. 成果物との接続
- OPS-004 障害対応計画：当番の一覧、呼び出しの順番、上に上げる基準、連絡役、社内・社外への連絡の雛形
- OPS-005 障害報告書：実際の障害で、誰が、いつ、誰に連絡したかの記録。計画の見直しの材料
9. AI WORKFLOW — 連絡の記録から時系列を整理させる
AIは、障害中の連絡の記録（チャット、メール、電話のメモ）から、誰が、いつ、誰に、何を伝えたかの時系列を整理する下書きに役立ちます。
指示例:
「次の障害中の連絡の記録から、時刻、発信者、宛先、伝えた内容を時系列の表にしてください。記録にない連絡を補ったり、連絡が遅かった・早かったの評価をしたりしないでください。」
10. REVIEW — AIの整理を確認する
- AIの時系列が、元の記録と合っているか（時刻の取り違えがないか）
- 記録に残っていない口頭の連絡を、対応した人に確かめて人が補ったか
- 連絡の記録（顧客名、社外の担当者名）を AI に渡してよいかを事前に確かめたか
11. 人間が判断すること
- 上に上げる基準と、実際に上げるか
- ベンダーに正式に依頼するか。顧客に説明するか、その内容と時期
- 責任の所在の議論を、いつ行うか
重大障害判断は、AIへ最終委任しない事項です（正本の方針）。
12. 判断演習
「土曜の深夜に、監視が連携の停止を検知した」場面を考えてください。
最初に呼ばれる人から、経営層に伝わるまでの連絡の順番を書いてください。それぞれの連絡について、「誰が」「何をきっかけに」「何を伝えるか」を 1 行ずつ書いてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
連絡は、障害の前に設計する。当番と呼び出し、上に上げる機械的な基準、連絡役と雛形、社外の窓口を決めておく。原因を絞ってから連絡するのではなく、絞るために連絡する。