いつもお世話になります。
京装コンピューターの渡上です。
>
>プロジェクト全体をプロジェクトの早期に高い精度で見積もれないと
>意味がないのですが。
>プロジェクトが進行するにつれ見積もりの精度が上昇するのは、実績が
>増え、見積もるべき分が減少するのでウォーターフォールでもXPでも
>当然のことです。
下記の日経IT-Pro引用記事にもありますが、
>「ユーザーの要求通りのシステムをつくるな」，ユニクロやJTBなどの
>情報システム担当役員が檄
>http://itpro.nikkeibp.co.jp/free/NC/NEWS/20011015/3/
特に地方官公庁関連のプロジェクトだったりすると、ユーザの方ご自身
「〜らしい」の連続で、要求仕様自体がプロジェクト開始時に纏められ
なかったりします。
実際はお役所的スパンの問い合わせルーチンに基いて、ウォータフォール
的な開発工程で言いますと、詳細設計が上がり始めた頃から仕様が判明
しだしたりする事が多い（暗号や通信関係、その他いろいろ）事例も中
にはあり、公共道路工事のように最初から要求仕様が明確で、何をやるか
が全て具体的に決まっており、あらゆるQ/Aは要求仕様分析またはシステム
概略仕様の設計段階で９９％判明するプロジェクトばかりじゃない、と言う
事から書いた感想です。
業務上、大抵火を噴いた案件へファイアーマン的な参加をする事が多いの
で、上記の私がぶつかるケースなどは、初期設計段階でのパッケージング
の不徹底もさる事ながら、XP的なアプローチの一つである、先ず最もリス
クの高い事から実装して解決する−−ではなく、全体工期の問題もあって、
先ず手を付けられるものから開発していく−−的な開発トップ指導の存在
が、悪循環を繰り返しているケースもあるように感じます。
上記などは、KentBeck的なアプローチだと、本来契約すべきではない相手
の筆頭としてあげられるのかも知れませんが．．．
>
>プロジェクト全体の見積もりの精度だけなら、要求仕様を最初に
>決定してしまうウォーターフォールの方がXPより有利でさえあります。
>
そんな訳で、硬直した開発体制の場合は、ウォーターフォールは決定的に
不利であるように感じる部分もあるな、と個人的に思っています。
が、こちらは私ごときが、判定できる内容ではありません。
ただ、ユーザへの提案時か？に、御用聞き的な対応から、理想要求仕様
的な提案対応を行えるほどスキルが身につけば、仰る通りなんだろうな？
と同意する部分が私自身の中にあります。
>XPは、見積もりの精度を高めることを狙った手法ではなく、不正確な
>見積もりでもプロジェクトが破綻しないことを狙った手法だと私は
>認識しています。
それで結局は濱井さんが仰っておられる事とイコールであるのですが、
開発担当への着手時期への違いから、私などのようにファイアーマン
的な業務が多いものにとっては、後工程で要求仕様が判明した段階で、
如何に全体への変更を伴わずに、適正なシステム構成への変更を行い
得るかに有効な手法として着眼していたります。
＃もちろん、改善用のモデル分析なども、有効な手段ですよね。
まだ、勉強中の身なので、勘違いなどありましたら、ビシビシご指摘
下さい。
＃前回の私の投稿で、お気を悪くされた部分がありましたらすみません。
以上