ベンダーロックインを脱却する

特定ベンダーへの依存が深まると、乗り換えたくても動けない状況に陥ります。そこから抜け出す考え方と、第三者保守が果たす役割をまとめました。

ベンダーロックインとは

システムの保守・開発を特定のベンダーに依存し続けざるを得ない状態が「ベンダーロックイン」です。依存の中身と、構造的な問題を押さえておく必要があります。

特定ベンダーへの依存が強くなり、切り替えにくくなる状態

ベンダーロックインとは、情報システムなどの中核部分に特定の企業の製品やサービスを組み込んだ構成にすることで、他社製品への切り替えが困難になる状態です。「コーポレートロックイン」と「テクノロジーロックイン」の2種類があります。

コーポレートロックインとは、契約面や人的な関係性によって生じるもので、ベンダーのみが業務・システムを理解している属人的な状況が原因。テクノロジーロックインとは、ベンダー独自のプログラミング言語やフレームワーク、データベースなどが原因となり、システム移行を困難にするものです。

公正取引委員会が2022年に発表した調査によると、98.9％の自治体が既存ベンダーと再度契約することになったと回答しており、48.3％がその理由として既存ベンダーしか既存システムの機能の詳細を把握できなかったためと答えています。^※

本質は移行を難しくするスイッチングコストにある

ベンダーロックインが存在する状態は、他社製品やサービスへ乗り換える際に発生するコスト、すなわちスイッチングコストが現実的な金額を超える場合。特定ベンダーを使っていること自体がロックインではなく、「離れられない構造」になっていることが問題の本質です。

一旦ロックイン状態に陥ると、ベンダー側が製品やサービスを値上げしてもしぶしぶ購入を継続せざるを得なくなり、他社製品を基盤とするシステムへ乗り換えようとしても莫大な再開発コストがかかってしまうことになります。

ベンダーロックインが起こる主な理由

ロックインは意図せず起こるケースがほとんどです。情報・技術・タイミングという3つの切り口から、発生の構造を把握しておきましょう。

データや運用ノウハウが一社に集中している

コーポレートロックインの根底にある原因は「情報の偏在」です。情報システムの開発・構築を曖昧な仕様でベンダーに発注すると、出来上がった情報システムの正確な仕様が、そのベンダーにしか分からなくなるケースがあります。

システムの保守・拡張・改修の際には、現存システムを開発・構築したベンダーに引き続き発注せざるを得なくなるベンダーロックインの状態に。設計書・仕様書といったドキュメントが整備されていないと、別のベンダーに移行を相談しても、まずリバースエンジニアリングから始める必要があります。コストも期間もその分だけさらに増加するでしょう。

運用ノウハウが属人的に蓄積されている場合も同様です。担当者が去れば情報ごと失われるリスクがあります。

独自仕様の製品や構成に依存している

テクノロジーロックインの大きな原因は、導入当初から独自技術に依存した設計を選んでいることにあります。独自技術を使用し、市場でのシェアが低いパッケージソフトやクラウドサービスを導入すると、その技術者を確保するのは困難です。他サービスやソリューションに移行しにくくなります。

たとえば、クラウドプロバイダー固有のAPIをシステム全体に組み込んでいると、別のプロバイダーへの移行には大規模な再開発が避けられません。長期間にわたり特定ベンダーの製品を利用している間に、機能追加やカスタマイズを繰り返してシステムは複雑化。

製品の老朽化により刷新が必要になった際には、別のベンダーで同等の機能を実現するのに多額のコストと手間がかかることになるのです。

保守終了が更新圧力として働いてしまう

メーカーの保守期間終了（EOSL）が、更新を迫る圧力として機能する点も見逃せません。一般的に、IT製品に対するメーカーのサポート期間は、販売終了から約5～7年程度に設定されています。この期限が近づくと、現行ベンダーは後継製品への乗り換えを提案します。ユーザー企業は、既存環境を維持しながら別の選択肢を比較・検討する時間が十分に取れないまま次のシステムへ移行することになりがちです。

