危機管理とゲームの理論

普段のビジネスや人間関係では、我々は顧客の利益を第一に考える。いわゆる「顧客第一主義」である。なぜ、自社の利益よりも顧客の利益を優先に考えなければならないのか。これはゲームの理論における囚人のジレンマで説明できる。

例えば、A社がB社に何かの商品を売ろうとしたとして、A社が顧客B社に対してまともな商品を売ったときA社とB社の満足度は共に3、A社が不良品をB社に売ってB社がそれを買ったときの満足度はA社が5でB社がマイナス2だとする。このような場合、短期的に見た場合、A社としては何とかB社をだまして不良品を売ってしまいたいという衝動にかられるが、だまされた相手は必ずしっぺ返しをしてくる。従って、A社とB社の関係が長期的かつ永続的な関係が期待できるならば、満足度が3であってもB社をだますことは避け、まともな商品を売っておいた方が満足度が大きくなる。つまり、一回限りのゲームであれば、相手を裏切ってでも自分の利益しか考えないかもしれないが、ゲームが無限繰り返しゲームになれば少しばかり自分を犠牲にしておいた方が得ということになるのである。

ただし、災害などが発生した場合には、このゲームの構図が変わってくる。自分の生死が問題にならないような通常時には、相手との関係を無限繰り返しゲームにすることによって、関係をWin-Winにすることができるが、ほっておくと自分の生命や自社の生き残りが危うくなるような場合には、無限繰り返しゲームにすることができない。従って、相手の利益よりも、自分の生き残りの方を優先に考えなければならない。まず、自分の安全、自分の家族の安全、自社の安全、自分のコミュニティーの安全が優先となる。すなわち、プライオリティーが変わってくる。

これは、我々の住む民主主義国家であれば当然に認めらる権利であり、自分を犠牲にしてまで、他人につくせ、などという権利は誰にもない。一部の新興宗教や自爆テロ強要するテロ集団、独裁国家の北朝鮮など以外は、当然に保障されている権利である。だから故に、刑法にも正当防衛や緊急避難などの違法性阻却事由が存在しているわけである。

通常時は、このように時間軸を長期にとるなどによってパイを大きくし、第3者との間のゲームを非ゼロサムゲームにすることができる。しかし、そこに突然やってくる災害と自分との間のゲームは災害という目に見えない敵を相手にしたゼロサムゲームになる。従って、目に見えない敵とのゲームに対処することを優先せざる得ない、という解釈もできる。

「インシデント」の語の定義は、あいまいであり、多くの学者がいい加減な解釈をしている。しかし、このように「ゲームの継続性を困難にし、自他との関係性におけるプライオリティーに変更を余儀なくする事象」ととらえるとすっきりする。

そもそもインシデント・コマンド・システムとは何か?

〜標準化自体が目的でありメリットである〜

See ⇒ 標準化とは何か?

最近は政府レベルでも、災害時のマネジメントシステムを標準化する必要性が少しずつ認識されてきており、まだ、ごく限られた一握りの人々の間ではあるが、検討会や勉強会が開催されている。国会議員の先生から筆者にも声がかかったのでボランティアで協力しているところであるし、民間でも、リスク対策ドットコムがインシデントコマンドシステム(ICS)の特集を実施したり、セミナーでICSの特集をやってみたりとアメリカで流行っているICSとは一体何なんだ、と関心をもつ人が少しずつ増えている。それはそれでよいことだ。

しかし、インシデント・コマンド・システムとは一体何なのか、そのメリットは何なのか、何をもってICSと定義するのか、などの点についての理論的背景については官民学を含め、まともに理解している人はどうもいないようだ。筆者は、かつて海上保安庁に勤めていた際、もう10年以上前のことだが人事院の留学制度でジョージ・ワシントン大学危機管理スクール(ICDRMという一種の危機管理専門大学院)にてこの種の理論を勉強した。これは大学院大国のアメリカでも極めてマイナーな大学院コースであるので、恐らくこの種の学問のために留学した日本人は筆者くらいしかいないのだろう。筆者は、その後、オーストラリアのボンド大学でMBAも取ったが、この両方を勉強してみると非常事態のマネジメントシステムと普通の企業経営とは大した違いがないものであり、どちらもマネジメントシステムの一種であって、その目的と時間軸が異なるだけのものである、ということに気がつく。

