システム開発の契約｜請負と準委任の違い・支払い・契約書の必須項目

システム開発の契約は、主に「請負契約」と「準委任契約」に分かれます。どちらを選ぶかで、責任・支払い方・トラブル時の対応が変わります。この記事では、2つの違いに加え、支払いのタイミング・契約不適合責任・ソースコードの権利帰属・契約書の必須項目まで、専門用語をかみくだいて解説します。

※本記事は契約の一般的な考え方の解説です。実際の契約は個別事情により異なるため、重要な契約は専門家にご確認ください。

請負契約と準委任契約の違い

システム開発の契約は、法律上は「請負」か「準委任」のどちらかがベースになります。名前は似ていますが、**「完成させる責任があるかどうか」**という一点で性格が大きく変わります。

	請負契約	準委任契約
責任	成果物を完成させる責任	業務を適切に遂行する責任
完成の保証	あり（仕様どおり完成・納品）	なし（遂行が目的）
指揮命令	開発会社が自社の判断で進める	開発会社が自社の判断で進める
支払い	検収・納品後が基本（着手金＋残金も）	稼働（人月）ベースの月次精算
契約不適合責任	あり	原則なし（善管注意義務）
向いているケース	作るものが固まっている	作りながら決める・継続改善

かみくだくと、**請負は「決めたものを完成させてもらう」、準委任は「一緒に走ってもらう」**契約です。請負は「家を建ててもらう（完成して初めて意味がある）」、準委任は「専門家に一定期間コンサルしてもらう（動いてくれること自体に価値がある）」とイメージすると分かりやすいでしょう。

注意したいのは、どちらも「開発会社が自社の判断で作業を進める」点は同じということ。発注側が開発者の一人ひとりに直接指示を出す形は、後述する「偽装請負」の問題につながります。

なお、準委任には2つのタイプがあります。稼働した時間・工数に応じて払う「履行割合型」と、あらかじめ決めた成果の完成に対して払う「成果完成型」（2020年の民法改正で明文化）です。伴走型・ラボ型の開発では履行割合型が多く使われますが、「この機能まで作れたら支払う」という区切りを設けたい場合は成果完成型も選択肢になります。契約書のどちらを採用しているかで支払い条件が変わるため、見積り段階で確認しておくと安心です。

発注側から見たメリット・デメリット

同じ開発でも、契約形態によって発注側が得られる安心と、抱えるリスクが変わります。発注者目線で整理します。

請負契約

• メリット：総額を固定しやすく予算が立てやすい。完成責任があるため「作りきってもらえる」安心感がある。不具合には契約不適合責任で対応を求められる。
• デメリット：仕様を先に固める必要があり、途中の変更に弱い（変更は追加見積りになりやすい）。要件が曖昧なまま契約すると「言った・言わない」で揉めやすい。

準委任契約

• メリット：要件の変更に強い。作りながら優先順位を変えたり、運用しながら改善したりしやすい。伴走型・アジャイル型の開発に向く。
• デメリット：完成保証がないため、成果が出ないまま費用だけ膨らむリスクがある。総額が読みにくく、進捗管理を発注側もある程度担う必要がある。

ざっくり言えば、**「予算と完成の確実性を優先するなら請負」「柔軟さと改善スピードを優先するなら準委任」**です。要件がどれだけ固まっているかで、向く形が変わります。要件整理の進め方は要件定義の進め方も参考にしてください。

支払いのタイミングの違い

「いつ・いくら払うか」も契約形態で変わります。ここがずれると資金繰りや検収でトラブルになりやすい部分です。

• 請負：検収後の一括、または「着手金＋中間金＋残金」など段階払い。完成に対して支払う。着手金の目安は総額の20〜30%、中間金を挟むなら各30%前後、といった配分がよく見られます。
• 準委任：毎月の稼働（例：2人月×単価）を精算。動いた分に対して支払う。「ラボ型開発」（一定人数を一定期間確保）もこの形です。

例：総額600万円の請負案件を「着手30%・中間30%・検収40%」で分けるなら、契約時180万円・中間段階180万円・検収後240万円といった流れになります。段階払いは、開発会社の資金繰りと発注側のリスク分散のバランスをとる仕組みです。全額前払いは避け、必ず検収後にまとまった額を残す設計にしておくと安全です。

発注側から見たコツは、「支払いの節目」と「確認できる成果物」を対応させること。たとえば中間金の条件を「設計書の提出」「主要画面の動作デモ」などに紐づけておくと、お金だけ先に進んで実物が見えない、という事態を避けられます。反対に「◯月末に一律で支払う」と日付だけで区切ると、進捗が遅れても支払い義務だけ発生してしまいます。支払い条件の考え方は支払いのタイミング・見積りの見方も合わせてご覧ください。

