こんにちは！ アスクルのBtoB開発マネージャーの笹井です！
私は現在、アスクルサイトやソロエルアリーナサイト全般に関わるシステムの障害対応において、インシデントコマンダー（IC）として障害対応の指揮をとっています。
障害が起きたときに、関係者を集め、状況を整理し、復旧に向けた意思決定とコミュニケーションを前に進める役割です。
ここでいう IC（Incident Commander） とは、障害の原因を直接調査・修正する“最前線の担当”というより、複数チーム複数システムが関わる中で、全体を俯瞰して復旧活動を成立させる司令塔を指します。
具体的には、情報の混線を防ぎ、役割を割り振り、優先順位を定め判断と共有のリズムを作ることで対応を最短距離で整えます。
ICは「解決する人」ではなく「解決できる状態を作る人」
ICに求められるのは、もっともシステムに詳しい人であることより、サービスとシステム両面を俯瞰して状況を整え続けることだと考えています。
サイト全般のシステムを対象にすると、次のような難しさが出てきます。
- 影響が“画面の一部”に見えても、原因は別の層にあることがある
- 依存関係の広さゆえに、情報が複数経路で飛び交い混線しやすい
- 復旧判断が、技術だけでなく顧客影響や業務影響も含む意思決定になる
だからこそ、ICは「自分が手を動かす」より先に、場・情報・判断の流れを作る必要があります。
私がICとして最初にやること：落ち着かせる／分ける／決める
障害発生直後の数分〜十数分で、次の3点に集中します。
1) 落ち着かせる（混線を止める）
障害対応が崩れる典型的なパターンは、技術課題ではなく“構造”の崩れです。
スレッドが乱立する、誰が何をやっているか分からない、判断が宙に浮く。これが起きると復旧が遅れます。
- 連絡経路を一本化する（議論の場、報告の場を分けることもある）
- 更新の頻度とフォーマットを決める（事実／仮説／次の一手）
- 記録係を立てて、意思決定の履歴を残す
2) 分ける（並列化する）
サイト全般を対象にすると、確認すべき範囲が広く、同時並行が不可欠です。
私は「レーン」を意識して分割します。
- 影響把握（どこまで・誰に）
- 影響抑止（今すぐ止血できること）
- 原因究明（根本に迫る調査）
- 外部/社内連絡（必要な人に、必要な粒度で）
3) 決める（意思決定を前に進める）
インシデント中は「正解を探す」より「判断して進める」局面が多いです。
たとえば、暫定策を打つか、手戻りを許容してでも巻き戻すか、影響説明をどの粒度で出すか。判断には常に前提が付きます。
ICの役割は、前提と根拠を明文化しながら、“今この瞬間の最善”を合意に変えることだと思っています。
ICが“あえて”やらないこと：深く手を動かしすぎない
ICが一番やってはいけないのは、「自分が最短で直せそうだから」と手を動かしすぎることです。
ICが深掘りに入ると、全体の交通整理が止まり、情報が散り、結果的に復旧が遅れます。
技術のコア調査や修正は、最適な担当者が行う。
ICは担当者が最大限の力を発揮できるように、ノイズを減らし、判断を速くし、コミュニケーションを整える。
この分業が、経験上、システム障害対応では特に効きます。
収束後にやるべきこと：学びを“組織の資産”に変える
障害が収束した後、次のインシデントが発生した際、より迅速に対応できるよう「学びの形式化」を実施します。
- 何が起きたか（タイムライン）
- 何が効いたか（良かった判断・運用）
- どこが詰まったか（監視、連絡、権限、手順、設計）
- 次はどうするか（仕組みで再発確率を下げ、検知と復旧を速める）
ここで大事なのは、個人の責任追及ではなく、構造の改善に落とし込むことです。
実際の様子
実際の対応は、次のようなフローで役割分担しています。
- システムアラート（New Relic） や 社内エスカレーション（問い合わせ等） が発生
- システム運用チーム が検知・受付
- IC（インシデントコマンダー） に連携され、状況を取りまとめて対応を指揮
- 影響範囲に応じてサイト各PF担当者へ連絡・招集し、役割分担して復旧を進める
システム障害時の連絡フロー
また、連絡はSlack・Zoomを利用し速度感のあるコミュニケーションを実現しています。
サービス継続性を背負うICという役割とは
ECサイトのシステムでは、ひとつの不具合がそのままお客様へのご迷惑に繋がり、影響が社内外へ一気に広がります。
だからこそICは、単に復旧を急ぐだけでなく、「お客様への影響を最小化し、事業の信頼を守る」という責任を背負うポジションだと受け止めています。
技術と組織の交差点に立ち、スピードと品質の両方を担保する─アスクルにおけるICは、サービスの継続性そのものを支える重要な役割だと考えます。
