先代の代からの開発会社に「うちでしか直せません」と言われたときに確認する契約書の項目

先代が創業した頃からシステムを任せてきた開発会社の担当者から、「うちでしか直せません」「うちじゃないと分からない仕組みになっています」と言われたことはないだろうか。見積もりを見て高いと感じても、他社に相見積もりを取ろうとしても、結局は「うちでしか直せない」の一言で押し切られてしまう。この記事を読んでいるあなたは、そういう状況に置かれている二代目・三代目の経営者かもしれない。

結論を先に述べる。「うちでしか直せません」という言葉の裏側にあるのは、契約書レベルで見れば実は単純な話で、①ソースコードを誰が持っているか、②著作権が誰に帰属しているか、③保守契約の範囲と期間がどう定められているか、この3点に尽きる。これらが発注者側（つまり会社側）に有利になっていなければ、開発会社の言い分は「事実として直せない」のではなく「契約上、他社に直させない」というだけの構造になっている可能性が高い。まずやるべきは、感情的に決別を切り出すことではなく、手元にある契約書とソースコードの現物を確認することだ。

この記事はこんな状態の人向けに書いている

• 先代の代から30年近く付き合いのある開発会社に、基幹システムの保守を任せている
• 見積もりの根拠が不透明なまま、毎年同じような保守費用を払い続けている
• 「システムのことは全部あの会社にお任せしている」状態で、契約書の中身を自分では読んだことがない
• 相見積もりを取りたいと思っても、「うちでしか直せません」と言われて動けなくなっている
• 経理や労務については税理士や社労士という相談相手がいるが、システムについては相談する相手が誰もいない

最後の一点は特に重要だと思う。株式の承継や登記の変更については、税理士や司法書士という専門家が必ずついている。ところがシステムについては、先代がその開発会社の担当者と長年の人間関係を築いてきたというだけで、承継後の社長は契約書の内容を知らないまま「窓口だけ引き継いだ」状態になっているケースが非常に多い。これは経営者個人の能力の問題ではなく、システムの契約という領域に、承継時のチェックリストが存在してこなかったことが原因だ。

なぜ「うちでしか直せません」が成立してしまうのか

まず整理しておきたいのは、「うちでしか直せません」という状況がどうして生まれるのか、という技術的・契約的な背景だ。これには大きく3つの原因がある。

1つ目はソースコードが発注者側に開示されていないことだ。契約書に特別な定めがない限り、開発会社が発注者にソースコードを開示する義務は、日本の法律上は原則として存在しない。システム開発に関して「ソースコードを引き渡さなければならない」という直接的な法規定はなく、開示するかどうかは契約内容がすべてを決める。つまり「開示してもらえていない」のは違法ではなく、契約でそう決めた（あるいは、契約で決めずに放置した）結果でしかない。

2つ目は著作権の帰属だ。ここは経営者が特に誤解しやすい部分なので、はっきり書いておく。開発費を全額支払ったとしても、納品されたソースコードの著作権は自動的に発注者側には移らない。著作権法は「創作した者に著作権が帰属する」という原則を採用しているため、実際にプログラムを書いた開発会社のエンジニアや、その会社自体に著作権が残ることが多い。契約書で著作権の譲渡が明記されていなければ、発注者は「お金を払って作らせたシステム」であっても、著作権者の許可なく改変することができない立場に置かれる。

3つ目は独自の技術・仕組みへの依存だ。ドキュメントが整備されておらず、開発会社の担当者の頭の中にしか設計思想が残っていない状態になっていると、たとえソースコードそのものは開示されていても、実質的に「読める人がその会社にしかいない」という状況が生まれる。

ベンダーロックインという言葉があるが、この3つの要因が重なって発生する状態を指す。契約で対策できるのは1つ目のソースコード開示と2つ目の著作権帰属の2つであり、3つ目のドキュメント不足は契約に加えて運用上の取り組みが必要になる。

まず確認すべき契約書の項目：ソースコードの帰属と開示

「うちでしか直せません」と言われたとき、最初に確認すべきは契約書のソースコードに関する条項だ。以下のポイントを一つずつ照らし合わせてほしい。

