はじめに
先日、はじめてインシデントコマンダーを担当しました。
バックエンドエンジニア4年目として開発・保守運用を経験してきた自分が、はじめてインシデントコマンダーを務めた経験から、気づいたことや反省をまとめます！
こんな方に読んでもらえると嬉しいです。
- これからインシデントコマンダーをやろうとしている方
- インシデントコマンダーって何をする人なの？と気になっている方
- プロジェクトリーダーとしてチームを動かす立場になる方
インシデントコマンダーとは？
インシデントコマンダーとは、インシデント対応全体を指揮する役割です。
インシデントが発生すると、エンジニアは原因調査・影響調査・暫定対応・恒久対応など、多くの対応に追われます。そのような状況で、「誰が何をするのか」「どの順番で進めるのか」「顧客にいつ何を伝えるのか」を各自が判断しながら動くのは非常に難しいです。
そこでインシデントコマンダーは、エンジニアが目の前の作業に集中できる環境を整え、インシデントを解決に導く役割を担います。チーム全体の動きを指揮し、スピードと判断の質を担保することで、顧客の不安をいち早く解消し、被害を最小限に抑えます。
僕たちのインシデント対応フロー
僕たちの開発組織では、監視ツールのアラートやCSからのエスカレーションをきっかけにインシデントコマンダーがアサインされます。インシデントコマンダーはまずインシデントのランク判定を行います。
重要度（顧客影響の大きさ）と緊急度（利用制限の深刻さ）を掛け合わせて、複数のランクに分類します。ランクによって、エスカレーション先・顧客通知の要否・対応納期の目標が変わります。
インシデントと判断されたら、Slackに専用チャンネルを作成し、対応メンバーをアサインして対応を進めます。
以下はインシデント対応フローの例です。
やってみてわかったこと6つ
ここからは実際にインシデントコマンダーを担当してみて、学んだこと6つ紹介します。
1. 全部自分で判断しようとしない
アサインも進め方も「全部自分で判断しなければ」と悩んでいたところ、先輩エンジニアから、「知ってそうなメンバーに聞けばいいよ」 とアドバイスをもらいました。「判断するために何が必要か」を自問して、必要な情報や意見をみんなから引き出しながら判断するといい意思決定ができると学びました。
例えばアサイン時に「水平調査として誰が必要ですか？」とシニアのエンジニアに聞くことで、自分では気づけなかった適任者に辿り着けたりします。
インシデントコマンダーは独断で動く必要はなく、チームの知見を活かして意思決定する役割です。
全部自分が持っている情報だけで意思決定しようとする
エンジニアから情報・意見を引き出しながら判断することで、適切なアサインができる
2. 組織を日頃から把握しておく
適切なアサインをするには、誰が何を知っていて、今どんな状況にあるかを普段から把握しておく必要があると学びました。
たとえば、
- Aさんは最近このドメインの実装を触っていて、原因調査が早そう
- Bさんは今スプリント終盤でかなり詰まっている
- CさんとDさんは同じプロジェクトだから、2人ともアサインするとそのプロジェクトが止まる
みたいな情報です。
ある程度、知っていると自負していましたが、実際アサインを決めようとしていると、細かいところまでは開発メンバーの状況を知れていないと反省しました。
普段から組織の状態を観察するようにしていると、もっとスピーディな意思決定ができそうです。
誰がどのチームでどんな状況か知らない
誰がどんな状況にあるか普段から知っておくことで、開発者組織の中でより適切な人をアサインできる
3. アサイン時は「可能ですか？」ではなく「お願いします」
対応するメンバーをアサインする際、「対応可能ですか？」と聞いたところ、先輩から「お願いしますって言えばいいよ」とアドバイスをもらい、なるほどなと思いました。
アサインする相手はほぼ全員自分より先輩のエンジニアで、みんな自分のプロジェクトを抱えている。「可能ですか？」と聞くと相手に判断を委ねてしまうし、インシデントコマンダーとしての覚悟も伝わらないです。
なので、「〇〇さんの力が必要なので、アサインさせてください」と明確に伝えることが大事だなと思いました。相手に「自分がやらなければ」と思ってもらえるかどうかが、対応のスピードに直結すると学びました。
「対応可能ですか？」と聞いてしまい、相手に判断を委ねる
「〇〇さんの力が必要なので、アサインさせてください」と明確に伝える
4. 自分は手を動かさない
これまでエンジニアとして「原因がどのコードにあるか」まで把握して動いてきた習慣から、インシデントコマンダーになってからも原因調査をしているエンジニアに「具体的にどのコードが原因ですか？」と深掘りして、一緒にコード調査をし始めてしまいました。
しかし、インシデントコマンダーが細かいコードの話まで把握する必要はありませんでした。インシデントコマンダーがやるべきことは、エンジニアたちをマネジメントしてインシデントを解決に導くことであって、自分が暫定対応するわけではない。細かい調査に時間を使うほど、全体俯瞰の質が落ちると感じました。
「自分は手を動かさない」という意識を持つことが大事だなと学びました。
原因を調査者と同じレベルまで理解しようとし時間がかかってしまう
「自分は手を動かさない」という意識を常に持つことで、インシデント全体を俯瞰的にマネジメントできる
5. 顧客影響を最小化するには何が最優先か考える
インシデントコマンダーは「何を先にやるか」の意思決定も担います。これを誤ると、チーム全体が的外れな方向に動いてしまいます。
実際に経験したのですが、影響を受けている顧客への通知を急ごうとしたところ、「このバグは2年前から存在していて、通知のタイミングが1日ずれてもほとんど意味がない」というケースがありました。その場合、バグが存在しているという通知よりも「これ以上被害顧客を増やさない」ことを先に行うべきでした。
顧客への通知を急ぐあまり、優先順位を誤る
「顧客影響を最小化するには何が最優先か？」を常に問い続けることで、適切な優先順位が見えてくる
6. チームを迷わせない
インシデント対応中、メンバーが最も不安になるのは「今どういう状況で、自分は何をすればいいのか」がわからないときです。
インシデントコマンダーが方針をコロコロ変えたり、意思決定を先延ばしにすると、チームの士気が下がります。逆に、「今はここまで進んでいる、次にこれをやる、〇時までにここまで終わらせたい」という状況を随時共有するだけで、メンバーは安心して目の前の作業に集中できます。
意思決定の中身だけでなく、それをメンバーに伝え続けることもインシデントコマンダーの重要な仕事です。チームが迷わないように道標を示し続けることが、対応スピードにも直結すると感じました。
方針変更や意思決定の先延ばししてしまい、メンバーが何をすべきか分からなくなる
現状/次のアクション/目標時間を決め、随時共有することでメンバーは目の前の作業に集中できる
おわりに
インシデントコマンダーをやってみて一番感じたのは、「エンジニアとしての経験とインシデントコマンダーとして必要なスキルは別物だ」ということです。
技術的に深く潜る力ではなく、全体を俯瞰してチームを動かす力。判断の速さと論理的な説明責任。そして普段からの組織観察。
これらは意識しないと身につきにくいスキルだと思うので、これからも経験を積みながら磨いていきたいと思っています。
同じくインシデントコマンダーをはじめる方の参考に少しでもなれば嬉しいです。