アメリカには、災害対応にルールがあるのをご存知ですか？災害だけではありません。あらゆる危機の発生時に、どのように対応計画を立て、どのような組織編制で、どのような指揮調整の方法によって関係機関が連携しながら対応にあたるかが、「Incident Command System」（ICS）と呼ばれる統一化されたルールが定められているのです。

何のためのルールか？

それは、異なる人々が、1つのチームとして連携して対応にあたれるためのルールです。例えば、統一した用語を使うことや、一人の上司が管理できる部下の数を決めておくこと、さらにリーダーなどが権限を委譲する時の引継ぎ方法などなど、細かく決められているのです。これらを日常組織に応用したらどうでしょう？

例えば会社などの組織でも、トラブルが発生すると、連携が乱れるようなことは皆さんも経験があるかと思います。直属の上司が部下を指示するはずだったのが、いきなり別の部署の上司や、場合によって経営者が上司を飛び越して末端の社員に指示してみたり、あるいは、社長がすべて一人で指示を出そうとしてパニック状態になってしまったり、それぞれの部署の状況が共有できないなんてこともあるかもしれません。こうした際の対応を、しっかりルールで定めておくことで、危機に強い組織ができるのです。

それでは、アメリカのルールはどうなっているのでしょうか？

ICSの特徴を読み解きながら、組織間連携のポイントを整理してみたいと思います。

■森林火災から生まれたICS

Incident Command System の Incidentとは、その言葉通り事故や事件、災害などの事象を指します。「コマンド・システム」は、「管理するための規格」あるいは「枠組み」というような意味です。ハードのイメージを持たれてしまうと、「コンピューターセンター」のようなものを思い浮かべてしまうかもしれませんが、「規格」とか「枠組み」という意味で理解していただければと思います。ちなみに、アメリカでは災害や事故の規模によって、Incident、Emergency、Disaster、Crisisなど言葉を使い分けていますが、ICSのポイントは、災害だけでなく、小さな事故や事件でも、適用が可能ということです。

ICSの開発の経緯は、1970年代まで遡ります。当時、米国カリフォルニア州で発生した森林火災の現場で、組織内外で連携がうまくいかなかったという反省から生まれたものだと言われています。例えば、用語や組織体制、資機材の規格に至るまで、標準化されていないと異なる組織間での連携はうまくいきません。このような反省から1980年代には全米の森林火災の現場で採用されるようになり、1990年代以降は、他の災害やオリンピックのような国際イベントでも採用され、米国ではNIMS（National Incident Management System）という規格によって、全米の州政府、市政府が、このICSを根幹とした災害対策本部を設置することが決められています。

近年では、アメリカだけでなく、イギリス、カナダ、オーストラリアなどでもICSを独自に定めるようになってきており、日本でも内閣府が音頭をとり、ICSなどを参考に、災害対応の標準化に向けた議論を始めております。阪神・淡路大震災では消防車のホースの太さが異なり連結ができなかったなどの問題があり、こうした不具合を消防では早くから解決し、今では緊急消防援助隊など、全国規模での連携活動が実現されるまでにいたりましたが、東日本大震災では、国と都道府県、自治体の連携、あるいは警察と消防、自衛隊の連携など、すべてがうまく機能したわけではなく、今後、首都直下地震や南海トラフ地震などの巨大災害に備えるにあたり、各組織が速やかに連携できるルールづくりが求められているわけです。

■ICS14の特徴

さて、それではさっそく、ICSで書かれている危機対応の基本的なルールのうち、非常に象徴的とされている14の特徴について解説します。

ICSは、FEMA（アメリカ合衆国連邦緊急事態管理庁）によって、教育プログラムがレベル別に定められていますが、FEMAではICSの特徴を次のように整理しています。

１　統一された用語の使用(Common Terminology)

２　権限の委譲ルールの明確化(Transfer of Command)

３　指揮命令系統の統一(Chain of Command & Unity of Command)

４　複数組織が関与する現場での統一指揮(Unified Command)

５　目標による管理(Management by Objectives)

６　災害対応計画(Incident Action Plan)

７　事案規模に応じた柔軟な組織編制(Modular Organization)

８　監督限界(Manageable Span of Control)

９　統合された資源管理(Comprehensive Resource Management)

10　統合された空間利用(Integrated Facilities Management)

11　統合された通信システム(Integrated Communications)

