変更管理・仕様変更プロセスとは？システム開発で使える5つのステップと変更要求書の書き方

システム開発プロジェクトで、こんな経験はないでしょうか。「あの画面の仕様、打ち合わせのときに変えるって言いましたよね？」「そんな話は聞いていません。変更するなら追加費用が発生します」。このような「言った・言わない」のトラブルは、変更管理プロセスが整備されていないプロジェクトで非常によく起こります。

仕様変更はシステム開発において避けられない現実です。要件定義がどれほど丁寧でも、開発が進むにつれてビジネス環境が変わり、ユーザーの要望が増え、仕様の見直しが発生します。問題は変更そのものではなく、変更を「どう管理するか」にあります。

変更を口頭や非公式なメッセージで受け付けていると、後から確認が取れない・誰が何を承認したのかわからない・スコープがどんどん膨らむという状況に陥ります。これを防ぐのが「変更管理プロセス」です。

本記事では、システム開発・ITプロジェクト管理における変更管理プロセスの基本から、明日から使える変更要求書のテンプレート、承認フローの設計方法まで、実践的にわかりやすく解説します。プロセスをゼロから整備したい方、既存の管理方法を見直したい方に向けた内容です。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

変更管理・仕様変更プロセスとは

変更管理とは何か

変更管理（チェンジマネジメント・コントロール）とは、プロジェクトや ITシステムに対して発生する変更要求を、体系的に評価・承認・記録・実施するプロセスのことです。

システム開発の文脈では、次のような変更が主な対象になります。

• 機能の追加・削除・修正
• 画面仕様・データ仕様の変更
• スケジュールや工数の変更
• システムの非機能要件（性能・セキュリティなど）の変更

変更管理の目的は「変更を禁止すること」ではありません。必要な変更を素早く・正確に・記録しながら取り込むことが目的です。

仕様変更プロセスとの関係

「仕様変更」と「変更管理プロセス」は混同されることがありますが、整理すると次のようになります。

• 仕様変更: 合意済みの要件・仕様を修正するという「行為」そのもの
• 変更管理プロセス: その仕様変更を適切に処理するための「仕組み・手順」

仕様変更は必ず発生しますが、変更管理プロセスがなければその変更を安全にコントロールできません。変更管理プロセスとは、仕様変更という現象に対処するためのルールセットです。

なぜ変更管理プロセスが必要なのか

変更管理プロセスが必要な理由は、大きく3つあります。

1. 変更の影響を事前に把握するため 仕様の一部を変更すると、思わぬ箇所に影響が波及することがあります。影響範囲を事前に分析することで、予期せぬ障害やコスト超過を防げます。

2. 合意と承認の証跡を残すため 「誰が・いつ・何を・なぜ」変更したのかを記録することで、後からのトラブル（追加費用の争い、責任の所在など）を防ぎます。

3. スコープの肥大化（スコープクリープ）を防ぐため 小さな変更が積み重なって気がつくとプロジェクトのスコープが当初より大幅に膨らんでいる——これが「スコープクリープ」と呼ばれる現象です。変更管理プロセスはスコープクリープへの最も有効な対策のひとつです。

変更管理なしのプロジェクトで起きること

変更管理プロセスが整備されていないプロジェクトでは、具体的にどのような問題が起きるのでしょうか。

口頭合意がトラブルの温床になる

変更の依頼が「口頭」「メッセージアプリ」「メール」でバラバラに届き、正式な記録がない状態で開発が進む——このパターンは多くのプロジェクトで見られます。

後から問題になるのは、合意の内容が人によって記憶が異なること、そして「誰が承認したのか」が不明なことです。特にシステム開発の受発注関係では、追加費用を巡るトラブルに発展することも少なくありません。

弁護士法人内田・鮫島法律事務所の資料によれば、システム開発の追加費用トラブルの多くは「仕様変更・開発スコープ変更に対する追加請求」に関わるもので（IT法務.COM参照）、変更の合意証跡がないことが根本原因となっています。

スコープクリープが起きるメカニズム

スコープクリープが発生するメカニズムはシンプルです。

1. 「これくらいの変更なら大丈夫」という判断が非公式に行われる
2. 変更が記録されず、累積量が把握されない
3. 気がつくと当初のスコープより大幅に作業量が増えている

アトラシアン社の資料によると、スコープクリープの原因のひとつは「変更管理プロセスの欠如」とされています（Atlassian参照）。

変更管理なしでは、各変更の工数・費用・スケジュール影響が見えないため、気づいたときには手遅れになりがちです。

「ついでに」が積み重なって炎上するまで

「この機能、ちょっと使いにくいから少し直してもらえますか」「前回の打ち合わせで言いましたよね？」——こうした「ついでの変更」が積み重なると、開発チームはどんどん追い詰められます。

