制作会社選びで迷っている方へ
費用相場・制作期間・進め方など、
まずは無料で方向性を一緒に整理いたします。
質問だけでも大歓迎です。
\ 強引な営業は一切ありませんのでご安心ください /


費用相場・制作期間・進め方など、
まずは無料で方向性を一緒に整理いたします。
質問だけでも大歓迎です。
\ 強引な営業は一切ありませんのでご安心ください /
システム開発を外注する際は、「請負契約」と「準委任契約」の違いを理解しておくことが大切です。
どちらもシステム開発でよく使われる契約形態ですが、責任範囲や報酬の発生条件が大きく異なります。
結論から言うと、請負契約は成果物の完成に責任を持つ契約、準委任契約は業務の遂行に対して報酬を支払う契約です。
この記事では、システム開発における請負契約と準委任契約の違いや、どちらを選ぶべきかをわかりやすく解説します。


システム開発の外注では、契約形態によって「ベンダーがどこまで責任を負うのか」が変わります。
たとえば、同じWebシステムの開発でも、請負契約であれば成果物の完成が前提になります。
一方、準委任契約であれば、一定期間の作業や専門業務の遂行に対して報酬が発生します。
契約すべき形態を間違えると、発注者と開発会社の間で認識のズレが起きやすくなります。
システム開発では、以下のようなトラブルが起こりがちです。
これらは、請負契約と準委任契約の違いを曖昧にしたまま契約してしまうことで起こりやすい問題です。
特にシステム開発は、発注時点ですべての仕様を完璧に決めることが難しいため、契約形態の選び方がプロジェクトの成否に直結します。

請負契約とは、受注者が仕事の完成を約束し、発注者がその結果に対して報酬を支払う契約です。
システム開発でいえば、Webサイト、業務システム、ECサイト、予約システムなど、あらかじめ定めた成果物を完成させることが目的になります。
民法上も、請負契約は「仕事の完成」を目的とする契約とされています。
システム開発における請負契約では、成果物の引き渡しや検収完了によって報酬が発生するのが一般的です。
| メリット | デメリット |
|---|---|
| ・成果物の完成が前提のため、ゴールが明確 ・要件・納期・費用を事前に決めるため、予算管理がしやすい ・最終的に納品される内容がイメージしやすい ・完成責任が開発会社側にあるため、品質担保が期待できる | ・仕様変更や機能追加に柔軟に対応しづらい ・変更時は追加費用や納期延長が発生しやすい ・要件が曖昧だと認識のズレが起きやすい ・「契約範囲内かどうか」でトラブルになりやすい |
請負契約が向いているのは、以下のようなケースです。
たとえば、既存サイトのリニューアル、仕様が固まった業務システム、機能範囲が明確なECサイト構築などは、請負契約と相性が良いです。

準委任契約とは、法律行為ではない事務作業や業務の遂行を委託する契約です。
システム開発では、エンジニアやPM、デザイナーなどが一定期間プロジェクトに参加し、業務を行う形で使われることが多くあります。
請負契約のように成果物の完成そのものが目的になるわけではありません。
作業時間や稼働期間に応じて報酬が発生する「履行割合型」の準委任契約が代表的です。
| メリット | デメリット |
|---|---|
| ・仕様変更や機能追加に柔軟に対応しやすい ・要件が固まっていない段階でも開発を進めやすい ・ユーザーの反応を見ながら改善できる ・新規サービス開発やアジャイル開発と相性が良い | ・成果物の完成が保証されにくい ・進捗管理が甘いと、費用だけが膨らみやすい ・発注者側にも優先順位や作業管理が求められる ・善管注意義務はあるものの、請負契約のような完成責任はない |
準委任契約が向いているのは、以下のようなケースです。
たとえば、新規サービスの立ち上げ、PoC、要件定義、アジャイル開発、既存システムの継続改善などでは、準委任契約の方が進めやすいケースも多いです。

