『変更要求が通らない・いつまでも揉める』を防ぐ統合変更管理：変更要求書テンプレートとCCB設計シートの型

型：変更要求書テンプレート

変更要求が通らない、あるいは同じ要求をめぐって毎回議論が揉め直すプロジェクトには、共通する手前の状態があります。要求が口頭か短いチャットの文面のまま回っていて、誰が・いつ・何を・どれくらいの影響で言ったのかが、どこにも固定されていません。判定する側も、何を基準に通すか通さないかを毎回その場で考え直しています。

下の10項目は、変更要求を受け付けた瞬間にこの状態を終わらせるための1枚です。要求が来たら、この用紙を埋めることが最初の作業になります。

変更要求書の項目構成と「書くときの基準」は、PMI関連の複数の専門メディアの解説（出典参照）を踏まえて、編集部が実務運用として構成したものです。

型：CCB（変更管理委員会）設計シート

CCB（変更管理委員会）は、変更要求の承認・却下を判断する会議体です。名前だけ置いて、誰が参加し、どこまで決めてよいかを決めずに運用すると、CCBは「集まって話す場」で終わり、変更要求は通らないまま積み残されます。下の6項目は、CCBを着手前に設計するための型です。

CCBの構成・権限・運営方法は、PMIの変更管理委員会に関する専門メディアの解説（出典参照）を踏まえて、編集部が実務運用として構成したものです。

型：統合変更管理チェックリスト（受付→評価→承認/却下→反映）

変更要求書とCCB設計シートができたら、要求が来たときに例外なく通す4段階のチェックリストです。スコープ管理の変更ルート判定フローの4段階を土台に、CCBの運営に絞って展開しています。

この4段階のどこかを省略すると、変更要求は「通らない」のではなく「どこかで止まったまま誰も気づかない」状態になります。受付と評価を飛ばしてCCBに直接かけると、判定材料が足りず結論が出ないまま持ち越されます。CCBでの判定を飛ばして現場の合意だけで進めると、スコープクリープに直結します。

なぜ変更要求は「通らない」「揉め続ける」のか

変更要求が通らない現場には、だいたい次のどれかが欠けています。

第1に、CCBに議長がいません。合議のまま意見が割れると、誰も最終判断を下せず、次回に持ち越され続けます。第2に、評価の担当が決まっておらず、影響度分析が「たぶん大丈夫」という感覚で済まされています。感覚ベースの評価は、CCBの場で技術担当から異論が出た瞬間に崩れます。第3に、判定基準が「その場の空気」になっています。コスト対効果でも技術リスクでもなく、声の大きさで決まる判定は、同じような変更でも結果が毎回変わり、次の要求者が「前回は通ったのに」と揉める原因になります。第4に、承認後の反映が1つのベースラインにしか届いていません。スコープ記述書は更新したのにWBSや予算が据え置きのままだと、承認したはずの変更がまだ「無かったこと」として扱われ続けます。

いずれも、変更要求書とCCB設計シートのどこかの欄が埋まっていないことに対応しています。揉める場所を特定するには、まずこの2枚のどこが空欄かを確認します。

変更要求書：項目ごとに迷うところ

実務でもっとも書き漏れやすいのは、影響度分析と緊急度です。影響度分析は「後で詳しく見積もる」として空欄のまま提出されがちですが、概算でもいいので起票の時点で必ず埋めます。精密な見積りが要るかどうかは、CCBで評価担当が判断すればよく、起票者が最初から精密さを求めて提出を遅らせる必要はありません。

緊急度は、起票者の自己申告と、CCBが判定する緊急度を分けて考えます。起票者が「緊急です」と書くこと自体は止めませんが、実際にCCBの定例を待てないかどうかは、評価担当の影響度分析を見てから判定します。この区別がないと、すべての要求が「緊急」として臨時CCBに持ち込まれ、臨時招集そのものが形骸化します。

