システム開発の契約で失敗しない方法（請負/準委任/NDA/著作権の注意点）

なぜ「契約」でシステム開発は失敗するのか

システム開発のトラブルは、技術力の差よりも契約で“期待値”と“責任範囲”を言語化できていないことから起きがちです。特に、開発に詳しくない発注側（中小企業の経営者・マネージャーや情シス）では「良いものを作ってくれるだろう」「言わなくても分かるはず」という前提が混ざり、要件の曖昧さがそのまま契約書にも反映されます。

代表的な失敗パターンは次の通りです。

• 仕様が固まっていないのに請負契約で固定価格にしてしまい、後から「追加費用」「納期延長」「品質低下」が発生する
• 準委任なのに「成果物」を期待し、ベンダーは「作業提供」と捉えて認識がズレる
• NDAが弱く、社内データや顧客情報の扱いで後から揉める
• 著作権・利用権の取り決めがなく、納品後に改修できない／別ベンダーに引き継げない
• 検収・受入の基準がなく、どこで「OK」か決められずプロジェクトが終わらない

このような問題は、開発工程の知識よりも、契約形態（請負/準委任）と、NDA・著作権・検収・変更管理をセットで設計することで大半を避けられます。以降では、実務でそのまま使える観点と例文レベルの考え方まで落とし込みます。

請負契約と準委任契約：選び方を「仕様の確定度」で決める

システム開発の契約形態は大きく請負と準委任に分かれます。違いを一言でいうと、請負は「完成責任」、準委任は「作業の提供（善管注意義務）」です。つまり、何を約束する契約なのかが違います。

請負契約が向くケース（完成物を約束できる）

請負は「この機能を、この品質で、この日までに完成させる」を契約上約束しやすい反面、仕様がぶれると摩擦が出ます。請負が向くのは、要件が固まっていて変更が少ない場合です。

• 既存システムの同等置き換え（機能がほぼ決まっている）
• 小規模な改修（影響範囲が限定的）
• 画面数・帳票数・外部連携が明確で、受入基準が決められる

請負契約では、成果物（納品物）・検収方法・瑕疵対応・成果物の範囲を強く合意する必要があります。ここが曖昧なまま契約すると、後で「それは範囲外」「当然入っているはず」が起きます。

準委任契約が向くケース（探索しながら進める）

準委任は「人月で支払う契約」と理解されがちですが本質は違い、仕様が確定していない状態でも、適切なプロセスで前に進めるための契約です。例えば、要件定義・PoC・UI/UX検証・データ整備・アジャイル開発など、途中で方針が変わり得る案件に向きます。

• 新規事業のプロダクト（要件が流動的）
• AI活用・データ分析など、試しながら決める必要がある
• 業務が複雑で、現場ヒアリングを重ねないと仕様が定まらない

準委任で重要なのは、「成果物を約束しない」ことを放置するのではなく、作業の中間成果（ドキュメント、プロトタイプ、スプリント成果）と意思決定の方法を契約・運用で固定することです。これがないと「お金は払ったのに何も残っていない」という不満が残ります。

現実解：フェーズを分けて契約する

失敗しにくい設計としておすすめは、前半を準委任（要件定義・設計）、後半を請負（実装・納品）のようにフェーズで契約を分ける方法です。仕様が固まった時点で請負に切り替えることで、発注側は予算見通しを立てやすく、受注側も完成責任を負いやすくなります。

契約書で必ず押さえる共通項目（検収・変更・責任・支払い）

請負/準委任どちらでも、契約書と発注書（仕様書・見積書・SOW）に落とすべき要点があります。ここを押さえると、交渉やトラブル対応が「感情」ではなく「合意」に基づいて進みます。

成果物・作業範囲の定義（SOWの重要性）

契約書だけで範囲を表現するのは限界があるため、実務ではSOW（Statement of Work：作業範囲記述書）や仕様書・画面一覧・API一覧などを添付して、「何をやる/やらない」を明確化します。添付資料は「契約の一部」として効力を持たせ、版管理（更新履歴）を残すのが安全です。

検収（受入）の条件と期限

検収は「納品を受け入れて支払い確定する」重要な手続きです。検収条件が曖昧だと、ベンダーは「納品した」、発注側は「使える状態ではない」で対立します。最低限、次を決めます。

