タイムライン(事前防災行動計画)に関する疑問

台風10号の本土接近に伴い台風関連のニュースが増えており、昨日のNHKでは、台風に対する事前防災対策で米国では「タイムライン」と呼ばれる手法が幅広くとられているかのような報道があった。国土交通省などが検討しているようだが、この手法がとれるのは、台風など、ハザードの発生からインシデントの発生までに時間的余裕がある災害に限られており、しかも、台風にもピンからキリまである。

まず、米国でさも幅広く導入されているかのような報道だったので、検索してみたが、「timeline hurricane」 などでは、全く報道されているような防災行動計画はヒットしない。そこで、日本で紹介されている資料でNew Jersey州にて導入されており、成果を上げていると記されているので、「timeline new jersey sandy」としても、Sandy災害に関する時系列の履歴としてのTimelineが出てくるだけで、事前防災対策としてのTimelineなどという資料は、ひとつも出てこない。そこで更にこのキーワードにpreventionを加えて、「timeline new jersey sandy prevention」とググるとやっとそれらしい英文資料が表示されたので開いてみたら、なんとそれは日本の国土交通省がアップロードした資料だった。国土交通省が嘘をついているとも思えないのでニュージャージ州ではそのようなtimelineもどきの内部資料が確かにあるのかもしれないが、検索してみた限りにおいては、ニュージャージー州として公表されている資料もなく、また、全米で幅広く導入されているという形跡もない。New Jersy Office of Emergency Managementにも”Timeline”などという仕組みの紹介は皆無である。

NHKで紹介されていたタイムラインという手法は、プロセスアプローチによって資源配分をしようとしているに過ぎないだろう。プロセスアプローチとは、時間軸に沿って成すべき仕事を定義し、それに対して資源(人、物、金など)を割り当てていく手法である。プロセスアプローチ自体は、さまざまなマネジメントシステムにて導入されているもので、決して珍しいものではない。ただし、このプロセスアプローチは、インプットからアウトプットまでの流れが明確に定義できる場合に限られる。企業の商品生産であれば、作るべき物は明確であるし、それに必要な原料や工程もすべて明確にすることができる。しかし、災害の場合はどうか。一部のパターン化した台風だけを取り上げれば、それに対する対応策のプロセスは確かに明確にできる。しかし、通常の災害は千差万別でどのような形で襲われるか予測もつかないものばかりであり、何の予告もなく、突然やってくるものばかりである。台風は、発生から上陸まで数日という余裕があるが、他の災害にそのようなものはない。

そもそも、米国の防災はオールハザードを基本にしている。すなわち、個別のシナリオに基づいて防災計画を立てるのではなく、どんな種類の災害に対しても対応できるよう柔軟なものになっている。その基本にあるのは、プロセス・アプローチではなく、「ファンクショナル・アプローチ」である。米国インシデント・マネジメント・システム(NIMS)にも書かれているように、現場においてはICS(Incident Command System)、支援活動についてはESF(Emergency Support Function)を採用し、いずれもファンクショナル・アプローチ、すなわち、時間軸や災害種類にとらわれない機能(Function)が基本に置かれている。オールハザード防災の核はこのような「ファンクショナル・アプローチ」である。従って、私には、米国が日本で紹介されているような「タイムライン」なる手法を幅広く推奨しているとは、信じがたい。ごく一部の州がハリケーン対策のためだけに独自にタイムラインなる手法を使っているのかもしれないが、あまり、一般的なものではないはずである。

なお、インシデントとは必ずしも実害の発生を意味しないので、ハリケーンの発生をもって、インシデントの発生と解釈し、ICPを立ち上げ、指揮官を置くということもできるはずであり、そうなると通常のインシデント・マネジメントである。恐らく、普通の州ではそうやっているのではないだろうか。

いずれにせよ、このタイムラインなる手法を進めようとしている人々は調査が不足しているのではないだろうか。全米標準のインシデント・マネジメント・システムとの関係を含め、理論的説明が全くない。単純に「アメリカでやってうまくいってますよ。」という主張をしているに過ぎないようだがそれにしてもその証拠もあまり見当たらない。この手法は、伝統的なシナリオベースのアプローチの一種であり、オールハザード化に逆行するものなので、当方から見ると、あまり、望ましい手法とは思えない。

保健所のICS

災害対応の業務における問題
・市役所と保健所でマニュアルの内容が異なる。 (方針が異なって調整されていない。)
・情報が来ない。
・連絡を取ることもままならない。
・上からの指示が来ない。
・自分たちの役割がわからない。
・市でも保健所でも同じ内容の会議をしている。
・ここの責任者は誰だ? ・A病院はいっぱいなのに、B病院は患者がいない。 (資源の活用アンバランス) などなど

災害時に起きる問題の 大部分は、 技術・知識の問題ではなく、 管理の問題です。

情報源:ICS理論から入る 危機管理調整システムの理解 – 全国保健所長会

ネット上にあるICS関係の資料は、誤解が多く正しく理解していないものが非常に多いのだが、この資料は、正しい理解に基づいた非常に良いプレゼンテーションだと思う。ICSは、アメリカの真似をしてICSごっごをしたところで何かが直ちに改善するというようなものではないので、このプレゼンテーション資料にあるようにその背景にある理論を学び、なぜ、このような仕組みを標準化することが合理的なのかを理解し、自分たちで、自分たちの組織に合わせて、仕組みを構築することが非常に重要である。