12　情報処理マネジメント(Information and Intelligence Management)

13　説明責任(Accountability)

14　人員、資機材の投入(Dispatch/Deployment)

■用語の統一「Common Terminology」

まずは、用語の統一「Common Terminology」について。ICSでは、組織の機能や、対応施設、資源、職位については共通用語を使うことを定めています。なぜでしょう？

それは複数の組織が連携する上で、こうした用語が共通化されていないと、混乱を招いてしまうからです。例えば、自分の組織では、本部長、部長、班長、係長、主任と呼び方を決めていたのに対し、別の組織では部長、課長、準課長、班長など、職位の名称が異なっていたら、連携する上で、誰の下についたらいいのか混乱してしまいますよね。また、施設についても、例えば、ある組織が、東京にある施設を「T１」、新潟にある施設を「N１」などと略した呼び名で使っていたら、災害対応で連携する場合、他の組織に「T１に行ってくれ」と言ってもおそらく通じません。ですからICSでは共通用語について、意思疎通能力の向上に不可欠であると強調しています。

会社ならどうでしょう？　日常的には、役職の名前や施設の名前が統一されていないなんてことはまず無いでしょう。でも、会議などで、資料にしっかり名称がついていなくて混乱したようなことはございませんか？　会議が度重なるたびに、資料が多くなり、「事業計画書」「売上計画書」「事業戦略計画書」「マーケティング計画書」など混乱し、しまいには「あの時の資料を持ってきてくれ」「あの時の資料って何ですか」なんていう会話が飛び出すことに。極端な例ですが、こうした資料１つ１つも名称をしっかり決めておくことが重要ですね。特に、普段一緒に仕事をしていない異なる部門や関連会社との会議などでは、用語の統一というのは特に気を付けるべき点だと思います。

■権限委譲のルールの明確化（Establishment and Transfer of Command）

次に権限委譲のルール（Establishment and Transfer of Command）について。

災害では、発災当初から、対応にあたる組織の指揮機能が明確に確立されていることが求められます。しかし、せっかく指揮機能が確立されていても、部隊が入れ替わるなど、災害対応にあたる指揮者が移動するような場合は、災害対応に空白の時間が生まれかねません。そこで、ICSでは、指揮者が入れ替わる時、安全かつ効率的に対応が引き継がれるように、配慮すべき点を細かく定めています。

例えば、最新の災害情報に更新されているか確認する、可能であれば災害地域を示すできだけ大きな地図や表を用意する、何を言うべきか自分の意見をまとめておく、「災害ブリーフィングフォーム」を作っておく、

以下はブリーフィング時にカバーしておきたいチェックリストの例です。

□最新の書式のコピーを交代指揮官に渡せるようにしておく

□地図や表など、被災地域や詳細を説明できるようなものを使用する

□現状況を説明する（災害状況マップのようなものを見たままに塗りつぶす）

□初動対応の目的と優先順位を説明する

□現状の行動や作戦を議論する

□やろうと計画していたことを復習しておく

□自分の築いた組織について復習しておく

□自分の考えておいた組織改編について議論する

□現場でどのように援助資源を活用したか復習しておく

□援助資源をどのような流れで調達し、計画した行動をどのようにサポートしたのか概要報告を準備する

□コミュニケーションの状況を与える

□災害の全体像評価をまとめておく

ここまで決めておかなくてもいいのではないかとも思いますが、このように整えておくことで指揮官が替わった際でもクオリティを下げることなく災害対応が引き継げるようにしているのです。

さらに厳しい言い方をすれば、災害対応では誰もが指揮者になり得るということです。最初の部隊が現場に到着した時点から災害対応は始まります。現場に居合わせたのが、末端のスタッフだったとしても、他の応援部隊が来るまでは、居合わせたスタッフの中で指揮者を決め、対応に当たらなくてはなりません。「誰もが指揮者になり得る」。こんな当事者意識もICSを考える上で、とても重要なキーワードになると思います。

もちろん、日常的な会社の業務にといても、リーダーは、いつでも業務を引き継げるように準備しておく必要があります。そしてリーダー以外の人は、いつでもリーダーになり得る自覚を持って業務に取り組むことが理想です。

■指揮命令系統の統一(Chain of Command & Unity of Command)／複数組織が関与する現場での統一指揮(Unified Command)