• 受入テストの範囲（どの機能をどこまで確認するか）
• 合格基準（致命的バグの定義、軽微不具合の扱い）
• 検収期間（例：納品後10営業日以内に合否通知）
• みなし検収（期限までに通知がなければ検収完了とするか）

発注側としては「みなし検収」が怖い場合もありますが、無期限に判断を先延ばしにするとプロジェクトが終わらず、結果的に保守移行も進みません。現場の負担を考え、検収観点を事前にテストケースとして用意しておくのが現実的です。

変更管理（追加開発・仕様変更）

炎上の最大要因が「仕様変更の扱いが決まっていない」ことです。請負では特に、契約金額に含まれない追加作業が発生します。準委任でも、優先度変更により計画が崩れます。そこで変更要求（CR）のルールを決めます。

• 変更の起票方法（誰が、何を、いつまでに）
• 影響評価（費用・納期・品質・リスク）を誰が出すか
• 承認プロセス（承認なしの着手は禁止）
• 軽微変更の扱い（一定時間内は吸収、などの上限）

契約に「協議のうえ」とだけ書くのは危険です。協議の手順がないと協議が成立しません。実務では、議事録・チケット・Backlog/Jira等の記録を「合意の証跡」にします。

責任分界点（発注側の役割も明記する）

開発はベンダーだけでは進みません。業務要件の確定、データ提供、関係部署調整、受入テスト、運用体制整備など、発注側のタスクが遅れると全体が遅延します。契約・SOWに発注側の前提条件（依頼事項）を入れておくと、遅延時の原因切り分けが容易になります。

支払い条件（マイルストーンと分割）

一括払いは発注側にリスクが高く、全額後払いは受注側の資金負担が重くなります。一般的には、着手金＋中間＋検収後の分割や、準委任なら月次締めが現実的です。請負でも「設計完了」「α版」「本番リリース」などマイルストーンで分けると、双方の緊張感と納得感が保てます。

NDA（秘密保持契約）で守るべき情報と、抜けがちな落とし穴

NDAは「とりあえず締結する書類」になりがちですが、システム開発では扱う情報が広く、漏えい時の損害も大きいため、内容の確認が重要です。特に中小企業では、顧客リスト・売上データ・原価・業務手順など、漏れると競争力に直撃する情報が含まれます。

NDAで最低限確認したい項目

• 秘密情報の定義（口頭情報、画面共有、チャット、ログ、ソースコードを含むか）
• 目的外利用の禁止（開発以外の用途で使えない）
• 再委託先への開示条件（下請け・クラウド運用会社への共有をどうするか）
• 管理方法（アクセス権、持ち出し、クラウドストレージの制約）
• 返却・消去（契約終了時にデータをどう扱うか、バックアップを含むか）
• 存続期間（開発後も一定期間は秘密保持が続く）

個人情報・機微情報がある場合はNDAだけでは足りない

顧客情報や従業員情報などの個人データを扱う場合、NDAに加えて、委託先管理として取扱い手順・アクセス制限・監査可能性を運用で担保する必要があります。たとえば、開発環境に本番データをそのまま入れない、マスキングしたテストデータを用意する、閲覧権限を最小化する、といった実務が重要です。

また、AI機能を試すために外部APIへデータを送るケースでは、送信データの範囲・学習利用の有無・保管期間が論点になります。ここはNDAだけでなく、利用規約・データ処理条項（DPA相当）まで確認し、必要なら「送信禁止データ」を契約添付で明確化します。

著作権・ソースコードの扱いで「納品後に詰む」ケースを防ぐ

システム開発の契約で見落とされがちなのが著作権です。発注側は「お金を払ったのだから自社のもの」と思いがちですが、法律上はソースコードや設計書は著作物になり得ます。契約で決めていないと、納品後に次のような問題が起こります。

• 別ベンダーに引き継ぎたいが、ソースコードの利用条件が曖昧で揉める
• 改修を自社内でやりたいが、編集・改変の権利が明確でない
• 開発会社がテンプレートや共通部品を使っていて、権利の切り分けができていない
• オープンソースを使っており、ライセンス違反リスクがある

「著作権譲渡」か「利用許諾」かを先に決める