保健所や病院は、災害時に大混乱をする最前線であり、たぶん、現場でのマネジメントの重要性が理解できるのだろう。この資料からは真剣さが感じられる。もっと、このような理解を促進する必要がある。

 

 

マニュアル化は善か悪か?

最近、畑村洋太郎氏の失敗学に関する書物を読んでいて思ったが、畑村氏は、マニュアル化を悪と捉える傾向が強すぎる。例えば、

マニュアルに従っていると、自分の頭で考える過程が省かれてしまいますから、表面的な部分しか理解されず、いつしかマニュアルのもつ真の意味が忘れられてしまいます。それが、「偽のベテラン」を生み出すことにもつながり、同じ失敗を何度も繰り返すことになる・・・・

畑村洋太郎[2011]、『「想定外」を想定せよ!―失敗学からの提言』、NHK出版、P130)

しかし、これはマニュアル化の程度による。マニュアルに何を書くかは、人それぞれ、組織それぞれであって、マニュアル化と一言で言いきれるほど共通した概念はない。要はマニュアルに何を書くかという問題である。あまりにも細かく書きすぎ、個人の裁量の余地をなくすような書き方をすれば確かに人は自分で考えなくなるが、マニュアルに思考のプロセスや問題解決ツールの選択枝だけ記しておき、その都度、最善の策を考えさせるような書き方もできる。このようなマニュアルであれば、マニュアルユーザーの思考を支援しているだけとなり、問題解決の方法まで強要していることにはならない。

畑村氏の言うように日本のマニュアルというのは細かく決め過ぎの傾向が確かに強いとは思う。例えば国や各地方自治体が定めている防災基本計画も一種のマニュアルだが、「誰(どの組織)が何をするか」を細かく決め過ぎているように思う。人や組織などを「資源」、その仕事を「機能」と呼ぶならば、資源と機能の関係が固定的過ぎる。大災害などが発生した場合には、様々な資源に被害が生じるので、予定された資源が予定通りの機能を果たせるとは限らない。必要な機能が果たされるならば、それを提供してくれる資源は何でもよいわけであるので、マニュアルには、災害時に必要とされる機能(すなわち仕事の内容)やプロセス(すなわち仕事の順序)を明記するにとどめ、その機能を果たすことができる資源にはこんなものやこんな組織がありますよ、と例示するだけにするならば、柔軟性が増す。

マニュアルには2つの書き方があるように思う。①「誰が○○○する」というように主語を明確にする方法と②「○○○がされるべき」というように受動形で主語や方法を固定的に示さない方法である。災害(インシデント)が発生する前に行うべき作業については①の方法でよいと思うが、災害(インシデント)が発生した後の作業については②によった方がよい。日本の防災基本計画などのマニュアルの最大の問題点はインシデントの発生前(災害予防)と発生後(災害応急対策)のことがひとつのマニュアルの中にごっちゃになっていることである。インシデント発生後の作業マニュアルについては切り離して②の方法によった方がよい。なお、②の方法はファンクショナルアプローチと呼ばれるものだが、日本でファンクショナルアプローチと言ったところで、何のことだかわからない人が大半である。

機能を先に定義し、あとから、それに必要な資源を割り当てるという考え方は、大前研一氏らが説く「戦略的自由度(Strategic Degrees of Freedom(SDF))」*を高めるという考え方と全く同じことである。

大前研一[2016]、『「0から1」の発想術』、小学館

大前氏は、商売上、お客様を満足させるような商品を開発する場合、自社にある既存資源を出発点としてそれをどう活用するかを考えるのではなく、お客様が何を求めているのか、すなわち、顧客が求める機能をまず最初に見出して、それを達成するために必要な資源を割り当てていきなさい、と述べているに過ぎない。ユーザーの目的関数を中心に考えれば、いくらでも自由が増しますよ、と言っているのであり、これが戦略的自由度(SDF)である。

災害時にも戦略的自由度は極めて重要である。しかし、多くのマニュアルがこの戦略的自由度を狭めるような書き方をしている感は否めない。災害時に必要な仕事、つまり、機能というのは経験則上、概ねわかっているし、思考のプロセスを明確化しておくことも可能だろう。従って、すべての災害に共通するような機能(権限なども一つの機能である)やプロセスのみを明確化しておき、それに割り振るべき資源の自由度は高めておくようなマニュアルであれば、畑村氏の言うようなマニュアル化の弊害は起きない(更に言えば、マニュアルを作る段階からそれを使う人も巻き込んで作るということが重要)。

全てのマニュアルが悪なのではなく、要はマニュアル化の程度や作るときのプロセスの問題である。防災用のマニュアルは、マクドナルドのマニュアルなどのようにハンバーガーの焼き方や挨拶の仕方まで縛るようなものにする必要はなく、一定の戦略的自由度を確保したものにしなければならない。

 

 

ファンクショナル・アプローチとプロセス・アプローチ

