Index: [Article Count Order] [Thread]

Date:  Fri, 19 Oct 2001 16:39:22 +0900
From:  hamai@....jp
Subject:  [XP-jp:02680] ソフトウェアと見積もり	 (was XP と Taylorism)
To:  extremeprogramming-jp@....jp
Message-Id:  <200110190739.QAA15893@....jp>
In-Reply-To:  <200110180624.PAA02389@....jp>
References:  <200110180624.PAA02389@....jp>
X-Mail-Count: 02680

濱井です。以前から考えていたことではあるのですが、整理する
のに少々時間がかかりました。
2001/10/18 15:24:54 +0900にANC04864@....COMさんが送られた
メールに関する返信です。

>> そもそも、ソフトウェア開発では、同じものを開発しても意味がない
>> ので、同じ生産物を作る、同じプロセスで作業を遂行するといった、
>> Taylorismの前提が成り立ちません。
>> # それなのに無理に適用したりするからおかしなことになる:-<
>
> はい、そう思います。
>
> 濱井さんのお考えをお伺いできれば嬉しく思うのですが、例えばポリシー
>を適用するのであるとすると、その産業的分類上の「前提が同じである必要
>はない」とは考えられないでしょうか?

それを説明するには、「ソフトウェアとは何か?」という話から
した方が良さそうです。

「ソフトウェアとは何か?」という問いに対する私の答は、
「ソフトウェアとはハードウェアを制御するための情報である」
というものです。

ソフトウェアは情報であり、著作権法の対象となる他の著作物と
類似した性質を持ちます。オリジナルを作ることは難しくても、
一旦作れば、同じものを大量かつ安価にコピーできます。
ソフトウェアは工業製品より、むしろ、小説や音楽などと似た
性格のものです。パッケージソフトなどは特にそうです。

小説の長さや曲の長さがその価値を決めないように、ソフトウェア
の規模はその価値を決めません。

ハードウェアの製造では製造する前にその製品の価値はほぼ決まって
います。同じものを作るわけですから、不良品でもないかぎり各製品
の価値は同じです。ソフトウェアの開発では同じものを作るわけでは
ありませんから、ソフトウェアごとにその価値は異なります。
そして小説や曲ができあがらないとその価値がわからないように、
開発が完了しないとそのソフトウェアの価値はわかりません。また、
その価値は、往々にして大きな違いがあります。

そのソフトウェアの価値が見積もりにおける大きな問題なのです。


> しかし、仮にXPでどんなに品質が良いものがつくられたとしても、濱井さ
>んが記述されているように、できるだけ正確な「時間の見積り」がビジネス
>では望まれるいう考えは変わらないと思います。それが正しければ、ボリュー
>ムからのざっくりとした見積りだけではなく、標準時間として計測可能な部
>分を見つけて作業方法と時間を規定し、見積りの精度を上げるという取り組
>みの重要性は今後も変わらないように考えます。
> そうであれば、ビジネスとしてモノを作る場合は、「stopwatch time study」
>(時間見積り) という考え方が、例えば部分であろうと必要であるという事
>にはならないでしょうか? もし、なるとしたらポリシーとして適用され得る
>と言ってもよいという事になるだろうと考えますし、その他のプラクティス
>(またはポリシー)についても同じようにビジネスとしてのモノ造りに必
>要な考え方であるのかどうかを検証してみる事は意味があるように思います。

見積もりの精度を上げるためのコストがほとんど無視できるほど
小さければ、見積もりの精度を上げれば上げる程いいでしょう。
ですが、これは成り立ちそうにありません。

過去に開発したソフトウェアと類似性の高いソフトウェアの開発
ならば、過去のデータを参考にして高い精度の見積もりができる
でしょう。逆に全く新規の開発となると過去のデータが参考にならず、
見積もりの精度は下がるでしょう。

ソフトウェアは情報であり、情報の価値の本質は他との差異にあります。
同じ本が何冊もあっても、得られる情報が増えるわけではありません。
同じ分野の類似の本を何冊も読むより、全く異なる分野の本を読んだ
方が効率よく多くの情報が得られるでしょう。
既存のソフトウェアとの類似性が高い、差異が少ないということは、
一般に、そのソフトウェアの価値が低いことにつながります。
逆に、価値の高いソフトウェアは一般に大きな新規性をもっています。

見積もりの精度を高めようとすれば、既存のソフトウェアとの差異を
小さくせねばならず、それは開発するソフトウェアの価値を下げる
ことになりがちです。開発するソフトウェアの価値を高めようとすれば、
既存のソフトウェアとの差異を大きくせねばならず、見積もりの精度を
下げることになります。

ソフトウェア開発の見積もりの精度は、開発するソフトウェアの価値と
両立しないということです。