変更管理できていますか？

第3回 変更管理できていますか？

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

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

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

• 要求変更
• 要求追加
• 要求削除 図2に示す要求構造のすべての階層で起こり得ます
  

図2のように要求を正しく構造化しながら定義できたとすると、どの階層レベルの要求に対して変更、追加、削除のイベントが発生したとしても、その影響範囲を判断し、実際に必要な影響への対処方法、所要コストを見積もることが可能となります。

もちろん、同一階層構造内にはない、例えば、複数の要求に含まれるような共通要求（典型的な例としては、何かにつけ確認メールを送信するようなシステムの場合の、“メールを送信する”などが挙げられます）との関係は、明示的に定義する必要があります。

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

要求を構造化し、要求間の依存関係を把握することに加えて、要求／タスク／成果物の依存関係も正確に把握しておかなければ、プロジェクトのライフサイクル全般にわたって発生する変更に対して、適切な対応はできないということです。

また、これらをすべて、何の仕掛けもないままで実践することは大変な労力を要しますし、プロジェクトによってはここまでやることのメリットがないものもあります。ただ、上記の実現を支援するようなツールも存在していますので、検討してみるのもいいかもしれません。

まとめ

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