The Dragon Scroll

Be just and fear not.

要件定義が失敗する理由。

最近、要件定義の仕事をしているので、要件定義系の本を良く読む。
たいがい、「要件定義は難しい。」という。
その理由として、以下のようなことをあげる。
−要求は言葉で正確に表現することはできない。
−要求はすべて伝えることができない。
−要求は変化する。
−要求はお客様の中でも立場によって異なる。
−要求は無制限に出てくる。
−要求は前後の関係で矛盾する。
−要求が何であるか開発側は分からない。
−要求が何であるかお客様も分からない。

ここまで来たら、「本当に何も分からないじゃないか。
要件定義なんてする意味があるのか?」と
問いたくもなるが、実際、要件定義は上記のような状況に
陥る。


SIerがなれない要件定義に失敗して、プロジェクトの頭から
こけて、火を噴くなんて話は、この業界、いくらでも
転がっていることだろう。
どういうプロジェクトであれ、要件定義が上手く行くという
現実感がなかなか感じられないのはなぜだろう。


そこで、アジャイル開発ですよ。

ドキュメントベースの要件定義なんて、上手くいくはずないじゃない。
動くモノをとっとと作って、客に見せて、
フィードバックを得て、旨いシステムを漸次的に作りこんでいくのが現実的ですよ。


確かにそうかもしれない。
ただし、要求には複数の段階がある。
それは、顧客の経営層が要求する、Whyをあらわすための要求と、
顧客側のシステム構築を担当する情報システム部門
要求する、Whatをあらわすための要求だ。
−なぜ、このシステムを構築するのか?
−なぜ、そもそもこのプロジェクトを立ち上げたのか?
が生み出す要求と、
−何が、このシステムでできなければいけないか。
−このシステムで、ユーザは何をするのか。
が生み出す要求の間には大きな隔たりがある。
前者の要求がぶれているプロジェクトでは、
いくら漸次的だろうが、イテレーティブにやろうが、
開発はいつまで経っても終わらないだろう。