想定外事故発生対応マニュアルの作り方

想定外事故が発生した場合の対応マニュアルを作るときの考え方がわかりません。
どういう考え方でマニュアルを構成すればいいのでしょうか。

No.2 ベストアンサー 回答者： noname#149221 回答日時： 2012/01/03 17:17

以前、とあるプロジェクトのリスク管理チームにいたこと

があります。いったい何に対する想定外事故なのかという
ことや、想定外の定義にもよりますので、ざっくりと。

たとえば、Ｘという結果を得るために、Ａ、Ｂ、Ｃという
要素からなるシステムＤが運用されていると考え、この
システムに対しての「想定外マニュアル」を作成する、
ということだと仮定して回答します。ここでいう想定外とは
「Ｘという結果が得られなくなった」もしくは「Ｘという
結果を得る過程で予想外の危険が生じた」という事態を指します。

Ｘという結果が得られている状態というのは、言いかえれば
システムＤから得られる結果が、所期の成果（目的通りの動き）
を見せているときのことです。この場合、全体を構成する個々の
要素同士（Ａ、Ｂ、Ｃ）の連関は、比較的単純でとらえやすい
プロセスの連なりとして記述できます。

これに対して、得られるはずのＸという結果が得られなく
なった場合、すなわちシステムＤの帰結が所期の成果から
外れてしまった場合、個々の要素の連関が多ければ多いほど、
全体的な帰結を読むのは難しくなります。というのは、本来は
Ａからaを受けてbを作りＣへと渡すはずだったＢに、Ａからa'
というありえないはずの要素が渡された場合、その後の成果も
順々に狂ってくるからです。つまり、システムが多くの構成要素
に支えられていればいるほど、初期値に対して鋭敏に反応する
モデルとなるため、プロセス同士の連関が予測不能となり、
最終的にどのような結果がもたらされるかの予想が極めて
困難となります。

したがって、こうした出来事が起こった際のマニュアルを作ろう
という立場では、「いかに全体の不具合が小さく見えるか」
という発想でマニュアル化すると大変危険です。（大きな組織の
デカいプロジェクトだと往々にしてこういうことがあるのですが…）
たとえば、表面化したa'をなんとかaにしさえすれば大丈夫
だろうとか、最後のＣからの部分で手を加えてcに戻せるだろう、
というようなマニュアル作りだと、結局その他の部分で予測不能な
動きが出て、上手くいかないことが多いのです。これは
時間・人・金といったあらゆるコストの面から考えて無駄を生みます。

お勧めするのは、こうした場合にはいったん要素ごとの運用を
停止して、各要素の内部で精査をすることです。いったん連関を
切り離して、それぞれのＡ、Ｂ、Ｃで上手く回っているかどうか
を確かめるのを優先してマニュアルを策定します。そして、「停止
から復旧までの時間」を最小にすることを最大の目的として
マニュアル化していきます。こうすることで、システム停止と不具合
の表面化は起きますが、結果的にはもっともコストがかからずに
復旧させることができます。

そしてマニュアルとあわせて予防段階として重要なのは、
平常時の個々の要素内の働き・仕組みをきちんと明確にして
おくことです。これが曖昧だったりハッキリとしていなかったり
すると、異常発生時の精査に手間取ります。そのため、
「想定内」時のマニュアルの精度が、想定外事故発生時の
マニュアルの精度も左右しうることになります。

「Ｘという結果を得る過程で予想外の危険が生じた」場合も
基本的には同じですが、こちらはより予防が重要となります。
起きてからでは取り返しがつかないケースが多々あるのがこちら
です。したがって、トラブル発生後には上のような対応となりますが、
その前段階として、発生しうるリスク情報をどれだけ収集して
マニュアルに盛り込めるかがカギです。

この情報というのは現場の意見ももちろんですが、行政庁や企業
から公にされている情報も積極的に取ることが求められます。
このケースで一番多いのが、「ありうる状況」の想定漏れです。
たとえば、回転ドアが設置されているビル、そこへ出入りする
人間の想定をビジネスマンだけにしておくと、幼い子供が
そこから漏れて事故が起こりえます。したがって、「想定外」と
されるケースについてどこまで幅広くリスクを考えられるか。
その防止策についてどこまで検討可能か、ということが、
実際の事故発生時のマニュアルの精度にも大きく影響してきます。

いずれにせよ、普段のときのシステムをどれだけ明確に把握
できているかということと、危険な情報をどれだけ収集できている
かということが重要です。あとは表ざたになろうとも、個々の要素に
分解してできるだけ早く復旧させる方向でマニュアル化すること
を個人的にはおススメいたします。

この回答へのお礼

お礼を差し上げるのが遅れて済みませんでした。
大変丁寧な説明で、考え方の基本がよく判りました。

結局は、対象のシステムについて、どれだけ理解をしているかが鍵になるんですね。当然といえば当然のことですが、眼からうろこのような気分です。

取り繕いの手順ではなく、トラブルの根幹を探し出すための手順、という視点でマニュアルを構成すればよいと考えましたが、間違っていたら再度ご指摘下さい。

ありがとうございました。

お礼日時：2012/01/04 12:34

No.1 回答者： misawajp 回答日時： 2012/01/03 12:17

マニュアルが作成できるようならば『想定外』ではありません

想定外の場合には、個々に対応するんのではなく、危険の想像予測と出来得る対応、その対応が二次災害を引き起こさないかの想像検討　が出来る能力を養うことが重要です

想定外のことが起こった場合には、確認注目する事項、情報が得られない場合・不完全な情報のみで対応しなければならなくなった時の基本的な考え方を教育する程度が限界です
あとは個人の知識能力経験決断力です

想定外の事態対応のマニュアルなどと発想することが、マニュアルの弊害に埋没して、まともな判断ができなくなっていることの証明でしかない無いことに気づくことがスタートです

この回答へのお礼

お礼が遅くなって済みませんでした。

「マニュアルが作成できるようならば『想定外』ではありません」　→　私の悩みもこの問題をどう理解した上で対応すればよいのか、ということでした。

どんな状況を想定すればよいかを考えるのではなく、想定できない状況に陥った時の為すべきこと、を考えればよいのだと理解しました。間違っていたらごめんなさい。

早々のご回答に対して、お礼申し上げます。

お礼日時：2012/01/04 12:28