以前の投稿でファンクショナル・アプローチについて述べたが、いわゆる◯◯◯アプローチと言われるものにはいろいろある。ファンクショナル・アプローチと180度逆のアプローチというものは未だに何と呼ぶのかよくわからないが、この◯◯◯アプローチというものは、マネジメント・サイエンスのおける「フレーム」の一種に過ぎないので恐らくいろいろな◯◯◯アプローチというものがこの世に存在するだろう。物事というものは、その切り口、つまり、縦に切るのか、横に切るのか、斜めに切るのか、などの断面によって見え方が異なってくる。ファンクショナル・アプローチは、物や組織やルールなどをその「機能」という断面で切った時にどのように見えるのかというひとつの見方に過ぎず、その他にも時間という軸を持ち込んだり、お金という軸を持ち込んだり、強み・弱みという軸を持ち込んだりと恐らく無限の切り口が存在するはずである。

そのような中でもISOのマネジメントシステムでは最近は「プロセス・アプローチ」というものが重視されている(⇒「ISO9000 Support Package」「日本語版はこちら」参照)。「プロセス」とは、

インプットをアウトプットに変換する,相互に関連する又は相互に作用する一連の活動(set of interrelated or interacting activities, which transforms inputs into outputs )(ISO22301 paragraph 3.40など)

と定義されており、企業などの一連のビジネス・プロセス(例えば、仕入れ⇒製造⇒販売)をまず定義し、それに必要な仕組み、言い換えれば人や物などの資源配分を考えていきましょう、という考え方である。つまり、「時間軸」を重視している。このビジネス・プロセスは、ビジネスの種類や内容などによって異なるので、個々の企業や組織によって当然異なるだろう。ISO22301(事業継続マネジメントシステム(BCMS))というマネジメント規格が数年前に制定されているが、これも、まず、自分の会社の一連のビジネス・プロセスを明確にして、一連のビジネス・プロセスの中でどのプロセス(「Activity(活動)」という表現が使われているが同じものであるような気がする。)が災害などで被害を受けると影響が大きいのか、どのプロセスがその復旧に時間がかかるのか、などということをまず明確にして、それらのプロセスを保護するためのあらゆる手段(Mitigation, Preparedness, Response, Recovery)を考えておいて、それを文書化するとともにちゃんと実施して下さいね、と要求している。これは、プロセス・アプローチによるオールハザード・アプローチとも言える。つまり、どうやってプロセスを保護するのかということに視点を当てているので、ハザードの種類には依存しない、ということである。

一方、この22300シリーズの中にはISO22320(インシデント対応に関する要件)という規格もある。こちらは、Mitigation, Preparedness, Response, Recoveryといった一連の危機管理サイクルの中の「Response(対応)」の部分にのみ焦点をあてて、あらゆるインシデントに対応するためにはどのような仕組みを作るべきか、という要件が書かれている。つまり、インシデントが発生してしまった後のことについてのみ書かれているので、BCMSのような時間軸の長いビジネス・プロセスについては何も要求されていない。他方、インシデントが発生してしまった後の時間軸の短いプロセスについてはこれを「指揮統制プロセス(Command and Control process)」と称して、「observation」⇒「information gathering, processing and sharin」⇒「assessment of the situation, including forecast」⇒「planning」⇒「decision-making and the communication of the decitions taken」⇒「implementation of decisions」⇒「feedback gathering and control measures」というプロセスを必ず設けて下さいね、と書いてある(ISO22320 paragraph 4.2.5)。つまり、ビジネス・プロセスのように各企業によって異なるというものではなく、ユニバーサルプロセスとして標準化したのだろう。そして、このような各プロセス毎にファンクション(機能)を定義した上で資源配分をインシデントの種類や規模に応じて柔軟に決めて下さいね、と決められている。どのようなファンクションがよいかはいくつか例示されてはいるものの決められてはいないので、この規格を採用しようとする組織や企業の自由である。その意味ではISO22320という規格は、プロセス・アプローチとファンクショナル・アプローチの両方の側面があると言えるのかもしれない。

ところで、そもそも、プロセスとファンクションとは厳密に分かれるのだろうか。逆にいうと分けなければならないのだろうか。プロセスとファンクションが同じになることだってあるだろうし、同じであってはいけないとも言えないだろう。アメリカのICSでは、PlanningとOperationというファンクションが定義されているが、これはよく考えてみるとプロセスでもある。Plan⇒DoのDoのことをOperationと呼んでいるだけである。アメリカは意図的にこの部分は一致させたのかもしれない。

なお、ISO22301とISO22320は別に相反する規格ではないので両立する。ISO22301では、インシデントが発生した後のプロセスやファンクションには言及していないので、両方満足するようなマネジメントシステムを作るのがよいと思われる。

ISO22320ではファンクションについては固定していないと書いたが、アメリカのICSはこれを国家レベルで固定、言い換えれば標準化している。標準化する場合には、このように何をどこまで固定するのか、また、固定できるかを慎重に考えていく必要がある。

 

危機管理におけるファンクショナル・アプローチとは?

アメリカの危機管理体制はファンクショナル・アプローチ(Functional Approach)によって構築されている。ICSも災害現場にどのような機能(ファンクション)を設置すべきかというモデルを標準化したものであるし、NIMSも災害現場を国家レベルでサポートするための機能(ファンクション)を整理し、種類や規模に関わりなく、あらゆるインシデントに対応できるようにしたものである。

