検収されないまま追加要求が来たとき、業務システム開発のトラブル対処を知る

2026年2月16日

前田壮一

この記事のポイント

✓業務システム開発で検収が下りないまま追加要求が続くとき
✓何を根拠にどう動けばよいのかを整理しました
✓契約書に入れておくべき条項

まず、安心してください。検収が下りないまま追加要求が来るという状況は、皆さんの実力不足で起きているわけではありません。業務システム開発という仕事の構造上、非常に起きやすいトラブルです。そして、対処の手順もある程度は定まっています。

とはいえ、正直に書きます。この状況は放置すると悪化します。追加要求に善意で応え続けているうちに、当初の範囲がどこだったのか誰も説明できなくなり、報酬の請求根拠まで曖昧になっていく。ここまで来ると解決の難易度が跳ね上がります。だから、早い段階で線を引く必要があります。

この記事では、検収が下りない状況で何を確認し、どういう順番で動けばよいのかを整理します。あわせて、次の案件で同じ目に遭わないための契約上の予防策も書いておきます。

業務システム開発のトラブルは、珍しいことではない

最初に、皆さんの状況が特殊ではないことを数字で確認しておきます。システム開発のプロジェクトは、そもそも高い確率で計画通りに終わっていません。

日経コンピュータの2018年度調査では「システム開発に関するプロジェクトの失敗率は47.2%」という結果も出ており、およそ2件のうち1件は失敗している状態にあります（ITプロジェクト実態調査 2018｜日経XTECH）。出典: houmu-pro.com

およそ47.2%という数字は、決して低くありません。2件に1件が何らかの形でつまずいているということです。だから、いま困っている状況を「自分だけが失敗した」と受け取らないでください。構造的に起きやすい問題に、いま直面しているだけです。

なぜ業務システム開発でトラブルが起きやすいのか

理由は3つあります。

ひとつ目は、完成の定義が曖昧になりやすいこと。物を作る仕事なら、寸法や個数で完成を判定できます。しかし業務システムは「業務が回るかどうか」で評価されるため、発注側が「まだ使えない」と言えば、それが未完成の主張になってしまいます。

ふたつ目は、発注側が自分の業務を完全には言語化できていないこと。現場の運用には、担当者本人も意識していない手順や例外処理が含まれています。それが実装後に「これも必要だった」という形で出てくる。悪意はなく、本当に気づいていないことが多いのです。

みっつ目は、要件定義の文書が薄いまま着手してしまうこと。急ぎの案件では「詳細は進めながら決めましょう」で始まることがあります。この形は、後から範囲を確定する根拠がなくなります。

追加要求が「仕様変更」なのか「当初範囲」なのか

トラブルの核心はここです。発注側は追加要求を「当然含まれているはずのもの」と考え、受注側は「範囲外の追加」と考える。この認識の差が対立を生みます。

実際に訴訟にまで発展した例では、この点が争点になっています。

Y法人側は「入力欄の設置や機能の実装については要件定義されていなかった」と主張したものの、X弁護士は「集団訴訟管理システムなのだから、定義されていなくても対応するのが当然」と主張し、Y法人に対して約450万円の損害賠償金を請求したという事例です。出典: houmu-pro.com

450万円という金額の是非はさておき、注目してほしいのは主張の形です。発注側は「定義されていなくても対応するのが当然」と述べています。この論理が通るかどうかは事案によりますが、要件定義書に書かれていないことでも争いになるという事実は、押さえておく必要があります。

つまり、要件定義書に書いてあることだけで守られるとは限らない。だからこそ、書いていないことについて「これは範囲外です」と明示的に確認しておく作業が重要になります。

検収が下りないとき、最初にやるべき3つのこと

いま困っている方に向けて、順番に書きます。感情的に反応する前に、この3つを済ませてください。

手順1：契約書と発注書を読み直す

まず、手元の書面を確認します。見るべき箇所は次の通りです。

検収の条件がどう書かれているか。「発注者が検収する」とだけ書かれているのか、「納品後◯日以内に書面で通知する」といった期限があるのか。期限が書かれている場合、その期限を過ぎていれば検収があったものとみなす条項が付いていることがあります。これは強い根拠になります。

業務範囲がどこまでと書かれているか。仕様書が契約書に添付されているか、参照されているか。

報酬の支払い条件がどうなっているか。検収を条件としているのか、納品を条件としているのか。ここの書き方ひとつで、請求できるタイミングが変わります。

契約書がない、発注書だけ、メールのやり取りだけ、という場合もあるでしょう。その場合でも契約は成立しています。書面がないから請求できない、ということはありません。ただし、内容の証明が難しくなるだけです。

