最悪の事故が起こるまで人は何をしていたのか

　飛行船墜落や原発事故、ビル倒壊など50あまりの事例を紹介。誰がどのように引き起こしたか、食い止めたか、人的要因とメカニズムをドキュメンタリータッチで描く。

　もちろん、大惨事を引き起こした事故の「情報」だけなら、失敗知識データベース[参照]を見ればよい。本書とほぼ同じネタは得られる。しかし、著者が現場を見、生き残った関係者にインタビューしてたどり着いた「知見」や「生きた教訓」は、本書から掘り起こすべし。

　「そんな大惨事を起こすような巨大システムに関わってないよ」という人には、もっと身近なやつをどうぞ　→　「なぜAT車のアクセルとブレーキの踏み間違いが起きるのか?」あるいは「飛行機事故から生還するため、乗ったら最初に確認すること」は、立ち読みでもいいので押さえておこう（後者は目からウロコだった）。

　システム開発屋であるわたしの場合とは、比較しようがない。わたしが携わるシステムが止まっても、新聞には載るだろうが人死が出るわけでもない。しかし、それでも、わたしが出くわしたエラーと、本書で紹介されるエラーは、驚くほどよく似ている。そして、わたしが打っている対策と、著者が推奨する対策も、やっぱり似ているのだ。

　その本質　→　「エラーを起こすのは人、くい止めるのも人」　←　あったりまえじゃん、という人は、以降および本書を読まなくても無問題。自分の問題として本書と向き合うと、得られるものはかなりある。事故事例として読むつもりなら、前出の「失敗知識データベース」だけでOK。以下、ヒューマンエラーについて、教訓から導き出された原則と、関連する本書のトピックをまとめる。

　そのエッセンスだけ列挙すると、こうなる。

• 原則1 : 情報を集める場所と、判断する場所を、物理的に分ける
• 原則2 : 重大な問題が発生したとき、メンバーをどのタイミングで休ませるか? を最初に考える
• 原則3 : トラブルの原因を探す/被害を最小限する/プロジェクト目標へ軌道を戻す目的を分ける
• 原則4 : 「外の目」を取り入れる
• 原則5 : 現場を責めるな！

　本書は橋本大也さん紹介[参照]で知る。良い本を教えていただき、感謝感謝。以降、具体論に移る。書いているうちにどえらく長くなってしまった。本書のレビューは橋本さんのエントリの方がまとまっているので、書評を求めているならそちらをどうぞ。

* * *

原則1 : 情報を集める場所と、判断する場所を、物理的に分ける

　トラブル対応からカットオーバーまで使える。物理的に部屋を分ける（WAR-ROOM）場合や、情報屋（新人が適任）をアサインすることで、情報を得るときに発生するノイズをキャンセルし、ノイズが判断に与える影響を低減できる。卑近に言えば、「客が耳元でぎゃんぎゃん文句言っている時に、冷静にバグ改修の見通しや、対処時期や、汚染領域の回復の検討なんてできねぇだろ?」となる。

　具体的には、ホワイトボードを用意して、電話、メール、怒鳴り込みでやってくる問い合わせに対し、「未知の不具合」なのか「既知の不具合」なのか「運用者の誤り」なのか「他へ問い合わせるべきこと」なのかフィルタリングしながら書く　→　それを別の人が読んで分析・判断をするわけ。決して、書く人・聞き取る人と、読んで判断する人を同一人物にしてはならない

　「スリーマイルアイランド原子力発電所の事故」がこれに対応する。著者によると、原発の制御室には、深刻な問題があったらしい。

　原子炉がどんどん高温になっているにもかかわらず、冷却水を削減する判断をした運転員たちを批判することは可能だが、そのコンソールを設計したわけではないことも指摘しなければならない。制御室の警報システム・レイアウトは深刻な問題を引き起こす要因があり、事故が発生する1年も前に経営側へ文書による警告があった―― 実質的な対策は講じられることなく、放置されていたのだが。

　主警報装置のアラームが複数鳴り響き、100以上の警告ランプが「警告」を報じる中で、冷静に事態を把握させようとすることは、不可能だろう。

原則2 : 重大な問題が発生したとき、メンバーをどのタイミングで休ませるか? を最初に考える

　あたりまえの話なんだが、たいていの「重大な問題」は、すぐに直るはずがない。直す箇所を調べるのにも時間がかかるし、直すのにも時間がかかるし、直ったかどうか検査するのにも時間がかかるし、二次リスクが起きていないか調べるのにも、さらに時間がかかる。おまけに、重大な問題が引き起こす影響を収束させる（データ汚染が顕著）のにも、莫大な時間がかかる。

