システム開発を発注して納品を受けると、「お金を払ったのだから、成果物は自社のもの」と考えるのが自然な感覚かもしれない。しかし、プログラムやドキュメントには著作権などの権利が生じ、その権利が誰に帰属するかは、契約での取り決めによって変わることがある。ここを整理しておかないと、後でシステムを改修したいときや、別の用途に使いたいときに、思わぬ制約に直面することがある。
本記事は、システム開発で生まれる成果物の権利を、発注者の視点で整理する。読者として想定しているのは、中小企業の経営者、発注担当、管理部門である。著作権や知的財産権というと専門的に聞こえるが、「権利が誰のものになるか」「自社はどこまで使えるか」「将来どう活用したいか」という観点を持てば、確認すべき点が見えてくる。なお、権利の帰属や利用許諾の取り決めには法律上の論点が関わり、個別の判断には事情が影響するため、最終的な判断は弁護士など専門家への確認を前提としていただきたい。
結論：権利の帰属と利用範囲を発注前に確認する
成果物の権利をめぐるトラブルを避けるには、権利の扱いを発注前に確認しておくことが欠かせない。GXOが発注者にすすめるのは、次の3点である。
- 成果物の著作権などの権利が、誰に帰属するのかを契約で確認する
- 権利が開発会社に残る場合でも、自社がどこまで使えるか（利用許諾）を確認する
- 将来の改修や再利用を見据えて、必要な範囲を見積もっておく
権利の扱いは、納品後に変えるのが難しい。発注前に、自社がそのシステムを将来どう使いたいかを考え、必要な権利や利用範囲を確認しておきたい。
なぜ成果物の権利が重要か
システムは、一度作って終わりではなく、運用しながら改修を重ねていくことが多い。改修や再利用をしようとしたとき、権利の扱いが曖昧だと、自由に手を入れられなかったり、別の会社に改修を頼めなかったりすることがある。
権利の取り決めが不十分だと、次のような問題につながりやすい。
- 改修したいのに、権利の制約で別の会社に頼めない
- 作ったシステムを別の用途に使いたいが、利用範囲が曖昧で判断できない
- 開発会社が成果物を他社にも転用してよいのか分からない
成果物の権利は、システムの将来の活用に関わる土台である。契約書全体の確認観点とあわせて押さえておきたい。確認の観点は契約書で確認すべき項目も参考になる。
著作権の帰属を確認する
権利は自動的に発注者のものにはならないことがある
プログラムやドキュメントに生じる著作権は、契約で特に取り決めがない場合、作成した側に帰属することがある。費用を払ったからといって、自動的に発注者に権利が移るとは限らない。だからこそ、契約での取り決めが重要になる。
帰属のパターンを理解する
権利の帰属には、いくつかのパターンがある。どれが適しているかは、システムの性質や将来の使い方によって変わる。
| 帰属のパターン | 内容 | 向く場面 |
|---|---|---|
| 発注者に帰属 | 権利が発注者に移る | 自社で自由に改修・活用したい |
| 開発会社に帰属＋利用許諾 | 権利は開発会社、発注者は使える | 開発会社の汎用部品を含む場合 |
| 共有 | 双方で権利を持つ | 共同で作り上げた場合 |
どのパターンでも、自社がそのシステムを「どこまで使えるか」を確認することが大切である。
利用許諾と再利用・流用を整理する
利用許諾（ライセンス）の範囲
権利が開発会社に残る場合でも、発注者が使える範囲を利用許諾として定めることがある。どの範囲で使えるのか、改修してよいのか、関連会社でも使えるのかなどを確認したい。
開発会社による再利用・流用
開発会社が、作った仕組みの一部を他社の案件にも使うことがある。汎用的な部品であれば一般的なことだが、自社のために作った独自の機能まで他社に転用されるのは避けたい、というケースもある。再利用・流用の扱いを確認しておきたい。
第三者の権利が含まれる場合
成果物に、オープンソースのソフトウェアや外部のライブラリが含まれることがある。これらには、それぞれ利用上の条件がある。どんな外部のものが使われているかを把握しておくと、後のトラブルを避けやすい。たとえば、外部のソフトを組み込んだ部分について、利用条件によっては特定の表示や開示が求められることもある。発注者がすべての条件を把握する必要はないが、「どんな外部のものが、どんな条件で使われているか」を開発会社に確認し、自社の使い方と矛盾しないかを押さえておきたい。開発会社の選び方はAI開発のベンダー選定基準も参考になる。
成果物の権利でよくある失敗
成果物の権利では、次のような失敗が起きやすい。いずれも、発注前に確認しておけば避けられる。
- 権利の帰属を確認しない：払えば自社のものと思い込み、改修で制約に直面する。
- 利用範囲を曖昧にする：使える範囲が定まらず、別用途への活用で迷う。
- 再利用・流用を放置する：独自に作った機能が他社に転用される取り決めに気づかない。
- 外部のものを把握しない：含まれる外部ソフトの条件を知らず、後で対応に追われる。
権利の扱いは、将来の活用を左右する。自社がそのシステムをどう使いたいかを考え、必要な範囲を発注前に確認しておきたい。
成果物の権利のチェックリスト
権利をめぐる後悔を避けるため、発注前に次の点を確認しておきたい。将来そのシステムをどう使いたいかを思い描きながら、必要な範囲を見積もっておくとよい。
- 成果物の著作権などの権利が誰に帰属するかを契約で確認したか
- 権利が開発会社に残る場合、自社が使える範囲（利用許諾）を確認したか
- 改修してよいか、関連会社で使ってよいかを確認したか
- 開発会社が独自機能を他社に再利用・流用する扱いを確認したか
- 成果物に含まれる外部のソフトやライブラリを把握したか
- 将来の改修を別の会社に頼める状態かを確認したか
- 自社がそのシステムを将来どう使いたいかを整理したか
これらが整理されていれば、納品後に「改修したいのにできない」「別用途に使えるか分からない」といった事態を避けやすい。権利は納品後に変えるのが難しいため、発注前の確認が肝心である。
将来の活用を見据えて権利を考える
成果物の権利を考えるうえで大切なのは、目先の納品だけでなく、その先の活用まで見据えることである。システムは導入して終わりではなく、業務の変化に合わせて改修を重ねていくことが多い。そのとき、権利の扱いが自社にとって不利だと、改修を別の会社に頼めなかったり、追加の許諾が必要になったりすることがある。
一方で、すべての権利を自社に集めることが常に最善とは限らない。開発会社の汎用的な部品を活用することで、開発の費用や期間を抑えられる場合もある。その場合は、権利は開発会社に残しつつ、自社が必要な範囲で使える利用許諾を整える、という形が現実的なこともある。大切なのは、自社の使い方に必要な範囲を見極め、その範囲を契約で確保しておくことである。判断に迷う場合は、弁護士など専門家にも相談しながら決めたい。システムを将来作り替えるときの費用感は業務システム入れ替えの費用ガイドも参考になる。
関連記事
よくある質問
Q1. 費用を払えば、成果物は自動的に自社のものになりますか
費用を払っても、著作権などの権利が自動的に発注者に移るとは限らない。契約で権利の帰属を取り決めていなければ、作成した側に権利が残ることもある。自社で自由に活用したい場合は、権利の帰属を契約で確認しておくことをおすすめする。
Q2. 権利が開発会社に残ると、自社では使えないのですか
権利が開発会社に残る場合でも、利用許諾として発注者が使える範囲を定めることが一般的である。問題になりやすいのは、その範囲が曖昧なときである。改修してよいか、関連会社で使ってよいかなど、使いたい範囲を具体的に確認しておきたい。
Q3. オープンソースが含まれていると問題になりますか
オープンソースの利用自体は一般的だが、それぞれに利用上の条件がある。どんな外部のものが含まれているかを開発会社に確認し、自社の使い方が条件に合うかを把握しておきたい。判断が難しい場合は、弁護士など専門家に確認するとよい。
成果物の権利の扱いを、発注前に整理しませんか
GXOでは、システム開発の成果物について、著作権の帰属、利用許諾の範囲、再利用・流用の整理など、将来の活用を見据えた権利の確認をご支援します。専門的な法務判断は専門家と連携しながら進めます。
※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。