受託開発で怖いのは、システムが完成してから「これ、うちのものじゃないんですか？」と気づくことです。実は、契約で何も決めないと、開発したシステムの著作権は作った開発会社側に残り、ソースコードも渡してもらえないことがあります。あとで改修したい、別の会社に乗り換えたいというときに、身動きが取れなくなりかねません。
この記事では、受託開発の契約で発注者が確認すべきことを、著作権の帰属・ソースコードの引き渡し・契約不適合責任という3つの観点から、発注側の目線で整理します。なお、契約は法律が絡む領域です。ここで扱うのは「発注前にチェックしておきたい観点」であって、法的な助言ではありません。実際の契約内容は、必要に応じて弁護士などの専門家に確認してください。
この記事のポイント
- 何も決めないと、著作権は開発した会社側に残るのが原則
- 著作権の帰属は、契約書に明記しないと後で揉めやすい
- 著作権を移しても、ソースコードの引き渡しは別に明記が必要
- 契約不適合責任（旧・瑕疵担保）の範囲と期間も確認する
目次
受託開発の契約で確認する著作権とソースコード
まず、発注者が一番見落としがちで、後のトラブルにつながりやすいのが「権利」まわりです。著作権の帰属と、ソースコードの引き渡しを、契約でどう決めるかを押さえます。
著作権はデフォルトで開発会社に帰属する
意外に思われるかもしれませんが、システムやソースコードの著作権は、原則として「それを作った人・会社」に帰属します。つまり、発注してお金を払っても、契約で何も決めなければ、著作権は開発会社側に残るのが基本です。「お金を出したのだから当然うちのもの」という思い込みが、後のトラブルのもとになります。
著作権が開発会社に残っていると、発注側が自由にシステムを改修したり、他社に頼んで機能追加したりする際に、開発会社の許可が必要になる場合があります。まず「放っておくと自社のものにならない」という前提を知っておくことが、契約確認の出発点です。
この原則を知らずに発注すると、「完成したシステムは当然自社の資産」と思い込んだまま運用してしまいます。多くの場合は問題が表面化しませんが、開発会社との関係が悪化したときや、別の会社に乗り換えたいときに、権利が自社にないことが初めて壁になります。トラブルが起きてからでは交渉が難しいため、契約の段階で権利を明確にしておくことが、何より重要になります。
契約で「著作権の帰属」を明記する
ではどうするか。答えはシンプルで、契約書に「著作権は発注者に帰属する（譲渡する）」と明記することです。口頭の約束や「たぶん大丈夫だろう」では不十分で、書面で明確にしておく必要があります。
ただし、開発会社にも事情があります。汎用的に使う部品（ライブラリやフレームワーク）まですべて発注側に譲渡すると、開発会社が今後の仕事で使えなくなるため、そこは開発会社に権利を残しつつ、発注側は利用できる形にする、といった調整が現実的なこともあります。「今回作ったシステム固有の部分は発注側に帰属」「汎用部品は開発会社に残すが利用許諾を受ける」といった線引きを、契約時にすり合わせておくと双方が納得しやすくなります。あわせて、著作者人格権を行使しない旨の取り決めも確認しておくと安心です。
実務では、契約書に著作権に関する条項があるか、そして誰に帰属すると書かれているかを、まず目で確認します。「別途協議する」「甲乙協議のうえ定める」といった曖昧な書き方になっている場合は要注意です。あとで協議がまとまらないと、権利の所在が宙に浮いたままになります。曖昧な条項は、締結前にはっきりした表現に直してもらうよう相談しましょう。
ソースコードの引き渡しは別途明記が必要
もう一つの落とし穴が、ソースコードの引き渡しです。実は、著作権を発注側に移す契約にしても、それだけではソースコード（プログラムの元の設計図にあたるもの）を渡してもらえるとは限りません。契約に「成果物にソースコードを含む」と明記していないと、動くものだけ納品され、中身のコードは渡されない、というケースがあり得ます。
ソースコードがないと、将来の改修や別会社への乗り換えが実質できなくなり、その開発会社に依存し続けるしかなくなります。これはベンダーロックインと呼ばれる状態で、発注側にとって大きなリスクです。契約時には「ソースコードおよび設計書を納品物に含める」ことを必ず確認しておきましょう。ベンダーロックインを避ける観点は、ベンダーロックインとは何かと発注側の対策を解説した記事もあわせて確認すると理解が深まります。
ソースコードに加えて、設計書や仕様書、環境の構築手順といったドキュメント類も、納品物に含めてもらえるかを確認しておきます。コードだけあっても、それがどう作られているかの資料がないと、別の会社が引き継いで改修するのは難しくなります。「動くものが手に入るか」ではなく「別の会社でも引き継げる状態で手に入るか」という視点で見ておくと、将来の選択肢を狭めずに済みます。
OSS・第三者の権利の扱い
多くのシステムは、オープンソースソフトウェア（OSS）や第三者のライブラリを組み合わせて作られます。これらには、それぞれ利用条件（ライセンス）があり、著作権とは別に扱いを確認しておく必要があります。
契約や補足資料に「使用したOSSとそのライセンス条件の一覧」を含めてもらうと、後で「このライブラリは商用利用に制限があった」といった問題を避けられます。発注側がすべてのライセンスを理解する必要はありませんが、「一覧を出してもらい、問題がないか開発会社に確認する」という姿勢を持っておくと安心です。専門的な部分は開発会社に説明を求め、判断に迷えば専門家に相談する、という進め方で十分です。
受託開発の契約で確認する責任範囲とトラブル回避
権利の次に確認したいのが、「うまくいかなかったときにどうなるか」です。不具合の責任や、完成をどう判断するかを契約で決めておくと、納品後のトラブルを防げます。
契約不適合責任（旧・瑕疵担保）の範囲と期間
納品されたシステムが、契約で決めた内容・品質・性能を満たしていない場合、開発会社が無償で修正などの対応をする責任があります。これは民法改正前は「瑕疵担保責任」と呼ばれていたもので、現在は「契約不適合責任」といいます。
発注側が確認すべきは、この責任をいつまで・どの範囲で追及できるかです。契約書には、不具合を通知できる期間（納品後◯か月など）や、対応の範囲が定められます。この期間が極端に短かったり、責任範囲が曖昧だったりすると、いざ不具合が出たときに「契約範囲外です」と言われかねません。何をもって「契約どおり」とするかは、次の検収基準とセットで確認しておきましょう。
注意したいのは、契約不適合責任は「契約で決めた内容」を基準に判断される点です。つまり、そもそも要件や仕様が曖昧なままだと、「これは不具合なのか、それとも仕様どおりなのか」で揉めることになります。責任を追及できるようにするためにも、何を作るかを要件として明確にし、それを契約・仕様書に落とし込んでおくことが前提になります。責任範囲の条項だけを見るのではなく、要件の明確さとセットで捉えておきましょう。
検収基準と再委託の確認
検収とは、納品物が要件どおりにできているかを発注側が確認して受け入れる工程です。この検収の基準（何を満たせば合格とするか）が契約で曖昧だと、「これで完成」と言われても発注側が判断できず、不具合の責任の線引きもあいまいになります。テスト項目や受け入れ条件を、契約や仕様書で明確にしておくことが大切です。
あわせて、再委託（下請けへの委託）の扱いも確認しておきましょう。契約した会社が実際には別の会社に開発を丸投げしていると、品質や情報管理の責任が不明確になります。「再委託する場合は事前に発注側の承認を得る」といった条項があるかを見ておくと安心です。契約でこうした点を詰めておくことは、発注後のトラブルを防ぐ最大の予防策になります。受託開発でよくある失敗と、その防ぎ方全般は、受託開発でよくある失敗パターンと対策を解説した記事で整理しています。
検収の期間も確認しておきたい項目です。納品されてから検収完了までの期間が極端に短いと、十分に動作を確認できないまま受け入れてしまい、後で見つかった不具合の対応を求めにくくなります。実際に業務で使ってみて問題がないかを確かめられるだけの検収期間を、契約で確保しておくと安心です。ここを開発会社任せにせず、自社が確認に必要な時間を見積もって交渉することが大切です。
契約前に確認すべき観点まとめ
ここまでの内容を、発注側が契約前に確認すべき観点として一覧にまとめます。契約書のドラフトを受け取ったら、次の点が明記されているかをチェックしてみてください。
- 著作権の帰属（発注側に帰属／譲渡すると明記されているか）
- ソースコード・設計書が納品物に含まれるか
- 著作者人格権を行使しない旨の取り決め
- 使用するOSS・第三者ライブラリのライセンス一覧
- 契約不適合責任の期間と範囲
- 検収の基準（合格条件・テスト範囲）
- 再委託の可否と承認ルール
これらの前提や範囲を含めて発注前に点検したい場合は、システム開発見積もりチェックシート（危険サインを見抜く60項目）も、契約・範囲の抜けを洗い出すのに役立ちます。なお、契約条項の妥当性そのものの判断は、弁護士などの専門家に確認するのが確実です。発注側の公的な参考資料としては、IPA（情報処理推進機構）の情報システム・モデル取引・契約書（第二版）が、発注者・受注者の役割分担や契約の考え方を示しています。
受託開発の契約に関するよくある質問
受託開発の契約について、発注側からよく聞かれる疑問をまとめました。
- Q. お金を払えば、著作権は自動的に自社のものになりますか？
- A. なりません。契約で「著作権を発注者に譲渡する」と明記しない限り、原則として著作権は作った開発会社側に残ります。発注側が権利を持ちたいなら、契約書での明記が必要です。
- Q. 著作権を移せば、ソースコードももらえますか？
- A. 別問題です。著作権の譲渡とソースコードの引き渡しは分けて考える必要があり、「ソースコード・設計書を納品物に含む」と契約に明記して初めて確実に受け取れます。
- Q. 契約書は開発会社が用意したものをそのまま使って大丈夫ですか？
- A. 内容を確認せずに押印するのは避けましょう。開発会社の雛形は開発会社に有利な場合もあります。著作権・ソースコード・責任範囲などの重要項目は、必要に応じて専門家に確認してから締結するのが安全です。
- Q. 契約前に、発注側は何を用意しておけばいいですか？
- A. 作りたいものの要件をできる範囲で整理し、著作権・ソースコード・責任範囲について「こうしたい」という希望を持っておくと、契約の話し合いがスムーズです。要件が曖昧なままだと、契約の重要項目も詰めきれません。
