オールハザードとは全てを計画することではない

“All-hazards” Doesn’t Mean “Plan for Everything

上記サイトの翻訳：

最新の危機管理における中心的な考え方は、オールハザード計画である。しかし、これは一体何を意味するのか。NFPA 1600 「災害／非常事態管理及び事業継続計画に関する標準」には、可能性の高いハザードとして４５個のカテゴリーがリストアップされている。オールハザード計画とは、このリストにあるそれぞれのハザードに対して別々に計画書を作るということを意味するのか。

この質問にいい加減に答えてはいけない。オールハザード計画とは起こり得る全ての事態に対して計画しておくことだ、と信じている非常事態管理者は非常に多い。しかし、実際には、そんなことは不可能なのである。たとえ、全てのハザードを予期することが可能だったとしても、そんなことができるほど十分な資源を持った組織や地域はないし、この世には、必ず、予期せぬ事態というものがある。

オールハザード計画には、２つの要素がある。第一の要素は、リスク分析である。非常事態管理の基本の原則は、全てのハザードを総合的に検討することであるが、NFP1600もこの原則に沿って、「別添Ａに記載されているハザードをリスク評価の過程で検討すること」と記している。そして、リスク分析を活用して、優先順位や資源割当を決める。

有限な資源を起こり得る全てのハザードに対する計画を作成するためにつぎ込むのではなく、リスク分析によって、コミュニティーにとって脆弱性が大きいハザードを特定してそこに資源を集中するのである。このようにすると、コミュニティーにとって影響が大きいリスク（注：ハザードではない）に資源を集中させることができる。

オールハザード計画の第二の要素は、機能別計画によって、複数のハザードに対処するための能力を備えることである。 警報発令計画、避難計画、避難所の設営計画などは、あらゆる種類の災害で多かれ少なかれ必要となる機能であり、ほとんど同じような手続きで運営される。このような考え方をすることにより、予期されているリスクのみならず、予期せぬリスクに対しても、多少の修正で対応できるようになる。

オールハザード計画は、すでに実証された考え方である。しかし、これは全ての起こり得るハザードに対して計画を作らなければならない、ということを意味しない。これは、リスク分析の一部として全てのハザードについて検討はするものの、機能別計画や優先順位が決められた緊急時計画によって、有限な資源の最大限の活用を図るものである。

 

にほんブログ村

政策研究・提言 ブログランキングへ

 

 

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

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

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

（畑村洋太郎[2011]、『「想定外」を想定せよ！―失敗学からの提言』、ＮＨＫ出版、Ｐ130)

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

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

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

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

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

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

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

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

 

 

オールハザードという考え方（想定外対策）

今回の熊本地震に関する報道でも、５年前と同様、やはり、「想定外だった」というフレーズが目立っている。日本社会は、今も昔も楽観的な想定をおいて、それに対して備えているだけで「安全だ」と自己満足にふける傾向が非常に強い。こんなことをしていてはいつか自然からとんでもないしっぺ返しをくらうだろうということは多くの人が頭の中ではわかっているのだろうが、ではどうしたらよいのだろう、という点に関して提言を述べる学者もマスコミもこれまでのところいなかった。

被害のハード的な予防策（例：建物に筋交いを入れる、堤防を作る、原子力発電所の冷却装置にバックアップバッテリーを設けるなど）を講じたり、発災後の被害を抑えるための道具を開発したりする場合には、確かに想像力を最大限に使って想定（シナリオ）を作る必要がある。しかし、事故や災害が実際に発生した後に対処する方法にまで詳細なシナリオを描いて誰が何をするというように決めてしまうのは、思考の硬直化を招き、シナリオ通り発生しなかった場合に対処が困難になるため大きな問題である。発災後というのは、全くシナリオが予想できないドラマであり、利用可能なあらゆる資源を柔軟に動員して被害を最小限に抑えるしかない。「想定外」の事態が存在するということを想定しておくことが極めて重要などであって、それをせずして「想定外だった」などと言ってはならない。

欧米には「オールハザード」という考え方がある。「ハザード」とは、災害等のインシデントを引き起こす原因となるような危険要因を意味するものであり、地震、津波、原子力災害、台風、テロ、その他、我々の生存を脅かす可能性のある自然現象や事故等を全て含む概念だが、「All Hazard」ということは、種類や規模を問わず、あらゆるハザードに対して、柔軟に対応できるようにするということである（FEMA Guide (CPG 101) 参照）。

