システム開発代金トラブル対応｜検収拒否・契約不適合・著作権帰属を弁護士解説

この記事の監修者

和氣 良浩（わけ よしひろ）

弁護士法人ブライト｜代表弁護士／パートナー弁護士

弁護士歴20年（2006年登録）／大阪弁護士会／大阪大学法学部卒

専門：顧問弁護士・企業法務・M&A・経営権紛争・事業再生

1. システム開発トラブルが起きる4つの定番パターン

システム開発をめぐる紛争は、ほぼ次の4類型に集約されます。

どの類型にも共通するのは、「契約書の文言だけでは決着がつかない」という点です。実務では、付属する仕様書・要件定義書・議事録・チャット履歴・受領印の有無といった「契約周辺の証拠」が勝敗を分けます。

2. 仕様変更トラブルを防ぐ「基本契約 + 個別契約」の二段構え

システム開発では、最初に「基本契約書（マスター契約）」を1通結び、各案件・各フェーズごとに「個別契約書」または「個別発注書」を発行する二段構成が実務の主流です。基本契約書には共通ルール（守秘義務・知的財産権・損害賠償の上限・解除事由）を、個別契約書には案件固有の事項（納期・対価・成果物仕様）を切り分けます。

個別契約書に必ず盛り込むべき項目

• 成果物の特定：「○○システム」だけでは紛争の元。機能一覧・画面遷移図・ER図への参照を明記
• 仕様書の優先順位：基本契約書＞個別契約書＞要件定義書＞議事録、など優先順位条項
• 変更管理プロセス：仕様変更は書面（メール可）と追加見積で合意 → 議事録への記載だけでは不十分
• 検収基準と検収期間：「○営業日以内に書面で検収または不検収理由を通知。期間内に通知なきときは検収みなし」
• 分割支払と完成定義：着手金・中間金・検収後残金の比率と、各支払の発生条件

「みなし検収条項」の威力

ベンダー側に最も効くのが「みなし検収条項」です。発注者が一定期間内に書面で異議を出さなければ検収完了とみなす条項を入れておくことで、「検収を出さずに支払を止める」という発注者の常套手段を封じることができます。発注者側から見ても、社内のレビュー期限が明確になるメリットがあります。

3.「検収拒否＋支払拒絶」コンボへの対処

システム開発の代金回収現場で最も頻発するのが「検収拒否＋支払拒絶」のコンボです。発注者側は「不具合があるから検収しない、だから支払えない」と主張し、ベンダー側は「軽微な不具合は受領後の対応で足りる、報酬は支払うべき」と反論します。

「完成」と「契約不適合」を切り分ける

2020年4月の改正民法以降、判例の整理がさらに進み、次の枠組みが定着しています。

• 仕事の完成（民法632条）：当該工事を最後の工程まで終え、客観的に予定された結果を実現していること。途中段階での不具合があっても、全体としての完成は認められうる
• 契約不適合（民法562条以下）：完成した仕事が、種類・品質・数量に関して契約内容に適合しない状態

この区別が重要なのは、「完成」していなければ報酬請求権が発生しないのに対し、「完成しているが契約不適合」であれば報酬請求権は発生し、別途追完請求や損害賠償で精算することになるからです。最高裁判例（最判平成15年10月10日など）は、社会通念に照らして仕事が完成しているかを基準に判断する立場を取っています。

発注者が選べる4つの権利

契約不適合があった場合、発注者は次の4つから請求内容を選択できます。

1. 追完請求（修補・代替物・不足分の引渡し）
2. 代金減額請求（追完が不能・拒絶された場合や催告後）
3. 損害賠償請求（債務不履行構成）
4. 契約解除（重大な不適合の場合）

従来の「瑕疵担保」では損害賠償と解除に限られていましたが、改正後は追完請求と代金減額請求が主軸になり、発注者が「直してもらう」「値引きしてもらう」を選べるようになりました。

4. 納期遅延・プロジェクト中断時の判断軸

「契約上の納期は過ぎたが、システムは半分くらいできている」という状況で、発注者は何を選べるのか。実務では次の手順で判断します。

解除を急がない方が得なケース

• すでに支払った着手金・中間金が大きく、解除しても返ってこない
• 他のベンダーに切り替えても、引継ぎコストとリードタイムで結局遅くなる
• 既存システムとの連携が複雑で、今のベンダーしか対応できない

