ある開発プロジェクトでの話。
アプリの開発具合を日々報告するのですが、開発した機能と潰したバグの報告に加えて、作成したプログラムのソースの提示が求められてます。ソースを閲覧して、コードレビューしてくれるのかな...と期待してたら、違いました。
どうやら、日々の開発したソースの有効量(コメント以外の実行行)を積算して、有効行数の増加分が日々の成果と判断している様子。
ある日、共通役割を整理して、基底クラスを幾つか作り、派生させる形式に改造したところ、ソースの量が減りました。
有効量が減ったことで、「なぜ減ったのだ。手戻りが発生したのか、プログラム設計ミスなのか....報告せよ」と通達があったそうです。
「 同じ機能なら、ソースの量が少ない方が、品質が高いことが多いし、バグも少ないですよ。良い記述法があれば、短くなりますよ」と説得しても、管理者から「社の方針がそうなので、私では如何ともできない。私見で判断できない。このプロジェクトのソースはは xxxxステップ位で完成するモノと見積もっている。それを元に人員計画している。キロステップ当たりのバグ数とテスト項目数で品質管理している。それなのに、その半分以下のステップで完成されたら、見積能力を疑われてしまう。なんとか量を近づけてくれ」と泣き付かれたらしい。
うーん。オープン化が浸透していると思っていたのに、ステップ管理文化が生きていたとは。(あ! Open化とは因果関係はないか..) OOPだと逆に増えるケースもあるので、一概には少ないのが良いとは言えない面もあるのでずか。
ソフトの品質の判定できる人が少ない現実があるとことか。コードレビュー基準も、オープン系に馴染まない項目も多々あるようですし。大手の業者が、そんな状態だと、業界内の品質格差は広がる一方になります。
将来に不安を感じる出来事でした。