手順2：やり取りの記録を時系列で整理する

次に、証拠の整理です。ここを飛ばして交渉に入る人が多いのですが、順番が逆です。

メール、チャット、議事録、画面共有の録画。すべての記録を日付順に並べ、次の点が分かるようにします。いつ何を納品したか。発注側がいつどんな反応をしたか。追加要求がいつどんな形で出てきたか。それに対して自分がどう答えたか。

この整理をすると、多くの場合で発見があります。「検収の連絡が来ないまま、次の要求だけが来ている」「一度は問題ないと言われたのに、後から覆っている」といった事実が、時系列にすると明確に見えてきます。

チャットツールは、プランによっては過去のメッセージが見えなくなることがあります。重要なやり取りは、早い段階で書き出して保存しておいてください。

手順3：現状を文書にして相手に送る

整理ができたら、状況を文書にして発注側に送ります。感情は書かず、事実だけを並べます。

書く内容は4点です。いつ何を納品したか。契約上の検収条件はどうなっているか。現時点で検収の通知を受けていないこと。追加要求として受け取っている項目の一覧と、それが当初範囲に含まれるかどうかについての自分の理解。

そして最後に、「◯月◯日までに検収の可否をご回答ください」と期限を切ります。回答期限を書かないと、この文書は宙に浮きます。

この文書を送ること自体が、大きな意味を持ちます。口頭のやり取りが記録に変わり、後で交渉や請求をするときの土台になるからです。文書の形式に自信がない方は、ビジネス文書検定の出題範囲が、通知文や依頼文の基本的な構成を確認する材料になります。

追加要求への対応、線の引き方

検収の確認と並行して、追加要求そのものへの対応を決める必要があります。

全部断る必要はない

ここは正直に書きます。追加要求をすべて突っぱねるのが正解とは限りません。関係を維持したいなら、小さな修正は受けたほうがよい場合もあります。

判断の基準はひとつです。「これは不具合の修正か、それとも新しい機能か」。不具合、つまり仕様通りに動いていない部分の修正は、無償で対応するのが通常です。一方、仕様書に書かれていない機能の追加は、別の仕事です。

この区別を、自分の中で先に決めてください。曖昧なまま対応すると、相手も区別がつかなくなります。

追加分は必ず見積もりを出す

範囲外だと判断した項目については、「対応可能ですが、追加のお見積もりとなります」と伝え、金額と納期を提示します。無償でやってしまうと、次も無償が前提になります。

ここで多くの方が躊躇します。「金額の話をすると関係が悪くなるのでは」と。しかし、見積もりを出さずに受け続けるほうが、最終的に関係は壊れます。作業量が増え、納期が延び、こちらが疲弊して品質が落ちるからです。

見積もりを出したうえで「無償でお願いしたい」と言われたら、そこで初めて交渉になります。金額を書いた紙が一枚あるかないかで、交渉の土俵がまったく違います。

一覧表にして棚卸しする

要求が多岐にわたっている場合は、一覧表を作ってください。項目ごとに、当初範囲か追加か、工数の見込み、対応の可否を並べます。

この表を相手に見せると、相手も自分が何を要求しているのかを俯瞰できます。個別に一つずつ言われているときは軽い要求に見えても、並べると総量が見えます。これで「では優先度の高いものだけに絞りましょう」という話になることが少なくありません。

検収が下りない典型パターンと、それぞれの動き方

ひとくちに「検収されない」と言っても、背景はいくつかに分かれます。原因が違えば、有効な打ち手も変わります。皆さんの状況がどれに近いか、当てはめてみてください。

パターン1：担当者が判断できない

もっとも多いのがこれです。窓口の担当者に決裁権がなく、上長の確認が取れないまま止まっている。悪意はまったくありません。ただ社内で話が進んでいないだけです。

この場合、責めても解決しません。有効なのは、相手が上に説明しやすい材料を渡すことです。何がどう完成したのか、当初の要件とどう対応しているのかを1枚にまとめて送る。担当者はそれをそのまま上に回せます。相手の仕事を減らす方向に動くと、話が前に進みます。

パターン2：現場が使ってみて不満を言っている

納品したものが仕様通りでも、実際に使う現場から「思っていたのと違う」という声が上がることがあります。窓口の担当者はその声に押されて、検収を出せなくなる。

ここで大事なのは、その不満が仕様との不一致なのか、仕様そのものへの不満なのかを分けることです。前者なら修正の対象、後者なら仕様変更です。この切り分けを、感情を交えずに文書で示してください。「ご指摘の3点のうち、1点目は仕様との不一致のため修正します。2点目と3点目は当初仕様の通りに動作しているため、変更をご希望であれば別途お見積もりします」という形です。

