ベンダーロックインとは？脱却するための対策方法対策方法と事例を解説

ベンダーロックインとは、ソフトウェアの機能改修やバージョンアップなど、導入したベンダー以外が実施できず、既存のベンダーを利用し続けないといけない状態になることです。
同様に、ハードウェアのメンテナンスなどにおいても、他のベンダーに切り替えることが困難になってしまう状態のことを言います。
ベンダーロックインに陥ると、DXを推進する上で大きな妨げになる場合があります。
本記事ではベンダーロックインの概要から発生要因、回避するための方法について解説します。

➡︎【資料ダウンロード】さまざまな業界のDX推進事例をわかりやすく解説「DX事例集」＜2024年版＞

ベンダーロックインとは

ベンダーロックインとは企業のシステムを導入、構築する際、特定のベンダーの製品、サービス、システムに大きく依存してしまい、他のベンダーに切り替えることが困難になってしまう状態のことを言います。
ベンダーロックインには、下記のコーポレートロックインとテクノロジーロックインの2種類があります。

➡︎【資料ダウンロード】さまざまな業界のDX推進事例をわかりやすく解説「DX事例集」＜2024年版＞

コーポレートロックイン

コーポレートロックインとは、システムが特定のベンダーに依存している状態を指します。
というのも、既存のベンダーは、自社の事業や組織、業務に関する理解が深いです。そのため別のベンダーに移行するには、改めて事業や業務に関するルールや方法などを説明する手間やコストがかかります。

また、既存のベンダーと同水準の理解度まで到達するには一定の期間が必要です。したがって、結果的に毎回同じベンダーに依頼することでこれらのリスクを防ぐことができるため、コーポレートロックインに陥りがちです。

テクノロジーロックイン

テクノロジーロックインとは、あるサービスやシステムの独自の開発手法や仕様に依存している状態を指します。コーポレートロックインと異なり、技術面で制限されてしまうことを言います。
例えば、ある地方自治体の基幹システムがMicrosoft社のMicrosoft Edgeでないと正常に動作せず、Google ChromeやFirefoxを使って利用できない場合、他の製品やサービス、システム等を調達する際の選択肢が狭められるといったことが起こります。

★ベンダーロックインからの脱却には「CodeRebuild AI」

➡︎【資料ダウンロード】さまざまな業界のDX推進事例をわかりやすく解説「DX事例集」＜2024年版＞

ベンダーロックインに陥っている自治体は約50％

公正取引委員会が2022年2月8日に発表した「官公庁における情報システム調達に関する実態調査報告書」によると、98.9％の自治体が「既存ベンダーと再度契約することとなった」と回答しました。再度契約することとなった理由として、48.3％の自治体は「既存ベンダーしか既存システムの機能の詳細を把握することができなかったため」としています。

その他の理由としては「既存システムの機能（技術）に係る権利が既存ベンダーに帰属していたため」、「既存ベンダーしか既存システムに保存されているデータの内容を把握することができなかったため 」といった理由が挙げられています。
これらのケースは民間企業でも大いに可能性のある事象だと考えられます。

➡︎【資料ダウンロード】さまざまな業界のDX推進事例をわかりやすく解説「DX事例集」＜2024年版＞

ベンダーロックインが発生する要因

それでは主にベンダーロックインが発生する要因にはどういったものがあるのでしょうか。

設計書などのドキュメントが整備されていない

一つ目の要因としては、設計書などのドキュメントが整備、最新化されていないということが挙げられます。技術者は設計書を読むことでシステムの仕様を理解します。ドキュメントが整備されていないと、システムの仕様理解に時間がかかり、結果的に移行のコストがアップしてしまいます。

ソリューション固有の技術を採用

二つ目の要因としては、導入したシステムが独自の技術を採用していることが挙げられます。独自技術を使用し、かつ、市場でのシェアが低いパッケージソフトやクラウドサービスを導入すると、その技術を理解する技術者を確保することが難しく、他サービスやソリューションに移行することが困難になってしまいます。

馴染みのベンダーは融通が利く

他社への切り替えが容易ではなく、DXの推進を阻む要因にもなるベンダーロックインですが、同じベンダーを使うことは一概に悪いことでもありません。特定のベンダーと取引を継続すると、自社の事業や業務に精通し、細かい要件や仕様を把握しているベンダーは頼りになります。気軽に相談ができたり、融通が効くという点ではメリットがあると言えるでしょう。しかし後述する問題点も多く、ほとんどの場合、ベンダーロックインは回避すべきとされています。

★DXについて詳しくはこちら

➡︎【資料ダウンロード】さまざまな業界のDX推進事例をわかりやすく解説「DX事例集」＜2024年版＞

ベンダーロックインの問題点

では、ベンダーロックインの問題点とは具体的にどういったものがあるのでしょうか。

★ベンダーロックインからの脱却には「CodeRebuild AI」

