情シス業務を進めて行く中で、外部の業者との協力体制は欠かせません。情シスが担当する全ての業務に、業者との協力体制が必要だと言っても過言ではありません。但し、そこには「ベンダーロックイン」という課題が付いて回ります。
本記事では、ベンダーロックインの定義、原因、リスクを明確にした上で、その回避戦略と対応方法を示します。
「今から、外部業者との協力体制を構築」「ベンダーロックインに陥りそう」「既に、ベンダーロックイン」の皆さんに、本記事が、役立つはずです。
注：情シスが協力を求める外部業者には、「ハードウェアメーカー」「OSベンダー」「SaaSベンダー」「クラウドサービス会社」「システムインテグレーター(SIer)」「ソフトウェア開発会社」「パッケージソフト開発会社」「ヘルプデスクサービス会社」等々、数え上げればきりがありませんが、本記事では、全て「ベンダー」と表記します。
ベンダーロックインとは？その原因と情シスへの影響
ベンダーロックインとは、「情シス業務に必要な製品、システム、サービスを、特定のベンダーに、過度に、依存する結果、そのベンダー以外では、業務が回らず、自社での業務遂行や他のベンダーが代替できない状況になること」を指します。
具体的には、「OSがWindowsから離れられない」から始まり、「基幹系にパッケージシステムを導入したが、保守費が高くても、他のシステムに乗り換えられない」、「オンプレミスでシステム開発を行い、開発ベンダーに運用も任せているが、ブラックボックス化している」というような状況を指します。
ここから、このベンダーロックイン発生のメカニズムを明らかにして、必要な対策の論理を組み立てます。
ベンダーロックインが発生する主な原因
「ベンダーロックインの原因は、ベンダーの協力が必要だから」と言っても、問題解決にはなりません。
もう一歩進めると、「どうしてベンダーの協力が必要なのか」「ベンダーの協力を受けると、全て、ベンダーロックインになるのか」「ベンダーロックインの原因は、発注側にあるのか、ベンダー側にあるのか」という疑問にたどり着きます。
どうして、ベンダーの協力が必要なのか
ベンダーの協力を必要とする理由には、以下が考えられます。
- 情シス要員の量的な人手不足
- 情シス要員の技術的側面での質的な人手不足
- 企業が必要とするベンダー独自の製品、システム、サービスの存在
ベンダーの協力を受けると、全て、ベンダーロックインになるのか
ベンダーからの協力を得ると、全て、ベンダーロックインとなるのでしょうか。実は、そうとは言えません。以下、ベンダーロックインになりにくいケースを示します。
- 短期的な人手不足を補うケース
- 標準化された技術分野を利用するケース
- 公開された情報技術を利用するケース
- 複数ベンダーで担当するケース
- 協力関係に適度な緊張感があるケース
これらの逆を考えてみると、ベンダーロックインに陥りやすいケースが浮かび上がってきます。
ベンダーロックインの原因は、発注側にあるのか、ベンダー側にあるのか
別の角度から、問題の起点について分析します。
量的人材不足や質的人材不足は、あきらかに発注側の問題です。一旦、ベンダーからの協力を得ると、「ベンダーを変更すると手間がかかる」「今のベンダーとは気心が知れている」という、精神的なものも、発注者側の理由です。また、特定のベンダーにしか提供できないような製品、システム、サービスの利用を望むことも発注側の理由です。とは言うものの、製品、システム、サービスの独自性は、ベンダーにとってのビジネス戦略であり、悪意があるものではありません。発注側が、そのことを十分に理解しておかなければいけないポイントです。
ここで、もうひとつ重要なポイントがあります。それは、悪意の有無にかかわらず、ベンダーが、その業務をブラックボックス化してしまうことです。例えば、業務システムの運用をベンダーに委託した場合、不具合が発生し、それを是正した時に、その対応策をログとして残さず、また、運用ドキュメントも整備されないままで、そのベンダーのみの経験値になってしまうということがあります。このロックインは、ベンダー起因です。
情シス担当者が直面するベンダーロックインのデメリット
ここまでに解説した背景によって、ベンダーロックインが起こるわけですが、そのデメリットには、どんなものがあるでしょうか。
- 費用の側面：コストコントロールの力が、ベンダーに偏り、コスト増大/コストの高止まりにつながる。
- 技術的側面：より効果的な他システムへの移行がスムーズに行えない。また、その影響として、DXが進められない等の競争力の低下に繋がる。加えて、ベンダーロックインが、外部に知られることで、他ベンダーから情報を得られなくなる。
- 組織/人的資源の側面：情シス内に経験や知識が蓄積されず、組織の成長や要員の成長の妨げになる。
- システム運用の側面：ブラックボックス化としての影響が発生する（緊急時の対応の遅滞、障害時対応としての未承認のシステム修正、ドキュメントの未整備、セキュリティリスクの増大、責任の不明確化、等）
- 経営的な側面：ベンダーの経営状況の悪化やサービス提供状況の変化により、利用システムやサービスの提供の中断や停止が起こり、結果的に、利用企業の事業継続に悪影響を及ぼす。
ベンダーロックインを「未然に防ぐ」ための戦略
ここまで、ベンダーロックインのメカニズムをみてきました。ここからは、新たなシステム導入や、既存システムの見直しの際に必要な、ベンダーロックイン予防策を解説します。
オープンスタンダード、汎用技術の積極的な採用
ベンダー固有技術ではなく、オープンスタンダードを利用することを優先してください。
オープンスタンダードは、「標準化団体で標準化され、仕様が公開されており、システム環境に非依存で、利用に制限が無いもの」と定義することができます。つまり、オープンスタンダードを利用することにより、特定のベンダーによる囲い込みを避けることができるのです。
また、いろいろなシステムに利用できる「汎用技術」の導入も、特定のベンダーに偏らないための方法です。
但し、オープンスタンダードや汎用技術を選定したとしても、その運用を1社に任せると、ベンダーロックインにつながりますので、注意が必要です。
マルチベンダー戦略の推進
マルチベンダー戦略には2種類あります。
ひとつは、コンポーネントごとにベンダーを分ける方法です。これにより、コンポーネントごとのベンダー変更が容易になります。また、コンポーネント間のインターフェースについての仕様が明確にされるため、ブラックボックス化を避けることができます。
但し、責任の境界が不明確になりますので、全体を管理する役割が必要です。
もうひとつの、マルチベンダー戦略は、ひとつのコンポーネントを2社以上に委託し、代替機能を持たせるものです。
これにより、コストのコントロールが効きやすくなりますし、緊急時対応も容易になります。
但し、二重投資になり、絶対額は上昇しますので、適用分野は限られます。
契約時の徹底した条件交渉
ベンダーロックインを防止するためには、契約時に以下のポイントをおさえて交渉する必要があります。
- SLA（Service Level Agreement：サービスレベルの定義とその合意）、成果物、報告体系
- 契約期間、更新条件、解除方法
- 契約満了/解除時の移行支援
- 価格、条件、および、その見直しタイミング
- 人材、ノウハウの依存回避策
- 権利帰属（著作権、利用許諾権、再利用許諾権、所有権等）
- 発注者による監査
情報システムのドキュメント整備と標準化
ベンダーとの契約には、SLAや成果物の内容を明記する必要がありますが、ハードウェア/OSの設定情報、業務システムの開発/運用ドキュメントを、自社で準備するか、委託業務の成果物の一部として契約するかも、明記すべきです。それらのドキュメントによって、業務の標準化が進み、ベンダーロックインの防止になります。
既存のベンダーロックインから「脱却する」ための実践方法
次に、ベンダーロックインに陥っている場合に、段階的に脱却するための具体的なステップを解説します。
現状把握と原因の特定
まず、ベンダーロックインの状況と、その原因を特定します。
ロックインの状況は、「どんなデメリットが現れているか」、原因は、「なぜ、ベンダーの協力が必要だったのか」というように、前章までの内容を参考にして、考え始めると、論理的に進めることができます。
ロードマップの策定と段階的な移行計画
次期システムへの移行のロードマップを策定します。これは、ベンダーロックインからの脱却が主目的ではありませんが、事業拡大、DXというような主目的と並行して、「次期システムではベンダーロックインは起きないか」とチェックすることが大事です。
社内IT人材の育成とナレッジの蓄積
「要員不足だから、ベンダーに依存する」「知見不足だから、ベンダーに頼る」という結果が、ベンダーロックインにつながるのですが、ここで、提案する、「社内人材の育成とナレッジの蓄積」との間には、明らかに矛盾があります。しかし、その矛盾を乗り越えて、情シス内に知見を蓄積することは、将来の適切な外注管理のためには、必須です。
方法としては、「ベンダーに丸投げ」ではなく、「関与する」ことです。詳細な技術の蓄積には、たどり着かないかもしれませんが、「何が、どのように、実行されているか」のナレッジは蓄積できるはずです。
経営層の理解とコミットメントの獲得
「次期システムへのロードマップ」「情シスの人材育成とナレッジの蓄積」は、経営層の理解とサポートが必要です。情報システムの事業への貢献点を経営層と協議するとともに、経営層のベンダーロックイン防止に対する理解と支援に対するコミットメントを得るようにしましょう。
成功事例から学ぶベンダーロックイン回避のヒント
最後に、ベンダーロックインからの脱却に成功した企業や、予防策を講じている企業の事例をふたつ紹介します。
事例1：レガシーシステムからの脱却とクラウド移行
A社は、正社員と契約社員の営業担当者100名を抱える、中堅食品メーカーです。日々の営業活動を報告するシステムを、15年前にW社に依頼して開発し、運用も任せていました。しかし、W社の担当者が、突然、転職してしまい、引継ぎもされず、ドキュメントも残さないままだったため、たちまち、システム運用に支障が出るようになりました。
A社は、これを機に、BPRを行い、必須機能を抽出した後、それが可能となるSaaSを5つ選んだ上で、RFPをもとにした入札で、B社のSaaSを採用しましたが、その際の契約書には、「使用料の変更は、3年毎の協議とすること」「3年ごとに、契約の見直しを行い、競争入札を行うこと」「他システムへの移行のためのデータを、B社が無償で準備すること」を明記しました。
これにより、ベンダーロックインを避けることはできましたが、3年に1度の「RFP大会」には、情シス部門の大きな労力が必要です。
事例2：マルチベンダー戦略によるコスト削減と柔軟性向上
C社は、ベーカリーショップをチェーン展開する中堅企業です。在庫管理、POS、販売データ分析を、全て同一ベンダーのパッケージに依存しており、年額保守料の値上げが続いていました。また、チェーン店数拡大を計画していましたが、それについても、「機能追加が必要となる」と、高額な見積りが出されていました。
検討の結果、C社は、在庫管理をX社、POSをY社、販売管理をZ社のシステムにリプレースすることにしました。また、それらの間のデータインターフェースはAPIを公開し、そのAPIに準拠さえできれば、どのシステムでも対応できるように設計しました。
その結果、ベンダーロックインからの脱却と、今後のベンダーロックインの防止が同時に行えることになり、初期導入に投資が発生したものの、運用費を大幅に下げることができ、5年で投資を回収することに成功しました。
留意点としては、障害発生時に、情シス要員がAPIを境界として、責任の切り分けを行う必要があることです。
まとめ
ベンダー各社との協力関係の基礎には、信頼関係が必要であり、そこから築かれる関係はWin-Winでなければなりません。ベンダーロックインは、Loose-Winだと言えます。
本記事で紹介した、ベンダーロックインの原因とその防止策や解消策は、Win-Winを前提としています。この前提は、はずさないようにしたいものです。