ユーザ企業における要件定義の難しさ

ユーザ企業においてシステムを構築する場合、そのシステムの要件定義はユーザ企業の情報システム部門でとりまとめるのが、本来の姿だが現状はなかなかそうなっていない。

１０年以上前から大手ユーザ企業の情報部門は情報子会社として独立させた企業が多く。情報システム部門は非常に人数が少なくなっている。そこに来て何十年も前からのシステムが山のようにあり、それらの保守も行わなくてはならなくなっている。

保守といっても実際に手を動かすのはパートナー会社なので、情報システム部門の人間がプログラムをいじることは無い。したがって個々のシステムがどのような仕様になっているかのは基本的に把握していないことが多い。

その山のようにあるシステムもオープン系のシステムの場合はハードウェアやミドルウェアなどのプラットフォーム・のサポート切れなどで、数年おきにシステムを更新する必要がある。

そのシステムを更新するための要件定義をどのように行うかが問題になっている。

通常はSIerに丸投げして要件定義も任せてしまうケースが多いが、仕様の最終決定はやはりユーザ企業が行わなければならず、丸投げといえど完全に任せきりに出来るはずもない。

更新案件の場合の一番の問題は丸投げにしてしまうと、新しい機能を入れることがほとんどのケースにおいてできないのである。

　１．更新案件なのでそんなに多くの予算を確保できない。
　２．プラットフォームが変わっているので、ほとんどのケースにおいて新規開発になる
　３．既存の機能はそのまま維持しないといけない
　４．新しい機能を従来の機能と整合性を取ったまま追加する必要がある
　　　　〜〜

これらのことをクリアするための要件定義が必要になるのである。

私は２０年近くオブジェクト指向でシステム開発をしているので、この要件定義にもUMLを使った方法を提唱している(http://http://www.vsa.co.jp/consul/1)。

この手法を顧客の状況に合わせてカスタマイズしながら短期間に要件定義する文化を育てている。
しかし、この文化を育てることが非常に難しい.....