ベンダーロックインとは　事例をもとに脱却方法を専門家が解説

ベンダーロックインとは

　ベンダーロックインとは、システムを導入・構築する際に特定のベンダー（製品・サービスの販売元）に依存しなければならない状態になることです。システムとは、ソフトウェアやハードウェアなどの情報システムのことを指します。

　多くのシステムは継続的な使用を通して、日々データを蓄積します。しかし、システムの仕様を発注者側がわからない状態であると、蓄積されたデータの移行がスムーズにできないため、結果的に既存のベンダーから抜け出せない状態になりがちです。この状態がベンダーロックインであり、DX（デジタルトランスフォーメーション）推進の大きな足かせとなってしまいます。

ベンダーロックインのデメリット・問題点

　では、既存ベンダーに依存してしまうことで何が問題になるのでしょうか。

改修コストなどの交渉が不利

　ベンダーロックインされてしまうと、発注者はいちじるしく交渉力を失います。完全にベンダーロックインされてしまったシステムは、改修や運用・保守など対応できるベンダーが不在になります。そのため、他社との競争もなくなり、見積金額が数億〜数十億円といった高額になることがあります。

　さらに、大きな問題になっている行政・自治体では、年間8000億円の予算のうち5000億円が単純な維持管理費を占めるような事態となり、DXを進めようにも取り組みたいことに予算を割けなくなってしまいます。

　とはいえ、すべてのシステムを他社に入れ替えてしまうよりは、改修費用を抑えられるため高額な費用の負担を強いられることになるのです。

　また、官公庁の情報システムにおける発注担当者が仕様に精通しておらず、ベンダーが不正確な情報を提供することで自社に有利な状況にさせて、他のベンダーの参入を妨げているなどの問題もあります。この場合、独占禁止法に当たる可能性があり、公正取引委員会でも、この点について指摘しています（参考：官公庁における情報システム調達に関する実態調査報告書）。

要件や要望が通りにくい

　ベンダーロックインした企業は、ベンダー側がそのシステムを支配できるため、よりよいシステムに改修するような最新の技術を研究する必要性がないといえます。

　そのため、「コストを下げてほしい」などのベンダー側にメリットのない要望が断られる可能性があります。したがって、陳腐化したシステムを長く使用する事態に陥ったり、システムに依存した業務フローを発注先が強いられたりする問題が発生します。

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

　ここでは、ベンダーロックインから脱却する方法を原因別に分類しながら紹介します。脱却は一筋縄にはいきません。脱却する方法を学ぶことで、予防策の重要性を理解できるでしょう。

原因が自社の社内規定にある場合

　多くの業務システムは個人情報や機密情報を扱うため、セキュリティなどの観点から、さまざまな社内規定が定められます。

　この社内規定策定をベンダーと同じ系列のコンサルティング会社に丸投げしてしまうと、ベンダーにとって都合のよいように社内規定が策定されることがあり、結果的にベンダーロックインの原因となってしまいます。

　また、昨今では業務システムをSaaSなどのクラウドサービスに置き換えることで、大幅にコストパフォーマンスを上げるケースも増えています。

　しかし、このSaaSなどのクラウドサービスも取り扱う機密情報の保管場所（サーバーの場所）を特定できないなどを理由とし、社内規定でSaaS導入に縛りを設けるベンダー系コンサルティング会社なども存在します。

　これらの対処法として、自社の社内規定はベンダーと独立したコンサルティング会社のもとで定期的に見直し、適切に運用することが有効です。社内のルールや規定が増えることがあっても、減ることはなかなかない職場も多く、DX推進を機会に既存ルールの見直し・是正も大切です。

　SaaSなどさまざまなサービスが市場に出ているなか、古いルールをいつまでも採用していると、競合からDX推進の後れをとる原因になってしまいます。

原因がベンダーの特許などに起因する場合

　ベンダーが特許を取得している独自の技術を使用している場合、その機能が必要であり続ける限りベンダーロックインされます。これはベンダー側に法的に認められた権利があるため、この場合は、代替できる別の技術を有するベンダーを探す必要があります。

　また、証券取引所のような毎秒何十万件もデータを処理し続けるような特殊なシステムは、特定の企業でしか構築・運用・保守できません。そもそも代わりとなるベンダーがいなければ、ベンダーロックインは回避できません。

　このような場合は、ベンダーロックインを受け入れる範囲を正しく把握したうえで発注することが大切です。

原因が契約内容に問題がある場合

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

　この場合は、ベンダーとの交渉が必要です。その際のポイントは、契約を無効化、もしくは賠償請求できるような、ベンダー側の契約不履行となる項目をできるだけ多く見つけることです。

　さらに、相手にとってメリットのある提案を用意することは、かなり効果的です。たとえば、本件を解約する代わりに別の仕事を用意するなどです。大手の商社や広告代理店のようなベンダーに対し、いくつも案件を紹介している実績がある場合は、不条理な要望であってもすぐに通せる場合が多くあります。

　ただし、基本的にはこのような事態が起こらないよう、あらかじめ契約内容を入念にチェックすることが大原則です。

原因がシステムの著作権にある場合

　フルスクラッチ（ソフトウェアやシステムを既存のものを流用せずに新規で制作すること）で開発する際に、そのシステムの著作権は誰に帰属するかという問題が発生します。特別な契約を取り交わしていない場合、著作権は開発したベンダーに帰属します。

　したがって、納品されたシステムを他のベンダーと協業し、複製して再利用しようとしたり、改修したりするには、著作権の保持者の許諾が必要です。