ある会合での他の先生方の発言を聞いていると「日本ではICSは無理だ!」とか「ICSを実践しなければならない。」などという意見があった。しかし、このように主張する場合、そもそもICSとは何なのか、どのようなものが無理なのか、何を実践すればICSを実践したことになるのか、という点をきちんと定義しなければ無意味な意見だろう。はっきり言ってしまえばアメリカと全く同じシステムを導入しようとしてもそれは確かに無理なことである。

最初に言っておきたいが、ICSとは何なのかは国際的には何も決まっていない。ICSという名のシステムを導入している国は、米英加独豪などいくつかあるが、その内容は国によって様々であり、国連等において国際標準化されているものではない。インターネットなどではアメリカのICSが主として紹介されているが、それが全てではない。

そこでICSを「アメリカの緊急時マネジメントシステム」という定義にしてしまうと、どこかの先生が言ったように「日本にICSを導入することは無理」ということになる。言い換えると「アメリカのICSと同じICSを導入することはほぼ非現実的」である。言語体系も価値観も現状の仕組みも全く異なる中で、アメリカのマニュアルをコピーし、日本語に翻訳して実施すれば日本の災害時におけるマネジメントが改善すると考えるのは、極めて浅はかな発想と言わざるえない。ある人は「Operation」を「運用部門」と訳し、他の人はこれを「実行部」と訳し、さらに別の人はこれを「事案処理班」と訳してみたりと人によって1つの単語の翻訳や解釈自体すらバラバラであるが、このように解釈がバラバラな状況下においてアメリカのマニュアルを訳して日本で即座に実施できるわけがない。即座に何か効果があると思うのは少々短絡すぎる。このように解釈がなぜ分かれるのかというと日本語と英語に間に非常に大きな概念上のギャップがあるからである。このような概念上のギャップがある中で下手な翻訳をして現場に浸透させようとすれば、現場は理解できないので大混乱を起こし、「なんでこんなことをしなければならないのだ〜!」などとの空気が広がり、正のメリットよりも負の弊害の方が大きくなるのは間違いない。実際にISO9000やISO14000という欧州発のマネジメントシステムが日本に紹介されたとき、このような空気になった。このため、私が以前、「ICSとは標準化されたマネジメントシステムである。」との説明をある会合でしたとき、何人かの人が「またISO9000みたいなことをするのか〜」と拒絶反応を示した。どうも「標準化」と聞くとISO9000などの悪いイメージを持つ人が多いようだ。

ICSの正しい定義は「インシデントに対応するための標準化されたマネジメントシステム」である。マネジメントシステムというものは、その良し悪しは別として、如何なる組織にもすでにあるものであり、そのようなバラバラなマネジメントシステムの中でもインシデントへの対応に係る部分のみを統一したものがICSであると考えればよい。言い換えれば、普段は異なる複数の組織を緊急時にはあたかも同一の組織であるかのごとく扱うということである。標準化し、組織間のコミュニケーションコスト(経済学でいう取引コストの一種)を削減するということが最大のメリットである。つまり、「標準化」すること自体にメリットがあるのであり、これをとったらほとんど意味がなくなるものである。従って、イメージは悪いかもしれないが「標準化」のメリットをまず強調した上で、今後、制度構築や世論へのアプローチを行っていかなければならない。

「標準化とは何か?」 参照

「標準化」の意味は非常に広いものであり、標準化できないものはないと言ってもよい。わかりやすいものでは、携帯電話や乾電池である。携帯電話は通信プロトコルや無線インターフェースがITUという国際機関で標準化されているから、世界中どこの国へ持って行ってもつながる。乾電池も単1だの単3だのというサイズがISOで標準化されているから、世界中どこに行っても同じサイズのものが売っている。日本語などの言語も国内で標準化されているコミュニケーションのための道具と考えることができ、「桜」といえばあの4月に咲く美しい花、と日本人ならイメージすることができるのは皆が共通認識を持っているからである。しかし、言葉は国際的には標準化されていないので、米国で日本語を喋ってもコミュニケーションできないのである。同様な発想で組織というものも標準化できるのではないだろうか、との意見がある日ISOという国際機関に持ち込まれた。その結果生まれてきたものがISO9000やISO14000というマネジメント規格と呼ばれているものであり、組織のあるべき姿を標準化したものである。ISO9000であれば、一定の品質の生産物を産出するために必要なプロセスや意思決定の仕組みを要件として定め、定められた要件を満たす企業等に証明書を発行し、「この企業には一定品質の物やサービスを作る能力がありますよ」と権威ある機関がお墨付きを与える、というものである。注意しておかなければならないのは、ISO9000を持っている企業が「良い品質」の物を作ることは保証されないということである。あくまでもISo9000を満たす企業は「一定の品質」の物を安定的に産出する能力があるということが強く推定されるにすぎない。