「種類や規模を問わず、あらゆる災害に対応できるようにすること」など不可能だという人は多いかもしれない。しかし、ベストエフォートで対応することは可能である。

最初にあえて誤解を恐れずに例えて言えば、これは「トヨタのジャスト・イン・タイム方式で車を作ること」や「オーダーメイドでスーツを作ること」と同じことだ、ということである。車の生産方式には２種類あり、ひとつは多品種少量生産を可能にする「トヨタ方式」、他方は少品種大量生産の「フォード方式」である。「トヨタ方式」では実際にニーズが発生してから最終工程の側から前工程へとさかのぼって必要な部品を必要な量取りに行き組み立てる。このため異なる車種の車でも臨機応変に組み立てることができる。そして完成車の在庫が発生しない。言い換えれば一種の注文生産である。他方の「フォード方式」では、実需ではなく、需要を予測して計画的に生産しようとする。このため、あまり多くの車種は作ることができず、作り過ぎれば完成車の在庫が発生し、作る量が足らなければ機会損失が発生する。スーツの製作も同じ。オーダーメイドスーツの場合、お客様の体の寸法を詳細に測り、お客様の好みの生地や色を十分聞いた上で、世界に一つだけのスーツをお客様のために作る。このため完成品の在庫というものがない。他方、紳士服のナントカみたいなお店では、需要予測に基づき計画的に大量生産されたスーツがあらかじめ並べられている。確かにいろいろな種類のいろいろなサイズのスーツはあるが、１００％ピッタリ自分の体や自分の好みにあったものというのはない。また、この方式では、やはり売れ残り、すなわち完成品在庫、または需要を満たさないことによる機会損失が発生する。

これを災害対応に言い換えると「需要を予測する」ということは、「想定を設定する」ということと同義であり、「在庫または機会損失が発生する」ということと「想定外の事態に遭遇する」ということは同義である。つまり、想定外をなくすということは製造業における在庫または機会損失をなくすということと同じということである。従って、製造業が特注品生産するときと同様なマネジメントシステムをインシデントマネジメントに導入すればよいのである。

災害対応とは、確かに目に見えるモノ作りではないが、「被害を最小限に抑え、迅速に復旧するためのサービスの提供」という捉え方をすれば、結局のところ、そうゆう「サービス」を生産するための生産工程であることには変わりない。そして、そのお客様のニーズというのは災害の種類や規模毎に異なり、実に千差万別で事前に予測することが難しい。災害の事前予測、すなわち想定に基づいて災害の種類毎にいくつものテンプレート的なマニュアルを用意しておいたところで、大体、想定外の事態に遭遇し、プロセスが行き詰まるのである。

オーダーメイドにするということは、実需が発生してから必要な資源の組み合わせを考えるということである。そのためには、初めから、全ての災害対応すなわちインシデントマネジメントがオーダーメイドである、という前提でマニュアルなりを作っておく方がよい。「オールハザード対応」＝「トヨタのジャスト・イン・タイム方式」＝「オーダーメイドのスーツ作り」との所以である。欧米先進国の災害対応の基本的考え方はすでにココに置かれている。ICSというのはそのために標準化された仕組みのことである。

オーダーメイドのスーツは、どのように作られるのだろうか。お客様がお店に行くと、まず、体の寸法を詳細に計測するだろう、そして好みの生地や好みの色も聞かれるだろう、さらにいつ頃までにほしいのか、という納期についても聞かれるだろう。これらの情報をもとにお客様の体に合わせて設計し、お店は生地メーカーに発注し、生地を調達する。生地が届いたら、設計に合わせて生地を切り、ミシンを踏んで製作する。完成したら、お客様に連絡し、試着してもらい、万が一、体に合っていなければお店の責任で作り直すことになる。これらの一連のプロセス自体は、お客様のニーズに関わらず一定であり、普遍的なものである。そして、設計するとか、生地を切るとか、生地を縫うという機能すなわちファンクションも常に必要になり、普遍的である。しかしながら、お客様によって異なるのは、生地の種類や色であり、場合によってはそれを切ったり、縫ったりするために必要な道具も異なってくる。極めて特殊な服で専門的な能力が必要な服だったら、製作に必要な人も異なるかもしれない。すなわち、材料、道具、人など、必要な資源が異なっているのである。但し、製作に使用する生地までも一から製作するとは限らない。幾つかお店側で予め決めておいた生地の中からお客様に選んでもらうだけの場合がほとんどだろう。いちいち生地までも特注していたら、時間も費用もかかり過ぎるからである。使用する道具や人にもあらかじめ幾つかの選択肢が用意されているだろう。情報システムなどの分野では、これを「モジュール化」と呼んでいる。モジュール化をしておけば、材料や道具、人などの資源を選択肢の中から選択するだけなので、特注品でも迅速かつ低コストで製作できる。その意味では、オーダーメイドスーツでも、お客様のニーズを１００％満たすものにはならないかもしれないが、それでもお店に並んでいるスーツの満足度が７０％位だとすると、オーダーメイドスーツならきっと９５％位まで満足度は上がるに違いない。

