勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

Incident Command Systemについて調べた

Google SRE本を読み終わった。いや、これはすごい本だ。しかし非常に広範囲なプラクティスの詰め合わせ(というか論文集だ)のため、完全に消化不良である。ゆえに、同書で気になった箇所を少しずつ整理検討しているのだけれども、そのひとつがIncident Command Systemである。これはすぐに使いこなしたいプラクティスだと思っている。まぁ、仕事の規模や質次第かも。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

Incident Command Systemとは何か?

14.3 インシデント管理のプロセスの構成要素
インシデント管理のスキルとプラクティスは、熱意ある個々人のエネルギーを正しい方向に向けるために存在するものです。Googleのインシデント管理のシステムは、明快でスケーラブルであることで知られるIncident Command Systemに基づいています。
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

  • いや、知られていないよ!知らなくてごめんなさい!
  • 英語版は全文公開されているので、興味があればこちらから該当箇所が読める。Google - Site Reliability Engineering

何かと思ったら、災害(障害)発生時の対応組織をボトムアップに(ブートストラップ的に)構成する標準化されたマネジメントシステムだった。消防とか警察とか軍事関連のように見える。いろいろ調べてみたけれども、以下のWikipediaの記事が一番わかりやすい印象。

  • インシデント・コマンド・システム - Wikipedia
  • 1人の監督者(インシデント指揮者)が5-7名までのメンバーで構成される臨時組織を立ち上げて問題に対処する。指揮者の監督限界を超えた場合は組織を分割しなければならない。
  • 指揮、実行、計画、後方支援、財務・総務の5つの機能をチームで分担して実行する。

米国では、1970年代、多くの山火事が発生し、当時の現場指揮官が、

  • 一度に多くの人が、一人の監督者に報告するので処理しきれない(上がって来る報告を溜めるバッファがない)。
  • 関係機関がそれぞれ異なった組織構造になっており、組織的な対応が困難。
  • 信頼のおける情報が流れてこない。
  • 通信装置や通信手順が統一化されていない。
  • 関係機関の間で共通の計画を策定するシステムがない。
  • 指揮命令系統が不明確。
  • 関係機関が使用する用語が統一化されていない。
  • 目標が不明確。

等の多くの問題に直面したため、1979年に消防大学校(Fire Academy)が次のコンセプトの下で「ICS」を開発した。
インシデント・コマンド・システム - Wikipedia

というわけなので、ITシステムの障害対応においても上記のような対応の失敗や課題に直面したことがあれば、採用検討に値するものではないかと思っている。