樋口です。
「生産量」がそもそも何を意味しているのかというのが問題なんですよね。
結局のところ、「満たされた要件の量」がそれに値すると思うのですが、
なぜか「コードの量」や「文書の量」が生産量とみなされていることが多く、
無駄なコードや文書を大量生産するほうが
生産性が高いと誤解されてしまいやすいのだと思います。
（あと、しっかり定時で仕事を済ませる人よりも、
残業する人の方が残業代が出て儲かってしまうとか、
「働き者」とみなされるとか、変な問題もありますね。）
再利用できるようにするコーディングや、リファクタリングは、
それだけ見ただけでは「満たされた要件の量」を増やしません。
（場合によっては、一時的に、満たすことができる要件の量を減らすことにもな
る。）
しかし、再生産を防いだり、コードを簡潔に保つことで
「これから満たすことができる要件の量」を増やすことができるのですよね。
つまり未来への投資なわけです。
これをどう評価するかという手法は確かにまだきちんとできていない気はします。
間違った前提からは間違った答えしか出ないというのは正しいと思います。
ただ、私としては、ソフトウェア工学が間違っていたというよりも、
そういった評価手法を利用して評価する人たちが
中途半端に評価手法を理解して、
「一見合理的に見えるが実は正しくない評価方法」を取ってしまったり
「目先の利益」にしがみついたりするのが問題なのだろうと思っています。
あと、なぜか CMM を盛んに批判されているようですが、
CMM は「要件をどれだけ『正確に』実現できるか」という問題であり、
「開発規模」や「生産性」とはあまり関係がないように思えます。
もちろん、高い品質のものを少ない工数で、という要望は理解できますし、
いつも迷わず同じ手法を繰り返すのであれば、
迷わない分だけ少ない工数で達成可能なはず、よって生産性が高いはずである
だから生産性に関わってくる、ということはわからないでもありません。
ただ、なぜ「同じプロセスを繰り返すことができるか」が問われているのかを
どこか誤解しているように思われます。
（同じような誤解を多くの測定者が持っているのかもしれませんが。）
プログラミングでは「スタイルに一貫性を持たせよ」としつこく言われているはずで
す。
これは「同じ事を繰り返せ」ということと同義です。
しかし、「同じ事を繰り返せ」ということは「同じ物を作れ」という意味とは違いま
す。
（スタイルに一貫性を持たせても、同じ物は作りませんよね。）
また、「開発規模」が問題になるのは、見積もりの段階であり、
「これくらいの要件であれば、この程度の予算/工数が必要」
というのを導くために必要なのだと思います。
見積もり段階は、「戦略級」の話が全般であり、
過去の見積もりと実績からの予測が中心です。
再利用やリファクタリングという「戦術級」の話は
残念ながら、ほとんど現れてこないと思います。
// 樋口 勝也
// bugbear@....nu
----- Original Message -----
From: <k-hamai@....com>
To: <extremeprogramming-jp@....jp>
Sent: Monday, January 07, 2002 10:53 AM
Subject: [XP-jp:02973] Re: CMM と XP
> 濱井です。
> 私が細かいところまで反論して話を発散させてしまったせいか、私の
> 批判の基本的なところが伝わっていないようです。
>
> 最も基本的な問題は、「ソフトウェアの開発規模は生産量をあらわす」
> という考えが間違っているということです。それは、「このノートPCの
> 生産量は幅30cm、奥行20cm、高さ2cmである」という言葉と同じくらい
> おかしなことです。
>
> 冗長なコードや不要な機能を削ったりするリファクタリングは、一般に
> ソフトウェアの開発規模を減少させますから、この考えと両立しません。
> 同様にソフトウェアの再利用などとも両立しません。
> わざわざこのメーリングリストにおいて、私が批判しているのはXPにおいて
> 重要なリファクタリングと両立しないという点が大きいです。
>
>
> 「生産性＝生産量（産出量）／投入量」ですから、生産量を測定していない
> ということは生産性を測定していないということであり、従来の
> ソフトウェア工学は生産性において全く間違った前提の下で議論されてきた
> ということです。CMMもその例外ではありません。
> 間違った前提からは、一般に間違った結論が導き出されます。
> CMMもあちこちおかしな点があると指摘しているわけです。
>