担当エンジニアは変更を個々に対応しているため、全体への影響を把握している人がいない状態になります。結果として、予期せぬバグが増え、品質が下がり、最終的にプロジェクトが炎上します。変更管理プロセスは、こうした「小さな地雷」を事前に発見するための仕組みでもあります。

変更管理プロセスの5つのステップ

変更管理プロセスは、次の5つのステップで構成されます。各ステップで「誰が・何を・どうするか」を明確にすることが重要です。

ステップ1: 変更要求の受付・起票（変更要求書の作成）

変更のプロセスは「変更要求書（RFC: Request for Change）」の起票から始まります。口頭やメッセージの変更依頼を受け付けた場合も、必ずこの変更要求書に転記してもらうことがルールです。

変更要求書には次の情報を記載します（詳細は後述）。

• 変更の概要と詳細
• 変更を要求した理由・背景
• 変更の優先度
• 要求者と日付

ポイント: 「書いてもらうのが面倒」という声が出る場合は、フォームやテンプレートをシンプルにすることが重要です。入力項目が多すぎると、関係者が非公式な経路で変更を依頼するようになります。

ステップ2: 影響範囲の分析（インパクト分析）

変更要求を受け取ったら、次にその変更が及ぼす影響（インパクト）を分析します。分析では「QCDトライアングル」の視点で評価します。

• Q（Quality / 品質）: 他の機能・仕様に与える影響はないか
• C（Cost / コスト）: 追加費用はどのくらい発生するか
• D（Delivery / 納期）: スケジュールへの影響はどのくらいか

インパクト分析は開発側の担当者またはPMが行い、その結果を変更要求書に追記します。

ポイント: 影響分析は「正確に」よりも「素早く・おおよその規模感を把握する」ことを優先します。詳細な見積もりは承認後に行えばよいため、分析段階では概算で構いません。

ステップ3: 審議と承認（CCBまたは承認者による意思決定）

インパクト分析が完了したら、変更を承認するかどうかを意思決定します。大規模なプロジェクトでは「CCB（変更管理委員会: Change Control Board）」と呼ばれる承認組織を設けます。

CCBはプロジェクトマネージャー、顧客（発注者）代表、技術リーダーなどで構成され、変更の承認・否認・保留を決定します（CCBの詳細はsint.co.jpの解説を参照）。

中小規模のプロジェクトでは、CCBの代わりに「PM + 顧客窓口」の2者承認でも機能します。重要なのは「誰が最終的に承認したか」を記録することです。

承認の結果は「承認」「否認」「条件付き承認（修正を加えて再提出）」の3種類になります。

ステップ4: 計画への反映と実施

変更が承認されたら、プロジェクト計画（WBS・スケジュール・予算）に変更内容を反映します。

• WBSに変更作業のタスクを追加
• スケジュールを更新（マイルストーン・リリース日の調整）
• 変更に伴うコスト増加を予算計画に反映
• 変更内容を開発チームに正式に共有

変更を「口頭でエンジニアに伝えた」だけで計画に反映しないのは危険です。後から「そんな変更を承認した覚えがない」というトラブルにつながります。

ステップ5: 記録・クローズと振り返り

変更の実施が完了したら、変更要求書のステータスを「クローズ」に更新し、変更管理台帳に記録します。

変更管理台帳は変更の全履歴を一覧管理するものです。後からの監査対応・トラブル対応に活用できます。また、プロジェクト終了後の振り返り（KPT）で「どんな変更が多かったか」を分析することで、次のプロジェクトの品質向上につながります。

変更要求書（変更依頼書）の書き方と必須項目

変更要求書に含めるべき必須項目

変更要求書は「変更の事実を記録する」ためのドキュメントです。次の項目を含めると実用的です。

インパクト分析（QCDへの影響）の書き方

インパクト分析で最も重要なのは「工数と費用の概算」と「他機能への波及影響」です。

工数の概算: 変更の規模感をTシャツサイジング（S/M/L/XL）や時間単位で表現します。最初から詳細な見積もりを求めると分析が重くなるため、「おおよそ○時間〜○時間の追加作業が必要」という形で十分です。

他機能への波及影響: 変更する機能と連携している機能・APIを洗い出し、予期せぬ不具合が起きないかを確認します。特にデータベースの変更は波及範囲が広くなりやすいため注意が必要です。

承認者・承認フローの設計方法

承認フローは変更の規模感に応じて階層を設定するとスムーズです。以下は一例です。

「軽微な変更の閾値を事前に決める」ことは、変更管理を機動的に運用するうえで非常に重要です。全ての変更に同じ審議プロセスを求めると、現場が疲弊して変更管理プロセス自体が形骸化します。

変更管理を成功させるための3つのポイント

変更管理プロセスを「作ったけど機能しない」という状態にしないために、実践で特に重要な3つのポイントを紹介します。

ポイント1: 変更の閾値（重大変更・軽微変更）を事前に決める