ところで、ファンクション、すなわち機能とは何だろうか。あらゆる物や組織には必ず機能がある。逆に言うと物は「機能」と「外形」に分けることができるし、組織も「機能」と「人」に分けることができる。私達がお店で何かを買う場合、その物によって実現されるであろう「機能」に対して対価を支払っているのであってその物自体に対価を支払っているのではない。例えば、ボールペンの機能は「字を書く」ということである。つまり、ボールペンそのものは「字を書く」ための道具としての機能を提供しているにすぎないのである。ところで、これだけなら、60円のボールペンでも1万円のボールペンでも変わらないわけであるし、ボールペンでなくても鉛筆で筆でもよいはずである。しかし実際には、「字を書く」という中心機能の他に、「美しさにより人を癒やす」、「書いた字が簡単には消えない」、「3色で書ける」などなど、様々な付加的な機能がついている。人はこのような様々な付加的な機能まで含めて総合的に判断して「これがいい」と決めたらそれにお金を払っているのである。このように必要なのはそれによって得られる「機能」であってその物自体ではない。

組織も同様である。組織には必ず「機能」がある。営業部という組織の機能は「自社の商品を売る」ということであるし、製造部の機能は「商品を作る」ということになる。それぞれの組織に属している人はそれぞれの機能を実現するための(言葉は悪いかもしれないが)道具である。しかし、実際には先にあげたボールペンの例のようにある会社の営業部には「商品を売る」という主たる機能の他にも「お客様の声を聞いて新しい商品を企画する」という付加機能があるかもしれない。別の会社では「新しい商品を企画する」という機能は営業部ではなく商品企画部などという独立した組織を設置しているかもしれない。このように組織の機能というものも同じ「営業」という名前であっても会社毎に微妙に異なっているということはよくあることである。役所などではこのような機能のことを「所掌事務」などといって細かく決めすぎていて、縦割りの弊害が起きていたりもする。欧米の企業などではこのような組織の機能のことを「ミッション(Mission)」と呼ぶこともあるが同じことであろう。

組織の機能は、更に様々な次元で細分化することも可能である。ある会社では営業部という組織が国内営業部と国外営業部に分かれているが、この場合、国内営業部の機能は「日本国内に自社の商品を売る」ということであり、国外営業部の機能は「外国に自社の商品を売る」ということになる。これは場所によって機能が分割された例である。また他の企業では官公庁営業部などといって「官公庁に自社の商品を売る」という機能に特化した組織を設置しているかもしれない。これは営業先の種類によって組織を分化させた例である。

このように組織にも必ず機能があるものであり、その機能が実現されるのであれば特定の人に依存するのではなく、別の人でもよいはずである。しかし、実際には人によってその機能(個人の機能の場合は「能力」といった方がよいかもしれないが)には違いがあり、1人で実現できる機能が多い人と少ない人がいる。ボールペンの例のようなものである。付加的な機能が多い人のお値段(給料)は高くなり、少ない人は安くなる。

オンライン辞典でFunction(機能)の意味を調べてみると次のような定義がある(名詞の部分のみ引用)。

 func‧tion【Longman English Dictionary Onlineより】
  1. [uncountable and countable] the purpose that something has, or the job that someone or something does
  2. [countable] a large party or official event:   This room may be hired for weddings and other functions.
  3. [countable usually singular] technical a quantity or quality whose value changes according to another quantity or quality that is related to it:   The degree of drought is largely a function of temperature and drainage.
  4. [countable] one of the basic operations performed by a computer

 function【英辞郎 on the Webより】

  1. 機能、作用、働き、効用  ・We will learn the structure and function of the skeletal and muscular system. : 骨格と筋肉組織の構造と機能を学びます。
  2. 《数学》関数
  3. 《数学》写像◆【同】map ; mapping
  4. 職務、役割
  5. 〔正式な〕会合、式典、催し物 ・Please do not park at the school, as they have a function that evening. : その晩は会合がありますので学校へは駐車しないでください。
  6. 《コ》関数
  7. 《言語学》機能

上記より、ファンクションに相当する日本語には「機能」の他にも「関数」「職務」「役割」などもあるということがわかるが、これらに共通する意味は概ね「the purpose that something has, or the job that someone or something does」に集約されるであろう。つまり、「何かに固有の目的、または、人や物が行う仕事」ということである。コンピューターではFunctionのことを関数と呼んでいるが、これもコンピューターのプログラムの一部が行う仕事のことである。日本語では異なるが英語では同じ「Function」である。

このようなファンクションをまず最初に考えて、その実現に必要な資源(人、人の集団、形ある物、資機材、プログラムやサービスなど)を割当てていこうとする考え方が「ファンクショナル・アプローチ」である。商品開発などの現場でファンクショナル・アプローチと言えば、まず、どのような機能を顧客に提供するのかということを考えて、それを定義して、それらの機能を実現するために必要な形やサービス、設計などを考えていくのである。

では逆にファンクショナル・アプローチの反対となるアプローチは何だろうか? 実は、それを明確に表した◯◯◯アプローチという言葉はないようだ。いろいろ調べてみたがこれに相当する用語がない。しかし概念的に考えれば、形から入っていくという考え方ということになるであろう。今ここにAという商品があるとし、AにはB、C、Dという機能があるとすると、B、C、Dという機能で満足してくれるお客さんを探しましょう、という考え方である。つまり、供給サイドを固定して「お客さんを選ぶ」という手法であろう。この言い方を使えばファンクショナル・アプローチとは供給サイドを柔軟にして「お客さんに合わせる」という手法ということになる。これは一概にどちらがよいということはできない一長一短の話しになる。