マクドナルドを例にとってみよう。マクドナルドではどこのお店に行っても全く同じ品質のハンバーガーを同じように短時間で買うことができる。サービスや店員の挨拶の仕方までどこへ行っても同じである。一見何の不思議もなくいつも食べているが、よく考えてみればこれは不思議なことである。そこで働いている人や店長も異なるのになぜ同じになるのだろうか。実はこれはマクドナルトという1つの企業の中で各店舗におけるプロセスや意思決定の仕組み、サービスの仕方、それに必要な資機材に至るまでが非常に詳細に標準化されているからである。言い換えればマニュアル化されているのである。職員は研修等でそのマニュアルを徹底的に覚えこまされ、訓練も受けている。だから、どこに行っても同じハンバーガーが食べられる。マクドナルドは当然ISO9000の要件を満たす企業であろう。なぜならば、「一定の品質」のものが安定的に産出されているからである。

このようにマネジメントシステムを標準化、言い換えればマニュアル化すると一定の品質のものが短時間で得られるようになる。そのためには、権限の現場への移譲なども伴わなければならない。マクドナルドの各店舗がその本社にお伺いを立てなければならない仕組みになっているとしたならば、このように短時間でハンバーガーは出てこないであろう。日本では福島第一原発事故時に首相官邸が「水を入れろ」とか「ベントしろ」などという非常に細かいことに口を挟んでいたが、これは各店舗におけるハンバーガーの焼き方についてまで本社どころか総理大臣が口を挟んだようなものであり、如何にプラスにならない行為であるか多くの人に考えてもらいたい。

複数の組織間で標準化の例としてはBTOパソコンが挙げられる。BTOとはBuilt To Orderの略、すなわち、顧客からHDDの容量やCPU、オプション装置の有無などの希望スペックを聞いてから注文生産されるパソコンである。注文生産と聞くと時間がかかると誰もが思うであろう。しかしながら、BTOパソコンは注文してから希望のスペックにあったパソコンが手元に届くまでは数日であり、驚くべきほど早い。これも、システムが非常に高度に標準化されているため可能になっているものである。ところで、BTOパソコンを作っているのはひとつの企業の工場で作られているわけではない。HDDはどこどこ、ディスプレイはどこどこ、RAMはどこどこというように別々の企業が生産しているものが大半であり、企業の垣根を超えてオーダーが瞬時に伝えられ、顧客の希望に沿った部品が用意され、瞬時に組み立てられ、顧客の元に届けられる。場合によっては国境を超えた別の国にある企業間でこのやり取りが行われているものさえある。これは、部品の規格や企業間でやり取りされるデータのフォーマットなどが高度に標準化され、それを瞬時に伝達する仕組みがあるから可能になっているものである。このシステムはサプライチェーン・マネジメント(SCM)と呼ばれているが、言わば企業の垣根を超えたトヨタのカンバン方式(Just In Time方式)である。