• 納品物としてソースコードそのものが明記されているか（「本システム一式」といった曖昧な表現だけで、ソースコードという言葉が出てこない契約書は少なくない）
• ソースコードの提供形式・提供時期が明記されているか（納品時に一度渡されるだけで、その後の改修分は渡されていないというケースは非常に多い）
• 改修・追加開発を行った差分のソースコードも都度提供される契約になっているか
• ソースコードの提供義務が保守契約側にも及んでいるか（開発時の契約書にしかソースコード条項がなく、保守契約は別の簡易な書面で処理されていることがある）

もし契約書にソースコードの提供条項が一切見当たらない場合、それは開発会社が意図的に隠しているというより、契約時にその点を誰も詰めていなかった可能性の方が高い。特に先代の時代、つまり数十年前の契約は、システム自体の重要性が今よりも低く見積もられていたため、簡易な発注書や見積書だけで済まされているケースが珍しくない。まずは「そもそも契約書という体系だったものが存在するか」を確認するところから始める必要がある場合もある。

次に確認すべき項目：著作権の帰属先

ソースコードの現物があっても、著作権が開発会社側に残っていれば、勝手に改変したり、別のベンダーに渡して保守を依頼したりすることはできない。著作権法上、著作権は創作した者（実際に開発したエンジニアやその所属企業）に原始的に帰属するのが原則であり、これを発注者に移すには契約書に明確な譲渡条項が必要になる。

確認すべき項目は次の通りだ。

• 著作権が発注者（会社側）に譲渡される旨が明記されているか、それとも開発会社に留保されているか
• 著作権が譲渡される場合、著作権法27条・28条（翻案権・二次的著作物の利用権）についても言及があるか（これらの権利は契約書に明記がないと譲渡されないと解釈される場合がある）
• 著作者人格権の不行使について合意があるか（著作者人格権は本人に一身専属する権利のため譲渡できず、改変等について後から異議を申し立てられないよう「不行使特約」を入れておく必要がある）

著作権が開発会社側に残っている契約は、一律に「悪い契約」というわけではない。パッケージ製品やクラウドサービスのカスタマイズなど、著作権を発注者に渡すこと自体が現実的でない契約形態も存在する。重要なのは、著作権がどちらにあるかを経営者自身が把握しており、それに応じた次の一手（改修の都度必ず現ベンダーを通す、あるいは移行を検討する）を判断できる状態にあるかどうかだ。

保守契約そのものの範囲と期間を確認する

開発時の契約だけでなく、現在支払っている保守契約そのものの条件も見直す必要がある。

保守契約でよく見落とされるのは「対応範囲」「対応時間」「自動更新条項」の3点だ。特に自動更新条項は、解約の申し出をしなければ同条件で自動的に1年更新されるという内容になっていることが多く、見直すタイミングを逃し続けている会社が非常に多い。

確認すべき項目を表にまとめる。

このうち最後の「解約時の引き渡し義務」が、実は最も見落とされがちで、かつ最も重要な項目だ。開発時の契約書にソースコード提供条項があっても、保守契約の解約時に何を引き渡すかが規定されていなければ、いざ乗り換えようとした時点で「保守契約はもう終わったので、資料の提供義務もありません」という水掛け論になりかねない。

経済産業省・IPAのモデル契約書を基準に照らす

自社の契約書が一般的な水準からどれだけ離れているかを判断する材料として、経済産業省とIPA（情報処理推進機構）が公表している「情報システム・モデル取引・契約書」が参考になる。これは受託開発と保守運用の双方について、ユーザー企業とITベンダーの間で担うべき責務を整理し、契約書のひな型を示したものだ。もともとは情報システムの取引構造が不透明であることへの対策として2007年に公表され、2020年には改正民法を踏まえた見直し版も出ている。

このモデル契約書には保守運用編も含まれており、対応範囲・SLA・再委託・契約終了時の引き渡しといった項目が体系的に整理されている。今の契約書と並べてみて、モデル契約書にある項目が自社の契約書にまったく存在しない場合、それは意図的に不利な契約を結ばされたわけではなく、単に「その時代、その規模の取引ではそこまで詰めていなかった」だけの可能性が高い。だからこそ、腹を立てる前に、まず現状を客観的に照らし合わせる作業が有効だ。

