PM アラカルト No.7 ハインリッヒの法則 2006.3.1 KT 今回は少し毛色の変わったトピックです。やや古い話で恐縮ですが、昨年 12 月 13 日の日本経済新聞の社説に某企業の事故についての記述があり、その中でハインリッヒの法則というものが引き合いに出されていました。当 PM アラカルトの筆者は、昔あるプロジェクトに参画していたときに、当時のプロジェクト・マネジャーからこの法則のことを教えてもらったことがあり、システム開発プロジェクトにもあてはまる法則だなあ、と感じたものです。今回はこのハインリッヒの法則を紹介し、合せてリスク・マネジメントとの関連についても言及します。ハインリッヒの法則は、米国のハインリッヒ氏が労働災害の発生確率の分析結果に基づいて提唱した法則で、別名を「１：２９：３００の法則」とも呼ばれており、保険会社などで利用されているようです。ハインリッヒの法則とは、「１件の重大事故の背後には２９件の小さな事故があり、さらにその背後には事故までには至らないが３００件のヒヤリとしたことがある」というものですが、これはビジネスにおける失敗発生の度合いを比喩したものとしても使えそうです。例えば、「１件のビジネスの大失敗の背後には２９件の顧客からの苦情などで明らかになった小さな失敗があり、さらにその背後には、特に苦情はなかったけれども３００件の担当者がヒヤリと思った経験がある」というように。この３００件の「ヒヤリ」とは、特に問題が表面化していないために見過ごされている、いわゆる潜在的失敗または将来顕在化するかもしれない失敗の「兆候」です。つまり、顕在化した失敗の背後には、実にその１０倍もの失敗の兆候があったということを象徴しています。また、２９件の小さな失敗も大失敗の兆候と言えます。例えて言えば、海に浮かぶ巨大な氷塊の、氷山として見える部分が顕在化した失敗であり、海面下で見えない大きな部分が失敗の兆候というイメージです。氷山 1 29 300 重大な失敗（顕在化）軽微な失敗（顕在化）ヒヤリとしたこと（潜在的）氷塊 Copyright© 2006 Technosurge Co.,Ltd. All Rights Reserved このハインリッヒの法則をプロジェクトに当てはめてみましょう。プロジェクトの推進中に重大な問題が発生してしまった場合、実はそれ以前にこの問題に関連した多くの小さな問題が起こっていた、更には、担当者が確信を持てず何となく不安を感じていたより多くのことがあった、ということがあります。後から思い起こすと、この多くの小さな問題や不安は、ある大問題の発生の兆候であって、その時どきでそれらを適切に処置しておけば、あるいは大問題の発生は防げたか、もしくは発生したとしてもその影響を限定的なものにできたのかもしれないのです。この「兆候」は、リスク・マネジメントでは大切なものです。プロジェクトの実行中に予期していた兆候が出現すると、それによって関連する大きなリスクが顕在化する可能性が高くなるため、直ちに計画してあった対応策を実行して、大きなリスクの顕在化を防止する、または顕在化してもその影響を最小限にとどめることができるようになります。例として、「納期が達成できないかもしれない」というリスクがある場合、その兆候にはどのようなものがあるでしょうか？色々考えられますが、例えば、「機能仕様書の確定化が遅れてしまった」という事象は兆候の一つでしょう。では今度は、「機能仕様書の確定化が遅れるかもしれない」ということをリスクとした場合、その兆候にはどのようなものがあるでしょうか？例えば、「お客様側の仕様策定責任者が他の仕事と兼務で忙しすぎ、仕様詰めの打合せが予定通りにできない」ということが兆候として考えられるかもしれません。ではそれが起ったときの対策は、というようにリスクとその兆候をさかのぼって追求すると、より具体的なリスク対応をより早い段階でとることができます。このように、プロジェクトの計画段階におけるリスク・マネジメントでは、リスクを識別して定性的／定量的分析をし、その評価結果に基づいて優先度付けをして対応策を立てますが、リスクの識別と合せてそれに関連する兆候も識別しておくことが大切です。＜end＞ Copyright© 2006 Technosurge Co.,Ltd. All Rights Reserved