組織論的にも同じ考え方ができる。ファンクショナル・アプローチによる組織としては機能別組織があるが、これは、社長の下に製造部、営業部、総務部などの機能組織を設けて全ての商品(ここではA商品とB商品を扱っていると仮定する)を製造販売する組織である。これに対して、事業部制組織と呼ばれるものもある。この場合は社長の下にA事業部とB事業部が置かれる。A事業部はA商品のみを製造販売し、B事業部はB商品のみを製造販売する。A事業部とB事業部にはそれぞれ製造部、営業部、総務部などがあり、製造、営業、総務という機能はA事業部とB事業部で重複することになる。詳細に見れば機能別組織の製造部にはA商品の生産ラインとB商品の生産サインというように部分的には分かれているかもしれないが、会社全体としては共有できる機能が多く、「お客さんに合わせ」て商品を提供することが柔軟にできる。しかし、事業部制の場合は、突然、A商品の需要がなくなったからといってA事業部全体を廃止したり、他の商品を製造販売したりすることはできない。要するに柔軟性に欠ける。日本が高度成長を続けていたときは、どこの企業でも事業部制という形態が多くとられていた。松下幸之助のパナソニックがラジオ事業部、ランプ・乾電池事業部などを設置したのが最初の事業部制組織だといわれるが(⇒「松下幸之助の生涯」参照)、事業部制の最大のメリットは自主責任経営の徹底と経営者の育成にあると言われた。事業部制は、日本が安定成長を続け、ある程度長期にわたってラジオやランプ・乾電池という特定の商品の需要が継続することが見通せたときにはよかったのだろうが、消費者の好みも多様化し、変化の激しい時代となるとこの事業部制は柔軟性の欠如というデメリットの方が目立つようになってくる。

ファンクショナル・アプローチという言葉は規則制定の場合にも使われる。筆者はかつて海の分野の国際ルールを作る国際海事機関(IMO)というところで働いていたことがあるが、ルールメイキングの分野でファンクショナル・アプローチといった場合には、条約などの国際規則上では必要とされる機能だけを定めておき、その機能を満たすのであれば如何なる手段を用いてもよいとする考え方である。例えば、船長になるには国際的な資格要件を満たさなければならないのだが、この資格要件はかつて、「知識Aと知識Bと経験Cを有していること」などのように具体的な形で規定されていた。これに対して、改正された国際条約はファンクショナル・アプローチにしよう、ということなって「Xということができ、Yということができ、Zということができること(機能X、機能Y、機能Z)」という定め方に変わった。このファンクショナル・アプローチによれば機能X、Y、Zがあるということが証明できればそのための手段はいろいろあるということになり、柔軟性が増すのである。

このようにファンクショナル・アプローチは様々な分野で使用されているが、ファンクショナル・アプローチとそうでないアプローチにはそれぞれ長所短所があって一概にどちらがよいと言えるものではない。一言で言えばファンクショナル・アプローチとは目的が達成されるなら手段は何でもよいという考え方であるので「柔軟性を増すためのもの」ということができるが、社会の変化が緩やかで安定的な状況下では柔軟性よりも他の価値の方が重要視される場合もあり、ファンクショナル・アプローチが常に正しいということにはならない。手段と目的を取り違えるということは現実社会の中で頻繁に発生しているが、必ずしもそれが100%悪とは限らないのである。

それでは危機管理、防災などの緊急事態・非常事態への対応を念頭においたマネジメント・システムを考える場合にはどのようなアプローチがよいのだろうか。筆者は以前このブログ上で書いた別の投稿「そもそもインシデント・コマンド・システムとは何か?」にて、緊急事態・非常事態というものは日本語の概念ではあまりよい表現がないが英語圏では「インシデント」という単語で包括できると書いた。インシデントとは、日常的な小さな事故から原発事故や東日本大震災などの大災害まで全ての含む災害などの種類や規模によらない概念である。インシデントがこのように多種多様で大小様々なものであるということになると、それへの対処を前提とするマネジメント・システムに必要になるのは「柔軟性」であろう。すなわち、ファンクショナル・アプローチによらなければうまく対応できない、という結論に行き着く。

アメリカのICSではインシデントの発生現場、言い換えれば災害現場に必要な機能、すなわち「ファンクション」としてIncident Commad(現場指揮)、Operation(運用)、Planning(計画)、Logistic(後方支援)、Administration/Finance(総務/財務)という5つの基本機能が定義されている。このように基本機能を定義する最大のメリットは、「この5つの機能はインシデントの種類や規模によらずに常に必要になる」ということにつきる。極端な例を持ち出せば、「金融危機」のような一見災害とは異なる種類なので全く違ったアプローチが必要なのではないかと思われる種類のもの(「金融危機」も立派なインシデントである。)でも、誰かが指揮し、誰かが何かを計画し、誰かが計画を実施し、誰かが側面からいろいろ支援しているだろう。指揮者は財務大臣かもしれないし、計画したりやそれを実施するのは財務省職員や日銀職員かもしれない。全てのインシデントに必要な機能を定義しておけば、異なるのはその機能の実現に必要な資源(人、資機材その他の道具)だけということになる。当然の事だが、金融危機というインシデントに消防署員や消防車を持ってきたところで何の役にも立たない。このようにインシデントの種類や規模によって、必要な人や道具は当然異なる。