オールハザード型災害対応の場合も、これと考え方は全く同じである。どんな災害の場合でも普遍的に必要となるプロセスとファンクションのみマニュアル化しておく。対応に必要な資源（救助隊等の人的資源や資機材、燃料等全ての人・物・金・情報を含む。）はモジュール化しておき、選択肢として準備しておく。いざ災害が発生した場合には、各種の資源は現場に急行し、災害現場にてチェックインする。チェックインを済ませた各資源は、出番がくるまで、待機場所（Staging Area）で一旦待機する。現場指揮官は、災害状況をまず調査し、チェックイン済資源の一覧表を睨みながら、問題解決のための計画を立案し、必要な資源に対して、出動を指示する。現場指揮官は、問題が解決されているかどうか常にモニタリングし、計画の修正が必要なら修正し、追加資源が必要なら、政府なり支援団体なりに追加派遣を要請する。

米国などではすでにこの仕組みが確立されている。我が国では、上記のようなプロセスやファンクション（責任や権限を含む。）が明確になっていないから、今回の熊本地震の場合も、現場の詳細な状況が把握されていない、ニーズが明確にならない、などといった初歩的な問題が発生するのではないだろうか。

この仕組みは一朝一夕に実現できるようなものではない。トヨタがジャスト・イン・タイム方式を確立するまでに要したことと同じだけの努力が必要になる。多能工の養成（いくつもの異なる道具を扱えるように訓練すること）、自働化、供給元企業（災害の場合には支援機関と読み替えるといいかもしれない。）との協力関係の確保など、時間のかかる努力が必要である。さらに世論の支持も必要だろう。この仕組みは基本的に逆ピラミッド型の意思決定（現場主義や要請主義と言ってもいい。）を基本に置く。東京に情報や権限を集中させるべきだという意見もあるので、中央集権的な意思決定システムでは機能しないということに関し、幅広いコンセンサスを形成する必要もある（注：現在の災害対策基本法は、一応、「要請主義」が基本になっている）。

参考図書：トヨタ生産方式―脱規模の経営をめざして・・・ 大野 耐一

 

災害対応とジャスト・イン・タイム方式

地震発生から１０日あまりが経つが、テレビ、ラジオ、新聞等で目立つのは「今被災地で必要なものは何か？」という議論である。専門家なる人物がテレビに出てきては、現地ではあれが足らない、これはもういい、こうしたほうがいい、などなどと自由活発な議論をする。それはそれで結構だが、これらはその一部の先生方が現地へ赴き、ごく一部の人たちから見聞きした、非常に断片的な情報に基づくものであって、決してマクロ的な全体を代弁したものではない、という点を我々は認識しておく必要がある。そうゆう人もいるだろうし、そうではない人もいる、ということであり、人のニーズというのはそんなに画一的なものではなく、多様なものである。必要な情報とは、Ａの状況の人が全体の何割ぐらい、Ｂの状況の人が何割ぐらい、Ｃの状況の人が何割くらいだ、というおよそでもいいから全体を推測した情報だ。こうゆう情報を専門家なら統計手法を駆使して迅速に発表してもらいたい。現地で１人２人の話を聞いてその話をテレビで代弁することぐらいなら誰でもできる。マーケティングの手法を駆使してもらいたいものである。

そして、このような需要予測というものがほんとうに正確にできるのであれば、政府のプッシュ型支援なるもの、言い換えれば政府による計画的配分で必要十分ということになるのだが、正確な需要予測など災害という大混乱の中では実際には非常に難しいということは容易に推測できる。ではどうすべきか。それが、ここで述べるジャス・イン・タイム方式、すなわち、トヨタのカンバン方式を採用するということである。後工程から前工程に対する要請主義、プル型といってもいい。

