プロジェクト管理の中の変更管理の説明です。
システム開発では、要件定義や基本設計等、各工程で合意した内容（ベースライン）で最後まで開発が進むことは稀で、開発途中でベースラインの変更要求が発生することが多々あります。その変更要求を適切にコントロールするのが変更管理になります。
変更管理には、コストと品質・リスクの観点があります。
１．コストの観点での変更管理
大きなプロジェクトでは、開発予算のバッファーをベンダーと共有して（実際にはベンダーは共有しているバッファー以外にもバッファーがある）、そのバッファー内で変更要求の対応有無を発注者と協議していきます。
変更要求を一定期間溜めておいて、変更しなかった場合の影響や変更する場合のコストやリスク、バッファーとして確保している予算から各変更要求をふるいにかけて、対応有無を判断していきます。
例えば要件定義が終わった後、基本設計に入って要件定義の変更要求が発生した場合、緊急度の高いもの以外は基本設計がある程度落ち着くまで溜めておいて、変更しなかった場合の影響や変更する場合のコスト、バッファーとして確保している予算から、どの変更要求を受け付けるか、却下するかを発注者とベンダーとで協議していきます。
ただ最近は開発期間がどんどん短くなってきているので、感覚的には１年以上の開発期間があるプロジェクトでないと、このようなプロセスをまわすことは難しいと思います。
ではそれほど規模の大きくないプロジェクトでは、変更管理は不要なのでしょうか？
コスト管理の面では、規模の小さいプロジェクトでは変更管理のメリットは小さいと思います。開発期間も短く、要員も大人数でないので、予算に収まるか？ということ以前に、期間内で対応できるのか？という方が重要になります。実態としては変更要求が発生する都度、期間内にできるのか、できないのか、という判断をすることになるため、変更管理台帳に要求を溜めて、重要度や影響等から総合的に対応の優先順位を判断するというプロセスをまわすことは規模の小さいプロジェクトでは困難です。
コスト管理の面では変更管理のメリットは小さいですが、品質管理の面では規模の小さいプロジェクトでも変更管理は有効です。
２．品質・リスクの観点での変更管理
①トレーサビリティー
規模の大きなプロジェクトでなければ、コスト面での変更管理のメリットは小さいですが、品質面ではプロジェクト規模の大小に関わらずメリットがあります。特に開発期間が短いプロジェクトほど、品質面では変更管理をきちんと行っていく必要があります。
開発期間が短いプロジェクトは、各工程が並行で動きます。要件定義が完全に終わる前に基本設計を進めたり、基本設計が完全に終わる前に詳細設計を進めたりします。その際に、例えば基本設計に着手した後で要件定義の変更があり、その変更が基本設計に反映できていない、というようなケースは現実のプロジェクトでは多々あります。
そのような状態を防ぐことも必要ですが、変更管理で変更を管理し、その変更をトレースすることで、このような「変更漏れ」の状態を検知します。具体的には発生した変更は、全て総合テストや受入テストで確認をすることになります。
要件定義は元請けベンダーが担当して、基本設計は下請けベンダー、詳細設計や製造は孫請けベンダーが担当するようなプロジェクトでは、開発途中の変更要求がベンダー間で上手く伝わらないケースが多いため、ベンダー間の情報共有のツール、品質確保のツールとして変更管理台帳は有効です。
変更管理は通常、ベースラインの変更を対象とするので、発注者側の変更要求が主な対象となりますが、ベンダー側の変更要求も対象となります。具体的にはテストでバグが見つかったケースです。通常、ベンダーは請負契約でシステム開発を受注するので、テストで見つかったバグは潰すのが原則です。
これは正論ですが、バグの修正には修正ミスというリスクがついてまわります。
それを発注者とベンダーが同じ目標を目指す仲間として、客観的に変更管理で判断をします。このバグは、本当にいま直すべきなのか？バグを抱えたままリリースすることの業務影響と、バグを直すことによるデグレードのリスクを天秤にかけて、判断をしていきます。特にテストのフェーズが進めば進むほど、バグが見つかっても対応しないという判断が重要になってきます。レアケースのバグをあわてて修正したがために、修正後のテストが不十分でメインルートのバグに気づかずに本番を迎えてしまったという残念なケースは、現実のプロジェクトで良くあることです。「バグなんだからすぐ直せ」ではなく、発注者は修正することのリスクを理解して、変更の判断をする必要があります。
プロジェクトやプロジェクトメンバーの特性によって、メリハリのある変更管理の運営が大切です。その辺りの勘所がないと、単に変更管理台帳で変更要求を管理しているだけでは、本来、変更管理で回避したい問題事象を回避することができません。
変更管理は、「その変更受けてコストが予算超過しないか」というコスト管理の観点よりも、「本当にこの変更要求を受けてしまってリスクは無いのか？」というリスク管理と、変更を受けた後、「きちんと変更が反映されているのか？」という品質管理の観点が重要になってくるのです。
【振り返り】
今回はプロジェクト管理の中の変更管理の説明でした。次回はコスト管理の説明をしていきたいと思います。
①．進捗管理
②．品質管理
③．コスト管理
④．課題管理
⑤．リスク管理
⑥．変更管理
⑦．コミュニケーション管理
⑧．成果物管理（文書管理）
⑨．要員管理
⑩．ステークホルダー管理
⑪．外注管理
