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

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

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

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

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

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

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

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

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

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

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

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

 

 

危機管理用語はわかりにくい

デカルトは方法序説の中で「難問は分割せよ」と言った。大抵の難問は分けて考えれば意外と簡単に解けるものであるという意味だが、日本では、最も難問とも言うべき危機管理がきちんと分割思考で検討されているとは思えず、高い曖昧性と意味不明の用語の乱用の中で運用されている。

そもそも「危機管理」という単語自体が極めてあいまいな語であって、どこにも定義らしい定義が存在しない。最初に危機管理を唱えたのは佐々淳公氏らしいが、氏もあまり細かな定義はしていない。この言葉を英語に直すと「クライシスマネジメント」だと思っている人が大半だが、Amazon.comでCrisis Managementと検索すると、大規模災害などのマネジメント関連書ではなく、どちらかというと企業不祥事などような企業危機のマネジメントに関する書物ばかりが表示される。

防災や大規模災害のマネジメントというカテゴリーは「インシデントマネジメント」という語になる。日本ではインシデントマネジメントというとITセキュリティーの用語だと勘違いしている人が多いが、ITシステムに対する攻撃がITセキュリティインシデントと呼ばれているだけのことであって、それが本家本元というわけではない。何らかの重大被害を生じさせる恐れのある事態がインシデントだと思っている人も多いが、それも間違っており、すでに重大な被害が発生している場合もインシデントである。すでに発生した事態がまた更に大きく甚大な被害を生じさせることもあるわけであって、その意味ではすでに発生しているか、発生しそうになっただけかは問題ではない。Amazon.comでIncident Managementと検索すると米国の防災基本計画ともいうべき「National Incident Management System」などの関連書が表示される。

小規模なものがインシデント、その次がアクシデント、更にそれが大きくなるとクライシス、などのように分けている場合もあるが、どの程度規模ならそれぞれ、インシデント、アクシデント、クライシスなのかを区別するのは、主観的にならざるえず、少なくとも法的に区別することは困難である。米国などでは被害の種類や大小に応じてマネジメントの仕組みを変えるなどということはできないため、インシデントの種類や被害の大小に応じて、投入資源の種類や投入量を変更するだけという考え方をとる(資源は変わるが機能やプロセスは変わらない)。なお、インシデントにぴったりと相当する日本語は存在しない。インシデントを「危機」と訳している人もいるが、これは大変な誤解を招く。警察官がひとりで対応するような交通事故もインシデントであるし、ちょっとした船舶海難も立派なインシデントであり、決して、日本語でいう危機的状態のみを指すわけではない。インシデントは、外来語として処理せざる得ない単語であり、意味を説明し、外来語として広げていくべきだろう。

マネジメントは、いくつかの段階に分かれる。まずは、大きく分けて、インシデントが発生する前と後。そして、インシデントが発生する前の段階は Prevention/Mitigation、 Preparedness、発生した後の段階は、Response、Recoveryに分かれる。そして、これらの英単語の意味自体は、英語圏内ではかなり明確だが、これを日本語に訳す段階で、人それぞれの趣味に応じたバラバラな翻訳が存在し、それぞれの日本語の意味が不明になっていることが多いようだ。

HazardとThreatという語についても不明確。ハザード(Hazard)[1]は、危険因子とか危険要因などと翻訳されることもあるが、「ハザードマップ」などのように外来語として定着している感もある。ハザードマップのハザードは「危険地域」という意味合いが強いが、本来的には「地域」かどうかは関係なく、害を引き起こす可能性がある根源的な要素という意味である。例えば土砂崩れが起きそうな山肌とか、洪水を起こすかもしれない河川とか、地震が起きるかもしれない断層帯とか、爆発するかもしれない危険物などのように災害を起こす要因となりうるものが「ハザード」である。ただし、河川とその水面より低い土地という2つの資源が掛け合わされて人間に対して害を及ぼす可能性のある新たなハザードが構成されているという解釈は成り立つので、洪水災害を起こす可能性がある土地自体をハザードマップ上でハザードと呼ぶことは特段の問題はない。他方、コンピュータウィルスによる攻撃やネットワークへの侵入、戦争における敵からの攻撃、ビジネスにおける競合他社の活動などのようなものはThreat[2]と呼ばれ、そのまま「脅威」と訳されている。ハザードと脅威は、使用される分野が多少違う(ハザードは防災分野、脅威は戦争やITセキュリティなどの分野)だけで、意味するところは、どちらも同じだ。要するに「害を引き起こすかもしれない何か」だ。更にリスクマネジメントの分野では「リスク源(Risk Source)」[3]という語もある。これも同じである。

[1]      Hazard: Source of potential harm(ハザード:害を及ぼす可能性のある源).  NOTE Hazard can be a risk source(注:ハザードはリスク源と呼ばれることもある). (ISO Guide 73:2009(E/F), Risk Management – Vocabulary, First Edition, 2009)

[2]     脅威:システム又は組織に損害を与える可能性があるインシデントの潜在的な原因(ISO27002:2006  2.16)