資源配分は「最適に配分する」ことが重要なのであって不足してはいけないが、多すぎてもいけない。現地ではすでに食料品などの支援物資は避難所が置き場に困るほど届いているらしいが、このように余分な物資が避難所を占有してしまうと、その分、人の避難スペースが減少する可能性だってあるだろう。これらは経営学でいうところの「在庫」であり、在庫とは無駄な費用である。これらはスペースも無駄にするし、お金も無駄にする。余計な物資の運搬に運用業者等の人員が割かれれば、これらの人員が他の必要な物品の運搬に割り当てることができたであろう時間（これは機会費用「Opportunity Cost」であってやはり一種の「費用」である。）をも浪費する。このように我々は災害時であっても常に最適配分を意識しなければならない。

上記の議論はおおむね食料や住居、生活物品などのような物的資源の分配に関するものだが、災害が発生してから収束するまでの様々な問題を解決するために現場はさまざまな資源を必要とする。資源は、目に見える物品や燃料などの物的資源だけでない。現場に入る自衛隊や消防のような救助隊の人も資源である。人的資源（Human Resource）である。物の購入等に必要なお金も資源であるし、人や物の割当を決めるために必要な情報も資源である。「人」「物」「金」「情報」これらは全て経営学で経営資源と呼ばれる「資源」である。これらの資源を目的を達成するために如何にして効果的に割り当てるか、これを決定し、その効果を継続的にモニタリングして、必要に応じて継続的に改善していくための仕組みがマネジメント・システムと呼ばれるところのものである。従って、まず、必要になってくるのは、決定したり、モニタリングしたり、改善するための「プロセス」である。どんなマネジメントシステムでもまずプロセスをきちんと定義する。もっとも単純化された基本的なプロセスはＰＤＣＡサイクル（ＰＬＡＮ－ＤＯ－ＣＨＥＣＫ－ＡＣＴＩＯＮ）である。実際には目的に応じてこれらのプロセスが更に細分化されて定義されている。

そして、このプロセスというフローの中で目的の達成に必要な機能（ファンクション）を決め、それらの各ファンクションに対して、人、物、金、情報といった経営資源を割り当ててていく。今回の地震では市庁舎などの防災拠点が地震で倒壊の危機にさらされ使えなくなってしまった、というニュースがあった。これは、防災拠点（ 欧米では「ＥＯＣ(Emergency Operation Center)」と呼ばれている）というファンクションに市庁舎という資源を割り当てていたものだが、災害のマネジメントでは、あるファンクションに特定の資源のみを固定的に割り振っておくことは望ましくない。日本の防災計画では、往々にして特定の資源を固定的にあるファンクションに紐づけている例が多いが、このようなことをすると大概予期せぬ事態に遭遇して身動きがとれなくなる。人という人的資源の場合も同様である。ある特定の人の仕事（つまりファンクションである）を固定的に防災計画の中で規定してしまうと、その人が何らかの事情でいなくなるとそのファンクションが提供されなくなる。必要なのはファンクションであって、特定の人や物ではない。災害対応の指揮官とてもケースバイケースである。米国などでは最初に現場に到着した人が指揮官になるとだけ決まっており、「誰が指揮官をする」とは決められていない。決めることなどできない。

ファンクションと資源の関係は、防災計画では柔軟に考えておかなければならない。実際には、災害が発生してから資源の割り当てを考えざるえない場合がほとんどである。事前に固定的な資源配分を防災計画で決めてしまうことは望ましくない。例示的な意味合いに留めておくべきだろう。

このようにファンクションに応じて資源を割り当てていく方法を「ファンクショナル・アプローチ」という（詳細：「危機管理におけるファンクショナル・アプローチ」参照）。

災害が起きる前にこのファンクションを定義し、日本国中のみんなが共通理解をもっておくことができれば、臨機応変に組織が編成されたとしても、各自の役割をすぐに理解することができるし、代替資源を供給することも容易になるだろう。また、プロセスがきちんと定義されていれば混乱する災害の中でも必要な作業を漏れなく、ダブりなく進めていくことができるだろう。