パターン3：予算が確保できていない

発注側の社内で予算が下りておらず、支払いのタイミングを遅らせるために検収を保留している、というケースもあります。表向きには技術的な理由が語られますが、実態は資金繰りということがあります。

この見分け方として、指摘内容が具体的かどうかを見てください。「全体的にまだ完成度が」といった曖昧な指摘が続く場合、技術的な問題ではない可能性があります。この場合は、支払い時期の相談に切り替えたほうが早く解決します。分割払いの提案が有効なこともあります。

パターン4：発注側の要件定義がそもそも未完成

着手時に要件が固まっておらず、作りながら決める前提だった案件です。この場合、そもそも「完成」の合意が存在しないため、検収の基準がありません。

ここで有効なのは、いま時点での成果物を確定させ、そこまでを一区切りとして精算する提案です。「現状の実装内容を仕様として確定し、ここまでを納品として扱わせてください。追加のご要望は次フェーズとして別途お見積もりします」という切り方です。区切りを作らないと、永遠に終わりません。

パターン5：担当者が交代した

途中で窓口が変わり、新しい担当者が経緯を知らないまま「これでは足りない」と言い出すケースです。前任者との合意が引き継がれていないのが原因です。

対処法は、経緯の再提示です。いつ誰とどんな合意をしたかを、記録とともに示す。ここで議事録が残っていれば一発で解決しますし、残っていなければ苦戦します。議事録の重要性が最も効くのがこの場面です。

交渉の場で、どう伝えるか

文書を送ったあと、打ち合わせや電話で話す場面が来ます。ここでの伝え方も結果を左右します。

立場を責めず、事実を並べる

「約束が違う」「そんなことは聞いていない」という言い方は、相手を防御に回らせます。防御に入った相手は、譲歩ができなくなります。

代わりに、事実と自分の理解を並べてください。「◯月◯日のお打ち合わせでは、この範囲で合意したと理解しています。認識に相違があればご指摘ください」。この形なら、相手は事実の確認として応じられます。

こちらの譲歩できる線を、先に決めておく

交渉の場で即断すると、後悔する判断をしがちです。話し合いの前に、自分の中で3つの線を決めておいてください。

理想の着地はどこか。受け入れられる最低ラインはどこか。それを下回るなら、どう撤退するか。この3つを決めておけば、その場の空気に流されずに済みます。

口頭で決まったことは、その日のうちに文書化する

打ち合わせで合意が得られても、口頭のままでは記録になりません。終わったらすぐ、決まった内容をメールで送ってください。「本日の内容を以下の通り確認いたしました」という形式で十分です。

このひと手間を面倒がると、同じ話をもう一度することになります。

感情が高ぶっているときは、一晩置く

正直に書きます。私も独立したての頃、腹が立ったまま返信を書いて送ってしまったことがあります。内容は間違っていなかったのですが、書き方が刺々しく、その後の関係がぎくしゃくしました。

強い言葉で書いたメールは、後から取り消せません。感情が動いているときは、下書きだけ書いて一晩置いてください。翌朝読み返すと、たいてい半分は削ることになります。

報酬を請求する段階での進め方

対話で解決しない場合、報酬の請求に進みます。段階を追って書きます。

段階1：請求書を出す

検収が下りないから請求書を出せない、と考えている方がいますが、契約の内容によります。納品を条件に報酬が発生する契約であれば、検収の有無にかかわらず請求できる場合があります。

まずは請求書を出し、支払期日を明示します。出さないままだと、後で「請求されていない」と言われる余地を残します。

段階2：内容証明郵便を送る

支払いがない場合、内容証明郵便で支払いを求める通知を送る方法があります。内容証明は、いつどんな内容の文書を送ったかを郵便局が証明してくれる仕組みです。

これ自体に強制力はありませんが、相手に対して「本気である」というメッセージになります。また、後の手続きで「請求した事実」を証明できます。

段階3：支払督促や少額訴訟を検討する

それでも支払われない場合、裁判所の手続きを使う選択肢があります。支払督促は、書類審査だけで進む簡易な手続きです。少額訴訟は、一定額以下の請求について1回の期日で審理する制度です。

ただし、相手が異議を出せば通常の訴訟に移行します。手続きの詳細と費用感については未払い報酬を回収する！弁護士の着手金・成功報酬と支払督促の流れ【2026年最新】で整理されているので、進む前に費用と手間を確認しておいてください。

※どの手続きを選ぶかは、金額、証拠の強さ、相手の資力によって判断が変わります。具体的な選択は弁護士に相談することをおすすめします。

