メディア

要求管理と変更依頼管理の違いを理解しよう：みんなが悩む要求管理（7）

» 2005年06月01日 12時00分公開

[玉川憲，日本IBM]

　どんなに注意深く要求を定義しても、ビジネス環境の変化や、顧客のシステムに対する理解の変化に応じて要求は変更されるものです。第5回「要求管理プロセスの流れを追跡する」では、要求の変更に対する管理プロセスの概要をお話ししました。今回は、特に要求への変更という観点だけでなく障害報告も含めた変更依頼という観点で、システムへの利害関係者の要望（Stakeholder Request）を管理する「変更依頼管理（Change Request Management）」を取り上げ、要求と変更依頼をきちんと分けて考えることによるメリットを解説します。

避けられない要求の変化にどう対処するか？

　システム開発において、「初期の段階で要求を確定し、その後変更しない」ことが可能であれば、要求を実現するシステムを構築する開発チームにとっては、非常にうれしいことです。しかし、実際のシステム開発においては、初期の段階で要求を確定することはあまり現実的ではありません。

　例えば、競合他社が新しいテクノロジを導入したり、システム開発のための予算が削減されたりといったようなビジネス環境の変化が起こり、要求を変化せざるを得ないケースは少なくありません。また、開発の初期段階において顧客自身がどんなシステムが欲しいのか分からなかったり、開発が進むにつれて顧客のシステムに対する認識が変わったりするなど、要求を初期の段階で確定することが難しいことは明らかでしょう。これらのことから、システム開発において要求の変化が避け難いことは容易に想像がつきます。

　では、そもそも要求が変化する可能性が高い状況では、どういう対策を取るべきなのでしょうか？まず、変更に強いシステム・アーキテクチャ（基盤設計）を設計すること、バージョン管理、リリース管理を含むソフトウェア構成管理を正確に行い、変更が入った際に、成果物の修正を管理できる体制を整えることが大切です。

　また、ソフトウェア開発の開発工程そのものを考えたときには、反復型の開発プロセスがその対策として挙げられるでしょう（第6回「反復型開発における要求管理の流れ」）。反復型開発においては、プロジェクト全体での時期に応じて、重要な作業を重点的に行います。

　プロジェクトの初期の反復では、業務分析、要件定義が重点的に行われ、プロジェクトの後半の反復になると主に実装が行われます。ウォーターフォール型の開発のように、初期の段階で要求を完全に作成することにこだわるのではなく、各工程を繰り返すことで、要求に対する理解を深め、堅牢なアーキテクチャを作り、実装、テストを繰り返して段階的に完成度を増してゆくことができます。

　これらのような、アーキテクチャ、ソフトウェア構成管理、反復型開発の話も大切ですが、今回は変更が入ったときにそれをどう取りまとめ、どう処理していくかという変更依頼管理に目を向けて、話を進めたいと思います。

要求と変更依頼を分けて考える

　要求に対する変更を管理するキーポイントの1つが、変更依頼と要求の違いを理解することです。変更依頼は、要求とは違うものです。表1は、変更依頼と要求の違いを簡略にまとめたものです。

変更依頼（Change Request）	新しい機能、拡張依頼、障害報告などの、全ての利害関係者からの要望記述内容が不明確、不正確なことがある用語が統一されていない変更依頼の中で重複していることがある
要求（requirement）	「システムが満たすべき様態や能力」であり、顧客と開発チームにより合意された、契約の基盤である要求の品質基準を満たしている IEEE830の品質基準：正確である／完全である／一貫している／明確である／重要性と安定性が評価されている／検証できる／変更できる／追跡可能である／理解できる
表1 変更依頼と要求の違い

　まず、変更依頼から見ていきましょう。変更依頼は、利害関係者からのシステム開発に対する要望です。要望の内容は、まったく新しい機能であったり、既存機能の拡張であったり、障害の修正要望であったりするでしょう。変更依頼は、多くの利害関係者により記述されるので、その記述内容は正確でないことが多々あります。変更依頼の記述に使われている用語も、開発チームの用語集にそぐわないものが交じります。また、変更依頼は重複して登録されることが多々あります。例えば、システムに重大な機能が欠けていたときは、多くのユーザーがそれを指摘して変更依頼を登録するでしょう。

　それに対して、要求はある問題を解決するシステムを作成するための、システムが満たすべき様態や能力を記述したものであり、顧客と開発チーム間の契約の基盤になるものです。良い契約の基盤であるために、要求は、「IEEE 830」の品質基準で定められているように正確で、明確なものでなければなりません。品質の高い要求であるからこそ、それを契約の基盤として、顧客と開発チームの間で合意を結ぶことが可能になります。

　このように、変更依頼と要求を明確に区別すると、要求に対する変更をできるだけ少なくすることができます。つまり、何か変更したいという依頼が入ったらそこからすぐに要求、コードを修正するアプローチに比べて、システムに対する本当の「要求」と、多数の利害関係者から出てくる「変更依頼」の違いを理解し、変更依頼に対して正式な処理を踏んだうえで、必要なときのみ要求を変更するアプローチを取ることで、要求に対する無駄な変更を避けるのです。

変更依頼の管理プロセス

　要求と、変更依頼の違いを整理したところで、ここから、変更依頼に対する管理プロセスを見ていきましょう。表2は、変更依頼管理プロセスの例をステップにまとめたものです。

