先に結論
インシデントコマンダー は、障害対応や重大インシデントのときに、全体の判断、優先順位、役割分担、進行をまとめる役割です。
いちばん大事なのは、自分が一番手を動かす人 ではなく、チーム全体が迷わず動けるように整理する人 だという点です。
大きな障害では、技術調査、影響確認、社内連絡、顧客連絡、復旧判断、追加招集が同時に走ります。
このとき、全員が個別に動くと、重複作業、判断待ち、連絡漏れが起きやすくなります。
インシデントコマンダーは、そうならないように 誰が何を担当するか 今の最優先は何か 次に何を試すか をまとめる役目です。
この記事では、2026年4月23日時点で Google SRE の Incident Management、Atlassian の incident commander 関連資料、PagerDuty の incident response docs を確認しながら整理しています。
インシデントコマンダーとは何か
インシデントコマンダーは、障害対応の司令塔に近い役割です。
ただし、偉い人が現場へ命令する、という意味ではありません。
本質は、情報と判断を一か所に集めて、対応を前に進めることです。
たとえば次のようなことを担います。
- いま何が起きているか整理する
- 影響範囲を確認する
- 技術対応役を割り当てる
- 連絡役や記録役を決める
- 優先順位を決める
- 切り戻しや機能停止の判断を進める
- 状況更新の頻度や出し先をそろえる
つまり、障害そのものを一人で直す人 ではなく、直すための場を回す人 です。
なぜ必要なのか
障害対応では、技術的に詳しい人ほど調査へ深く入りやすいです。
それ自体は必要ですが、同時に 今は調査継続か、切り戻しか 顧客へ何を伝えるか 誰を追加招集するか の判断も必要になります。
ここを誰も持たないと、次のようなことが起きやすいです。
- みんなが同じログを見ている
- 誰も全体影響を把握していない
- 顧客連絡が遅れる
- 似た調査を別々に進める
- 切り戻し判断が後手になる
インシデントコマンダーがいると、全体を見る役 が明確になるので、技術担当は技術に集中しやすくなります。
技術対応役との違い
ここはかなり重要です。
インシデントコマンダーと技術対応役は、同じ人でも回せることはありますが、役割としては分けて考えた方が安全です。
| 役割 | 主に見ること |
|---|---|
| インシデントコマンダー | 全体判断、優先順位、役割分担、連絡、進行 |
| 技術対応役 | 原因調査、復旧作業、変更実施、検証 |
Google SRE や PagerDuty 系の考え方でも、インシデントコマンダーは 技術変更を自分で進めること より、対応全体を調整すること が中心です。
つまり、インシデントコマンダーが深く手を動かし始めると、全体を見る人が消えやすくなります。
これが障害対応でよくある詰まり方です。
具体的に何をするのか
1. 状況を宣言する
まず、インシデントとして扱うか、重大度はどれくらいか、誰を集めるかを決めます。
ここが曖昧だと、招集も連絡も遅れます。
2. 役割を分ける
最低限でも、次を意識すると回りやすいです。
- インシデントコマンダー
- 技術対応役
- 連絡役
- 記録役
小規模チームでは兼任でも構いませんが、今この人は何を見る役か は明確にした方がよいです。
3. 次の一手を決める
障害対応で大事なのは、無限に議論しないことです。
まずログ確認 まず切り戻し まず機能停止 のように、時点ごとの優先順位を切ります。
4. 定期的に状況をそろえる
何分ごとに更新するか、誰へ伝えるか、事実と推測を分けるかをそろえるのも重要です。
これをしないと、社内と顧客で違う説明が出やすくなります。
小規模チームではどう考えるか
小さな会社や少人数開発では、そんな役割分担をする人数がいない ことも普通です。
それでも、役割の考え方自体はかなり役立ちます。
たとえば3人しかいなくても、次のように整理できます。
- 1人は全体判断と連絡を見る
- 1人は技術調査を進める
- 1人は検証や影響確認を回す
人数が足りないときは兼任でもよいですが、判断している人 と ログに潜っている人 を意識的に分けるだけで、かなり詰まりにくくなります。
インシデントコマンダーに必要な力
インシデントコマンダーは、必ずしも一番強い実装者である必要はありません。
むしろ重要なのは次の力です。
- 状況を要約する力
- 優先順位を切る力
- 人へ任せる力
- 話を短く整理する力
- 事実と推測を分ける力
- プレッシャー下でも落ち着いて進める力
Atlassian や PagerDuty の資料でも、資源配分、コミュニケーション、意思決定が中核だとされています。
よくある失敗
1. 一番詳しい人が全部抱える
技術的には強くても、全体進行まで同時に持つと崩れやすいです。
特に大きな障害では、調査と進行を分けた方が安全です。
2. 誰も最終判断を持たない
切り戻すのか、待つのか、別案へ切り替えるのかが曖昧だと、時間だけが過ぎます。
インシデントコマンダーは、この判断を前に進める役です。
3. 連絡が後回しになる
技術対応に集中するあまり、社内、サポート、営業、顧客向け更新が止まることがあります。
すると、障害そのものに加えて信頼低下も起きやすくなります。
4. 記録を残さない
何をいつ判断し、何を試し、何が失敗したかが残っていないと、復旧後の振り返りがかなり弱くなります。
よくある誤解
1. インシデントコマンダーは上司だけがやるもの
そうとは限りません。
役職よりも、その場で整理し、判断を進められるかの方が大事です。
2. 技術的に一番詳しい人がやるべき
詳しい人が適任なこともありますが、常にそうではありません。
全体整理と技術調査を同時に背負うと、どちらも中途半端になりやすいです。
3. 大規模障害だけの役割
小規模チームでも、重大障害や本番トラブルではかなり効きます。
役職として固定しなくても、今回は誰がICをやるか を決めるだけで変わります。
実務で最初に決めておくとよいこと
- 障害時に誰がICになるか
- 重大度の基準
- 連絡チャネル
- 記録の残し方
- 切り戻し判断の流れ
- 復旧後の振り返り方法
これを先に決めておくと、障害発生時に まず誰がまとめるのか で揉めにくくなります。
まとめ
インシデントコマンダー は、障害対応で判断、優先順位、役割分担、連絡をまとめる役割です。
一番大事なのは、自分が全部直すことではなく、チーム全体が前に進める状態を作ることです。
技術対応役と分けて考えるだけでも、重複作業、判断待ち、連絡漏れはかなり減らせます。
特に本番障害で混乱しやすいチームほど、今回のICは誰か を決めるだけで動きが整理されやすくなります。
参考リンク
- Google SRE: Managing Incidents
- Google SRE: Incident Management Guide
- Atlassian: The role of the incident commander
- Atlassian: Understanding incident response roles and responsibilities
- PagerDuty: Incident Commander