ベンダーロックインを避けるには｜発注時に押さえておきたい工夫

ベンダーロックインは、特定の開発会社や製品に依存しすぎて、ほかの会社に切り替えたくても切り替えられなくなる状態を指します。保守費用の値上げを提示されても交渉材料がない、改修の見積もりが妥当か判断できない、担当者が退職して対応が遅くなっても乗り換え先がない、といった形で表面化します。

やっかいなのは、ロックインが発注した時点ではほとんど目に見えないことです。開発中は順調に進み、数年たって保守や改修のタイミングで初めて「この会社以外に頼めない」と気づくケースが少なくありません。そのときには契約もシステムもできあがっており、後から手を打つには費用と時間がかかります。

一方で、特定の会社や製品に頼ること自体が悪いわけではありません。信頼できる開発会社と長く付き合うことは、多くの中小企業にとって合理的な選択です。問題になるのは「頼っている」ことではなく、「いざというときに離れる選択肢がない」ことです。

この記事では、ロックインが起きる仕組みを整理したうえで、許容してよい依存と避けるべき依存の見分け方、契約・設計・納品物の各段階で発注側が押さえておきたい工夫を解説します。

ベンダーロックインが起きる3つの仕組み

ロックインと一口にいっても、原因はいくつかに分かれます。原因によって打つ手が違うため、まずは自社がどのタイプのリスクを抱えているのかを切り分けることが出発点になります。

タイプ	起きていること	典型的な兆候
知識のロックイン	仕様や改修履歴を開発会社しか把握していない	設計書が古いまま、口頭の経緯が多い、担当者が替わると対応が止まる
権利のロックイン	ソースコードの著作権やデータの扱いが開発会社側に残っている	契約書に権利の帰属が書かれていない、ソースコードを受け取っていない
技術のロックイン	独自のフレームワークや特定の製品・サービスに強く依存している	その会社の自社製品の上に構築されている、扱える技術者が市場にほとんどいない

公正取引委員会が2022年2月に公表した「官公庁における情報システム調達に関する実態調査報告書」では、国の機関や地方公共団体に、既存ベンダーと再度契約することになった理由を尋ねています（複数回答）。最も多かったのは「既存ベンダーしか既存システムの機能の詳細を把握することができなかったため」で48.3%でした。このほか、「既存システムの機能（技術）に係る権利が既存ベンダーに帰属していたため」が24.3%、「既存ベンダーしか既存システムに保存されているデータの内容を把握することができなかったため」が21.1%でした。

これは官公庁を対象にした調査ですが、民間企業でも構図は同じです。とくに知識のロックインは、権利の問題よりも多く起きていることが読み取れます。契約書をきちんと整えても、仕様を把握しているのが開発会社だけであれば、実質的には乗り換えられません。

逆にいえば、ロックインを避ける工夫は「権利を押さえる」「知識を発注側にも残す」「代わりの効く技術を選ぶ」の3つに整理できます。以降の章では、この3つを発注の流れに沿って見ていきます。

参考：官公庁における情報システム調達に関する実態調査報告書／公正取引委員会

許容してよい依存と避けるべき依存の見分け方

すべての依存をなくそうとすると、かえって費用がかさみます。たとえば、クラウドの独自サービスを一切使わずに汎用的な構成だけで作れば乗り換えはしやすくなりますが、そのぶん開発や運用の手間が増えます。どこまで依存を許すかは、システムの性質で決めるのが現実的です。

判断の軸になるのは、そのシステムが止まったり改修できなくなったりしたときの事業への影響と、そのシステムをどれくらいの期間使い続けるかの2つです。

システムの性質	依存の考え方
売上や顧客対応に直結し、5年以上使う基幹的なシステム	権利・知識・技術のすべてで乗り換えの余地を残す。多少費用がかかっても標準的な技術を優先する
社内向けで、止まっても手作業で代替できるシステム	権利とデータの取り出しだけは確保し、技術選定は開発会社の得意分野に任せてもよい
検証目的や期間限定のシステム	依存を許容し、スピードを優先する。本番化するときに作り直す前提で進める
業界標準のパッケージやSaaSで代替できる業務	製品への依存は前提として受け入れ、データを定期的に取り出せるかを確認する

