先に要点
- インシデントコマンダー（IC）は、障害対応で全体の判断・優先順位・役割分担・進行をまとめる役割です。
- 大事なのは、自分が一番手を動かすことではなく、チーム全体が迷わず動けるように整理することです。
- 技術対応役と役割として分けて考えるだけで、重複作業・判断待ち・連絡漏れが減ります。
- 小規模チームでも、「今回のICは誰か」を決めるだけで動きが整理されやすくなります。
先に結論
インシデントコマンダー は、障害対応や重大インシデントのときに、全体の判断、優先順位、役割分担、進行をまとめる役割です。
いちばん大事なのは、自分が一番手を動かす人 ではなく、チーム全体が迷わず動けるように整理する人 だという点です。
大きな障害では、次の作業が同時に走ります。
このとき、全員が個別に動くと、重複作業、判断待ち、連絡漏れが起きやすくなります。
インシデントコマンダーは、そうならないように 誰が何を担当するか 今の最優先は何か 次に何を試すか をまとめる役目です。
この記事では、2026年4月23日時点で Google SRE の Incident Management、Atlassian の incident commander 関連資料、PagerDuty の incident response docs を確認しながら整理しています。
インシデントコマンダーとは何か
インシデントコマンダーは、障害対応の司令塔に近い役割です。
ただし、偉い人が現場へ命令する、という意味ではありません。
本質は、情報と判断を一か所に集めて、対応を前に進めることです。
- いま何が起きているか整理する
- 影響範囲を確認する
- 技術対応役を割り当てる
- 連絡役や記録役を決める
- 優先順位を決める
- 切り戻しや機能停止の判断を進める
- 状況更新の頻度や出し先をそろえる
つまり、障害そのものを一人で直す人 ではなく、直すための場を回す人 です。
なぜ必要なのか
障害対応では、技術的に詳しい人ほど調査へ深く入りやすいです。
それ自体は必要ですが、同時に 今は調査継続か、切り戻しか 顧客へ何を伝えるか 誰を追加招集するか の判断も必要になります。
- みんなが同じログを見ている
- 誰も全体影響を把握していない
- 顧客連絡が遅れる
- 似た調査を別々に進める
- 切り戻し判断が後手になる
インシデントコマンダーがいると、全体を見る役 が明確になるので、技術担当は技術に集中しやすくなります。
技術対応役との違い
ここはかなり重要です。
インシデントコマンダーと技術対応役は、同じ人でも回せることはありますが、役割としては分けて考えた方が安全です。
| 役割 | 主に見ること |
|---|---|
| インシデントコマンダー | 全体判断、優先順位、役割分担、連絡、進行 |
| 技術対応役 | 原因調査、復旧作業、変更実施、検証 |
Google SRE や PagerDuty 系の考え方でも、インシデントコマンダーは 技術変更を自分で進めること より、対応全体を調整すること が中心です。
インシデントコマンダーが深く手を動かし始めると、全体を見る人が消えやすくなります。これが障害対応でよくある詰まり方です。
具体的に何をするのか
最低限の役割の分け方は、次のような形です。
小規模チームでは兼任でも構いませんが、今この人は何を見る役か は明確にした方がよいです。
小規模チームではどう考えるか
小さな会社や少人数開発では、そんな役割分担をする人数がいない ことも普通です。
それでも、役割の考え方自体はかなり役立ちます。たとえば3人しかいなくても、次のように整理できます。
1人目
全体判断と連絡を見る
2人目
技術調査を進める
3人目
検証や影響確認を回す
人数が足りないときは兼任でもよいですが、判断している人 と ログに潜っている人 を意識的に分けるだけで、かなり詰まりにくくなります。
インシデントコマンダーに必要な力
インシデントコマンダーは、必ずしも一番強い実装者である必要はありません。
むしろ重要なのは次の力です。
整理
状況を要約する力
判断
優先順位を切る力
委任
人へ任せる力
伝達
話を短く整理する力
区別
事実と推測を分ける力
平静
プレッシャー下でも落ち着いて進める力
Atlassian や PagerDuty の資料でも、資源配分、コミュニケーション、意思決定が中核だとされています。
よくある失敗
失敗
1. 一番詳しい人が全部抱える
技術的には強くても、全体進行まで同時に持つと崩れやすいです。特に大きな障害では、調査と進行を分けた方が安全です。
失敗
2. 誰も最終判断を持たない
切り戻すのか、待つのか、別案へ切り替えるのかが曖昧だと、時間だけが過ぎます。インシデントコマンダーは、この判断を前に進める役です。
失敗
3. 連絡が後回しになる
技術対応に集中するあまり、社内、サポート、営業、顧客向け更新が止まることがあります。すると、障害そのものに加えて信頼低下も起きやすくなります。
失敗
4. 記録を残さない
何をいつ判断し、何を試し、何が失敗したかが残っていないと、復旧後の振り返りがかなり弱くなります。
よくある誤解
そうとは限りません。役職よりも、その場で整理し、判断を進められるかの方が大事です。
詳しい人が適任なこともありますが、常にそうではありません。全体整理と技術調査を同時に背負うと、どちらも中途半端になりやすいです。
小規模チームでも、重大障害や本番トラブルではかなり効きます。役職として固定しなくても、今回は誰がICをやるか を決めるだけで変わります。
実務で最初に決めておくとよいこと
これを先に決めておくと、障害発生時に まず誰がまとめるのか で揉めにくくなります。
インシデントコマンダーのよくある質問
Q. インシデントコマンダーは技術力が必要？
A. 必要ですが、技術的に最も詳しい人 ではなく 判断と調整ができる人 の方が向いています。技術者にはコマンダー役より 現場対応に集中 してもらった方が、組織としてのインシデント対応が回りやすい。
Q. オンコール体制とどう違いますか？
A. オンコールは 「誰が呼び出される」、IC は 呼び出された後の対応をまとめる役割。オンコール対応者がそのまま IC になる場合もあれば、別の人が IC を担う場合もあります。
Q. 小規模チームでも IC は必要？
A. 必要です。3人チームでも、誰がまとめるか を決めておかないと混乱が起きます。一番経験のある人が IC のような暗黙ルールでも、最初に明示することが重要。
Q. IC のトレーニングは？
A. 過去インシデントの振り返り(ポストモーテム)で学ぶ、障害対応訓練(Game Day、Chaos Engineering)、PagerDuty や Datadog のインシデント管理機能の使い方、で実践的に学べます。
Q. ポストモーテムとは？
A. インシデント収束後の振り返り会。時系列、原因、影響、対応、改善案 を文書化。Blameless(個人を責めない) で実施し、組織として再発防止策を蓄積します。
Q. 重大度(Severity)の決め方は？
A. S1: 全システム停止/重大な情報漏洩、S2: 主要機能の不能、S3: 一部機能の不調、S4: 軽微な問題、のような4段階が一般的。誰が判定するか を事前に決めておきます。
Q. ツールは何を使いますか？
A. PagerDuty、Opsgenie、Incident.io、FireHydrant、Datadog Incident Management、などです。通知 + ステータス共有 + ポストモーテム がまとまったツールが効率的。
まとめ
インシデントコマンダー は、障害対応で判断、優先順位、役割分担、連絡をまとめる役割です。
一番大事なのは、自分が全部直すことではなく、チーム全体が前に進める状態を作ることです。
技術対応役と分けて考えるだけでも、重複作業、判断待ち、連絡漏れはかなり減らせます。
特に本番障害で混乱しやすいチームほど、今回の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