ソースコードエスクローという選択肢

「うちでしか直せません」と言われても、今すぐ全面的に開発会社と決別する必要はない場合も多い。関係を維持しながらリスクだけを下げる方法として、ロックイン対策の一つに「ソースコードエスクロー」という仕組みがある。

これは、ソースコードを開発会社が保有したまま、信託会社などの第三者機関に預けておき、あらかじめ定めた条件（開発会社の倒産、事業譲渡、保守契約の終了など）が成立した場合に発注者がソースコードを取り出せるようにする制度だ。開発会社にとっては普段はソースコードを手放さずに済み、発注者にとっては「もしものとき」の保険になるため、両者の利害を調整しやすい。特に、基幹業務システムのように長期利用を前提とし、かつ特定の中小開発会社への依存度が高いシステムでは、活用する価値が大きいとされている。

先代の代からの付き合いを一気に断ち切るのではなく、「関係は維持しつつ、もしその会社がなくなった時にどうするかだけを今のうちに決めておきたい」という切り出し方であれば、相手も感情的に身構えずに応じやすい。角を立てずに関係を整理したい承継社長にとっては、現実的な落とし所になりうる選択肢だ。

「うちでしか直せません」と言われたときの切り出し方

契約書の中身を確認したうえで、開発会社にどう切り出すかも重要だ。いきなり「他社に相見積もりを取ります」と伝えるのではなく、次のような順序を踏むことをすすめたい。

1. まず自社の契約書・見積書・過去のやり取りを一通り読み直し、ソースコード・著作権・保守範囲の現状を自分の言葉で把握する
2. 「事業を引き継いだので、システムの契約内容を一度確認させてほしい」という、承継を理由にした自然な切り出し方で資料開示を依頼する
3. ソースコードの提供状況、直近の改修分の差分提供状況を確認する
4. 保守契約の対応範囲・費用の算定根拠について、具体的な項目ごとに質問する
5. 関係を維持する前提で、ソースコードエスクローなどのリスク低減策を提案してみる

このプロセスは、開発会社との関係を壊すためのものではない。むしろ、先代の時代には整理されていなかった契約関係を、承継を機に一度きちんと棚上げしないままにしておくと、次に何か問題が起きたとき（開発会社の廃業、担当者の退職、システムの重大な不具合など）に会社側が丸ごとリスクを抱え込むことになる。承継のタイミングは、こうした確認を「先代への不信感の表明」ではなく「事業継続のための当然の手続き」として行える、数少ない機会でもある。

契約書が見当たらない・古すぎる場合の対処

先代の時代の契約書を探しても、簡易な見積書や発注書しか出てこない、あるいは契約書自体が見つからないというケースもある。この場合、慌てて開発会社を問い詰める前に、次の手順を踏むことを勧める。

• 現在使っているシステムの一覧と、それぞれの契約状況（契約書の有無、保守費用、契約期間）をシステム管理台帳として一枚にまとめる
• 契約書が見当たらないシステムについては、開発会社に「契約書の写しを再発行してもらえないか」と依頼する（多くの場合、先方にも保管されている）
• 口頭でのやり取りしかない場合は、現状の保守内容・対応範囲を書面（メールでもよい）で確認し直す

契約書だけでなく、ロックインを裏付ける技術的な兆候の見分け方は「うちでしか分からない」を裏付ける、先代契約のシステム仕様の確認方法でも扱っている。この作業を一度やっておくと、次に代替わりする際にも、あるいは自分がシステムについて何か判断を下す際にも、土台になる資料が残る。先代から引き継いだのがシステムの「使い方」だけで、契約の「中身」ではなかったのだとしたら、今のあなたがそれを整理して、次の世代、あるいは将来の自分自身に引き渡す番だと考えてよい。

乗り換えを検討する場合に追加で確認すべきこと

