第3回 変更管理できていますか？：要求仕様のボトルネックを探る

[今村智，ボーランド]

　今回は、要求管理の中でも特に重要なアクティビティである「変更管理」にフォーカスします（一般には、変更管理という言葉には、今回取り上げる要求変更のみでなく、プログラムバグに対する修正要求なども含まれます）。「仕様変更はあって当たり前」だとか「変化ヲ抱擁セヨ」というフレーズを都合よく解釈した結果、失敗プロジェクトに転落してしまう状況は枚挙に暇がありません。このような状況はどのように改善したらよいのでしょうか。

（1）プロジェクトにおける“変更”の影響

　自社のソフトウェアパッケージ製品の開発であろうと、請負開発であろうと、“プロジェクト”として行う以上は、期間、コスト、および実現される機能に制約があることに違いはありません。最終的な成果物（ソフトウェア）の品質は、この3つの要素のバランスによって決まります。「Developing Applications With Java and UML」（Paul R. Reed, Jr.、Addison-Wesley）では、これらの関係を三角形の3辺とその形状で説明しています。

図1 期間、コスト、機能のバランスが品質を決める

　つまり、バランスの取れた状態から、期間だけを半分に短縮するとか、コストを半分にするという場合には、機能も半分にしないとバランスが保てずに、品質に影響を与えるということです。機能が増えた場合は、コスト、期間も増やさなければバランスは保てません。このたとえで重要なことは、品質をその面積ではなく形としてとらえていることです。これは、プロジェクトにおけるさまざまな変更要求への対応を判断する際に、自身を冷静にする、またはユーザーにトレードオフを説明するためにも、有効であると感じています。

　さて、ほとんどのプロジェクトでは、コストおよび期間が途中で積極的に変更されることはありません。多くの変更は機能に対してであり、それらへ対応した結果としてコスト、期間に変更が生じることになります。この変更によって、発注者（ユーザー）と受注者（開発者）双方が不利益となることのないように調整がなされ、合意に基づく処置が実施されれば何の問題もないわけですが、現実はそれほど美しくないことは皆さんご存じのとおりです。なぜそのようにならないのか？ 原因は大きく2つに分類できます。

1. ユーザーがそれを、機能に対する変更（または追加）とは認識していない
2. ユーザー、開発者のどちらか、または双方が、その変更（または追加）による影響を過小評価している

　「1. ユーザーがそれを、機能に対する変更（または追加）とは認識していない」は、本来、要求として当然抽出されているべきものであったり、暗黙的な期待を含んでいたりというように、要求開発の問題であることが多く、要求分析者のスキル（コミュニケーションスキル、クリティカルシンキング、ITスキルetc……）と、要求構造化の手法に依存するところが大きいものであり、本稿のスコープから外れるため、ここでは扱いません。「2. ユーザー、開発者のどちらか、または双方が、その変更（または追加）による影響を過小評価している」は、変更による影響のとらえ方を整理することで改善が可能なものであり、本稿はこれについて述べていきます。

（2）プロジェクトで発生する要求へのイベント

　多くの変更は、機能に対して発生すると述べましたが、機能を要求としても大意に違いはありませんので、以下では“要求”に統一します。要求に対しては、プロジェクトのライフサイクル全体を通して以下のイベントが発生します。

　要求変更

　要求追加

　要求削除

　そして、これらのイベントは、図2に示す要求構造のすべての階層で起こり得ます（なお、システムに対する要求としては、ここに示す機能要求同様に、非機能要求も重要な意味を持つことは前回触れたとおりですが、今回は機能要求にフォーカスすることにします）。

図2 要求構造

　さて、図2のように要求を正しく構造化しながら定義できたとすると、どの階層レベルの要求に対して変更、追加、削除のイベントが発生したとしても、その影響範囲を判断し、実際に必要な影響への対処方法、所要コストを見積もることが可能となります。もちろん、同一階層構造内にはない、例えば、複数の要求に含まれるような共通要求（典型的な例としては、何かにつけ確認メールを送信するようなシステムの場合の、“メールを送信する”などが挙げられます）との関係は、明示的に定義する必要があります。実際にプロジェクトが進行している中で前述のイベントが発生すると、以下の流れに従ってそれらへの対処方法を決定することになります。

1．発生したイベントに対して評価する

a） イベントが、変更、追加、削除のどれに当たるのか？

b） イベントによって影響を受けるのはどの要求なのか？

c） イベントに対応するとしたら、必要な工数と、スケジュール、品質に対する影響を見積もる

2．イベントへの対応可否を判断する

3．最終的な決定と、最新の要求、スケジュールを関係者全員が共有する

　この手順自体は、皆さんにとって何ひとつ新鮮味のないものだと思います。問題は、多くのプロジェクトではこの当たり前のことの実践が、非常に困難だということです。私が知る限り、ほとんどのプロジェクトで見られるやりとりは、「これ対応できる？」という問い掛けに対して、「たぶん、できます」「難しいです」「やってみます」のいずれかで応答するというものです。。そして、このように答えているのは、設計者でも、テスト担当者でもなく、実装者またはその代弁者（通常は実装チームのリーダー）です。

