インシデントコマンドシステム
定義
インシデント対応を構造化するためのロール（役割）ベースのフレームワーク。もともと消防の指揮システムから派生した。
| ロール | 役割 |
|---|---|
| IC（Incident Commander） | 指揮官。全体を統括し、優先度を決定する |
| OL（Operations Lead） | 技術的な修正作業を実行するチームをリード |
| CL（Communications Lead） | 社内外への状況報告・エスカレーションを担当 |
なぜ重要か
大規模インシデントで「全員が技術対応に集中」すると：
- 状況が外部に伝わらない（ユーザー・経営層が不安）
- 誰が何をすべきかがわからず二重作業が発生
- 重要な判断（ロールバックすべきか）が先送りになる
ICは問題を解決しない。チームが解決できるよう指揮することが仕事。
適用場面
- 複数チームをまたぐSEV1インシデント
- 対応が長期化（1時間超）するインシデント
- 初めてオンコールをするエンジニアのガイドとして
3C フレームワーク
| C | 意味 | 実践 |
|---|---|---|
| Coordinate | 調整 | IC がリソース配分と優先度を決定 |
| Communicate | 伝達 | CL が定期的（15〜30分ごと）に状況を共有 |
| Control | 制御 | 変更を行う前に IC に確認を取る |
インシデント対応の流れ
- アラート受信 → 初動担当がICを宣言
- インシデントチャンネル（Slack等）を作成し招集
- ICが状況把握 → 深刻度評価 → ロール割り当て
- OLが技術対応、CLが状況報告（外部ページ更新など）
- 収束宣言 → ポストモーテム日程調整
ハンドオフのポイント
長時間インシデントではICを交代させる（燃え尽き防止）：
- 現状と仮説を文書化してから交代
- 「今試みていること」「試みていないこと」を明記
関連パターン
- 非難のないポストモーテム — インシデント後の学習プロセス
- オンコール設計 — ICを担うエンジニアの育て方
出典
Google SRE Workbook（Betsy Beyer他）第9章「Incident Response」