[3]     リスク源:それ自体又はほかとの組合せによってリスクを生じさせる力を本来潜在的にもっている要素(ISO31000:2009  2.16)

つまり、ハザード=脅威=リスク源、である。

ところで、Preventionとは、和訳すると「予防」である。つまり、被害が発生しないようにすること。このためには、ハザードや脅威を根本的に除去するしかない。従って、100%除去することができるものもあればできないものもある。例えば、河川というハザードがあったとする。この場合、河川自体を埋め立ててしまえば、少なくともその川に起因する災害が発生する可能性はゼロになる。土砂崩れを起こしそうな山があったならばその山自体を削って平らにしてしまえば土砂崩れは起きない。踏切も電車と車がぶつかるというリスク源である。この場合、電車の線路と道路を立体交差にして物理的に踏切というリスク源を除去してしまえば電車と車がぶつかるリスクは回避できる。原子力発電所を廃止してしまえば原子力災害のハザードはゼロとなるので原発事故は回避できる。戦争では敵を攻撃して殲滅してしまえば敵の脅威はなくなり、敵から攻撃は回避される。逆に敵と和解した場合、敵からの攻撃は一時的には回避されるが、裏切られる可能性もあるので、その脅威を100%除去することはできない。コンピューターウィルスもしかり、ウィルスを作っている連中を逮捕して除去できればよいが、すぐに別の人間が開発するので、その脅威を100%除去することはできない。地震を起こしそうな断層をなくすなどということは物理的にできないし、地球のマントル対流を止め、プレートが動くのを止めることもできないので、地震というハザードも100%除去することはできない。

このようにハザードや脅威を100%除去することができない場合、次にできることはMitigationである。実は、このMitigationという語の和訳は人によってバラバラであって一定ではない。私は、「減災」と訳していたが、英和辞書の訳通りに「軽減」や「緩和」と訳す人もいる。一部のジャーナリストには、「減災」を後に述べるResponseの意味で使っている人もいる。しかし、MitigationとResponseは明確に異なるフェーズである。Mitigationとは、脆弱性(Vulnerability)を下げ、ハザードや脅威に耐える力を増強すること、言い換えれば、弱みや弱点を補強すること、対抗性を強化すること、である。コンピュターセキュリティーの分野では、ウィルスによる攻撃や外部からのネットワークへの侵入といった脅威に対して弱いことを「脆弱性がある」とか「脆弱性が大きい」などという。中には「脆弱性が高い/低い」という表現を使う人もいるが「高い/低い」では混乱する。「ある/なし」「大きい/小さい」の方がよいだろう。脅威からネットワークを守るためにはその弱点を補強する、すなわち「脆弱性を小さくする」必要がある。ただし、この脆弱性とか、「脆弱だ」という単語、決してコンピュターの世界だけの特殊用語ではないはず。普通に災害などで使っても違和感はない。要は、弱いところを強くして、ハザードや脅威に対する抗力を増強すること、それがMitigationである。例えば、住宅の耐震性を強化する、巨大な堤防を作って津波から守る、ワクチンを打ってインフルエンザウィルスから身を守る、子供がベランダから落ちないように転落防止策を作る、土砂崩れ防止策を山肌に作って土砂が道路に落ちてこないようにする、コンピューターのOSやセキュリティソフトをバージョンアップして、セキュリティーホールを少なくする、などなどである。Mitigationには該当するよい日本語がない。あえて意訳して「脆弱性最小化」とでもしたほうがよいかもしれない。

そして、Mitigationをしても所詮、被害が発生する確率や可能性を「減少」させているに過ぎない。ハザードや脅威そのものを取り除いたわけではないので、被害発生の確率や可能性は依然としてゼロではない。従って、被害の発生に備えておかなければならない。これがPreparednessであり、「準備」と訳される。この訳には何の問題もないだろう。なお、日本語で「災害への準備」と言った場合、前述のMitigationに関することまで含んだ意味で使われていることもある。しかし、この2つは明確に異なる。Mitigationは、被害が発生する確率に働きかける、すなわち被害が発生しにくくする行為であるのに対し、準備(Prepareness)は、どんな被害が発生しようとも迅速に「人間」が対応(Response)し、被害が次から次へと広がっていくのを防ぐための資源をあらかじめ用意しておくことだ。人間が迅速に対応するために必要なものは、資機材、制度、練習、訓練などである。これには、異常事態を検知したときに人間に知らせるアラームの設置や緊急時の対応計画の策定、消火器や消防車などの資機材の購入、防災訓練、研修、第3者との協力協定の締結などが含まれる。いずれもポイントは「人間による対応」ができるようにしておくこと、である。

Mitigation(脆弱性最小化)とPreparedness(準備)は何が違うのかと言えば、Mitigationは、人間以外の「物」による防御、言い換えればSafeguardを構築することである。「物」が自動的に対応してくれるように備えておくこと、と言うこともできるだろう。これに対し、Preparedness(準備)は、「人間」が手動で対応できるように備えることである。

