第6章：連絡とエスカレーション（判断基準/情報粒度）

この章で学ぶこと

• 連絡は“頻度と粒度”を固定する
• エスカレーション基準を事前に持つ
• 必要支援を具体化する

成果物（または判断基準）

• 状況共有（付録: 状況共有）
• エスカレーション（付録: エスカレーション）

本文

連絡が機能しない主因は、情報量の過多/不足、更新欠落のいずれかである。テンプレで最小項目と更新頻度を固定する。

共有の最小セット

• いま何が起きているか
• 何を試したか（結果）
• 次に何をするか
• 影響見込み

更新頻度の目安（Severity別）

目安であり、組織の窓口/顧客影響/法令要件がある場合はそれらを優先する。

注: ETA（復旧見込み時刻）は確度が低い場合、未確定と明示し、次回更新時刻を先に約束する。

エスカレーションは“判断根拠”と“必要支援”が揃っていると迅速化する。

エスカレーション文面例（最小）

テンプレを貼り付けて埋めると、情報不足/過多を避けやすい（付録: エスカレーション）。

【エスカレーション】決済 API で 5xx 増加（暫定 P1）
影響: 決済失敗が一部顧客で発生（失敗率 6%、暫定）
緊急度: 継続中、悪化の可能性あり
必要な支援: DB 担当に接続状況の確認（15 分以内）
暫定策: 機能フラグ OFF、もしくはロールバック判断
次回更新: 11:00 JST

注: セキュリティ疑いがある場合は、影響の確定を待たず証跡保全と所定窓口へのエスカレーションを優先する（組織の手順に従う）。

具体例（場当たり→再現性）

悪い例（場当たり）

原因調査中です（以上）
次に何をするかが不明

良い例（再現性）

状況: 決済 API で 5xx が増加
影響見込み: 決済失敗が一部顧客で発生（暫定）
試行: 直近変更を比較→変更Aが疑わしい
次: ロールバック可否確認→実施判断
支援: DB担当に接続状況の確認依頼
次回更新予定時刻: 11:00 JST

チェックリスト

• 共有頻度が定義され、定期更新できている
• 次アクションが明確
• エスカレーションの判断根拠がある

まとめ

• 更新頻度と粒度を定義し、最小セット（状況/試行/次アクション/影響見込み）で共有する
• 判断根拠と必要支援を整理し、エスカレーションの遅延を防ぐ
• 状況共有テンプレを一次情報として運用し、関係者の前提を揃える

次章への接続

• 次章: 第7章