指揮命令系統の統一(Chain of Command & Unity of Command)と複数組織が関与する現場での統一指揮(Unified Command)については、セットで解説した方が理解がしやすいと思います。

ICSでは、指揮系統の原則として、一元指揮（Unity of Command）と統合指揮（Unified Command）という2つの概念があります。

一元指揮は、上司と部下のように縦のラインについてルールを定めており、具体的には、「一人の上司から命令を受ける。それに対して報告するのも一人の上司」という権威の明確な一元制が謳われています。この原則に基づく組織体制を、Chain of Commandと呼んでおり、報告関係を明確にすることで、管理体制の矛盾などによって引き起こされる混乱をなくすことを目的としています。

災害対応に限った話ではなく、日常的な組織運営においても同じでしょう。ある現場のスタッフに、様々な現場の上司が命令したのでは、そのスタッフは何から何をしていいのか分からずパンクしてしまうでしょう。

「そんなことは当たり前」と思われるかもしれませんが、例えば、社長が突然現場に視察に来て、いきなり末端のスタッフに指示をする、なんてことは起き得ますよね。皆さんが末端のスタッフだったらどうしますか？指示されたスタッフは対応せざるを得ないでしょうが、そんなことが大きな混乱を引き起こすきっかけにもなりかねません。福島第一原発事故でこのような事態が起きたことは今更説明するまでもありませんが、これを徹底するには、トップもしっかりとこうしたルールを認識しておく必要があるということです。

もう1つの統合指揮（Unified Command）については、災害対応に係る主要な組織の現場指揮者によるチームワークについてのルールを定めたものです。文化の異なるさまざまな組織を、一貫性を持たせて単一の指揮命令系統のもとに任務を遂行させることを目的としています。

例えば、州の境界をまたいだような災害や、連邦政府と州と地方自治体のように多様な行政レベルが係る場合、あるいは、石油会社や学校など民間産業や公的機関が加わる場合など、それぞれの組織が個々の指揮官のもとで対応にあたったのでは、例えば重複した場所でバラバラに救助・捜索活動を行うなど、効率の良い作業は期待できません。

逆に、これらがあたかも1つの組織として共同で指揮が執れれば、災害対応の目的や優先順位が共有でき、24時間7日間といった具合に作業を引継ぎなら長期間継続できるようになるなどさまざまなメリットが生まれます。

そこで、ICSでは、統合指揮を行う上でのルールとして◇統合指揮に入るメンバーを明確にすること、◇それぞれの管轄や組織にとっての目的と優先順位を明確にすること、◇それぞれの管轄や組織にとっての制限、考慮すべきこと、優先順位についての合意を図ること、◇基本的な組織構造についての合意を得ること、◇最高の資格を持ち、最も受け入れやすい実行部隊の長と副長を任命すること、◇対応のスタート時間とオペレーショナルピリオド（対応期間）を明確にすること、◇組織の構成スタッフ（一般スタッフ、計画担当、ロジスティック担当、ファイナンス担当）を明確にすることなどを決めることを求めています。

2012年にロンドンで開催されたオリンピック運営について取材をしたことがありますが、政府機関ODA（Olympic Delivery Authority:オリンピック運営局）や関連団体であるLOCOG（London Organising　Committee of the Olympic and Paralympic Games：ロンドンオリンピック・パラリンピック組織委員会）など、それぞれが統合指揮のもとで、役割を決めて準備・運営を行っていました。会場が異なったり、競技種目が異なったり、あるいは環境面への配慮や危機対応への配慮など管轄別に管理体制を決めていました。大規模になればなるほど、一定の秩序が必要で、そのルールを定めているのがICSと言えると思います。

■目標による管理(Management by Objectives)

次に目標による管理(Management by Objectives)ということについて解説します。目標による管理は、ICSの概念の中で、私が最も好きなものの１つです。危機対応に限ったことではなく、経営などでもよく使われている言葉のようです。ウィキペディアにも解説が載っていますが、それによると、「個々の担当者に自らの業務目標を設定、申告させ、その進捗や実行を各人が自ら主体的に管理する手法」とあります。1950年代に米国のピーター・ドラッカーが提唱したと言われています。一人ひとりに対して、いろいろ細かに指示するのではなく、組織と本人の目標がしっかりしていれば主体性が発揮されて結果として大きな成果が得られるということです。