契約不適合責任（旧・瑕疵担保責任）を押さえる

請負では、納品物が契約に適合しない（バグ・仕様漏れ等）場合、発注側は修補・代金減額・損害賠償・解除を求められます。これが契約不適合責任です（2020年の民法改正で「瑕疵担保責任」から改称）。

ポイントは対応期間。システム開発では「検収後◯ヶ月」と契約で定めるのが一般的（例：3〜6ヶ月）。ここが曖昧だと「これは無償対応？有償？」で揉めます。契約前に必ず確認しましょう。

あわせて押さえたいのが「どこまでが契約不適合か」の線引きです。仕様書に書かれた挙動と違えば契約不適合ですが、「仕様書に書いていない新機能の追加」は不適合ではなく別途の追加開発です。つまり、契約不適合責任を実質的に機能させるには、仕様書がきちんと書かれていることが前提になります。責任期間だけでなく、次の3点を契約で明確にしておきましょう。

• 対応期間（例：検収後3〜6ヶ月）
• 対象範囲（仕様書に沿った不具合か／仕様外の要望か）
• 対応方法（無償修補か・代金減額か・その判断は誰がするか）

成果物（ソースコード）の権利は誰のもの？

見落とされがちですが、**契約で最も重要な論点のひとつが「ソースコードの著作権が誰に帰属するか」**です。ここを決めておかないと、後で大きな不利益を被ることがあります。

著作権法では、契約で譲渡を定めない限り、開発したソースコードの著作権は開発会社に残るのが原則です。発注側が代金を払っても、コードの権利まで自動的に手に入るわけではありません。権利が開発会社に残ったままだと、次のような問題が起きます。

• 他社に乗り換えられない：改修や機能追加を頼めるのが、そのコードを書いた会社だけになる。
• 改修のたびに言い値になりやすい：競合がいないため、追加開発の費用や納期の交渉力が下がる。
• 会社が対応をやめると詰む：開発会社の廃業・撤退・担当者離脱で、システムが塩漬けになる。

これがいわゆるベンダーロックインです。回避するには、契約書に「本件成果物（ソースコードを含む）の著作権は、検収・支払い完了をもって発注者に譲渡する」といった条項を入れ、あわせて著作者人格権の不行使についても取り決めておくのが基本です。ソースコード一式・設計書・環境構築手順の引き渡し方法まで明記できると万全です。

例：ある会社が業務システムを外注したものの、契約に著作権の記載がなく、機能追加のたびに元の開発会社へ割高な費用で依頼せざるを得なくなった——というのは典型的なロックインの形です。逆に、最初から権利譲渡を契約に入れておけば、将来ほかの会社に相見積りを取ることも、社内エンジニアで改修することも自由にできます。**「支払いが済めばコードは自社のもの」**という状態を、契約時点で確保しておくことが大切です。詳しくはベンダーロックインの回避もご覧ください。

注意：「偽装請負」にならないように

請負・準委任では、発注側が開発者に直接、業務の指揮命令をしてはいけません（してしまうと「偽装請負」として違法とされる恐れがあります）。やり取りは開発会社の窓口・責任者を通すのが基本です。細かい作業指示を直接出したい場合は、労働者派遣など別の形態が必要になります。

具体的には、次のような行為が偽装請負とみなされやすいとされています。

• 発注側が開発者個人に勤務時間や休憩、出退勤を指示する
• 発注側が開発者へ日々の作業指示・タスクの割り振りを直接行う
• 開発会社の責任者が実質的に存在せず、発注側が現場を仕切っている

予防のコツは、**「窓口を一本化する」「指示は成果物ベースで出す」**こと。誰にいつまでに何を、という細かい割り振りは開発会社側に委ね、発注側は「何を実現したいか（要件・優先順位・受け入れ条件）」を伝える役に徹すると、契約形態と実態のズレを防げます。

契約書で必ず確認すべきチェック項目

契約形態にかかわらず、次を書面で明確にしておきましょう。契約書を受け取ったら、この表を横に置いて1行ずつ確認するのがおすすめです。

項目	確認内容	見落とすとどうなる
成果物の範囲	何を納品するか	「これは範囲外」で追加費用に
納期	いつ納品するか	遅延の責任があいまいに
検収の条件	どうなったら「完了」か（→検収とは）	いつまでも「完了」しない
追加費用	変更・追加の単価と手続き	想定外の請求が発生
著作権	成果物の権利が発注側に移るか	ベンダーロックインに
契約不適合責任	対応の範囲と期間	不具合対応が有償扱いに
秘密保持	情報の取り扱い	機密情報の流出リスク
再委託	外部への再委託を認めるか	知らぬ間に第三者が関与
支払い条件	いつ・いくら払うか	資金繰り・検収で衝突
保守・運用	納品後の対応範囲と費用	「作って終わり」で放置