そして、この仕組みを効果的に動かすためには、各プロセスの中で流れる情報の定型フォーマット（例：米国のICS各様式）を決めておくこと及び各資源のチェックインを管理すること（米国では救助隊や支援物資といったあらゆる資源をStaging Areaという場所にチェックインさせて一旦プールし、そこから必要なだけピックアップしていく）が極めて重要になる。これは、言い換えると災害対応というマネジメントシステムをトヨタのカンバン方式（Just In Time(JIT)方式）のようにするということに他ならない。災害対応版サプライ・チェーン・マネジメント（SCM）と言っても過言ではない。トヨタのカンバン方式では、カンバンという定型フォームを各製造工程（プロセス）の中で行き来させることによって、擬似的な注文生産のような工程を構築し、在庫を極限までなくすことに成功して、世界が注目したマネジメント・システムである。筆者が１０年前米国のGWUで米国流危機管理を学んでいたとき、あるFEMA OBの教授が、「Just-in-Time !」「Just-in-Time !」と強調していたことを思い出す。あの先生は筆者が日本人だということ見て、「これはおまえの国から学んだことなんだぞ」と言いたかったのだろう。しかし、我が国ではモノづくりでこそJITが根付いたかもしれないが、それを災害対応に応用するなどどいうことは、思いもよらないことだろう。そんなこと言い出した途端に「災害対応と自動車の製造を一緒にするな！」と言われそうだ。よく考えてみればどちらもマネジメント・システムの問題であり、目的やアウトプットが異なるだけであって、自動車のドアやエンジンなどの部品の代わりに、First Responder（自衛隊・消防・警察等）、ＤＭＡＴ、ＮＰＯ、ボランティアや支援物資という部品を投入して、一定のアウトプットを産出するための工程に他ならないのだが（災害は千差万別なのでまさに特注の注文生産工程が必要だ）。【「人間は部品ではない！」と怒る人も恐らくいるだろう。しかし、経営科学という観点では、部品＝資源であり、人＝人的資源＝資源である。従って、部品＝人である。この点を割り切って考えていかないと仕組みの改善はできない。】

なお、最近の災害ボランティアは、現地のボランティア受付センター（米国のStaging Areaに相当する）で登録後（要するにチェックインである）、ニーズがあるまで待機させ、必要に応じてプールされたボランティアを必要としている家庭などに派遣するという手法をとっているが、これはまさにトヨタのカンバン方式でいえば、後工程が前工程に必要なときに必要なだけ必要な部品を取りにいっているのと同じことである。２０年前の阪神大震災やナホトカ号油流出事故のときは、ボランティアの管理ができていなかったため、ウロウロしていたボランティアがかえって現場の邪魔になっていたことを反省して、現在のような仕組みになったのだろう。言い換えれば、ボランティア団体の方が、一歩先にいっており、政府部門の方がまだ改善されていないということになる。

以上述べたことは災害対応（インシデントマネジメント）を標準化するということに他ならず、我が国の災害対応の仕組みの中で決定的に欠けている部分であり、今回の地震の場合でも全ての問題は「最適な資源配分をもたらすための仕組み」の欠如という課題に帰結する。

マネジメントシステムが標準化されていれば様々な資源配分がもっとスムーズに、かつ、最適に実施されるはずである。災害対応について考える前にトヨタのカンバン方式について学んでみてはどうだろうか。

参考図書：トヨタ生産方式―脱規模の経営をめざして・・・ 大野 耐一

 

～ＩＣＳとはトヨタのジャスト・イン・タイム方式を災害対応に応用したものである～

 

 

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

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

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

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

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

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

オンライン辞典で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があるということが証明できればそのための手段はいろいろあるということになり、柔軟性が増すのである。

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

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

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

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

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

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

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

話が少し横にずれたが、米国ICSの５つの基本機能について再度考えてみよう。ところで、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）の４つの小機能に分かれるとされる（集まった資源（人や物）を管理し、被害の状況を管理し、様々な文書を管理し、任務の割当てを管理する。）。つまり、P＝R+S+Do+Deと米国は定義しているということである。しかし、このような定義というのは、国や組織によってまちまちであって、何かが正しいとか間違っているという問題ではない。例えば、ドイツのICSの場合、基本機能としては、Incident Command、Personnel/Administration、Information Gathering/Assessment、Operation、Logistics、Media and Press、Communication and Transmissionの７つが定義されているし、オーストラリアなどでは米国ICSをほとんどそのままコピーしつつも、Administration/Financeという機能は独立させる必要はないとしてLogisticの中に小機能として含めているようである。このように、基本機能の定義というものは、文化や習慣、言語などによって異なるのが普通であり、どのように定義すると自分達の組織の最大多数の人にとってわかりやすいかという点を検討し、コンセンサスにて決められるべきでものあろう。

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

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

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

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

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

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

• 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（広報、メディア対応、議会との関係、外国との調整活動などを支援する機能）

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