最悪の事故が起こるまで人は何をしていたのか飛行船墜落や原発事故、ビル倒壊など50あまりの事例を紹介。誰がどのように引き起こしたか、食い止めたか、人的要因とメカニズムをドキュメンタリータッチで描く。大惨事を引き起こした事故の「情報」だけなら、失敗知識データベース[参照]を見ればよい。本書とほぼ同じネタは得られる。著者が現場を見、生き残った関係者にインタビューしてたどり着いた「知見」や「生きた教訓」は、本書から掘り起こすべし。「なぜAT車のアクセルとブレーキの踏み間違いが起きるのか?」あるいは「飛行機事故から生還するため、乗ったら最初に確認すること」は、立ち読みでもいいので押さえておこう(後者は目からウロコだった)。システム開発屋であるわたしの場合とは、比較しようがない。わたしが携わるシステムが止まっても、新聞には載るだろうが人死が出るわけでもない。それでも、わたしが出くわしたエラーと、本書で紹介されるエラーは、驚くほどよく似ている。わたしが打っている対策と、著者が推奨する対策も、やっぱり似ているのだ。あったりまえじゃん、という人は、以降および本書を読まなくても無問題。自分の問題として本書と向き合うと、得られるものはかなりある。事故事例として読むつもりなら、前出の「失敗知識データベース」だけでOK。以下、ヒューマンエラーについて、教訓から導き出された原則と、関連する本書のトピックをまとめる。そのエッセンスだけ列挙すると、こうなる。現場を責めるな!本書は橋本大也さん紹介[参照]で知る。書いているうちにどえらく長くなってしまった。本書のレビューは橋本さんのエントリの方がまとまっているので、書評を求めているならそちらをどうぞ。情報を集める場所と、判断する場所を、物理的に分けるトラブル対応からカットオーバーまで使える。物理的に部屋を分ける(WAR-ROOM)場合や、情報屋(新人が適任)をアサインすることで、情報を得るときに発生するノイズをキャンセルし、ノイズが判断に与える影響を低減できる。卑近に言えば、「客が耳元でぎゃんぎゃん文句言っている時に、冷静にバグ改修の見通しや、対処時期や、汚染領域の回復の検討なんてできねぇだろ?」となる。それを別の人が読んで分析・判断をするわけ。書く人・聞き取る人と、読んで判断する人を同一人物にしてはならない「スリーマイルアイランド原子力発電所の事故」がこれに対応する。著者によると、原発の制御室には、深刻な問題があったらしい。原子炉がどんどん高温になっているにもかかわらず、冷却水を削減する判断をした運転員たちを批判することは可能だが、そのコンソールを設計したわけではないことも指摘しなければならない。実質的な対策は講じられることなく、放置されていたのだが。主警報装置のアラームが複数鳴り響き、100以上の警告ランプが「警告」を報じる中で、冷静に事態を把握させようとすることは、不可能だろう。最初に考えるあたりまえの話なんだが、たいていの「重大な問題」は、すぐに直るはずがない。直す箇所を調べるのにも時間がかかるし、直すのにも時間がかかるし、直ったかどうか検査するのにも時間がかかるし、二次リスクが起きていないか調べるのにも、さらに時間がかかる。おまけに、重大な問題が引き起こす影響を収束させる(データ汚染が顕著)のにも、莫大な時間がかかる。それにもかかわらず、たいていの重大な問題は、「とりあえず」「全員で」とりかかる。小学生のサッカーのように、ボール(見えている不具合)の周りに全員が必死に群がっている。限界を超えた努力を強いることになる。それも、トリビアルなエラーを。することで、サステイナブルに問題に取り組むな体制を維持することができる。本書では、「油井噴出事故の調査」が相当する。疲労が人間の判断力を鈍らせることは良く知られているが、当人が予想するよりも、はるかに鈍らせていることは、あまり知られていない。油井噴出についての世界規模での調査では、半数が真夜中過ぎの深夜、とくに夜中の2時から3時の間で起きている疲労と睡眠不足のため、コックピットの風防のボルトをちゃんと留めていなかった結末は、悲惨ナリ(思わず笑ってしまったが)。眠くて眠くてしょうがない状態で、書いた記憶もないようなプログラムを、「小人が書いた」という。そんな「小人が書いたプログラムのバグを見つけるのは、難しい」のは、自分がエラーを起こしていることすら気づかないから。トラブルの原因を探す/被害を最小限する/プロジェクト目標へ軌道を戻す目的を分けるできればチームも分けたいところだが、そこまで潤沢に人的資源はない。「今話し合っていることは、どの『目的』を遂行するためか?」を自問自答しながら対応している。限られたリソースをどこへ突っ込むのかは、目の前のトラブルをどう扱うかによる。原因究明(=二度とこんなトラブルを起こさない)のか、被害を最小限(=他システムへ伝播している)のか、あるいは、軌道を戻す(=初期目標の方が大事)のか、気を配っておく。「その問題は、どこに重心があるのか?」ってね。ないと、「みんな重要」になってしまう。リソースは限られているので、初期の目的が達せられなくなったり、あるいは、社会的影響にまで波及したにもかかわらず、放置されてしまったりする。します?」と訊くと意外と素直に答えてくれる。これは、「アポロ13の事故」よりもむしろ、そこからの生還プロジェクトの方から学んだ。本書よりもむしろ、「アポロ13」から。これは、わたし自身そーいう目に遭ってきたから分かる。上の3つは、互いに影響しあうため、一人にするにはムリがあるもちろん本書でも「アポロ13の事故」は取り上げられている。ジェームズ・ラベル「アポロ13」よりも概略化されており、分かりやすい。「外の目」を取り入れる手空きの部署から参謀役を引っ張ってきたり、逆に自分の手が空いているときに、スタンドアップミーティングに強制参加させられる。メリットは外の(冷めた)意見が聞けるから。火急の事態にてんてこまいになっている人に、これがどれだけ重要なのかは、産業事故における次の分析が証明している。産業事故の現場に居合わせた人々が、事故の初期段階での原因解釈にしがみつくあまり、あとからさまざまな証拠が出てきても解釈を変えない、ということがある。自分ではどうしても見つけられなかったバグが、他の人に見てもらうと、ひょいと発見できたり。最初に認知し情報をロックして、そこから固定化された発想でしか事物を捕えられなくなる。「人は見たいものを見る、見たいものしか見えない」やね。これも「スリーマイルアイランド」の例が典型だ。「冷却水の水位計は満タンを指しているが、温度はどんどん上がりつづけている」という状況下で警報が鳴り響く中、「冷却水はすでに空っぽになっているんじゃぁないか?(水位計が故障しているのではないか?)」ということを真っ先に疑ったのは、トラブルを聞いて駆けつけた非番のオペレータだったという。エラーは設計で作りこまれる。運用の時点で「手抜き」や「警報スイッチを切る」あるいは「数値を読み誤る」といった致命的な行動をとってしまうことがある。運用時の行動が致命傷のトリガーとなる場合は、非常にどころか、皆無だ。大惨事の最初のトリガーは、設計時点で作りこまれている。プログラミングを例に挙げよう。運用時に重大なエラーが発生するとき、プログラミング時点でのバグを起因とするものは、ない。原因を追求すると、設計時や検討時に織り込まれているのが常だ。単なるコーディングエラーが引き起こした虫は、テストでほぼ叩きだせる。