>>859
>>ユーザーが数百人いて、使い方や望む機能がまちまちで、
>>顧客側の担当者がそれをまとめきれなければ、どうするの？
>
>そんな状態になったらどんな手法でもそのプロジェクトは破綻するんでは(笑)

破綻するプロジェクトってのはだいたいそういうもんだよ。
そうでなきゃウォーターフォールでも破綻しない。

>ともあれ、XPでは顧客は「決定権のある人」を要求している。
>その例ではそもそもXPはできないな。

だからウォーターフォールが破綻するようなプロジェクトはXPでも
破綻する。

>>860
>
>ただ、良いソフトウェアをつくるためには、
>超ハードユーザの助けが必要だというのが、これまでの知見なのだ。
>その人選に問題がある場合は、どの道ソフトウェア開発はうまくいかない。

同上の答えだ。なんとなくキミと俺ではプロジェクトが窮地に立たされる
主原因の想定に違いがあるようだ。

俺は基本的に顧客からの要求仕様の確定にネックがあると思っている。
顧客もSEもこの部分が分析しきれないから、破綻する。

一方キミが想定している破綻の原因はなんだい？顧客側に自分たち
が望むもののとりまとめが出来る人物を想定しているわけだよね。

となると設計や実装の方にネックがあるといってるの？それもあるけれど、
一番の原因は要求仕様のほうだと思うけど。

で、設計能力の未熟さはXPで改善できるが、要求仕様について
XPは開発者側から顧客側に責任を押し出しただけで、全体としては
なにも改善されていないだろう、と俺はいっている。

>で、突き放すだけではあれだから、別の方法についても提示しておくよ。
>ハーバードプレスの「隠れた人材価値」という本がある。
>http://www.amazon.co.jp/exec/obidos/ASIN/4798102245/ref=sr_aps_d_1_1/250-2897484-1399424
>リンクうまく行くといいんだけど。

ふむ。読んでみようかな。

>何でもかんでもＸＰでってのは無理さ。

俺の言いたいこともまさにそれだ。XPの考えはよいが、XPだけじゃ駄目だ。