システム構築に携わった過去を思い浮かべると、何度と無く危ない橋を綱渡りしてきた事に気づかされます。

例えば、ある生産管理システムのマスタ運用を行っていたときは、スクリプトを作成して、特定文字から始まる一時テーブルを削除しようとしたのですが、文字設定を誤って全マスタを削除しかけた事がありました。

他にも、ECサイトのユーザ告知メールの設定ミスで、あやうく全ユーザに10通ずつまったく同じメールを送りかけたりと、あと少しでユーザからクレームの嵐を巻き起こしてしまうところだった、という経験もしました。

こうした出来事を、一般に「ヒヤリハット」と表現しますね。gooの国語辞典に書かれた説明を読むと、

（説明）

直前・直後に回避したミスや，幸い被害が小さかったミスなどをさす。

医療・建築の現場など，生命上の安全性が求められる分野で多く使われる。「―事例」「―報告」

＜ヒヤリとしたり，ハットしたりすることから＞

このように書かれると、主に製造業や医療の現場を想起しますが、システムが社会に浸透するにつれて、「社会的な安全性」も重視されるようになり、IT業界においても、先に述べた事例のようなヒヤリハットの事例が増えてきたように思えます。

ところで、ヒヤリハットについて、米国のハインリッヒという人物は、労働災害の事例を統計分析し、このような法則を発表しているのをご存知でしょうか？

（ハインリッヒの法則）

重大災害が1件発生したとすると、それまでに軽傷の事故が29件、そして無傷災害は300件は発生している。

これをかつてのジェイコム株誤発注問題に照らし合わせてみると、次のようになることでしょう。

・重大事件：1件　 誤発注により株価全体に影響があった

→社会全体が知っている

・軽度事件：29件　誤発注してしまったが株価には影響がなく会社内部で揉み消した→当該会社と入力担当者のみ知っている

・無傷事件：300件 入力ミスにより警告が表示された。

→入力担当者のみ知っている

※ジェイコム事件はこちらを参照

http://itpro.nikkeibp.co.jp/article/COLUMN/20051227/226805/

よく言う「氷山の一角」という表現がありますが、まさに重大事件の裏には見えてこない膨大な件数のミスが存在するということです。

システム構築の現場ではこの理論を応用し、重大なバグと軽度のバグの比率を見てバグの潜在可能性を探ることもでき、障害管理におけるサービスレベルの定義にも使えるので、覚えておいて損は無い法則ですよ。

ちなみに、コールセンターのクレーム管理ではすでに一般的な手法としてハインリッヒの法則が取り入れられています。

1件のクレームの裏側で300件以上の物言わぬ不満ユーザがいる事を想定する作りになっているようで、コールセンターシステムの構築に携わった方の中には、ハインリッヒの法則を取り入れてコーディングした経験を持っている方もいるやもしれませんね。

著者紹介

吉澤準特 (ヨシザワジュントク)

外資系コンサルティング会社に勤務。守秘義務を破らない範囲でIT業界の裏話をつぶやきます。ファシリテーション、ビジネスフレームワーク、人材教育など執筆多数。日本能率協会、秀和システムそれぞれから書籍刊行。執筆依頼/インタビューお引き受けします。こっそりITIL Manager (v2)資格保有。

筆者ブログ「IT業界の裏話」

Twitterやってます

この記事は吉澤準特氏のブログ「IT業界の裏話」の過去記事を抜粋し適宜加筆・修正を行って転載しています。