LOC生産性でチームの開発能力を評価してほしくない
最初に、すいません。ただのグチです。
まあ、仕事をしていると嫌なこともあるわけで、腹の中でモヤモヤしているのも健康上良くないので、ここで整理してみようかと。
チームの開発生産性の比較にLOC生産性を使うな
結論はこれなんですけど、もうちょっとだけ。
保守開発なんてやっていると、他システム起因のプロジェクトにチームとして案件支援を行うことがあるのですが、それらを統括するPMO部隊の発言で、ひっくり返りそうになるのがコレ。
「今回は各チームとも生産性を○○KLOC/MM以上にして欲しい」
「オタクのチームは、見積生産性が☓☓KLOC/MMで生産性が悪いんじゃないか」
この手の発言聞くとやる気激減なわけですけど、仕事なので仕方が無い。。。
所謂クソコードが多いプロジェクトの方が生産性がよく見える
そもそも、チームの開発生産性を比較するのに、LOC生産性を使うのは問題がおおすぎるのですよ。
保守開発の現場では、今回開発予定規模を「母体係数法」を使うことがあります。
この母体係数法では、
今回修正規模 ＝ 実修正規模 ＋ 母体規模 × 係数
なんて式で開発規模を求めるわけですが、母体規模が大きければ大きいほど今回修正規模が大きくなるわけですね。
てことは、
- コードクローンがたくさんある
- 到達不能コードがたくさんある
- モジュール分割せずに巨大ソースを書く
なんて状態のプログラミングを行っているチームのほうが母体規模が大きいってことになるわけで。
で、オッサンはちまちまリファクタリングしたりして、少しでも書きやすいコード、修正しやすいコードにしようとメンテナンスしているわけですけど、そうやってメンテナンスすればするほど、母体規模は小さくなるし、修正が必要な量も少なくなる。
でも、実現する機能量は変わらないので、必要となるテストやドキュメントなどはさほど減らない。
なので、見た目上LOC生産性が悪くなるようにみえるわけなんですよね。
改善すればするほど、何もしないチームよりも生産性が低いなんて言われたりしたらふざけるな、といってしまいたくなるわけですよ。
まったく、やってらんない。
そもそもプロジェクト特性を無視して開発生産性を比較するな
LOC生産性なんて指標だと、数字出すこと自体は案外柔軟に行えるもので、プロジェクトの形態を問わず生産性を算出できるわけですが。。。
バッチ中心のプロジェクトと、オンライン中心のプロジェクトの生産性を単純比較するなよと。
同じような理由で、生産性が出づらい基幹系システムと生産性が稼ぎやすい情報系システムを比較したり、生産性が出づらい超大規模なプロジェクトと生産性が稼ぎやすい小規模プロジェクトを比較するのも違うだろうと。
プロジェクト特性により、必要となるタスク、開発量は変わってくるのだから、十把一絡げにLOC生産性を評価してもしょうがないだろうに。
というか、同一チームにおける過去の案件と次回案件での開発生産性の比較以外で生産性なんか使うもんじゃあないだろうと。
予算削減の理由として開発生産性を問題にするべきじゃあない
こんな感じで生産性が問題になるってのは、要は予算を減らしたいって思惑なわけなんですけど、生産性なんて「生産性悪いんじゃないの」なんて指摘したって当然上がるわけない。
むしろ、どこかに歪みが生じるわけで、リスク上昇や品質低下などろくな事にはならんと思うわけなんですよね。
予算を減らしたければ、基本は要求といったフォーカス減らすべきでしょう。
無駄な要求、無駄なタスクを要求し、上積みしているにもかかわらず開発生産性が悪いって言うのは筋違いだろうと思うわけです。
まとめ
まあ、仕事を依頼する側も結局は更に上役に対して説明するために、LOC生産性を利用するって理屈もわからなくはないわけです。
誰にでもカンタンに計測ができるLOC生産性ならば、数多くのチームが共通の指針として算出する事自体は簡単です。
大人数、多数のチームが参画するようなプロジェクトでは仕方が無い理由があるのでしょう。
とはいえ、最初に戻るわけですけど、LOC生産性をチームの開発能力比較に使わないでほしいわけですね。
アカウンタビリティを易きに流れLOC生産性を使うのではなく、チーム特性ごとにきちんとした分析指標で説明できるようにしたほうが有用だと思うわけです。
全くやってらんないわけです。愚痴りたくもなりますよ。
以上