要求管理のプロセスを追跡する(1)システムが解決すべき問題を整理するみんなが悩む要求管理(3)

 前回「ソフトウェア要求の詳細な分類」は、要求の分類分けをテーマに取り上げました。今回 から 、要求管理プロセスの流れを見ていきたいと思います。

» 2004年10月29日 12時00分 公開
[玉川憲,日本IBM]

 本連載で取り上げているRUP(Rational Unified Process)は反復型の開発プロセスです。反復型開発では、業務分析、要件定義、設計、実装、テストといった一連の作業を、順を追って一度だけ行うのではなく、何度か繰り返すことで開発を行います。この一回の繰り返しを “反復 ” と呼びます。ただし、単純に同じように繰り返していくわけではなく、プロジェクト全体での時期に応じて、重要な作業を重点的に行います。例えば、プロジェクトの初期の反復では、業務分析、要件定義が重点的に行われ、プロジェクトの後半の反復になると主に実装が行われます。

 つまり、反復型開発における要求管理プロセスは、1つのプロジェクト内でもその時期に応じて形を変えながら繰り返していきます。というわけで、反復型の要求管理プロセスを正確に追跡するのは非常に骨が折れるのですが、今回は要求管理プロセスの全体像を理解することを目的としているので、ひとまず反復のことは忘れてください。要求管理プロセスの流れをばっさりと単純化し、要求管理の6つのスキルとして、前から順に説明していきたいと思います。

◆ スキル1: 問題の分析 (第3回)
◆ スキル2: 利害関係者のニーズの理解 (第3回)
◆ スキル3: システムの定義 (第4回)
◆ スキル4: システム範囲の管理 (第4回)
◆ スキル5: システム定義の詳細化 (第5回)
◆ スキル6: 要求変更の管理 (第5回)

スキル1 問題の分析

ALT 図1 要求のピラミッド 「問題の分析」

 図1は“要求のピラミッド” と呼ばれ、RUPにおける要求管理手法の全体像を説明するのによく用いられます。

 「スキル1 “問題の分析”」では、解決しようとしている問題の説明について、顧客と合意をとりつけます。

 まず注目していただきたいのは、右上の問題領域と書いてある雲の部分です。作成するシステムに対して要求を決める前に、まず作成するシステムが解決すべき問題が何であるかを考えなければなりません。そうしないと、利害関係者のニーズを満たすシステムを作成するのは難しいからです。

 この問題領域は、例えば、競合他社との競争に打ち勝つために業務用アプリケーションを導入したい人々の領域であり、開発チームと比べると技術的、経済的背景の違う人々の世界です。そのため、ちょっと霧のかかったイメージとして雲のようなものが描かれています。大切なことは、異なる背景を持つ人々の問題を理解したうえで、その問題を解決するシステムの作成に注意を配ることです。この問題領域に踏み込まないでシステムを作成すると、真のニーズを満たせないシステムを作ってしまうケースが多くなります。

 この“問題の分析”における具体的な手順について流れを追ってみましょう。まず、問題領域に関係する利害関係者を特定し、問題を分析することで表面的に出ている問題の背後に隠れた根本的な問題を理解することに務めます。そして、解決すべき問題に対して利害関係者の合意を取り付けます。問題を明確に記述するために、RUPでは下記の表形式の”問題の記述”が作成されます。

問題の内容 現在の受注管理システムは書類ベースで行われているため、対応に時間がかかるだけでなく、人手による書き間違いや読み間違いも発生する
問題の影響を受ける人 顧客、受注担当者
影響 処理の時間がかかるだけでなく、精度にも問題があるため、顧客、社員に不満がある
ソリューションが成功すると 在庫問い合わせの時間が短縮し、確実な情報の入出力が行われる
“問題の記述”の例(受注管理システム)

 次に、その問題を解決する際の制約を理解したうえで、問題を解決するソリューションを提案し、利害関係者の合意を取り付けます。当然、これらの手順を通じて、共通の用語について共通の認識を得るために、用語集を作成していくことになります。

スキル2 利害関係者のニーズの理解

ALT 図2 要求のピラミッド 「問題の分析」

 「スキル2 “利害関係者のニーズの理解”」では、利害関係者からさまざまな要望を収集することで、利害関係者のニーズを理解することに務めます。

 通常、要求の出てくるもととなる利害関係者の種類は多岐にわたります。顧客、エンドユーザーはもちろんですが、業務の専門家、経営層、プロジェクトチームメンバーも要求元となります。業務用アプリケーションを開発する場合は、エンドユーザーや業務の専門家が特に重要な要求元であり、多くの場合、システムレベルではなく、ビジネスモデルのレベルからも分析を行います。市販する製品を開発する場合は、対象となる市場のニーズをよく理解する必要があるため、マーケティング関係者が重要な要求元となるでしょう。

 利害関係者の要望にはいろいろなレベルがあります。非常に抽象的なものから、システムに依存したとても細かいレベルのものまで多岐にわたります。利害関係者から引き出したレベルのまちまちな“利害関係者の要望”の中から、ソリューションに依存しない形で抽出した上澄みが“利害関係者のニーズ”であり、“要求のピラミッド”の頂上部分に相当します(注1)。


(注1) 利害関係者の要望と利害関係者のニーズという言葉は非常に似ていて分かりにくいのですが、今回の記事ではこのように使い分けています。


 利害関係者の要望を導き出す手法としては様々なものがあり、場合によって使い分けることになります。例えば、顧客から渡されたRFP(Request for Proposal)のレビュー、利害関係者を集めたワークショップの開催、ブレーンストーミング、ユースケースモデリング、インタビュー、プロトタイピング、アンケート、ロールプレイングなどが挙げられます(注2)。


(注2) ユースケースモデリングとは、ユースケースを用いてモデリングすることです。まず、モデリングとは、一言でいうと、文脈に応じて物事を単純化して分かりやすくすることです。次に、ユースケースとは、システムが提供する機能要求を表現する手法の1つです。システムに対してある役割(ロール)を持つ人をアクターとし、そのアクターが望むサービスをユースケースと呼びます。そして、アクターとシステム間におけるデータや要求のやり取りを、ストーリー形式で記述します。システムに対してユースケースモデリングを行うと、アクターとユースケースの一覧、そしてユースケース毎にそのやり取りを書いたユースケース記述ができることになります。詳細は次回以降にお話しします。



 以上、今回は、要求管理プロセスの全体像を理解するシリーズの1回目として、“問題の分析”と“利害関係者のニーズの理解”のスキルを見てきました。“問題の分析”では、解決しようとしている問題の説明について顧客と合意を取り付けること、”利害関係者のニーズの理解”では、利害関係者からさまざまな要望を収集することで、利害関係者のニーズを理解することがポイントでした。次回は“システムの定義”、“システム範囲の管理”についてお話をしたいと思います。

著者プロフィール

玉川憲(たまがわけん)

 IBM東京基礎研究所に入所後、超小型腕時計型LinuxコンピュータWatchPadの研究開発に従事。現在は、IBM Rational事業部にて、RUP・要求管理・オブジェクト指向分析設計の講師としてコンサルティングを行っている。



Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