システム開発を外注しようと調べていると、「受託開発」と「請負開発」という言葉が並んで出てきて、何がどう違うのか分からず戸惑う方は多いと思います。見積書や提案書に「請負契約」「準委任契約」と書かれていても、それぞれで自社の責任やリスクがどう変わるのかまでは、なかなか説明されません。
実のところ、受託開発と請負開発は同じ土俵で比べられる言葉ではありません。受託開発は「外部の会社に開発を頼む頼み方」全般を指し、請負開発は「請負契約という契約の形で頼むこと」を指します。受託開発の多くは請負契約で結ばれますが、仕様が固まりきらない案件では準委任契約で頼むこともあります。この記事では、受託開発と請負開発の違いを言葉の整理から始め、請負契約と準委任契約で発注者の責任や守られ方がどう変わるのか、どちらで頼むべきか、契約前に何を確認すべきかまでを発注側の目線で解説します。
この記事のポイント
- 受託開発は「頼み方」全般、請負開発は「請負契約で頼むこと」を指す
- 受託開発の多くは請負契約だが、準委任契約で頼む受託開発もある
- 本当の分かれ目は請負契約か準委任契約かで、完成責任の所在が変わる
- 仕様が固まっているなら請負、伴走や変更が多いなら準委任が向く
目次
受託開発と請負開発の違いを整理する
受託開発と請負開発の違いでつまずくのは、多くの場合「同じレベルの2択」だと思って比べてしまうからです。実際には、この2つは指している層が違います。ここを分けて理解すると、開発会社の提案がすっと読めるようになります。
受託開発は「頼み方」、請負開発は「契約の種類」
受託開発とは、外部の開発会社にシステムづくりを委託し、成果物を納めてもらう頼み方全般を指す言葉です。自社に開発リソースがなくても、専門の会社に任せて必要なシステムを手に入れられます。いわば「外注でシステムを作ってもらうビジネスの形」を表す、広めの言葉です。
一方の請負開発は、「請負契約」という契約形態で開発を頼むことを指します。請負契約は、民法上「仕事の完成」を約束する契約です。つまり請負開発と言ったときは、契約の種類にフォーカスした言い方になっています。受託開発が「誰に、どういう関係で頼むか」という頼み方全体の話なのに対し、請負開発は「その頼み方を、どの契約で結ぶか」という一段細かい話だと考えると整理しやすいです。
私が発注相談を受けるときも、この2つを対等な選択肢のように並べて悩んでいる方は少なくありません。ですが実際は「受託開発で頼む」と決めたうえで、「その契約を請負にするか準委任にするか」を選ぶ、という入れ子の関係になっています。まずはこの層の違いを押さえておくと、以降の判断がぶれません。
多くの受託開発が請負契約で結ばれる理由
受託開発と請負開発がほぼ同じ意味で使われがちなのは、受託開発の多くが請負契約で結ばれているからです。発注側の多くは「動くシステムを完成させて納めてほしい」と考えます。この「完成した成果物に対してお金を払いたい」というニーズに、仕事の完成を約束する請負契約がそのまま合致します。
発注者にとって、請負契約には分かりやすいメリットがあります。あらかじめ仕様と金額を決めて契約するため、総額が読みやすく、社内の予算承認も取りやすい。そして完成責任が開発会社側にあるので、「作りきってもらう」ことを契約で担保できます。この安心感から、受託開発といえば請負契約、というイメージが定着しています。
ただし、受託開発がすべて請負契約というわけではありません。仕様が動きやすい開発や、開発会社に継続的に伴走してもらう進め方では、準委任契約で受託するケースもあります。「受託開発＝請負契約」と思い込むと、準委任という選択肢を最初から見落としてしまうので注意が必要です。
本当の分かれ目は請負契約か準委任契約か
ここまでを踏まえると、発注者が本当に判断すべきなのは「受託開発か請負開発か」ではなく、「受託開発の契約を請負契約にするか、準委任契約にするか」だと分かります。この契約形態の違いこそが、発注者の責任や守られ方を大きく左右します。
請負契約は、前述のとおり仕事の完成を約束する契約です。開発会社は成果物を完成させる義務を負い、完成しなければ原則として報酬を請求できません。対して準委任契約は、業務を誠実に遂行することを約束する契約で、成果物の完成までは約束しません。決められた稼働のなかで専門家として誠実に作業すれば、仮に成果物が想定どおり完成しなくても報酬は発生します。
なお、準委任契約は「人手を借りる」SESと構造が近く、混同されがちです。受託開発とSESの違いについては受託開発とSESの違いを解説した記事で詳しく整理しているので、あわせて読むと契約形態ごとの関係がつかめます。次の章では、請負と準委任で発注者の責任がどう変わるのかを具体的に見ていきます。
請負と準委任で変わる受託開発の責任
同じ受託開発でも、請負契約か準委任契約かで、発注者が受け取れる保証と負うリスクは変わります。ここを理解しないまま契約すると、「完成すると思っていたのに未完成のまま費用だけ発生した」といったズレが起きます。
完成責任と契約不適合責任はどう違うか
請負契約と準委任契約の違いは、発注者から見ると「どこまで責任を持ってもらえるか」に集約されます。主な違いを整理すると次のとおりです。
| 観点 | 請負契約 | 準委任契約 |
|---|---|---|
| 約束する内容 | 仕事（成果物）の完成 | 業務を誠実に遂行すること |
| 完成責任 | あり（完成させる義務を負う） | なし（善管注意義務を負う） |
| 契約不適合責任 | あり（不具合の修正を求められる） | 原則なし |
| 報酬の対象 | 完成した成果物 | 業務の遂行や稼働 |
| 仕様変更への対応 | 都度の追加合意が必要になりやすい | 柔軟に対応しやすい |
| 発注者の主な安心材料 | 完成を契約で担保できる | 状況に応じて進め方を変えられる |
発注者にとって重要なのは、完成責任と契約不適合責任です。請負契約なら、開発会社が成果物を完成させる義務を負い、納品後に不具合が見つかれば契約不適合責任として修正対応を求められます。準委任契約では完成責任がなく、成果物の不具合に対する契約不適合責任も原則ありません。そのぶん、完成に届かなかったときのリスクは発注者側に残ります。
準委任契約で開発会社が負う「善管注意義務」という言葉も、発注者としては押さえておきたい概念です。これは「善良な管理者としての注意義務」の略で、専門家として通常期待される水準の注意を払って業務を遂行する義務を指します。完成までは約束しないものの、いいかげんに作業してよいわけではなく、プロとして相応の品質で取り組む責任は負っています。ただし、その水準を満たしていれば成果物が未完成でも義務違反にはならないため、完成そのものを求めたい発注者にとっては物足りなさが残る点に注意が必要です。
この構造を知らずに準委任契約で結ぶと、「お金は払ったのに動くシステムが残らなかった」という事態が起こり得ます。逆に言えば、完成をしっかり保証してほしい案件で準委任を選ぶのは、発注者にとって不利になりやすいということです。契約書に書かれた「請負」「準委任」の一語で守られ方が変わるので、金額や納期だけでなく契約形態そのものを必ず確認しておきましょう。
仕様が固まっているかで請負か準委任か選ぶ
では発注者はどちらを選べばよいのか。判断軸はシンプルで、「発注時点で仕様がどこまで固まっているか」です。
作りたいものがはっきりしていて、仕様書として書き出せる状態なら、請負契約が向きます。完成という到達点を定義できるからこそ、開発会社に完成責任を持たせられ、総額も固定しやすい。発注者にとって最も守られる形です。一方、新規事業やDXの初期のように、作りながら仕様を詰めたい、優先順位が動く、といった案件では、完成物を先に定義しきれません。無理に請負で結ぶと、変更のたびに追加見積もりと再契約が必要になり、かえって進みにくくなります。こうした案件では、準委任契約で開発会社に伴走してもらう進め方（いわゆるラボ型やアジャイル的な進め方）が合います。
たとえば、既存の紙業務をそのままシステム化するような、ゴールがはっきりした案件は請負が向きます。完成の姿を仕様書に落とし込めるため、完成責任を持たせて総額を固定できるからです。反対に、利用者の反応を見ながら機能を足していきたいサービス開発や、社内のどの業務から手をつけるか自体を検討しながら進めるDX案件では、準委任のほうが素直です。作りながら優先順位を組み替えられるので、変更のたびに再契約する手間がかかりません。工程で分けて、要件定義は準委任・実装は請負とする折衷案も現実的です。
私の感覚では、発注者が失敗しやすいのは「仕様が固まっていないのに請負で安く早く作らせようとする」パターンです。完成の定義が曖昧なまま請負契約を結ぶと、認識のズレが検収時に噴き出します。仕様が動く前提なら、最初から準委任で柔軟に進めるほうが、結果的にトラブルは少なくなります。開発手法とあわせた進め方の判断は受託開発の仕組みと流れを解説した記事も参考になります。
契約前に発注者が確認すべきこと
請負か準委任かを決めたら、契約前に責任範囲の前提を必ず確認しておきます。ここが曖昧だと、どちらの契約でもトラブルの火種になります。最低限、次の点は握っておきたいところです。
- 「完成」の定義と検収の基準（何をもって完成・合格とするか）
- 仕様変更が発生したときの費用と手続きの扱い
- 契約不適合責任の対応範囲と期間
- 再委託（下請けへの外注）の可否と、その場合の責任の所在
- 成果物やソースコード、著作権の帰属
これらは見積もりや契約の段階で抜けやすい項目でもあります。システム開発見積もりチェックシート（危険サインを見抜く60項目）で、責任範囲や検収の前提に抜けがないかを点検しておくと、請負・準委任どちらで結ぶ場合も安心です。特に著作権やソースコードの扱いは後から揉めやすいので、受託開発の契約で確認すべきことをまとめた記事もあわせて確認しておくとよいでしょう。
よくある質問
- Q. 受託開発は必ず請負契約になりますか？
- A. いいえ。受託開発の多くは請負契約で結ばれますが、仕様が固まりきらない案件や、開発会社に継続的に伴走してもらう進め方では準委任契約で受託するケースもあります。受託開発だからといって自動的に請負契約になるわけではありません。
- Q. 準委任契約だと発注者は不利になりますか？
- A. 一概に不利とはいえません。準委任には完成責任がないぶん、完成保証を求める案件では発注者のリスクが残ります。一方で、仕様が動く案件では柔軟に進められるメリットがあります。案件の性質と合っているかで判断するのが適切です。
- Q. 途中で請負契約から準委任契約に変えられますか？
- A. 双方の合意があれば可能です。要件定義や設計は準委任、仕様が固まった実装工程は請負、というように工程ごとに契約形態を分ける進め方もあります。開発会社に相談してみるとよいでしょう。