ファンクショナル・アプローチを採用すれば全ての種類のハザード(危険要素)に同じプロセスやメカニズムで対応が可能になるので「オールハザード・アプローチ」とも呼ばれる。先にファンクショナル・アプローチによればあらゆるインシデントに対応できると書いたので、「オールインシデント・アプローチ」とでも呼ばれていればスッキリするのだが、なぜか世界ではそのようには呼ばれていない。そこで、ハザードとインシデントの関係が混乱するかもしれないが、実際のところ、この2つの単語は欧米でも混乱して使用されており、わかりにくい。ハザード(Hazard)は、本来、危険の原因、危険物、障害物などを意味する英語である。日本でも「ハザードマップ」と称して地方自治体などが土砂崩れが起きやすい場所や河川氾濫時に浸水しやすい場所、つまり危険箇所を示した図を発行しているが、このような土砂崩れが起きやすい傾斜面や浸水しやすい土地というもの、言い換えれば、土砂崩れや浸水の原因となりうる根源的な要因が「ハザード」である。これに対して、このような崩れやすい傾斜面などに豪雨や地震などといった他の要因が加わって、実際に土砂崩れが起きてしまったものが「土砂崩れ」という「インシデント」である(「リスクマネジメント・プロセス」の項を参照)。ただし、インシデントは実際に被害があったかどうかには関係がない。土砂崩れでいえば、崩れやすい傾斜面に地震などの他の要因が加わって、少しでも変化が生じ、このままほっておけば被害が確実に出るとともに拡大する恐れがあると思われる全ての状態が「インシデント」に含まれると考えるべきである。ところで、土砂崩れの例では「崩れやすい傾斜面」をハザードと呼び、「地震」を他の要因と呼んだが、この2つを逆にとらえてもよいのではないだろうか。すなわち、「地震」がハザードであり、「崩れやすい傾斜面」を他の要因ととらえるのである。これも別に不自然ではない。さらに「地震」とは何か考えてみるとプレートと呼ばれる地下にある広大な岩盤の厚い層と層が対流して歪み、これに歪みを元に戻そうとする反対方向の力が加わったときに生じる地殻変動による振動波である。このモデルで考えるならばプレートとプレートの間のズレをハザードと呼び、これに別方向にプレートを動かそうとする他の力が加わって生じたインシデントが地震であるとの解釈もできる。つまり、地震とはそれ自体がインシデントであると同時に土砂崩れという別のインシデントを引き起こすハザードとも言えるのである。このように考えるとハザードとインシデントの関係はニワトリが先かタマゴが先かという議論になり、学問上の定義としてはハザードが原因となり、それに他の原因などが加わってインシデントが発生するのだ、とは言われているものの、実際の事象に照らした場合には、ハザードにもインシデントにもなりうるものばかりということになってしまうのである。だから、この2つは混乱して使用されているのであり、結局、どうでもよい話である。従って、地震は、ハザードであり、かつ、インシデントでもあるし、津波もハザードであり、かつ、インシデントでもある。火災も、ハザードであり、かつ、インシデントであるし、金融危機だってよく考えればハザードであり、かつ、インシデントである。

なお、参考までにコンピュターに対する情報セキュリティ・インシデントを議論する場合は、このハザードに相当するものは「Threat(脅威)」と呼ばれる。ウィルスやハッキングのような行為は「Threat(脅威)」であり、ハザードとは呼ばれない。戦争のような戦いの場合も「(敵の)Threat(脅威)」が問題となる。様々な個別分野によって、このように異なる用語が使われることはあるが、その本質は皆同じである。ハザードも脅威も同じものであり、どちらもインシデントを引き起こしうる原因要素である。

米国のICSでは「ファンクション(機能)」としてIncident Command、Operation、Planning、Logistic、Administration/Financeという5つを基本として定めているが、これらのファンクションはいかなる種類のインシデントにも必要になるものであり、いかなる規模のインシデントにも必要になるものである、とされている。家の中でタバコの火の不始末でジュウタンが少し燃えてしまった、というような小規模なインシデントであれば、この5つのファンクションを実施するのに必要な資源は、その場に居合わせた自分1人と台所においてあった消火器1台で十分かもしれない。他方、大規模なビル火災が発生した場合には、100人もの消防士とハシゴ車が数台必要かもしれない。しかし、どちらのインシデントの場合でも、5つの基本ファンクションが必要なことは同じであり、ただ、そのファンクションの実施に必要な資源、言い換えれば道具(人を含む)の量や種類が異なるだけである。自分1人で対応することができるようなちょっとしたボヤのような非常に小さなインシデントの場合には自分一人で全てのファンクションをこなしているにすぎないのであって、そのことを本人はあまり意識していないかもしれないが、考え方のモデルとしては成り立つものである。米国のICSで定義されている5つのファンクションを固定的な組織の在り方のように解釈し、常にこのような5つの機能組織を設ければ全てがうまくいくと思っている学者や役人、民間コンサルタントなどをたまに見かけるが、このような解釈はファンクショナル・アプローチとは何かを理解していないことの証である。A、B、C、D、Eという機能があった場合には、それぞれの機能に別々の人を割当ててもかまわないし、AとBの機能をまとめて1人に任せ、CとDとEの機能をまとめて別の人に任せてもよいのである。当然、これらの全ての機能を1人にまかせてもかまわない。また、機能というものは「◯◯◯することができる。」というような能力的な要素であるので、必ず何かをしなければならないという義務的な要素ではなく、Eという機能を任されたからといってその機能を実施する必要がなければする必要すらない。それだけのことであり、重要なことは定義された機能に対して、柔軟に人や資機材を含む資源を割り振り、必要な機能を実施させるということなのである。