インシデントが発生し、Mitigationの段階で構築したSafeguardが破られた場合、最終手段として人間が対応しなければならない。これがResponseであり、その訳として「対応」という語は、すでに幅広く使用されているようである。なお、人間が効果的にResponse(対応)するためには、その前段階であるPreparedness(準備)が十分なされているかどうかにかかっている。ただし、インシデントへの対応方法などを完璧に予測して準備しておくことは不可能である。準備しておいた資機材や人材、各種の計画などを臨機応変に活用してベストの解決策を創造する、言い換えれば、発生したインシデントに応じて、準備しておいたいろいろな人や物、計画書などを適宜組み合わせて解決方法のイノベーションを起こすこと、これが対応時のポイントだろう。

インシデント発生後の段階としては、Response(対応)とRecovery(復旧)があるが、この2つはどう違うのか。どのような状況になったらRecovery(普及)段階と言えるのか。これも厳密に定義することは難しい。インシデントが発生すると何らかの資源に害が及ぶ、または害が及ぶ恐れが顕在化し、ほっておくと何かの資源が失われていく。ここでいう資源とは、目に見える人間、物、道路、建物、お金などだけでなく、目に見えない「信用」などの場合もある。従って、失われつつある資源を救助し、被害の最小化を図ること、これがResponse(対応)の段階の仕事ではないかと考える。

資源を救助する方法には2種類ある。一つ目は資源そのものを救助する方法、二つ目は資源が提供している機能を救助する方法である。インシデントが発生した場合はまずは資源そのものを救助しなければならない。それも、人間という人的資源の救助が最優先であり、その次に人間以外の資源ということになるだろう。人間以外の資源をどのような順序で優先的に救助するかは、人や組織によって異なるものであり、それぞれ個別に検討しておかなえればならない。いかなる場合でも、失ったら復旧することが不可能な資源の救助が最優先(人命という資源は失ったら元に戻すことができない)である。なお、人間という資源の救助には、がれきの山の中から生存者を救助するというような狭義の救助に加えて、その後の医療支援なども含むものとする。

二つ目の救助方法である「機能の救助」とは、代替資源を使用するということである。例えば、東京メトロで事故が発生した場合、東京メトロでの復旧作業が行われている間、JRで振替輸送が行われる。これは、東京メトロという資源が提供している輸送という「機能」をJRによる輸送によって救助しているようなものと考えることができる。これにより、普段は30分で行けるところが1時間以上かかるかもしれないが、行けないよりもマシということである。なお、このような代替サービスを提供するためには、インシデントが起きる前に東京メトロとJRが協定なり契約なりをあらかじめ結んでおかなければならない(あるいは鉄道の公共性に鑑み、役所が法律によっていざというときの協力を義務付けているのかもしれない)。東京メトロとJRは普段はコンペティターだが、いざというときはひとつの組織のように協力する仕組みをあらかじめ構築しておくということである。

なお、この「機能の救助」という段階を民間企業のBCMSでは「事業継続の段階」と呼ぶこともある。Response(対応)とRecovery(復旧)の間で、どちらとも一定期間オーバーラップする段階である。ただし、事業継続と言ってしまうと民間企業特有のものと考えてしまうかもしれないが、決してそのようなことはなく、道路が寸断されたときの迂回路の設定、災害時における食糧支援、仮設住宅の提供などもこれに属する。

最後の段階がRecoveryである。復旧と訳されたり、復興とも訳されることがあるが、どちらもその規模感の違いだけで意味するところに違いはない。この段階での仕事は、ダメージを受けた資源を元通りに戻すということである。ただし、完全に元通りとするのがよい場合とよくない場合がある。また、元通りにそもそも戻せない場合もある。例えば、人命という資源は、一度失われてしまうと復旧不可能である。世の中にはこのような「不可逆性」があるものが多数ある。そのような場合には復旧不可能ということになり、復旧の前段階である「機能の救助」をもって我慢しなければならない事態もあるだろう。生命保険なども人間が提供していた生産機能を金銭にて代替する「機能の救助」と考えることができる。東日本大震災で大きな津波被害を受けた一部の三陸沿岸の町では、元々あった場所に町を復旧するのではなく、高台移転を促し、元と異なる場所に町を構築した。これも、どちらかというと元あった場所に戻ると再度津波にあう危険があるため、不可逆性のある状態だ、と考えることができる。従って、町という資源をそのものを元に戻すのではなく、町の機能を高台に移すという一種の機能の救助を実施したと考えられる。

ところで、わが国の災害対策基本法は、どのような区分をしているのだろうか。この法律には、「災害予防」「災害応急対策」「災害復旧」の3つしかない。法律の内容をよく読むと、

「災害予防」= Prevention + Mitigation + Preparation

「災害応急対策」 = Preparation + Response

「災害復旧」= Recovery

である。この法律は制定されたのが昭和36年と非常に古い法律であり、内容もグローバルスタンダードとはかけ離れている。法律に基づく防災基本計画は、各役所が予算を獲得するための道具としては役に立っているかもしれないが、実際のインシデントに対応するためにはあまり役に立たない。