樋口です。
>客：「ＸＸという機能だが、私が思っていたのとは違う。直してくれ。」
>あなた：「いえ、これは、数ヶ月前にきちんと承認印をもらっている正式仕様で
>す。」
>客：「そうだっけ？しかし、それは違うんだよ。こういう意味なんだ。」
>あなた：「そうなのですか？でも、もうすでに、仕様書に書いてあるように全体が
動
>いています。ほぼ開発完了していますし、これからやりなおすわけにはまいりませ
>ん。」
>客：「...」
少なくとも証拠がある以上、顧客の負け。
なければ水掛け論でしょうね。（ありがち。）
水掛け論の方がよっぽど信頼関係を崩します。
また、なぁなぁで修正を続けてコストをだらだら垂れ流す方がよっぽど危険です。
（ところで誰が支払うんですかそのコスト?）
変更には必ずコストがかかります。
まだ変更するかもしれないのに、
「なんとなくこれでいいや」とゴーサインを出したのであれば
それは顧客の責任であって開発者の責任ではありません。
もちろん、顧客がゴーサインを出すかどうかを判定する時に、
開発者には十分な説明をする責任があります。
（最近流行の「説明責任」ってやつですね。）
典型的なウォーターフォール型開発をしていると、
ひたすら仕様書を仕上げているだけでどんどん時間が過ぎ、
顧客は仕様書だけ見ても何ができるのかさっぱりわからない状態で
ゴーサインを出さざるを得なくなり、
数ヶ月〜数年後、最後にできたものを見て驚くことになり、
「直してくれ」と言っても、「ベラボーなコストがかかる」と言われて泣く
ということになるわけです。
これを改善したのがスパイラル型開発で、
顧客が理解できる量、短期間で開発できる量にして、
顧客が理解できるものを作り、
もしも間違っても少しの変更（軌道修正）で済むようにしたわけです。
そしてそのサイクルを最大限に小さくしたのが XP でしょう。
（というのをここで説明しなきゃならんのですかね…）
>計測して第一指標にすればそれが常態になります。
これって、何を計測して、その計測値を何の役に立てるのですか?
何度も書いてますが、
「プロセス改善(コスト削減)」と
「価値の拡大」とではスコープが違うのです。
XP で行うことは残念ながら(?)「プロセス改善」が中心です。
「価値の拡大」はソフトウェア工学ではなくマーケティング学の話になってしまいま
す。
無視しているのではなくて、スコープが違うし、
計測方法も予測方法もソフトウェアと相関関係が少ない（統計を勉強しましょう）か
ら
ソフトウェア工学では通常対象にしないのです。
「対象にしないから間違っていたのだ」というのは、お門違いなのです。
XP でいくら工期を削っても、売れないものを作ればダメなのは当たり前過ぎます。
また、価値は一旦無視して、
「同価値のものを作るのにどれだけコストがかかるのか」としないと、
コストは計測できないのです。
コストに価値が含まれてしまっては、
コストを測定しているのか価値を測定しているのか
分からなくなってしまいます。
価値を含んでしまうと、
「高価値のものを作ればコスト削減しなくてもよい」
というおかしな結論に至ってしまうのです。
「コスト削減」と「価値の拡大」は両輪そろって意味を持ちます。
「コスト削減」をないがしろにして「価値の拡大」を図っても、、
「価値の拡大」をないがしろにして「コスト削減」を図ったりしても
どっちもうまくいきません。
しかし XP が対象としているのは、プロセス改善であり、コストの削減が中心です。
ソフトウェア工学は、「同一要件のものをどれだけ少ないコストで作れるのか」を考
えます。
だから、主に「コスト削減」が語られるだけであって、
「価値の拡大」を無視しているわけではないのです。
通常は「価値の拡大」は顧客の業務部門やマーケティング部門が考慮することになり
ます。
業務を理解していたりマーケティングもできるSEはもちろん評価は高いのですが、
それはまた違う話でしょう。
範囲が広すぎるので、それぞれ勉強してちょうだいって言うしかないですよね。
// 樋口 勝也
// bugbear@....nu