# 危機時の指揮系統 ## 定義 危機時の指揮系統(Crisis Command Structure)とは、セキュリティ危機と判断されたインシデントの発生から終結までを通じて指揮・統制・コミュニケーションを維持し続けるための、時間軸に沿った運用の型を指す。トリアージによって「危機である」と判断された後、インシデントコマンダー(IC)を宣言し、オペレーションリード(OL)以下のチームを編成し、作業を並列化し、長時間化する場合は引き継ぎ(handover)やfollow-the-sunローテーションで対応者を交代させ、対応チームの士気を維持するという、一連の時間発展する運用手順の総体である。 本概念は [[Incident Commander]] とは焦点が異なる。[[Incident Commander]] は IC という役割そのものの定義・起源(ICS)・コアコンピテンシー・組織モデル(専任チーム/ドメイン別/志願制)を扱うのに対し、本概念は「危機と判断された後、その対応をどう時間方向に持続させるか」という運用の振り付け(choreography)——並列化・引き継ぎ・ローテーション・士気管理——に焦点を当てる。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 17 Crisis Management]] §Keeping Control of the Incident, §Parallelizing the Incident, §Handovers, §Morale) ## 横断的知見 - **ch16 の事前準備(チームチャーター・運用パラメータ)と ch17 の指揮系統は、同一書籍内で時間軸の前後を分担する独立ソースとして補完関係にある**: 『Building Secure and Reliable Systems』16章はインシデント対応チームの使命・範囲・成功の定義(チームチャーター)や初動対応までの目標時間・SLOといった運用パラメータを**事前に**文書化しておくべきだと説くのに対し、17章はそれらの体制が整っている前提で、実際の危機発生後に IC を宣言し OL 以下のチームを編成し作業を並列化していく**最中**の振る舞いを詳述する。同じ著者チームによる同一書籍でも章が独立しているため、両者は「準備(16章)→実行(17章)」という時間軸の分業を示す2つの独立した一次資料として読める。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 16 Disaster Planning]] §Establish a Team Charter, §Define Operating Parameters for Engaging the IR Team, [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 17 Crisis Management]] §Beginning Your Response, §Establishing Your Incident Team) - **IC のボトルネック化という構造的限界に対し、ch17 は「時間軸での分散」という、[[Incident Commander]] が集約する既存の緩和策とは別次元の解決策を示す**: [[Incident Commander]] が集約する Maguire の博士論文第6章は、指示と報告が単一の IC に収束する構造そのものによって IC がボトルネック化することを理論的に示し、Chapman の Area Command はこれを「空間軸(複数インシデント間のリソース競合)」で緩和する解決策として位置づけられている。これに対し ch17 の引き継ぎ(handover)と follow-the-sun ローテーションは、**単一インシデント内で IC 個人の疲労が限界に達する前に別の IC へ交代させる**という「時間軸」での緩和策であり、Area Command とは直交する解決軸を提供する。両者を合わせると、IC のボトルネック問題には「空間(複数インシデントを俯瞰する上位層を作る)」と「時間(同一インシデント内で人を交代させる)」という少なくとも2つの独立した緩和軸があることが分かる。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 17 Crisis Management]] §Handovers, [[@2020__PhD__Controlling the Costs of Coordination in Large-scale Distributed Software Systems - Chapter 6 Discussion]]) - **「12時間シフト上限」という具体的な運用ルールは、[[インシデントシミュレーション]] が集約する Solo Artist / Band Member の実証知見と方向性が一致する**: ch17 は連続シフトを12時間までに制限し、少人数組織の「ヒーローモード」を極力避けるべきだと明言する。これは [[インシデントシミュレーション]] が Silatani の20名実験から導いた「一人で抱え込む Solo Artist よりチームに分散する Band Member の方が有効」という知見と、個人への負荷集中を避けるという結論の方向で一致する。ただし ch17 は疲労と時間経過(12時間という具体的な閾値)に着目するのに対し、Silatani の知見は同時点での役割分担の巧拙に着目しており、「いつ交代するか(時間)」と「今どう分担するか(同時並行)」という異なる軸を扱っている点には注意が必要。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 17 Crisis Management]] §Handovers) ## 未解決の問い - ch17 の「12時間シフト上限」は具体的だが、実際に何時間を境に対応品質(誤り率・解決時間)が低下するかを定量測定した研究はあるか。[[インシデントシミュレーション]] の staged world 実験はこの閾値を検証できる設計になりうるか。 - follow-the-sun ローテーションと Chapman の Area Command(空間軸の緩和策)を同時に運用している組織の実例はあるか。両者を組み合わせた場合、IC 間の情報同期コストはどう変化するか。 - ch17 の引き継ぎ会議アジェンダ(「もし引き継がないとしたら次の12時間で何をするか」という自問)は、[[Incident Commander]] が集約する Chapman の「no give backs ハンドオフ」(IC からインシデントレビュー担当EMへの一方向引き継ぎ)とは異なる、IC間の双方向引き継ぎである。両者を比較した運用上の違い・失敗しやすいポイントはどこにあるか。 - 士気管理(食事・睡眠・ストレス発散・燃え尽き察知・模範を示す)という ch17 の実践は、[[人的要因]] や [[レジリエンスエンジニアリング]] が扱う人的パフォーマンスの理論とどこまで接続できるか。 ## 関連 - [[インシデント管理]] — 本概念が対象とするインシデント対応ライフサイクル全体 - [[Incident Commander]] — IC という役割そのものの定義・起源・組織モデル。本概念はその運用の時間発展を扱う - [[インシデント対応成熟度モデル]] — 本概念が前提とする組織的な事前準備の成熟度 - [[インシデントシミュレーション]] — Solo Artist / Band Member 等、負荷分散の実証知見 - [[インシデント対応時の運用セキュリティ]] — 危機時の指揮系統と並行して求められる、調査活動そのものの秘匿 - [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 17 Crisis Management]] — 本概念の中心的ソース - [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 16 Disaster Planning]] — 事前準備(チームチャーター・運用パラメータ)を扱う姉妹章 ## 出典 - Matt Linton (with Nick Soda and Gary O'Connor), "Crisis Management", in Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 17. - Michael Robinson and Sean Noonan, "Disaster Planning", in Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 16.