開発・保守運用のコストが高額になりがち

ベンダーロックインに陥ると、特定のベンダーに依存している状態になるので、価格交渉など交渉力が低下する恐れがあります。なぜなら、対応できるベンダーが他にいないため、既存ベンダーと他社との競争がなくなるためです。既存ベンダーに高額な費用で提案され、その金銭的妥当性が不透明な場合でも、その提案を受け入れざるを得ない状況に陥る可能性があります。

相見積もりが出来なくなる

また、相見積もりを取ろうにも、ドキュメントが整備されていなかったり、既存ベンダー独自の技術が採用されていると、他のベンダーは既存システムについて理解する手段がありません。開発規模の算出ができないという問題も発生します。

レガシーシステムを使い続ける可能性

ベンダーロックインに陥ると、他のベンダーへの切り替えが困難なことから、レガシーシステムを使い続けるという状況になりがちです。
レガシーシステムを使っていると、特定の人にしか扱えず属人化する、古い技術のため作業効率が悪い、新たな脅威に対するセキュリティに乏しいなどといったリスクを負うことになります。

★レガシーシステムについて詳しくはこちら

他社への移行が困難

社内でベンダーの切り替え検討がなされたとしても、他社の構築したシステムを運用できないとお断りされるケースや、既存のベンダーと同水準の理解度まで引き上げるには長期の期間を有するケースもあります。いずれにしても手間やコストが発生することから、移行が困難と判断されてしまうことが多いです。

ベンダーの都合で移行する可能性

また、逆にベンダー側の都合による提供サービスの終了や、事業撤退、倒産などが起こった場合、移行が困難であっても他社への切り替えが必須となることもあります。移行コストを避けるために陥りがちなベンダーロックインですが、結果的に膨大な移行コストがかかることになります。

要件や要望を通しにくくベンダーの言いなりになりがち

既存ベンダーは、他のベンダーに切り替えることが困難であることをいいことに、より良いシステムに改修するなどの前向きな提案をしなくなる場合があります。そのため、コストを下げてほしいといった要望が断られるどころか、逆に運用・保守コストを上げられたり、ベンダー側の立場が強いために要求を満たしてくれない、また、対応が不誠実であっても安易にベンダーを変えることができないといった問題が起こりがちです。

DX推進の妨げになる

上記の問題点から本来自社のDX推進に割くべき予算を既存のシステムの維持管理費などで占めるようになり、新しい取り組みに予算が割けないといった事態になります。
ベンダーロックインからの脱却はそれなりの期間とコストがかかりますが、中長期的にみて脱却したほうがよいケースがほとんどです。

★ベンダーロックインからの脱却には「CodeRebuild AI」

➡︎【資料ダウンロード】さまざまな業界のDX推進事例をわかりやすく解説「DX事例集」＜2024年版＞

ベンダーロックインから脱却する方法

そもそもベンダーロックインに陥らないためには、1社にまるごと発注せず、分散させることと、切り替えのコストを加味して、移行しやすいシステムや技術を運用することが大切です。

ここではベンダーロックインから脱却する方法を5つ解説いたします。
すでにベンダーロックインに陥っている場合だけではなく、これからベンダーと取引をしていく上で、ベンダーロックインに陥るリスク回避となる方法論ですので、ぜひ確認してみてください。

設計書などのドキュメントを整備する

設計書や仕様書がないと、他のシステム開発会社に開発してもらったシステムについて相談しても、相談された開発会社側もシステムについて正確には把握・理解できません。仕様書が手元にない場合、リバースエンジニアリングが新システムの開発とは別に必要となり、開発費以上のコストが発生します。
リバースエンジニアリングとは、既存のシステムの解析・分析をし、システムの構造や仕様を把握することです。最初にシステムを開発してもらう際には、納品物として設計書や仕様書も含めましょう。

また、社内の管理として、どのようなドキュメントが必要でどのようにメンテナンスするかなど定義をして、設計書をはじめとした各ドキュメントを充実、整備し、ベンダーが変わってもドキュメントを渡せば問題ないという状況にしておくことが理想です。

特定のソリューション固有の技術や概念を使用しない

できるだけ特定のパッケージ、固有のデータモデルなどの概念を使用しないほうが賢明です。例えば、ベンダーが特許を取得している独自の技術を使用している場合、その機能が必要であり続ける限りベンダーロックインされます。代替可能な別の技術を有するベンダーを探す場合、その技術の独自性から膨大な工数や手間がかかる可能性があります。

自社の社内規定の確認と見直しを行う

多くの業務システムは個人情報や機密情報を扱うため、セキュリティの観点から、さまざまな社内規定が定められています。この社内規定作成までベンダーに丸投げしてしまうと、ベンダーにとって都合の良いように社内規定が作成されることがあり、結果的にベンダーロックインの原因となってしまいます。