利害関係者が、変更依頼を作成する（変更依頼は一括管理される）
変更審査委員会は、変更依頼を分析し、どのように対応するか決定し、承認された変更依頼に担当者をアサインする
担当者は、その変更依頼に応じて、要求、設計、コードなどの成果物を修正する
テスターが、修正内容を検証する
変更審査委員会は変更依頼をクローズする

表2 変更依頼管理プロセスのステップ例

　まず、変更依頼が登録されます。もし、開発チーム内のメンバーがその変更依頼に対して個々に対応して要求を修正したり、コードを修正したりすると、プロジェクト内の成果物に対してさまざまな変更が同時多発的に発生することになり、プロジェクトは管理不能な状態に陥ります。そうならないように、図1にあるようにすべての変更依頼を集めて、単一の承認ルートを通すようにします。このルートは、小規模なプロジェクトの場合は、プロジェクトマネージャのような担当者が取り仕切ることになりますが、ある程度大規模なプロジェクトの場合、要求や設計チームの代表者から編成した変更審査委員会（CCB：Change Control Board）が取り仕切ります。

図1 変更依頼を一元的に管理する

　次に、変更審査委員会は個々の変更依頼を分析して、どのように対応するか決定し、担当者をアサインします。その対応は、ある場合は、単純に要求に対して正確に実装されていないコードのバグを修正することになるでしょうし、ある場合は、要求を変更する、あるいは、新しい要求を作成することになるでしょう。いずれにしろ、いきなりコードに手を入れるのではなく、要求から修正が必要かどうかきちんと確認したうえで、要求から段階的に修正を掛けていくことが大切です。このときに、要求内でのトレーサビリティ、要求から設計、コード、テストケースへのトレーサビリティが引かれていると、変更依頼の分析、担当者の作業にとって非常に役立つことはお分かりでしょう。

　もし、変更依頼が、要求セットに対する変更を含む場合は、変更依頼は要求を修正する際の土台になります。変更依頼自体がそのまま要求になるのではない、ということが重要です。最初にお話したように、変更依頼と要求は別物なのです。要求は、あいまいではなく、要求セットの中で矛盾が存在せず、検証されたものでなければなりません。変更依頼は通常、そういう視点では書かれていません。

　変更依頼に対する作業をアサインされた担当者が作業を終えると、テスターが修正内容を検証し、正しく修正が行われたことを確認したうえで、変更審査委員会はその変更依頼に対する対応を終えます（クローズする）。

　変更依頼を適切に処理するには、多数の変更依頼を一元的に管理し、その変更依頼に対する評価、担当者、作業状況などを追跡する必要があります。大規模なシステム開発を行う場合は、変更依頼管理ツール（IBM RationalのClearQuest、BorlandのStarTeam、TelelogicのSYNERGY/Changeなど）を導入することで、管理コストを削減することが可能です

変更依頼管理プロセスと要求管理プロセスの融合

図2 変更依頼管理プロセスと要求管理プロセスの関係

　図2は、変更依頼管理プロセスと要求管理プロセスの関係を表したものです。図2の左側の要求関係から見ていきましょう。システム開発が始まると、解決すべき問題を分析し、利害関係者のニーズを理解したうえで、システムに対する要求を記述していきます。システム開発の初期の段階では、まだ要求そのものがきちんと形作られていないので、この段階では、特に変更依頼として個々の利害関係者の要望を処理する必要はありません。

　そして、要求が固まってくる時期になると（RUPの場合、推敲フェイズの終盤）、要求セットのスナップショットを作成し（これを要求ベースラインと呼びます）、開発チームにこのベースラインを公開します。それ以降の要求ベースラインに対するすべての変更は、変更依頼管理プロセスも含めた形で行うようにします。

　図2の右側の変更依頼関係に目を移します。ここでは、変更依頼が登録され、個々の変更依頼は、変更審査委員会によって審査されます。変更依頼が分析された結果として、この変更依頼を受け入れることになると、ベースライン化された要求セットに対して、修正を行うことになります。修正が終了し、反復のための要求セットが特定されると、この要求セットをベースに、設計・実装・テストが行われることになります。反復が終了し、次の反復が存在する場合は、また変更依頼を受け入れ、次の反復のための要求セットを特定する、ということを繰り返します。

　以上、今回は、変更依頼管理（Change Request Management）を取り上げ、要求と変更依頼の違い、変更依頼管理プロセスの流れ、要求管理と変更依頼管理の組み合わせを説明してきました。多くの変更依頼を、変更審査委員会という単位ルートで処理することで、漏斗（じょうご）のように変更依頼を絞り込み、承認された変更依頼のみを要求から段階的に処理していく、というところがキーポイントでした。この仕組みを構築することで、要求に対する無駄な変更を避けることができるのがお分かりいただけましたでしょうか？

著者プロフィール

玉川憲（たまがわけん）

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

「みんなが悩む要求管理」バックナンバー

変更依頼（Change Request）	新しい機能、拡張依頼、障害報告などの、全ての利害関係者からの要望記述内容が不明確、不正確なことがある用語が統一されていない変更依頼の中で重複していることがある
要求（requirement）	「システムが満たすべき様態や能力」であり、顧客と開発チームにより合意された、契約の基盤である要求の品質基準を満たしている IEEE830の品質基準：正確である／完全である／一貫している／明確である／重要性と安定性が評価されている／検証できる／変更できる／追跡可能である／理解できる
表1 変更依頼と要求の違い