■ 1. はじめに
- システム障害対応では「影響範囲の調査」「原因の特定」「復旧対策の実施」という一般論は広く知られているが実践的な指針は少ない
- 実際の困難は部分的にしか見えない流動的な状況下で錯綜する情報を元に優先順位を判断することにある
- 『システム障害対応の教科書』はシステム障害の検知から原因調査・復旧対応までの基本的な動作と現場マネジメントをまとめたものである
- 本稿では同書をベースに著者の経験を交えた5つの勘所を解説する
■ 2. 旗振り（インシデントコマンダー）を決める
- 旗振りとはシステム障害対応チームのリーダー（インシデントコマンダー）のこと
- 主な役割:
- 体制構築: 対応メンバーを集め役割をアサインする
- 兵站: メンバーのシフト・食事・宿泊を割り振る
- 情報の一元化: 原因解析・仮説検証・復旧対策の状況を集める
- コミュニケーションのハブ: 顧客や関連チームと連携する
- 旗振りはまず障害の対応方針（システム復旧優先かデータ汚染阻止優先か等）を決定する
- 状況の変化に応じて優先度の再考も必要となる
- 旗振り不在の場合:
- 全員がボールに集まる「ちびっこサッカー」状態となる
- 場当たり的な対応となり情報は断片的なまま集まるが解決に結びつかない
- 情報錯綜により作業が重複しデータ破壊などの二次被害が発生する
- 対応できる人に作業が集中し長期対応でその人が消耗・破綻するリスクがある
- 旗振りと作業者は必ず分離する:
- 2つの役割を兼任させると作業ミスや連絡漏れなどの二次被害リスクが高まる
- 通常は「分かる人」「できる人」が作業者となるため上司が旗振りを担うことが多い
■ 3. メンバーの健康維持のための宿を確保する
- システム障害の最大の特徴は「いつ終わるか分からないこと」である
- ヤバそうなトラブルと感じた時点でまず宿泊手段の確保を検討する:
- 会社泊か近隣宿泊施設かを判断する
- 誰が泊まり誰を帰すかを決める
- メンバーの休息サイクルを最初に設計しない場合:
- 限界まで働いてから場当たり的な休息となる
- 連泊連勤が続くとパフォーマンスが著しく低下し体調不良者が続出する
- 復旧後に退職者が出るリスクがある
- システム障害の終息時期は予測困難である:
- 原因が判明しても復旧方法（データパッチ・ロールバック・プロセス再起動等）はさらに検討が必要
- 業務担当との調整や上層部の判断も必要となる
- 大きなトラブルと感じた時点で長期戦を覚悟し宿を予約する:
- 空振りしても問題ない（重要なのはメンバーの体調とチームのパフォーマンス）
- ホテルが確保できない場合はスパ銭利用の当番表を作成するなど代替手段を講じる
- 「まだイケます」と申し出るメンバーも強制的に休ませる
- システム障害時のリーダーの最大の役割はメンバーをどうやって休ませるかである
■ 4. War Roomをつくり情報を集約・可視化する
- War Roomとはそこに行けば最新情報と状況が把握できる会議室（物理・ウェブ・ハイブリッド）のこと
- ホワイトボードはフロー型とストック型の2種類を用意する:
- フロー型: 時系列の一覧表
- 発生事象・影響調査・解析状況を時系列で記録する
- 「いつ」「どこで」「何が」「どこの情報か」を記載する
- 記録は消さずに継続し満杯になったら別ボードを用意する
- ストック型: 現在の最新状況のまとめ
- 発生事象と影響・解析状況と直接原因（事実/仮説の区別含む）・復旧対処の準備と状況を記載する
- 復旧リミットや復旧作業に伴う業務影響も記載する
- 未確定事項もその旨を明記する
- 更新時は右上に日時を書いて画像として保存する
- 途中参加・交代メンバーはこのボードで状況を把握する
- ホワイトボード周辺にはシステム全体図・連絡体制図・当番表を揃えておく
- 情報更新タイミングをボードに明示し非同期でも情報が届く仕組みを作る
- ホワイトボードはチームの盾としての機能を持つ:
- 「どうなっているのか」と怒鳴り込む人にはストック型ボードを見せることで説明に代える
- 無茶な要求や暴言はフロー型ボードにそのまま記録し後の責任問題への証拠とする
- ウェブ会議の場合は全てレコーディングしておく
- ホワイトボードは「人から問題を切り離す装置」として機能する:
- 問題はホワイトボード上（当事者間）にあるという形にすることで経営層と現場の対立姿勢を和らげる
■ 5. 陥りがちな罠を見極め二次被害を避ける
- システム障害の解析・復旧において二次被害は普通に発生するものとして認識する
- 二次被害が発生しやすい理由:
- 緊急・重要な状況でリソース・時間・情報が不足している
- 普段しない作業を慣れていないメンバーが実施する場合がある
- 通常は複数人でやるリスクのある作業をひとりで実施せざるを得ない場合がある
- 疲労困憊した状態での作業となる
- 二次被害の具体例:
- 手順書のサーバ名誤り（IPアドレスとホスト名の食い違い）による無関係サーバのシャットダウン
- 削除対象確認漏れによるシステム領域の全消去
- 再実行禁止バッチ処理の誤実行によるデータ件数倍増と容量圧迫
- 連携先システムでの確認漏れ
- 対策:
- 危険な作業は複数人でチェックする
- リモートで画面共有しながら実施する
■ 6. 責任転嫁のための犯人探しをやめさせる
- 犯人探しは障害対処中・ポストモーテム中を問わず必ず発生する:
- 組織が大きくなるほど役職が上になるほど発生しやすい
- 犯人探しの背景:
- 不確実な状況下での恐怖を誰かへの責任転嫁によって解消しようとする心理的行動である
- 犯人探しの悪影響:
- 報告遅延・情報隠蔽が起きる
- 解明が遅れ根本解決に至らない小手先の対処となる
- 一時的な小康状態の後にさらに大きな事故が発生するリスクがある
- 犯人探しへの対処法:
- 原因調査の主語を「人」から「プロセス」に変える
- 「誰が設定を変えたか」ではなく「いつどの手順に則って変更したか」と問う
- 変更理由・背景・承認プロセスの欠陥を明らかにする
- 問題はミスした「人」ではなくミスを防げなかった「プロセス」にあると強調する
- 感情的になっている人から現場エンジニアを全力で守る
- 怒りを人ではなく別の何か（ぬいぐるみ等）にぶつけることで責任所在を「誰か」から「何か」に転換する
■ 7. おわりに
- システム障害における現場マネジメントの要点:
- 旗振りを決め体制を構築する
- 兵站に目配りしてWar Roomをつくる
- 二次被害に注意しながら解析・復旧を進める
- 犯人探しを厳に慎む
- より具体的・網羅的な情報は『システム障害対応の教科書』を参照
- いま余裕のある状況で「連絡体制図」を更新しておくことを推奨する:
- 電話番号・メアドだけでなくメーリングリスト・SlackやTeamsアカウント名・担当窓口も最新状態に保つ