受託開発のトラブルを防ぐ。検収・仕様変更・追加請求の決め方

金曜日の夕方、開発会社から追加の見積書が届きます。発注側は「最初から必要だと伝えた」と言い、開発会社は「見積もりの範囲外です」と答えます。完成予定日は近づいていますが、両社が見ている仕様書の版まで違います。

受託開発のトラブルは、契約書の厚さより、変更が起きた日の動きを決めることで減らせます。検収、仕様変更、追加請求で揉める案件では、誰か一人の説明力よりも、合意済みの版、承認できる人、費用と納期を決め直す手順が欠けています。

検収と追加請求の衝突は、着手前にかなり減らせます。すでに揉めている場合も、正しさを言い合う前に資料と動作を固定すれば、直す範囲と交渉する範囲を分けられます。

受託開発のトラブルは、着手前の三つの空欄から始まります

最初の空欄は、合意済み仕様の基準となる文書です。基本契約、個別契約、見積書、要件定義書、画面案、議事録が存在していても、優先順位と版が決まっていなければ、両社が別の完成像を持ちます。

僕なら、開発会社が実装へ入る前に、仕様書のファイル名、版番号、承認日、承認者を一行で書きます。メールや会議で内容を変えた場合に、基準文書へ反映する担当者と期限も決めます。議事録に残った要望が自動で開発範囲へ入るのか、変更手続を通すまで入らないのかも明記します。

次の空欄は、変更を承認できる人です。現場担当者が画面を見て「項目を一つ増やしてください」と頼み、開発者が親切心で着手すると、発注側の経営者も開発会社の営業担当も費用増加を知らないまま進みます。依頼できる人と、予算や納期の変更を承認できる人を分けます。

最後の空欄は、検収の合格条件です。「問題なく動くこと」だけでは、月末処理、権限の違い、外部サービスが止まった場合まで判定できません。誰が、どのデータで、どの操作を行い、どの結果なら合格かを実装前に書きます。

契約書だけに情報を詰め込む必要はありません。契約書には変更と検収の手続を書き、仕様書には作る機能を書き、変更票には差分を書きます。発注前の条件と提案範囲を分けるには、RFPで必須条件と評価基準をそろえる方法も参考にしてください。

仕様変更と追加請求は、一枚の変更票でつなぎます

仕様変更の相談を受けたら、開発会社は作業を始める前に影響を返します。変更する画面だけでなく、データ移行、テスト、操作説明、公開作業、納期への影響まで見ます。発注側は、追加料金を払って入れるか、別の機能を外すか、次回へ送るかを選びます。

変更票には、依頼日、依頼者、変更理由、変更前後の仕様、追加費用、納期への影響、検収項目の差分、両社の承認者を置きます。調査しなければ金額を出せない場合は、調査作業の上限、調査後に開発を続けるか決める日、承認がない場合の停止位置も書きます。

IPAの情報システム・モデル取引・契約書（第二版）も、第37条の変更管理手続で、変更理由、仕様の詳細、費用、スケジュール、契約条件への影響を記録し、双方の責任者が承認する流れを示しています。対象は一部の企画を含む受託開発と保守運用で、主に対等な交渉力を持つユーザ企業と開発会社によるウォーターフォール型開発を想定したモデルです。小規模案件へ自動で適用される規則ではなく、IPAも参照法規が公表時点の内容である点へ注意を求めています。

変更票は、追加請求を通すためだけの書類ではありません。費用が増えない場合も、画面変更によってテスト期間が延びるなら記録します。予算、納期、対象範囲のどれを動かしたかが残れば、請求書が届いた日に初めて変更へ気づく事態を避けられます。

口頭依頼だから合意ではない、と決めつけるのも危険です。2026年7月12日時点の民法522条は、法令に特別の定めがある場合を除き、契約成立に書面などの方式を必要としない原則を定めています。署名済みの変更票がない事実だけで、変更合意の有無まで確定するとは限りません。

だからこそ、契約上の変更方法を決め、チャットの依頼を変更票へ移す運用が必要です。誰が承諾したか曖昧な依頼には着手せず、影響調査と正式な承認を先に行います。個別案件で合意が成立したかは、契約書、メール、会議記録、作業経過を弁護士へ渡して確認してください。

受託開発の検収トラブルは、納品日より前に合格表を作ると減らせます

検収表を作り始める日は、納品後ではありません。仕様が固まり、開発会社が見積もりを出す時点で最初の版を作ります。検査に必要な利用者、データ、外部サービス、実施場所が分かれば、発注側が準備する作業も見積もれます。

