日々常々

ふつうのプログラマがあたりまえにしたいこと。

仕事の範囲

プロジェクトは複数でやるもので、各自の仕事の範囲を明確にする必要がある。明確にしないと、どこまで手をつけていいやら判らず、過不足が出てきてしまうから。
この複数ってのがクセモノで、複数の会社からなる幾つかのチームが異なる場所で開発してたりすると、会社毎に仕事の範囲を明確にしようとする。この場合、本来やるべき仕事よりも、より少ない仕事量で線引きを行った方が各社としては勝ちらしく、自らの仕事量が少なくなるように、目に見えているやれる範囲だけで線引きする。当然、目に見えづらいあやふやな部分、すなわち各チームの連携部分等がどこもやりたがらない状態で残る。結果として、ギリギリになって慌てたり、力の弱い(声の小さい)所に流れ込む事になる。
そんな事になるとデスマーチ確定なわけで、プロジェクトを失敗させたくは無いと思っている所が自分に関係の無い部分でも口を出し始める。するとよく判らない調整という押し付けが行われ、口を出した所が無関係のはずの部分も背負い込む事になる。結果的にプロジェクトは何とか収束するだろうけど、本来と無関係部分の仕事を行った所はそれほど評価されない。なぜなら最初の段階では目に見えない部分の仕事であるため、無かった事として扱われるから。結果として、より小さい範囲で線引きを行った所はたいしたゴタゴタもなくプロジェクトの完了を迎えたと言う事実のみを引っさげ、次のプロジェクトに堂々と入っていく。
数字に見えない仕事をいくらやっても、数字(=お金)を出す人からすればやってない事になる上、最初に数字を出す人はいつまで経っても目に見えない部分を見ないまま数字を出す。危険そうな部分に気づいて背負い込む人はいつまでも背負い込み続けるだろう。下手すれば数字の出ない仕事に時間をかける駄目なヤツの烙印を押されかねないが、失敗なんてさせたくないから不利益承知でやってしまったりする。一方で出された数字から仕事を計算して差分の利益を得るところも有る。
各社の利益も重要だろうし、それを軽視したら立ち行かないのもわからないでもない。プロジェクト全体としてまともに終わらせる気は無いのかと問いたい所だが、下手なことをやって不利益の責任を被れるわけでもないのかと考えると、目に見えづらい仕事が正当に評価されなければならないのかなとも思う。でもそういうところって大抵の場合に後の方になって見えてくるものだったりで、初期の段階では本当に見えない所だったりする。それらを再評価するってのは、よほどやりづらいらしい。最初に決めた予算、スケジュールを変更するなんてとんでもないと言う考えがあるから。結果として、どこかが泣かないといけないようになってる。泣くのは弱いところ。