仕様変更は、「依頼を書面で受ける」「影響を見積もる」「決める人が可否を判断する」「計画と記録を直す」の4つの順番で進めます。口頭で受けた小さな変更が積み重なると、どの変更で日程や費用が膨らんだのかが後から分からなくなり、発注側と受注側のどちらも説明がつかなくなります。情報処理推進機構（IPA）が公表している「情報システム・モデル取引・契約書」の第二版（2020年）は、システム開発の受託契約を対象に、変更の提案を書面で行い、変更の内容・費用・日程・契約の条件への影響を書いた「変更管理書」をもとに双方で協議する手続きを示しています。この記事では、その手続きをもとに、変更依頼書と変更管理表の項目、影響の見積もり方を示したうえで、仕様変更が終わらなくなる理由と直し方を説明します。

仕様変更が終わらなくなる仕組み

仕様変更そのものは、悪いことではありません。使う人の声を聞いて内容を直すのは、よい成果物を作るために必要なことです。問題になるのは、変更の受け方が決まっていないことです。

決まっていないこと起きること
依頼の窓口担当者が利用部門から直接頼まれ、取りまとめ役が知らないまま作業が増える
影響の見積もり「すぐできます」と引き受けた作業が、試験や資料の直しまで含めると数日かかる
決める人誰も断れず、すべての依頼が「対応する」になる
記録どの変更でどれだけ遅れたかが分からず、遅れの理由を説明できない

デジタル庁の「デジタル・ガバメント推進標準ガイドライン 解説書」（2026年）も、個々の変更の影響を把握せずにプロジェクトを進めると、提供の時期の遅れや質の低下を招くおそれがあるとしています。

変更管理の手順（5つの段階）

同じ解説書は、変更管理の活動として、変更の手続、変更による影響の評価、変更要求の優先順位付けと承認、緊急時の変更手続、変更結果の評価と報告、変更完了を、文書にして定めておくことを挙げています。社内の案件で使いやすい形に直すと、次の5つの段階になります。

  1. 依頼を書面で受ける：口頭やチャットで頼まれた場合も、依頼した人か受けた人が変更依頼書に書き、変更管理表に番号を付けて載せます。窓口は取りまとめ役1人に集めます
  2. 影響を見積もる：作業の担当者が、日程・費用・ほかの作業・品質への影響を見積もります。作ったものの直しだけでなく、試験のやり直し、手順書や説明資料の直し、関係者への説明まで含めます
  3. 可否を判断する：影響の大きさに応じて決めた判断者が、「受ける」「受けない」「後の段階に回す」「ほかの作業と入れ替える」のどれかを決めます。決めた理由も残します
  4. 計画と記録を直す：受けた変更は、工程表・予算・仕様書に反映し、変更の番号を書き添えます。ガントチャートの当初の予定は消さずに残します
  5. 結果を確かめて閉じる：変更が終わったら、見積もりどおりだったかを確かめ、変更管理表の状態を「完了」にします

変更依頼書の項目の見本

IPA のモデル契約の第37条は、変更の提案を受けた側が、次の事項を書いた変更管理書を相手に渡し、連絡協議会で変更の可否を協議するものとしています。

  • 変更の名称
  • 提案の責任者
  • 年月日
  • 変更の理由
  • 変更に係る仕様を含む変更の詳細事項
  • 変更のために費用を要する場合はその額
  • 検討期間を含めた変更作業のスケジュール
  • その他変更が契約の条件（作業期間又は納期、委託料、契約条項等）に与える影響

この項目をもとに、社内の案件でも使える変更依頼書の見本を作ると次のようになります。

項目書くこと誰が書くか
変更No変更管理表の番号取りまとめ役
件名何をどう変えるか依頼者
依頼者・依頼日誰がいつ頼んだか依頼者
変更の理由なぜ必要か、変えないと何が困るか依頼者
変更の内容今の仕様と変えた後の仕様依頼者（担当者が補う）
急ぎかどうか希望の時期と、その理由依頼者
日程への影響何日延びるか、どの節目に響くか作業の担当者
費用への影響追加の費用や人手作業の担当者
ほかへの影響試験・資料・ほかの機能・運用への影響作業の担当者
判断受ける・受けない・後回し・入れ替え判断者
判断者・判断日・理由誰がいつ、なぜそう決めたか判断者

変更管理表の見本

変更依頼書は1件ごとの書類で、変更管理表はそれを一覧にしたものです。

No件名依頼者日程への影響費用への影響判断判断者状態
3受注画面に納品先の欄を足す営業部3日追加なし（予備の日数で吸収）受ける取りまとめ役完了
4請求書の書式を取引先ごとに変える経理部3週間追加あり後回し（本番の後に検討）オーナー保留
5在庫の引当を自動にする物流部2か月追加あり受けない（範囲外）オーナー見送り

