いまさら聞けない要求管理の基本：みんなが悩む要求管理（1）

　「顧客の真のニーズを満たす」「高品質」「期間内」「予算内」という4つのキーワードが出てきますが、どれも要求管理と大きくかかわってきます。まず、「高品質」な製品を作るためには、要求管理において、信頼性やスループットといった製品の機能面以外の要求も確実に把握することが重要です。また、「期間内」「予算内」で製品を開発するには何が問題でしょうか？ プロジェクトは、時間と予算とリソースが制限された状態で製品を開発しなければなりません。与えられた時間、予算、リソースを用いてどれくらいの作業ができるか考慮して、製品の要求仕様の範囲を、作業が可能である範囲に抑えねばならないのです。

　QCD（Quality：品質、Cost：価格、Delivery：納期）というキーワードは非常によく用いられるため、“高品質の製品を、期間内、予算内に開発する”の部分は、皆さんも耳慣れていることでしょう。しかし、ここで特に注目していただきたいのは、“顧客の真のニーズを満たす”の部分です。どれだけ高品質な製品を予算内、期間内に作っても、顧客の真のニーズを満たしていなければ、その製品は無駄なものになってしまいます。

　例えば、営業員の事務処理を効率化するための業務用アプリケーションを作成するとします。このプロジェクトでは、高度なスキルを持った開発者が素晴らしい設計をし、拡張性も十分に考えられた業務用アプリケーションができました。しかし、その業務用アプリケーションがユーザー（営業員）にとって非常に使いにくいものであったため、営業員の多くが使うことを敬遠し、そのうちに、その業務用アプリケーションは自然消滅してしまいました。この製品は、“事務処理の効率を上げる”という顧客の真のニーズが反映されなかったのです。つまり、このニーズを満たすための要求（例えば GUIの使いやすさなど）が抜け落ちてしまったのです。残念ながら、こういったことはよくあるケースです。ここでは、“顧客の真のニーズを満たす”ができて初めて、プロジェクトは成功に導かれるということを強調しておきたいと思います。

　一方、データからも要求管理はプロジェクトの成功に大きく寄与することが説かれています。ソフトウェア開発現場の調査レポートとして著名な（Standish Groupの）CHAOS（2001年）レポートによると、プロジェクトの成功に寄与した要因のリストに、「ユーザーからの入力」「ビジネス目標を明確にする」「開発範囲を最小化する」「安定した要求項目」など要求管理に関することが上位を連ねています。また、プロジェクトの失敗要因のリストにも、要求管理に関することが上位を連ねています。このことからも要求管理の重要性を分かっていただけたと思います。

要求とは？ 要求管理とは？

　要求管理の具体的な中身について触れる前に、まず要求と要求管理の定義を見てみましょう。RUPでは要求と要求管理を下記のように定義しています。

　“要求”の定義は非常にシンプルです。要求を定義するとは、“システムが満たすべき様態や能力”を定義することです。いい換えると、「何を作ればよいのか」を定義しているといえますし、これはまた、プロジェクトの成功の基準を定義している、ともいえます。要求と一言でいっても要求にはさまざまな種類、レベルが存在しますが、要求の詳細な定義については次回以降に見ていきたいと思います。

　RUPにおける“要求管理”の定義で注目していただきたいのは、要求管理が扱う範囲の広さです。要求管理という言葉は、まず、“要求を引き出す”ことを含みます。“要求を引き出す”というのは、顧客やエンドユーザーから、システムに対する要望を出してもらうということです。通常、要望は簡単に出てこないので、さまざまな手法を使って引っ張り出すことになります。

　 次に、要求管理という言葉は“要求を整理する”ことを含みます。複雑なシステムになると、要求が数百件以上になるのは当たり前ですので、それらを整理する必要があります。そして、要求管理という言葉は“要求を文書化する”ことも含みます。普通の人はそれほど多くの要求を記憶することはできませんし、顧客と開発チームの間で要求を共有するためにも、文書化が必要となります。

　さらに、要求管理という言葉は、“顧客と開発チーム間の合意を形成し、保守する”ことも含みます。上記のように、“要求を引き出し、整理し、文書化する”ことができると、次は、それらの要求に対して、期間内、予算内に開発を終えるために、プロジェクトで扱う要求の範囲について顧客と開発チームの間で取り決めを行う必要があります。また、開発が進むにつれて要求変更が発生した際に、影響範囲を分析し、受け入れられるものとそうでないものに対して顧客と合意を形成することも大切なことです。

要求管理は簡単ではない

　2〜3人規模の小さなプロジェクトだと誰も要求に関して悩んだりしませんが、小規模なパッケージソフトウェア開発で数千件、大規模なプロジェクトになると数万件以上の要求を管理することになり、大規模になるにつれて要求管理においてさまざまな問題に直面することになります。以下に、プロジェクトで起こり得る典型的な問題を挙げています。

「要求を引き出すのが難しい」

　開発チームは、解決すべき問題を十分に理解せずに技術的な解決策を提供する傾向があり、顧客のニーズを満たしていないシステムを作り上げてしまうことが多くあります。そうならないために、顧客のニーズを引き出すことが重要ですが、顧客やユーザーと開発者の間には、異なる用語、バックグラウンド、動機、目的を持っているため、コミュニケーションのギャップが存在します。

「要求を体系化し整理するのが難しい」

　大規模なプロジェクトでは単純に要求の数が非常に多いため、扱うこと自体が難しくなります。また、これらの要求の出所も、ユーザーだけではなくシステムにより影響を受ける利害関係者（Stakeholder）は多岐にわたります。さらに、要求には多様な種類、レベルがありますし、さまざまな成果物と関係するので体系化が非常に困難です。

「要求を文書化するのが難しい」

　これは、要求が明確になっていない場合もありますし、単純に要求というものを言葉で表すのが難しい場合もあります。文書化するのが難しいだけでなく、品質の高い要求文書を書くにはレビューが欠かせませんし、要求変更した際に文書を更新していくのも手間が掛かる作業です。

「要求変更に追随するのが難しい」

　プロジェクトが進むにつれて、要求が進化し成長していって、プロジェクトのスケジュールと予算が計画を上回ってしまうことがあります。これは要求のクリープといわれる現象です。そもそもは顧客の頻繁な要求変更が原因ですが、開発チームの対応の仕方にも問題があります。要求変更の影響を分析ができず、顧客とうまく合意を取ることができない場合があります。また、要求変更を開発チーム全体で共有するのも簡単ではありません。

　以上、さまざまな問題を見てきましたが、これらの問題に適切に対処するためにも、要求管理に対して体系化されたプロセスが求められます。次回は、要求管理の具体的なプロセスに入る前に、要求の様々な種類、レベルについて見ていきたいと思います。