こんにちは、濱井さん。
赤坂です。
濱井さんの意見にほぼ賛同しますが…
On Fri, 17 May 2002 08:04:19 +0900
HAMAI Kyoichi <k-hamai@....com> wrote:
> 私が書いたのは、記事の批判というよりもウォーターフォール一般への批判
> になります。
> 納期が長かろうと短かろうと、ウォーターフォール型の開発では仕様をある
> 時点で固定してそれ以降の要求の追加、変更は拒否することになります。
> 仕様通りに開発されても、必須の機能が抜けていて顧客にとっては開発の意味
> が無いというようなケースが起こり得ます。
>
> 必要な機能を要求し損ねた顧客の責任だというような考え方もできますが、
> コミュニケーションの失敗はほとんどの場合双方にそれなりの原因がある
> ことを考えると、顧客だけが責任を負うというのは不公平でしょう。また、
> ビジネス的にもまずいやり方です。
> # 現実には、顧客は仕様の全責任を負うほど弱い立場ではありませんが……。
おそらく一般的なウォーターフォールではそう実践されてしまうケースが多いの
でしょうが、それは"変更管理"が行われていないせいではないでしょうか。
ウォーターフォールであっても
きちんと要求仕様がまとめられていれば、開発中であっても顧客の変更の要求は
受け付けられると思います。
もちろん、その時点で変更のリスク(開発工数、スケジュール等へのインパクト)
をきちんと検討することで、変更を"認める"または"認めない"判断が出来るはず
です。
おそらく、変更管理ができていないので、変更による影響が分からないのではな
いかと思います。
# 単に理想論といってしまえばそれまでですが…
>
> 仕様通りに開発するという観点からは、仕様の固定は早ければ早いほど良い
> でしょうが、顧客の満足を高めるという観点からは、仕様の固定は遅ければ
> 遅いほど良いことになります。
> イテレーション型ならウォーターフォール型の失敗が完全に防げるというわけ
> ではありませんが、その確率は下げることができます。
個人的には、繰り返し型の場合、イテレーションでの失敗を次で挽回できる余地
があるといったほうが正しい気がします。
> ウォーターフォール型の開発が生き延びてきたのは、顧客の満足を高めること
> より、仕様通りに開発することが重視されてきたことに一因があるように
> 思えます。
まず仕様ありき、といったお役所的な考え方ということですよね。
それもありますね(^^;;
ではでは。
--
Hidehiko AKASAKA <akasaka@....jp>
Object Technology Center, OGIS-RI Co.,Ltd
// メールアドレスが変わりました(tyo.otc ⇒ tk-bay)