注意したいのは、検証目的で作ったものがそのまま本番で使われ続けるパターンです。「とりあえず動けばよい」で作ったシステムが数年後に業務の中心になり、気づいたときには作った会社しか触れない状態になっている、ということがよくあります。検証段階で依存を許容するなら、本番に移す前に一度、権利・ドキュメント・技術構成を見直すタイミングを計画に入れておくと安全です。

また、開発会社と長期的に付き合うことと、ロックインを避けることは矛盾しません。乗り換えられる状態にあることで、開発会社側も「選ばれ続けるために品質と価格を保つ」動機を持ちます。乗り換えの余地は、関係を良好に保つための保険と考えるとよいでしょう。

契約の段階で押さえる権利と義務

権利のロックインは、契約書でほぼ防げます。ただし、契約書のひな形は開発会社側が用意することが多く、発注側が確認しないまま締結してしまうと、権利が開発会社に残る内容になっていることがあります。

まず確認したいのが、ソースコードの著作権の扱いです。著作権法では、プログラムの著作権は原則として実際に作成した側に発生します。発注側が費用を払ったからといって、自動的に発注側のものになるわけではありません。権利を発注側に移すなら、契約書に譲渡を明記する必要があります。

さらに、著作権法第61条第2項は、著作権を譲渡する契約で第27条（翻訳権、翻案権等）や第28条（二次的著作物の利用に関する原著作者の権利）に規定する権利が譲渡の目的として特掲されていないときは、これらの権利は譲渡した者に留保されたものと推定する、と定めています。改修や機能追加はプログラムの翻案にあたりうるため、「著作権を譲渡する」とだけ書くのでは不十分で、「著作権法第27条及び第28条に規定する権利を含む」と明記するのが一般的です。

一方で、開発会社が以前から持っている汎用的な部品やライブラリまで譲渡を求めると、開発会社が受けられなくなったり見積もりが上がったりします。その場合は、汎用部分は開発会社に権利を残し、発注側には自由に利用・改変できる許諾（ライセンス）を付ける形で折り合うのが現実的です。

著作権以外にも、乗り換えに関わる条項はいくつかあります。契約書を確認するときは、次の項目が書かれているかを見てください。

• ソースコード一式と、ビルドやデプロイに必要な設定ファイルを納品物に含めること
• データベースのデータを、汎用的な形式で発注側が取り出せること
• 契約終了時に、後任の開発会社への引き継ぎに協力すること（期間と費用の扱いを含む）
• 設計書や運用手順書など、納品するドキュメントの範囲
• 開発会社が外部の開発パートナーに再委託する場合の扱い

引き継ぎ協力の条項は見落とされやすい項目です。契約が終わった後に協力を依頼しても、相手には応じる義務がありません。「契約終了後◯ヶ月間は、別途定める単価で引き継ぎ作業に協力する」といった形で、期間と費用の目安を決めておくと揉めにくくなります。

参考：著作権法／e-Gov法令検索

設計と技術選定で乗り換えの余地を残す

技術のロックインは、開発の初期に使う言語やフレームワーク、インフラを決めた時点でほぼ決まります。発注側が技術の細部まで判断する必要はありませんが、提案を受けたときに確認すべき観点はあります。

最も確認しやすいのは、「この技術を扱える会社がほかにもあるか」という点です。広く使われているプログラミング言語やフレームワーク、データベースであれば、乗り換え先の候補は多くなります。反対に、開発会社が独自に作ったフレームワークや自社製品の上に構築する提案であれば、その理由と、将来ほかの会社が引き継げるかを質問しておくべきです。

確認する観点	望ましい状態	注意が必要な状態
言語・フレームワーク	広く使われていて、扱える技術者が多い	開発会社独自のもの、更新が止まっているもの
データの持ち方	一般的なデータベースに、意味の分かる項目名で保存されている	独自形式のファイルや、暗号化されて中身が読めない形で保存されている
外部との連携	APIなど仕様が文書化された方法でつながっている	システム同士がデータベースを直接読み書きしている
インフラのアカウント	クラウドやドメインの契約者が発注側になっている	開発会社のアカウントの中でサーバーが動いている

