失敗学の畑村洋太郎の弟子である中尾政之さんの書いた「失敗は予測できる」（光文社新書）を読む。この予測できるというのは、失敗をモデル化、パターン化できることを意味している。

この中尾さんという人は、元日立金属に勤めていたひとでその後東大教授になった。だから、大学の研究室にとじこもっていたわけではないので非常に実践的である。ぼくも、工場勤務が長かったので書いてあることがものすごくよく分かる。

ぼくのいた工場でも、事故やトラブルがあり、そうしたとき分析もし、今後の対策を考えることが大変重要なことになる。だからこの本にも書いてあるように“ヒヤリハット”事例を集めてそれを小冊子にして配るというふうなこともやったし、日常のミーティングでKYといって危険予知活動もやった。だから、そうだそうだとうなずきながら読んだのである。

こうした、学問こそこれからどんどん出てきて欲しい。それこそ産学協同というのはこういうことなのである。

筆者は機械のエンジニアに関する事故や事件を２００例近く集めて分析した結果、４１の失敗のパターンに分類できるという。

ここでいちいち取り上げるわけにはいかないが、ぼくの経験から言えるのは人間とか組織とかいったものが要因となるケース、すなわちコミュニケーション不足によって引き起こされる失敗が多いような気がしている。そうしたら、この本でもそこについて５つの失敗シナリオが提示されていた。

１．「誰かがやると思っていた」（他人依存）（同意体質）
２．「自分はその道のプロだと過信していた」（自信過剰）（ワンマン）
３．「現状がわからず遠隔操作していた」（情報遅延）（誤判断）
４．「伝えなければならない人が多かった」（齟齬多発）
５．「効率的に仕事をしたつもりが干渉していた」（干渉発生）

これって、機械のエンジニアのことだけではないと思いませんか。システム開発の現場でもよくある話であるような気がします。そして、このような失敗は仲間内のようなフラットな小組織で、顔をつき合わせてやるような仕事環境では起こらないという。確かに大きな組織になればなるほどありえる話です。

そのソフトウエアの仕事でいうと、金額3億円以下の仕事では納期遅れがないという話も紹介されている。さらに、組織を管理できる範囲について、いくら優秀なトップエンジニアでも、ソフトウエアや研究開発の分野だと20人、機械のメーカーだと200人のグループまでだそうです。

こうしてみると、システム開発が大規模ウオーターフォール型開発から少人数によるアジャイル開発への流れていくのは、失敗学からいっても必然なのでしょう。

さて、この本でも失敗を分析できれば、それを予測できるということを示したが、それ以上に大事なこととして、失敗を回避すること、その失敗を生かして逆転することをあげている。PDCAサイクルではないが、分析―予測―回避―改善というサイクルを定常的にまわすということが重要なのだろう。

ただし、最大の問題は失敗は予測できてもそれを回避するとき人間の心理的要素が入り込むということである。昔、ありえないようなオペミスをした人になぜ失敗を繰り返したかと聞いてみると、家庭がうまくいっていなくてその日も夫婦喧嘩をして出社したということがあった。

これはどうしようもないことかもしれないが、「ああすれば、こうなる」式だけではいかないケースがあることを頭に入れておくことも必要なのだ。

この本は、ITに関わるエンジニアの人にとっても非常にためになるのでぜひ読んでもらいたい一冊です。