契約書の確認を終え、実際に別の開発会社への切り替えや内製化を検討する段階になった場合、追加で確認すべき点がある。

• データそのものを他システムへ移行できる形式で書き出せるか（データポータビリティが確保されているか）。独自形式でしかデータを保持していないシステムは、著作権やソースコードの問題が解決しても、データ移行という別の壁に当たることがある
• 現在のシステムが特定の業務にしか対応していない場合、複数のベンダーやサービスを組み合わせる構成に切り替えるのか、それとも一社に任せる体制を維持するのかを判断する
• システムが自社サーバーで稼働する形式なのか、クラウド型なのかによって、移行の難易度と費用が大きく変わる

これらは技術的な判断が絡むため、経営者一人で判断しきれない部分も多い。だからこそ、契約書の確認という最初の一歩を自分の手で済ませておくことが重要になる。技術的な当否は専門家やセカンドオピニオンの開発会社に相談できても、契約書に何が書いてあるかは、結局は発注者側である会社が自分の目で確認するしかない。

公正取引委員会が示した保守契約の位置づけ

参考情報として、保守契約そのものの適法性について、公正取引委員会が示した見解も紹介しておく。ソフトウェアメーカーが自社ソフトウェアの利用顧客に対して、アップグレード版の販売時に保守契約の締結を義務付けることについて、独占禁止法上直ちに問題となるものではないと回答された相談事例がある。つまり「保守契約への加入を求められること」自体は、一般的には違法でも不当でもない。問題になるのは、保守契約の内容が不透明であったり、乗り換えを実質的に不可能にするような条項（ソースコード非開示、著作権の留保、引き渡し義務の欠如）が組み合わさっている場合だ。この切り分けができていないと、「保守契約を結ばされていること自体」に不満を持ってしまい、本当に確認すべき契約条項の内容から目がそれてしまう。

レガシー化したシステムほど「うちでしか直せません」が強くなる理由

先代の代から使い続けているシステムは、多くの場合、開発から10年以上、場合によっては20年以上が経過している。こうした古いシステムは、当時の言語やフレームワークで書かれており、今の若手エンジニアが読める形では残っていないことが多い。開発会社の中でも、実際にそのシステムを保守できるのは、当時から在籍している特定の担当者一人だけ、という状態も珍しくない。

これは開発会社側にとっても実はリスクだ。その担当者が退職したり、体調を崩したりすれば、開発会社自身も「うちでも直せなくなる」可能性がある。つまり「うちでしか直せません」という言葉は、発注者を縛る目的だけでなく、開発会社自身も薄氷の上に立っていることの裏返しである場合が多い。この構造を理解しておくと、相手を「悪意のある値上げ屋」と決めつけずに、「双方にとってリスクである状態を、どう一緒に解消するか」という話し合いの土台を作りやすくなる。

古いシステムほど、次のような技術的な問題が積み重なっている可能性が高い。

• 開発言語やフレームワークのバージョンが古く、セキュリティパッチの提供が終了している（EOL（サポート終了）を迎えている、あるいは迎えつつある）
• 設計書やドキュメントがほとんど存在せず、ソースコードのコメントも当時の担当者独自の書き方でしか残っていない
• サーバーやOSも古いバージョンのまま稼働しており、システム本体だけでなく基盤自体の刷新も同時に必要になる

これらの事実を契約の話に絡めて確認することも重要だ。単に「うちでしか直せません」という言葉を受け取るだけでなく、「そのシステムは技術的にあと何年使えるものなのか」を開発会社に率直に聞いてみるとよい。誠実な開発会社であれば、この質問に対して正直に答えてくれるはずだ。逆に、この質問をはぐらかされたり、明確な回答が得られなかったりする場合は、契約書の確認と並行して、システムの技術的な将来性についても第三者の意見を求めた方がよい局面かもしれない。

契約書確認と並行して用意しておきたい社内の記録

契約書そのものの確認と同時に、社内に残っている記録も整理しておくと、その後の判断がしやすくなる。特に以下の3種類の記録は、契約書と組み合わせて初めて意味を持つ。

