権利の話は、揉めてから読むと遅い書類です。契約前の穏やかな段階で、一つずつ確かめておく価値があります。
1. なぜ契約前に確認するのか
ソースコードの権利は、日常の開発ではほとんど意識されません。問題として表に出るのは、資金調達の審査、事業の譲渡、開発会社の変更といった局面です。そのときになって契約書を読み、「権利が移っていない」と分かっても、遡って直すには相手の同意が要ります。相手にとって不利な変更であれば、応じてもらえないこともあります。契約前であれば、条項の追加や修正を落ち着いて相談できます。この資料は、その打ち合わせの場で開くための一覧です。
- 資金調達では、成果物の権利関係が確認の対象になることがある
- 開発会社を変えるとき、権利の所在が移行の可否と費用に影響する
- 事業の譲渡や合併では、権利の整理が前提条件になりやすい
- 確認は契約前のほうが、後からの交渉より進めやすい
2. 契約書で見る条項
契約書の中で権利に関係する条項は、一箇所にまとまっておらず、いくつかに分かれて書かれていることが多いものです。表題だけを見て判断せず、実際の文言を読んでください。特に、著作権を開発会社側に留保すると書かれている場合や、「本件成果物」の定義が納品物の一部に限られている場合は、意図した範囲が自社に移らないことがあります。以下は、確認すべき条項とその見方の一覧です。
3. 権利が移る時期を確かめる
権利の帰属が定められていても、実際に移る時期が代金の完済時とされている契約は一般的です。分割で支払う場合、最後の支払いが終わるまで権利は移らないことになります。これ自体は不当な取り決めではありませんが、その期間中に開発を中断したくなったときや、開発会社を変えたくなったときにどうなるかを、あらかじめ想像しておく価値があります。想定が難しければ、その場合の扱いを条項として書き加えられないか相談してみてください。
- 権利が移るのは、納品時か、検収完了時か、代金完済時か
- 分割払いの場合、途中で契約を終えたときの成果物の扱いはどうなるか
- 検収が長引いた場合に、権利の移転も遅れる構造になっていないか
- 契約を中途で解除したときに、それまでの成果物を自社が使えるか
4. 移らない部分を把握する
すべての権利が自社に移るとは限りませんし、そうする必要もありません。開発会社が従来から持っている汎用的な仕組みや、広く使われている公開された部品は、権利が移らないまま利用を許諾される形が一般的です。問題になるのは、その範囲が分からないことです。移らない部分がどこで、それをどういう条件で使い続けられるのかを、一覧にしてもらってください。契約が終わった後も使い続けられるかどうかが、特に重要な点です。
- 開発会社が従来から持っている汎用の仕組みが使われているか
- 第三者の部品やテンプレートの一覧と、それぞれの利用条件
- 利用の許諾が、期間や用途で制限されていないか
- 開発会社との契約が終わった後も、引き続き使い続けられるか
- 商用利用・改変・再配布に制限がないか
5. リポジトリの置き場所と権限
権利が契約上は自社にあっても、ソースコードの置き場所が開発会社のアカウントのままであれば、実際には自由に扱えません。最初から自社名義のアカウントを用意し、そこに開発会社のメンバーを招く形にしておくと、契約終了時の移管作業がほぼ不要になります。小規模な利用であれば費用も大きくありません。あわせて、本番の設定値や鍵をコードと同じ場所に置かない運用になっているかも確認してください。
- リポジトリを置くサービスの契約名義が自社になっているか
- 自社の管理者が、権限の付与と削除を自分でできるか
- 開発会社のメンバーの権限を、契約終了時に自社側で外せるか
- 変更の履歴が残る形で運用されているか
- 本番の設定値や鍵が、コードと同じ場所に置かれていないか
6. コード以外の成果物
権利の議論はソースコードに集まりがちですが、実務で困るのはそれ以外の部分であることも少なくありません。デザインの編集可能な元データがなければ、後から画像を一つ差し替えるだけでも手間と費用がかかります。ロゴやイラスト、写真、有償のフォントについては、制作者や提供元との間で別の条件が定められていることがあるため、それぞれ個別に確認してください。ライセンスの契約名義が誰になっているかも合わせて見ておきます。
- デザインの元データ(編集可能な形式)を受け取れるか
- ロゴ・イラスト・写真の利用条件(用途や媒体の制限がないか)
- 有償のフォントや素材を使っている場合、ライセンスの名義は誰か
- 設計資料・仕様書・手順書の権利と、受け取る形式
- ドメイン・サーバー・外部サービスの契約名義
7. 秘密保持と実績公開の扱い
権利と並んで確認しておきたいのが、情報の扱いです。開発の過程では、事業計画や顧客に関する情報が相手に渡ります。その保護の範囲と期間、契約終了後も義務が続くかどうかを確認してください。あわせて、相手が自社の名前やサービス名を実績として公開してよいかを決めておきます。公開の可否は事業の段階によって判断が変わるため、契約時に一律で許諾するのではなく、その都度の書面確認とするのが安全です。
- 秘密保持の対象・期間・契約終了後の扱い
- 開発会社が再委託する場合、同等の義務が及ぶか
- 自社の社名やサービス名を実績として公開する場合の手続き(事前の書面確認とするか)
- 契約終了時に、自社から渡した資料やデータの返還・削除を求められるか
8. 打ち合わせで聞く形にする
契約書を読んで疑問が出たときは、条項の修正をいきなり求める前に、まずその意図を聞いてみてください。定型の雛形をそのまま使っているだけで、相談すれば調整できることも少なくありません。以下は、そのまま口に出せる形にした質問です。回答は口頭で終わらせず書面でもらい、最終的に契約書の文言として反映されているかまで確認してください。ここまで進めば、権利に関する確認はおおむね済んだと言えます。
- 成果物の権利は、いつ、どの範囲で当社に移りますか
- 当社に移らない部分はどこですか。一覧をいただけますか
- リポジトリを当社名義のアカウントに置く形にできますか
- 契約が途中で終わった場合、それまでの成果物を当社は使えますか
- 将来、別の会社へ引き継ぐ場合、どのような協力をいただけますか
9. ご注意
本資料は一般的な情報を整理したものであり、特定の契約についての法的な助言ではありません。契約条項の解釈や権利の帰属は、契約全体の文言と当事者の間の個別の事情によって結論が変わります。第三者の部品の利用条件についても、提供元ごとに定めが異なります。実際の契約の締結・変更にあたっては、弁護士など専門家にご確認ください。
関連するインサイト
- アジャイル開発と契約 — 準委任で進める場合の合意事項アジャイル開発と請負契約の相性、準委任契約で進める理由、目的とスコープ・体制・検収・変更・知的財産権・中途終了など事前に合意すべき事項と発注側の責務を、発注者の視点で整理します。
- 開発パートナーの選び方|4つの選択肢の違いスタートアップがプロダクト開発の依頼先を選ぶときの判断軸を整理します。大手SIer、Web制作会社、フリーランス、小規模開発会社、内製の向き不向きを資金調達フェーズと速度の観点で比較し、契約前に確認したい質問と、内製化への移行の考え方を解説します。
- 開発の内製化ロードマップ — 外注から自社チームへ移行する手順外注に頼っていた開発を自社チームへ移す手順を、現状の棚卸し、最初に内製化する領域の選定、採用と技術顧問の活用、コードとドキュメントの引き継ぎ、並走期間、移行後の外部パートナーの使い方まで段階的に解説します。
関連するサービス
監修: フィリット・コンサルティング株式会社公開