ソフトウェア開発の分野では、その他の分野と同様に、マネージャがプログラマのパフォーマンスおよびプロジェクトの進捗を正しく評価する必要がある。しかしながら、この目的への適切なメトリックを定義するのは、厄介なタスクであるかもしれない。
コードのソースライン(SLOC)を評価することは、一般的に使用されているアプローチであるが、近ごろShahar Yair氏(リンク)およびSteve McConnell氏(リンク) によって多くの重要な制限が提示された。まず最初に、コードのラインの量は、結果よりもアクティビティに重点を置いているため、プロジェクトの進捗を効率 的に評価することができない。LOCは、それ自体は価値を持たない。つまり、最終生産物は、そのパフォーマンスや品質に依存しており、コードの量には依存 していない。したがって、後者にフォーカスすると生産性のアプローチが非常に制限される。
SLOCは、保守容易性、柔軟性、拡張可能性の観点では、間近に迫った問題の複雑性や最終生産物の品質について何も語らない。品質に関して、実際否 定的に関連付けられる。設計パターン同様にリファクタリングは、コードの質を改善しながらも、LOCを減らすことになる。コードベースが大きくなると、ノ イズが多くなり、不必要に複雑になり、読み出し可能性や柔軟性がなくなることを意味する。
プログラマのパフォーマンスの還元的なビューを導入する上で特に危険なことは、誤ったインセンチブを作成するということである。最終生産物の観点か ら作業を最適化するよりむしろ、デベロッパは、品質に被害が及ぶまでにコードの量を支持するよう働きかけられている。またしかも、意図的に詳細なコードを 記述するように後押しされている。「査定されるものが、終えられる」とSteve McConnell氏は思い起こしている。
氏は、メトリックを査定する際に、ファンクションポイントを使用することで、これらの問題は解決することができると指摘している。プログラムサイズは、入力、出力、クエリーおよびファイルの数によって決定される。そうは言っても、このアプローチには欠点もある。McConnell氏 は、認証ファンクションポイントカウンターを所有する必要性および各ファンクションポイントを個々のプログラマにマッピングする際の難しさといった現実的 な問題について言及している。認証ファンクションポイントのスペシャリストであるDaniel Yokomizo氏は、そういったアプローチのその他の制限についても強調している。それは、ファンクションポイントの複雑性を査定するためのツールおよ びコードの共有、フレームワーク、ライブラリ、など機能を作成するために必要な時間に影響を与えるものを考慮するためのツールがないことである。
アプローチの評価に関する議論に関わっている解説者の多くが、それぞれの制限に同意を示しているけれども、プログラマのパフォーマンスを評価する必 要性を必ずしもはねつけているわけではない。たとえば、SLOCは、さまざまな要因が組み合わさったより複雑な分析をするためのベースラインとして使用す ることができる、ことを多くの人が主張している。これは、McConnell氏によって概説された4つの原則と足並みをそろえる。それはプログラマの生産性の分析を正しく導くものである。
1. 生産性の次元評価によって、個々の生産性の良い図式が得られると期待してはいけない[…]
2. 評価によって[…]それぞれの生産性を細かく区分することができると期待してはいけない。 答えるべき質問を提示するが、答えを与えてはくれない[…]
3. 傾向はたいてい、ある1つの地点の評価よりも重要な意味を持つことを忘れてはいけない[…]
4. そもそも、なぜ個々の生産性を評価する必要があるのかを自問する[…]
実際に、どのコンテキストでプログラマの生産性を評価するのが意味があるのか?それには、どんな基準を用いることができるか?どのように結び付けることが できるか?多くの質問が、まだ議論を受付中であり、実際の経験によってある種の答えを得たのであれば、気軽にそれを提供して欲しい。
原文はこちらです：http://www.infoq.com/news/2008/10/measure-programmers-productivity