第一に、過去の見積もりと支払いの履歴だ。何年前にいくら払って、どのような改修を依頼したのか。これが年表形式で残っていれば、開発会社が提示する見積もりの妥当性を判断する材料になる。急に費用が跳ね上がった年があれば、その理由を尋ねることもできる。

第二に、過去のトラブル対応の記録だ。システムに障害が発生した際、どのくらいの時間で対応してもらえたか、対応の質はどうだったかという記録は、保守契約のSLA（対応時間・対応範囲）が実際に守られているかどうかを検証する材料になる。契約書に書かれている内容と、実際の運用実態がずれていないかを確認する上で欠かせない。

第三に、社内の誰がそのシステムのどの部分を使い、何に困っているかという現場の声だ。経理担当者、製造現場の担当者、営業担当者など、実際にシステムを使っている社員から「この部分が使いにくい」「この機能がないと困る」という声を集めておくと、乗り換えや改修を検討する際の判断材料になるだけでなく、開発会社との交渉でも「現場が求めている具体的な改善点」として提示できる。

これらの記録は、経理の書類や労務の記録のように毎年当然に整備されているものではないため、承継のタイミングで初めて意識的に集め始める会社が多い。しかし一度整理してしまえば、その後は毎年少しずつ更新していくだけで済むようになる。

内製化という選択肢についても触れておく

契約書を確認し、著作権やソースコードの帰属が発注者側に有利であることが分かった場合、選択肢の一つとして、システムの保守を社内に取り込むかどうかの判断も出てくる。ただし、これは規模の小さい中小企業にとって、必ずしも現実的な選択肢とは言えない場合が多い。専門のエンジニアを一人雇用するコストと、外部の開発会社に保守を依頼するコストを比較した上で、システムの重要度や複雑さに応じて判断する必要がある。

完全な内製化とアウトソースの二択ではなく、多くの中小企業にとって現実的な中間解は、「複数の開発会社やサービスに分散して依存する」という考え方だ。基幹システムは長年の付き合いのある開発会社に任せつつ、比較的独立性の高い一部の業務（例えば勤怠管理や請求書発行など）は、標準的なクラウドサービスに切り替えて依存先を分散させる、という段階的なアプローチも検討に値する。すべてを一気に変える必要はなく、リスクの高い部分から徐々に手を入れていくという発想の方が、実務的には失敗しにくい。

決別ではなく「見える化」から始める

最後にもう一度、この記事の趣旨を確認しておきたい。「うちでしか直せません」と言われたときに必要なのは、開発会社との決別を決断することではない。まず契約書という一次資料を読み、現状がどうなっているかを「見える化」することだ。

見える化した結果、契約内容が対等で問題がないと分かれば、それはそれで安心材料になる。逆に、著作権もソースコードも開発会社側に完全に握られている状態だと分かれば、それは今すぐ関係を切る理由にはならないが、今後どう付き合っていくかを考える上での重要な出発点になる。いずれの結果であっても、「知らないまま」よりは「知っていて選んでいる」状態の方が、経営判断としてはるかに健全だ。

先代がどういう思いでその開発会社と付き合ってきたのかは、契約書だけでは分からない部分もあるだろう。しかし、次の世代に何を引き渡すかを考えるとき、少なくとも契約の中身については、感情や人間関係とは別の軸で、一度きちんと確認しておく価値がある。

契約書を読むときに陥りやすい誤読

納品物の中身から著作権の所在を具体的に読み解く方法は先代システムのソースコードの権利は誰にあるか、納品物から確認する方法にまとめている。契約書を実際に手に取って読んでみると、経営者が誤読しやすいポイントがいくつかある。ここで代表的な3つを挙げておく。

第一に、「納品」という言葉と「著作権譲渡」という言葉を混同してしまうことだ。「本システムを納品する」という条項があっても、それは物理的・電子的にファイルを受け取ることを意味するだけで、著作権が移転するとは限らない。著作権の移転には「著作権を甲(発注者)に譲渡する」といった、権利の移転を明示する文言が必要になる。納品条項と著作権条項は別の条文として、両方が存在するかどうかを確認する必要がある。