前述の通り、全ての変更を同じプロセスで管理しようとすると現場が回らなくなります。プロジェクト開始前に「この規模の変更はPM単独で承認できる」「この規模は必ずCCBを通す」という閾値を決め、プロジェクト憲章や基本合意書に明記しておきましょう。

閾値の設定は「工数○時間以上は中程度以上の変更」のように数値で定義するのが理想です。曖昧な基準は現場での判断にブレが生じます。

ポイント2: 変更管理台帳で全変更を可視化する

変更管理台帳とは、プロジェクト中に発生した全変更要求を一覧管理するシートです。Excelやスプレッドシートで十分機能します。

台帳には次の情報を記録します。

• 変更番号・起票日・要求者
• 変更概要・ステータス
• QCDへの影響（累積）
• 承認者・承認日

台帳を定期的に確認することで「最近変更が多すぎないか」「QCDへの累積影響はどのくらいか」を把握できます。変更管理台帳は週次の進捗会議で確認する習慣をつけると効果的です。

ポイント3: 変更管理プロセスをプロジェクト開始前に関係者全員で合意する

変更管理プロセスが機能しない最大の理由のひとつは「そんなプロセスがあること自体を知らなかった」という関係者の存在です。

プロジェクトキックオフのタイミングで、変更管理プロセスの存在・変更要求書の提出方法・承認フローを全関係者に共有し、合意を取ることが重要です。

可能であれば、変更管理プロセスの内容を契約書・基本合意書・プロジェクト憲章に明記することが理想です。特に受発注関係のプロジェクトでは、「変更要求書なしの変更依頼には応じない」というルールを最初から合意しておくことで、後のトラブルを大幅に減らせます。

発注者・受注者それぞれの変更管理の役割

変更管理プロセスは、発注者（クライアント）と受注者（開発会社）の両方が正しく理解し、協力して運用することが前提です。

発注者側の役割と変更要求提出のルール

発注者側の担当者が変更管理において担う主な役割は次の通りです。

• 変更要求を「変更要求書」として正式に提出する
• 変更の優先度・背景・理由を明確に記載する
• 変更が承認されるまで開発変更が行われないことを認識する（口頭依頼で作業を急かさない）
• 承認済みの変更に対してのみ追加費用・スケジュール調整を受け入れる姿勢を持つ

発注者側が「ちょっとした変更」を非公式に依頼し続けると、開発会社側が実態を把握できなくなります。双方の信頼関係のためにも、変更要求書の文化を共有することが大切です。

受注者（開発会社）側の変更管理責任

受注者側には次の責任があります。

• 口頭・非公式の変更依頼を「変更要求書として正式に提出してください」と案内する
• インパクト分析を素早く行い、工数・費用・スケジュールへの影響を明確にする
• 承認された変更のみを実施し、記録を残す
• 変更管理台帳を維持し、累積QCDへの影響を可視化してクライアントに共有する

受注者が変更管理プロセスを主導することで、クライアントとの信頼関係を維持しながら適正な費用請求ができるようになります。

契約書・基本合意書への変更管理プロセス明記

経済産業省のモデル契約（情報システム・ソフトウェア取引標準）では、変更提案書の受領から所定日数以内に変更管理書を作成し、変更の詳細・費用・スケジュール影響を記載することが定められています。

受発注関係のシステム開発においては、契約書の別紙または基本合意書に「変更管理プロセス」を明記することを強くお勧めします。少なくとも次の3点を契約段階で合意しておきましょう。

1. 変更要求の提出方法（変更要求書フォームの利用）
2. 承認までのリードタイム（受領後○営業日以内に承認/否認）
3. 承認前の作業着手の禁止（承認なしの変更作業は行わない旨の確認）

仕様変更に伴う追加費用の詳細については、システム開発の仕様変更で追加費用が発生する原因と防止策も参考にしてください。

まとめ

変更管理・仕様変更プロセスについて、定義から実践的な運用方法まで解説しました。要点を整理します。

• 変更管理プロセスとは: 変更要求を体系的に評価・承認・記録・実施する仕組み
• なぜ必要か: 口頭合意のトラブル・スコープクリープ・炎上を防ぐため
• 5つのステップ: 受付→インパクト分析→審議・承認→計画反映・実施→記録・クローズ
• 変更要求書: 変更番号・概要・理由・QCDへの影響・承認者を必ず記録する
• 成功のポイント: 変更の閾値を事前に定義する、台帳で可視化する、開始前に全員で合意する

変更管理プロセスは「完璧なもの」を最初から作ろうとしなくても構いません。まず変更要求書のテンプレートを1枚用意し、「変更はこのフォームで提出する」というルールを1つ決めるだけでも大きな違いが生まれます。

小さな一歩から始め、プロジェクトを重ねながらプロセスを磨いていくことが、変更管理定着への近道です。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。