どうもこたにんです。
ハインリッヒの法則というものをご存知でしょうか。
ハインリッヒの法則（ハインリッヒのほうそく、Heinrich's law）は、労働災害における経験則の一つである。1つの重大事故の背後には29の軽微な事故があり、その背景には300の異常が存在するというもの。
業界用語でいうところの「ヒヤリハット」を定量的な指標としたものです。
- 1件の重大な事故
- 29件の軽微な事故
- 300件のヒヤリハット
これらの比率に従ってインシデントは発生するんだよ、という経験則。
顕在される1件のインシデントは、300件以上の兆候から成り立つということ。
そりゃもちろん例外的に、突然インシデントが起こるケースもあるでしょう。
しかしそれらにもきっと、紐付きうるヒヤリハット、防ぎうる方法はあったのでしょう。
この法則には、以下分析があります。
この2つの分析はかなり興味深いところです。
何かしらのインシデントの真因は予防可能である、発生ベースではなくせるということ。
また、そのうちほとんどが人的要因にあたるということ。
そしてそこから、以下2つの教訓的対策が提唱されています。
- 教訓1 災害を防げば傷害はなくなる
- 教訓2 不安全行動と不安全状態をなくせば、災害も傷害もなくなる
そもそも1件のインシデント発生前のステップを潰せば、災害は発生しなくなる。
ドミノ理論の考え方ですね。
また、人的要因（不安全行動）をなくすことで根本が潰せるということ。
機械的不安全は、突然の停電とかハードウェア故障とかですかね。
それらは冗長構成を組む、UPS付けておく、イレブンナインなクラウドサービスを使う。
そういったことで予防可能でしょう。
人的不安全は、現場環境の整備・フローの徹底でカバーできることかもしれません。
働き方に不満があればそれを吸い上げる組織体制をつくる。
健康環境が悪いのであればそこを見直すとか。
ことエンジニアにおいて、この数値は無視できない考え方です。
- テストフェーズでいかに小さい事象でも対策を講じて母数を減らす
- お客様や先方のクレームは塵積、1件のご指摘があれば330件あると考える
いかにピラミッドの底を狭めて、たった1件のインシデントの発生を0にするか。
プログラミングでもエンジニアリングでも、そこへの予防アクションはたくさんある。
静的・動的解析ツールの導入、継続的インテグレーション、継続的デリバリー。
解決するための、予防するためのソリューションはいくらでもありそうです。
「バグたった1つです」「このクレームたった1人でしょ」はこの理論的には通用しない。
統計的にも、経験則的にも、この数字って肌感間違ってないように聞こえます。
先に起こるたった1件のインシデントに対して、数値ベースで意識付けておくことが大事。
そしてそれを機械的に解決するアプローチが必要だと思った。
リスクとそれに対するコストのトレードオフではありますが、判断材料として使う。
ライトな記事にまとめました、ハインリッヒの法則でした。