そして実は災害マネジメント、緊急事態へのマネジメントというものもこのように標準化することによって、迅速かつ高品質な対応を提供することが可能になる。災害等の緊急事態は時間との戦いになるのは言うまでもない。時間とともにどんどん被害は広がっていくものである。迅速な意思決定と迅速な対応は必要不可欠であるが、日本の場合、これが極めてトロい。非常に遅い。非常事態にあっても役所が縦割りで縄張り争いをしたり、責任の押し付け合いをする。あちこちに◯◯対策本部というものがたくさんできるが書類を右から左に転送しているだけであり、そこが何を意思決定しているのかさっぱりわからない。個々の職員は一生懸命やっているのは事実である。しかし、それが国全体として最適化されていない。これが現実である。ただし、各省庁が単独で対応するような場合、例えば、海上保安庁が単独で海難救助を実施する、消防が単独で火災を消す、警察が単独で事故に対応する、などのような場合は大きな問題なく、スムーズに行われる。これはなぜかというと各省庁には自分の省庁にのみ適用されるマニュアルが訓令や通達という形で存在するからである。日本人はこのようなマニュアルがあればきちんと動く。そうゆう緻密さがあることは間違いない。しかしながら、全省庁に適用されるような横断的なマニュアルがない。だから、動けないし、動かないし、責任の押し付け合いをする、ということになるのである。そして、この組織横断的なマニュアルに相当するものがアメリカなどで導入されているICSだ、と考えてもらうとわかりやすい。各省庁のみに適用されるマニュアルもよく分析してみれば、他の組織と共通化できるプロセスや機能や装備というものはあるものである。言い換えれば、共通化できるものとできないものとがある。共通化できるものを共通化することができれば、組織の垣根は低くなる。例えば、各省庁の保有する無線機は周波数もデジタル方式も異なるが、これを共通化するだけでも意思疎通は改善し、効果は絶大である。さらにその通信の中身である言語、用語、単語の定義なども共通化すればさらに意思疎通は改善する。さらに情報交換のフォーマットも共通化すれば情報の漏れやダブリがなくなる。どのようなプロセスでだれが意思決定をするのかが決まっていれば意思決定も迅速化する。目標管理(MBO)を採用すれば現場の自立性が更に高まる。ICSとは簡単に言えばそのようなものである。

日本は阪神大震災や東日本大震災などを経験しているはずだが、緊急時のマネジメントシステムを改善することに関しては誰も何も手をつけて来なかった。何も変わっていないといっても過言ではない(原子力災害に関しては10年前に原子力災害対策措置法という法律ができ少し改善されたがその他は無策)。変わらない理由は幾つかあるだろう。1つには、役所のマネジメントシステムが目に見えにくいという点があげられる。2つ目は、役所の人事異動が激しすぎ(1年から2年でゴロゴロ人が変わる)、このような複雑かつ根本的な制度改正ができない、または、できる人がいない、という点もある。さらに3つ目としては、どのように改善したらよいのか、あまりよいモデルがなかった、という点もあるであろう。少なくとも3つ目のモデルとしては、海外のICSやインシデントマネジメントという概念が目に入ってきているようであるので、手元にあると言える。しかし、残りの2つも手強い。まず、役所のマネジメントシステムを目に見えるものにしなければならない。そして、役所の人事異動の周期も改善する必要がある。少なくとも災害、防災関係者は10年くらい異動がないというくらいにしなければならないであろう。災害などというものは10年に1度くらいしかない。折角、貴重な経験をしたスタッフを変えてしまって何が改善できるのか。全く、愚かである。なお、そもそも、役所はなぜ、このような超短期の人事異動を繰り返しているのかというと一言で言えば「責任回避」のためである。いろいろな経験をさせるためだとか業者との癒着防止のためなどという人もいるが、それは言い訳だ。いろいろ浅く広く経験するということは全てにおけるド素人を作っているということであり、災害時など短時間での意思決定と専門的知識が要求される場面では極めてマイナスに働くことになる。全てのスタッフを専門職化せよとは言わないが半分くらいのフタッフ、せめて防災関係者くらいは専門職化し、10年くらい異動がないようにしないと何もできないし、緊急時にロクな対応ができないであろう。

話が多少横道にそれたが、要は、災害時、緊急時におけるサプライチェーン・マネジメントのようなシステムを作ることが必要だということなのである。なお、ここでパソコンの部品に相当するものは、消防の部隊であったり、DMATのような医療専門チームであったり、海上保安庁のような海難救助の専門部隊であったり、警察の部隊であったり、道路の復旧をする自衛隊の部隊であったりするかもしれない。これらは部品といってもパソコンのHDDのような物ではなく、人や資機材の集合体と考えたほうがよいだろう。そして、この集合体を専門的には「ファンクション(機能)」と呼ぶ。災害の種類や大きさによって必要なファンクションは当然異なる。このような考え方はアメリカなどでは「ファンクショナル・アプローチ」と呼ばれている。千差万別の災害に対し、必要なファンクションを柔軟に組み合わせることによって解決する。そして、このファンクションを高度に標準化しておくとともに通信方式なども標準化しておき、いつでも誰でも瞬時にオーダーできるようにしておく、ということがICSの目的であり、本質である。このように見てみると、災害対応とはオーダーメイドのパソコン作りとあまり変わらないということが理解できるであろう。

