業務システム開発の修正を何回まで受けるか｜先に決めておく

2026年3月4日

朝比奈蒼

この記事のポイント

✓業務システム開発修正対応で消耗しないための決め方をまとめました
✓修正と追加開発の線引き
✓見積書と契約書に書く文言

業務システム開発の修正対応で消耗している人の相談は、ほぼ同じ形をしています。「納品したのに終わらない」「直しても直しても次が来る」「どこまでが無償なのか分からなくなった」。結論から書くと、これは修正の腕前の問題ではなく、着手前に回数と範囲を決めていないことが原因です。

修正対応は、決めておけば揉めません。決めていないから揉めます。そして厄介なことに、決めていない状態は着手直後には何の痛みも生まないため、問題が表面化するのは納品後、つまり最も交渉しづらい時期になります。この順番が、修正対応というテーマの難しさのすべてです。

この記事では、業務システム開発を受ける側の立場から、修正対応を制御するための決め方を扱います。修正と追加開発の線引き、「1回」という単位の定義、見積書と契約書に書く文言、上限に達したときの伝え方、そして修正そのものを減らす進め方まで、判断の基準を具体的に書きます。費用の話も出しますが、金額そのものではなく、何に対して費用が発生する構造なのかという観点で整理します。

修正の範囲を決めないと何が起きるのか

まず、決めなかった場合に何が起きるかを押さえておきます。ここを具体的に理解していないと、契約時に「そこまで細かく決めなくても」と流されたときに踏みとどまれません。

修正と追加開発の境目が消える

最初に起きるのがこれです。範囲を定義していないと、依頼側は「動かないから直してほしい」も「やっぱりこの項目も出したい」も、同じ「修正」という言葉で送ってきます。悪意があるわけではなく、依頼側にとっては両方とも「思っていたものと違う」という同じ体験だからです。

しかし受ける側にとっては、この2つはまったく別の作業です。前者は当初の合意どおりに動いていないので直す義務がありますが、後者は合意になかった機能を作る話で、本来は別途の見積もりが必要です。この区別が言語化されていないと、追加開発が無償で積み上がっていきます。

さらに悪いのは、一度受けてしまうと基準が下がることです。1回目の追加要望を「これくらいなら」と無償で受けると、2回目以降も同じ扱いになると相手は認識します。これは相手が意図的に押し込んでいるわけではなく、実際に前例ができたからです。線引きは最初にやるしかありません。

検収がいつまでも終わらない

範囲が決まっていないと、検収の終わりも決まりません。検収が終わらなければ請求のタイミングも来ないため、資金繰りに直結します。フリーランスや小規模事業者にとって、これは修正の工数以上に重い問題です。

システム開発の一般的な流れでは、改修が終わった後に本番環境で動作検証を行い、そこで見つかった不具合を直して納品という順序を取ります。

無事に改修が完了したら、本番環境にて動作検証をおこないます。動作検証にて不具合などが発生した場合、その修正対応をおこなって納品です。出典: hnavi.co.jp

この流れ自体は正しいのですが、「動作検証にて不具合などが発生した場合」の範囲が定義されていないと、この工程が無限に伸びます。不具合の定義がないため、依頼側は使いにくい点や見た目の好みも同じ枠で挙げてきます。正直なところ、この工程を期間で区切らずに進めている案件が多すぎると感じます。

見積もりの前提が崩れる

見積もりは、想定した工数に基づいて出しています。修正対応の回数を想定していなければ、その分は見積もりに入っていません。つまり無制限の修正を受けるということは、見積もりの前提を自分で壊すということです。

ここを「サービスのつもりで」と処理してしまう人は少なくありませんが、続きません。時間あたりの採算が下がり続けるため、他の案件に手が回らなくなり、最終的にはその案件自体を投げ出す形になります。誠実に見えて、いちばん不誠実な結末です。

修正を3つに分類して線を引く

範囲を決めるための実務的な方法は、修正の申し出を3つに分類することです。この分類を先に相手と共有しておくと、後の会話が格段に楽になります。

分類1 不具合の修正

合意した仕様どおりに動いていないものです。ボタンを押しても保存されない、計算結果が仕様書の式と合わない、特定の条件でエラーになる。これらは受ける側の責任範囲であり、回数の上限をつけずに直すのが原則です。

