【初心者必見】プロジェクトマネジメントの変更管理とは？変更管理の目的と手順を解説

システム開発のプロジェクトマネージャーを任命されたけど、変更管理はどうすればいいの？
そもそも変更管理ってなに？
変更管理のやり方がわからない？

プロジェクトを進めていくと、途中で必ずお客様から仕様変更を要求されます。そのため、変更要求が発生した場合の運用ルールや運用フローをプロジェクト計画時に取り決めておく必要があります。

今回は、プロジェクトにおける変更管理とは何か？プロジェクト計画に記載すべき変更管理のポイントをわかりやすく解説します。

前回のおさらい（プロジェクト計画の書き方）
プロジェクトにおける変更管理とは？
- お客様とシステム担当者の変更要求事例
- 変更要求を安易に受け入れると大変なことに
変更管理のやり方
- 変更管理のフロー図
- 変更によって影響するポイント
変更管理で記録すべき項目
変更要求を適切に管理してプロジェクトを成功に導こう

前回のおさらい（プロジェクト計画の書き方）

これまで、プロジェクトを成功させるためにプロジェクト計画を立てること、そしてプロジェクト計画の最初は「プロジェクト概要」をまとめることを解説しました。

プロジェクト概要がまとまったら、次はプロジェクト計画を詳細に落とし込んでいきます。プロジェクト計画でやるべきことは、そのプロジェクト概要を含めて11項目あります。

これらはプロジェクトを円滑に運営するための重要なガイドと言えるものです。この11項目をプロジェクト計画書にまとめ上げ、ゴールに向かってプロジェクトをスタートしましょう。

今回は、変更管理を解説します。

プロジェクトにおける変更管理とは？

システム開発のプロジェクトでは、まず最初にお客様からシステム化の要求事項を伺います。具体的には、要件定義の工程でシステム化する機能の要件を洗い出し、必要な機能は何かお客様と整合して決定していきます。

要件定義で決まった要件をベースに、概要設計→詳細設計→プログラム開発と進んでいくわけですが、プロジェクトの途中で必ずと言っていいほどお客様の要求・仕様は変わります。

その変更の話をお客様から聞くのは日頃からお客様と接している担当者になりますが、担当者が安易に変更要求を受け入れると大問題です。なぜなら、プロジェクトで重要な品質（Quality）、コスト（Cost）、納期（Delivery）に影響するためです。その影響は工程が進めば進むほど大きくなります。

お客様とシステム担当者の変更要求事例

とあるシステム開発で概要設計を進めているプロジェクト。
※登場人物はこちらの「システム開発の体制図サンプル」に合わせています。

ある時、出荷管理機能の画面イメージを提示してお客様と打ち合わせしている時に

お客様
出荷業務課
上野さん

宅配便で出荷する以外にも、たまに営業所で
受け渡しすることもあるのよね。

システム会社
出荷管理担当
阿部さん

え？そうなんですか？
要件定義では営業所で受け渡しする事は
聞いていませんでしたが・・・

お客様
出荷業務課
上野さん

要件定義に参加していた村田課長が説明していると
思うけど、村田課長は知らなかったのかな？
でも、必要な機能だから追加してください。

システム会社
出荷管理担当
阿部さん

必要なんですね。承知しました！
その機能を追加しておきます。

という感じでシステム担当の阿部さんがあっさり変更要求を受け入れしまいました。

その後、システム開発会社の出荷管理チームでミーティングを行った時に、阿部さんがこの変更要求を受け入れたことを説明すると

システム会社
出荷管理リーダー
小林さん

その変更を追加することで影響を
受ける機能はどこになるの？

システム会社
出荷管理担当
阿部さん

すいません。
まだ影響範囲は調べてません。

システム会社
出荷管理リーダー
小林さん

すぐに影響範囲を調べてください。
概要設計が完了した画面にも影響すると手戻りが出るなあ・・・

システム会社
出荷管理担当
阿部さん

あ、そうだ！注文時点で営業所で引き渡しするかを
決めるそうなので、注文管理画面にも影響します。

システム会社
出荷管理リーダー
小林さん

わかった、すぐに注文管理リーダーの佐藤さんに連絡するよ。
納期やコストにも影響しそうだから、明日のリーダー会議でＰＭの鈴木部長にも相談してみる。

システム会社
出荷管理担当
阿部さん

こんなに大きな話になるとは思ってませんでした。
すいません・・・

変更要求を安易に受け入れると大変なことに

この事例のように、安易に変更要求を受け入れてしまうと、プロジェクトマネジメントで重要な品質（Quality）、コスト（Cost）、納期（Delivery）を守れなくなってしまいます。この変更によるコスト増加やスケジュール遅延は、お客様にとっても簡単に了承されるものではありません。