費用対効果を冷静に見る

正直に書きます。少額の未払いについて、費用と時間をかけて回収するのが合理的とは限りません。回収に成功しても、かけた労力を考えると割に合わないことがあります。

だからこそ、請求する前に「いくらまでなら追う価値があるか」を自分で決めておいてください。この線引きがないと、意地になって時間を失います。皆さんの時間は、次の仕事に使ったほうが価値が高い場合もあります。

法律による保護と、その限界

2026年時点で、フリーランスとして仕事を受ける個人には、いくつかの保護があります。

発注事業者との取引に関するルールでは、書面等による取引条件の明示や、報酬の支払期日についての定めが設けられています。受領した日から一定期間内に支払わなければならない、といった規制です。また、正当な理由なく受領を拒むこと、不当に報酬を減額することなども問題とされます。

つまり、「イメージと違うから払わない」といった理由が、そのまま通るわけではないということです。

ただし限界もあります。これらのルールは、取引条件が明示されていることを前提にしている部分があり、そもそも何を発注したのかが曖昧な案件では、判断が難しくなります。また、規制の対象になる取引かどうかは、発注側の事業規模等によって変わることがあります。

具体的な要件と手続きについては、公正取引委員会や中小企業庁の案内で確認してください。発注書や契約書に何を書いてもらうべきかを事前に整理しておきたい方にはフリーランスを守る「下請法（取適法）」の知識｜発注書・契約書の必須項目チェックリストが実務的なチェックリストとして使えます。

次の案件で同じことを繰り返さないための予防

ここからは、トラブルが起きた後ではなく、起きる前の話です。予防のほうが、対処よりはるかに安く済みます。

検収条項を必ず入れる

契約書に入れるべき条項の筆頭が、検収に関する定めです。具体的には次の3点です。

納品後、何日以内に検収の結果を通知するか。その期間内に通知がない場合、検収に合格したものとみなすか。検収で不合格とする場合、その理由を書面で示すことを求めるか。

このみなし規定があるかないかで、状況がまったく変わります。期限を過ぎても連絡が来ない場合に、合格として扱えるからです。

範囲外を明示的に書く

仕様書には、やることだけでなく「やらないこと」を書いてください。「本件には◯◯の機能開発は含まない」「既存システムの改修は範囲外とする」といった記述です。

書いていないことが争点になるのは、先に紹介した事例が示す通りです。含まれないことを明記しておけば、後の主張がしやすくなります。

仕様変更の手続きを決めておく

仕様変更が発生したときに、どういう手順を踏むかを契約段階で決めておきます。変更内容を書面で提示し、工数と金額を見積もり、双方の合意をもって着手する。この流れを条項にしておくと、追加要求が来たときに「では変更手続きを取りましょう」と自然に返せます。

手続きが決まっていないと、毎回その場の力関係で決まってしまいます。

段階的な支払いにする

すべての報酬を検収後に受け取る契約は、リスクが集中します。着手時に一部、中間の成果物提出時に一部、完了時に残り、という形にすると、万が一もめたときの損失が小さくなります。

発注側に嫌がられるのではと心配される方もいますが、大きな案件では段階払いのほうが一般的です。提案してみる価値はあります。

議事録を必ず残す

打ち合わせの後、その日のうちに議事録を送ってください。決まったこと、宿題、次回の予定を3行でも構いません。

「認識に相違があればご指摘ください」と添えて送り、指摘がなければ合意したものとして扱う。この積み重ねが、後で最大の武器になります。ツールは何でも構いません。メールでも、共有ドキュメントでも、記録が残る形であれば十分です。

記録を残すための道具立て

予防の話をしましたが、実際に記録を残すには道具が要ります。難しいものは必要ありません。皆さんがすでに使っているもので十分です。

まず、やり取りの主軸をメールに置くことをおすすめします。チャットは手軽ですが、プランによっては過去のメッセージが閲覧できなくなることがあり、後から証拠として取り出すのに苦労します。重要な合意はメールで確認する、という運用にしておくと安心です。

次に、仕様と課題の一覧を、双方が見られる場所に置くこと。表計算の共有ファイルでも、課題管理のサービスでも構いません。大切なのは、誰がいつ何を追加したかの履歴が残ることです。口頭で追加された要望が、履歴に残る場所に書かれるだけで、後の争点が半分になります。

三つ目に、納品の証跡です。ファイルを送っただけでは、相手が受け取ったかどうかが分かりません。納品時には「◯月◯日、以下の成果物を納品いたします」という文面をメールで送り、内容の一覧を明記しておきます。これが後に「いつ納品したか」の根拠になります。