第二に、「無償で提供する」という表現と、「所有権が移る」という意味を混同してしまうことだ。ソースコードを無償で提供してもらえる契約になっていても、それはあくまで「見せてもらえる」という話であり、そのソースコードを改変したり、他社に見せて保守を依頼したりする権利までは含まれていない場合がある。利用許諾の範囲がどこまで及ぶかは、別途確認が必要だ。

第三に、契約書の「本文」だけを読んで、別紙や覚書を見落とすことだ。長年の付き合いのある開発会社との契約では、当初の契約書のあとに、個別の改修ごとに簡易な覚書や発注書が積み重なっていることが多い。これらの中に、本文とは異なる条件（たとえば著作権の扱いについての例外規定）が紛れ込んでいることもあるため、契約書本体だけでなく、関連する覚書・発注書もまとめて確認する必要がある。

開発会社側の事情も理解しておく

契約書の確認を進める際、開発会社を一方的に「悪者」と決めつけて臨むと、その後の関係修復が難しくなる。開発会社側にも、それなりの事情があることを理解しておくと、交渉がスムーズに進みやすい。

中小の開発会社にとって、長年保守してきたシステムのソースコードを外部に開示することには、いくつかの現実的な不安がある。一つは、開示した結果、発注者が別のより安価な会社に切り替えてしまい、これまでの投資（長年の無償対応や、担当者が独自に積み上げてきた知見）が回収できなくなるという不安だ。もう一つは、ソースコードの品質そのものへの不安で、長年の改修の積み重ねで内部が複雑化しているシステムを見せることに、単純に気恥ずかしさや抵抗を感じている担当者も少なくない。

こうした事情を理解した上で、「今後も引き続きお付き合いしたい前提で、リスク管理のために契約内容を確認させてほしい」という姿勢で伝えると、開発会社側も身構えずに応じやすくなる。ソースコードエスクローのように、開発会社がソースコードを手放さずに済む仕組みを提案することも、この文脈では有効な選択肢になる。

「うちでしか直せません」への対応を先延ばしにするコスト

契約書の確認は、正直なところ手間のかかる作業だ。決算期の対応、取引先との調整、日々の現場対応に追われる中で、「今すぐ手をつけなくても、システムは今のところ動いている」と判断し、先送りにしたくなる気持ちは理解できる。しかし、この確認作業を先延ばしにすることには、目に見えにくいコストが積み重なっていく。

一つは、開発会社の担当者の高齢化・退職というリスクだ。先代の時代からその会社を担当してきたベテラン社員が退職すれば、契約書に何が書いてあろうと、実質的に「読める人」がいなくなってしまう可能性がある。この場合、契約書の確認を先延ばしにしていた期間がそのまま、対応不能になるまでの時間の目算を狂わせることになる。

もう一つは、システムそのものの経年劣化だ。古いシステムほど、稼働しているサーバーやOS、周辺のソフトウェアが先にサポート終了を迎え、契約や著作権の話をする前に、そもそも動かし続けられるかどうかという、より緊急度の高い問題に直面することがある。契約の確認を後回しにしている間に、こうした技術的な期限が先に来てしまうことは珍しくない。

• 担当者の高齢化・退職は予告なく発生することがある
• サーバーやOSのサポート終了は、多くの場合あらかじめ日付が決まっている
• 契約内容の把握には時間がかかるが、緊急時には時間の余裕がない
• 平時のうちに確認しておくことで、緊急時の選択肢が狭まらずに済む

平時に契約書を確認しておくことは、いわば保険のようなものだ。何も問題が起きなければ確認した時間が「無駄」に見えるかもしれないが、実際に何かが起きたときには、その確認作業の有無が対応スピードを大きく左右する。

システム以外の承継作業と並べてみる

最後に、システムの契約確認という作業を、事業承継における他の作業と並べて位置づけておきたい。事業承継では、株式の移転、登記の変更、取引先との契約の引き継ぎ、金融機関との取引関係の見直しなど、様々な契約関係を確認する作業が発生する。これらの多くには、税理士・司法書士・弁護士といった専門家が付き、チェックリストに沿って進められる。