発注側のゴールにより最適解は変わります。一般に、将来の自由度を最大化したいなら著作権譲渡（または必要な権利の移転）を検討します。一方、開発会社の汎用部品まで全て譲渡させるのは現実的でないことも多く、再利用される共通部品は開発会社に残しつつ、自社が困らない利用許諾を得るという設計が多いです。

ソースコードの納品範囲と「ビルドできる状態」を契約で担保する

「ソースコード一式」と書いても、実際には環境変数、ビルド手順、秘密鍵、CI設定、インフラ構成が欠けていると再現できません。納品定義として、第三者が手順書に沿ってビルド・デプロイできる状態を求めると、将来の保守が安定します。

• リポジトリ（Git等）の引き渡し方法、履歴の扱い
• 依存関係（ライブラリ、バージョン）とロックファイル
• 開発・検証・本番の環境差分と構築手順
• インフラがIaCならコード（Terraform等）の納品
• 秘密情報は別管理し、受け渡し方法を定義

オープンソース（OSS）とライセンスのリスク

多くのシステムはOSSを利用します。これは悪いことではありませんが、ライセンス条件によっては、配布時の義務やソース開示義務が絡みます。発注側が最低限求めたいのは、採用OSS一覧（SBOM相当）とライセンス遵守の説明です。契約で「OSS利用時は事前通知」「禁止ライセンスの扱い」などを決めておくと安心です。

失敗しないための進め方：発注側が持つべき資料と運用ルール

契約は「紙」ですが、プロジェクトは「運用」で決まります。発注側が準備すべきものを揃え、意思決定の場を作るだけで、炎上確率は大きく下がります。

発注前に用意したい最小セット

• 目的と成功条件（何を改善したいか、KPI、いつまでに）
• 現状業務の流れ（紙でも可：誰が何を入力し、どこで詰まるか）
• 利用者・権限・拠点などの前提（ユーザー数、ピーク時間）
• 連携先（会計、基幹、SaaS、CSV運用など）
• 制約条件（セキュリティ、クラウド可否、社内規程、予算上限）

ここで大事なのは、完璧な仕様書を作ることではありません。「判断に必要な前提」を先に共有し、ベンダーからの質問の質を上げることです。

会議体と意思決定の設計（情シス・現場・経営の三角形）

開発では、「現場はこうしたい」「情シスは守りたい」「経営は早く成果が欲しい」がぶつかります。そこで、週次定例（進捗・課題）、隔週の仕様決定会（優先度・変更承認）、月次のステアリング（予算・方針）のように、レイヤー別に会議体を分けると意思決定が滞りにくくなります。議事録を合意の根拠として残すことが、契約条項（変更管理・責任分界）を現場で機能させます。

ベンダー選定で見るべきは「技術」だけではない

提案書や見積の比較では、金額や機能だけでなく、契約・運用を含めたプロジェクト設計力が重要です。確認観点の例は次の通りです。

• 要件が曖昧な部分を質問で掘り起こしてくれるか
• 請負/準委任の提案理由が合理的か（自社に都合が良いだけでないか）
• リスク（スコープ増、データ品質、運用負荷）を先に言ってくれるか
• 納品物（設計書、テスト、手順書、ソース）の粒度が具体的か

まとめ

システム開発の契約で失敗しないための核心は、契約形態（請負/準委任）を「仕様の確定度」に合わせ、NDA・著作権・検収・変更管理を一体で設計することです。技術が分からなくても、次のポイントを押さえれば、発注側として大きな地雷を避けられます。

• 仕様が固いなら請負、探索が必要なら準委任。迷うならフェーズ分割が現実的
• 範囲（SOW）・検収条件・変更管理（CR）・責任分界点・支払い条件は必ず具体化
• NDAは目的外利用、再委託、返却消去、個人情報の扱いまで確認する
• 著作権は「譲渡」か「利用許諾」かを決め、ソースコードが再現できる納品を求める

もし「自社の場合は請負と準委任のどちらが良いのか」「契約書のどこを直すべきか」「著作権やOSSが不安」といった状況であれば、要件の整理段階から第三者視点での確認が効果的です。契約は一度結ぶと後戻りが難しいため、着手前の数時間〜数日の見直しが、数百万円〜数千万円規模の損失を防ぎます。