開発するソフトウェアの発注内容に矛盾が含まれることがあります。びびる話ですが、残念ながらあります。モレがあるなんてことは、当然のように起こります。
ここで僅かなサンプルから、ものすごい一般化をしますが、日本では発注者がクソである、という仮説があります。ありますって、勝手にいまでっちあげたんですけど。大規模検査/管理システムを構築するメーカの人曰く「ドイツの会社は数百ページにわたる要件定義書を渡してくる。同じようなシステムに対して日本の会社は3ページくらいで済ませてくる」と。日本の発注者、というような集合に共通の特性があるわけあらへんやろう、という感じではありますが。けれど、私の観測範囲では SI の委託側と受託側の互いの期待がずれているために、不幸が起こっているように見えるのです。そして、発注側がけっこうクソなんじゃないのか、って感じがするのです。
SIer に仕事をたのむのは、何らかの事情で自分たちができないからです。時間とか、外注のほうが安いとか、技術がないから、とか。まあ、いろいろあるでしょう。そして、発注側に技術や能力や機能がないとき、発注側が要件定義できない場合、ということがあり得るのです。それはべつに構わない。
問題は、発注する側が (1) 要件定義できていないことを自覚していない、とか (2) 要件定義のコストを負担する気がない、ときです。 (1) が真のとき、当然 (2) も真になります。何が欲しいかを合意することなく、開発が進むと、当然、コレジャナイみたいな展開になるわけです。
もう、こんなことさんざん議論されていることなのですが、未だに、こんなことが起こっているような気がします（ソースは脳内）。SIer に指摘してもらうとか、コンサルしてもらうとか何でもいいけど、発注者はなんらかの形で、要件定義のコストを負担しなければいけないと思っています。伝わったことが伝えたことなのです。要件定義にOKを出すことができるのは、発注者しかいない。ここから次のことが分かります。
1. 発注担当者には要件定義の責任がある
2. 責任を果たさない奴はクソである
3. 私はクソである
たぶん一発で要件定義をすることは難しいでしょう。オンラインのサービスなら、なおさら。であれば、システムの稼働中や開発中に要件定義が変更になる、というのは、組み込んで置かないといけない。と、むりやりアジャイルな話に持って行ってみたり。
