本日2007年5月19日の日本経済新聞夕刊で
「原発事故などの組織的教訓　保安院データベース化」
という記事を読みました。(今のところNIKKEI NETにも掲載あり)

1990年代以降に原子力発電所や鉄道で起きた
約900の事故や不祥事について、組織としての教訓を
データベース化してインターネットで公開するとのことです。

事故といえば、「ハインリッヒの法則」という有名な法則があります。

重大な事故が1件あったら、
その背後には29件の軽い事故が起こり、
300件の「ヒヤリ・ハット」事例（もうちょっとで事故）がある。

というものです。

現場の人がヒヤリ・ハット事例を逐一報告しても、
上が握りつぶしてしまったら意味がありません。
事故を防ぐためには、重大な事故につながり得る情報（＝予兆）を
組織的に集約し、分析する必要があります。

現場の1人が「ヒヤリ・ハット」したということは、本人や上司にとっては
「たまたま運が悪かった」くらいのことに感じるかもしれません。

しかし同様に他の何人もが「ヒヤリ・ハット」を体験したという情報が
上層部に集約されていれば、何か重大な事故が起きる予兆なのでは？
という疑問に至る可能性が高まります。

事故が絶対に発生しない物やシステムはあり得ません。
事故の予兆を捉え、発生する前に回避しようとする組織体制を作るには、
過去の事故の情報というのは貴重な参考資料となり得るでしょう。

その素材として失敗知識データベースは大変参考になります。

こちらは独立行政法人科学技術振興機構が作ったものです。
国内外からたくさんの失敗事例を集め、どのようなシナリオで
失敗に至ったか、ということが大変詳しくまとまっています。
以下は失敗DB内の有名な事故へのリンクです。

• タイタニック号沈没事故
• 御巣鷹山の日航ジャンボ機の墜落
• JCOウラン加工工場での臨界事故

組織を運営する側の人は、事故の兆候を掴んで回避することが仕事です。
しかしエンジニアと名の付く職業についてしまった人は、
（システムエンジニアも含めて）日頃からこのような事例を研究し、
他山の石とする必要があります。

例えば先日のジェットコースター脱線事故では、
車軸が金属疲労を起こしたことが原因と報じられていました。

ジェットコースター業界には自動車の車検のような
法定点検の制度がないため、メーカが自主規制をして
車軸の耐用年数を決めていたそうです。
しかし今回の事故ではそれが守られていませんでした。

三菱自動車のリコール隠しが発覚した時は、
設計ミスによる強度不足の部品が破損することにより
たくさんの被害が出ました。この事件が起きた時に
「うちの会社は大丈夫かな？」と思って点検を強化するなどの
対策を実施していれば、結果は違ったものになったかもしれません。

成功事例は業界の垣根を越えてよく宣伝される傾向にあります。
そのため、意図的に情報交換の場を設けなくても伝わりやすいです。
しかし失敗情報はなかなか広く伝わっていくことが少ないです。
（日経ビジネスの『敗軍の将、兵を語る』はおもしろい企画ですね）

インターネットによる情報共有は大変効力があると思います。
JSTの失敗知識データベースや、保安院が整備する予定の
教訓データベースにより、失敗情報の交換が促進され、
世の中から事故が減ることを期待しています。

そう言われてみると、何年も前から情報処理技術者試験の高度区分の
午後問題では「G君は設計書を作成したが、H課長に誤りを指摘された」
という形式の問題が必ずと言っていいほど出題されます。

出題者の方々は「失敗に学ぶ事こそ成功への近道」というポリシーを
既にお持ちなのでしょう。