開発途中の変更費用はどう決める？発注前に確かめる作業と承認の条件

元の範囲・未確定・変更依頼・影響調査を分ける

変更費用の話を始める前に、何を基準に追加と考えるかをそろえます。次の言葉を分けると、必要な資料と、誰に何を聞くかを説明しやすくなります。

元の仕様・合意した範囲

どの仕事を、誰が、どのようにできる状態にするかについて、双方が参照する内容です。実案件では契約書、仕様書、見積りの注記などの関係を確認します。

未確定事項

契約前の時点で、詳細がまだ決まっていない部分です。後で決める時期・担当・費用への扱いまで、確認する対象にします。

変更依頼

基準となる範囲との差を示して、新しい要望や修正を相談することです。依頼しただけで、作業の開始や費用の了承が決まるわけではありません。

影響調査

追加や変更によって、どの作業、既存機能、試験、品質、日程が変わるかを調べることです。調べる作業自体の費用や回答範囲も、先に確かめます。

了承する手順

誰が、どの範囲・費用・予定を見て進めてよいと判断し、どの版を記録に残すかという確認です。社内の権限と相手方の手順を、実際の契約・合意に合わせます。

IPAの共通フレーム2013のガイダンスは、未確定要件の扱い、変更要求、影響の調査、協議と合意を分けて説明しています。この考え方を、契約前に確認する質問へ当てはめるのが本記事の方法です。2013年の資料にある条文番号や例を、そのまま現在の個別契約の義務として当てはめることはしません。

何を変更と扱うか、元の仕様へ戻って確かめる

業務要件担当は、今決まっている受発注の仕事と、まだ決まっていない所を分けて説明します。IT担当は、双方が同じ版を参照しているか、仕様と見積りの注記で範囲が食い違っていないかを確かめます。

将来の項目追加を考えるときは、画面に欄を足すだけか、その値を保存・検索・帳票・連携でも使う必要があるかを聞きます。見た目には一つの欄でも、その後の仕事や確認する範囲が変われば、頼む作業の説明も変わります。この例では、追加する項目の具体名や実装方法はまだ決まっていません。

すでに含む仕事と、新しい要望を混ぜない

元の合意に含む動作ができていない場合と、合意した内容へ新しい要望を足す場合は、まず参照する資料と事実を分けます。見た目だけで同じ「変更」にまとめず、提供会社へ、どの範囲との違いを理由に、何の作業を見積もるのかを説明してもらいます。

その確認だけで、有料・無料、支払義務、契約上の責任を決めるものではありません。実際の契約文と合意内容に照らして確認し、解釈が必要な所は当事者の責任者や必要な専門家へつなぎます。相手の説明がない段階で、追加請求が正しいとも不当だとも結論づけません。

まだ決まらない所は、決め方を先に相談する

契約前に詳細をすべて決められない場合もあります。その部分を空欄のままにせず、何が未確定で、いつ、誰と決めるか、決まった内容が費用や日程へどう反映されるかを質問します。

未確定であることと、後から必ず追加費用になることは別です。逆に、未確定だから当初の金額へすべて含まれるとも言えません。後で比較する基準と、条件を見直す手順を、実際の回答として残す必要があります。

開発・試験・調整・調査の費用条件をそろえる

費用の総額だけでは、何をしてもらえるかが分かりません。変更が生じたときに、どんな作業の内訳で回答してもらうかを、契約前に聞きます。内訳を細かくすること自体を目的にせず、発注側が必要な仕事と確認範囲を説明できる形へそろえます。

開発する作業と、確かめる試験を分ける

開発は、画面の変更、保存先の変更、帳票や連携への反映など、実際に何を作り直すかを説明してもらいます。試験は、追加部分の動作だけか、影響する既機能まで含むか、どの条件で確かめるかを聞きます。

発注側が確認する仕事も分けます。提供会社の試験と、利用部門が業務で使えるかを確かめる作業は、担当も準備も同じとは限りません。発注側の資料や確認が必要なら、いつまでに何を用意するかも相談します。

