確かに
「大量の無駄な物を生産した。
でも、生産物の『量』に応じてお金がもらえるシステムだから、
逆に儲かっちゃった。」
という問題は現実に起こっています。
--------------------------------
さて、では望ましい場合と、望ましくない場合とを並べてみましょう。
望ましい場合
「非常にスマートに仕事をして、低コストで、とある物を仕上げた。」
望ましくない場合
「非常に無駄な仕事をして、高コストで、とある物を仕上げた。」
等しいのは、生産物である「とある物」です。
違うのは「コスト」です。
ということで、「同一の生産物」という基準を作ったうえで、
「コストを減らす方法」
「コストが低い方を見つける方法」
が重要となるわけです。
前者は、プロセス改善であり、
後者は、低コストでプロセスを実現できるチームの発見でしょう。
ソフトウェアでの問題の一つは、
この「とある物」を完全に同じに2つ作れないということが挙げられますね。
完全に同じものを作っても仕方ないですから。
ですからここはせいぜい「類似するもの」で比較するしかありません。
しかし、濱井さんは、
これを「同じものを作らないから、比較不可能である。」としているので、
コストもまったく比較不可能なんですよね。
ところが、比較できないのに、
「高コストのものには金は支払えない」と言っているので
もう支離滅裂になってます。
--------------------------------
「コストが低い方法」を見つける方法として、
同じ生産物に対してコストを予測させて比較する方法があります。
これが一般で行われている「入札」ですね。
同じ生産物でも、
スマートな仕事をするチームと無駄な仕事をするチームとで
当然コストが違ってくるはずです。
しかし、濱井さんは、
「生産量とは売り上げである。」
「売り上げは先に予測できない。」
「コストは計測するべきではない。」
としているので、やっぱりコストを比較することができません。
--------------------------------
「生産量が多い方がよい」ということは間違っていません。
問題は「『量』とは何を指しているのか」ということです。
濱井さんも、結局、そこを間違えているために、
「ソフトウェアにおける生産とはコストの増大のことだから、
生産を減らした方がよい。」
「生産した価値は売り上げで評価すればよい。」
というおかしな結論に至っているのです。
この理屈だと、
「何も作らないのがベスト」なのに、
「作ってもいないものが売れる」
というおかしなことになってしまいます。
（プログラムは作ってなくても、
それは実は何かのサービスに置き換わっているのでしょうね。）
そもそも、たとえば2つの生産物を作ったのに、
「2つ作るのはコストが2倍かかっている」
とするのはどう見ても変です。
濱井さんの論で行くと、
「製品Aと製品Bを作ったら、コストが増える。
よって、製品Aだけを作るのが望ましい。」
ということになりかねません。
また、売り上げを指標にしてしまうと、
「製品Aの売り上げが、製品Bの倍だったら、
製品Aの生産性は、製品Bの倍である。」
という訳の分からない指標になってしまいます。
私が考えるに、ソフトウェアにおける「生産量」とは「満たされた要件の量」です。
（簡単に言えば「できるようになってうれしいこと」の量）
これならば、生産量が増えることはとても望ましいことになります。
「製品Aと製品Bを作ると、満たされた要件は増える。
よって製品Aと製品Bを作るのは望ましい。」
物を作るからには必ずコストがかかります。
コストは要件の量に対してほぼ正比例します。
（ただし、類似の要件に対してであり、まったく別の要件に関しては当然比例しな
い。）
--------------------------------
一度、式にあらわしてみましょう。
(納品先の利益) = (納品先が、満たされた要件によって得た利益) - (開発者の受注
価格)
(納品先が、満たされた要件によって得た利益) = Kgain * (満たされた要件の量)
Kgain は、要件に対する平均利益率
(開発者の利益) = (開発者の受注価格) - (開発コスト)
(開発者の受注価格) = Kmargin * (開発コスト)
Kmargin は、開発コストに対する上乗せ価格の率。
（通常は開発コストに対して、何割かの利益という形でもらうことになるため、ほぼ
比例する。)
(開発コスト) = Kcost * (満たすべき(あるいは満たされた)要件の量)
Kcost は、要件の量に対する平均コスト率
（通常は、開発コストは要件の量にほぼ比例する。）
こんな感じでしょうか。
(開発者の利益)を上げるには、
Kmargin を上げて、(開発者の受注価格)を上げるか、
Kcost を下げて、(開発コスト)を下げる
しかありません。
(納品先の利益)を上げるには、
Kgain を上げて、(納品先が、満たされた要件によって得た利益)を上げるか、
Kmargin, Kcost を下げて、(開発者の受注価格)を下げる
しかありません。
開発者が、Kcost を下げることが、生産性の改善です。
納品先が、Kcost と Kmergin が低いものをさがすのが、入札のようなものです。
納品先が、Kgain を上げるのは、企画の改善(?)です。
濱井さんは、「Kgain を上げる」ことを
選択したようにしか見えませんが、
これは開発者としてはどう見ても不可能な選択でしょう。
開発者が可能とするならば、それは納入先と開発者とが同一の場合のみです。
--------------------------------
さて、冒頭のおかしなシステムを表す式を立てて見ましょう。
(納品先の利益) = (納品先が、満たされた要件によって得た利益) - (開発コスト)
(開発者の利益) = (開発コスト)
(開発コスト) = (コード量とか工数とか)
という感じでしょうか。(ものすごく荒っぽいけど。)
これならば開発コストがかかればかかるほど開発者の利益が上がるわけです。
現実問題として、こういう素朴な計算になってしまいがちなのは
残念ながら事実です。
なぜそうなるのかと言うと、
「無駄な作業なのか」「正当な作業なのか」の判別が、
非常に困難であることが一番の原因です。
この困難性に対する解答は、濱井さんからはまったく聞こえてきません。
「困難だから Kgain で測定しろ」という乱暴な答えしか聞こえてこないのです。
// 樋口 勝也
// bugbear@....nu