このケースでは、解除ではなく「催告 → 履行遅滞責任に基づく損害賠償請求 → 納期の再設定」を交渉する方が経済合理的です。

解除すべきケース

• 進捗率が著しく低く、当初納期から大幅に遅延する見込みが高い
• ベンダー側のキーマンが離職し、プロジェクト続行が事実上不可能
• ベンダーの財務状況が悪化し、債権回収リスクが高まっている

解除する場合は、改正民法上の催告解除（541条）または無催告解除（542条）の要件を充たすかを丁寧に検討します。催告なしに一方的に解除を通告すると、逆にベンダーから債務不履行解除に基づく損害賠償を請求されるので注意が必要です。

既履行部分の精算

解除した場合でも、既に履行された部分が可分で発注者にとって利益となる場合は、原状回復請求権と既履行部分の対価との相殺で清算します。途中まで作ったソースコードの取扱い・著作権の帰属・成果物の引渡し条件を、解除合意書で明確にしておくのが実務の定石です。

5. 多段下請けと著作権帰属

大規模なシステム開発では、元請ベンダーが下請けベンダーを使い、下請けが孫請けを使う多段構造が一般的です。この構造で頻発するのが「成果物の著作権が誰のものか」というトラブルです。

著作権の原始帰属ルール

プログラムの著作権は、原則として創作した個人（プログラマ）に発生します。例外として、職務著作（著作権法15条2項）の要件を満たせば、雇用主たる法人に帰属します。問題は、下請けベンダーの従業員が職務著作で作った成果物が、契約上どう発注者まで届くかです。

• 下請けベンダー → 元請ベンダー：個別契約で「著作権はすべて元請に譲渡」と明記が必要
• 元請ベンダー → 発注者：基本契約で同様に譲渡条項が必要
• 条項に漏れがあると、発注者は「使用権はあるが著作権は持っていない」状態になり、二次利用・改変・第三者への転売ができない

著作者人格権不行使特約

著作権を譲渡しても、著作者人格権（公表権・氏名表示権・同一性保持権）は譲渡できません。そこで実務では「著作者人格権を行使しない」という不行使特約を契約書に入れます。これがないと、発注者が成果物を改変するたびにプログラマ個人から「同一性保持権の侵害だ」とクレームが入るリスクが残ります。

6. トラブル発生時の証拠保全 ── 議事録・チャット・メール

紛争になってから「あの時の口頭合意は……」と思い出しても遅いのが実務の悲しい現実です。日常的に次の3点を運用ルール化しておくことが、いざというときの最大の保険になります。

• すべての打合せに議事録：合意事項・宿題事項・決定保留事項を区別して記載。次回打合せ冒頭で前回議事録を確認する儀式を定着させる
• チャット履歴のエクスポート週次バックアップ：Slack・Teamsは管理者権限でデータ保全しておく。退職者のアカウントが消されると履歴も飛ぶリスクがある
• メールの社内ルール：重要事項は必ずメールで残す（議事録だけでは「読んでいない」と争われる）

受領印・受領メールの威力

納品物の受領を示す「受領印」「受領メール」「受領書面」の有無は、検収完了の有無と同じくらい重要な争点になります。送付状に「受領した旨を返信ください」と書いて返信を確実に取る運用、または受領印付き受領書を必ず提出してもらう運用を、発注フェーズの最初から徹底します。

7. 弁護士に相談すべきタイミングと顧問契約の活用

システム開発トラブルは、紛争化してから弁護士に相談するのは費用対効果が悪い領域です。なぜなら、契約書・仕様書・議事録の整備状況がほぼすべての勝敗を決めるため、紛争化した後では「証拠を作り直す」ことができないからです。

顧問弁護士の活用パターンとして、次の3点が中小IT企業・受託開発企業で特に効果が高いものです。

• 基本契約書のテンプレート整備：自社が発注者・受注者どちらの立場でも使える条項セットを用意
• 個別案件の契約レビュー：見積書発行前に5〜10分の電話レビュー
• 定期ミーティング：月1回30分で進行中案件のリスク棚卸し

弁護士法人ブライトでは、システム開発・SaaS事業・受託開発を行う中小企業の顧問契約を多数受任しており、契約書テンプレートの提供から個別案件の契約レビュー、紛争発生時の代理交渉・訴訟対応まで一貫してサポートしています。紛争を「起こさない」体制づくりをご一緒に設計させてください。