「ここを直して」と言ったら追加見積りが届いた。不具合と仕様変更の分け方

たとえば、開発中の画面を見て「ここを直してください」と伝えたら、追加見積りが届いた（想定例）。発注者には修正のつもりでも、開発側は新しい依頼と受け取っている。このとき、金額だけを先に交渉しても、何の作業に対する費用かが定まりません。

合意が曖昧なら「未確定」として調べます。変更だから必ず別料金、不具合と呼べば必ず無償、とは一律に決めません。

個別の費用負担は、契約内容と事実関係から判断します。

同じ「修正」でも、見る資料は違います。

依頼	まず見るもの	この例の扱い
値引き後3,400円のはずが3,600円になる	合意した計算式と、同じ入力での結果	不具合候補として修正手続へ
初回対象外だった状態検索を追加したい	対象外とした合意	新しい要望。影響を見て先送りも選ぶ
利用者を100人に増やしたい	登録人数と同時利用人数の元の合意	元条件が曖昧なので、分類から保留

「合意と違う」「条件を変える」「機能を加える」

まず、依頼を「合意どおり動かない」「合意済みの条件を変える」「新しい機能を加える」に分けます。後二つは、どちらも合意範囲の変更になり得ます。ただし、必要な資料が不足しているときは、無理に三つのどれかへ押し込まず、未確定として残します。

たとえば、値引きを差し引くと決めた金額が値引き前で表示されるなら、合意した動作を実現する修正から見ます。利用人数の条件を増やすなら、条件変更です。初回対象外と合意した検索条件を追加するなら、新しい要望として整理します。いずれも、作業量の大小だけでは区別できません。

IPAの第二版は、契約不適合、報酬、成果報酬型準委任、協力義務、再構築などを別の論点として扱っています。契約不適合とは、契約で求められる内容に適合していないことです。「請負だから全部無料」「準委任だから必ず時間払い」と契約名だけで決めず、何を約束し、どの条件で対価が発生するかを読みます（出典：IPA「情報システム・モデル取引・契約書（第二版）」、見直しのポイント・利用時の注意事項）。

以下の分類と記入欄は、IPA資料を踏まえた本記事の整理方法です。

何を合意したか分かる資料

契約書・個別契約には範囲、報酬、変更手続が、仕様書や画面案には動作の具体像が書かれています。議事メモは決定の経緯、受入条件は試す結果を補います。これらは役割の異なる資料です。どれか一つだけを見て結論を出さず、契約での位置づけや優先順位の定めも確かめます。

集める際は、資料名だけでなく、版、日付、該当箇所、承認者、承認された範囲をそろえます。画面案に項目があることと、その機能の実装まで承認されたことは分けて確認してください。「仕様書にない」だけで対象外とせず、提案書や合意記録も照合します。

たとえば、見積条件が「登録20人・同時利用5人」、議事メモが「20人利用」なら、後者がどちらの人数を意味するかを残します。都合のよい数字へ統一せず、「最終合意に採用した条件が不明」と記録し、双方の責任者に確認します。今回ほしい条件も、登録人数と同時利用数を分けて書きます。

IPAの講演資料には、仕様等の変更、未確定事項、変更管理を分けたモデル条項が掲載されています。本記事でも、資料の不一致と、当初から決定を先送りした事項は区別して残します。どちらも、名称だけで追加費用を確定させる理由にはしません（出典：IPA「システム開発の健全化に向けて」（PDF）、pp.55–57、モデル契約第33・34・36・37条）。

元の要求そのものが言葉になっていない場合は、開発相談前の要件整理｜受注から出荷の記入例で、目的・利用者・例外の整理から戻れます。

検索条件、計算式、利用人数の三つのケース

三つのケースを、元の合意と今回ほしい結果から整理します。分類した後に、実際の契約条件から費用負担を確かめます。

記入例の日付は2026年9月15日です。配布Excelには、元の合意資料と変更票の版も記入しています。

ケース1：検索条件の追加は、対象外の合意から見る

表1　検索条件の追加を整理する（想定例）

項目	記入例
元の合意	画面仕様v1.2：検索は伝票番号と期間。状態検索は初回対象外として双方承認。
今回の要求・動作	既存の二条件は動く想定。対応状態を一つ選び、既存条件と組み合わせて検索したい。
不具合・変更・未確定	変更（新しい要望）。初回対象外という合意が記録に残っている想定。
費用と納期の影響	説明用試算は80,000円（税別）、承認後5営業日で試験環境へ。現行納期への影響は未合意。
合意する内容	空欄は全状態、閲覧権限は維持。今期は先送りし、実装は承認しない。
前提・未確定	既存データが三つの状態値に統一されている前提。差異があれば再見積り。当初対象なら分類を見直す。