それでは、米国ICSで定義された5つのファンクションとは、それほど素晴らしいものなのだろうか?  米国ICSをコピペして、日本語に訳して実施させたら困難な大規模災害へスムーズに対応できるのか? 米国にはICSという標準化された仕組みがあり、日本も導入する必要があるだろうという機運が東日本大震災の後、多少ではあるが生まれており、それは非常によいことであり、筆者も当然賛成であるし、標準化されたマネジメント・システムが必要なことは明らかである。しかしながら、この種のマネジメント・システムというものは形から入っていくと必ず失敗する。例えば、ISO9000が日本を導入しようといろいろなコンサルタントが日本企業の支援をしてきたが、大概彼らはどこかの国内外の企業のマニュアルを適当にコピペして、顧客企業に提供し、ISO9000の証書を取得できる程度の文書化を進めただろう。しかし、このようなやり方をした企業は大概ISO9000が言わんとしている様々なメリット、言い換えればなぜそのような仕組みにすることがよいのかということを全く理解せずに実施しているので、当然個々の社員にしてみれば目的からして理解できず、「よけいな仕事が増えた〜」「ばかかばしい〜」などということになり、形骸化していくのである。従って、インシデント・マネジメント・システムをこれから検討するにあたっても、決して形から入ってはならず、必ずその目的やメリット、なぜ、この仕組みが必要なのかということをできる限り多くの人が理解し、共有した上で議論していかなければならない。

話が少し横にずれたが、米国ICSの5つの基本機能について再度考えてみよう。ところで、Incident Command、Operation、Planning、Logistic、Administration/Financeを正確に和訳するのは意外と難しい。Incident Commandを和訳しようとしても、英語のIncidentの概念とぴったり一致する日本語が存在しない(「インシデントとは?」を参照)。筆者は、適切な日本語が存在しないので外来語としてカタカナで「インシデント」と表記するようにしているが、その場合、「インシデント指令」とでも訳すのか? それも何かしっくりこない。ある人はこれを「事案指揮」と訳していたが、これもあまり一般的な言葉ではない。意訳して「現場指揮」とすれば筆者のように官公庁出身者には比較的受け入れやすいが、それも民間部門で受けいれられる訳語かどうかは多々疑問があるところである。Operationについては、「運用」「実行」「実施」などなど、Planningについては、「計画」「戦術」「計画情報」「諜報」などなど、Logisticについても「兵站」「後方支援」「物流」などなど、様々な企業や団体が米国ICSをそれぞれの趣味に応じていろいろな翻訳をしていることが、インターネット上を検索してみるとよくわかる。おそらく、それぞれの人が個々の機能の内容まで理解せずに訳しているので、これらの訳語は所詮訳者の「好み」の領域を出ていない。本気で日本にICSを浸透させようとするならばこの程度のいい加減な訳では多くの人が理解できないだろう。さらに個々の基本機能は、多数のサブ・ファンクション(小機能)に分割できる。例えば、米国ICSの場合、Planning(P)という基本機能には、Resources(R)、Situation(S)、Documentation(Do)、Demobilization(De)の4つの小機能に分かれるとされる(集まった資源(人や物)を管理し、被害の状況を管理し、様々な文書を管理し、任務の割当てを管理する。)。つまり、P=R+S+Do+Deと米国は定義しているということである。しかし、このような定義というのは、国や組織によってまちまちであって、何かが正しいとか間違っているという問題ではない。例えば、ドイツのICSの場合、基本機能としては、Incident Command、Personnel/Administration、Information Gathering/Assessment、Operation、Logistics、Media and Press、Communication and Transmissionの7つが定義されているし、オーストラリアなどでは米国ICSをほとんどそのままコピーしつつも、Administration/Financeという機能は独立させる必要はないとしてLogisticの中に小機能として含めているようである。このように、基本機能の定義というものは、文化や習慣、言語などによって異なるのが普通であり、どのように定義すると自分達の組織の最大多数の人にとってわかりやすいかという点を検討し、コンセンサスにて決められるべきでものあろう。

米国のICSでいうCommand/Operation/Planning/Logistic/Administrationという機能要素は、基本的にインシデント発生現場において必要となる機能である。筆者はこれを更に簡素化して次のように定義したい。

  • 指揮機能:インシデント発生現場における実施計画の承認、目標達成状況の監視、目標達成のための改善の指示に関わる機能(Command)
  • 計画機能:発生したインシデントの状況を把握・分析し、目標を設定するとともに目標達成に必要と思われる資源(人や物など)を含む実施計画を立案する機能(Planning)
  • 実施機能:与えられた資源を使用して実施計画にて定められた目標を達成する機能(Operation)
  • 現地支援機能:計画の作成及び計画の実施に必要な資源(人物金など)を手配する機能(Logistic/Administration/Financeをひとまとめにする)

