> >> 仮に、ソフトウェア自体を計って、生産量Xが得られるとしましょう。こ
> >> こで、全く同じソフトウェアが複数の組織や個人で別々に開発されたとし
> >> たら生産量の合計はいくらになりますか？
> >
> >生産量は単純に合計し評価し、重複分は別途(無駄なものとして)
> >評価すればよいだけです。ひとつの数値ですべてを表そうとする
> >から何もかも「できない」という結論になるのです。
>
> 現実的には、ソフトウェア全体の規模がある程度以上になってしまうと重複
> 分を調べることなど不可能です。偶然、重複しているものが見つかることが
> あるにすぎません。
だからそういっているわけです。しらみつぶしにやるなら下記の
洗い出し率は100%となるはずです。
| 再発明に相当する無駄な分を洗い出し、そういったものの比率が少
| なくなるようにするのではないですか？「ゼロ」にするには洗い
| 出し作業のコストが膨大になりますから、「少なく抑える」方向
| になると思います。どの程度少なくなったかなどの割合は、そも
| そも全体の量を求めなければならないので、上記の単純に合計し
| た値を用いることになるでしょう。
|
| 重複分が減少すれば、ある側面の生産性が上がったとみなすこと
| ができるでしょう。ここで重複分の洗い出し率が未定義ですが、
| 便宜上コストに比例すると置くしかないと思います。すなわち
| 重複分の洗い出し率/洗い出し作業に掛けたコスト=一定とした分
| が現実との誤差であり、一連の数値が実際の値ではなく近似であ
| る証です。
> プログラム全体がまるごと重複していることはまず無く、クラスやメソッド
> のレベルで重複しているでしょうから、そのレベルで調べなければなりませ
> ん。そのため、チェックすべき組み合わせの数は膨大なものになります。
>
> 重複をチェックすべき組み合わせの数は、ソフトウェアの数の自乗に比例
> します。メソッド数が1万なら約5千万通りに、10万なら約50億通りになりま
> す。その数パーセントぐらいはチェックしないと誤差が大きすぎて推定値で
> あったとしても意味をなしません。
それでは、売り上げを基準とすればそれより効率よく確実に重複分
が減少するわけですか？そこまで反対意見に確実性を求めるな
ら、自説により期待される効果も、具体的に示すべきでしょう。
--
Michitaro Horiuchi / Access Co.,Ltd.
horiuchi@....jp / horiuti@....jp