　従って、プロジェクト全体に対して、その時点での影響を漏れなく把握した回答にはなっていません。つまり、多くのプロジェクトでは、1-a→1-b→2→3→1-c→混乱というサイクルでイベントへの対応がなされていることになります。これは、要求へのイベントによって影響を受けるものとして、要求“以外”のものが把握できていないことに起因します（実際には、影響を受ける可能性がある要求すらも正しく把握されていないことも多く、最終的にはコスト、期間、機能、品質、すべてが破綻してしまうプロジェクトが珍しくないのは皆さんご存じのとおりです）。

（3）影響範囲を把握する

　要求の構造化が正しくなされていれば、1-bについては問題なく実施可能ですが、1-cについては、それだけでは十分ではないということです。ここで、プロジェクトとは何かを再確認してみます。PMBOKガイドによると、「プロジェクトは、独自の製品やサービスを創造するために実施される有機的な業務である」とあります。また、独自の製品やサービス、業務といったものは段階的に詳細化されるともあります。システム開発プロジェクトにおいては、プロジェクトは要求と、それを実現するために必要なタスクと、そのタスクによって生み出される成果物で表現することができ、それらが時間の経過とともに積み重ねられることで、最終的な目的を達成することになります。つまり、プロジェクトの完了は、これらすべての成果物の完了をもって表すことができるということです。図3はこのイメージを表現したものです。

図3 プロジェクト＝要求＋タスク＋成果物

　話をイベントへの対応に戻すと、1-cで見積もっているのは、図3の実装を主としており、賢明な担当者によってテストのやり直しについて言及されることはあっても、どの程度の影響があるかを正確に把握していることは稀（まれ）です。個々のタスクの成果物まで把握するのは、“要求”管理の領域を超えているようにも思われますが、前述の手順を正しく行うために必要であれば、それが要求管理の範疇（はんちゅう）なのか、プロジェクトマネジメントの範疇なのかは重要ではないのですが、あえて前準備と実際のイベントへの対応をそれぞれの役割を意識して整理すると表1のようになります。

	要求分析者、要求管理者	プロジェクトマネージャ	各担当者
事前準備	1. 要求を正しく構造化し、依存関係を含めて定義する	2. 各要求を実現するために必要なタスク、成果物、担当者を定義する（WBSの作成）	3. 割り当てられたタスクを、主として成果物を完成させることで遂行する
イベント発生時の対応	1. 要求の構造から、影響を受ける可能性のあるすべての要求を特定する	2. （影響を受ける可能性のある）あらゆる要求に関連したすべてのタスクの担当者を特定する	3. 影響の有無、対応に要する工数を見積もる
		4. 対応可否を決定し、計画に反映する
	5. 必要に応じて、要求のバージョン、ステータスを更新する		6. 新たな計画、要求に基づく作業の実施
表1 要求へのイベント発生時の対応の流れ

　これでお分かりいただけると思いますが、要求を構造化し、要求間の依存関係を把握することに加えて、要求／タスク／成果物の依存関係も正確に把握しておかなければ、プロジェクトのライフサイクル全般にわたって発生する変更に対して、適切な対応はできないということです。また、これらをすべて、何の仕掛けもないままで実践することは大変な労力を要しますし、プロジェクトによってはここまでやることのメリットがないものもあります。ただ、上記の実現を支援するようなツールも存在していますので、検討してみるのもいいかもしれません。

　さて、3回にわたって“要求”という視点でプロジェクトが抱える問題に対する改善案をお伝えしたわけですが、これらを簡潔にまとめると、

1. 要求は構造化することで漏れなくダブりもなく把握する
2. 要求の評価（テスト）を要求開発と同時に実施する
3. 要求を起点として、タスク、成果物の依存関係を把握する

となります。1、2は、高品質な要求を開発することを意味し、3は、要求とそれに関連する情報の品質を維持する（管理する）ことを意味します。もちろん、プロジェクトが抱えている問題は非常に多く、これらですべてが解決するわけではありません。しかし、問題の根幹の1つに“要求”があることは紛れもない事実であり、“要求”の周りで沸き起こる問題に対して、根治療法を取ることは大変効果が大きいものなのです。

プロフィール

今村智（いまむらさとし）

　メインフレームでの証券取引所データリアルタイム配信システム開発を経験後、数々のオブジェクト指向での企業情報システム開発を経て、ソフトウェア開発に関わる方々を少しでもハッピーにすべく、要求開発・管理、ソフトウェア開発プロセス構築に関する啓蒙、コンサルティングに従事。

「要求仕様のボトルネックを探る」バックナンバー

• 第3回 変更管理できていますか？
• 第2回 コンポーネントの再利用、できていますか？
• 第1回 オフショア開発でハッピーになれましたか？