このようにまとめればインシデントの種類や規模に関わらず、適用できるであろう。マイケル・ポーターのバリューチェーンというモデルで言えば、計画⇒実施は「主活動」に相当し、現地支援機能は「支援活動」に相当する。なお、上記の機能は更に小機能(サブ・ファンクション)に実際には分かれるだろうが、それは非常に各論的な議論になってしまうので、ここでは議論しない。ここで重要なことは、インシデント・マネジメントも「マネジメントの一種」である以上、必ず、付加価値を生み出す「主活動」(インシデント・マネジメントの場合は、『付加価値を生み出す』(プラスを増加する)というよりも『被害を広げない』(マイナスを減少する)と言うべきだろう。)と「支援活動」に分かれるはずだ、ということである。

なお、上記の機能は、インシデントの発生現場において必要となる機能を意味している。日本では、時たま、現場から遠くはなれた東京の本社、本庁、場合によっては首相官邸といった中枢組織が現場の細かい作業にまで口を挟むが、現場から離れれば離れるほど状況の伝達には時間がかかり、また、伝言ゲームをしているかのごとく正確な状況というものはつかめなくなるものである。このような中央からの介入は基本的に事態の改善には繋がらないと考えたほうが良い。現場の判断が間違っていることも当然あるだろうが、情報が正確迅速に伝わらなければ中央の判断が間違う可能性の方が遥かに高く、中央の判断を待つということが習慣化し前提条件になってしまうと作業が遅れ、被害が広がる可能性の方が高いであろう。従って、現場から遠く離れた組織の役割というものは、基本的に「現場の支援」である。現場が自ら考えた計画を実施するために必要な資源(人物金など)を最大限提供し、また、そのために必要な調整を実施するという役割につきる。通常時の組織の上下関係を緊急時には持ち込むべきではない(「災害時には逆ピラミッド型組織」を参照)。

さて、このように大きなインシデントになればなるほど、現場にある資源だけでは十分に対応できないということになるので、当然、現場以外の外部からの支援が必要になるが、この支援機能についてもファンクショナル・アプローチをとることが可能である。言い換えれば、インシデントの種類や規模に関わりなく必要とされる支援機能を定義し、その機能が提供されればその機能の提供者は誰でもよい、と考えるのである。このような支援機能の提供者も、これまでに述べたように、場合によっては1人で全部提供しても構わないし、100人で提供されてもかまわないし、提供する必要がなければ0人でもよいと考えるのである。外部からの支援機能を含めて、ファンクショナル・アプローチによるインシデント・マネジメントをイメージ図化すると下記のようになるだろう。

functional approach layers.001

この外部支援機能は、米国ではEmergency Support Functions(ESF)といって、次のような機能が定義され、それぞれどのような組織がその機能を提供するかも、連邦レベルや州レベルであらかじめ決めてある。ただし、注意しなければならないのは、これは「機能」であるので、1つの組織が複数の機能を提供することもあるし、1つの機能を提供できる組織も1つとは限らず、複数あるということである。

  • ESF1: Transportation(交通インフラの安全や復旧などを支援する機能)
  • ESF2: Communications(通信・ITインフラの安全や復旧などを支援する機能)
  • ESF3: Public Works and Engineering(公共インフラの安全や復旧などを支援する機能)
  • ESF4: Firefighting(消防活動の調整を支援する機能)
  • ESF5: Information And Planning (情報の収集及び計画の作成などを支援する機能)
  • ESF6: Mass Care, Emergency Assistance, Temporary Housing and Human Services(ボランティアの管理や避難所の設置などを支援する機能)
  • ESF7: Logistics Management and Resource Support (必要な支援物資の調達や管理を支援する機能)
  • ESF8: Public Health and Medical Services(医療や健康管理などを支援する機能)
  • ESF9: Search and Rescue(捜索救助活動を支援する機能)
  • ESF10: Oil and Hazardous Materials Response(油及び危険物対応活動を支援する機能)
  • ESF11: Agriculture and Natural Resources(動植物の安全や文化施設の安全を支援する機能)
  • ESF12: Energy(エネルギーインフラの復旧などを支援する機能)
  • ESF13: Public Safety and Security(治安維持などを支援する機能)
  • ESF14: Long Term Community Recovery(社会的影響・経済的影響などを評価し、長期的な復興を支援する機能)
  • ESF15: External Affairs(広報、メディア対応、議会との関係、外国との調整活動などを支援する機能)

なお、上記のような個々の機能の定義は米国の価値観に基づいて分類され、ひとつのまとまった機能として捉えられているだけであるので、必ずしも日本の価値観の下で多くの人に理解しやすいものではないと思われる。上記の個々の機能は、複数の小機能(サブ・ファンクション)の和であるので、どのような小機能を大括り化するべきかというのは我々の社会の中で、再検討を要する事項であろう。重要なことはインシデントの種類や規模に関わりなく必要になる機能を見出し、定義するということであろう。