判定結果の欄に却下・保留の理由を書くことも、見落としやすい項目です。理由を残さずに却下すると、同じ要求が別の担当者から再提出されたとき、CCBは同じ議論を最初からやり直すことになります。

CCBの構成：人数ではなく役割で決める

CCBの構成で起きやすい失敗は、参加人数を先に決めてしまうことです。「5人にしよう」と決めても、技術的な実現可能性を判断できる人が入っていなければ、CCBは評価を外部に丸投げするだけの会議になります。設計シートの「構成メンバー」欄は、人数ではなく役割（議長・PM・技術担当・品質保証担当・ステークホルダー代表）で埋めます。

小規模プロジェクトでは、この役割をPMと数名が兼務して構いません。重要なのは、議長にあたる最終判断者が誰かを、着手前に名前で決めておくことです。議長が決まっていないCCBは、判定が出ないまま次回に持ち越される会議になりやすく、これが「いつまでも揉める」の典型的な原因になります。

権限の線引き：CCBで決める範囲と、上申する範囲

CCBがすべての変更を自分たちだけで決めてよいわけではありません。プロジェクト憲章で定めたPMの権限レベル（単独決定・是正要求・上申）と同じ考え方で、CCBにも「どこまでなら決めてよいか」の上限を置きます。

目安は、プロジェクト憲章に書いた前提条件・制約条件が崩れるかどうかです。予算の枠内で収まる変更、スケジュールの余裕内で吸収できる変更は、CCBの判定で確定させます。逆に、予算の大幅な追加や、スコープの大枠そのものを変える要求は、CCBで評価・判定した上で、その結果をスポンサーや上位の会議体に上申します。この線引きを変更要求書の「対象のベースライン」欄と組み合わせておくと、どの変更が上申対象かを起票の時点でおおよそ判別できます。

承認後が本番：ベースラインの同時更新を忘れない

CCBが承認した時点で、作業は終わっていません。承認した変更が、スコープ記述書・WBS・予算・スケジュールという複数のベースラインのうち、どれに影響するかを変更要求書の「対象のベースライン」欄で確認し、該当するものをすべて同じタイミングで更新します。

この同時更新を忘れると、文書同士が食い違う状態が生まれます。スコープ記述書には新機能が追記されているのに、WBSにはその作業が存在せず、予算にも反映されていない。この状態は、本人が気づかないまま進み、進捗報告や予算消化の数字がどこかでつじつまが合わなくなった時点で、第三者のレビューによって初めて発覚します。変更要求書の「ベースライン反映日・反映担当」欄は、この同時更新を確実にするための欄です。

スコープ管理の変更ルート判定フローとの違い

スコープ管理の実務は、要求事項の収集からスコープ記述書の作成、変更が来たときの4段階の判定フローまでを扱っています。本記事はこの4段階のうち、承認・判定を行う会議体そのもの（CCBの構成と権限）と、受付時に使う文書そのもの（変更要求書の項目）を、着手前に設計するための型として切り出したものです。

スコープ管理の記事を読んでWBSやスコープ記述書を先に整えたプロジェクトでも、CCBの議長が決まっていなかったり、変更要求書の項目が揃っていなければ、変更が来た時点で同じように揉めます。両方の記事は競合するものではなく、スコープ管理の記事が「何を変更として扱うか」を、本記事が「誰が、どの手続きで決めるか」を担う関係にあります。

まとめ：明日やる3つ

まず、いま止まっている変更要求を1つ選び、変更要求書の10項目をその場で埋めます。空欄になった欄が、揉めている原因です。次に、CCBの議長にあたる最終判断者を名前で決め、構成メンバーを役割で埋めます。最後に、CCBで決めてよい範囲と上申する範囲の線引きを、プロジェクト憲章のPM権限レベルと照らして1行で書いておきます。この3つが揃えば、次に来る変更要求は、通る・通らないを空気で決める会議ではなく、手順で判定する会議にかけられるようになります。