IPAのモデル契約では、テスト項目、テストデータ、方法、期間などを検査仕様書へ定め、システム仕様書と納品物が合うかを検査する例を示しています。自社の契約では、検収期間が始まる条件も確認します。画面のURLが届いた日なのか、ソースコード、操作手順、テスト結果を含む納品物がそろった日なのかで、発注側が使える時間は変わります。

みなし検収の条項がある場合は、期限と通知先を社内の予定表へ入れます。担当者が休んでいる間に期限を過ぎないよう、代理の確認者も決めます。不合格を伝える際は、「使いにくい」ではなく、確認した版、操作手順、入力値、仕様書の箇所、期待した結果、実際の結果を残します。システム開発の検収で合否を記録する方法に、受入テストの作り方を詳しく書きました。

検収で見つかった課題は、合意済み仕様と動作が違う不一致、必要な業務が合意文書へ書かれていない認識差、納品画面を見て生まれた新しい要望に分けます。不一致は修正範囲を確認し、認識差は議事録まで戻り、新しい要望は変更票へ移します。全部を不具合と呼んでも、全部を追加開発と呼んでも話は進みません。

条件付きで合格する場合は、残る課題、修正期限、再検査する人、支払いと保守開始日の扱いを文書にします。契約が条件付き合格を想定していなければ、合意書の要否を契約担当者と専門家へ確認します。

受託開発でトラブルが起きているなら、最初の営業日に事実を固定します

進行中の案件では、相手を説得する資料より、後から同じ状態を再現できる資料を先に守ります。契約書、見積書、仕様書の全版、変更依頼、議事録、課題管理ツール、請求書を保存します。ソースコードのコミット、検証環境の版、本番へ公開した版、エラーログも記録し、修正作業で証拠が上書きされる前に退避します。

次に、一つの変更を一行にした時系列表を作ります。依頼日、依頼した文、受けた人、影響説明、承認記録、実装した版、請求された金額、両社の主張、根拠文書を横へ並べます。感情や推測は別欄にせず、確認できた事実だけを書きます。

両社の責任者が集まる場では、各行を仕様との不一致、変更合意の争い、新しい要望へ仮置きします。サービス停止を避ける回避策、合意済み範囲で続けられる作業、協議中は止める作業も決めます。管理画面の権限を交渉材料として取り上げたり、支払い停止や公開作業を担当者だけで決めたりすると、事業上の被害まで広がりかねません。

検収後の不具合なら、発見日、再現手順、仕様上の期待動作、業務への影響を契約上の窓口へ通知します。無償修正の対象や通知期限は契約ごとに異なります。取引の終了も視野に入る場合は、開発会社を変更する前に契約と移管条件を棚卸しする手順も確認してください。

契約終了を検討する段階では、開発方式の呼び名だけで動きません。民法632条、641条、651条、656条は、請負の定義と完成前の解除、委任の解除、準委任への準用に関する原則を定めています。請負では注文者が損害を賠償して完成前に解除できる原則があり、準委任へ準用される委任の解除でも相手方に不利な時期などには損害賠償が問題になります。

実際の作業がどの契約類型に当たるか、契約条項が法定の原則と異なる条件を置いているか、未払い報酬や移管費用をどう扱うかは、資料と経過によって変わります。一方的に作業や支払いを止める前に、弁護士へ時系列表と契約資料を渡してください。技術面では、外部のエンジニアに読み取り専用の権限を渡し、完成している範囲、動いている版、移管に必要な資料を確認してもらうと、法的な評価と技術的な復旧を混ぜずに進められます。

次の受託開発では、失敗した納品日を契約前に再生します

契約前の打ち合わせでは、順調なデモだけを見ません。たとえば、検収直前に画面項目を増やしたい、納品物が一部届かない、月末処理だけ失敗する、想定外の追加見積もりが届く、という場面を一つ選びます。

開発会社へ、依頼をどこへ記録するのか、影響を誰が調べるのか、費用と納期を誰が承認するのか、協議中の作業をどう扱うのかを聞きます。口頭の回答で終えず、実際に使う変更票へ仮の依頼を書いてもらいます。

次に、仕様書の版、見積もりの前提、変更票、検収表、納品物一覧を同じ画面へ開きます。ファイル名と担当者が空欄なら、開発開始日を決める前に埋めます。発注側にも、業務を説明する人、予算変更を承認する人、受入テストを行う人が必要です。

明日確認する一枚は、契約書の表紙ではなく変更票です。提案書にある機能を一つ選び、途中で項目を増やす想定を書き、費用、納期、検収項目、承認者まで埋めてください。進行中の案件なら、同じ欄を過去の依頼で埋め、空欄に残った事実だけを両社の責任者へ確認します。

受託開発で揉めない会社は、変更が起きない会社ではありません。変更が起きた日に、見る版、止める作業、決める人、残す記録が分かる会社です。