Index: [Article Count Order] [Thread]

Date:  Fri, 17 May 2002 08:04:19 +0900
From:  HAMAI Kyoichi <k-hamai@....com>
Subject:  [XP-jp:03462] Re: FYI: [NOS]	仕様変更に打ち勝つ
To:  extremeprogramming-jp@....jp
Message-Id:  <iss.1e01.3ce43af4.94e95.1@....com>
In-Reply-To:  <20020514224518.ABC9.AKASAKA@....jp>
References:  <20020514224518.ABC9.AKASAKA@....jp>
X-Mail-Count: 03462

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

>> ふと思ったんですが。
>> 顧客は自分たちの要求をかなえて欲しくて金を払うわけですから、顧客の要求
>> を拒否する仕様凍結が当然だというような考え方は何か根本的に間違っている
>> と思います。
>
>意外な意見だったので少し考えてしまいました(^^;;
>改めて読み直してみたのですが、確かにある部分では要求を拒否するところも
>あるのかも知れませんね(引き算、あるいは中抜きと書かれたところ)。

私が書いたのは、記事の批判というよりもウォーターフォール一般への批判
になります。
納期が長かろうと短かろうと、ウォーターフォール型の開発では仕様をある
時点で固定してそれ以降の要求の追加、変更は拒否することになります。
仕様通りに開発されても、必須の機能が抜けていて顧客にとっては開発の意味
が無いというようなケースが起こり得ます。

必要な機能を要求し損ねた顧客の責任だというような考え方もできますが、
コミュニケーションの失敗はほとんどの場合双方にそれなりの原因がある
ことを考えると、顧客だけが責任を負うというのは不公平でしょう。また、
ビジネス的にもまずいやり方です。
# 現実には、顧客は仕様の全責任を負うほど弱い立場ではありませんが……。


仕様通りに開発するという観点からは、仕様の固定は早ければ早いほど良い
でしょうが、顧客の満足を高めるという観点からは、仕様の固定は遅ければ
遅いほど良いことになります。
イテレーション型ならウォーターフォール型の失敗が完全に防げるというわけ
ではありませんが、その確率は下げることができます。


ウォーターフォール型の開発が生き延びてきたのは、顧客の満足を高めること
より、仕様通りに開発することが重視されてきたことに一因があるように
思えます。