爆笑問題という人がハインリッヒの法則というのを発見して、日本リスクコンサルタント協会から賞をもらったりしているらしい。この法則は「一つの重大事故の背景には、２９の軽傷事故があり、さらにその陰には３００のニアミス（ひやっとすること）がある」というものらしい。これ、漫才のネタとしては特に笑えないが危機管理のネタとしてはなかなか参考になる。
しかし「法則」と言ってしまった時点で、この1対29対300の比率が固定されているという印象を与えてしまうのはあまり良いことではない。これでは「この比率を変える」という改善への意志が見られないのだ。換言すれば、発生事故の比率があたかも自然界の確率であるかのように受け取られて終わってしまうのだ。まあコメディアンの考えたことだからそれ以上を望むのは難しいが、なんとかこの1対29対300を1対59対600に持っていけないか、あるいは1対9対10000に持っていけないかということを考えるきっかけとはしたいものである。（最終的にはニアミス自身が減って結局1:29:300に戻るかもしれないが、そのときは絶対数が大幅に減少しているはずだ。）マーケティングへの応用なんかは専門外だが、せめてシステム障害くらいには具体的に応用できないかと考えた。
ここで前半の1:29を見てみると、印象としては1の重大障害は29の軽微な障害の間に原因や事象についてはあまり差異が無いように見えた。結局はその障害が起こった対象システムが重要障害を引き起こす可能性があったかというだけの差だったように思える。このことについては爆笑問題も認めてくれると思う。なぜ彼らは29としたのか、30ではないのか。これは1と29が原因や事象としては差が無く、事象が起こったタイミングが悪かっただけだと言うことを示唆しているのではないか。
そして、300のニアミスはすぐ気がついたから事なきを得たが、見過ごしてしまえば少なくとも軽微な障害となっているものという印象である。さらに個人的な印象で言えばラッキーでなんとかなったというものも少なくない。逆に言うと30の障害はアンラッキーが（重なって）生じたものということもいえる。
障害発生は運の善し悪しで決まることも多いというのはあるだろうが、ならば、運が良くなくてもきちんと障害の種を見つけ、また多少運が悪くとも軽微な障害に至る前で食い止めるというのは、それは必要でしょう。できれば組織的対策をとりたいところ。よしこれでハインリッヒの法則の呪縛から脱出だ！これこそ危機管理（リスク管理でもエマージェンシー管理でもなくクライシス管理）！ともかく気勢は上がった。（あくまで自分一人だが）で、障害管理関連の本を読んだり、Webサイトを探したりしたが・・・システム障害とハインリッヒの法則は相容れないのね。確かに障害管理についての文献蓄積はバカになりませんが、それらは全て開発段階のもの。これに対してハインリッヒの法則はあくまで「事故」を対象としていますから本番運用後のものを対象とするべきでしょう。
確かに本番運用後の障害をネタにするのは難しいなあ。タブーはタブーだから、公式には発表されにくいし。日経コンピュータの「動かないコンピュータ」も実は開発段階の問題点を見ているだけだし。
でも、最近少し風潮が変わってきた。信頼性の低いパソコンやUNIXサーバーを使う場合はハード障害・ネットワーク障害は起こりうるものとして容認されているし（だから二重化とかされている。）ウィルスが本番で発生したというのはニュースに上がってくるようになったし、銀行や取引所、航空会社の本番システム障害は当たり前のように記事になるようになった。そしてMicrosoft製品は今日もどこかで止まっており、電子メールは文字化けしている。この調子で行けば今後、システム障害は起こるものという理解が広まることになるだろう。ならばハインリッヒの法則を応用して、いかにこの比率をよりよいものにかえてゆくかということが障害対策の一つの流行になるかもしれない。よし、まずは自分でやるかと決意した。障害が「ヒヤリ」で未然に防がれたのはなぜか。あるいは軽度障害で終わったのはどうしてか。これを具体的事例に基づいて集計・分析すればハインリッヒの法則に言う比率を良い方に変えることができるのではなかろうか。
いろいろと仮説は出したのだ。「再試行可能なプログラムで、１日の予備日があるから、単純な再作業でユーザーへの影響を無くせたからではないか」とか「予め処理遅延時の作業手順を作成しユーザーの承認を得ていたからではないか」とかいうふうに。または「二重化していないドライブ装置が故障したがシステム臨時作業用なのでユーザーサービスには影響ないから、軽度障害で済んだ」なんてのがあるかなと思っていたのだ。が、ハインリッヒの法則で300にあたるニアミスは一つも見つかりませんでした。今や開発と運用の分離のために「ヒヤリ」と思っても手順書通り行いますから、ニアミスで留まらないのですね。起こったときは重度軽度を問わず障害は障害になります。結構面白いネタだと思ったのですが残念です。やはり情報処理とハインリッヒの法則は相容れないらしいようですね。
ハインリッヒの法則が対象としておらず、かつ「実に言いにくい」システム障害を取り扱ったため論旨がうろうろしているが、要約すると、こういうこと。コンピュータネタ、目次へハインリッヒの法則に言う、300件のニアミスと(29+1)件の事故の間に、何らかのフィルタがあるだろうと推測した。（「運」も立派なフィルタだ。）
このフィルタに働きかければ、330の事象のうち、ニアミスで留まるものの割合が増えるだろう。そのためには今までどういうフィルタが働いてきたかを調べましょう、というのが今回の主張。
建前としてはニアミス自身も起こってはいけないのだが、コンピュータは止まるものという認識が広まれば、ニアミスが起こるのは常識とされるはずであるし、そうなれば事象をニアミスで留める方策を立てることも容認されるだろう。で、容認された場合、効果は大きそうである。
でもよく考えるとニアミスって記録されないんだよねえ。（ハンフリー博士は記録しているのだろうが、多分開発プロセスだけだろう。）それにしても、ハインリッヒさんはどうやってニアミスを300件とカウントしたのだろう。