障害をふせぐために考えること

問題が起きてから騒ぐ奴らがいる、これが一番ガキというか、起きてから騒ぐのなら子供でもできるんだよ。
騒ぐだけで問題解決に向けた取り組みができないようでは、とても戦力として期待はできない。
正直に言うと、自分のプロジェクトにそんな奴らは要らない。


大切なのは、事前予測で、想定どおりの障害が起きれば想定してた対処が取れる、ということになる。
というわけで「SEの質とはどれだけお客さんのために事前予測ができるか」に掛かっているんじゃないか、
と、ここ何年か思っている。
で、たまたま、他業務で空いたプログラマさんと、仕事を、という話になったときに思ったんだが
たとえば、典型的なJavaとかだと

try{

  // A:もともとの目的の処理

}catch(SQLException e){

  // B:目的の処理で失敗した場合の対処

}finally{

  // C:絶対にやらないといけない処理

}

という感じになっていて、Aの部分はやりたい事を素直に言うだけなので、簡単にお願いができるのだけれど、
（まぁ、やりたい事を言うだけならシロートと大差は無いよね）
Bの部分についてはある程度の業務知識が要求されるな、と、思って、ちょっと考えた。
絶対に避けねばならない最悪の事態というのは、複数あって、
そこをどれだけ事前想定できるか、というので勝負が決まるような気がする。
つまるところ、設計の仕事というのは、この辺の「決め事」をあらかじめ、どれだけ洗い出せるか、に、掛かっていると思う。
この辺りに、単なるプログラム好きと、自分の書いたプログラムに責任を背負う人間の境界線なんだろう。
プログラムでメシを食う奴らには両方居る、ということに気づいたのは、悔しいことについ最近だ。


で、そういうのを考えて設計書を書いていると、俺がコード書いたほうが早いんだけどな。というのは、時々思う。