IPA（情報処理推進機構）や経済産業省が公開するモデル契約書を土台にすると、抜け漏れを防げます。ゼロから自作するより、公的に整備された雛形をベースに自社の事情を反映するほうが、条項の抜けや偏りを避けられます。特に追加費用の単価・手続きと著作権の帰属は、金額や将来の自由度に直結するので、口頭ではなく必ず書面で確認してください。

もう1つの実務的なコツは、契約書と仕様書・見積書を「セット」で管理することです。契約書が「範囲は別紙仕様書のとおり」と書いていても、その仕様書が曖昧では意味がありません。契約書・仕様書・見積書の3点が食い違わないよう、金額・範囲・納期の数字が一致しているかを最終確認しておきましょう。

よくあるトラブル事例と予防

契約まわりのトラブルは、パターンがある程度決まっています。代表例と予防策を挙げます（いずれも一般化した架空の例です）。

• 例：追加費用でもめる——「言ったはず」の機能が仕様書になく、後から高額な追加見積りに。→ 予防：範囲を仕様書で確定し、変更時の単価・手続きを契約に明記。

• 例：検収が終わらない——完了基準が曖昧で、細かな要望が延々と続き最終支払いが宙に浮く。→ 予防：検収条件（テスト項目・合格ライン・期間）を先に合意。

• 例：乗り換えできない——著作権が開発会社に残り、他社に改修を頼めず言い値の保守費に。→ 予防：著作権譲渡とソース一式の引き渡しを契約に入れる。

• 例：担当者が消える——キーパーソンの離脱でブラックボックス化し、誰も直せない。→ 予防：設計書・手順書の納品を必須にし、属人化を避ける。

• 例：再委託で品質がぶれる——気づかないうちに一部が外部へ再委託され、想定より品質や連絡体制が落ちる。→ 予防：再委託の可否と、認める場合の責任の所在を契約で明確化。

共通する予防策は、**「範囲・完了条件・権利・トラブル時の対応を、着手前に書面で決めておく」**こと。契約形態そのものより、この4点が明確かどうかが、揉めるかどうかの分かれ目です。逆に言えば、契約書がしっかりしていれば請負でも準委任でも大きく外すことはありません。あわせてよくある失敗パターンや失敗事例も参考になります。

どちらを選べばいい？（使い分け）

• 請負が向く：要件が固まり「この仕様で完成させてほしい」が明確。総額を固定でき予算が立てやすい。
• 準委任が向く：要件が変わりやすく、作りながら方向を決めたい。運用・改善を継続的に頼みたい。

実際には「初期開発は請負、その後の運用・改善は準委任」と組み合わせるのが定番です。判断に迷ったら、次の順で考えると整理しやすいでしょう。

1. 作るものの仕様は、契約時点で8割方固まっているか？→ はい なら請負が有力。
2. 予算を先に固定したいか？→ はい なら請負。
3. 走りながら仕様を決めたい・継続改善したいか？→ はい なら準委任。

契約形態は開発会社が提案するので、発注側は希望を伝えれば十分です。「完成責任を求めたいのか」「柔軟に進めたいのか」という方針だけ整理しておけば、あとは会社側が案件に合った形を組み立ててくれます。もし開発会社が契約形態やその理由をきちんと説明できない場合は、発注前の相性チェックとしても注意信号と考えてよいでしょう。会社選びはシステム開発会社の選び方、社内開発と外注の比較は内製と外注の比較もご覧ください。

一律料金だと契約の不安が減る

契約で発注側が不安になりやすいのは「結局いくらになるのか」という費用面です。D-oneAppは料金が一律100万円（大規模なプロプランは一律200万円）で、総額が最初から固定。請負の「総額が読める安心感」を、追加費用の心配なく得られます。成果物（ソースコード）の権利もお渡しするので、ベンダーロックインの不安も小さくできます。「あとから追加請求が来るのでは」「他社に乗り換えられないのでは」という、契約でありがちな2つの不安をまとめて解消できるのが特徴です。

まとめ

システム開発の契約は、「作るものが固まっているなら請負（検収後払い・完成責任あり）」「作りながら決めるなら準委任（稼働払い）」が基本です。契約不適合責任の期間、著作権（ソースコードの帰属）、偽装請負の注意点を押さえ、契約書はモデル契約を土台に、範囲・納期・検収・追加費用・権利・保守までを書面で明確にしましょう。契約形態そのものより、「何を・いつ・どこまで・トラブル時どうするか」が決まっているかが肝心です。契約の疑問も含め、無料相談でお気軽にご相談ください。