失敗の特徴

これから仕事で失敗プロジェクトの分析に関わることになりそうです。

前回の記事でも紹介しましたが、失敗学をソフト開発に活かす事に興味があり、以前本を読んだことがありました。
そこで、この失敗プロジェクトの分析に失敗学が役立てられるのではと思っています。

この機会に失敗学の本をもう一度読み直しましたが、いくつか失敗の特徴で気になった点があったので、紹介したいと思います。


■失敗の特徴
①失敗は確立現象
いわゆる、ハインリッヒの法則のことで、大規模、中規模、小規模な事故の割合が、「１：２９：３３０」というものです。
これはソフトウェア開発にもかなり当てはまると思います。
プログラムのバグや、プロジェクトの問題を、小さなうちに類似見直しを含めた十分な対策をとらないと大きな問題につながります。

②失敗情報はうまく生かされない
１つのプロジェクト内、あるいは部署内でも同じような失敗をしている人が多くいます。
しかし、この失敗情報が他の人にまったく活かされないことがよくあります。
これはソフト開発の現場でも何度も経験したことがあります。
これは情報交換が不十分という問題もありますが、失敗情報の伝え方には工夫がいるという特徴に影響されているようです。

③よくある失敗
(1)同じ失敗が繰り返される
　②の話と関係しますが、構造化された組織では失敗情報が伝わらない傾向にあります。
　これは全体を見る人がいないことや、横のつながりが無いことが原因です。
(2)隠れたリンクに気づかない
　組織・仕事・プログラムなど、対象が複雑化し、関係する人が増えるほど、目に見えないつながりが増えていきます。
　ある１つの変更が、思いもよらない別の個所に影響し失敗を招きます。
(3)途中変更による失敗
　前提条件が変わっても、その影響範囲を全体に反映しきれないことによって起こる問題です。
　また、変更されてことで今までうまくいっていたことがうまくいかなくなる事を見通し対策をとらないと失敗の原因になります。
(4)手配・連絡漏れによる失敗
　影響範囲の見誤り、途中で担当が変わることによる連絡漏れ、手配・連絡順を間違えたことによる漏れなど、仕事でよくあるパターンの失敗です。
　また、退職によって熟練者の暗黙知が失われることも大きな失敗を引き起こします。