永遠の課題「ベンダーロックイン」との付き合い方



 ついにクラウドでも「ベンダーロックイン」のリスクが、現実となりそうだ。最近、こう実感する出来事や意見を頻繁に聞くようになった。

 その一つが2017年4月に米VMWareが発表した、欧米のパブリッククラウド事業からの撤退だ。VMWareはパブリッククラウドサービス「VMware vCloud Air」をフランスの通信事業者に売却する。vCloud Airは日本から2017年3月に撤退済みで、日本の利用者は「まさか撤退するとは」と驚いていた。

 こうした出来事に加え、ここ3カ月くらいの間にクラウド関連の取材で「クラウドを積極的に活用したいとは思っている。しかしAmazon Web Services(AWS)の独自のサービスを使ってしまうと、AWSに囲いこまれてしまうのではないか」といった意見を頻繁に聞くようになった。

 こうした懸念は、AWSユーザーに限らず、米Microsoftの「Azure」や米Googleの「Google Cloud Platform」、米IBMの「Bluemix」など様々なクラウドのユーザーが抱えるようになっているのではないだろうか。

 特定の製品やサービスへの囲い込み、あるいはベンダーロックインが起こると、どのような問題が発生するのだろうか。最大の問題点は、情報システムを利用し続けるうえで、コストや技術の最適化が図れなくなることだ。

 利用中のサービスのサポート費用が急に値上がりしたり、競合ベンダーが全く異なる技術の製品やサービスを出したりしても、ベンダーロックインの状況だと、現状の製品やサービスを使い続けるしかない。その結果、システムの保守運用に想定上の費用がかかったり、競合企業と比べて古い技術を使い続けなければならなかったりする。

オープン化でも終わらなかったベンダーロックイン

 ベンダーロックインの問題はクラウドに始まったことではない。企業情報システムでは常に発生してきた。ITベンダーが技術的、あるいは契約で顧客を囲い込むのは必ずしも意図的ではないかもしれない。しかし結果的に、問題が発生してもすぐに顧客が「逃れられない」状態になっている。

 メインフレームやオフコンの時代は、ベンダーロックインが一般的だった。同じCOBOLで記述されたアプリケーションでも米IBM製メインフレーム向きのアプリケーションをNEC製メインフレームに移行するというのは現実的ではなかった。

 こうした問題を解消しようと1990年代後半、オープン化の波がやってきた。オープンシステムという名前の通り、どの製品ベンダーでも標準技術を採用し、当初はメインフレームやオフコンで生じていたベンダーロックインが終わるかのようにみえた。

 しかし、実際にはベンダーロックインが続いている。読者の皆様も実感しているのではないだろうか。



Related Post