ICS(インシデントコマンドシステム：緊急指令システム)と事業継続計画(BCP) (4)
ICS(インシデントコマンドシステム：緊急指令システム)の内容と組織体制の続きです。
今回は組織/体制です。
ICSは5つの機能(チーム)を持ちます。
コントロール可能な管理スパンのところで触れたように、人間一人が対処できる相手の人数には限りがあり、3人から7人くらいまでで、最適な数は5としています。
ICSでは指令部門の下に、4つの部門（実行、計画、調達、財務）がぶら下がるようになっています。
1. 指揮本部（Command）
全体の指揮をとり、責任を持ちます。活動の優先順位や目標設定を行い、競合問題などの解決を図ります。
日本のいわゆる災害対策本部に相当しますが、計画・情報収集機能が別チームになっているなど違いがあります。
2. 実行部（Operations）
ここが実際の復旧活動を行います。施設、セキュリティ（保安）、情報システム、通信などを含む最も大きな組織です。
日本の一般的な災害対策組織では、情報システムを独立したチームとして扱いますが、ICSでは、業務復旧活動の一要素として他の要素との密接な連携を図るため、実行部の中に組み込んでいます。
3. 計画部（Planning & Intelligence）
情報収集を行い中身を精査して共有を図ります。
BCPの中で実際に必要になる行動の提案を行います。
日本の一般的な災害対策組織では、この計画機能は災害対策本部に含まれて喧々諤々議論して、その場のトップダウンで決めるやり方を採っていると思います。
ICSでは、復旧には即時的なもの、短期的なもの、長期的なものがあるので、冷静な頭を持って先も見ながら判断するのが重要と捉えており、計画機能を外出ししています。
災害対策本部との機能分担により、プレッシャーや長時間の対応による疲労から判断が鈍ることを防いで、負荷分散するということを狙っているようです。
4. 調達部（Logistics）
いわゆる後方支援機能として、施設、サービス、物資の供給を行います。
医療面での手当てや食料供給が第一の責任となります。
5. 財務部（Finance）
全てのコストの対する監視と文書化に責任を持ちます。
給与も含めた必要な資金提供を行います。
保険会社とも連携して会社や社員の保険金の支払いを担当します。
このようなICS型組織構造を持つと、情報の流れがスムースになり、混乱が減り、人員の派遣や物資の輸送などが効率よく速く出来るようになるとしています。
日本企業の組織風土になじまないと思われるかもしれませんが、現在の災害対策本部がうまく機能しない、復旧組織が細分化されすぎていてうまくマネジメントできていない、訓練をやってもいつも情報が錯綜して混乱している、などの課題をお持ちの場合は、ICSのエッセンスを取り込んでみることを検討されてはいかがでしょうか？
もう既にこれに似たことをやっているよという会社や団体の方がいらしたら、その効果などを書き込んでもらえると皆さんの参考にもなると思いますので、是非お願いします。
また感想、ご意見でも良いですので皆さんのフィードバックをお待ちしています。
最終更新時間 18:28 | コメント (0) | トラックバック
ICS(インシデントコマンドシステム：緊急指令システム)と事業継続計画(BCP) (3)
ICS(インシデントコマンドシステム：緊急指令システム)の内容と組織体制の続きです。
9つの考え方のうちの6つめからです。
(6) 強固なアクションプラン
これはゴール、作業目標、サポート活動を明確化することですが、インシデントの複雑さや規模に応じて、タイムフレームと共に決めていきます。
タイムフレームの長さは、24時間以内で、大規模のインシデントの場合12時間が一般的、インシデント発生直後は2～4時間位の単位となっています。
(7) 前もって定められたコマンドセンター(対策本部)
ポイントは2箇所は決めておくということです。
例えば本社が被災してしまうと、どこか他の拠点となりますが、地震のように交通機関が麻痺する場合、重要な人が自宅から通えるかといった点も考慮しなければなりません。
本社が地震に対して非常に脆弱、もしくは地域的に交通機関が麻痺する場所にある場合、2箇所目と3箇所目を決めておくのも有効でしょう。但し、その分、訓練もしっかりやっておかないといけませんんが。
(8) 総合的なリソース管理
災害発生時には様々なリソースが極端に不足する事態が発生します。スタッフの安全確保は勿論のこと、他地区からの応援要員、他地区での代替オペレーション、そのための交通手段や宿泊、物資の確保などが必要になります。
これはうまくアレンジしていかないと、早く要求したところに先にリソースがあてがわれたために、本当に必要なところには不足してしまうという事態も起こりえます。
そのためには、復旧もしくは継続すべき業務に対して、最低限どのくらいのリソースが必要なのかを予め決めておくのが有効です。
(9) 的確な情報収集・管理・伝達
災害時には情報が錯綜します。これをうまく収集・管理して、必要な人・場所へ伝えるには一定のルールを決めておいて、普段から訓練しておくのが重要です。
地震などの場合、発生直後は電気が止まり、電話などの通信手段も使えなくなる可能性が高いですが、時間を追うに連れて復旧していくはずです。
災害伝言ダイヤルは通信規制を受けている間は有効な手段ですし、Webサイトなども多くの人にタイムリーに情報を伝えるには有効です。
最近ではブログも一般的になったので、電子メールによるやりとりの混乱を解消する手段の一つとして、ブログを活用するのも手でしょう。
次回は、組織/体制について触れたいと思います。
最終更新時間 21:19 | コメント (0) | トラックバック
ICS(インシデントコマンドシステム：緊急指令システム)と事業継続計画(BCP) (2)
ICS(インシデントコマンドシステム：緊急指令システム)の内容と組織体制について触れてみましょう。
9つの考え方をそれぞれ説明します。
(1) コントロール可能な管理スパン（報告要員数）
例えば災害時に対策本部長に色んな部署から一斉にかつ非同期に報告が上がるとしましょう。数人なら何とかさばけますが、十人もとなると恐らく管理しきれなくなって混乱してしまうでしょう。
一人の管理者が対処できる部下の数は5人が最適と言われています。
これは災害対策本部の組織を階層的に持つ場合、参考になる考え方と言えるでしょう。今考えているBCPや既存の災害対策本部を見て、一つの部署に多くの部署がぶら下がっているようなところがあれば、要注意です。
(2) 用語の共通化
一つのビルの中に納まっている会社であれば、更に事業の種類も少なければ、用語も部門間で方言が生まれることは少ないかもしれません。しかし、複数事業を行って、地域的にも分散し、海外も含むとなってくると、意思疎通を的確に図るためにも用語の統一は不可欠です。
例えば災害対策本部といった場合、本社の本部を指すのか、地区の本部を指すのか、明確にする必要がありますし、めったに起こらないことへの対応なので、用語もできるだけ平易で誤解が生じにくいもので統一すべきです。
BCPの中にも、単に専門用語の解説という位置付けだけでなく、全社で共通に使う用語の明確な定義のページを必ず入れましょう。
(3) モジュール化され拡張可能な組織体制
BCでは災害の要因によらないで（最悪の事態を想定して）事前に準備するのが基本なので、緊急事態（インシデント）の規模や複雑さに係らず、全てのインシデントに対して対応責任者を明確にしておきます。
即ち組織構造としては、モジュール化されたものを集めてフルセットで定義しておき、実際に起こった災害の対象や影響範囲に応じて該当するモジュール（チーム）を活動させる方式をとります。
日本の場合、地震がもっとも気になる災害要因で、地震は影響範囲が広いという特性も持っているので、とりあえず地震でチーム編成を考えて（モジュール化）してみるのも良いでしょう。爆弾テロや疫病テロ対策は次の強化検討時に反映していきます。
(4) 統一的・明確な指揮系統
先ほどの用語の共通化でも触れましたが、地震など大規模な災害になった場合、複数の地域で対策本部を立ち上げて、人命救助や復旧作業を進めると共に、被災していない地域も重要な役割を占めるようになります。
その際複数組織が混乱無く対応にあたれるよう、指揮権の確立や委譲を定義しておきます。
BCPの中で体制図が出てきたら、各組織間の位置づけと役割、災害時の役割の変更手順などを出来る範囲で事前に決めておきましょう。
(5) 統合化されたコミュニケーション
災害時にもっとも重要な一つが情報の流通（コミュニケーション）です。ここでも標準化された運用手順や手段、用語を使うことが鍵になります。
また災害時に使える手段は時間を追って変化していく（増えていく）可能性が高いので、安否確認システムなどでも、複数手段をカバーできるようなものを選んで、かつ使えるようにして、普段から訓練しておくことが肝要です。
残りについては次回にまた解説します。