請負契約と準委任契約の一番大きな違いは、成果物の完成責任です。
請負契約では、開発会社が成果物の完成に責任を持ちます。
一方、準委任契約では、業務を適切に遂行することが中心であり、成果物の完成そのものを直接約束する契約ではありません。
そのため、発注者が「完成まで責任を持ってほしい」と考えるなら請負契約が向いています。
反対に、「仕様を調整しながら進めたい」「まずはプロトタイプを作りたい」という場合は準委任契約が向いています。
請負契約では、成果物の納品や検収をもって報酬が発生するのが一般的です。
一方、準委任契約では、作業時間や契約期間に応じて報酬が発生します。
つまり、請負契約は「完成したもの」に対して支払う契約、準委任契約は「実施した業務」に対して支払う契約と考えるとわかりやすいです。
請負契約では、契約時に定めた範囲をもとに開発を行うため、仕様変更が発生すると追加費用やスケジュール変更が必要になりやすいです。
準委任契約では、稼働時間や作業内容を調整しながら進められるため、仕様変更には比較的柔軟に対応できます。
ただし、柔軟に対応できるからといって、無制限に変更できるわけではありません。
準委任契約でも、作業範囲、稼働時間、優先順位、成果物の確認方法は明確にしておく必要があります。

システムの仕様や画面、機能、納期、予算が明確に決まっている場合は、請負契約が向いています。
たとえば、「この機能を持つ予約システムを作りたい」「既存の業務フローをシステム化したい」「要件定義が完了している」という状態であれば、成果物を定義しやすいため、請負契約で進めやすくなります。
一方で、作りたいものの方向性はあるものの、具体的な仕様がまだ固まっていない場合は、準委任契約が向いています。
特に新規サービス開発では、最初から完璧な仕様を決めることは難しいものです。
ユーザーの反応や事業状況を見ながら改善していく必要があるため、準委任契約の方が現実的なケースも多くあります。
実務では、請負契約か準委任契約のどちらか一方だけで進めるのではなく、フェーズごとに使い分ける方法もあります。
たとえば、要件定義や企画段階は準委任契約で進め、仕様が固まった後の設計・開発・実装は請負契約にする方法などです。
この進め方であれば、初期段階では柔軟性を確保しつつ、開発段階では成果物の完成責任を明確にできます。
契約形態を選ぶ際は、「現時点で完成物を明確に定義できるか」を基準にすると判断しやすくなります。
完成物を明確に定義できるなら請負契約、まだ定義できないなら準委任契約が基本です。
無理に請負契約にしてしまうと、後から仕様変更や追加費用でトラブルになりやすくなります。
反対に、完成物が明確なのに準委任契約にすると、発注者側にとって成果が見えづらくなる可能性があります。

システム開発の契約で最も重要なのは、契約前の要件定義です。
どのような機能が必要なのか、どの業務をシステム化するのか、どこまでを開発範囲に含めるのかを明確にしておかなければ、請負契約でも準委任契約でもトラブルになります。
特に請負契約では、要件が曖昧なまま契約すると、後から「これは含まれている」「これは含まれていない」という認識違いが起きやすくなります。
契約書では、成果物や作業範囲をできるだけ具体的に記載することが重要です。
たとえば、以下のような項目を明確にしておくと安心です。
特にシステム開発では、「どこまでが今回の契約範囲なのか」を明確にしておくことが重要です。
システム開発では、途中で仕様変更が発生することは珍しくありません。そのため、契約前に仕様変更のルールを決めておく必要があります。
たとえば、以下を事前に決めておくことで、後から揉めにくくなります。
請負契約では、検収条件も重要です。
検収とは、納品されたシステムが契約内容を満たしているかを確認する工程です。
検収条件が曖昧だと、「完成している」「まだ完成していない」という認識のズレが起こります。
そのため
を事前に定めておくことが大切です。
システム開発のトラブルは、契約書の問題だけでなく、発注者と開発会社の認識のズレから起こることも多くあります。
発注者は「当然こうなる」と思っていても、開発会社は別の前提で設計しているかもしれません。
そのため、契約前だけに限らず、開発中も定例ミーティングや議事録、仕様書、確認資料を通じて、認識合わせを続けることが重要です。
請負契約と準委任契約のどちらが正解というわけではありません。大切なのは、開発内容やプロジェクトの状況に合った契約形態を選ぶことです。