対処法としては、自社の社内規定は、自社で作成、見直しすることが大前提です。さらに専門企業のもとで定期的に見直し、適切に運用することも有効な手段でしょう。また、DX推進を機会に既存規定の見直し・是正をすることも必要です。SaaSなどさまざまなサービスが市場に出ているなか、古い規定をいつまでも適用していると、競合企業からDX推進の後れをとる原因になってしまいます。

成果物の権利関係を明確にする

著作権は、著作物の創作と同時にその作成者に帰属する権利です。
著作物を創作した著作者に自動的に著作権が付与されます。システムにおいても例外ではなく、開発したベンダー（技術者）に帰属する権利となります。

したがって著作権がベンダー側にあると、自社都合でシステム内のコードなどを改変できません。ただし、著作権法の第61条には「著作権は、その全部または一部を譲渡できる」と記載されています。つまり、ベンダーと合意のうえで、システムの権利を自社に帰属させるといったことも可能です。

契約期間の縛りに留意する

ベンダーと取り交わした契約内容が原因で、ベンダーロックインとなっている場合があります。それは、随意契約期間や保守契約期間を締結している場合です。
もし、契約期間が2年であるならば、この2年以内に他の新しいシステムに切り替えても、契約満了までシステムの保守費用を支払わなくてはなりません。

契約満了を待たずに切り替える場合、契約書内にベンダー側の契約不履行に該当する項目があれば、違約金を払わずに済ませられることもあります。

ただし、ビジネスマナーとしてあまりスマートな方法とは言えませんので、基本的にはこのような事態が起こらないよう、あらかじめ途中解約の可否や違約金についての条項を入念にチェックすることが大原則です。また、多額の違約金が発生してしまう場合、切り替えを契約満了まで延長することが賢明と言えます。

★ベンダーロックインからの脱却には「CodeRebuild AI」

➡︎【資料ダウンロード】さまざまな業界のDX推進事例をわかりやすく解説「DX事例集」＜2024年版＞

ベンダーロックインの脱却に成功した企業事例

最後に実際にベンダーロックインから脱却に成功した企業を紹介します。

タブリエ・コミュニケーションズ株式会社

タブリエ・コミュニケーションズ株式会社（以下、タブリエ）は、アニメや声優、ゲーム関連の音声番組を提供する企業です。同社の運営する『インターネットラジオステーション＜音泉＞』は、新規ユーザー獲得のために、既存機能をより使いやすく定期的にアップデートし、サービスの品質を向上させることが求められていました。しかし、既存のベンダーでは、タブリエのビジネス要望に沿った開発体制の構築が困難だったため、ベンダーの見直しを検討していました。

そこでタブリエは、既存のベンダーへのヒアリング段階で新規ベンダーの開発メンバーをアサイン。既存サービスの課題を抽出し、サービス視点、プロダクト視点の両面でキャッチアップを行いました。
結果として、世界で 4億600万人以上のユーザーが利用するオーディオ ストリーミングサービス「Spotify」上でも、音声コンテンツを配信することができるビジネスパートナー向けツールSpotify Open Access の国内第一弾コンテンツとして公開することができました。

★事例について詳しくはこちら

➡︎【資料ダウンロード】さまざまな業界のDX推進事例をわかりやすく解説「DX事例集」＜2024年版＞

まとめ：ベンダーロックインから脱却しDXを推進しよう

ベンダーロックインとは企業や組織のシステム（基幹システムの場合が多い）を導入、構築する際、特定のベンダーの製品、サービス、システムに大きく依存してしまい、他のベンダーに切り替えることが困難になってしまう状態のことを言います。

本記事で解説したように、他社への切り替えが容易ではなく、DXの推進を阻む要因にもなりかねないベンダーロックインについて、ぜひ一度、社内で既存ベンダーとの取り組みや導入しているシステムについて情報整理を行ってみてはいかがでしょうか。

➡︎【資料ダウンロード】さまざまな業界のDX推進事例をわかりやすく解説「DX事例集」＜2024年版＞

システムのモダナイゼーションを検討している企業ご担当者様へ

モンスターラボは、約20年にわたるサービス・プロダクト開発実績から得られたデジタル領域の知見や技術力を活かし、デジタルプロダクト開発事業を展開しています。

老朽化しメンテナンスが困難なシステムや、仕様書がなくブラックボックス化したシステムを抱えてお困りではありませんか。弊社生成AIソリューションの“CodeRebuild AI”を活用し、古いコードの書き換え支援やシステム刷新実現性のPoC検証が可能です。検証後はリホスト&リライト、リビルドといったソリューションを段階的に実施し、ビジネス最適化された単位でのモダナイゼーションを支援します。

モンスターラボが提供するサポートの詳しい概要は以下リンクをご確認ください。

➡︎モンスターラボのサービス概要はこちら

案件の相談はこちら