周辺の調整を、金額の外へ隠さない

項目を足すために、既存データ、他社が持つ連携先、操作説明、文書の更新などを確かめる必要があるかを聞きます。「開発を含む」という回答だけで、関連する仕事がすべて入っていると扱いません。

含む作業、別の見積りになる作業、まだ分からない作業を、同じ条件で説明してもらいます。分からない所は、必要な情報と、回答する時期・担当を残します。記載がない費用を0円に置き換えて合計することは避けます。

影響を調べる作業の扱いも聞く

正確な見積りには調査が必要な場合があります。調査に何を含み、何を回答してもらえるか、調査自体に費用が発生するかを先に質問します。調査の依頼と、その後の実装の了承を分けて記録できるようにします。

調査費がある場合は、対象・回答範囲・金額や上限の扱い・了承する人を、実際の契約先に確認します。この記事では調査費、標準単価、所要日数を決めていません。無償の調査を当然の前提にすることも、有償と決めつけることもせず、回答を条件へ反映します。

1. 何を作るか。追加する項目と、画面・保存・帳票・連携などへの関係を説明します。
2. 何を確かめるか。追加部分と影響する既機能の試験、利用部門の確認を分けます。
3. 周辺で何が変わるか。資料や操作説明、ほかの担当との調整が入るかを聞きます。
4. 見積りまでの調査をどう頼むか。調査の対象、回答、費用、了承を先に確かめます。

日程と品質への影響、誰が了承するかを聞く

費用が回答されても、元の予定や確認作業への影響が未回答なら、その条件で進めるかを判断できません。作る期間、試験する期間、発注側で確かめる期間を分け、着手できる条件と、既存の計画へどう反映するかを聞きます。

実装の作業量だけを、使い始められる日付へ置き換えません。既機能への影響確認、連携先の調整、発注側の準備が必要かで、全体の予定が変わることがあるためです。影響がないという結論も、調査回答がないまま補いません。

要望を出す人、調べる人、判断する人を区別する

業務要件担当は、その項目を何のために使い、どこまで必要かを説明します。提供会社の窓口や開発担当には、必要な作業、試験、日程や品質への影響を調べてもらいます。IT発注担当は、それらの回答を同じ版でまとめ、社内で判断する人へつなぎます。

最終的に誰が了承できるかは、社内の権限や個別契約の手順で確認します。要望を出した人、窓口へ取り次いだ人、費用回答を受け取った人を、そのまま了承者として記録しません。この架空例には、具体的な担当者名や実際の了承はありません。

何を記録すれば、後から同じ条件へ戻れるか

変更の対象、参照した仕様と見積りの版、費用の内訳、日程と試験への影響、未決事項、判断した人と日付を結びます。どの媒体で文書として残し、関係者へどう知らせるかも相談します。

これは、案件の条件を確認しやすくするための説明です。特定の書面を作れば自動的に契約変更が成立する、という意味ではありません。実際に必要な手順と記録は、当事者が契約に合わせて確かめます。

確認項目の下書きと、記載がない状態を読み分ける

確認項目を書いた架空の下書きでは、変更の境界・作業の内訳・影響・了承について、相手へ何を聞くかが具体的です。記載がない下書きと同じ項目で比べます。確認項目があることと、取引先との契約・費用の合意があることは分けて読みます。

次は、何を質問にするかを考えるための架空の下書きです。二つの実在ベンダーの回答や、契約条文の良し悪しを比べる表ではありません。確認項目を書いた状態でも、取引先がその条件を受け入れたことにはなりません。

「開発と試験を分けた回答を求める案」と書いてあれば、どんな回答が必要かを相談できます。確認項目の下書きがあることと、契約や費用の合意があることを区別します。

記載がない下書きから分かるのは、この資料だけでは条件を確認できないということです。無料、対象外、回答拒否、違法などへ読み替えず、原文や相手の回答を確認します。分からない所を都合のよい条件で埋めないことが、比較の出発点です。

図で、追加したい項目と確認する仕事を結ぶ

解説図を原寸で見る

