先代が契約した基幹システムのベンダーから、ある日「御社にはソースコードの権利はありません」と言われたら、あなたはどう答えるだろうか。
答えられない社長は多い。株式の承継なら株主総会議事録があり、登記の承継なら登記簿謄本がある。だがシステムの承継には、それに相当する「確認すべき一枚」が何なのか、誰も教えてくれない。先代は口約束と信頼関係でベンダーと付き合ってきた。契約書は総務の棚の奥か、先代の自宅の書斎に眠っている。二代目・三代目の社長が最初にぶつかる壁は、まさにここにある。
結論を先に書く。ソースコードの権利が誰にあるかは、契約書の著作権条項と、実際に手元にある「納品物」の中身を照らし合わせなければ確定しない。多くの中小企業では、システム開発を請負契約で発注しており、日本の著作権法では、契約に特別な定めがない限り、著作物を作った側（受託したベンダー）に著作権が原始的に発生する。つまり、何も定めていなければ「お金を払って作らせたのに、権利は向こう」という事態が普通に起こる。この記事では、先代が結んだ契約の中身をどう確認し、納品物のどこを見れば実態がわかるのかを、承継したばかりの社長の目線で順番に解説する。
こんな状態の方に向けて書いている。先代が引退し、基幹システムや業務ソフトを開発した会社との付き合いを引き継いだが、契約書がどこにあるか把握していない。古参の経理担当や工場長は「昔からその会社にお願いしている」としか知らず、契約の詳細までは答えられない。ベンダーの担当者も代替わりしていて、当時の経緯を知る人がもう社内にいない。そんな状況で、システムを乗り換えたり改修したりしようとした瞬間に、「ソースコードは渡せない」「著作権はうちにある」と言われて動きが止まる——という状況を想定している。
なぜ「ソースコードの権利」が承継後に急に問題になるのか
先代の時代は、この問題が表面化しなかった。同じベンダーに保守も改修も任せ続けていたからだ。権利が誰にあろうと、実務上は困らない。ところが二代目・三代目が代替わりし、コスト見直しや新しいベンダーへの切り替えを検討し始めた瞬間、この問題が一気に牙をむく。乗り換え先のベンダーに現行システムを見てもらおうとしたら、旧ベンダーが「ソースコードの開示はできません、著作権は当社にあります」と言ってくる。改修すら「著作権者の許諾が必要」と言われて身動きが取れなくなる。株や不動産の承継とは違い、システムの権利関係は普段誰も気にしないまま何年も放置されるという特性があるため、承継のタイミングで初めて発覚することが多い。
前提知識：著作権は「作った人」に発生する
まず基本を押さえておきたい。日本の著作権法では、プログラムを含むソフトウェアも著作物として保護され、著作権はそれを創作した者に原始的に帰属する。これは開発を外部に発注した場合も変わらない。委託者（発注側の会社）が開発費を全額払っていても、契約書に著作権の帰属について特に取り決めがなければ、著作権は制作した受託者（ベンダー）側に残るのが原則だ。
これは車を買うときの感覚とは大きく異なる。車を買えば所有権は当然買い手に移る。しかしソフトウェア開発は「モノを買う」のではなく「作ってもらう」契約であり、著作権という別の権利体系が絡んでくる。先代が「お金を払ったんだから、うちのシステムだ」という感覚で契約していたとしても、法律上はそう単純ではない。
ソフトウェア開発委託契約（請負契約）で作成したソースコードの著作権は委託者と受託者のどちらにあるかは、契約書等で特に諸権利について定めのない場合に問題となる。契約では、納品物に関する著作権について、従前から保有していた著作物や汎用的な利用が可能なプログラムの著作権を除き、委託料が完済されたときに受注者から発注者へ著作権を移転する等の規定が置かれることがある。
この「特に定めがない場合」に揉めるという構図こそが、承継後に噴き出す典型パターンだ（エンタープライズジン「ソフトウェアの著作権は誰のものか」）。
確認すべきは「契約書」と「納品物」の2つ
権利関係を確認するには、大きく2つの現物を突き合わせる必要がある。
- 契約書・注文書・仕様書などの契約関連文書 — 著作権の帰属条項がどう書かれているか
- 納品物そのもの — ソースコード、設計書、マニュアルなどが実際に会社の手元にあるか
契約書に「著作権は発注者に譲渡する」と書かれていても、納品物としてソースコードが手元になければ、権利があっても使う手段がない。逆に納品物としてソースコードのファイルが手元にあっても、契約書で著作権がベンダー側に残ると定められていれば、無断で改変したり別のベンダーに渡して改修させたりすることは著作権侵害になりうる。この2つは別の問題であり、両方を確認しないと実態は見えてこない。
ステップ1：契約書そのものを探し出す
まずやるべきことは単純だが、地味に時間がかかる。契約書の現物を見つけることだ。
先代の会社では、システム関連の契約書が次のような場所に散らばっていることが多い。
- 総務・経理部門のファイルキャビネット（「契約書」「業務委託」などのラベル）
- 先代の個人オフィスや自宅の書斎（重要書類として手元に置いていたケース）
- 顧問税理士・顧問弁護士に保管を依頼していたケース
- ベンダー側にしか原本がなく、自社にはコピーすら残っていないケース
最後のパターンが最も厄介だが、実際に少なくない。契約書が見つかったら、以下の書類が揃っているかを確認する。
- 基本契約書（取引の基本条件を定めるもの）
- 個別契約書・注文書・注文請書（個々の開発案件の内容・金額・期間を定めるもの）
- 仕様書・要件定義書（何を作らせたかの範囲を示すもの）
- 検収書・納品書（何が実際に納品され、検収が完了したかを示すもの）
基本契約だけがあって個別契約が見当たらない、あるいは注文書だけで基本契約が存在しないというケースもよくある。中小企業のシステム開発では、口頭でのやり取りと簡易な発注書だけで進んでしまっていることが少なくないため、まず「何が現存するか」を棚上げせずに全部並べてみることが最初の一歩になる。
ステップ2：著作権条項を探して読む
契約書が見つかったら、著作権に関する条項を探す。多くの場合「知的財産権」「著作権の帰属」「権利の帰属」といった見出しの条文がある。よくある記載パターンは次の3つに大別できる。
| パターン | 記載内容の例 | 実務上の意味 |
|---|---|---|
| 発注者帰属 | 「本件業務によって生じた著作物の著作権は、委託料の完済をもって甲（発注者）に移転する」 | 発注側の会社に著作権がある。乗り換え・改修は原則自由 |
| 受託者帰属 | 「本件成果物の著作権は乙（受託者）に帰属する。甲は本件成果物を目的の範囲内で利用できる」 | ベンダー側に著作権が残る。利用範囲を超えた改変・転用は制限される |
| 記載なし・不明確 | 著作権に関する条文自体が存在しない、あるいは曖昧な表現のみ | 原則としてベンダー側（作成者）に権利が残ると解釈されやすい |
経済産業省が公表している「情報システム・モデル取引・契約書」でも、納入物の著作権について「甲又は第三者が従前から保有していた著作物の著作権を除き、乙（受託者）に帰属する」という案と、発注者に移転する案の双方が紹介されており、どちらが正解ということではなく、契約当事者間の合意によって決まる事項だという位置づけになっている（経済産業省「情報システム・モデル取引・契約書」）。つまり先代の契約が「受託者帰属」になっていたとしても、それ自体が不当というわけではない。当時それで合意していたという事実がある、というだけのことだ。
ここで見落としやすいのが「委託料の完済をもって」という条件だ。分割払いや保守費と開発費が一体になった契約では、著作権移転の条件が満たされているかどうかが不明確なまま何年も経過していることがある。契約書に移転条件が書かれている場合は、その条件が実際に成立しているかも確認しておきたい。
ステップ3：「利用許諾の範囲」の記載を見る
著作権がベンダー側に残る条項になっていたとしても、それだけで即「使えない」とは限らない。多くの契約では、著作権はベンダーに残しつつ、発注者には「本件業務の目的の範囲内で利用する権利」を許諾する形が取られる。ここで重要なのは、その利用許諾の範囲がどこまでかという点だ。
- 「甲は本件成果物を自社の業務のために使用できる」→ 自社利用は問題ないが、他社への譲渡や改修依頼への流用は範囲外になりうる
- 「甲は本件成果物を改変・改修することができる」という条文があれば、他のベンダーに改修を依頼する余地が出てくる
- 改変を禁止する条文（同一性保持権に関する言及）があれば、ソースコードの改修自体がベンダーの許諾なしにはできない可能性がある
日本の著作権法では、著作物を翻案（改変）する権利は原作者に専属する権利として定められており、著作権を譲り受けた側であっても、契約書に翻案権が含まれる旨を明記していなければ、この権利は譲渡した側（作成者）に残ると解釈される。つまり「著作権を譲渡する」という条文だけでは不十分で、改変・改修まで許諾する条文が別途必要になる場合がある。ベンダーロックインという状態は、著作権がベンダー側に残り、かつ利用許諾の範囲が「自社利用のみ」に限定されている契約でとくに発生しやすい。先代の代からこの構造で契約していた場合、乗り換えを検討する際にまず突破すべき壁がここになる。
ステップ4：納品物の現物を確認する
契約書の条項を確認したら、次は現物、つまり実際に何が納品されているかを見る。ここで多くの中小企業が直面するのが「そもそもソースコードが手元にない」という事実だ。
契約書で著作権が発注者に帰属すると定められていても、ソースコードそのものが納品されておらず、実行ファイル（コンパイル済みのプログラム）しか渡されていないケースは珍しくない。この場合、権利があっても中身を見ることも改修することもできない。逆に言えば、権利の帰属条項と納品物の実態は別問題であり、両方が揃っていて初めて「使える」状態になる。
確認すべき納品物の一覧はおおむね次の通りだ。
- ソースコード一式（プログラムの原本ファイル）
- データベースの設計書・定義書
- 開発に使ったツール・フレームワークのバージョン情報
- インフラ構成図・サーバーの設定情報
- 運用マニュアル・保守手順書
- 検収書（何を検収したかの記録）
弁護士法人によるシステム開発委託契約の解説では、ベンダーにソースコードの提供義務があるかどうかが契約書上明記されていない場合、後になって発注者側がソースコードの引渡しを求めても、ベンダー側が応じる法的義務がないと判断されるケースがあると指摘されている（IT法務.COM「ソフトウェア開発委託契約におけるベンダのソースコード提供義務」）。
この指摘は承継後の乗り換え交渉で実際に効いてくる。契約書に「ソースコードを納品する」と明記されていなければ、たとえ発注者側に著作権があっても、ベンダーの手元にソースコードがあるだけで、それを引き渡す義務までは契約上発生していない、という解釈になりうる。システム管理台帳を整備し、どのシステムについてソースコード一式が現物として手元にあるかを一覧化しておくことは、権利関係の確認と並行して進めておくべき作業になる。
ステップ5：検収書・議事録など「補足資料」も見る
契約書と納品物だけでなく、開発当時の検収書やメール、議事録が残っていれば、それも確認材料になる。とくに次のような記録は重要だ。
- 検収書に「ソースコード一式」と明記されているか
- 追加開発・カスタマイズを依頼した際の注文書に、著作権に関する追記があるか
- ベンダーとのメールに「ソースコードは追加費用で提供可能」といった言及がないか
先代の時代の担当者が退職していても、当時のメールやFAXの控えが社内に残っていることがある。地味な作業だが、こうした補足資料が契約書の空白を埋める手がかりになることは意外と多い。
パッケージソフト・SaaSは「著作権」ではなく「利用許諾」の話になる
ここまではオーダーメイドで開発してもらったシステム（受託開発）を前提に書いてきた。一方で、先代が導入したシステムが市販のパッケージソフトやオンプレミス型の業務ソフトである場合、話は少し変わる。この場合、著作権はそもそもソフトウェアメーカー側にあり、発注者（自社）が持っているのは「利用許諾（ライセンス）」にすぎない。
パッケージソフトの場合に確認すべきは、著作権条項ではなく利用許諾契約書（ライセンス契約書）だ。ライセンスが「買い切り型」なのか「サブスクリプション型」なのか、ライセンス数の上限、契約の自動更新条項、解約時のデータ持ち出し可否などを確認する必要がある。ここは受託開発の著作権問題とは別の論点になるため、まず自社のシステムが「受託開発（オーダーメイド）」か「パッケージ・SaaS導入」かを最初に見極めておくことが確認作業の出発点になる。
契約書が見つからない・不明確な場合の対処
契約書そのものが見つからない、あるいは条文が曖昧で判断がつかない場合、いきなりベンダーに強い態度で確認を求める前に、次の順番で進めるのが穏当だ。
- まず自社内で現存する資料を全部集める（契約書のコピー、注文書、検収書、当時のメール）
- ベンダーに対して、契約関連文書の写しを事務的に依頼する（「代替わりに伴い、契約内容を確認させてください」という趣旨で、感情的にならずに）
- 回答が得られない、または食い違いがある場合は、弁護士など専門家に契約書の解釈を相談する
ここで重要なのは、先代の代から付き合いのあるベンダーに対して、いきなり「権利をよこせ」という態度で臨まないことだ。多くのベンダーは、著作権を主張すること自体が目的ではなく、契約時点でのビジネス上の理由（保守契約を継続してもらうため、他社への流出を防ぐため等）でその条項を入れている。承継したばかりの社長が確認したいのは「今後どういう選択肢があるか」であって、対立をあおる必要はない。事務的な確認依頼として進めるほうが、その後の関係整理もスムーズになる。
なお、下請代金支払遅延等防止法（下請法）の対象となる取引であれば、中小企業庁と経済産業省が策定した「情報サービス・ソフトウェア産業における下請適正取引等の推進のためのガイドライン」も参考になる。多重かつ不透明な下請関係が生じやすいこの業界の実態を踏まえ、取引条件の明確化を促す内容になっており、自社が受注側（下請側）として関わっていた過去の契約を見直す際にも視点として使える（中小企業庁「受託適正取引等推進のためのガイドライン」）。
「株や登記には専門家がいるが、システムには相談先がいない」という孤独
事業承継の実務では、株式の承継には税理士や公認会計士が、登記の承継には司法書士が、事業計画には中小企業診断士や金融機関が、それぞれ専門家として付いてくれる。ところが基幹システムやソフトウェアの権利関係になると、相談できる専門家の窓口がはっきりしない。弁護士に相談すればいいと分かっていても、「契約書の何を確認すればいいのか」が分からなければ相談の入り口にすら立てない。
この記事で挙げたステップは、専門家に相談する前に、社長自身が最低限やっておける「棚卸し」の範囲だ。契約書を探し、著作権条項を読み、納品物の現物を確認する——ここまでを自分でやっておけば、弁護士に相談する際も「この条項の解釈だけ教えてほしい」という具体的な質問ができるようになる。逆に、何も確認せずに相談すると、契約書を探すところから何ヶ月もかかってしまうことがある。
確認が終わったら：3つの選択肢が見えてくる
契約書と納品物の確認が終わると、おおむね次の3パターンのどこに自社が当てはまるかが見えてくる。
- 著作権が自社にあり、ソースコードも手元にある → 乗り換え・改修は自社の判断で自由に進められる。ただしデータポータビリティの観点で、実際にデータを別システムへ移せる形式になっているかは別途確認が必要
- 著作権はベンダーにあるが、利用許諾の範囲が広い → 改修や別ベンダーとの並行発注の余地がある。ベンダーとの協議で利用範囲を明確にする交渉から始める
- 著作権もソースコードも実質的にベンダー側にある → 今のベンダーとの関係整理が最優先事項になる。契約更新のタイミングで条件を見直す、あるいはシステムの刷新に合わせて契約内容そのものを再交渉する。具体的な乗り換えの判断フローは開発会社の乗り換え判断フロー、承継後いつ・どの手順で切り替えるかで整理している
いずれのパターンでも、「今すぐ全部を変える」ことを急ぐ必要はない。まず現状を正確に把握し、次の契約更新や保守契約の見直しのタイミングに向けて、選べる選択肢を増やしておくことが、承継したばかりの社長にとって現実的な進め方になる。
古参社員は「昔からの付き合い」しか知らないという前提で聞く
契約書の現物確認と並行して、社内の古参社員への聞き取りも欠かせない作業になる。ただし、ここで注意したいのは、古参の経理担当や工場長が「著作権」や「ソースコード」という言葉の意味を正確に理解しているとは限らないという点だ。多くの場合、彼らが知っているのは「先代の代からこの会社に頼んでいる」という取引の歴史であって、契約条件の詳細までは把握していない。
聞き取りの際は、「著作権はどうなっていますか」という抽象的な聞き方ではなく、「システムを作ってもらったときの契約書や見積書は、どこに保管されていますか」「担当者が変わったときに、引き継ぎの書類はありましたか」といった、具体的でイメージしやすい質問に落とし込むほうが、実のある情報が出てくることが多い。先代自身が存命で相談できる場合は、記憶が鮮明なうちに一度、当時の経緯を聞いておく価値もある。
親族内承継なら契約自体は基本的にそのまま引き継がれる
ここで一つ整理しておきたいのが、代替わりの方法によって契約の扱いが変わるという点だ。親から子への親族内承継で、株式を承継する形（先代が持っていた株式を相続や譲渡で引き継ぐ形）であれば、会社という法人格そのものは変わらない。ベンダーとの契約は会社（法人）と結ばれているのが通常なので、代表者が先代から自分に変わっても、契約そのものは当然に存続する。契約書を結び直す必要は基本的にない。
一方で、事業の一部だけを会社分割や事業譲渡の形で引き継いだ場合は話が違う。この場合、契約上の地位を移転するには、原則として契約相手（ベンダー）の承諾が必要になる。もし自分の会社の承継が、株式承継ではなく事業譲渡や会社分割を伴う形で行われているなら、システム関連の契約についても「相手の承諾なしに契約上の地位が移っていないか」を確認する必要がある（マストリー「地位承継とは？事業譲渡で知っておくべき契約上の地位の承継」）。
多くの中小企業の親族内承継は株式承継の形をとるため、この論点が直接問題になることは少ない。しかし、事業の一部門だけを分社化して承継した、あるいはホールディングス化の過程で契約関係が動いている場合は、念のため確認しておいたほうがよい。ライセンス契約の名義変更については先代の代からのライセンス契約、名義変更で困らないための確認事項も参考にしてほしい。
契約書の「甲」が誰を指しているかも見ておく
契約書を読む際、もう一つ確認しておきたい細かいポイントがある。契約の当事者（「甲」）が「株式会社◯◯」という法人名になっているか、それとも先代個人の氏名になっているかという点だ。
創業から時間が浅い会社や、個人事業から法人化した直後に結んだ契約では、契約書の当事者欄が先代個人の氏名のままになっていることがある。この場合、法人としての自社と、契約上の当事者である「先代個人」が食い違っている状態になり、法人が当然に契約上の権利義務を引き継げるかどうかがあいまいになる。とくに古い契約ほどこの食い違いが起きやすいので、契約書の冒頭にある当事者の表記を必ず確認してほしい。もし法人名ではなく個人名になっている場合は、ベンダーとの間で契約の当事者を法人に変更する手続き（覚書の締結など）を検討する価値がある。
契約更新のタイミングを逃さない
もう一つ重要なのが、契約の更新タイミングを把握しておくことだ。多くの保守契約やライセンス契約は1年ごとの自動更新になっており、更新拒絶の通知期限（多くは契約終了の1〜3ヶ月前）を過ぎると、望まなくても自動的に更新されてしまう。
先代の代から契約内容を見直したことがない場合、この自動更新の存在自体に気づいていないことが多い。契約書を確認する際は、著作権条項だけでなく、契約期間・更新条項・解約通知期限も併せて確認しておくと、権利関係の見直しと契約の見直しを同じタイミングで進めることができる。契約更新のタイミングは、ベンダーとの交渉の中で著作権条項や利用許諾範囲の見直しを申し出る、数少ない自然な機会でもある。ここを逃すと、また1年間、同じ条件での契約が続いてしまう。
ベンダーが廃業・倒産した場合のリスクも一緒に考えておく
権利関係の確認と合わせて、承継したばかりの社長に考えておいてほしいのが「先代の代から付き合っているベンダーが、将来廃業・倒産した場合にどうなるか」というリスクだ。先代が長年付き合ってきたベンダーは、多くが同じくらいの世代の経営者が営む小規模な会社であることが少なくない。ベンダー自身も代替わりの時期を迎えていたり、後継者不在で事業を畳む可能性を抱えていたりする。
契約書で著作権が自社にあり、ソースコードも手元にあるという状態であれば、ベンダーが廃業してもシステム自体は問題なく使い続けられる。しかし著作権もソースコードもベンダー側にある状態で、その会社が突然廃業してしまうと、保守・改修を頼める先がどこにもなくなり、システムがブラックボックス化したまま放置されるという最悪のパターンになりかねない。
複数のベンダーに業務を分散させておくこと自体もリスク低減策の一つになる。この体制のメリット・デメリットはマルチベンダー体制のメリット・デメリット、承継後の見直しどきで扱っている。これを防ぐための一つの方法が、契約時にソースコードの寄託（エスクロー）を取り決めておくことだ。ベンダーが存続している間はソースコードを開示しないが、ベンダーが事業を停止した場合には第三者機関や公証人役場を通じてソースコードが発注者に開示される、という仕組みを契約に組み込む方法がある。すでに先代の代の契約でこうした取り決めがないか確認し、なければ次の契約更新のタイミングで交渉材料にできる。取り決めがないまま長年の付き合いに頼っている状態は、ベンダーの高齢化・廃業リスクが年々高まっている今、承継した社長として早めに手を打っておきたい論点の一つだ。
損害賠償・免責条項もあわせて確認しておく
著作権条項を確認する作業と合わせて、契約書の損害賠償・免責に関する条項にも目を通しておくとよい。システムの不具合によって業務が止まった場合、ベンダー側の責任がどこまで及ぶのか、賠償額の上限がどう定められているかは、著作権と同じ「知的財産権」の章ではなく別の条項に書かれていることが多いため見落とされやすい。
古い契約では、賠償上限が「委託料の範囲内」など低く抑えられていることがある。これは契約当時の一般的な相場や、ベンダーの規模に応じて決められたものであり、当時としては妥当だった可能性が高い。ただし、現在の自社の事業規模やシステムへの依存度に照らして、その上限が実情に合っているかどうかは、著作権条項の確認と同じタイミングで一度見直しておく価値がある。
保守費用の請求書からも「依存度」が見えてくる
契約書と納品物の確認と並行して、毎月・毎年支払っている保守費用の請求書にも目を通しておくとよい。請求書の内訳が「保守一式」とだけ書かれている場合と、「サーバー運用監視」「バグ対応」「機能追加」など項目が分かれている場合とで、自社がそのベンダーにどこまで依存しているかの見え方が変わってくる。
内訳が不明瞭な「一式」請求が何年も続いている場合、実際にどの作業にどれだけの費用がかかっているのかを自社側で把握できていない状態にあることが多い。これは著作権やソースコードの権利とは別の論点だが、ベンダーとの関係を見直す際には合わせて確認しておきたい。具体的な内訳を尋ねること自体は失礼な要求ではなく、長年の取引を継続する上でも双方にとって有益な確認作業だ。内訳を明確にしてもらうよう依頼すること自体が、契約内容の見直しに向けた最初の対話にもなる。
先代の代からの請求書が経理担当の手元に何年分も保管されているなら、金額の推移や内訳の変化を並べて見るだけでも、契約更新のたびに何が変わってきたのか、あるいは何も見直されずに続いてきたのかが見えてくる。これも契約書そのものと同じくらい、承継したばかりの社長が最初に目を通しておく価値のある資料だ。
確認作業は一度で終わらせず、記録を残す
最後にもう一つ、実務上の助言を加えておきたい。契約書を探し出し、著作権条項を読み、納品物を確認する——この一連の作業は、一度やって終わりにするのではなく、確認した結果を簡単なメモや表として残しておくことを勧める。「どの契約書に何が書かれていたか」「ソースコードは手元にあるか」「利用許諾の範囲はどこまでか」を一覧化しておけば、次に自分が誰かにこの会社を引き継ぐときにも、同じ苦労を繰り返さずに済む。
四半期ごとにベンダーへの確認事項をどう更新していくかは四半期ごとに開発会社への確認事項をどう更新していくか、1年目の場合にまとめている。先代がこの記録を残していなかったからこそ、今の自分が契約書を探すところから始めなければならなかった。同じ状況を次の世代に引き継がないためにも、確認した内容を1枚のシートにまとめておくことは、承継したばかりの社長が今できる最も地味で、しかし最も効果の長続きする対策になる。
まとめ
先代システムのソースコードの権利は、契約書に何も書かれていなければ原則としてベンダー側に残る。これは日本の著作権法の基本ルールであり、開発費を払ったかどうかとは別の話だ。だからこそ、承継した社長がまずやるべきことは、契約書の現物を探し出し、著作権条項と利用許諾の範囲を読み、実際にソースコード一式が納品物として手元にあるかを確認するという、地味だが確実な棚卸し作業になる。株や登記のように専門家が最初から付いてくれるわけではないシステムの承継だからこそ、この最初の一歩を社長自身が押さえておくことが、その後のベンダーとの関係整理や乗り換え判断を、冷静かつ有利に進めるための土台になる。
よくある質問
Q. 契約書自体がどこにも見つからない場合、権利は誰のものになりますか。
契約書が見つからない場合でも、著作権法の原則に従えば、著作物を実際に作成した側（多くの場合はベンダー）に著作権が原始的に帰属していると解釈されるのが基本だ。ただし、口頭合意や当時のメール、注文書などから契約内容を推認できる場合もあるため、契約書がないと即座に「権利は一切ない」と結論づける前に、周辺資料を集めて弁護士に相談することをお勧めする。
Q. ソースコードが手元にあれば、著作権がなくても自由に改修していいのでしょうか。
いいえ、そうとは言えない。ソースコードのファイルが物理的に手元にあることと、それを改変する権利があることは別問題だ。著作権がベンダー側に残っている場合、契約書で認められた利用範囲を超えてソースコードを改変すると、著作権侵害（翻案権の侵害）にあたる可能性がある。改修を検討する場合は、契約書の利用許諾の範囲を必ず確認してほしい。
Q. 古参のベンダーに契約書の写しを求めたら、関係が悪化しないでしょうか。
代替わりに伴い契約内容を確認するのは、事業を引き継いだ経営者として自然な事務作業であり、それ自体で関係が悪化することは通常考えにくい。角を立てないためには、「乗り換えを前提に」という切り出し方ではなく、「承継にあたり契約内容を整理しています」という事務的な依頼として進めるのが穏当だ。あわせて保守体制の今後の方針についても、この機会に相談しておくとよい。
Q. 著作権がベンダーにある契約は、今から発注者側に変更できますか。
既存の契約を遡って変更することは、双方の合意がなければできない。ただし、保守契約の更新時や追加開発の発注時など、契約を結び直すタイミングがあれば、そのときに著作権条項の見直しを交渉することは可能だ。大きな改修や刷新を予定している場合は、契約更新の交渉材料として権利関係の見直しを提案するタイミングとして適している。
