近年、「ベンダーロックイン」と呼ばれる状態に多くの企業や自治体が陥ってしまっている現状をご存知でしょうか。
ベンダーロックインとは、システムの開発・保守について特定のベンダーに対する依存を余儀なくされ、他のベンダーに切り替えることが困難になってしまっている状態のことを指します。
令和4（2022）年には、98.9％もの自治体が「既存ベンダーと再契約することになった」と回答したという公正取引委員会の調査結果もあり、問題の深刻さが浮き彫りとなっています。
そこで今回は、ベンダーロックインに陥ってしまう要因や起こり得る問題、脱却するために必要なポイントについて詳しく解説していきます。
・ベンダーロックインについて、聞いたことはあるけど詳しくは知らない
・ベンダーロックインがなぜ起きてしまうのか知りたい
・ベンダーロックインに陥ると何が問題なのか知りたい
・ベンダーロックインを解消するにはどうしたら良いか知りたい
・・・とお考えの方は、この機会にぜひご一読ください。
目次
１．ベンダーロックインとは
「ベンダーロックイン」とは、システム開発・保守の発注先が特定のベンダーに大きく依存してしまっており、他社ベンダーへの乗り換えが難しくなっている状態のことを指します。
特に、ベンダー独自の技術やソリューションを組み込んだ形でシステムを構築していると、ベンダーロックインに陥りやすくなる傾向にあります。
なお、ベンダーロックインには「コーポレートロックイン」と「テクノロジーロックイン」の2種類があります。
コーポレートロックイン
「コーポレートロックイン」とは、現行ベンダーに対する依存度が非常に高く、他社への移行が困難になっている状態のことです。
コーポレートロックインに陥ってしまう原因の1つとして、自社の事業や業務内容、業務に関するルール、システム内部の細かい仕様に至るまで、最もよく理解しているのがこれまで取引を続けてきた現行ベンダーだという事情があります。
仮に他社ベンダーへ乗り換えるとなると、自社の業務やシステムについて先方に改めて一から説明しなければならず手間やコストがかかるほか、元のベンダーと同じ水準まで理解度を深めてもらい、信頼関係を構築するにも長い期間が必要になります。
こうした膨大な移行コストが発生することを考えると、毎回同じベンダーに依頼するのが結局のところ望ましいという形に落ち着き、コーポレートロックインからなかなか抜け出すことができなくなってしまうのです。
テクノロジーロックイン
「テクノロジーロックイン」とは、ベンダー独自の開発手法や仕様によってシステムが構成されている関係で、他社への移行が困難になっている状態のことです。
現行ベンダーに縛られてしまう「コーポレートロックイン」とは異なり、技術面の制約が大きいために他社製品・サービスへ乗り換えられず雁字搦めになっている状態を指し、最悪の場合、一度使い始めた製品をずっと利用し続けなければならなくなる可能性もあります。
よくあるテクノロジーロックインに陥るケースとしては、次のようなものが挙げられます。
・Microsoft Edgeブラウザでないと正常に動作せず、Google ChromeやFirefoxでは使えない基幹システムがあり、リプレイスの選択肢が狭まっている
・あるメーカーが開発したアプリケーションの動作条件が、そのメーカーの機器を使用していることが前提となっており、別のアプリケーションに乗り換えできない
・独自の設計思想やデータの持ち方をしているパッケージ製品を導入しており、データの体系が移行先のシステムとは異なるため、データの変換や移行ができない
・独自仕様が原因で他クラウドサービスへの移行ができず、現在提携中のクラウド事業者によるランニングコストの急な増加やサービス停止の影響をもろに受けてしまった
２．ベンダーロックインが起きる要因
ベンダーロックインが発生してしまう要因としては、どのようなものがあるのでしょうか。ここでは、考えられる4つの原因をご紹介します。
設計書などのドキュメントが整備・最新化されていない
システムの設計書や仕様書など、ドキュメントがきちんと整備・最新化されていないと、ベンダーロックインに陥る可能性が高くなります。
IT技術者は設計書を読むことでシステムの仕様を理解しますが、肝心の設計書の内容に不備があり、実際に動いているプログラムソースと一致していなければ、正しく仕様を理解することができません。
こうなると、正確な仕様把握のために多くの工数を割かなけなければならず、移行コストが跳ね上がって、結果的に他社ベンダーへの乗り換えを諦めざるを得なくなる場合があります。
独自の技術・ソリューションが用いられている
導入したシステムに独自の技術が採用されている場合も、ベンダーロックインの状態になる可能性が高くなります。
独自技術を使用していると、その技術に精通しているIT技術者を確保するのが難しいため、他サービスやソリューションへ移行しにくくなるほか、仮に上手く新しいシステムへ乗り換えられたとしても、移行先のベンダーがその独自技術を理解するためには莫大な時間とコストが必要になります。
また、現行ベンダーが独自技術に関する特許を取得していた場合、その技術が含まれるシステムの開発・運用・保守は法律上他のベンダーに任せることができないため、取引は継続せざるを得なくなります。
このように、システムの特殊性や専門性が高まれば高まるほど、代替ベンダーを見つけるのが困難になり、ベンダーロックインに陥りやすくなるのです。
システムの著作権がベンダー側にある
システムの著作権をベンダー側が保持している場合も、ベンダーロックインに陥る可能性が高くなります。
著作権がベンダー側にある状態だと、開発者であるベンダーから許可を得ない限り、システムの改修やカスタマイズを行えないため、結果として既存システムに対する依存度が高まり、現行ベンダーとの取引終了のタイミングが掴みづらくなります。
契約期間や保守期間に縛りがある
現行ベンダーと取り交わしている契約内容が、他社製品・サービスへの切り替えに向けた足かせとなるケースもあります。
例えば、システム導入時にベンダーと2年間の保守契約を結んでいたとすると、2年以内に別の企業が提供するシステムに乗り換えたとしても、契約満了まではメンテナンス費を払い続けなければなりません。
契約満了を待たずに自社都合で保守契約を打ち切ると、場合によっては多額の違約金が発生する可能性もありますので、現在締結している契約書の内容は入念に確認しておく必要があります。
３．公正取引委員会によるベンダーロックインに関する調査結果
令和4（2022）年2月8日、公正取引委員会は官公庁におけるベンダーロックインに関する実態調査の結果を発表しました。
「官公庁における情報システム調達に関する実態調査報告書」によると、なんと全体の98.9％もの自治体が「既存ベンダーと再度契約することになった事例がある」と回答したことが分かりました。
なお、既存ベンダーと再契約した理由については、「既存ベンダーしか既存システムの機能の詳細を把握することができなかったため」と答えた自治体が48.3％と約半数近くにのぼっており、多くの自治体が「コーポレートロックイン」に悩まされている現状にあります。
４．AWSが定義するベンダーロックインの原因
AWS（Amazon Web Services）は、Amazon社が提供するクラウドコンピューティングサービスの総称であり、数あるクラウドサービスの中でも世界トップシェアを誇っています。
アメリカの調査会社Canalys（カナリス）によると、直近の2023年3Q時点におけるAWSのシェア率は全体の31%を占めており、2位のMicrosoft Azure（25%）や3位のGoogle Cloud Platform（10%）を抑え、今でも世界シェアNo.1の座を守り続けています。
世界でも圧倒的なユーザー数を誇るAWSですが、特定のクラウドサービスに依存して「テクノロジーロックイン」に陥ってしまうことを懸念している利用者に向けて、「ベンダーロックインを解きほぐしていくために」というホワイトペーパーを発行しています。
ホワイトペーパーでは、「ベンダーロックイン」について、
ベンダーロックインが存在する状態というのは、他社製品やサービスへ乗り換える際に発生するコスト＝「スイッチングコスト」が現実的な金額を超えた場合のことである
と定義しており、必ずしも「特定のクラウドサービスに依存している＝ベンダーロックインに陥っている」わけではなく、むしろすべてのユーザーが必要に応じていつでも任意の別のベンダーに変更できる状況にあるのが理想だ、というAWS側の考えが示されています。
５．ベンダーロックインの問題点
ここからは、企業がベンダーロックインに陥ってしまうとどんなデメリットがあるのか見ていきましょう。
開発・運用コストが高額になりやすい
ベンダーロックインに陥ってしまうと、今後のシステム改修や運用・保守における価格交渉のシーンで不利になり、高額な費用の負担を強いられる可能性があります。
特定のベンダーにしか依頼できないとなると、ベンダー側は競合相手が不在であるという状況を利用し、自分たちにとって有利な価格を提示するようになります。
顧客側は、提示された見積金額に納得がいかず、その妥当性について説明を求めたとしても、「どうしてもそれだけの金額がかかる」と強引に押し切られてしまえば、他に頼れる企業もないため、どんなに高額なプランだったとしてもその提案を受け入れざるを得なくなってしまうのです。
ベンダーの言いなりになりがち
ベンダーロックインによりベンダー側の立場が強くなり、顧客対応の品質が低下してしまう点もデメリットの1つです。
例えば、「コストを下げてほしい」「最新技術を取り入れてほしい」など、ベンダーにとって特にメリットの無い要望や、実現に向けて大量のリソースを必要とする要望については、競合相手がおらず顧客が他のベンダーへ容易に乗り換えられない状況にあるのをいいことに、のらりくらりと断られる可能性があります。
顧客側としては、「運用・保守コストを上げられる」「要求をなかなか満たしてくれない」など、ベンダー側の対応に明らかに問題があったとしても、簡単にはベンダーを変えられないため強くは抗議できず、結局は泣き寝入りしてベンダーの言いなりにならざるを得ないケースが多くなっています。
他社への移行が難しくなる
先述のように、「コーポレートロックイン」の場合は、他社ベンダーに乗り換えるとなると先方に改めて自社の事業や業務内容について説明をしなければならず、元のベンダーと同じ水準まで理解度を深めてもらうまで非常に長い期間を要します。
一方、「テクノロジーロックイン」の場合も、既存システムの独自仕様を正確に把握する必要があるため、移行時のコストがかさむ傾向にあります。
システムの規模やIT技術者の単価にもよりますが、1人の技術者が現行システムの仕様理解に約3ヶ月要する場合、調査費用は約300万～450万円程度になると言われています。
いずれにせよ、ベンダー切り替えに伴う移行作業には多くの手間やコストが発生することから、移行は困難だと判断されてしまいがちです。
レガシーシステムを使い続けなければならなくなる
ベンダーロックインに陥ると、新しいシステムへの切り替えが困難になることから、長期間同じシステムを使い続けなければならなくなる場合があります。
新しい技術が次々と世に生み出されるなか、リプレイスを行わずに長年同じシステムを使い続けていると、老朽化によっていつしか時代にそぐわない古いシステム＝「レガシーシステム」となり、運用コストの増加、属人化による業務効率の低下、新たな脅威に対するセキュリティリスクの増大といった問題が生じる可能性があります。
６．ベンダーロックインのメリット
ベンダーロックインにはデメリットばかりでなく、一部の企業にとってはプラスに働くケースも存在します。
その最たるものが、「自社の特性を把握している馴染みのベンダーは何かと頼りになる」ということです。
特定のベンダーと取引を続けていると、システムの細かい要件や仕様のほか、自社の事業や業務内容、経営課題についてもベンダー側に深く理解してもらえるようになります。
そのため、ベンダーに対して気軽に相談ができたり、融通が利きやすいという面ではメリットがありますが、特定のベンダーにすっかり頼りきりになって生じる問題も多いことから、やはりベンダーロックインは極力避けるべきとされています。
７．ベンダーロックインから脱却するための方法
最後に、企業がベンダーロックインの状態から抜け出すために実施すべきことをご紹介します。
ベンダーロックインに陥っている原因を明確にする
まずは、自社がベンダーロックインに陥っている原因を正確に把握することが重要です。
例えば、ドキュメントの未整備が原因の場合は、システム仕様書や設計書の更新が必要になりますし、ベンダーとの間に交わした契約期間や保守期間が原因の場合は、契約内容の見直しが必要になります。
原因の内容次第で自社の取るべき対応は異なるため、ベンダーロックインの原因を正確に把握することで、ベンダーロックインによって起こり得る問題やデメリットに対する適切な解決策を立案しやすくなります。
ドキュメントの整備・最新化を行う
ベンダーロックインの原因が仕様書や設計書といったドキュメントの未整備にある場合は、現行ベンダーにドキュメントの最新化を依頼しておきましょう。
仕様書や設計書が手元に無いと、移行について相談を受けた他社ベンダー側もシステムの仕様を正確に把握できず、既存システムの解析・分析を行ってシステム内部の構造や仕様を把握する「リバースエンジニアリング」が別途必要となり、さらにコストが膨れ上がることになります。
第三者がいつ見ても分かりやすい状態でドキュメントを整備しておき、ベンダーが変わってもドキュメントさえ渡せば問題なし、という状況にしておくことが理想です。
なお、ベンダーと保守契約を締結している場合、ドキュメントの更新はサービスの一部に含まれるため、追加コストが発生する心配はありません。
自社の社内規定を見直す
ベンダーロックインの原因が自社の社内規定にある場合は、既存ルールの定期的な見直し・是正が有効です。
社内規定の作成をベンダー、あるいはベンダーと同じ系列のコンサルティング会社に丸投げしてしまうと、ベンダーにとって都合の良いように社内規定が作られてしまうことがあり、結果としてベンダーロックインへとつながってしまいます。
自社の社内規定は自分たちで作成・見直しすることは大前提として、できればベンダーと独立した専門のコンサルティング会社のアドバイスを受けながら、定期的に既存規定の是正を図るのが最適解といえます。
ベンダー固有の技術・概念を極力使用しない
ベンダーが特許を取得している独自の技術を使用している場合、その技術が含まれるシステムの構築・運用・保守は現行ベンダーにしか任せられないため、当該システムが必要であり続ける限りベンダーロックインは回避できません。
移行に伴い代替可能な別の技術を有するベンダーを探すにしろ、その技術の独自性からベンダーの選定等に膨大な工数や手間がかかる可能性があり、一筋縄ではいかないでしょう。
システム構築の際は、極力特定のパッケージや固有のデータモデルなどの概念を採用しないことが重要です。
システムの著作権を自社に帰属させる
著作権は、著作物の創作と同時にその作成者に自動で付与される法律上の権利です。
システムの場合、特段の取り決めがなければそのシステムを開発したベンダー側に帰属することになります。
ただし、著作権法第61条の「著作権は、その全部または一部を譲渡できる」という記載から、ベンダーと合意のうえでシステムの著作権を自社に帰属させることもできます。
システムの著作権がベンダー側にあると、自社都合でシステム内のコードなどを勝手に改変できず不便なため、契約締結によって可能な限り著作権を自社側へ移転させておくと良いでしょう。
契約内容の見直しを図る
ベンダーとの間に締結している契約（随意契約期間、保守契約期間など）が原因でベンダーロックインに陥っており、契約満了を待たずにシステムの切り替えを行いたい場合は、現行ベンダーとの交渉が必要になります。
交渉をできるだけ有利に進める方法として、既存の契約を解約する代わりに新たな仕事を見繕うなど、相手にとってメリットのある提案を用意すると効果が高まります。
そのほか、あまりビジネス的にスマートな方法とは言えませんが、ベンダー側の契約不履行に該当する項目を見つけて、契約解消や賠償請求にこぎつける方法もあります。
ただし、基本的にはこのような事態が起こらないよう、あらかじめ途中解約の可否等についての条項を入念にチェックしておくことが重要です。
もし多額の違約金が発生してしまうようなら、システムの切り替えは既存契約の満了まで待ったほうが賢明かもしれません。
移行先ベンダーの選定を行う
ベンダーロックインから脱却するために他社ベンダーへの移行を検討している場合は、移行作業（マイグレーション）を得意とするベンダーを複数リストアップして、移行計画や実現可能性、費用などについて相談してみましょう。
この時、移行作業後のトラブルを回避するため、「他社の構築したシステムの運用が可能かどうか」を忘れずに確認するようにします。
技術力やコストも考慮しつつ、自社の要件に最も合うベンダーを選定しましょう。
社内に専任の担当者を配置する
ベンダーロックインの状況からマイグレーションを成功させるには、移行先のベンダーに自社の業務内容や既存システムの仕様・課題などをしっかりと理解してもらう必要があるため、かなりの期間を要することがほとんどです。
その際、社内でシステム管理の責任を持つ担当者を任命することで、新ベンダーとの仲介役・マイグレーションにかかる全工程の監督者として、移行プロセスの一貫性を維持しながら作業を進めることができます。
８．インフラ基盤の移行・再構築に関するご相談は、ぜひコンピュータマネジメントへ
いかがでしたでしょうか？
ベンダーロックインを解消するためには、まず自社がベンダーロックインに陥っている原因を正しく特定し、その原因に合わせて適切な対応を取ることが重要です。
他社への切り替えが難しく、DXの推進を阻む要因にもなりかねないベンダーロックインについて、ぜひ一度社内で既存ベンダーとの取引内容や現行システムの仕様に関する情報整理を行ってみてはいかがでしょうか。
なお、当社コンピュータマネジメントでは、「オンプレミスからAzureへの移行」「レンタルサーバーからAWSへの移行」など、EOL対応やセキュリティ対策に伴う基盤移行を手がけてきた確かな実績がございます。
ベンダーロックインからの脱却に伴い、インフラ基盤の移行や再構築をご検討されている企業様は、どうぞお気軽にお問い合わせください。
お電話・FAXでのお問い合わせはこちら
03-5828-7501
03-5830-2910
【受付時間】平日 9:00~18:00
フォームでのお問い合わせはこちら
この記事を書いた人
Y.M（マーケティング室）
2020年に株式会社コンピュータマネジメントに新卒入社。
CPサイトのリニューアルに携わりつつ、会社としては初のブログを創設した。
現在は「情シス支援」をテーマに、月3本ペースでブログ更新を継続中。