危機対応においては、組織全体の方針のもと、インシデントの状況を評価し、対応するための体制を確立し、適切な戦略・戦術にもとづいて、かつ、インシデントの状況の推移をフォローできるような目標の設定が重要とされています。

目標を設定する上での優先順位は、LIP（Life Safety:生命の安全、Incident stabilization：災害の安定性、Property protection：財産の保護）という順番になります。命を優先するのは当然だと思われるでしょうが、緊急時には、こうした基本がおろそかにされるケースが多いように思います。例えば、企業の不祥事はどうでしょう？　食品の異物混入などで、消費者の人命に関わるような事態であっても、企業の風評などを懸念して記者会見が遅れてしまうケースなどは、その典型です。

ICSでは、効果的な目標を設定するためにSMART（賢いという意味）に掛け合わせて：Specific（特定的）、Measurable（測定可能）、Attainable（達成可能）、Realistic（現実的）、Time sensitive(即自的)であることを求めています。

ただ、ここまで細かく目標を設定していなくても、組織としての「目的」を明確にして共有しておくたけでも、危機対応においては十分に効果があると考えています。災害に限らず、組織内で様々なハプニングが発生したとき、その時々に、上司が対応を指示していたのでは、時間ばかりがかかり、逆に事態は悪化しかねません。ですから、「現場に任せる」ということが重要になると思うのですが、その際、現場がしっかりとした判断ができるようにするためには、組織として物事の目的をしっかり定めることが不可欠になります。一人ひとりが問題に直面した時に、目的に照らし合わせて自らの使命を分析し、行動を決定できるようにするというのがMBOの醍醐味です。

■災害対応計画（Incident Action Plan）

災害対応計画（Incident Action Plan）は、ICSにおいて不可欠なものと言っていいでしょう。あらゆる危機対応を進める上で、口頭であれ、書面であれ、計画が必要になります。ICSでは、この計画をIAP（Incident Action Plan）と呼んでいます。様式が統一されていないと災害対応において混乱を招くため、ICSでは、災害対応にあたるあらゆる組織が統一化されたIAPを作ることを求めています。

企業で事業継続計画を策定されている方なら「あぁ、BCP（Business Continuity Plan）のことか」と思われるかもしれませんが、少しニュアンスが違うようです。BCPは、被災時に備え、あらかじめ事業継続の手法などを策定しておくものですが、IAPは、災害が起きた後、実際にどう対応にあたるのかを定めるもの。事前計画（受け身の状態）ではなく、目の前に起きている災害にどう対応するか（攻めの状態）へ、体制を変える上で不可欠なものです。

具体的には、災害対応にあたる関係者に対して、いつの時点までに何を達成するのか、そして、どのような資源を使うかまで明確にします。したがって、達成すべき目標を記載した目標シート、組織構成をどうするかを示した組織図、組織ごとの行動計画、人材や資機材の割当表、その他、通信計画や、医療計画、地図、輸送計画なども加えられます。

「えっ、事前計画があるなら、その通りやればいい」と思われるかもしれませんが、危機というものは、残念ながら、想定した通りに起きてくれないことは、東日本大震災をはじめ、過去に何度も経験しているはずです。どこまでが想定通りなのか差はあるにしろ、やはり目の前に起きている事象に対しては、対処方針・計画を新たに考える作業が必要になります。だからこそ、特に組織のトップ、現場の指揮者には、計画通りに動けるようにするだけでなく、新たに起きている事態にどう対応するか、プランニングする能力が必要になるのです。

重要になってくるのは、「時間の区切り」という概念です。災害対応は長期化します。したがって、当面の計画でも期間を決めて行わないと、担当者はばててしまいます。このような時間の区切りをOperational Periodと呼びます。ICSでは、アルファベットのPの字を象徴的に使って災害対応が表されますが、Pの字の左下の棒の下の部分から災害対応は始まり（災害が起きるということが出発点）、その災害が起きたことに気付き、状況を分析して、ミーティングを開いて最初の対応方針・計画を決め、後は、Pの字の右の丸い部分を、ミーティング⇒対応⇒改善と、ぐるぐる回っていくというわけです。

つまり、災害対応においては、定期的に継続的に対応をマネジメントしていくことの重要性を示しているわけです

■事案規模に応じた柔軟な組織編制(Modular Organization)

