新規サービスやDXの相談を進めていると、開発会社から「受託開発で承ります」と言われることもあれば、「ぜひ共同開発でやりましょう」と提案されることもあります。どちらも外部の会社と一緒にシステムを作る点は同じですが、言葉の響きだけでは何がどう違うのか、自社にとってどちらが得なのかが分からず、返事に迷う方は多いと思います。
結論から言うと、受託開発は「作りたいものを決めて、外部の会社に完成させて納めてもらう頼み方」、共同開発は「両社が役割とお金を出し合い、一緒に作り上げていく頼み方」です。この違いは、契約の形・責任の所在・費用の負担・完成したものの権利が誰のものになるか、というところにはっきり表れます。この記事では、受託開発と共同開発の違いを発注側の目線で整理し、知的財産権が共有になって自社だけで売れなくなる落とし穴や、名目は共同開発でも実態は受託というパターンの見抜き方、そしてどちらで頼むべきかの判断軸までを解説します。
この記事のポイント
- 受託開発は成果物を納めてもらう頼み方、共同開発は両社で協力して作る頼み方
- 受託開発の権利は契約で自社に集められるが、共同開発の成果物は共有になりやすい
- 共同開発は相手の技術やデータが不可欠な新規事業に向き、要件が固まった案件は受託開発が向く
- 費用は全額こちら持ちなのに「共同開発」と呼ばれる案件は、実態が受託開発でないか確認する
目次
受託開発と共同開発の違いを整理する
受託開発と共同開発の違いでつまずくのは、どちらも「外部の会社とシステムを作る」ことだけが目に入り、両社の関係やお金の流れまで見えていないからです。ここを分けて理解すると、開発会社の提案がどちらの前提で話しているのかが読めるようになります。まずは定義・契約・責任・費用・権利の観点で、違いを一つずつ整理していきます。
そもそも受託開発と共同開発は何が違うのか
受託開発とは、発注者が「こういうシステムが欲しい」と要件を決め、その要件をもとに開発会社が成果物を作って納める頼み方です。お金を払うのは発注者、作るのは開発会社という役割がはっきり分かれています。発注者は完成したシステムを受け取り、開発会社は対価として開発費を受け取る。関係としては「頼む側」と「請け負う側」に分かれた、いわば縦の関係です。
一方の共同開発は、二つの会社が対等な立場で、お互いに人・技術・お金・データなどを出し合い、一つの成果物を一緒に作り上げる頼み方です。たとえば、業務ノウハウを持つ事業会社と、開発力を持つIT企業が組んで新しいサービスを作る、といった形が典型です。どちらか一方が「頼む側」なのではなく、両社が当事者として関わる横の関係になります。
私が発注相談を受けるときも、この二つを「安いのはどっち」「早いのはどっち」と同じ物差しで比べようとする方が少なくありません。ですが両者は、そもそも自社がどう関わるか、成果物が誰のものになるかが違います。受託開発は「お金を出して完成品を手に入れる」、共同開発は「一緒に汗をかいて資産を共有する」。この立ち位置の違いが、以降のすべての差につながっていきます。
契約形態と責任の所在はどう違うか
受託開発の契約は、多くの場合「請負契約」で結ばれます。請負契約は成果物の完成を約束する契約で、開発会社が完成責任を負い、納品後に不具合が見つかれば契約不適合責任として修正を求められます。仕様が固まりきらない案件では準委任契約で受託することもありますが、いずれにせよ「開発会社が発注者のために作る」という一方向の責任構造になっている点は変わりません。契約形態ごとの責任の違いは、受託開発と請負開発の違いを解説した記事でも詳しく整理しています。
共同開発の契約は「共同開発契約」という別の形で結ばれます。ここでは、両社がそれぞれ担当する開発範囲や提供するもの（役割分担）、費用の負担割合、秘密保持、成果物の権利の扱いなどを取り決めます。責任も一方向ではなく、お互いが自分の担当範囲について義務を負う形になります。誰か一社に完成責任を丸ごと預ける受託開発とは、責任の持ち方が根本的に違います。
この違いは、うまくいかなかったときにはっきり表れます。受託開発なら「完成させて」と開発会社に求められますが、共同開発では「どちらの担当範囲の問題か」「役割分担のどこがずれたのか」を両社で切り分けることになります。責任の所在が共有されているぶん、契約書で役割と責任の線引きを丁寧に決めておかないと、トラブル時に押し付け合いになりやすいのが共同開発の難しさです。
費用負担と成果物の権利（知的財産権）の違い
発注者にとって一番大きな違いが、この費用と権利の部分です。受託開発では、開発費は発注者が全額負担します。そのかわり、完成した成果物やソースコードの権利（著作権などの知的財産権）は、契約で発注者に譲渡してもらうのが一般的です。お金を出した自社が、できあがったシステムを自由に使い、改修し、必要なら他社にも展開できる。費用と引き換えに権利をまるごと自社に集められるのが受託開発の特徴です。
共同開発では、費用は両社で分担するのが原則です。ただし実務上は「開発費はこちらが多めに出すが、相手はノウハウやデータを提供する」といった、お金以外の貢献も含めた分担になることが多く、線引きは交渉次第です。そして最も注意したいのが成果物の権利で、共同で生み出したものの知的財産権は両社の共有になりやすいという点です。共有になると、その成果物を自社だけの判断で他社にライセンスしたり、事業として売り出したりする際に、相手の同意が必要になる場合があります。「一緒に作ったのだから権利も一緒」という前提を軽く見ていると、後から自社の事業展開が縛られることになりかねません。
主な違いを整理すると、次のようになります。
| 観点 | 受託開発 | 共同開発 |
|---|---|---|
| 両社の関係 | 頼む側と請け負う側（縦の関係） | 対等な当事者同士（横の関係） |
| 主な契約形態 | 請負契約が中心（準委任もあり） | 共同開発契約 |
| 完成責任 | 開発会社が負う | 両社が担当範囲について負う |
| 費用負担 | 発注者が全額負担 | 両社で分担（交渉次第） |
| 成果物の権利 | 契約で発注者に集められる | 両社の共有になりやすい |
| 向く場面 | 要件が固まった開発 | 相手の資産が不可欠な新規事業 |
この表のとおり、受託開発と共同開発は「安い・高い」で選ぶものではなく、お金の出し方も権利の持ち方も違う別の頼み方です。特に権利の扱いは後から変更しづらいので、契約前に自社がどこまで成果物を自由に使いたいのかをはっきりさせておくことが欠かせません。
受託開発と共同開発の違いで頼み方を選ぶ
違いが整理できたら、次は自社の案件がどちらに向くかです。判断のポイントは、作りたいものの要件がどこまで固まっているか、そして相手の技術やデータがなければ成り立たない事業なのか、の二つです。ここを見ると、受託開発と共同開発のどちらで頼むべきかの見当がついてきます。
受託開発が向くケース
作りたいものがはっきりしていて、要件を仕様として書き出せる案件は、受託開発が向きます。既存の業務をシステム化する、決まった機能の業務システムを作る、といったゴールが見えている開発です。完成の姿を定義できるからこそ、開発会社に完成責任を持たせられ、総額も固定しやすく、社内の予算承認も取りやすくなります。
もう一つ、受託開発を選ぶ強い理由が「成果物を自社のものにしたい」という点です。開発費を全額負担するかわりに、契約でソースコードや権利を自社に譲渡してもらえば、あとから自由に改修も横展開もできます。作ったシステムを自社の資産として囲い込みたいなら、権利を集めやすい受託開発が素直な選択です。外注と内製で迷う段階の方は、受託開発と自社開発の違いを解説した記事もあわせて読むと、頼み方全体の見取り図がつかめます。
私の感覚では、多くの企業がまず検討すべきは受託開発です。関係がシンプルで責任の所在も明確、権利も自社に集められるため、発注者にとって守られやすい形だからです。共同開発は、あえてその枠を外してでも組みたい相手がいる場合の、一段特殊な選択肢だと考えておくとよいでしょう。
共同開発が向くケース
共同開発が向くのは、相手の技術・ノウハウ・データ・販路といった資産がなければ、その事業そのものが成り立たない場合です。たとえば、特定業界の深い知見を持つ事業会社と、その知見を活かしたサービスを作りたいIT企業が組む、といったケースです。単に「作ってもらう」のではなく、相手も当事者として本気で関わってほしい。そのためにリスクと成果を分け合う、というときに共同開発は力を発揮します。
新規事業やPoC（試作・検証）のように、作りながら中身を詰めていく案件も共同開発と相性がよい場面があります。完成物を先に定義しきれないため、両社で仮説を出し合い、試して直してを繰り返す。こうした進め方では、一方に完成責任を丸投げする受託開発よりも、一緒に走る共同開発のほうが動きやすいことがあります。長期的に一緒にプロダクトを育て、そこから生まれる価値を分け合っていきたい、という関係を目指す場合の選択肢です。
ただし共同開発を選ぶなら、相手が対等な当事者として時間とお金を出す覚悟があるかを見極める必要があります。相手にとってのメリットが薄いと、途中で熱量が下がって開発が止まる、というのは共同開発でよく起きるつまずきです。だからこそ、パートナーとして本当に組む価値がある相手かどうかの見極めが、通常の発注以上に重要になります。
共同開発でよくある落とし穴と「実態は受託」の見抜き方
共同開発には、発注者が見落としやすい落とし穴があります。第一に、成果物の知的財産権が共有になり、自社だけの判断で事業展開できなくなること。自社が主導で売りたいサービスなら、権利の帰属や、相手の同意なしにどこまで使えるかを、契約書で必ず詰めておく必要があります。第二に、責任の所在が曖昧になりやすいこと。役割分担の線引きが甘いと、不具合や遅延が起きたときに「どちらの担当か」で揉めます。
そして最も注意したいのが、名目は「共同開発」でも、実態は受託開発というパターンです。費用はほぼ全額こちらが負担し、相手は言われたものを作っているだけ。それなのに契約は共同開発になっていて、成果物の権利は共有――これは発注者にとって不利な組み合わせです。全額お金を出しているなら、本来は受託開発として権利を自社に集められたはずが、共同開発の名のもとに権利を分け合わされている状態だからです。
見抜くための問いはシンプルです。「相手は当事者としてお金や技術を出しているか」「うまくいかなかったとき、相手も損をする立場か」。この答えがどちらもノーなら、それは共同開発ではなく受託開発として結ぶべき案件かもしれません。契約の名前ではなく、お金の流れと権利の行き先で実態を判断してください。権利や責任の詰め方は、受託開発の契約で発注者が確認すべきことをまとめた記事も参考になります。頼み方を決める前に、依頼先ごとの条件を並べて比べたいときは、ベンダー選定比較表テンプレート（10カテゴリ100項目）で、費用・権利・体制の前提を同じ物差しで点検しておくと判断がぶれません。
よくある質問
- Q. 共同開発なら開発費を安く抑えられますか？
- A. 必ずしもそうではありません。共同開発は費用を分担できる可能性がある一方で、成果物の権利が共有になり、自社だけで自由に使えなくなる場合があります。目先の費用だけでなく、権利や事業展開の自由度まで含めて判断することをおすすめします。
- Q. 共同開発で作ったシステムは自社だけで使えますか？
- A. 契約次第です。知的財産権が両社の共有になっている場合、他社への提供や事業展開に相手の同意が必要になることがあります。自社主導で使いたいなら、権利の帰属や利用範囲を契約書で明確にしておく必要があります。
- Q. 途中で受託開発から共同開発に切り替えられますか？
- A. 双方が合意すれば可能ですが、費用負担や権利の帰属が大きく変わるため、契約を結び直す必要があります。特に、すでに開発が進んでいる場合は、それまでの成果物の権利をどう扱うかで揉めやすいので、慎重に取り決めてください。
