要求定義における“品質”確保の方法：ビジネスサクセスのための“情報システム品質”（2）（1/2 ページ）

　ところが現在の情報システム開発では「要求定義」が非常に難しいものになっています。これは、情報システムがいまや業務基盤化し、会社にとっての経営戦略そのものとなっており、そのため要求＝業務として実現したいこと──がビジネス上の競争の激しさを反映して多様化・複雑化していることが大きな理由です。

　もともと「要求定義」という活動は、“正しい要求がすでに存在している”ということを前提に行われていました。例えば、会計システムの開発であれば、会計処理の手続きやルールはすでに決まったものがあって、それをコンピュータ化したい、というようなものが「要求」だったわけです。

　ところが今日の要求定義は、顧客や市場の変化への対応やITによるイノベーションなどを指向しているため、新たな業務のやり方やルールを定義したり、データ処理の方法を考えたりといった活動を前提にしています。ビジネス上の「やりたいこと」を“正しく”書き表すことが“品質”の高い要求定義だとしたら、「やりたいこと」が固定的ではない今日の要求定義は“正しさ”さえ見えない、そんな状態になっているといえるかもしれません。

　その一方、「要求定義」は「開発」よりも前の工程なので、ここでの成果物（要求仕様）の品質が低いと、後工程（開発・実装）の品質がいくら高くても、最終製品の品質を高くすることはできません。つまり、その要求定義の段階で“品質”が決まってしまうという状況なのです。ここでいう品質とは「実装品質」ではなく、いわゆる「狙いの品質」と呼ばれているものです。

　情報システムの開発には、もう1つ特徴があります。コンピュータ・システム──特にソフトウェアは、作っている途中で内容の確認をすることができません。どれだけ作業が進んでいるか、進ちょくの確認はできます。画面をちゃんと表示するとか、計算が合っているかといったソフトウェア部品ごとに動作確認も可能です。しかし、そこで定義された「要件」がそもそも妥当なものであったかどうかは、情報システム全体を動かしてみなければ確認できません。

　「要件定義」は通常、ユーザー企業の業務部門が行います。開発者が業者だとすると、発注者（お客さま）です。「○○を作ってくれ」と発注しても、その○○が“妥当”かどうかを確認できるのは開発が終わった後、利用者や情報システム運用者が行う、いわゆる運用テスト段階以降です。要件定義を誤った場合、もう一度要件定義からやり直さなければなりません。

図表1　開発者に技術力があれば、険しい山にも登ることができる。しかし要件定義を誤れば、違う山に登ってしまう

　開発者がどれだけ要求定義どおり“正しく”開発したとしても、要求自体が“正しくない”場合には、ビジネスに役立つ“品質”の高い情報システムは完成しません。この利用者＝発注者の要求の“品質”が確保できなければ、情報システムの“品質”も確保できないということです。つまり、ユーザー企業における発注力＝要件定義力の強化が極めて重要だということです。

ビジネス構想は、完全に定義し得ない

　要件自体の品質を高めるためには、まず第一に、正しい要求、すなわち利用者や顧客のニーズを把握することが必要です。それでは、要求自体の品質をどう高めればよいか考えてみましょう。例えば、要求が具体的であれば、“正しい要求”といえるでしょうか？

　ビジネスで実現したい「現実の世界」はあいまいで複雑なものです。硬直化した「要求」では、将来あり得る変更に対応ができなくなることに留意すべきです。

　つまり、ビジネス構想とはもともと完全なものとして定義し得ないということを認識して、変更への対応を考えておくことが重要です。そのためには、ビジネス構想の「目的」を明確にしておく必要性があります。

　ビジネス構想の目的が明確であるということはどういうことでしょうか。これは、経営戦略・ビジネス課題を可視化することで、情報システムを通じてユーザー企業が提供できる価値を明確にすることです。

　そこで、「要求」は情報システムが実現するビジネス構想、つまり業務そのものを分析することによって、ロジカル（論理的）に開発されるべきだというアプローチが登場しました。これが「要求開発」です。要求開発については、以前にも紹介したOpenthologyが大変参考になると思いますので参照してください。

品質を決定する鍵は、RFP

　JUAS（日本情報システム・ユーザー協会）の「ユーザ企業IT動向調査2004」に、日本企業のシステム開発の驚くべき実態を見ることができます。『提案依頼書（RFP）における役割分担』に関する質問に対して、「RFPは、ほとんどユーザー企業が作成している」と答えたユーザー企業は全体の16％（回答総数653社）にすぎないというのです。

　「ベースはユーザー企業が作成し、細部の作成はベンダに委託」と答えたユーザー企業は33％、「ラフなRFPはユーザー企業が作成、あとはベンダに委託」と答えたユーザー企業は41％、「RFPはすべてベンダが担当」と答えたユーザー企業は9％でした。つまり、全体の半数がベンダに依存しているのです。

　また同調査によると、『発注者としての反省点』の中で一番多かったのは、「システム仕様の定義が不十分なまま発注」、次に多かったのは「発注者にRFPを明確に提示しなかった」という結果が出ています。

　これらが示すとおり、RFPはユーザー企業にとって情報システムの開発前における「品質を決定する鍵」であることは間違いないようです。