失敗で得た教訓をどう活用するか
本日2007年5月19日の日本経済新聞夕刊で
「原発事故などの組織的教訓 保安院データベース化」
という記事を読みました。(今のところNIKKEI NETにも掲載あり)
1990年代以降に原子力発電所や鉄道で起きた
約900の事故や不祥事について、組織としての教訓を
データベース化してインターネットで公開するとのことです。
事故といえば、「ハインリッヒの法則」という有名な法則があります。
重大な事故が1件あったら、
その背後には29件の軽い事故が起こり、
300件の「ヒヤリ・ハット」事例（もうちょっとで事故）がある。
というものです。
現場の人がヒヤリ・ハット事例を逐一報告しても、
上が握りつぶしてしまったら意味がありません。
事故を防ぐためには、重大な事故につながり得る情報（＝予兆）を
組織的に集約し、分析する必要があります。
現場の1人が「ヒヤリ・ハット」したということは、本人や上司にとっては
「たまたま運が悪かった」くらいのことに感じるかもしれません。
しかし同様に他の何人もが「ヒヤリ・ハット」を体験したという情報が
上層部に集約されていれば、何か重大な事故が起きる予兆なのでは？
という疑問に至る可能性が高まります。
事故が絶対に発生しない物やシステムはあり得ません。
事故の予兆を捉え、発生する前に回避しようとする組織体制を作るには、
過去の事故の情報というのは貴重な参考資料となり得るでしょう。
その素材として失敗知識データベースは大変参考になります。
こちらは独立行政法人科学技術振興機構が作ったものです。
国内外からたくさんの失敗事例を集め、どのようなシナリオで
失敗に至ったか、ということが大変詳しくまとまっています。
以下は失敗DB内の有名な事故へのリンクです。
組織を運営する側の人は、事故の兆候を掴んで回避することが仕事です。
しかしエンジニアと名の付く職業についてしまった人は、
（システムエンジニアも含めて）日頃からこのような事例を研究し、
他山の石とする必要があります。
例えば先日のジェットコースター脱線事故では、
車軸が金属疲労を起こしたことが原因と報じられていました。
ジェットコースター業界には自動車の車検のような
法定点検の制度がないため、メーカが自主規制をして
車軸の耐用年数を決めていたそうです。
しかし今回の事故ではそれが守られていませんでした。
三菱自動車のリコール隠しが発覚した時は、
設計ミスによる強度不足の部品が破損することにより
たくさんの被害が出ました。この事件が起きた時に
「うちの会社は大丈夫かな？」と思って点検を強化するなどの
対策を実施していれば、結果は違ったものになったかもしれません。
成功事例は業界の垣根を越えてよく宣伝される傾向にあります。
そのため、意図的に情報交換の場を設けなくても伝わりやすいです。
しかし失敗情報はなかなか広く伝わっていくことが少ないです。
（日経ビジネスの『敗軍の将、兵を語る』はおもしろい企画ですね）
インターネットによる情報共有は大変効力があると思います。
JSTの失敗知識データベースや、保安院が整備する予定の
教訓データベースにより、失敗情報の交換が促進され、
世の中から事故が減ることを期待しています。
そう言われてみると、何年も前から情報処理技術者試験の高度区分の
午後問題では「G君は設計書を作成したが、H課長に誤りを指摘された」
という形式の問題が必ずと言っていいほど出題されます。
出題者の方々は「失敗に学ぶ事こそ成功への近道」というポリシーを
既にお持ちなのでしょう。