　また、システムのパッケージを購入・導入する場合、システムの著作権はベンダー側に帰属します。この場合も正確に把握することが大切です。

原因がシステムの仕様書に関する場合

　利用中のシステムの仕様がわからず、他のベンダーに切り替えられないケースもよくあります。ただ、システムの仕様書を開示してもらえない場合も少なくありません。

　このような状況で他社のベンダーへ移行する場合は、要件を定義して課題を整理し、1つずつ解決策を考えていくことが求められます。

　また、仕様書がなくとも、費用の問題を解決すれば移行できることがあります。

　たとえば、リバースエンジニアリングが新システムの開発とは別に必要となり、開発費以上のコストが発生します。リバースエンジニアリングとは、既存のシステムの解析・分析をし、システムの構造や仕様を導くことです。

　加えて、移行したいデータの構造の解析に費用が大きく発生することもあります。そして、証券やインフラなどのシステムのように、常にリアルタイムでデータが更新され続ける場合は、移行期間中はシステムの停止が必要となるため、移行プロジェクトにも費用が発生します。

　こうした移行にかかる費用を計算し、移行後に採算が取れるのかを事前によく検討すれば、ベンダーロックインから抜け出せる可能性が高まります。

ベンダーロックインに対応するときに参考となる企業事例

　大手外資系クレジットカード会社（以下、日本法人）が長年、サーバーを保持できない状況にあり、デジタルマーケティング施策がままならなかったものの、大手広告代理店（以下、代理店）がベンダーロックインを切り崩したケースを紹介します。

　セキュリティ関連を米国本社の米国大手ITベンダー（以下、米国ITベンダー）がグローバルで統括しており、米国ITベンダーの監査をクリアしないと、日本法人でサーバーを保持する許諾が下りない状態でした。

　そこで、日本法人は代理店に米国ITベンダーとの交渉を依頼。代理店は米国ITベンダーと繰り返し話し合いをしながら、達成すべきミッションとその手段、乗り越えるべき課題を整理し、米国ITベンダーから提示されるセキュリティポリシーに基づいて対策案（ファイアアウォール・IDS〈侵入検知〉の仕様の調整、電源・ネットワーク・サーバーといった多重化構成の構築など）を出していきました。

　代理店のこうした粘り強い交渉が功を奏し、結果として日本法人は、汎用的な多重化構成のサーバー・インフラを保持することに成功しました。

　このようにセキュリティを1社にグローバルで丸投げしている状態だと、各国法人のマーケティング活動に大きな弊害をもたらしてしまいます。ロックインしているベンダーと対立関係にならないように、達成する目標を共有し、ともに課題を解決する姿勢をとることが大切です。

ベンダーロックインを予防する方法

　ベンダーロックインを予防する方法は、1社にまるごと発注せずに、複数社に分散して発注することが基本です。

マイクロサービス・アーキテクチャとオープンソースプログラムを目指す

　たとえば、大規模なシステムを構築する場合、モノリシック・アーキテクチャではなく、以下の右図のように、マイクロサービス・アーキテクチャ（機能ごとに小分けしたシステムを構築してREST APIやGraph APIで連携させサービスを実現する構造）で構築すると、機能ごとに細かく最適なベンダーにわけて発注しやすくなります。

　また、アプリケーションからミドルウェア、OS、ハードウェア、ネットワークなどベンダー独自の製品で構築してしまうと、ベンダーロックインに陥りがちです。

　以下の右図のように、オープンソースプログラムを使用してアプリケーションを開発したり、汎用的なIaaSやPaaS（AWS、GCP、Azureなど）を組み合わせて構築したりするなどの対処法により、ベンダーロックインを回避しやすくなります。

IT管理に予算をかけられない場合はリスクマネジメントが大切

　中小企業では各部門の担当が個人で管理している場合も多く、むしろベンダーロックインされないと自社でのマネジメント自体が難しいケースもあります。

　たとえば、来月からWindowsがなくなると発表された場合、Windowsから移行困難なアプリケーションを業務で使っているケースが考えられます。短期間ですべての業務をMacやLinuxなどに移行することは難しいでしょう。この場合もある意味、ベンダーロックインといえます。このベンダーロックインを恐れて、Windowsパソコンを使わない意思決定は正しいとはいえません。

　このように中小企業では、ベンダーロックインが必ず発生するものであり、うまく利用するものだと正しく認識する必要があります。何をロックインされ、何を回避すべきかを理解しマネジメントしながら、想定外のベンダーロックインを発生させないよう取り組むことが重要です。

ベンダーロックインから脱却するためには原因の特定が重要

　ベンダーロックインは大なり小なり必ず発生することをふまえ、適切にシステムをマネジメントする必要があります。

　そもそも、ベンダーロックインしているベンダー自身もさまざまなハードウェアのメーカーやパートナー企業からベンダーロックインされているのが現実です。

　たとえば、先に挙げた例でWindowsがなくなってしまうと、Windowsアプリケーションの開発ベンダーは多くのエンジニアが職を失います。これはベンダーロックインと依存の次元が異なりますが、サービスそのものが依存しているとダメージが大きいという例です。

　ベンダーロックインされている状態からのDX推進は困難ですが、段階的にフェーズを刻むなど、対処法は検討できます。

　特にSaaSサービスなどに至っては便利・低コストであればあるほど、ベンダーロックインのリスクと表裏一体となります。したがって、コストを抑えることが重要な中小企業においてはベンダーロックインをマネジメントすることが大切です。