四つ目に、打ち合わせの記録です。録音は相手の同意が必要になる場面があるため、確実なのは終了後の議事録メールです。決まったこと、保留のこと、次回までの宿題。この3項目を箇条書きで送るだけで十分な記録になります。

最後に、バックアップです。納品したバージョンのソースコードや設計書は、自分の側にも保管しておいてください。後から「納品時点でどうだったか」を証明する必要が出たとき、手元にないと困ります。

道具を増やすことが目的ではありません。すべては「いつ、誰が、何を決めたか」を後から取り出せるようにするための仕込みです。トラブルが起きてから記録を作ることはできません。平時のうちに、この形を作っておいてください。

43歳で独立した立場から、皆さんに伝えたいこと

私自身、メーカーを辞めてフリーランスになった頃は、契約書の重要性を軽く見ていました。相手が大きな会社だから大丈夫だろう、という感覚があったのです。

実際に痛い目を見て学んだのは、トラブルは悪意から起きるとは限らないということでした。発注側の担当者が異動して、話が通じなくなる。現場が「これも当然含まれている」と本気で思っている。こうした善意のすれ違いのほうが、悪質な踏み倒しよりずっと多い。だからこそ、人を疑うためではなく、お互いの記憶を補うために書面を残すのだと考えるようになりました。

もうひとつ学んだのは、早く言うことの大切さです。範囲外だと思った瞬間に伝えれば、まだ軽い話で済みます。3か月溜めてから言うと、相手は「今まで文句を言わなかったのに」と受け取ります。言いにくいことほど、早いほうが痛みが小さい。

20年この市場を見てきた立場からの観察

在宅・業務委託の市場を長く運営してきた立場から言えば、トラブルの発生率は、案件の規模よりも「発注側の体制」に強く相関します。

運営者として見てきた限りでは、担当者が一人しかおらず、その人の頭の中にしか仕様がない案件は、途中で必ず止まります。担当者が異動したり多忙になったりした瞬間に、誰も判断できなくなるからです。逆に、関係者が複数いて意思決定の経路がはっきりしている案件は、多少もめても最後まで到達します。案件を選ぶとき、金額より先にこの点を確認する価値があります。

もうひとつ観察していることがあります。長く続いている人ほど、納品して終わりにせず、運用がどうだったかを聞きに行っています。この一手間が、追加要求をトラブルではなく次の発注に変えている。「この人に任せると楽だ」という関係ができていると、追加が出たときも自然に見積もりの話になります。

手取りの構造にも触れておきます。仲介手数料が乗る経路で受けると、報酬から一定割合が差し引かれます。同じ発注額でも、中間マージンが乗らない直接取引なら、依頼する側はより多く頼めて、受け手の手取りは厚くなる。手数料0%で直接やり取りできる場を持っていることの意味は、単価が上がることより、無理な追加要求に応じなくても収支が成り立つという余裕にあります。値下げや無償対応を断れるかどうかは、その余裕があるかどうかで決まります。

独自データから見た、トラブルが起きやすい工程

在宅・業務委託の案件情報を工程別に整理していくと、トラブルの発生しやすさには偏りがあります。

もっとも多いのが、要件定義が薄いまま実装に入った案件です。Web・業務システム開発のお仕事では工程が要件定義から保守運用まで分けて説明されていますが、上流の工程に十分な時間が配分されていない案件ほど、後工程で追加要求が噴出します。

次に多いのが、検収の基準が業務側の主観に委ねられている案件です。「使いやすくなったら合格」のような基準では、いつまでも終わりません。数値や動作で判定できる基準に翻訳しておく作業が、着手前に必要になります。

報酬の面でも見ておきましょう。トラブル対応にかかった時間は、通常は請求できません。つまり、もめた分だけ実質の時間単価が下がります。ソフトウェア作成者の年収・単価相場で示される相場と自分の実績を比べるとき、額面ではなく「トラブル対応を含めた総時間」で割ってみてください。予防に投じる時間のほうが、はるかに安いことが分かるはずです。

契約や請求の実務に不安が残る方は、専門職の視点から書かれた会計士の副業ガイド｜監査法人勤務でもできる高収入の稼ぎ方【2026年版】でも、業務委託の契約と報酬の扱いに触れられています。隣接領域としてAI・マーケティング・セキュリティのお仕事も見ておくと、成果の定義がしやすい仕事とそうでない仕事の違いが見えてきます。

皆さんに一番お伝えしたいのは、いま起きているトラブルは、次の案件の契約を強くするための材料になるということです。今回の経験で「この条項があれば防げた」と分かったことを、必ず次の契約書に反映してください。それができれば、この経験は損失ではなくなります。