Modular Organizationは、災害対応にあたる組織は、災害などの事象の規模に応じて拡大したり、縮小したり、組合せが可能な構成になっていなければいけないということです。ICSでは、Modular Organizationの目的として「組織が災害にふりまわされるのではなく、組織が災害をあやつらなくてはいけない」と説明しています。

例えば、イベントなどでも大きい規模になると、主催者が運営スタッフや受付係を外部にお願いすることがありますが、同じように、必要に応じて組み合わせが可能な体制にしておくというのがポイントです。大きすぎても、足りなくてもいけない、ちょうどいい適切なサイズにすることが重要です。その上で、ICSでは、災害などの危機対応を管理する上で、5つの主要な機能が必要になるとしています。その5つとは、指揮（Command）、運用（Operations）、計画（Planning）、後方支援（Logistic）、財務（Finance/Administration）です。

消火対応に例えるなら、「指揮」とは「火を消せ」と指示する人。「実行」は火を実際に消す人。「計画」は、火を消すための計画をつくったり、計画の進捗を管理する人。「後方支援」は、火を消す人のケアなどに当たる人。「財務」は、火を消すための費用を算出する人です。

災害の事象が小さければ1人が何役も兼ねることもあるし、大きくなれば、それぞれ役割分担をすることもあります。ただ、少なくても、これらの主要機能が必要になるし、そのことを明確にしておくことが、必要に応じて拡大・縮小するなど組み立て可能な組織が作れるようになるということです。日常業務の組織体制ですべてがあたはまるとは限りません。しかし、指揮、運用、計画、後方支援、財務といった主要機能が常に補完されているかという視点で組織編制を見直すことで、改善が図れることもあるでしょう。

■監督限界(Manageable Span of Control)

監督限界（Manageable Span-of-Control）は、危機対応時に管理者が報告を受けられる人数の限界について示した概念です。ICSでは、1人の管理者が報告を受けられる人間の限界数を3人から7人、できれば5人が最適と言っています。変なことまで決めているものですね。この話を最初に聞いた時は、私も何を言っているのか、さっぱり意味が分かりませんでした。

このSpan-of-Controlが意図することは、災害が発生しているような緊急時に、多くの人が一斉に1人の管理者に報告をしたら、その管理者は情報を処理しきれなくなって、正しい判断が下せなくなる恐れがあるということです。皆さんの組織でも、本部長の下に、いくつも災害対応班が並列で連なっているようなところはあるのではないでしょうか。もちろん、それらが機能しないと言っているわけではありませんが、Span-of-Controlの観点から、一度、体制の見直しを検討してみてもいいかもしれません。

■統合化された資源管理:（Comprehensive Resource Management）

次に統合化された資源管理:（Comprehensive Resource Management）について解説してみたいと思います。

危機対応に必要な「資源」とは何でしょう？　人、資機材、飲み物や食べ物、被災者への支援物資、災害対応なら瓦礫類を型付けられるブルドーザーなどの特殊車両、人を救出できるヘリコプター…、いろいろありますね。しかし、普段顔も合せたことがないような異なる組織が、それぞれの資源を持ち寄って災害対応にあたったらどうでしょう？　しかも時間的にもバラバラに災害現場に搬入されたり持ち出されたりしたら…。

例えばヘリコプターについて考えてみましょう。東日本大震災では、消防のヘリ、海上保安庁のヘリ、自衛隊のヘリ、DMATのヘリ、警察のヘリなどさまざまな組織のヘリコプターが、災害現場の上空を飛びました。それぞれがバラバラに飛んでいたら、効率的な災害対応は行えません。　3.11では、県などの中間自治体の災害対策本部にヘリ統合運用班を設けて、各組織のヘリコプターの運用を統合管理したところもあります。

支援物資についても、いろいろなトラックが勝手に被災地に支援物資を運び入れたのでは大変です。その時々に、不足している物資を、不足している場所へ効率的に運ぶために、やはり統合的な管理が求められます。

資源の使用状況を、最新かつ正確に可視化しておくことは危機対応の重要な要素です。誰が、どこへ、何のリソースを注文したのか、リソースがどこから送られてきたのか、今どこにあるのか、など、こうした情報を共有できる仕組みが求められます。

アメリカでは、資源管理の必要性は、ICSが開発された1970年代から認識されており、古くからTカードというTの字型をした資源管理カードが使われているということです。Tカードは、資源の種別に、災害対応クルー（チーム）は緑、物資は小麦色、ヘリコプターは青、車両はバラ色、特殊機材は黄色、などと決められており、それぞれ資源番号、管理組織名、リーダー名、チェックイン時刻、発送元、行き先場所などが書き込めるようになっています。

