Index: [Article Count Order] [Thread]

Date:  Mon, 20 May 2002 14:59:00 +0900
From:  HAMAI Kyoichi <k-hamai@....com>
Subject:  [XP-jp:03473] Re: FYI: [NOS]	仕様変更に打ち勝つ
To:  extremeprogramming-jp@....jp
Message-Id:  <iss.4ad3.3ce890a4.f22a3.1@....com>
In-Reply-To:  <20020517094702.6EB6.AKASAKA@....jp>
References:  <20020517094702.6EB6.AKASAKA@....jp>
X-Mail-Count: 03473

濱井です。
2002/05/17 09:52:52 +0900にakasaka@....jpさんが送られた
メールに関する返信です。

>> 納期が長かろうと短かろうと、ウォーターフォール型の開発では仕様をある
>> 時点で固定してそれ以降の要求の追加、変更は拒否することになります。
>> 仕様通りに開発されても、必須の機能が抜けていて顧客にとっては開発の意味
>> が無いというようなケースが起こり得ます。
>> 
>> 必要な機能を要求し損ねた顧客の責任だというような考え方もできますが、
>> コミュニケーションの失敗はほとんどの場合双方にそれなりの原因がある
>> ことを考えると、顧客だけが責任を負うというのは不公平でしょう。また、
>> ビジネス的にもまずいやり方です。
>> # 現実には、顧客は仕様の全責任を負うほど弱い立場ではありませんが……。
>
>おそらく一般的なウォーターフォールではそう実践されてしまうケースが多いの
>でしょうが、それは"変更管理"が行われていないせいではないでしょうか。
>
>ウォーターフォールであっても
>きちんと要求仕様がまとめられていれば、開発中であっても顧客の変更の要求は
>受け付けられると思います。
>もちろん、その時点で変更のリスク(開発工数、スケジュール等へのインパクト)
>をきちんと検討することで、変更を"認める"または"認めない"判断が出来るはず
>です。

検討するだけでも工数がかかります。変更要求が続出すると変更しなくても
それだけで作業が大きく遅れることになりかねません。