サポート体制への過度の依存は、特定のベンダーのサポートやノウハウに頼りすぎることになり、そのベンダーなしでは業務が立ち行かなくなる状況に陥るリスクにもなります。つまり、保守終了というタイムリミットがベンダー側に有利な交渉環境をつくり出す構造があります。

ベンダーロックインから脱却するための考え方

脱却には、一気に解決しようとするのではなく、依存の全体像を把握したうえで段階的に取り組む視点が求められます。

まず依存の中身を分解する

何にロックインされているかを整理することが、脱却の出発点です。技術的な依存（独自API・データ形式・プログラミング言語）なのか、情報的な依存（ドキュメント未整備・属人化）なのか、契約的な依存（長期契約・高額違約金）なのかによって対処の方向が変わります。

ベンダーロックインが発生する要因は、大きく分けて契約的なもの（コーポレートロックイン）と技術的なもの（テクノロジーロックイン）の2種類です。契約的な要因には長期契約の締結や高額な違約金の設定などが挙げられ、技術的な要因には独自の技術や規格の採用、システムの複雑化やデータ移行の困難さなどが含まれます。

依存の種類を明確にしないまま動くと、コストと工数をかけた割に状況が変わらない、という結果になりやすいため、まず現状の棚卸しが重要です。

一気に全面刷新しようとしない

ベンダーロックインの解消を全面刷新で一気に対処しようとすると、かえってリスクと費用が膨らむことになりかねません。

ベンダーロックインの状況からマイグレーションするためには、かなりの期間を要します。マイグレーションベンダーへ自社の業務や現システムの現状と課題などをしっかりと理解してもらい、適切なマイグレーションを行う必要があります。

現実的なアプローチは、業務への影響が少ないシステムや、標準的な技術に置き換えやすい部分から着手し、段階的に依存度を下げていくやり方です。現行環境を完全に止めることなく移行できるよう、並行稼働の期間を設ける計画も有効です。スコープを絞り込むほど、リスクをコントロールしやすくなります。

オープン標準と移行性を重視する

次のシステムを選定する段階では、将来の移行しやすさを選定基準の一つにするのがポイントです。仕様が公開され、あるいは標準化された規格に基づいており、複数の実用的選択肢が提供されている技術や製品（オープンアーキテクチャ）を組み合わせてシステムを構成すれば、ある程度ベンダーロックインを回避することができます。

APIを構築する際には、OAuth2.0などの国際標準規格に準じて構築したりデータは一般的に利用されることの多いSQL DBなどのデータベースを採用したりするのがコツ。アプリケーションの領域でも、JavaやPythonなどのシェアの高いプログラミング言語を採用するとよいでしょう。

特定ベンダーの独自機能に依存しない構成を意識することで、将来の乗り換えコストを抑えた設計が可能になります。

第三者保守はベンダーロックイン脱却にどう関わるのか

第三者保守は、ベンダーロックインを直接的に解消するサービスではありません。しかし、脱却のための時間と計画の余地を確保するうえで、有効な手段になり得ます。

更新を急がず、検討時間を確保しやすくなる

ベンダーロックインが深刻になる場面の一つは、メーカー保守終了というタイムリミットを目の前にして、十分な検討時間が取れないまま後継システムを選ばざるを得ないときです。

第三者保守サービスを活用することで、EOSLを理由に急いでリプレイスを進める必要がなくなり、自社の計画に合わせた保守期間の延長ができます。

時間的な余裕は、そのまま交渉の余地となるでしょう。

ただし万能ではなく、適用範囲の確認が必要

第三者保守は、延命手段としては有効ですが、対応できる範囲に制限があります。

第三者保守は基本的にハードウェア保守に特化しているため、ソフトウェアのセキュリティパッチ提供やバージョンアップ対応は含まれないのが一般的です。古い機種では契約できない場合があったり、契約が1年などの期間限定となったり、一部の部品が保守対象外とされたりする場合もあります。

第三者保守の導入にあたっては、対象機器の型番・対応範囲・契約期間の上限を事前に確認し、移行計画の全体スケジュールと照らし合わせて丁寧に判断することが欠かせません。