■統合された空間利用(Integrated Facilities Management)

統合された空間利用(Integrated Facilities Management)では、「場所と施設」については、機能や、名称、表記の仕方などを細かく規定しています。

災害時には、発災場所の近くに、さまざまな支援施設が立ち上がります。現場指揮所や、ロジスティックの調整を行う場所、ヘリコプターをとめておく基地や発着場所、避難者が一時的に退避する場所や、水や食料などを与える場所、などなど。災害対応にあたるのは、同じ組織だけではなく、時には外部から地理的な感覚が無い人もたくさん応援に来るわけですから、こうした場所の名称やサインをしっかり決めておかないと、混乱が起きてしまいます。例えば、ベースなのかキャンプなのか、ヘリベースなのかヘリスポットなのか。何の役割の場所がどこなのかをしっかり決めておくことが重要です。

ですからICSでは、現場調整所とは具体的にどういうことを行う場所なのか、地図上ではどのようなマークで示すのか、一般的にどのような場所に設置するのか。

同様に、ヘリベースは…、ステージングエリアは…、などを細かに規定しています。

今、ある地域の防災計画の策定についてお手伝いをしているのですが、ここでも施設の名称や表記の仕方はちょっとした課題になっています。地図を見ると、広域避難所、避難所、一時（いっとき）避難場所という言葉が使われていて、中には指定避難所とか補助避難所、福祉避難所などを設置している自治体もありますが、さらにそれらが地震と水害で異なっているなど、正直分かりにくい！と感じることも多々あります。地図上での表記も、避難所と一時避難場所がほとんど同じで、これを住民の方に理解しろと言っても、難しいようにも思います。日本人で分かりにくいのですから、外国人ならなおさらのことでしょう。外国人とまで言わなくても、外部からの観光客ぐらいには、統一したルールで分かりやすい防災マップを示してあげることが、観光大国を目指す上で不可欠ではないか、とも考えてしまいます。

■統合された通信システム（Integrated Communications）

「統合された通信システム」（Integrated Communications）については、ハード（設備）だけでなくソフトも含め、操作要領や通信計画なども統合的に運用できるようにすることを求めています。

共通の通信機器を使い、共通の通信計画に基づいて運用を行うことで、危機対応者は他の対応者ともコミュニケーションが取れ、情報を共有できるようになります。通信は行政区や管轄を超えても運用できるようになっていなくてはいけません。日本はどうでしょうか？　

これについては、2013年4月に、ボストン・マラソンを襲った連続爆弾テロ事件の対応がとても参考になります。同事件を調査した元公益財団法人公共政策調査会の河本志朗氏によれば、ボストンでは、ボストン市を含む62の市町で構成される「ボストン都市圏」に、ボストン市救急部が運営する「中央医療緊急指令」というシステムがあり、そこがボストン医療情報センターと情報を共有し、圏内の病院に情報を伝え、さらにはマサチューセッツ州の「緊急事態対策センター」とも情報を共有し、さらに、一部の情報は警察ともリンクしており、消防、警察、病院、自治体の迅速な連携が実現したとしています。例えば、救急車が現場に到着すると同時に、各病院ではいつでも負傷者が受け入れられるよう体制を整える。あるいは、各病院の医療品の過不足、支援可能なスタッフの準備状況、予想される負傷の種類などもリアルタイムに情報共有したとのことで

す。

日本では、救急車が来たものの、患者の受け入れ先の病院が見つからないといったニュースが過去に何度かありましたが、こうしたシステムは導入を検討してもらいたいものです。

では、すべての関係スタッフが全員、統合された通信システムにより、あらゆる情報を共有すべきでしょうか？　例えば大規模な地震において、ある家でタンスが倒れて誰かが怪我をしたという情報は、あらゆる災害対応者間で共有されるべきでしょうか？　

残念ながら、ICSでも、どのような情報を、どのような範囲で共有できるようにすべきかまで、細かく解説されているわけではありません。ですが、普通に考えれば、統合された通信システムを導入したからといって、細かな情報まですべて耳に入ってきたのでは、雑音が多くなり逆に判断を鈍らせてしまうのではないかと危惧されます。