ただし「不具合」と呼ぶには、比較対象になる合意が必要です。仕様書、画面設計、データ項目の一覧のいずれかに書かれていることが前提になります。書かれていないものは不具合ではなく、次の分類に入ります。

不具合の修正には期間の定めを置きます。無期限にすると、数年後に見つかった問題まで無償対応の対象になりかねません。実務上は納品から一定期間を保証期間とし、それ以降は保守契約として別に扱う形が一般的です。

分類2 解釈違いによる手直し

仕様書には書かれているが、書き方が曖昧で受け取り方が分かれたケースです。「一覧を見やすく表示する」といった記述が典型で、どちらの責任とも言い切れません。

この分類の扱いが、修正対応の設計で最も重要です。ここを無制限に受けると際限がなくなり、逆にすべて有償にすると関係が悪化します。したがって、この分類にだけ回数の上限を設けるのが実務的な解になります。「解釈の調整は3回まで、それ以降は別途見積もり」という形です。

この分類が発生する根本原因は、着手前の合意が文章になっていることです。文章は解釈の幅が広いため、画面イメージとデータ項目の一覧で合意しておくと、この分類自体が大幅に減ります。

分類3 仕様変更による追加開発

合意になかった機能や項目を足す話です。これは修正ではなく新規の作業なので、回数の枠外で扱い、別途の見積もりを出します。

依頼側がこれを「修正」と呼んでくるのは自然なことなので、責める必要はありません。受ける側が「これは追加開発に当たるので、別途お見積もりを出します」と淡々と分類し直せば済みます。重要なのは、この言い方を事前に決めておくことです。その場で考えると、遠慮が出て曖昧な返答になります。

「1回」の単位をどう定義するか

回数を決めるとき、多くの人が見落とすのが単位の定義です。上限を3回と決めても、「1回」が何を指すのか決めていなければ意味がありません。

指摘1件を1回と数えない

指摘1件ごとに1回と数えると、依頼側は指摘を出しにくくなり、まとめて後出しする動機が生まれます。結果として大きな手戻りが一度に来ることになり、受ける側にとっても損です。

実務では「1回のフィードバックにまとめて出してもらい、それをまとめて直したら1回」と定義します。つまり回数は、やり取りの往復回数を指します。この定義にすると、依頼側は気づいた点を集めてから出すようになるため、双方の作業効率が上がります。

期限を切って締める

まとめて出してもらう運用にするなら、いつまでに出すかを決める必要があります。「納品物の確認は営業日で5日以内、その期間に挙げられた指摘をまとめて1回とする」といった形です。

期限を切ることには、もうひとつ効果があります。依頼側の社内で誰が確認するのかが決まるということです。期限がないと、確認は誰の仕事でもない状態のまま放置され、忘れた頃に別の部署から指摘が来ます。期限を切ると、確認の担当が自然に決まります。

差し戻しの受け取り方を決める

指摘を受け取る場所も決めておきます。メール、チャット、課題管理ツールが混在すると、対応漏れが発生します。漏れると「直っていない」と言われ、余計な往復が増えます。

推奨は、一覧で管理できる形にすることです。表計算のシートでも構いません。各行に「指摘内容」「分類（不具合か、解釈調整か、追加開発か）」「対応状況」を持たせ、分類欄を受ける側が埋める運用にします。この一覧があると、上限に達したことを説明するのも簡単になります。数えるまでもなく、表を見せれば伝わるからです。

見積書と契約書に書いておく項目

決めた内容は、書面に落とさなければ効きません。口頭の合意は、担当者が変わった時点で消えます。

見積書に入れる行

見積書には、金額の内訳だけでなく、前提条件の欄を作ります。ここに書くのは次の項目です。

修正対応の範囲として、不具合の修正は保証期間内で対応すること。解釈調整の手直しは指定した回数まで含むこと。仕様変更に当たる追加開発は別途見積もりであること。この3行があるだけで、後の会話が変わります。

さらに、検収の期限も書きます。納品後いつまでに確認してもらうか、その期間を過ぎた場合にどう扱うかを明記します。ここを書いていない見積書が非常に多いのですが、実務上いちばん効く一行です。

見積書の書き方そのものに自信がない場合、ビジネス文書の基本形を押さえておくと迷いが減ります。文書の構成や条件の書き方を体系的に扱うビジネス文書検定の出題範囲は、見積書や仕様確認書の作成にそのまま応用できる内容です。