　それにもかかわらず、たいていの重大な問題は、「とりあえず」「全員で」とりかかる。小学生のサッカーのように、ボール（見えている不具合）の周りに全員が必死に群がっている。

　突貫工事の結果、その「重大な問題」は収束するかもしれないが、メンバー全員がヘトヘトになっている、おそらく寝ていないはずだ ―― では、「重大な問題」が連続して発生したら? 限界を超えた努力を強いることになる。疲労はエラーを呼ぶ。それも、トリビアルなエラーを。

　こいつを回避するために、重要なイベントの際には、最初からメンバーを交代制にして、うまく引き継ぎができるような仕掛けを設ける（ホワイトボード&wiki が強力だ）。そうすることで、サステイナブルに問題に取り組むな体制を維持することができる。

　本書では、「油井噴出事故の調査」が相当する。

疲労が人間の判断力を鈍らせることは良く知られているが、当人が予想するよりも、はるかに鈍らせていることは、あまり知られていない。油井噴出についての世界規模での調査では、半数が真夜中過ぎの深夜、とくに夜中の2時から3時の間で起きている

　疲労と睡眠不足のため、コックピットの風防のボルトをちゃんと留めていなかった結末は、悲惨ナリ（思わず笑ってしまったが）。眠くて眠くてしょうがない状態で、書いた記憶もないようなプログラムを、「小人が書いた」という。そんな「小人が書いたプログラムのバグを見つけるのは、難しい」のは、自分がエラーを起こしていることすら気づかないから。

原則3 : トラブルの原因を探す/被害を最小限する/プロジェクト目標へ軌道を戻す目的を分ける

　できればチームも分けたいところだが、そこまで潤沢に人的資源はない。せめて「今話し合っていることは、どの『目的』を遂行するためか?」を自問自答しながら対応している。

　つまりこうだ。限られたリソースをどこへ突っ込むのかは、目の前のトラブルをどう扱うかによる。原因究明（＝二度とこんなトラブルを起こさない）のか、被害を最小限（＝他システムへ伝播している）のか、あるいは、軌道を戻す（＝初期目標の方が大事）のか、気を配っておく。「その問題は、どこに重心があるのか?」ってね。

　そうでないと、「みんな重要」になってしまう。リソースは限られているので、初期の目的が達せられなくなったり、あるいは、社会的影響にまで波及したにもかかわらず、放置されてしまったりする。バランスやね。「ぜんぶ最優先だ！」と鼻の穴をふくらませる顧客には、具体的に一つ一つ「これとこれは、どうします? こうします?」と訊くと意外と素直に答えてくれる。

　これは、「アポロ13の事故」よりもむしろ、そこからの生還プロジェクトの方から学んだ。本書よりもむしろ、「アポロ13」から。自分のblogエントリ[参照]からの引用になるが、

　　バグであれ、設計・仕様上のものであれ、重大な不具合が見つかると、「原因究明」「影響回避」、さらには顧客・上長への説明を、同一人物にまかせてはいないだろうか? 彼/彼女が「一番分かっているから」という理由で、その人に委ねては、いないだろうか? これは、わたし自身そーいう目に遭ってきたから分かる。上の3つは、互いに影響しあうため、一人にするにはムリがある

　もちろん本書でも「アポロ13の事故」は取り上げられている。ジェームズ・ラベル「アポロ13」よりも概略化されており、分かりやすい。

原則4 : 「外の目」を取り入れる

　手空きの部署から参謀役を引っ張ってきたり、逆に自分の手が空いているときに、スタンドアップミーティングに強制参加させられる。メリットは外の（冷めた）意見が聞けるから。火急の事態にてんてこまいになっている人に、これがどれだけ重要なのかは、産業事故における次の分析が証明している。

　産業事故の現場に居合わせた人々が、事故の初期段階での原因解釈にしがみつくあまり、あとからさまざまな証拠が出てきても解釈を変えない、ということがある。かれらは決心を固め、問題の解決だけを望んでいるので、相反する情報があってもそんなものに気を取られていては時間の無駄だと考える

　あるでしょ? トラブルってて目がイっちゃってる人に、「ひょっとして○○なんじゃぁ…」と話し掛けても、「ウルサイ！」と撥ね退けられて、仕方がないから自分でちょっと調べてみたら、実はそうだった―― なんてこと。あるいは、自分ではどうしても見つけられなかったバグが、他の人に見てもらうと、ひょいと発見できたり。