かつて、こんな質問を、ICSに詳しい京都大学防災研究所の林春男先生に聞いてみたことがあります。林先生の説明を引用させていただければ、「目的の達成に必要な情報を、目的を達成する関係者間で共有できるようにしておけばよい」ということです。つまり、ここでもICSの「目的による管理」（Management by Objectives）の原則があてはまるわけです。

SNS機能などを取り入れた災害時の情報共有システムが相次いで開発されていますが、個人的には、大切なことは「どれだけ多くの情報を共有できるか」ではなく、「どれだけ必要な情報を必要なスタッフ間で共有しやすいか」だと思います。監督限界（Span of Control）の概念ともかぶりますが、危機発生時に一人が多くの情報を管理することは難しく、雑音を少なくするというのも大切なことです。

■情報処理マネジメント（Information and Intelligence Management）

情報処理マネジメント（Information and Intelligence Management）については、情報トリアージと言い換えた方が分かりやすいかもしれません。要は、様々な情報の中から、対応に必要な情報を見つけ出すという情報を見極めるトリアージ活動が必要になるということです。

原文では「危機管理に係る組織は、情報の収集、分析、共有、管理にかかわるプロセスを確立しなくてはいけない」としています。そして、そのプロセスによって、さまざまな情報「information」から、危機対応に必要な重要な情報「intelligence」を導き出すべきだとしています。難しいようですが、日本語ではinformation もintelligenceも「情報」ですが、ICSでは、作戦に必要な情報を、普通の情報と区別してintelligenceという言葉で表現しています。

災害時には情報が足りないこともそうですが、誤報やデマも含め、さまざまな情報

が入りすぎてくる特徴があります。それらすべてを信じていたら危機対応が遅れるだけでなく、逆に危険な状況に組織を導きかねません。いかに早くinformationからintelligenceを導きだすのか、そのプロセスが必要だというのです。

では、危機が拡大する中で、いかにinformationからintelligenceを導き出す情報管理の仕組みを構築すればよいのでしょうか？

すでに紹介しましたが、危機対応においてはLIPという順位で優先順位を決定すべきとの原則があります。すなわち、Life Safety（救助・救命）、Incident Stabilization（被害の拡大防止、二次災害の防災）、Property/Environmental Conservation（財産の保護）です。これに基づけば、その局面、局面でどのような情報を優先すべきかは、ある程度理解していただけるかと思います。

東日本大震災で岩手県災害対策本部の医療班の指揮を執った岩手医科大学の秋冨慎司氏は、弊社のインタビューで次のように答えています。

「発災当初は8割以上の情報が誤報です。けれども、その中に本当に対応しなくてはいけないものが隠されています。そして、情報がないことが重要な情報だったりもするのです。日本では、正しい情報が常に入ってくることを前提に災害対応を考えますが、実は情報マネジメントの必要性を理解していない。情報の質、信頼度を精査していないのです」

そして、本当に対応すべき情報を選び出す基準については「信頼度が低くても人命にかかわるような重要なことに対しては対応度をあげないといけない。逆に、信頼度が高くても優先度が低ければ後回しにしなくてはいけない…」と話しています。

これこそLIPに基づく情報（intelligence）の選定方法だと私は思います。では、命に関する情報を優先するだけでいいのでしょうか？　いえいえ、そういうわけでは

ありません。重要なのは「必要な情報を導き出すプロセス」です。

2011年11月に危機対応の国際規格であるISO22320（2013年10月にJIS）が発行されましたが、ICSの内容は、このISO22320の中にも色濃く反映されています。今回の「情報処理システム」（Information and Intelligence Management）については、「活動情報」“operational information”という章で解説されています。

そして、operational information（活動情報）については、「計画策定および指示」「収集」「収集処理および操作」「分析および作成」「配信および統合」「評価およびフィードバック」の6つのステップが必要としています。かなり高度な内容のように感じられますが、簡単に言えば、どのような目的を達成するための情報が必要なのか、その計画を策定し、スタッフに指示をしなくてはいけないということ。その上で、必要と思われる情報を収集し、その情報が果たして、本当に目的を達成する上で役に立つものかどうかを分析し、それを関係者に配信する。例えば時間帯の異なる2つの情報を統合することで、役立つ情報になることもありますし、断片的なものをいかに組み合わせるかといった視点も求められます。いずれにしても配信した後はその情報を評価し、改善していかなくてはならない。この繰り返しをPDCAサイクルとして行うということが書かれています。

