階段で足を滑らせたけれど、手すりにつかまって転ばずに済んだ。『何も起きなくてよかった』で終わらせるか、『なぜ滑ったのか』を確かめるか。その違いを考えるきっかけになるのが、ハインリッヒの法則です。
ハインリッヒの法則の意味
ハインリッヒの法則は、重大な事故の背景に、より多くの軽い事故や、けがに至らなかった出来事があるという考え方です。米国の安全管理の研究者ハーバート・ハインリッヒに由来し、『1：29：300』という比率で知られています。
| 区分 | よく紹介される比率 |
|---|---|
| 重大な事故 | 1 |
| 軽い事故 | 29 |
| けがに至らなかった事故・ヒヤリハット | 300 |
大きな事故だけを調べるより、結果が軽かった出来事にも目を向けようという発想です。『ヒヤリハット』は、ヒヤリとした、ハッとしたけれど、今回は大きな被害にならなかった場面を指します。
300回の次に、必ず重大事故が起きる？
1：29：300は、どんな現場でも固定で成り立つカウントダウンではありません。事故の種類、作業の条件、報告の仕方によって比率は変わります。『まだ300件に達していないから安全』とも、『軽い事故を減らせば重大事故も自動的になくなる』とも言えません。
NIOSHの研究者による解説では、鉱山の軽い事故が将来の死亡事故を予測する手掛かりになる一方、事故の重さをどう分類するかで、安全三角形としての関係が変わることを示しています。
数の多さだけでなく、『もし少し条件が違ったら、どんな被害になったか』を見ることも必要です。たった一件でも、重大な危険につながる仕組みが見つかれば、優先して対応する理由になります。
ヒヤリハットを改善に変える記録
階段で滑った例なら、『気をつける』だけで終わらせず、場所、時間、床の状態、荷物の持ち方などを具体的に残します。雨水で濡れていたなら、水を取り除く方法や、濡れた状態に気づける表示も考えられます。
- 何が起きたか：結果と推測を分け、事実を短く書く。
- なぜ被害が小さく済んだか：手すりや確認手順が働いたのか、偶然だったのかを見る。
- 何を変えるか：担当、期限、確かめ方まで決める。
報告した人を責める仕組みでは、情報が集まりにくくなります。報告件数が増えたときも、『危険が増えた』のか、『今まで見えなかった出来事が共有され始めた』のかを分けて考えましょう。
アプリ開発にも生かせる発想
例えば、テスト中に一度だけ保存が失敗したとします。再起動したら直ったとしても、直前の操作、通信状態、端末、エラー表示を残しておくと、同じ問題を追いやすくなります。
ここでアプリの不具合が1：29：300になるという話ではありません。小さな異常を、原因を探る手掛かりとして生かすという応用です。何十回も起きる表示のずれと、一度だけ起きたデータ消失では、頻度だけで優先順位を決められません。
ハインリッヒの法則の使いどころは、数字を暗記することより、『今回は無事だった』から次の改善を始めることです。思い込みで都合のよい情報だけを見ないために、確証バイアスも併せて考えてみてください。