変更管理（チェンジマネジメント）入門：要件変更を制御する

読了時間：約7分

「プロジェクトが終盤になって顧客から大きな要件変更が入った」——PM経験者なら一度は経験したことがある場面です。問題は変更が来ること自体ではありません。変更を受け入れるかどうか、受け入れるなら何をトレードオフにするかを即座に判断できる仕組みがあるかどうかです。この記事では、その仕組み＝変更管理プロセスを一から構築する方法を解説します。

この記事の結論 変更管理の本質は「変更を拒否すること」ではなく「変更の影響を可視化してから意思決定すること」。変更依頼書（CR）で情報を整理し、4ステップ（受付→分析→承認→実行）のプロセスを回す。承認フローに関係者を明記しておくことで「誰が決めるのか」問題を防げる。AIでインパクト分析の叩き台を出し、PMが精査する使い方が効率的。

変更が起きる根本原因

変更管理を設計する前に、なぜ変更が起きるのかを理解しておくことが重要です。原因によって対策が変わるからです。

原因	典型例	対策の方向性
要件定義の不完全性	「この機能はこういう意味だと思っていた」	要件定義を深掘りし、認識合わせを徹底する
ビジネス環境の変化	「競合が先に出してしまったので機能を追加したい」	変更管理プロセスでインパクトを可視化する
技術的な制約の発覚	「実装してみたら仕様通りにできない部分があった」	早期プロトタイプ・技術検証で発覚を早める
ステークホルダーの意見の変化	「やっぱり別の方向性にしたい」	キックオフで合意内容を明文化し、変更コストを共有する

変更が来ること自体は避けられません。大切なのは「変更が来たら、このプロセスで処理する」という共通ルールをプロジェクト開始前に合意しておくことです。

変更管理プロセスの4ステップ

ステップ1：受付（変更依頼書で情報を整理する）

変更の依頼が来たら、口頭ではなく必ず書面（変更依頼書：CR）で受け付けます。「ちょっとこれ変えてほしいんですけど」という口頭の依頼をそのまま受け入れると、後で「言った・言わない」の問題が発生します。

変更依頼書に記載する内容：

変更の内容：何をどう変えたいか
変更の理由：なぜ変更が必要か
希望する期日：いつまでに対応してほしいか

この段階では「できるかどうか」「受け入れるかどうか」は判断しません。まず情報を正確に受け取ることに集中します。

ステップ2：分析（インパクトを洗い出す）

変更を受け入れた場合の影響を、4つの視点から分析します。

【インパクト分析の4視点】

① スコープへの影響
   → 追加・削除される機能や成果物は何か

② スケジュールへの影響
   → 何日（週）延びるか、または短縮されるか

③ コストへの影響
   → 追加工数・追加費用は発生するか

④ 品質・リスクへの影響
   → 変更することで新たなリスクは生まれるか

この分析が揃って初めて「受け入れるかどうか」を正しく判断できます。分析なしで「いいですよ」と即答してしまうと、後でスケジュールが破綻する原因になります。

ステップ3：承認（誰が決めるかを明確にする）

分析結果をもとに、関係者が承認・却下・保留を判断します。このステップで最も大切なのは、「誰が最終決定者か」をあらかじめ決めておくことです。

変更の規模	承認者の目安
小（工数1〜2日以内）	PM単独で判断可
中（工数3〜5日）	PM＋プロジェクトスポンサー
大（スコープ・期日・予算に影響）	PM＋スポンサー＋顧客の意思決定者

承認フローを事前に合意しておかないと、「この変更は誰が決めるのか」というやり取りで余分な時間が取られます。

ステップ4：実行（変更を計画に織り込む）

承認された変更は、WBSとスケジュールに正式に組み込みます。非公式に「後で対応しておきます」と流すことは厳禁です。計画外の作業として静かに進むと、工数の過剰消費とスケジュール遅延の原因になります。

変更依頼書（CR）のテンプレート

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
変更依頼書（Change Request）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
CR番号：CR-〔連番〕
提出日：〇〇年〇〇月〇〇日
提出者：〔氏名・役職〕
プロジェクト名：〔プロジェクト名〕

■ 変更の概要
〔何をどう変えたいかを簡潔に〕