契約書に入れる条項

契約書では、検収の条項と、修正対応の条項を分けて書きます。検収の条項では、検収の基準（合意した仕様書に照らして判断する旨）と期間を定めます。修正対応の条項では、保証期間、回数、追加開発の扱いを定めます。

もう一点、忘れられがちなのが、依頼側が用意する前提の記載です。テスト環境の提供、テストデータの用意、確認担当者の指定といった項目で、これが遅れると納期にも修正回数にも影響します。実務では、依頼側が用意できる部分を明示しておくと、費用も工期も抑えられます。

例えば、システム改修時のマニュアル修正などはスキルを問わないため、可能であれば自社で修正対応すると良いでしょう。また、テストデータの作成も一般的にはシステム開発会社が用意しますが、自社側でデータやテストパターンを用意しておくのも費用削減につながるでしょう。出典: hnavi.co.jp

この観点は、受ける側から提案しても嫌がられません。依頼側にとって費用が下がる話だからです。分担を提案することは、そのまま自分の修正対応の負担を減らすことにもつながります。

上限に達したときの伝え方

決めておいても、実際に上限に達したときに言えなければ意味がありません。ここでの伝え方には型があります。

伝える順番

順番は、事実、分類、選択肢の3段階です。感情や遠慮を挟まないほうが、結果として関係が保たれます。

まず事実として、当初の合意で解釈調整は指定回数までとしていたこと、今回の指摘でその回数に達することを述べます。次に分類として、今回の指摘のうちどれが不具合で、どれが追加開発に当たるかを一覧で示します。最後に選択肢として、追加開発分を別途見積もりで進めるか、今回の納品で一度締めて次のフェーズにまとめるかを提示します。

選択肢を2つ出すのが重要です。1つしか出さないと「断られた」という受け取り方になりますが、2つ出すと「どちらにするか決める場面」に変わります。実務でトラブルになるのは、断るときではなく、選択肢を出さずに断るときです。

使わないほうがよい言い方

「契約書に書いてあります」だけで押すのは避けてください。事実としては正しくても、相手は追い詰められた感覚になり、その後の協力が得られなくなります。書面は根拠として静かに添えるもので、武器として振り回すものではありません。

「サービスで対応します」も避けます。一度言うと、その後のすべてがサービスの対象になります。無償で対応する判断をした場合も、「今回は分類1の不具合と判断したので保証範囲で対応します」と、必ず理由をつけてください。理由のない無償対応は前例になり、理由のある無償対応は基準になります。

修正そのものを減らす進め方

回数を決めるのは防御です。攻めの手として、修正の発生自体を減らす方法があります。こちらのほうが本質的です。

文章ではなく画面で合意する

修正の大半は、着手前の合意が文章だったことに起因します。文章は読む人によって像が変わるため、動くものができた瞬間に差分が噴き出します。

対策は、着手前に画面のイメージとデータ項目の一覧で合意することです。手描きでも構いません。「この画面に、この項目が、この並びで出る」という形にしておくと、後から「思っていたのと違う」が出にくくなります。異常系、つまりエラーが起きたときにどう振る舞うかも、この段階で決めておくと効きます。

途中で見せる回数を増やす

一度も見せずに納品すると、修正はまとめて来ます。逆に、途中で何度か見せておくと、方向のずれが小さいうちに直せます。

ここで注意すべきなのは、途中で見せることを修正回数のカウントに含めないという合意です。含めてしまうと、依頼側は見せてもらうことを遠慮するようになり、結果として最後に大きな手戻りが来ます。中間確認は回数の外に置くのが実務的な設計です。

議事録を送る習慣

打ち合わせの後に、決まったことを短く書いて送ります。長い議事録は読まれないので、決定事項と保留事項だけの数行で十分です。これを続けると、認識のずれがその都度つぶれます。

この習慣は、修正対応の場面でも効きます。「前回こう決めました」と示せる記録があるかどうかで、話の進み方がまったく変わるからです。

費用がどう決まるかを理解しておく

修正対応の交渉では、費用の構造を説明できるかどうかが効きます。金額の提示ではなく、なぜ費用が発生するのかという構造の話です。

