商品を作っている職業プログラマーにとって、生産性は非常に重要な要素です。プログラムに限らず、商品を作る場合に原価は非常に重要ですが、プログラムの場合には原価はほぼ製作者の作業量に比例するのですから。
また、オープンソースプログラマーや研究者の場合は多少関係があいまいになりますが、原理的には同じことが言えます。お金には換算しにくくなりますが、作業量が有限なリソースであるという点では同じです。
プログラムにおいて生産性は重要なので、生産性を上げるために学ぶべきことはたくさんあります。プログラマーは比較的学習を求められる職業ですが、必要とされる多くは生産性にまつわるものです。
もちろんすべてではありません。たとえば効率的なアルゴリズムを求めるという学習もあります。これはあまり生産性には関係してきません。でも、効率的なアルゴリズムについての技術書は全体の中ではわずかですね。
学問的なものでは、設計に関するソフトウェアメトリクスなどの研究もされていますが、それを測る意味がなんであるかというと、それは生産性が上がるということにほかなりません。どんな設計をしたところで、無限の時間を与えられてコーディングとデバッグを繰り返せば、いつかは完成するわけですからね。有限の時間を有効に使う必要があるから、プログラムの技術は必要とされるのです。
しかし困ったことに、生産性を定量的に測定する方法は確立されていません。
現代科学の成果は定量的な測定によって確実な結果を積み重ねることによってなされてきました。プログラムの生産性を定量的に測定することができれば、様々な技法の優劣を細かに検証することができるため、有利な技法のみを組み合わせることができ、プログラムの生産性は飛躍的に上がることでしょう。しかし残念ですが、プログラム業界でそういう現象はまだ起きていません。
もちろんプログラム技術の研究の初期には定量的な測定の試みは行われ、結果も出ていました。たとえば古典的名著「人月の神話」には、プログラマーによって生産性に10倍の差が出るという結果がのっています。
ただその後の報告が続いていないようです。論文などに目を通して言っているわけではないので、純粋に学会レベルでは成果も出ているのかもしれませんが、書籍で紹介されるようなレベルで活用できる数字は数十年出てきてない模様です。
そして、最近ではプログラム業界の偉い人が、生産性を測定するなどそもそもあきらめろと言っています。
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?MeasuringProductivity
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?CannotMeasureProductivity
プログラム業界に「計測できないものは制御できない」という言葉を広めたトム・デマルコは、
http://www.amazon.co.jp/dp/4764901331/xpjp-22
後年を撤回し、計測の効果を計測することはできていない、と言っています。
http://www.amazon.co.jp/%E3%83%87%E3%83%9E%E3%83%AB%E3%82%B3%E5%A4%A7%E3%81%84%E3%81%AB%E8%AA%9E%E3%82%8B%E2%80%95%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A224%E3%81%AE%E9%96%83%E3%81%8D%E3%81%A8%E5%86%B4%E3%81%88-%E3%83%88%E3%83%A0-%E3%83%87%E3%83%9E%E3%83%AB%E3%82%B3/dp/4817160578/ref=cm_cr-mr-title
プログラムの生産性の測定は誤差が大きく、たぶん実用レベルで測定することは現代の科学では不可能です。計測できないことが実証されたわけではないので、将来もできないとは限りませんが、少なくとも現状でそれを行うには大変なコストがかかり、現実的ではありません。
信用できない数字を探すことにコストをかけることや、また信用できない数字を信じて対策を立てることは、生産性を上げる邪魔にしかなりませんから、そのような数字はだんだんあげられなくなっているようです。
それでも、しばらく前まではRuby on Railsの生産性がJavaの10倍という話があったように、宣伝文句には数字が挙げられていたようです。しかし、最近Visual Studioの宣伝で生産性の向上は数字では挙げられていません。現代では、宣伝にすらそんないい加減な数字はだされなくなっているようです。
ただ、生産性の向上を定量的に計測することが不可能だからと言って、生産性の向上をしなくてもよい、ということにはなりません。多くの開発者は現代も生産性を向上させるための努力を行っています。自分だけが行わなければ、自分の作成するソフトウェアの価格競争力がなくなるだけのことです。
測定を定量的に行うことが不可能なら、定性的に行えばよいのです。科学的に厳密な検証には使いにくくなりますが、人間が一般的な活動で法則のほとんどは定性的にしか得られていませんので、十分に役に立つといえます。
プログラム業界の話を具体的にすると、一つ一つのツールや工夫を試してみて、労力が減るかどうかを主観的に判断すればよいのです。
実験とかを見慣れていない人にはこちらのほうが理解しやすいとも言えるでしょう。
定量的な測定と違い、一つ一つの工程について確実な効果を積み重ねるというわけにはいきませんが、工夫は大量に行われますから、一つ一つの効果を確実に確認する必要は必ずしもありません。一定の割合で役に立たないものがあったとしても、全体的には効果があることは認められるでしょう。
可能であるなら、数社の単位で総合的な生産性の測定を行うとよいでしょう。ただ、Micorosoftが自社のツールについてそういう数字を発表できていないことを考えると、相当大規模なデータをそろえないと、意味のある数字は出せない可能性が高いですが。
そもそも努力したことを客観的に確認できないから何も努力しませんってわけにはいきませんからね。プログラム業界に限らず、目に見えない努力の上に世の中は成り立っているのですから。
現状では、数値測定ができないから無駄とは思わずに努力を続けていく必要があります。