「受けない」「後回し」になった依頼も、行を消さずに残します。同じ依頼が別の人から来たときに、前回の判断と理由をすぐに示せます。

伎冶商事合同会社（当サイトの運営会社）のサービスのご案内

話す・決める・進める。毎日の仕事を、ひとつのアカウントで。TalkLogs社内チャットPhaseLogsプロジェクト管理ThinkLogs会議のボード3名までずっと無料・クレジットカード登録不要BORDERCROSS を見る

誰が判断するかを先に決める

変更のたびに誰が決めるかを話し合っていると、判断そのものが遅れます。影響の大きさで判断者を分け、立ち上げの時点で決めておきます。

影響の大きさ判断者の例
節目の日程も費用も変わらない取りまとめ役
節目の日程が変わる、または予備の日数や予算の範囲で費用が増えるオーナー
予算を超える、範囲や目的が変わる、契約の条件が変わるオーナー（必要に応じて経営会議）と、取引先との協議

判断を上げる基準の作り方はプロジェクト立ち上げの手順でも扱っています。段階ごとに予算を承認する考え方はシステム開発の段階的な予算承認の設計が参考になります。

取引先との契約にかかわる注意

外部の会社に開発を頼んでいる場合、変更の内容によっては契約の変更が必要になります。デジタル庁の解説書も、変更の内容によっては事業者との契約の変更が必要になることがあり、その際は定められた契約変更の手続きを行うとしています。IPA のモデル契約は、第34条で仕様書などの変更は第37条の変更管理手続によってのみ行うと定め、第38条で協議が調わない場合の契約の終了についての考え方を示しています。

同じ IPA の講演資料（2025年）は、発注側から変更の提案を受けた受注側は、変更による影響を十分に分析して発注側に説明し、本当にその変更を行うべきかを慎重に協議する必要があるとしています。分析や説明をしないまま変更に応じて遅れや不具合が生じた場合には、受注側が責任を負う可能性があるとも説明しています。自社の契約がどのように定めているか、個別の変更で費用や責任をどう扱うかは、契約書を確かめ、必要に応じて専門家に相談してください。

自社の変更管理を点検するチェックリスト

  • 変更の依頼を受ける窓口が1人に決まっている
  • 口頭で受けた依頼も、その日のうちに書面にしている
  • 影響の見積もりに、試験・資料・説明の手間が含まれている
  • 影響の大きさごとに、判断者が決まっている
  • 「受けない」「後回し」にした依頼も記録に残っている
  • 受けた変更が、工程表・予算・仕様書に反映されている
  • 契約の変更が要るかどうかを確かめる手順がある

仕様変更が終わらない理由と直し方

担当者が直接頼まれて受けてしまう

利用部門と作業の担当者が近い関係にあると、「ちょっとここを変えて」という依頼が取りまとめ役を通らずに流れます。1件ずつは小さくても、積み重なると日程が崩れます。窓口を1人に集め、担当者が直接頼まれた場合も「変更管理表に載せてから着手する」ことを決まりにします。

見積もりが作業の直しだけになっている

画面の項目を1つ足すだけに見える変更でも、試験のやり直し、手順書の直し、利用者への説明が付いてきます。影響の見積もりの欄を「作業」「試験」「資料」「説明」に分けておくと、見落としが減ります。

「やらないこと」が決まっていない

範囲の外にあることが文書になっていないと、どの依頼も「もともと含まれていたはず」と言われ、変更として扱えません。立ち上げの段階で範囲と「やらないこと」を文書にし、発注側と受注側で合意しておきます。

課題と変更が混ざる

課題の検討の結果が「仕様を変える」になったのに、課題管理表で閉じただけで計画に反映されないことがあります。課題の結論が計画や仕様を変えるときは、変更管理表に回して番号を付けます。課題の扱いは課題管理表の作り方で説明しています。

実行時の落とし穴

  • 手続きを重くしすぎる：小さな変更にまで何人もの承認を求めると、依頼する側が手続きを避け、口頭での依頼に戻ります。影響の小さい変更は、取りまとめ役の判断で受けて記録だけ残せるようにします
  • 決定を共有しない：判断の結果が依頼者にしか伝わらないと、ほかの関係者は変更を知らないまま作業を進めます。決まった変更は定例の場で共有します。決定の残し方は会議の決定事項の共有方法で扱っています
  • 予備の日数を黙って使う：変更を工程表の予備の日数で吸収するときも、どの変更で何日使ったかを記録します。工程表での予備の置き方はガントチャートの作り方で説明しています

意思決定に関するほかの記事は意思決定・リーダーシップからご覧いただけます。

出典