要件定義という虚構
日経コンピュータに「要件定義技術」某大手SIベンダーが取り組みを行っており、
この記事に対して、
まず、ウォーターフォール開発の場合、
システム発注の段階で顧客は発注するシステムに関する要件が
はっ
システム屋の仕事は、それを聞き出し、書きならべることで、
不可能です。
不可能以前に、前提条件が破たんしています。
「システムに関する要件がはっきりしていること」
なんていう前提は、
「
それどころか、
「
あり得ないことだと断言できます。
ちなみに、要件の存在有無については、
大切なことは、
「システム開発時点では、
数学界では、虚数の導入に際して激しい議論があったと聞きます。
その存在を素直に受け入れることが難しかったことは想像できます
しかし、虚数を使ったほうが、
また、量子論についても同様に、
余談が長くなりましたが、この場合も、
「
と確定してしまったほうが、
存在しない物に対して、「専門家」
うまくいくはずがないと思います。
要件は、常に変化し、追加されます。これは、
どんなに否定しようとも、クラアントを馬鹿にしようとも、
どんなプロジェクトでも
当初決まっている要件ですが、筆者の経験を元にざっくり言うと、
世のシステム開発会社は、その3~4割を100%
これでシステム開発がうまくいくわけがないですよね?
要件だけでも、2~3倍に膨らむわけです。開発中に。
それ以前に、当初の要件分を開発するだけでも、
システム屋さんの苦悩が目に浮かびます。
そんな惨憺たる状況の中ですので、
開発要件が変わることは絶対に避けたいと思うのは当然のことだと
でも、それが一番の罠なのです。
無いものねだりです。
前提条件が間違っているのです。
ありもしない要件を確定するために心血を注ぐぐらいなら、
「変化する要件に対して、
そして、この方法は必ず成果が表れます。
効率的なプログラミングツール、言語、データベースを使い、
スモールスタートで徐々に拡張していくような開発手法をどんどん
注意してほしいのは、
「要件ありき」で進めたのでは、
「要件が確定していない」ところからスタートして、
失敗しないシステム開発のコツは、この一点です。
簡単なことです。
拍子抜けするほど単純なことが、
さらに余談
システム開発に「要件が存在しない」ことを実感する、
それは、自分のために、
自分自身がクライアントなんだから、「要件を聞き出す」
ハンディ0です。
「要件定義が存在するが聞き出せないだけ」が事実なら、
100%
が、
うまくいきません。
うまくいかないのです。自分自身がお客様なのに。
なぜ?
開発前に、要件が存在しないからです。
またまた経験則ですが、
当初予定していた機能の3倍ぐらい作りこまないと、
本当に使いやすいシステムとするためには、さらに3倍。
これが現実なのです。

