前回，要求開発がもたらす恩恵の一つとして，システム開発の生産性が向上することを挙げた。生産性が向上すると考える理由は，要求開発がシステム開発の成果物の「基礎となる成果物」を作成していることにある。基礎となる成果物とは，具体的に言うとビジネス・プロセス・モデルと概念モデルである。これらがシステム開発の成果物に対して距離的に近いものであるなら，手間が省けるぶんだけシステム開発の生産性は向上するはずだ。
しかしながら，前回説明したように，この「省力化」の効果を単純に期待するとプロジェクトは失敗する。その背景には，(1)要求開発モデルに記述するべき情報の基準がない，(2)要求開発モデルを活用するツールがない，(3)完全な要求開発モデルを作成する時間がない，という3つの問題がある。以下ではこれらについて考えてみよう。
(1)要求開発モデルに記述するべき情報についての基準がない
要求開発モデルには，何をどこまで詳細に記述するべきか，明確な基準がない。システム開発側が必要とする情報を提供できる保証がないのである。これは，システム開発側から見ると，何を要求開発モデルから継承できるのか分からないことになる。そうなると，システム開発側としては「面倒だからもう一度やろう」ということになり，要求開発のときと比べて少しだけ「システム寄り」になったビジネス・プロセス・モデリングや概念モデリングを再度行うことになる。これでは，省力化どころか2度手間である。ユーザーとしては迷惑な状況だ。
ところで，読者の中には「モデルに何をどこまで詳細に記述すべきか分からない」という状況が，ピンと来ない方もいらっしゃるかもしれない。簡単な例を挙げてみよう。書籍を扱う情報システムでは，まず間違いなくISBNコードを取り扱うことになる。ISBNは，世界中の書籍やCD-ROMを一意に識別するためのコードで，ISO（国際標準化機構）が定めているものだ。当然長さも決まっている。
では，ISBNコードの長さ（現在は10ケタ）がユーザーから得られたとして，これは要求開発モデルが提供するべき情報なのだろうか。要求開発担当者としては「データベースのフィールド長に関する情報は，システム開発の段階で調べることだ」などと判断するケースが多いかもしれない。それはそれで良いのだが，それならそうすることを事前にどこかで宣言するべきである。
図1[拡大表示]に，3人のモデラーによる3通りの書籍クラスモデルの例を示す。Aさんは単純に書籍クラスの属性名だけを記している。Bさんはもう少し詳しく，著者名が複数になり得ることを示している。Cさんは，書籍コードがISBNという型になることを示し，ISBNについては別途ノート形式で補足している。このように，同じUMLを用いてもある程度の違いが生じるのは避けられない。システム開発側に対して一定品質の情報を提供するのは簡単なことではないのである。
 図1 3人のモデラーが作成した3通りの書籍クラスモデル Aさんのモデルは属性名だけを記しているのに対し，Bさんのモデルは著者が複数になる可能性を示している。CさんのモデルはISBNが型になることを示し，ISBNについてノートで補足している。 [画像のクリックで拡大表示] |
(2)要求開発モデルを活用するツールがない
要求開発モデルに盛り込むべき情報の基準と，その基準に従った情報が得られたとしても，それを有効に活用する手段がなければシステム開発の生産性は向上しない。要求開発モデルが提供する情報は，システム開発の様々な場面で役に立つ可能性がある。例えば，先のISBNの文字列長に関する情報は，画面のフィールド長，各種の関数やメソッドが持つパラメータの型，データベースのスキーマなどを決める際に役立つはずである。
しかし，こうした情報が必要なときにすぐ得られるようにするためには，単に「要求開発モデルのどこかにISBNコードに関する情報がある」というだけでは不十分だ。また要求される情報の形式も様々である。あるときはExcelシート，またあるときはXMLファイルと形を変えて出力しなければならない。
このような作業を効率よく行う，つまり，冗長性の低いモデルから必要な情報を導出できるようにするためには，使いやすいツールが必要となる。このようなツールがあってこそ，要求開発の成果物はシステム開発側から歓迎されることになる。
(3)完全な要求開発モデルを作成する時間がない
要求開発モデルの基準やツールがあったとしても，時間がないことがある。要求開発のような上流工程は，リソースが少なめにしか与えられないのが一般的なので，頻繁に直面する問題と言える。ここで言う「完全」は，素晴らしいとか非の打ちどころがないといった意味ではなく，「完了している」ということだ。例えばユースケースが100個あるのに，そのうちの80個しか抽出していないビジネス・プロセス・モデリングは完全とは言えない。同様に，残りの20個のユースケースに登場する概念がモデル化されていなければ，その概念モデリングは完全ではない。
この(3)は(1)とよく似た問題だが，両者には明確な違いがある。それは，(1)が質に関する問題であるのに対して，(3)が量に関する問題である点だ。量の問題は一般にリソースの投入によって解決を図ることができる。そのため，完全なモデルを要求開発段階で作成する必要はなく，より多くのリソースが許されるシステム開発段階まで先延ばしにするという考え方もあり得るように思う。この点については，次回以降にもう一度触れる。
次回は，前回述べた2つの手段，つまり「モデルによる工程間連携」と「フロント・ローディング」によって，これらの問題がどのようにして克服できるかを解説する。
| （依田 智夫＝要求開発アライアンス理事） |