この図を読んだ後の判断：項目追加を、費用だけの質問にせず、必要な作業と試験、影響、了承の条件へ分けて説明できます。実際の取引先の条件と価格は未確認です。IT発注担当と業務要件担当は、元の資料と質問を契約先へ渡し、回答が得られた所から図と文章を同じ内容へ更新します。

回答で条件を更新し、未回答は保留する

契約先から説明が届いたら、同じ質問へ答えているかを読みます。「変更対応を含む」だけでは、どの作業、どの試験、どの段階まで入るかが曖昧なことがあります。回答を元の仕様や見積りの版へ結び、条件が変わった所を更新します。

作業と試験の内訳が分かった場合

どの変更作業と、どの試験を含むかを、発注側の必要な仕事と照合します。たとえば、入力欄の変更だけの回答なら、保存や帳票、連携への反映が必要かを業務側へ確かめ、必要ならその範囲も含む回答を求めます。これは条件別の説明で、この架空例で回答が届いた記録ではありません。

試験についても、追加部分だけか、影響する既機能を含むかを確認します。必要な範囲を減らして金額だけをそろえるのではなく、作業の差が分かる形で比べ、変更する範囲や時期を相談します。

調査後に費用を回答する場合

調査の対象、必要な資料、費用が発生する条件、調査後の回答、了承する人を先に確かめます。調査費を了承した場合でも、実装の範囲・金額・日程まで了承したことにはなりません。どこまでを依頼したか、残る判断は何かを分けて残します。

影響や了承の手順が未回答の場合

未回答の条件を、問題なしや自動承認として扱いません。誰がいつ回答できるか、どの情報がそろえば判断できるかを確認します。発注の時点で決められない詳細は、未確定事項と、その後に決める手順として残します。

実際に追加要望が出て見積回答を受けた後は、見積回答と着手の了承を分ける手順で、今回の依頼と回答、判断の記録を結びます。発注前に確認するルールと、個別の変更を進める判断を、一つの記録として混ぜないようにします。

契約前に聞く文面を、元の範囲から作る

契約先へは、「変更はいくらですか」とだけ聞くより、基準となる資料、未確定の所、想定する追加の仕事を添えます。次は質問の書き方を示す架空例です。実際の契約条項や送信済みの依頼、合意した条件ではありません。

発注前の確認文の例（未確定）

受発注システムの入力項目を、開発途中で追加する可能性があります。まず、元の範囲として参照する仕様書・見積りの版と、詳細が未確定の部分を確認したいです。

項目追加を検討する際に、画面・保存・帳票・連携などの変更作業と、追加部分・影響する既機能の試験を、どのような内訳で回答していただけますか。調整や文書の更新、発注側の確認がどこまで含まれるかも教えてください。

影響を調べる作業の対象、費用が発生する条件、調査後に回答する範囲、日程と既機能・品質への影響の示し方を確認したいです。誰がどの条件を了承し、どの版の文書へ残すか、未回答の所をいつ誰と決めるかも相談させてください。

回答が得られたら、この文面の未確定部分と、比較する条件を同じ内容へ直します。前の回答の金額と、後の回答の日程だけを組み合わせず、どの版で確認した条件かを残します。

質問を送り、担当者名を記録しただけでは終わりません。必要な作業と試験が条件に入るか、日程への影響を判断できるか、了承する手順を説明できるかまで読み返します。契約文の解釈や支払義務に関わる判断は、実際の原文をもとに当事者の責任者や必要な専門家と確認します。

まとめ：変更の境界・内訳・影響・了承を確かめる

開発途中の変更費用に備えるには、契約前に、元の仕様と未確定事項を分けます。そのうえで、何を変更と扱うか、開発と試験を含む作業、調査や調整の扱い、日程・品質への影響、了承する人と記録を、同じ条件で確かめます。

記載がない所を無料や対象外にせず、確認項目を書いただけで実際の取引条件や合意になったとも扱いません。回答が得られた所は版と根拠を結び、未回答は確認先と次の質問を残して保留します。