要件定義という虚構

日経コンピュータに「要件定義技術」
というキーワードが載っていました。

某大手SIベンダーが取り組みを行っており、要件定義の専門家を養成するとのことでした。

この記事に対して、システムの要件定義に関する持論をひとつ述べたいと思います。

まず、ウォーターフォール開発の場合、
システム発注の段階で顧客は発注するシステムに関する要件
はっきりしていることが前提となっています。
システム屋の仕事は、それを聞き出し、書きならべることで、
いかに「漏れをなくすか」ということに重点が置かれています。

不可能です。

不可能以前に、前提条件が破たんしています。
「システムに関する要件がはっきりしていること」
なんていう前提は、
絵の中のトラをお殿様が追い出してくれたら」と言っているのと等しいのです。
それどころか、
システムに関する要件がシステム開発前に存在している」ことですら、
あり得ないことだと断言できます。

ちなみに、要件の存在有無については、議論の分かれるところかもしれませんが、
ことの本題から外れますので、本当はどっちでもよいのです。
大切なことは、
「システム開発時点では、全ての要件を手に入れることは不可能」
ということを前提に話を進めることです。
数学界では、虚数の導入に際して激しい議論があったと聞きます。
確かに、理解の範疇を超える概念のため、
その存在を素直に受け入れることが難しかったことは想像できます
しかし、虚数を使ったほうが、あれこれ計算をするのに便利だったため、
結局は受け入れられることとなりました。
また、量子論についても同様に、
アインシュタインは最後までその存在を否定し続けました。
しかし、その計算結果は驚くほど正しかったのです。

余談が長くなりましたが、この場合も、
システム要件は存在しない」
と確定してしまったほうが、開発がスムーズに進むということが言いたいのです。

存在しない物に対して、「専門家」というのも馬鹿げていますよね。

うまくいくはずがないと思います。

要件は、常に変化し、追加されます。これは、事実であり真実であり、現実であり、実績値です。
どんなに否定しようとも、クラアントを馬鹿にしようとも、憤慨しようとも、泣いてもわめいても、
どんなプロジェクトでも必ず発生します。

当初決まっている要件ですが、筆者の経験を元にざっくり言うと、
良くて7割ぐらいです。
半分も固まっていれば良いほうだと思います。3~4割が普通なんじゃないでしょうか。

世のシステム開発会社は、その3~4割を100%として要件定義し、契約を結びます。
これでシステム開発がうまくいくわけがないですよね?
要件だけでも、2~3倍に膨らむわけです。開発中に。
それ以前に、当初の要件分を開発するだけでも、
中間マージンを取られたり、ダメな技術者やマネージャが居たり、
そもそも営業が信じられない値引きをして受注してきたりで、アップアップしているわけです。

システム屋さんの苦悩が目に浮かびます。

そんな惨憺たる状況の中ですので、
開発要件が変わることは絶対に避けたいと思うのは当然のことだと思います。

でも、それが一番の罠なのです。


無いものねだりです。


前提条件が間違っているのです。


ありもしない要件を確定するために心血を注ぐぐらいなら、同じパワーを使って、
「変化する要件に対して、いかに効率的に追従していけるか?」
という命題の解決にリソースを割いたほうが、はるかに有意義で効率的です。
そして、この方法は必ず成果が表れます。

効率的なプログラミングツール、言語、データベースを使い、可能な限り作業を自動化し、
スモールスタートで徐々に拡張していくような開発手法をどんどん取り入れていくことです。
注意してほしいのは、
要件ありき」で進めたのでは、どんな方法でもうまくいかないということです。

要件が確定していない」ところからスタートして、いかに素早く要件を"作りこむ"か?

失敗しないシステム開発のコツは、この一点です。
簡単なことです。
拍子抜けするほど単純なことが、案外一番大事なことだったりするのです。


さらに余談

システム開発に要件が存在しない」ことを実感する、簡単な方法があります。
それは、自分のために、自分が必要なシステムを作ってみることです。
自分自身がクライアントなんだから、要件を聞き出す」必要がないので、
コミュニケーション能力も業務知識も必要ありません。

ハンディ0です。

要件定義が存在するが聞き出せないだけ」が事実なら、
100%成功するプロジェクトとなるはずです。

が、

うまくいきません。
うまくいかないのです。自分自身がお客様なのに。

なぜ?

開発前に、要件が存在しないからです。

またまた経験則ですが、
当初予定していた機能の3倍ぐらい作りこまないと、満足に動作するシステムは作れません。
本当に使いやすいシステムとするためには、さらに3倍。
当初見込みの10倍は、パワーが必要になります。

これが現実なのです。