システム開発の契約書｜著作権の帰属で必ず決める4項目
こんにちは、合同会社SAi代表の佐藤です。
システム開発を発注するとき、多くの方が「お金を払うのだから、できたものは自社のもの」と考えます。
ところが実際は違います。契約で決めていなければ、著作権は開発した側に残ります。
数年後に「別の会社に改修を頼もうとしたら断られた」「ソースコードをもらえなかった」と気づくケースは珍しくありません。この記事では、契約書で決めておくべき4つの項目と、発注者からよく聞かれる「同じものを他社に売られないか」という不安への対処法を整理します。
※ 本記事は開発を請ける立場からの実務的な整理であり、法的な助言ではありません。重要な契約は弁護士にご確認ください。
結論：払っただけでは、自社のものになりません
著作権法では、著作物を創作した人に著作権が発生するのが原則です。プログラムも著作物なので、開発会社が書いたコードの著作権は、まず開発会社に発生します。
発注者に移すには、契約で「譲渡する」と定める必要があります。
「お金を払ったから」「発注したから」という理由だけでは移りません。ここが最初につまずくポイントです。
決めていないと、こうなります
- 別の会社に改修を頼めない … 改修には元のコードを扱う必要があり、権利がなければ手を出せない
- 同じものが他社に納品される … 権利が開発会社にあるので、法的には可能
- ソースコードを渡してもらえない … 納品義務がなければ、渡さないという選択もありうる
いずれもその開発会社と付き合い続ける限りは表面化しません。問題になるのは、担当者が辞めたとき、会社が廃業したとき、条件が合わなくなって乗り換えたいときです。
契約書で決める4つの項目
① 著作権の帰属
誰が権利を持つか。選択肢は大きく2つです。
- 譲渡を受ける … 発注者が著作権を持つ。自由に改修・転用できる
- 使用許諾にとどめる … 著作権は開発会社に残り、発注者は使う権利だけを得る
譲渡を受けるほうが安心ですが、その分の対価は費用に乗ります。開発会社にとっては、再利用できない資産になるためです。
なお譲渡の契約では、著作者人格権を行使しない旨もあわせて定めるのが一般的です。著作者人格権は譲渡できない権利なので、「行使しない」という形で処理します。
② 利用できる範囲
権利をどちらが持つにせよ、発注者が何をしてよいかを書いておきます。
- 自社で改修してよいか
- 別の会社に改修を依頼してよいか
- グループ会社や子会社でも使ってよいか
- 将来、別事業に転用してよいか
とくに2つ目が重要です。「他社に改修を依頼できるか」は、乗り換えの自由度そのものです。ここが制限されていると、実質的にその開発会社から離れられなくなります。
③ ソースコードの納品
中身を受け取れるかどうかです。権利の話とは別に、明記が必要です。
権利を譲渡されていても、コードが手元になければ改修できません。逆に、コードを持っていても権利がなければ手を加えられません。両方そろって初めて「自社のシステム」と言えます。
納品を受ける場合は、次も決めておくと確実です。
- 納品の形式（リポジトリごとか、ファイル一式か）
- 環境構築の手順書があるか
- 使用している外部サービスやライブラリの一覧
④ 汎用部品の扱い
ここは発注者側が見落としがちですが、もめる原因になりやすいところです。
開発会社は、ログイン機能や帳票出力などどの案件でも使う共通の仕組みを持っています。これを「今回作ったもの」として全部譲渡してしまうと、開発会社は自社の資産を渡すことになります。
実務では、個別に開発した部分と、もともと持っていた汎用部品を分けて考えるのが一般的です。
- 個別実装（貴社の業務に合わせて作った部分）→ 発注者に譲渡
- 汎用部品（他案件でも使う共通の仕組み）→ 開発会社に残し、使用を許諾
この線引きを契約書に書いておけば、後から揉めません。
「同じものを他社に売られないか」への対処
発注者からもっとも多く聞かれる不安がこれです。とくに自社のノウハウを組み込んだシステムの場合、当然の心配です。
対処法は2つあります。
方法1：著作権の譲渡を受ける
もっとも確実ですが、費用が上がります。また汎用部品まで含めて譲渡を求めると、開発会社側が受けられないこともあります。
方法2：対象範囲を限定した競業避止の条項を置く
権利は開発会社に残したまま、「この分野・この用途では、他社に同種のものを提供しない」と定める方法です。
ポイントは範囲を具体的に書くことです。
- ✗ 「同様のシステムを他社に提供しない」 … 範囲が広すぎて、開発会社が受けられない
- ○ 「◯◯業界向けの△△機能については、他社に提供しない」 … 対象が明確
範囲が広すぎる条項は、開発会社にとって今後の事業をすべて制限される意味になるため、まず合意されません。自社が本当に守りたいのはどの部分かを先に整理してから交渉すると、話がまとまりやすくなります。
多くの場合、守りたいのは「システム全体」ではなく「自社のノウハウが入っている部分」です。そこだけを限定すれば、開発会社も応じやすくなります。
費用とのバランス
すべてを発注者に寄せると、費用は上がります。
| 決め方 | 費用への影響 |
|---|---|
| 著作権を全部譲渡 | 上がる（開発会社が再利用できないため） |
| 個別実装のみ譲渡＋汎用部品は使用許諾 | 標準的 |
| 使用許諾のみ | 抑えられるが、乗り換えの自由度は下がる |
判断の基準はシンプルです。
将来、別の会社に改修を頼める状態にしておきたいか。
社内の基幹システムのように長く使うものなら、譲渡とソースコード納品を受けておく価値があります。一方、数年で作り替える前提の小さなツールであれば、使用許諾で足りることもあります。
発注前に確認しておくこと
- 著作権は誰に帰属するか、契約書に書かれているか
- 他社に改修を依頼できるかが明記されているか
- ソースコードの納品の有無と形式が決まっているか
- 汎用部品と個別実装の線引きがあるか
- 守りたいノウハウがある場合、その範囲が具体的に書かれているか
- 開発会社が廃業した場合に、システムを継続できる状態か
最後の項目は見落とされがちです。権利もコードも手元にない状態で相手が廃業すると、システムは事実上その時点で終わります。
よくある質問
Q. 費用を払えば、システムの著作権は自社のものになりますか？
なりません。著作権法では、著作物を創作した側に著作権が発生するのが原則です。プログラムも著作物にあたるため、開発会社が書いたコードの著作権は、まず開発会社に発生します。発注者に移すには契約書で「譲渡する」と定める必要があります。支払いの有無とは別の問題です。
Q. ソースコードは納品してもらえますか？
契約次第です。納品義務は当然には発生しません。権利を譲渡されていてもコードが手元になければ改修できないため、著作権の帰属とは別に、納品の有無と形式を明記してください。あわせて環境構築の手順書や、使用している外部サービスの一覧も受け取っておくと、後から別の会社に引き継げます。
Q. 同じシステムを競合他社に売られないか心配です。
2つの方法があります。1つは著作権の譲渡を受けること。もう1つは、権利は開発会社に残したまま「この分野・この用途では他社に提供しない」という条項を置くことです。後者の場合、範囲を具体的に書くのがコツです。「同様のシステムを提供しない」のような広い書き方は、開発会社が今後の事業を制限されるため合意されにくく、対象業界や機能を限定した表現のほうがまとまります。
Q. 開発会社が汎用部品の権利を渡さないと言っています。おかしいですか？
おかしくありません。開発会社は、ログイン機能や帳票出力など、どの案件でも使う共通の仕組みを持っています。これを譲渡すると自社の資産を失うことになるため、通常は個別実装は譲渡、汎用部品は使用許諾という形で分けます。発注者にとっても、自社システムを使い続けるうえで実害はありません。
Q. 開発会社が廃業したらシステムはどうなりますか？
著作権とソースコードが手元にあるかで決まります。両方あれば、別の会社に引き継いで改修を続けられます。どちらも無ければ、事実上その時点でシステムの寿命が決まります。長く使う予定のシステムほど、この点を契約時に確認しておくべきです。
Q. 契約書は開発会社が用意したものをそのまま使って大丈夫ですか？
本記事の4項目だけは必ず確認してください。著作権の帰属／利用できる範囲／ソースコードの納品／汎用部品の扱い。この4つが書かれていない契約書は珍しくありません。書かれていなければ、追加を依頼して問題ありません。重要な契約や金額の大きい案件では、弁護士への確認をおすすめします。
まとめ
- 費用を払っただけでは、著作権は自社のものになりません
- 契約書で決めるのは①帰属 ②利用範囲 ③ソースコードの納品 ④汎用部品の扱いの4つ
- 「他社に改修を依頼できるか」が、乗り換えの自由度を決めます
- 「他社に売られないか」の不安には、範囲を限定した条項が現実的
- すべてを寄せると費用は上がる。「自社で改修できる状態か」を基準に決める
当社では、ソースコードを納品し、個別に開発した部分の権利は発注者にお渡しする形を標準としています。開発した会社に縛られない状態でお使いいただくためです。
契約条件を含めたご相談も承っていますので、お問い合わせからお気軽にご連絡ください。料金は開発内容別の料金一覧に公開しています。