　最初に認知し情報をロックして、そこから固定化された発想でしか事物を捕えられなくなる。「人は見たいものを見る、見たいものしか見えない」やね。

　これも「スリーマイルアイランド」の例が典型だ。「冷却水の水位計は満タンを指しているが、温度はどんどん上がりつづけている」という状況下で警報が鳴り響く中、「冷却水はすでに空っぽになっているんじゃぁないか?（水位計が故障しているのではないか?）」ということを真っ先に疑ったのは、トラブルを聞いて駆けつけた非番のオペレータだったという。

原則5 : 現場を責めるな

　大きなトラブルに見舞われたとき、一番の被害者は現場の人だ…にもかかわらず、エラーの犯人探しをしようと躍起になるあまり、現場にいて災厄を食い止めようと奮闘するオペレータを責めてはいけない―― これは自戒も込めて。

　エラーは設計で作りこまれる。もちろん運用の時点で「手抜き」や「警報スイッチを切る」あるいは「数値を読み誤る」といった致命的な行動をとってしまうことがある。しかし、運用時の行動が致命傷のトリガーとなる場合は、非常にどころか、皆無だ。

　つまり、大惨事の最初のトリガーは、設計時点で作りこまれている。

　プログラミングを例に挙げよう。運用時に重大なエラーが発生するとき、プログラミング時点でのバグを起因とするものは、ない。原因を追求すると、設計時や検討時に織り込まれているのが常だ。単なるコーディングエラーが引き起こした虫は、テストでほぼ叩きだせる。

　にもかかわらず、重大なエラーが起きるとき、そいつを直す―― 本来そこを書いたわけでないプログラマ―― に詰めよりがちだ。どうなってるんだってね。でもって最初に作った人は、もう別プロジェクトに行っちゃってるというわけ。わたし自身、前任者のクソだらけの尻を何度も舐めさせられたことがあるので、よく分かる。自分のせいでもない不具合の釈明をさせられるのは、ものすごくストレスがかかる。

　大きな故障が発生した場合、実際にはその真因となる重大なミスはずっと以前に起きていて、本来は設計者や管理者――そうした人々が作り上げたシステムは、どこかで歯車が狂うと、現場の人に超人的な行為を要求することがある――責任だったのに、オペレータや乗組員が非難される例があまりにも多い

　この典型例は、「タイタニック号のリベット」だ。本書で初めて知ったのだが、タイタニック号が氷山に衝突して、裂け目や傷がついたわけではなく、氷山とこすれて鉄板がよじれて「すきま」ができたせいだという。

　海底で行われた調査の結果、船体には大きな裂け目や傷はついていないことが分かっている。いっぽう、リベット強度が足りないために氷山とこすれてできた「すきま」をあわせると、小型絨毯ほどの面積になる

　では、なぜそのような「すきま」ができたのかというと、こう分析している。

　タイタニック号に使用された300万本のリベット用に錬鉄を供給した会社は、当時、他の大プロジェクトを完成させるべく圧力を受けていたが、要求を満たすことができる技術をもった職人は少数しかいなかった。リベット用に出荷された鉄材は、通常の4倍のスラグを含んでおり、品質に大幅な問題を抱えていた

　確かに、タイタニック号を運転する現場のエラー（見張りの不在/通信士への仕事集中による警告の無視など）はあっただろうが、本当の原因は、事故が発生するずっと以前に作りこまれていたというわけだ。

　反対に、現場の人が超人的な能力を発揮して、事態を回避したというパターンもあるが、それは珍しいケース。たまたま事故現場の先頭にいたのが運用者だからといって、自動的に彼/彼女を責めるのはお門違いだ。あらゆる事故に共通して言えるのだが、この傾向はおかしい。感情的には理解できるが、運用者がエラーと犯したのなら、エラーを犯すような運用のさせ方、あるいはエラーを大惨事に結びつけるような連鎖を引き起こしたことこそ、問題にするべきなんだ。

　日本で起きた大事故を思い出しながら、強くそう思う。同時に自分への戒めとする。

* * *

　以上、各論おしまい。「最悪の事態を想定したリハーサルの重要性」や「逸脱の常態化が招くもの」、「ヒューリスティックスに『最悪の事態』を想定する弊害」などなど、書きたいネタは大量にある。後知恵で塗り固めた失敗事例集ではなく、一人称として取り組むならば、本書から得るものは多い。