修正の費用は、基本的に工数で決まります。工数を押し上げる要因は、影響範囲の広さ、既存コードの読み解きにかかる時間、テストのやり直しの量です。表面的には小さく見える修正でも、影響範囲が広ければテストの範囲が広がり、工数が増えます。

依頼側から「1行直すだけなのに」と言われたときは、この構造を説明します。1行の変更でも、その変更が他の機能に影響しないことを確認する作業が必要であり、その確認が工数の大半を占めることが多いという説明です。この説明ができると、追加費用の話が通りやすくなります。

一方で、「ITシステムバグ修正には実際いくらかかるのか」「軽微な修正でも費用が発生するのはなぜか」「調査費用と修正費用は別なのか」「保守契約に入っていれば無料で対応してもらえるのか」といった疑問を持つ方も多いのではないでしょうか。出典: note.com

依頼側がこうした疑問を持つのは当然です。だからこそ、受ける側が先回りして構造を説明しておくと、信頼につながります。調査と修正を分けて考えること、保守契約の範囲がどこまでかを明示することは、そのまま自分を守ることにもなります。

保証期間の終わりと、保守契約への移行

修正対応の設計でもうひとつ決めておくべきなのが、終わり方です。保証期間をいつまでにし、その先をどう扱うか。ここを決めていないと、納品から時間が経ってからの連絡に、その都度どう返すか悩むことになります。

保証期間に何を含めるか

保証期間に含めるのは、原則として分類1の不具合だけです。合意した仕様どおりに動いていないものを、期間内に限って無償で直します。

期間の長さは、システムの規模と、業務でどれくらいの周期が回るかで決めます。月次の処理があるシステムなら、少なくとも月次処理を1回は通した後まで含めないと、実質的に検証されていない状態で保証が切れることになります。年次処理があるものは年次まで含めるかどうかを個別に判断しますが、そこまで無償で抱えるのは現実的ではないため、年次処理の確認は保守契約側に置くのが実務的です。

保証期間に含めないものも明記します。依頼側の環境変更に起因する不具合、依頼側が別の業者に改修させた後に生じた不具合、外部サービスの仕様変更による動作不良。これらは受ける側の責任範囲外ですが、書いていないと責任範囲として扱われがちです。特に外部サービスの仕様変更は、近年増えている論点です。連携先の認証方式が変わって動かなくなるといった事象は、受ける側の作りの問題ではありません。

保守契約で決める項目

保証期間の後は、保守契約に移行するか、都度の見積もりにするかの二択です。継続的に運用されるシステムなら、保守契約にしたほうが双方にとって見通しが立ちます。

保守契約で決めるのは、対応する範囲、対応にかかる時間の目安、連絡の受け付け方法と時間帯、そして月あたりに含まれる作業量です。とくに時間帯の取り決めは重要で、これを決めていないと深夜や休日の連絡に応じる前提になってしまいます。業務システムは業務時間に使われるため、障害の連絡も業務時間に来るのが基本ですが、月末や期末には時間外の連絡が発生しやすくなります。

保守の範囲を説明できると、依頼側にとっても予算化しやすくなります。運用を前提とした業務システムでは、作って終わりではなく維持にコストがかかるという点を、着手前の段階で共有しておいてください。ここを言わずに納品すると、保守の話を切り出したときに追加請求のように受け取られます。

現場で起きがちな3つのつまずき

決め方が正しくても、運用の場面でつまずくパターンがあります。頻度の高いものを3つ挙げます。

依頼側の担当者が途中で変わる

業務システムの開発では、期間が長いぶん担当者の異動が起こります。新しい担当者は、それまでの経緯を知りません。前任者と決めた修正回数の合意も、引き継がれていないことがあります。

対策は、合意事項を依頼側の社内で共有できる形にしておくことです。個人宛のチャットではなく、見積書や仕様確認書といった正式な書面に落としておけば、担当が変わっても引き継がれます。担当交代が分かった時点で、決めてある条件を一度整理して送り直すのも有効です。責める調子ではなく、引き継ぎの補助として送ると受け取られ方が変わります。

確認する人が複数いて指摘が矛盾する

依頼側の複数の部署が確認に入ると、指摘が食い違います。営業部門は入力の速さを求め、経理部門は入力項目の網羅を求める、といった形です。この状態で両方に応じると、修正が往復し続けます。