検索欄の追加でも、保存済みデータ、閲覧権限、外部連携、検索結果の点検まで調べます。状態値の変換が必要なら、既存データの移行と検証も別に試算します。この例の8万円は、調査2時間、実装4時間、テスト3時間、反映準備1時間を、仮の単価8,000円／時間で計算したものです。合計10時間と、待ち時間等を含む5営業日は別の指標です。

ケース2：誤計算の修正は、新しい計算ルールと分ける

表2　誤計算の修正を整理する（想定例）

項目	記入例
元の合意	計算仕様v1.1：金額は「単価×数量−伝票単位の値引き」。税計算はこの例の対象外。
今回の要求・動作	単価1,200円、数量3、値引き200円なら3,400円。想定画面は3,600円で、値引き分を直したい。
不具合・変更・未確定	不具合候補。合意した式と、同じ入力条件での結果を照合する。
費用と納期の影響	追加機能とせず、まず契約内の修正手続に沿う。費用負担・完了日は不明。
合意する内容	再現条件、原因調査、修正範囲、再テストを合意。有償追加作業の承認は保留。
前提・未確定	同時に新しい値引きルールを希望する場合は別件。原因、過去データへの影響、契約条件は未確定。

ここでは「さらに数量別の値引きもしたい」を混ぜません。元の式へ直す依頼と、新しい業務ルールの追加を別の票にすれば、修正に追加機能の費用が含まれていないかも確かめられます。画面だけでなく、保存額や帳票へ同じ誤りが伝わるかも確認対象です。

ケース3：利用人数の増加は、人数の意味からそろえる

表3　利用人数の増加を整理する（想定例）

項目	記入例
元の合意	見積条件v1.0は登録20人・同時5人。議事メモv1.1は「20人利用」で、最終合意の条件が不明。
今回の要求・動作	登録100人・同時20人で使いたい。現行の性能と新条件での動作は未測定。
不具合・変更・未確定	未確定。元の条件が20人・同時5人と分かれば、条件変更として検討する。
費用と納期の影響	初期改修、継続利用料、負荷試験、納期への影響は不明。人数比だけで算出しない。
合意する内容	人数の指標、データ量、応答条件、試験環境を確定。増員は保留し、調査の範囲と費用を先に協議。
前提・未確定	100人・同時20人が既に合意済みなら不具合の判定へ戻る。外部サービスの利用条件は未確定。

利用アカウントの数と、同じ時間に操作する人数は分けます。契約担当から利用許諾や課金条件を、運用担当から利用時間帯を、開発側から試験方法と環境条件を集めます。増員時の性能は、資料を読んだだけでは実測済みにできません（出典：IPA「情報システム・モデル取引・契約書（第二版）」、論点・適用範囲／IPA「システム開発の健全化に向けて」（PDF）、p.57）。

依頼を受けた後に、何の作業を認めるか

変更票には、何を調べ、何を実施するかを残します。依頼を受け付けた段階、調査を許可した段階、実装を承認した段階を区別し、契約で定めた承認者と方法に合わせて記録します。調査自体の費用も不明なら、先に対象と上限を協議します。

IPAのアジャイル開発向けの説明には、開発対象の大枠内の変更と、大枠を変える変更とで手続を分ける例があります（出典：IPA「システム開発の健全化に向けて」（PDF）、p.46・p.48）。自分たちの契約に定めた変更手続に合わせ、実施の可否と条件を決めます。

記入例と空欄票は、判断表・変更依頼票（Excel）から利用できます。

表4は、表1の検索条件追加を今期は実施しないと決めた記入例です。空欄版では、不明な欄をゼロ円や影響なしで埋めないでください。

表4　変更依頼票の記入例：今期は先送り

