多くの企業では、これまで企業の成長に合わせてシステムの拡張・再構築を繰り返しながら経営環境の変化に対応してきた。しかし、企業の売上が伸び悩むなかで、そのような「継ぎ足し方式」の開発で肥大化したシステムが重荷となり、さらにIT投資を追加的に実施する余力もなくなってきた。そこで事業再編やリストラなど企業内組織を最適化する動きとともに、システムに対しても最適化する動きが活発化している。無駄がなくスリムで長持ちするシステムが、経営から強く求められるようになっているのである。

　継ぎ足し方式のシステム開発は、どちらかと言うと“どのように”システムを作るかに力点が置かれる。システム構築の手法や設計書の構造もそれを前提に練り上げられてきた。これに対して、無駄がなくスリムで長持ちするシステムを構築するためには、今まで以上に“なぜ”システムを作るのかを正確に定義することが前提となる。そしてシステム開発プロジェクトのメンバーがつねに現場業務の要求を蓄積・共有し、それに基づいてシステムの設計・開発・保守を実施することがより重要であると考えられてきている。

要求工程に対する誤った“常識”

　現場業務の要求をシステムに確実に反映させるために、これまでJAD（Joint Application Development：利用者と開発者の合意を得ながら開発していく方式）やCASE（コンピュータ支援によるソフトウェア工学）技術など、多くの工夫が試みられてきた。しかしそれらは、成果を実感するよりも適用に苦労するケースのほうが多かった。

　その結果、「現場の要求とはそもそも曖昧なもので、明確に定義して記述するのは困難。人の頭の中でしか管理できない」とか、「現場の要求の精度は業務知識や専門知識、コミュニケーション能力など個人の能力によるもので、手法で解決できる代物ではない」と言われてきた。

　たしかに、要求工程（ソフトウェアに対する要求をまとめる工程）の品質はその多くを属人的な能力に依存する部分がある。たとえば、意思決定の不備、コミュニケーションの欠如、問題解決力の不足、分析力の不足、顧客との連携の不備、リーダーシップの欠如などがあっては、現場の要求を確定していくことはできない。このように、品質を決定する要因が個人の能力のみであるという「常識」にとらわれていたため、個人の能力を最大限に発揮する手段を工夫する余地が認識されず、軽視されてきたのである。

　野村総合研究所（以後、NRI）では、要求工程において個人にその能力を最大限に発揮させる手法について研究を実施してきた。その結果、「要求の構造化」とそれをベースにした「要求の開発」と「要求の管理」が、要求工程の品質、ひいてはプロジェクトの品質に影響する可能性が大きいことを確認している。

カギを握る「要求の構造化」

　要求に関する工程は、大きく2つの段階に分けられる。1つは、現場業務の要求を明確化し、分析、検証して一定の品質の要求を定義する「要求開発」であり、もう1つは、定義された要求とその後の変更内容、他の設計成果物との関連性を管理する「要求管理」である（図1参照）。この両者を共通の基盤の上で密接に関連づけるのが「要求の構造化」である。

（クリックで拡大表示）

　「要求の構造化」とは、業務のレベルからシステムの仕様のレベルまで、システムへの要求をいくつかのレベルに分けて定義し、その相互の関係性を構造としてとらえることである。あるべき「要求の構造」は、業務内容などによって異なるもので、1つの種類に限られるわけではない。しかしいずれの場合も、システム使用者が「自分の業務でシステムに支援してほしいこと」を明らかにし、さらにそれを「システム化したほうがよいこと」に具体化・詳細化したものが、要求の基本構造となる。

　たとえば、システムの構想、新業務のイメージが出来上がった段階で業務設計を実施し、「システムに支援してほしいこと」を業務要求として定義し、それに紐付けながら、「システム的に実現すること」をシステム要求として定義する。さらに、システム要求を実現する上で必要な処理内容を「ソフトウェア仕様」として、システムの機能の大まかな単位と紐付けながら記述する（図2参照）。