標準化とは極めて広い概念であり、何でも含まれる。意思決定の権限を誰に与えるのか、どのような本部を作るのか、どのような手続を踏むのか、などといったことも全て含まれる。そして、これらの要素は必ずしも日本において全く標準化されていないわけではない。災害対策基本法や原子力対策特別措置法などといった法律で、さまざまな仕組みはすでに標準化されている。しかし、米国などのようにもっと詳細なファンクションやプロセスまでをも標準化する必要があるということなのである。従って、米国と全く同じICSを日本に導入するということは到底非現実的な話であるが、さまざまなマネジメント要素を標準化するということ自体は決して不可能なことではない。すでに部分的には標準化されているものはあるので、これらをどのように修正し、かつ、追加的に何を標準化すれば普段は別々の組織が緊急時には単一の組織であるかのごとく、スムーズかつ迅速に活動することができるようになるか、ということなのである。言い換えれば「最適化」作業だともいえるものである。

筆者は、「日本にインシデントコマンドシステムを導入する」とか「日本版ICSを構築する」という表現は混乱を招くものだと思っている。米国でもインシデントコマンドとインシデントマネジメントの違いは不明確である。代わりに「日本のインシデントマネジメントを標準化する」ということを目標にした方がわかりやすいし、やらなくてはいけないことを正確に表わすのではないかと考える。しかし、ここで問題になるのはインシデントの定義である。インシデントとは一体何か? ISOには次の定義がある。

Incident = “Situation that might be, or could lead to, a disruption, loss, emergency or crisis”  (ISO22300(2.1.15)) 「中断・阻害、損失、緊急事態又は危機になり得る又はそれらを引き起こし得る状況」

インシデントを「危機」とか「事案」とか訳している方もいるが、これらは不適当である。実はこれに相当する日本語が存在しないのである。東日本大震災のように最初から大災害のものもインシデント、日々発生しているような交通事故もインシデント、医療事故もインシデント、航空機がニアミスを起こすのもインシデントであり、火事もインシデント、企業の工場で生産ラインが止まってしまうのもインシデント、製造ラインに農薬を混入されるのもインシデント、パソコンがウィルス感染するのは情報セキュリティインシデント、みな全てインシデントである。そもそも、かつては事故(アクシデント)が発生する一歩手前の状況がインシデントと呼ばれていたのだが、事故などが発生した後でもほっておけば被害は拡大していくわけであり、その意味ではその事故自体がまた他の事故や危機の発生する一歩手前と考えられるという観点から目に見える事故が発生する一歩手前の状況からすでに目に見える事故や災害が発生してしまった状況までをも含めてインシデントと呼ばれるようになり、ISOではそのような定義がされたのであろう。突発的な出来事で、迅速な対応が要求され、即座に対応しなければ被害が広がっていくものは全てインシデントという言葉で含有されるのであり、インシデントには大小様々、種類様々なものがあるということである。決して危機とか大災害だけを指すものではなく、また、事故が起きる一歩手前の状況のみをインシデントと呼ぶわけでもない。普段発生しているような小規模なインシデントから10年に一度しか発生しないような大規模なインシデントまで、全てを同列に扱うこと、これがインシデントマネジメントの基本であり、それを可能にするのがファンクショナル・アプローチという発想なのである。なお、適当な日本語が存在しない以上、インシデントは外来語としてそのまま普及に務めた方がよいのではないかと思っている。

なお、マネジメントには継続的な改善が必要不可欠である。つまり、現状を踏まえた上で問題点を抽出し、少しずつ改善していかなければ組織全体にはなかなか浸透しない。従って、米国のICSマニュアルを日本の役所などにいきなりもってきて、そのまま実施せよと言われても理解できるわけがない。これは水と油のような関係である。米国のみならず諸外国のシステムを研究し、どのようなマネジメント要素が共通化され、どのような要素が共通化されていないのか、を詳細に分析し、そのような理論的背景を十分踏まえた上で自分たちのマニュアルのどこを切り離して共通化し、どこを共通化しないのかを考えなければ実用的なものはできない。

現在、インシデントマネジメントの標準化に携わっている方々には今一度標準化の目的を考えていただき、何のための標準化なのか、どんなメリットがあるのかを再認識してもらいたいと思っている。