記入項目	記入例
管理番号・目的	CR-001 v1.0／未対応の伝票を探せるようにする。
元資料・依頼内容	画面仕様v1.2。対応状態の単一選択を追加し、伝票番号・期間と組み合わせる。
対象・受入条件	状態は未対応・対応中・完了。空欄は全状態。閲覧できる伝票だけが検索結果に出る。
対象外・前提	保存項目の新設、CSV出力との連動は対象外。既存データの状態値が統一されている前提。
費用・納期	説明用試算80,000円（税別）。承認後5営業日で試験環境へ。現行納期との調整は未合意。
未確定・問い合わせ先	状態値の揺れは開発側へ、次期の優先順位は発注側業務責任者へ問い合わせる。
実施可否・理由	今期は先送り。現行納期を優先し、次期に範囲と日程を見直す。
承認記録（想定）	2026-09-15、双方の責任者が先送りのみ合意。実装は未承認。調査発注も別に決める。

追加見積りには、作業の内訳、前提、初期費用と継続費用、何が変わると再見積りになるかを求めます。実施するなら、修正した仕様・受入条件の版と確認担当も残します。「お願いします」という返信だけで、どの範囲の承認かが曖昧にならないようにします。建設・リフォームの追加工事でも、見積りの変更と施主の承認を同じ形で残します（追加工事の記録のつなぎ方）。

テストの結果と再確認条件の書き方は、システムの受入テスト・検収で確かめることに整理されています。

追加費用を払うほかに、先送りや範囲交換も選べる

予算や期限に収まらないときは、追加費用を受け入れる以外の進め方も比べます。費用負担の扱いは、選ぶ範囲と契約条件に合わせて協議します。

先送りは、次の公開や予算の時期まで実施を待つ選択です。表4が該当します。範囲交換は、未着手の別機能を外して必要な変更へ振り替える選択ですが、既に使った工数や契約上の精算条件があるため、外した機能の見積り額がそのまま相殺できるとは限りません。

表1の目的は、未対応の伝票を探すことです。今期は状態検索を追加せず、既存の伝票番号・期間検索で一覧を絞り、担当者が状態を目で見る方法を比べます。その時間と見落としが許容できるなら、表4の先送りを選べます。難しいなら状態検索の追加へ戻ります。担当と次期の再検討日も残し、手作業を続ける負担を試算します。

反対に、予算内でも合意済みの計算が誤っている状態を、追加機能の先送りと同列には扱いません。業務への影響、暫定措置、修正の点検を別に進めます。期限を動かせるなら実施に変わる場合も、費用が収まっても必要な試験期間を取れず見送る場合もあります。

次の打ち合わせでは、元の合意資料、今回ほしい結果、分類が決まらない理由、費用と納期、対象外、承認者を一緒にそろえてください。何を変え、どこまで実施するかを双方で合意することが判断の基準です。

当初の見積りの前提をそろえ直すには、システム開発の相見積り｜条件をそろえる比較表が使えます。

NeoLogicの修正・追加開発の条件

ここまでは一般的な整理です。NeoLogicに依頼した場合は、次の条件で扱います。

開発途中に、合意済みの範囲を変える場合

NeoLogicのFAQでは、合意済みの範囲を変更・追加する際は費用と期間への影響を確認し、別途合意してから進める方針を案内しています。

不具合の修正

不具合の修正は、無償で対応します。

完成・検収後の既存機能の改善

完成・検収から1年間は、画面・操作・帳票など当社がつくった機能を、追加の費用なしで何度でも直します。別の仕事のための機能を新しく加えるときや、システム全体をつくり直すときは、別にお見積りします。

分割のお支払いが1年より長く続く場合は、最後のお支払いの期日まで対象です。途中でご利用を終えた場合は、その時点で終わります。不具合対応の対象と期間は、お見積りと個別契約で明示します。

保守・運用は開発費に含まれません。ご希望の場合は、別途お見積りし、別契約でご案内します。

新たな開発や範囲の見直しを相談する際は、元の合意、今回の要求、未確定の条件を整理してご相談ください。契約上の請求・責任に争いがある場合は、開発相談とは分けて弁護士などの専門家へ確認します。

オーダーメイドの業務システム受託開発

参考出典

• IPA「情報システム・モデル取引・契約書（第二版）」
• IPA「システム開発の健全化に向けて」（PDF）

確認日は2026-09-15です。モデル取引・契約書（第二版）は2020-12-22公開、本文資料2025-04-08更新、案内2026-09-11更新で、見直しのポイント、構成とダウンロード、利用時の注意事項を参照しています。「システム開発の健全化に向けて」は2025-04-24講演、2025-04-28公開で、PDF表示pp.43–48はアジャイル開発版、pp.55–57は変更管理条項です。モデルの手続は個別契約へ自動適用されるものではありません。