開発途中で「この画面を変えたい」「連携条件を追加したい」となったとき、小さな変更に見えるからといって無償対応と決めることはできません。当初何を合意していたか、変更による影響がどこまで及ぶか、契約上どのように承認するかを分けて確認する必要があります。
この記事では、変更要望を整理し、影響調査と見積もりを踏まえて、実施・縮小・段階導入・保留を判断する方法を解説します。追加費用や納期の協議を始める前に、発注者側でそろえるべき情報と進め方を確認しましょう。
仕様変更は、当初合意との照合で要望を整理した後、影響調査と承認を経て進めます。見た目の小ささだけで無償・有償を決めないことが重要です。
01Sectionまず変更要望を3つに暫定分類する
最初にするべきことは、依頼内容を「何を変えたいか」だけでなく、「当初何を合意していたか」と照合することです。分類は費用負担や責任を決めるものではなく、確認する資料と影響調査の依頼内容を決めるための一次整理です。
IPA「情報システム・モデル取引・契約書（第二版）」は、仕様、プロジェクト管理方法、検収方法について、ユーザ企業とITベンダが共通理解のもとで対話を深めるための確認先になります。
変更時に使う基本用語
受入条件
納品物を受け取れると判断するために、事前に合意する動作、性能、帳票、テスト結果などの条件です。
検収
受入条件を満たすかを確認し、受け取りを判断する手続です。
契約不適合の可能性
成果物が合意済みの内容や品質、条件に合っていない可能性を指します。該当性は契約、仕様、検収、通知、原因の確認が必要です。
請負
一般に、仕事の完成に重点を置く契約類型です。成果物、仕様、納期、検収条件を確認します。
準委任
一般に、専門的な業務の遂行に重点を置く契約類型です。業務範囲、稼働枠、優先順位、精算条件を確認します。
| 暫定分類 | 判定質問 | 主な照合資料 | 影響調査前の扱い |
|---|---|---|---|
| 当初仕様の確認・補正 | 合意済みの目的・機能・受入条件を具体化する対応か | 要件定義書、仕様書、画面設計、議事録、受入条件 | 該当箇所を示し、実装への反映状況と影響の有無を確認する |
| 不具合・契約不適合の可能性 | 合意済み仕様または受入条件と、実際の動作が異なるか | 仕様書、テスト記録、不具合票、検収記録 | 再現条件、期待結果、実際結果、発見日を記録する |
| 新規要件・要件変更 | 新しい機能・条件・連携・性能などを追加または変更するか | 契約、見積前提、要件定義書、変更要求 | 実装依頼ではなく、影響調査と選択肢の提示を依頼する |
たとえば、合意済みの画面文言が異なるなら補正や不具合の可能性を確認します。一方、文言変更により同意取得、通知条件、多言語対応まで変わるなら、新規要件としての影響調査が必要になり得ます。帳票の新しい集計軸、連携先や認証方式の追加、合意になかった性能・監査要件の追加も同様です。
02Section無償・有償は何で分かれるか
追加費用の協議は、変更の規模だけでなく、当初の合意内容と契約・見積の前提、必要な手続をまとめて確認します。
無償・有償を変更の見た目や作業量だけで決めると、見積もりや納期の協議が曖昧になります。当初合意、変更原因、影響範囲、変更手続、精算条件を資料で確認してから協議します。
経済産業省サイト掲載の「情報システム・ソフトウェア取引トラブル事例集」は、仕様、見積前提、変更手続の曖昧さが取引上の問題につながり得ることを検討する補助資料です。
無償・有償を協議する前の確認事項
- ✓
当初仕様、受入条件、見積前提に今回の内容が含まれていたかを、文書名・版・該当箇所で確認する。
- ✓
変更が必要になった原因と、発見された工程・検収状況を整理する。
- ✓
調査、要件・設計、実装、テスト、リリース、資料更新、調整のどこへ影響するかを確認する。
- ✓
変更要求、見積、承認、追加発注または変更契約について、定められた手続を確認する。
- ✓
単価または固定額の対象範囲、精算上限、直接実費、納期影響、再見積条件を確認する。
追加見積もりは総額だけで承認せず、対象と除外事項、前提条件、工程別作業、工数または成果物、受入条件、再見積となる条件を確認します。当初合意が抽象的な場合は、「実現したい目的」「実現方法」「変更後の受入条件」を分けると協議しやすくなります。
表面上の分類だけで無償・有償を決めない
当初仕様を満たしていないように見える場合でも、直ちに無償対応と結論付けることはできません。仕様の確定度、変更が必要になった原因、検収・通知の状況、契約上の変更・修補に関する条件、影響範囲を確認して協議します。
03Section費用と納期はどう試算・比較するか
費用と納期は総額・総日数だけでなく、作業範囲、実費、承認や連携先の待機要因に分けて確認すると比較しやすくなります。
Webサービスやスマホアプリの仕様変更には、条件をそろえて比較できる全国共通の円建て相場を置きにくい面があります。既存コード、連携先、テスト範囲、リリース条件、体制、契約条件によって必要な作業が変わるためです。自社の契約または個別見積の入力値で試算します。
追加費用は、次の形で整理します。
追加費用 ＝ 追加工数 × 契約または見積上の単価 ＋ 直接実費
追加工数には、影響調査、要件・設計、実装、テスト、リリース・資料更新、関係者・連携先との調整が含まれるかを確認します。追加納期は、追加作業 ＋ 承認待ち ＋ 連携先待ち ＋ テスト・リリース枠待ちとして分けて確認します。
IPA「ITユーザとベンダのための定量的見積りの勧め」およびIPA「CoBRA法に基づく見積り支援ツール」は、規模、工数、コスト、リスクの前提を共通認識にして見積もりを検討する考え方の確認先です。市場単価や一律の標準工数を示す資料としては扱いません。
最初に影響調査を予算化する
| 試算項目 | 確認・入力する内容 | 未確定時の扱い |
|---|---|---|
| 影響調査 | 調査対象、回答項目、費用上限、回答期限 | 実装費ではなく調査だけを先に承認する |
| 追加工数 | 要件・設計、実装、テスト、リリース・資料更新、調整の追加作業 | 対象外の工程と理由を明記する |
| 単価または固定額 | 契約単価、職種別単価、固定額の対象範囲、精算上限 | 個別契約・発注書・過去見積・請求書で確認する |
| 直接実費 | 外部サービス、連携先対応、試験環境などの実費 | 工数費用と分け、発生条件を確認する |
| 除外事項・再見積条件 | 他社改修、データ修正、教育、前提未達時の扱い | 確定見積の前提または再承認条件にする |
| 納期影響 | 作業日数、承認待ち、連携先待ち、テスト・リリース枠待ち | 各待機要因の担当者と期限を置く |
単価が不明なら、実装費より先に影響調査の範囲を合意すると、予算と判断期限を管理しやすくなります。
単価が不明な場合の確認順
- Step01
個別契約・発注書を確認する
固定額、単価、精算上限、変更手続を確認します。
- Step02
過去見積・請求書を確認する
同一ベンダーの近い工程・職種について、単価と実費の扱いを確認します。
- Step03
調達・経理へ確認する
正式な単価表、追加発注の条件、承認期限を確認します。
- Step04
影響調査だけを承認する
単価や対象範囲を取得できない場合は、調査の上限・期限・回答項目を承認し、確定見積後に実装可否を再決裁します。
概算と確定見積を分ける
概算見積は、選択肢を比較するための前提付き試算です。対象、除外事項、依存先、受入条件、テスト・リリース条件が固まった後に、確定見積と実装承認へ進みます。未確定事項は、見積に含めた仮定なのか、再見積の条件なのかを明記します。
期限や予算が固定なら3案を比較する
| 比較軸 | 最小対応 | 標準対応 | 段階導入・後続化 |
|---|---|---|---|
| 解決する業務課題 | 必須条件に限定する | 品質・運用を含めて解決する | 初回の必須部分と次期対応を分ける |
| 追加費用 | 工数×単価＋実費 | 工数×単価＋実費 | 初回・次期を分けて試算する |
| 納期影響 | 固定期限に収まる範囲を確認する | 影響工程と待機要因を含めて確認する | 各回の期限と依存先を確認する |
| 品質・運用負担 | 対象外部分の暫定運用を確認する | 回帰テスト、資料更新、運用負担を含める | 初回と次期それぞれの受入条件を置く |
| 変更しない場合の影響 | 残る業務リスクを確認する | 業務上の効果と総負担を比較する | 後続化できる条件と時期を決める |
| 受入条件・承認期限 | 最小範囲で明文化する | 全対象で明文化する | 各回で明文化する |
費用だけで案を選ばず、受入条件、依存先、暫定運用の負担、変更しない場合の事業影響を同じ条件で比較します。
04Section仕様変更を揉めずに進める8ステップ
実装を急ぐ前に、影響調査と比較・承認を行い、変更後の条件をそろえてから着手する流れです。
変更管理では、実装を急ぐ前に影響を調べ、選択肢を比較し、必要事項をまとめて承認する流れが重要です。要件が固まらないまま進めると起こりやすい問題は、システム開発で起こりがちな失敗も参考にしてください。
要望を整理して影響を調べる
起票から影響調査まで
- Step01
変更要求を起票する
背景、目的、変更前後、優先度、希望期限、変更しない場合の影響、受入条件を記載します。
- Step02
当初合意を照合する
契約、発注書、見積書、仕様書、議事録、受入条件を時系列で確認します。
- Step03
暫定分類する
補正、不具合・契約不適合の可能性、新規要件、要協議に分けます。
- Step04
影響調査を依頼する
対象・除外事項、費用・納期、依存先、リスク、代替案、再見積条件の回答を求めます。
比較・承認して実装へ進む
比較からテスト・検収まで
- Step01
複数案を比較する
最小対応、標準対応、段階導入、後続化を、費用以外の軸も含めて比較します。
- Step02
5項目を一括承認する
変更後仕様、費用、納期、受入条件、承認者・着手条件を一つの承認単位にします。
- Step03
契約上必要な書面を整える
契約で定めた変更書面、追加発注、変更契約などの方法に従い、関連資料を更新します。
- Step04
テスト・検収し記録を更新する
変更箇所と影響箇所を、承認済みの受入条件とテスト記録に基づいて確認します。
合意前に実装へ着手しない
変更後仕様、費用、納期、受入条件、承認者・着手条件のいずれかが未確定なら、実装ではなく影響調査または協議を継続します。未承認着手は、費用負担、成果物の範囲、受入条件について後から争点を増やしやすくなります。
アジャイル開発を外部委託する場合も、初期計画、完了基準、品質基準、初期バックログ、役割分担、権限の確認が重要です。IPA「情報システム・モデル取引・契約書（アジャイル開発版）」は、その確認項目を検討する参考になります。
変更要求に記載する項目
背景・目的と事業影響
なぜ変更するのか、変更しない場合にどの業務・利用者へ影響するかを記載します。
変更前後の仕様と根拠資料
文書名、版、該当箇所、変更後に求める状態を示します。
対象範囲・優先度・希望期限
画面、機能、権限、データ、連携、利用者、運用への対象と優先度を明らかにします。
受入条件と確認方法
何を満たせば受け入れるか、判定者とテスト方法を決めます。
影響調査への回答依頼
費用、納期、前提、除外事項、依存先、リスク、代替案、再見積条件を求めます。
05Section請負・準委任でも、まず個別契約を確認する
請負では成果物、仕様、納期、受入・検収条件が確認の起点になり、準委任では業務範囲、対象期間、稼働枠、優先順位、精算条件が起点になります。ただし、契約名称だけで無償範囲や追加費用、依頼方法を決めることはできません。
変更前に、個別契約の作業範囲・精算上限・依頼経路・承認者を確認します。
個別契約で確認する項目
- ✓
今回の対象が、個別契約、発注書、添付仕様、見積前提に含まれるか。
- ✓
固定額または単価の対象範囲、精算上限、直接実費、再見積条件は何か。
- ✓
誰が、どの書面または経路で変更を正式に依頼・承認できるか。
- ✓
契約、発注書、見積書、仕様書、議事録が矛盾した場合の文書優先順位は何か。
- ✓
変更後の受入条件、テスト範囲、判定者、検収の扱いをどう更新するか。
文書優先順位、変更条項、検収条件を確認する際は、契約確認で押さえるべきポイントも確認してください。
スクラムを前提とするIPA「アジャイル開発外部委託モデル契約（解説付き）」では、準委任を前提に、大枠の変更は協議と書面合意の対象とし、大枠を変えない変更はバックログで扱う想定が示されています。これは同モデル契約の前提に基づく整理であり、すべてのアジャイル契約に一律に適用できるものではありません。
06Section話がまとまらないときは、証跡と期限で分岐する
追加費用、仕様解釈、品質、納期の議論が平行線になった場合は、責任を先に決めようとせず、資料を日付順に並べて争点を分けます。
対立時に整理する証跡
契約・発注・見積資料
基本契約、個別契約、発注書、見積書、見積前提を時系列で整理します。
仕様・受入条件
要件定義書、仕様書、設計資料、受入条件、テストケースを整理します。
変更に関する記録
変更要求、見積回答、承認記録、追加発注・変更書面を整理します。
コミュニケーション履歴
議事録、メール、チケットを日付・発言者・合意内容が分かる形で整理します。
品質・検収の記録
テスト結果、不具合票、検収記録、リリース記録を整理します。
協議では、次の5つを分けて確認します。①当初合意の範囲、②変更が必要になった原因、③影響範囲と見積根拠、④未承認着手の有無、⑤品質・契約不適合の可能性です。
合意期限までに確定すべき事項は、変更後仕様、費用、納期、受入条件、承認者・着手条件の5点です。5点が確定した場合は必要な書面を整えて着手します。必須機能だけ確定した場合は最小対応または段階導入を選びます。安全性や受入条件が未確定なら、着手またはリリースを保留します。契約解釈が主な論点なら法務・調達または専門家への確認を、技術・見積が主な論点なら技術レビューや再調査を検討します。承認ルールが機能していない場合は、PMや意思決定体制を見直します。
契約解釈と技術評価を混ぜない
契約・責任分担、技術的な影響と見積根拠、優先順位と進行管理では、確認すべき資料と相談の目的が異なります。論点ごとに資料を分けると、協議の次の行動を決めやすくなります。
取引条件に関する相談先を探す入口として、中小企業庁「取引上の相談窓口・講習会について」を確認できます。ただし、窓口ごとに対象となる取引や対応範囲は異なり、個別の契約トラブルの解決までは扱わない窓口もあります。中小企業庁の相談窓口一覧などで、利用前に各窓口の対象取引、対応範囲、費用を確認してください。
07Section変更依頼前に、決裁に必要な情報がそろっているか確認する
実装可否の決裁では、変更案ごとの費用、納期、品質・運用負担、変更しない場合の事業影響を同じ軸で示します。分類、影響調査、承認記録がそろっていれば、途中で条件が変わった場合も再協議の起点を残せます。
実装承認前の最終確認
- ✓
当初合意資料と照合し、変更要望を暫定分類した。
- ✓
影響調査で、対象・除外事項・依存先・リスク・再見積条件を確認した。
- ✓
最小対応、標準対応、段階導入を費用・納期・品質・運用負担・事業影響で比較した。
- ✓
変更後仕様、費用、納期、受入条件、承認者・着手条件を一括で承認した。
- ✓
契約上必要な書面、テスト範囲、検収記録、変更履歴を更新する担当と期限を決めた。
仕様変更の費用・契約で迷いやすい質問
小さな画面修正なら無償と考えてよいですか。+
修正の見た目だけでは判断できません。合意済みの画面仕様や受入条件との差分か、業務ルール・通知・権限・回帰テストまで影響する変更かを確認し、契約文言と取引経緯を踏まえて協議します。
追加見積の単価が分からない場合、何を先に承認すべきですか。+
実装費ではなく、影響調査の対象、費用上限、回答期限、回答項目を先に承認します。個別契約、発注書、過去見積・請求書、調達・経理で単価や精算条件を確認した後、確定見積を基に実装可否を再決裁します。
準委任契約なら既存の稼働枠で自由に変更を依頼できますか。+
準委任であっても、業務範囲、稼働枠、優先順位、精算上限、正式な依頼経路、承認者を確認する必要があります。変更可能であることは、無制限または無償での変更を意味しません。
契約不適合の可能性があるとき、すぐに追加費用を拒否できますか。+
該当性や対応方法は、契約、当初合意資料、成果物、検収・通知の状況、変更が必要になった原因によって異なります。まず期待結果と実際結果、根拠資料、影響範囲を整理し、必要に応じて法務・調達などへ確認します。
仕様変更の影響整理や開発体制の見直しを相談したい場合
契約資料や変更要求を整理しても、影響範囲の評価や実装方針の比較が難しい場合があります。Webアプリ・SaaS開発の支援会社を比較し、自社の状況に合う相談先を検討できます。
Webアプリ・SaaS開発4593社掲載
PartnerBase Mag 編集部
デジタル発注の比較・発注準備を専門に扱う編集チーム。
デジタル発注の比較・発注準備を専門に、依頼範囲、費用、選定基準を実務で使える粒度に整理しています。
支援会社を比較する
得意領域、対応サービス、地域、実績を見ながら候補会社を絞り込めます。