そのため、プロジェクト遂行上の変更要求は必ず文書化し、ステークホルダーで共有して、お互いの責任者の承認をもって反映する仕組みをプロジェクト計画段階で合意しておく必要があるわけです。

お客様と仕様を凍結する時期を決めてプロジェクト計画書に明記しましょう。
仕様凍結後に発生する変更は、変更管理のルールに従って記録しましょう。
サブシステム間の仕様不整合がないように影響範囲をしっかり調査しましょう。
変更は、お互いの責任者の承認後に反映しましょう。

変更管理のやり方

変更管理の流れはどのようになるでしょうか。
以下に変更管理のフロー図とポイントをまとめます。

変更管理のフロー図

番号	実施担当	実施内容
1～2	お客様	変更要求が発生したら、プロジェクト担当者へ連絡します。
3	システム会社	プロジェクトメンバー間で変更要求を説明し、変更内容を記録します。
4	システム会社	変更要求を確認し、要求を受け入れるか判定します。（ここでは検討を開始するかどうかの判断程度です）あきらかに対応が困難な場合は却下とし、却下通知を行います。変更要求がプロジェクトの目的から外れておらず、変更が必要と判断された場合は検討を開始します。
5	お客様	却下理由を確認します。もし変更されないことで業務に影響が出る場合は業務見直しを検討します。
6	システム会社	影響範囲を調査します。
7	システム会社	変更要求に対する対応方法を検討します。追加工数が発生する場合は工数を見積もります。
8	システム会社	変更内容を確認し、問題なければお客様のプロジェクトメンバーへ連絡します。この時、追加工数が発生する場合はその見積もりも提示します。
9	お客様	変更要求通りの対応内容か確認します。追加工数が発生する場合、工数に見合った効果があるかも判断します。
10	両者	プロジェクトメンバー同士で変更内容を整合します。問題なければ両者の責任者の承認を得ます。
11	システム会社	責任者の承認により、変更が確定したことをプロジェクトメンバーで共有し、開発者へ変更反映を依頼します。
12	システム会社	変更内容を設計書やプログラムへ反映します。

変更によって影響するポイント

変更要求があった場合、まずは影響範囲を調査する必要があります。どこに影響があるのか、調査すべきポイントをまとめます。

確認ポイント	確認内容
スコープ	スコープ（開発対象範囲）内の変更要求か。スコープから外れている場合は却下すること。
機能要件・仕様	関連する機能要件・仕様を変更する必要はないか。作成済の設計書の修正はないか。
連携先システム	データやサービスを連携する既存システムに影響はないか。該当テーブルやデータ連携項目が変更になる場合は要注意。
他プロジェクト	複数のプロジェクトが同時進行する大規模プロジェクトの場合、会計システム等の他のプロジェクトに影響しないか。
コスト	変更要求を対応することで追加コストは発生しないか。
スケジュール	変更要求を対応することでスケジュールに影響しないか。
リスク	現時点で対応することによるリスクはないか。
委託契約	変更作業によって開発会社との委託契約に問題はないか。納期や工数に影響する場合は要注意。

変更管理で記録すべき項目

変更管理で記録すべき項目を下記にまとめます。これらを横に並べて一覧表形式で利用してもよいでしょう。

分類	記録項目	項目内容
変更要求	受付日	変更要求を受け付けた日
	変更内容	変更する内容
	希望回答納期	希望する回答の期限
	変更要求担当者	変更を要求した担当者
	システム機能	変更するシステム機能名
	発生工程	変更が発生した工程（概要設計、詳細設計、開発、結合テスト、システムテストなど）
	状況	「受付」「調査中」「仕様整合中」「承認済」「変更中」「却下」「完了」などの状態
変更調査	調査内容	調査した結果、変更可能な対応内容
	影響範囲	影響を受ける範囲（画面やサブシステム、他のアプリケーションなど）
	工数見積もり	変更することで追加工数が発生する場合、その見積もり工数
	調査担当者	調査をした担当者
	回答日	調査結果を回答した日
変更判定	採否判定	変更を承認するか、却下とするか
	採否確定日	採否が決定した日
	承認者（お客様）	お客様側の責任者
	承認者（システム会社）	システム会社側の責任者
	却下理由	却下の場合、その理由
変更完了	対応内容	実際に対応した変更内容
	対応担当者	対応した担当者
	対応完了日	対応が完了した日
	対応工数	対応にかかった実績工数
	最終承認者	お客様の最終確認した責任者
	完了承認日	完了を確認した日