失敗というのをまじめに考えていくと、どうしてもついつい自暴自棄になりがちになります。
ただ、その失敗をうまく乗り越えていくことができれば、それが大きな成果につながっていくわけで。。。
個人的には、失敗事例を踏まえつつ、同じ轍を踏まないように対策をうっていくのがいいのかなと思ってますが、そこには人の問題も入ってくるのでなかなか難しいなというのが印象です。
ただ、この本を読んでいるとなるほどなと思うところも多々。
事前に過去の失敗知識を調査して、再発防止策を練っておけば事故が防げそうだったのに、実はやってなかった、という事例が大半を占めることが理解できよう。
つまり、やっちゃったなーとか言っているとき、その対策に追われて対策が終わった後にああ、やれやれという感じで喉元過ぎれば熱さを忘れるのような感じになると、結局は再度失敗をするという可能性が高いということ。
結構スペシャルケースでの対策を打つことがあったとしても、本当の原因は何なんだろうと徹底的に考えていけばいいんだろうなとも。
ただ、ここ最近は短時間で物事を考える必要があるので、なかなかそういうのができないところがあるんですよね。。。そこが悩ましい。
さて、失敗は主にこの5つに分類されるそうです。
①コミュニケーション不足
②安全装置の解除
③企画変更の不作為
④倫理問題
⑤企画不良
①は重たいですね。コミュニケーションはとっているつもりでも、とっていない可能性もあるわけで。
そう思うと、どうコミュニケーションを確保するかが肝となるわけで。となると、仕組みでカバーしていくのがいいのかもしれませんねぇ。
失敗の原因は主に3つ。
失敗の原因は、
①人間的な原因(いわゆるヒューマンエラー)
②エンジニア個人の設計能力不足
③エンジニア個人が所属する組織の問題
という三つに大別することができる。つまり、(事故の原因)=(技術的②の原因)+(日技術的な人間的①+組織的③の原因)が成り立つ。
ついつい①と②は混同しがちになるので注意が必要かなとも思います。
そして、③の組織の失敗パターンは次の5つ。
①「誰かがやると思っていた」(他人依存)(同意体質)
②「自分はその道のプロと過信していた」(自信過剰)(ワンマン)
③「現状が分からずに遠隔操作していた」(情報遅延)
④「伝えなければならない人が多かった」(齟齬多発)
⑤「効率的に仕事したつもりが干渉していた」(干渉発生)
やっぱりコミュニケーションだよなと。
①、③、⑤はおもいっきりそれだし。やはり、コミュニケーションをきちんととるというのが無駄をなくすとともに、失敗を防ぐ貴重なツールなんだなと思う。
やはり、コミュニケーションは仕組みで担保がいいのかなぁ。。。
最後に、失敗事例を集めてみてもいいのかも。
組織の失敗も、失敗例を集めてみるといくつかのシナリオに集約することができ、技術的な失敗と同じように、次に起こるであろう失敗を予測できる。
こういうのって大事だよなと思う。
失敗があるからこそ、慎重にしつつも、新しいことを生み出すきっかけになるわけですから。そう思うと、そのあとの発想をどうやっていくかが大事なんだろうな。。。