■ 変更の理由
〔なぜこの変更が必要か〕

■ 変更の詳細
現状：〔現在の仕様・設計〕
変更後：〔変更後の仕様・設計〕

■ 希望対応期日
〇月〇日まで

■ インパクト分析（PM記入）
スコープへの影響：〔あり・なし＋内容〕
スケジュールへの影響：〔+〇日 / なし〕
コストへの影響：〔+〇万円 / なし〕
品質・リスクへの影響：〔あり・なし＋内容〕

■ 承認結果
□ 承認　□ 条件付き承認（条件：　　　）　□ 却下　□ 保留
承認者：〔氏名〕　承認日：〇月〇日

■ 対応方針（承認の場合）
担当者：〔氏名〕　対応期限：〇月〇日
WBS・スケジュールへの反映：完了 / 未完了
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

承認フローの設計方法

変更管理で最も失敗しやすいのが承認フロー設計です。「大きな変更は役員が承認」と口頭で合意しても、いざ変更が来ると「これは大きい変更なのか？」という認識のずれが生まれます。

承認フローを設計する3つのポイント

1. 変更の規模基準を数値で定義する

「小・中・大」という区分を、工数や金額などの数値で定義します。

例：変更規模の定義
・小：追加工数3人日以内、スケジュール変更なし
・中：追加工数4〜10人日、スケジュール1週間以内の変更
・大：追加工数11人日以上、スケジュール1週間超の変更、または予算変更

2. 各規模に対応する承認者を明記する

規模	承認者	承認期限目安
小	PM	2営業日以内
中	PM + スポンサー	3営業日以内
大	PM + スポンサー + 顧客責任者	5営業日以内

3. キックオフで合意を取る

承認フローは、プロジェクト開始時のキックオフミーティングで明示的に合意を取ります。プロジェクト途中で「実はこういうルールです」と説明しても、受け入れてもらえないことが多いです。

AIでインパクト分析を補助する方法

変更依頼書の「インパクト分析」パートは、考慮漏れが起きやすい部分です。ChatGPTにプロジェクト概要と変更内容を渡すと、検討すべき影響のチェックリストを素早く出してくれます。

プロンプト例

以下のプロジェクトに変更依頼が来ました。
インパクト分析として、検討すべき影響をスコープ・スケジュール・コスト・
品質・リスクの5視点から列挙してください。

【プロジェクト概要】
ECサイトのリニューアル（期間5ヶ月・残り2ヶ月）
現在フェーズ：開発・テスト中

【変更依頼の内容】
当初計画になかったポイント機能の追加（会員登録時にポイントを付与する機能）
理由：競合サービスが同様の機能を先行して出したため

【チーム構成】
PM1名・エンジニア3名・デザイナー1名

AIの出力例（要約）

【スコープへの影響】
・ポイント管理DBの設計追加が必要
・会員登録フロー・マイページへのポイント表示追加
・管理画面へのポイント操作機能追加（テスト範囲も拡大）

【スケジュールへの影響】
・設計・開発・テスト含め最低2〜3週間の追加工数が見込まれる
・現在の残期間（2ヶ月）では完了が難しい可能性がある

【コストへの影響】
・エンジニア追加工数：概算3名 × 10日 = 30人日
・外部ポイントシステムとの連携が必要な場合は別途見積もり必要

【品質・リスクへの影響】
・ポイント残高の整合性バグ（二重付与・消滅）が発生するリスク
・テスト範囲の拡大によりリリース品質への影響が出る可能性

AIの出力を叩き台に、PM自身が実態に合わせて精査・加筆します。

まとめ

変更管理の目的は「拒否」ではなく「可視化」：変更依頼を受けたら、影響を分析してから意思決定する
4ステップで処理する：受付（CR作成）→ インパクト分析 → 承認 → 計画への反映
承認フローを数値で定義する：「小・中・大」の基準と承認者をキックオフで合意しておく
口頭の変更依頼は受け付けない：すべて変更依頼書（CR）で記録することが「言った・言わない」を防ぐ
AIでインパクト分析の漏れを防ぐ：プロジェクト概要と変更内容を渡して検討チェックリストを生成、PMが精査する