下請け会社のプログラマは、元請からは個人単位では評価されずに会社単位で評価されます*1。たとえば、5 人のプロジェクトだけど実際には 1 人のプログラマがコードの大半を書いていたとしても、会社単位で評価され 1 人頭の売上はおんなじです。まぁ、そんなもんです。実際には会社から支払われる給与はモチロン差はある程度は付くけど。
さて、じゃあ下請け会社の評価基準は色々あると思う。ただ、大抵の元請ではバグレポートはその 1 つに入ってるのではないでしょうか。あるプロジェクトにつき、バグの出現数と致命的度合いによる評価、とかそんな感じのやつです。
要は減点方式なワケで、この状況下では出来るだけバグを出さないことが重要となります。
恐ろしい事に、仕様書がクソッタレで実装が曖昧にならざるを得なかった個所が妙な動作をしたとしても、たちどころにバグレポートの山が積み上がります。現場の人間は（元請側の人間も）何がどう悪いのか正確に把握しながらも、バグレポートに報告されちゃったので我々下請けプログラマの失点となり、これ即ち下請け会社の評価ダウンとなります。
仕様書が曖昧な部分は出来るだけ早く明確にするようにはするけど、仕様書の不備に起因する「バグ」はどうしようもないし、作ってみて始めて分かる問題もあるんで仕方の無い部分もある。この辺もうちょっとアジャイルなやり方が出来れば随分改善できるんだろうなぁ･･･といつも思うんだけどねぇ*2。
それはさておき、どうしてもバグレポートに上げられてしまうものは体制等の問題もあって手が出せないので、その他のバグが上がらないようにする必要がある。その他のバグとは、仕様書には書かれないけど実装することが暗黙に求められる類のもの。
それはぶっちゃけエラー処理。null や空文字の許容/非許容に始まり、数値や日付やナントカ番号の形式検査を漏れなく全画面遷移の必要個所に入れ、DB が不整合起こさないように ID の重複や矛盾しないようなチェック処理、などなど。言い換えればトコトン防御的にプログラムを書くってとこです。
取り得る入力値のパターンをしらみつぶしに検証するというひたすら地道な作業ですが、それで会社の評価ダウンが少しでも防げるならやるしかないよなぁ、ってカンジです。仕様書には書いてないけど内部的な品質向上に繋がってるワケだから無駄じゃない、ハズ。
もちろん、使い勝手などの外部的な品質向上はまた別の問題になるんだけど･･･。
本音を言うと、こんなことは口に言うまでも無く当たり前のことだと思ってたんだけど、そうじゃない人もいるわけで･･･。「バグレポートに上げられたものがバグであり、それを直せばいい。仕様書に書いてあることだけやればいい」みたいな。こういう人には「出来るだけバグの出にくいコーディングを」と説いてもわかってくれないというかなんというか･･･。もっと言うと、そういう態度はプログラマー以前にビジネスマンとしてどうかと思うんだけどねぇ。
