変更管理のプロセス
「ちょっとだけ直してほしい」「この画面に項目を1つ足すだけ」。変更の依頼は、たいてい小さく、断りにくい形でやってきます。
変更管理とは、こうした依頼を止めるための仕組みではありません。変更を受けるかどうかを、組織として判断できる状態にするための仕組みです。目的を取り違えると、「変更管理＝面倒な手続き」という運用になり、結局は誰も通さなくなります。
■ 変更管理がないとどうなるか
手続きが決まっていない現場では、変更は現場の善意で吸収されます。担当者が「まあ、このくらいなら」と引き受け、残業で埋める。一件ごとは小さいので、誰も報告しません。
問題は、これが積み重なったときに起きます。遅れが表面化した時点で、増えた作業量を把握している人が誰もいない。原因が説明できないため、「見積りが甘かった」「管理ができていない」という話に着地してしまいます。実際には、承認なしにスコープが膨らんでいただけです。
■ 変更が通る道をつくる
この5つのうち、現場で省略されがちなのは1と5です。
1を省略すると、そもそも変更があったという記録が残りません。5を省略すると、変更が関係者に伝わらず、古い前提のまま作業を続ける人が出ます。地味ですが、この2つが欠けると仕組み全体が機能しません。
■ 影響分析で見るべき5つの軸
変更要求を受けたら、次の観点で影響を見積もります。「工数が何人日増えるか」だけでは足りません。
スコープ：他の機能や成果物に波及しないか
スケジュール：クリティカルパス上の作業に影響するか。するなら納期が動く
コスト：追加工数と、それに伴う費用
品質：テスト範囲がどれだけ増えるか。再テストの手間を忘れやすい
リスク：新たに生じるリスクはないか。既存のリスクが大きくならないか
とくに見落とされるのが品質です。機能を1つ足すと、その機能のテストだけでなく、影響範囲の回帰テストが必要になります。「実装は半日」でも「テストを含めると3日」ということは珍しくありません。
■ 誰が判断するのかを決めておく
変更管理委員会（CCB：Change Control Board）という言葉が使われますが、大げさな組織を作る必要はありません。重要なのは判断者が事前に決まっていることです。
金額・日数の小さい変更は、PMの裁量で決める（閾値を決めておく）
それを超える変更は、プロジェクトオーナーが判断する
納期やコストの前提が変わる変更は、発注者と受注者の双方が合意する
この閾値を決めていないと、すべての変更が上に上がるか、すべてがPMの判断で処理されるか、どちらかに振れます。前者は動きが止まり、後者は責任がPM一人に集中します。
■ ベースラインという考え方
変更管理が成り立つ前提は、「変更前の状態」が定義されていることです。これをベースラインと呼びます。
スコープ、スケジュール、予算のそれぞれにベースラインを置き、承認された変更が入ったときだけ更新します。ベースラインを都度上書きしていくと、当初の計画との差が消え、「どれだけ変わったのか」を誰も説明できなくなります。
承認済みの変更だけを反映する、というのがここでの原則です。反映されていない変更が混ざっていると、実績との比較が意味を失います。
■ 運用を軽くする工夫
手続きが重すぎると、現場は迂回します。実務では次のような調整が有効です。
書式は1枚に収める：起票のハードルを下げる。項目は、内容・理由・希望時期・起票者で足りる
審議を定例に組み込む：都度会議を招集するのではなく、週次の定例に審議枠を置く
緊急時の簡易ルートを用意する：障害対応など待てない変更は、先に実施して事後に起票するルートを決めておく
却下も記録する：「検討したが見送った」という記録が、後から同じ議論を繰り返すことを防ぐ
■ PMの立ち位置
変更管理の仕組みがもたらす最大の効果は、PMが判断する人から、判断材料を示す人になれることです。
「その変更はお受けできません」と個人として断るのは、角が立つうえに、断る理由を自分で背負うことになります。一方、「この変更には追加で12人日、納期に5日の影響が出ます。実施するかどうかをご判断ください」と示すのであれば、対立は起きません。判断は依頼した側に戻ります。
■ チェックリスト
変更要求の書式があるか（1枚で済むか）
PMの裁量範囲が金額・日数で決まっているか
影響分析に品質・リスクの観点が入っているか
スコープ・日程・予算のベースラインが保存されているか
却下した変更も記録しているか
承認された変更が関係者に周知されているか
変更そのものは悪いことではありません。状況が変われば、計画も変わるべきです。問題になるのは、変更が見えないまま進むことのほうです。変更管理は、それを見えるようにするための最小限の手続きだと考えると、運用しやすくなります。