■説明責任(Accountability)

説明責任(Accountability)は「透明化の確保」とも言い換えることができるでしょう。誰がどのタイミングで災害（対応）現場に入ったのか、どのような対応計画を立てているのか、どのような指揮命令系統になっているのか、資源がどのように管理されているのか、など、これまでに解説してきたICSの各項目が透明性を持って明確に説明できなくてはいけないということです。そのため、ICSでは、さまざまなテンプレート（ひな形）が用意されています。日本の地域防災計画や防災マニュアルでも、もっとテンプレートを多く入れては、と思うのですが…。

■人員、資機材の投入(Dispatch/Deployment)

最後は「人員、資機材の投入」(Dispatch/Deployment)について解説したいと思います。

ICSには「人員、資機材は、関係当局から要求があった時、あるいは派遣された時に限って対応しなくてはいけない」と書かれています。

何だか難しい文面ですが、要は、必要な時に必要な人・資機材を、必要な場所に投入できるようにするということ。

これは、イベントの運営を危機対応に例えると、とても身近に、分かりやすく説明することができます。例えば、運営主体社が、必要以上のスタッフや資機材を現場に取り入れてしまうと、現場で混乱を招き、逆に必要な行動に支障をきたすようなことが多々あります。例えば、小さなイベントにも関わらず、たくさんの運営スタッフを動員すると、たいていの場合、やることが無くなったスタッフは受付の近くでぶらぶらし始めて、最悪の場合、そこでおしゃべりをして、入場者の妨げになるようなケースがあります。同様に、無線機などの通信機材を必要数以上に入れると、やはり、どうでもいいようなおしゃべりで無線機を使う人が出てきて、来場者から「うるさい」なんて叱られる始末になるなんてことも…。いずれも、極端な例ですが、目的のはっきりしない人員や資機材は、管理しようがないということです。災害対応は、繰り返しになりますが、複数の文化が異なる組織が集まり、1つの目的に沿って対応にあたることが求められます。

東日本大震災では、自衛隊、消防、警察、自治体、ボランティア組織など、災害直後から、多くの組織が、スタッフを現場に派遣し、数カ月後には現地からの引き上げが始まりました。全体を俯瞰すれば、災害対応に応じて、必要な人、資機材が必要な時期に投入されたと言えるかもしれませんが、現地に入り込んでみると、医療品が足りない状況が続いていたり、何か月も立って毛布類などがあまりはじめているのに毛布類が現場に届いたり、とまだまだ課題もあるように思いました。

必要な時に、必要な人・資機材をしっかり投入できるようにしておくということは、それだけ計画が緻密につくられていないと絶対に実現できません。そしてその計画が、関係者間で共有されなくてはならない。ですから、ICSでは災害発生後に災害対応計画（Incident Action Plan）をつくり、それを定期的に見直し、関係機関と情報共有を図りながら、必要な人員、資機材についても見直していくことを推奨しているのです。

■おわりに

さて、ICSについて原則とも言える特徴について説明してきましたが、ICSにこの特徴のことが、事細かに解説されているわけではありません。ICSでは、この特徴に基づいて、具体的に組織構造のことや、計画の策定方法、説明方法、現場指揮者やスタッフの責任や役割などが細かく説明されています。言い換えれば危機対応の「ルールブック」です。

私がICSを学んで良かったと思ったことは、いろいろな災害や事故対応を検証する上での評価軸ができたことです。災害だけでなく、事故や不祥事への対応を見るとき、あるいは自分がちょっとしたトラブルに直面した時、ICSの考え方に照らし合わせるとどうなんだろう、と客観的に考えることができるようになりました。検証ができるようになれば、改善を行えるようになります。災害や事故の歴史を積み重ねていく上で、同じ間違いを繰り返さないようにするためにも評価軸が重要になります。ICSは危機対応から教訓を導き出し、再びおなじ過ちを犯さないようにしていく、改善のツールでもあると思うのです。

最後に、私個人としての意見ですが、アメリカのICSをそのまま日本に当てはめることは、言葉も（たとえ翻訳したとしても）文化も違い無理があると思います。しかし、これまでにメルマガで紹介してきたような特徴・考え方は大いに参考になりますし、日本も日本なりの災害対応のルールを日本のICSとして決めていくべきだと思います。