インフラのアカウントの持ち主は、技術に詳しくない発注側でも判断できる重要な項目です。クラウドの利用契約、ドメイン、ソースコードを保管するリポジトリが開発会社名義になっていると、乗り換えのときにそれらの移管から交渉しなければなりません。最初から発注側の名義で契約し、開発会社には作業に必要な権限だけを付与する形にしておけば、契約を切り替えても環境はそのまま手元に残ります。

クラウドの独自サービスについては、使うかどうかを一律に決める必要はありません。データベースや認証のように多くのクラウドに似たサービスがあるものは、乗り換えの際も移しやすい部類です。特定のクラウドにしかない機能に業務の中核を載せる場合は、その機能が使えなくなったときの代替手段を、提案の段階で開発会社に聞いておくとよいでしょう。

技術提案の比較では、開発会社が得意とする技術を使うこと自体を否定する必要はありません。得意な技術で作るほうが品質も速さも上がりやすいからです。確認したいのは、その技術が自社にとって将来の足かせにならないかという一点です。判断に迷う場合は、複数の開発会社に同じ要件で提案を依頼し、技術構成の違いとその理由を聞き比べると、各社の考え方が見えてきます。

知識を発注側に残すドキュメントと運用

先ほどの調査結果のとおり、最も起きやすいのは知識のロックインです。契約と技術を整えても、システムの中身を理解しているのが開発会社だけでは、実際には乗り換えられません。知識を発注側にも残す工夫は、開発中から継続して行う必要があります。

ドキュメントについては、量よりも「後任の開発会社が最初に読むもの」が揃っているかが重要です。最低限、次のものがあれば引き継ぎの初動は大きく変わります。

• システム全体の構成図（どのサーバーやサービスが、どうつながっているか）
• データベースの主なテーブルと項目の意味
• 開発環境の作り方と、本番に反映する手順
• 外部サービスとの連携先と、その契約・アカウントの一覧
• 定期的に動いている処理（夜間バッチなど）の一覧と、止まったときの影響

これらは一度作って終わりではなく、改修のたびに更新されなければ意味がありません。保守契約に「改修時に関連ドキュメントを更新する」ことを含め、年に一度は発注側が中身を確認する場を設けると、古いまま放置されるのを防げます。

もう一つの工夫は、発注側にシステムの全体像を説明できる担当者を置くことです。プログラムを書ける必要はありません。どの業務がどの機能で動いているか、データがどこに保存されているか、改修の経緯がどうだったかを把握している人が社内にいれば、開発会社が替わっても話の起点を失わずに済みます。

あわせて、改修の依頼と回答は、メールやチャットの個別のやりとりだけで済ませず、課題管理ツールなど後から検索できる場所に残しておくと、経緯の把握に役立ちます。「なぜこの仕様になっているのか」は、ドキュメントよりもやりとりの記録に残っていることが多いためです。

まとめ

ベンダーロックインは、知識・権利・技術の3つの経路で起きます。特定の会社と長く付き合うこと自体は問題ではなく、避けたいのは「離れる選択肢がない」状態です。依存をどこまで許すかは、そのシステムの事業への影響と使用期間で決めるのが現実的です。

これから発注する場合と、すでに稼働しているシステムがある場合とで、最初にやることは変わります。

状況	まずやること
これから発注する	契約書で著作権の譲渡（第27条・第28条の権利を含む）、ソースコードとデータの納品、引き継ぎ協力を確認する。クラウドやドメインは自社名義で契約する
すでに稼働しているシステムがある	現行の契約書で権利の帰属を確認し、ソースコードを受け取っているか、クラウドやドメインが誰の名義かを棚卸しする
どちらにも共通	システムの全体像を説明できる社内担当者を決め、構成図とデータの説明書が最新かを確認する

明日すぐにできることとしては、手元の契約書を開いて権利の帰属と納品物の範囲を確認し、クラウドやドメインの契約者名義を調べてみることをおすすめします。ここが曖昧であれば、次回の保守契約の更新が条件を見直す機会になります。