ハインリッヒの法則（1:29:300の法則）

今までにも何度も書いたことだが、私は会社のスタッフにこの話を良くする。参考になればと思って書くことにします。

皆さんは、Things that can go wrong will go wrong.「失敗する余地があるなら、失敗する」というマーフィーの法則はよく聞かれると思いますが、それ以外にハインリッヒの法則というのがあるのです。マーフィーの法則がどちらかというと自然の摂理のようなものなのに関して、ハインリッヒの法則はもっと実用的なことなのです。

この法則を簡単に説明すると、取り返しがつかない１つの大事故が発生するには、29回の小さな事故がすでに発生している。その小さな事故が29回の前には300回のハッと思うようなことが発生しているというものです。これを理解して、小さな事故、ハッとするようなことを明確に連絡を受けて対応することで大事故は防げるというものです。

ソフトウェア開発で言うと、小さな簡単に直せるバグが何度もリリース前のテスト段階で発生している場合、リリースしたソフトウェアにはその約1/10のバグが残っている。そしてそれが続くと救いようのない事故（致命的なバグ）が発生するというものです。これをテストやバグを直すことで対応していたとしたらこの法則の確率から抜け出すことはできません。致命的なバグ、リリース後のバグの発生を少なくするためには、開発（場合によっては設計）のプロセスや人材、ツールから見直すことが必要なのだと私は言っています。

ハインリッヒの法則は私にとって大切な「注意書き」リマインダーなのです。

スポーツでは1/13の法則があります。一人の大怪我（死亡も含む）の発生には13回のヒヤリがあるとの事。ヒヤリには個人差があると思いまうすが、似たような法則ですね。