システムの契約についても、本質的には同じ種類の作業だ。「誰が何を持っているか」「契約の終了時に何が起きるか」「今の条件は市場水準と比べてどうか」という視点は、株式の譲渡契約でも、取引先との基本契約でも、システムの保守契約でも共通している。違うのは、システムについては専門家という「型」がまだ社会的に定着していないという点だけだ。

契約書を自分で読み込むべきか、顧問税理士や弁護士に確認してもらうべきかで迷う場合は承継1年目、システムの契約書は自分で読むか顧問に確認してもらうかを参考にしてほしい。だからこそ、経営者自身がこの記事で挙げたような項目を一つずつ確認していく作業には、単なる契約書の点検以上の意味がある。それは、先代が築いてきた事業を、承継後の社長が自分の言葉で理解し直す作業であり、次に何かが起きたときに「知らなかった」という状態から会社を守るための、地味だが欠かせない準備でもある。

まとめ：契約書は「先代への不信」ではなく「経営の当然の道具」

「うちでしか直せません」という言葉は、多くの場合、開発会社側に悪意があって発せられているわけではない。むしろ、契約書の整備が後回しにされてきた結果、開発会社自身も「自分たちしか触っていないから、自分たちしか分からない」という状態を、特に疑問を持たずに続けてきただけ、というケースが大半だ。それはまた、開発会社自身も薄氷の上に立っているという事情の裏返しでもある。

先代の代からの関係を断ち切る必要はない。まず契約書を読み、ソースコードの帰属、著作権の帰属、保守契約の対応範囲と引き渡し義務という3つの軸を確認する。それだけで、次に取るべき行動——関係を維持しながらリスクだけ下げるのか、エスクローのような仕組みを導入するのか、それとも本格的に別の体制へ移行するのか——がはっきりしてくる。

株式の承継や登記の変更については、税理士や司法書士という専門家が必ず横にいる。システムについては、今この記事を読んでいるあなた自身が、契約書という一次資料に向き合う最初の一人になる。それは先代への不信の表明ではなく、事業を次の世代へつなぐための、経営者としての当然の道具の使い方に過ぎない。

FAQ

Q1. 「うちでしか直せません」と言われたら、まず何をすればよいですか。

まず開発会社を問い詰めるのではなく、自社が保管している契約書（開発時の契約書と、現在の保守契約書の両方）を確認してほしい。ソースコードの提供条項、著作権の帰属条項、保守契約の解約時における資料引き渡し義務の3点があるかどうかを見る。この3点が確認できれば、「本当に他社では対応できないのか」「契約上そう仕向けられているだけなのか」の区別がつきやすくなる。

Q2. 開発費を全額払っているのに、なぜ著作権が自社にないことがあるのですか。

著作権法は「創作した者に著作権が帰属する」という原則を採用しており、費用を負担したことと著作権の帰属は自動的には連動しない。契約書に著作権を発注者へ譲渡する旨の明確な条項がなければ、実際にプログラムを書いた開発会社側に著作権が残ったままになる。この点は多くの経営者が誤解しやすいポイントなので、契約書の文言を必ず確認してほしい。

Q3. 契約書が見当たらない場合はどうすればよいですか。

簡易な見積書や発注書しか残っていない、あるいは契約書自体が見つからないというケースは、先代の時代の契約では珍しくない。この場合はまず現状使っているシステムの一覧と契約状況を一枚にまとめ、契約書が見当たらないシステムについては開発会社に写しの再発行を依頼するのが現実的な第一歩になる。

Q4. 開発会社との関係を維持したまま、リスクだけを下げる方法はありますか。

ある。ソースコードエスクローという仕組みを使えば、ソースコードは開発会社が保有したまま、第三者機関に預けておき、倒産や契約終了などの条件が成立した場合にのみ発注者が取り出せるようにできる。関係を断ち切らずに「もしものとき」の備えだけを整えたい場合の現実的な選択肢になる。

契約書の確認と並行して、実際にデータをエクスポートできるかどうかも試しておきたい。先代契約のSaaS解約前にやるべきデータエクスポート手順を参照。