対策は、指摘の窓口を1人に決めてもらうことです。社内で意見が割れた場合は、依頼側の内部で調整してから1つの指摘として出してもらう運用にします。この取り決めを着手前にしておくと、依頼側の社内調整も進みやすくなります。窓口を決めずに進めた案件は、ほぼ確実に修正が膨らみます。

本番データでしか再現しない不具合

開発環境では動くのに、本番のデータで動かないという事象は珍しくありません。文字コード、想定外の桁数、過去データの不整合などが原因です。

この種の不具合は、受ける側の責任範囲かどうかの判断が難しくなります。判断の基準は、着手前にデータの前提を確認していたかどうかです。データの仕様や件数の想定を書面で共有していれば、そこから外れたデータによる不具合は追加の調査として扱えます。逆に確認していなければ、想定不足として保証範囲に入る可能性が高くなります。着手前にサンプルデータを受け取っておくのが、最も確実な予防策です。

なお、システムの稼働環境そのものに起因する事象も混ざります。通信やサーバーの構成が原因なら、そもそも修正の対象ではありません。この切り分けができると余計な作業を抱え込まずに済むため、ネットワークの基礎知識は投資に見合います。体系的に学びたい場合はCCNA（シスコ技術者認定）の出題範囲が、切り分けに必要な範囲をひととおり押さえています。

業務システム開発を受ける側から見た市場の構造

修正対応の設計は、案件の取り方とも関係します。どういう経路で仕事を受けているかによって、条件を決められる度合いが変わるからです。

業務システムの開発は、在宅で受けられる仕事のなかでも継続性が高い領域です。一度作ったシステムは運用されるため、保守や改修が続きます。この分野で何が求められているかを整理したものとして、Web・業務システム開発のお仕事に、実際にどういう工程が在宅で発注されているかがまとまっています。要件定義から保守までのどこを担うのかによって、修正対応の設計も変わってきます。

職種としての位置づけを統計から確認したい場合は、ソフトウェア作成者の年収・単価相場が参考になります。公的な統計をもとにした整理なので、自分の条件が市場から外れていないかを確かめる基準として使えます。

海外の案件を受ける場合、修正対応の設計はさらに重要になります。時差があるため往復の回数がそのまま期間に跳ね返り、回数を決めていないと納品が数カ月遅れることもあります。海外案件の進め方についてはUpworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法に、契約条件の詰め方と実務の流れが整理されています。国内より条件を明文化する文化が強いため、修正回数の書き方の参考にもなります。

働く場所を選ばない形で続けたい人にとっても、修正対応の制御は前提条件です。移動しながら働くと、まとまった作業時間の確保が難しくなるため、無制限の修正を抱えたままでは成立しません。この働き方の実際についてはWebマーケティングフリーランスで海外ノマド！年収、スキル、成功への道に、時間の使い方と案件の選び方が書かれています。

この市場を長く見てきた立場からの観察

在宅で働く人と依頼する人をつなぐ市場を20年見てきた立場から言えば、修正対応で疲弊して離脱する人と、長く続く人の差は、技術力ではありません。差は、着手前に条件を言葉にできるかどうかの一点にあります。

技術力の高い人ほど「直せてしまう」ため、条件を決めずに受けてしまう傾向があります。直せるので直す、その結果として時間が消え、採算が合わなくなり、疲れて離れる。この経路は本当によく見ます。逆に長く続いている人は、技術の話をする前に、範囲と回数と期限の話を先にしています。相手に嫌がられそうな話を先にする人ほど、結果として同じ相手から繰り返し依頼を受けています。

もうひとつ、運営者として見てきた限りでは、中間に手数料が乗らない直接の取引をしている人ほど、条件の交渉がしやすくなっています。間に業者が入ると、条件は上流で決まったものが降りてくるため、修正回数のような実務上の条件を後から変えるのが難しくなります。手数料0%の直接取引で得られる価値は、手取りが厚くなることだけではありません。依頼者と直接、範囲と回数を詰められることそのものが価値です。依頼する側も、間に人を挟まないぶん同じ予算でより多く頼めるようになるため、双方にとって合理的な形になります。

修正対応は、受ける側が一方的に我慢する領域ではありません。決め方を知っていれば、依頼側にとっても見通しの立つ進め方になります。着手前の30分で決められることを、納品後の3週間かけて揉めるのは、どちらにとっても損です。