ユーザーが「ベンダーロックイン」を恐れる本当の理由
吉田：ありがとうございました。改めて各社のサービスの内容を聞き比べてみると、PaaSといっても、いろんなパターンがあるのだなと思います。さて、最初のテーマとして「ベンダーロックイン」を各ベンダーは、どう捉えているかについて、ご意見を伺いたいと思います。
私見なのですが、個人的には「なんでそんなにみんな、ベンダーロックインが嫌いなのかなぁ」と感じていまして。
一同：（笑）
吉田：個人的には、ロックインされることは「必ずしも悪いことじゃない」という意見を持っています。というのは、ある結果を「楽に出したい」と思ってサービスを契約するわけで、そのお付き合いの結果として、そのベンダーさんと仲良くなったというのは決して悪いことじゃないと思うんですね。
セミナーなどで、ベンダーロックインについて否定的な立場で意見を言われる方の状況を察するに、販売会社の説明不足などから「支払う金額に対する納得感がなかった」というような不幸なケースも多いように感じています。
TIS：そういうユーザーさんは、もしかするとオンプレミス全盛の時代に、嫌な思いをした経験があるのかもしれませんね。あるシステムが高く付いて仕方がないので、もうやめて、より合理的な新しいものに移りたいのに、実装が特定の環境に「どっぷり漬かっている」ためにそれができないというような状況が過去にあったとすれば、それも仕方ないのかもしれません。
IIJ：私も、個人的にはベンダーロックインが必ずしも悪いことだとは思っていません。承知の上で「心地よくロックインされる」という状況もあるという立場です。
ただ、IIJのクラウドでは、ロックインするような独自の実装はしないということを念頭においています。アプリケーションのポータビリティを重視した実装を心がけており、お客様がお持ちのアプリ資産をわれわれのサービス上で動かすにあたっては、改修を必要としないような環境を提供するようにしています。
また、ユーザーとしても、本当にロックインされることを避けたいと考えているのであれば、ベンダーに依存しない、オープンでスタンダードな実装方法を考えて、実行していく必要があるだろうと思います。
Engine Yard：クラウドサービスの利用者の中には「心地よくロックインされる」という状況を実際に見ることもあることから、個人的には、必ずしもロックインを悪しきものとして過剰に忌避するものではないとは思っています。
一方で、Engine Yardの利用を検討しているユーザーから「特定のIaaSやPaaSの仕組みでのロックインは避けたいと考えているが、他のインフラやプラットフォームへのポータビリティー性はあるか」というお問い合わせをいただくこともあります。まず、このお問い合わせの回答としては「Yes」ですが、このようなお問い合わせの背景には、特にオープンソーステクノロジーを好むユーザー層が、Engine YardのPaaSを検討してくださるケースが多いためであると思います。また、それ以外の背景としては、クラウドではサービスのスケールに応じてリソースの拡大も縮小も容易であり、規模が一定のレベルを超えた段階でコスト面やメンテナンス性やサービスレベルを鑑みて、アプリケーション環境を自社データセンターなどに移行可能なポータビリティー性を求めるケースがあるからだと考えています。
また、Engine Yardとしては、創業当時からオープンソーステクノロジーに貢献していることもあり、基本的に「ベンダーロックインを良しとはしない」という考え方を持っています。その方針に基づき、Engine Yardは先進的なオープンソーステクノロジーを疎結合に組み合わせて開発したオープンな設計のPaaSを提供しています。
そして、ロックインを避けるための思想として、プラットフォーム層のDBサーバーやAPサーバーを含む各種コンポーネントも複数の選択幅を持っていることや、Chefの仕組みを用いてユーザーがプラットフォームを比較的自由にカスタマイズできるよう設計・構築されています。また、インフラ層は主要なベンダーが提供する複数のIaaS群に加え、近い将来にOpenStackやCloudStackに対応したPaaSを提供することでインフラのロックインも、より一層回避できるようになります。さらに、Engine Yardでデプロイしたアプリケーション環境を、他のIaaSで構築されたEngine YardのPaaS上に容易に移行できるポータビリティー性をも実現させるべく、鋭意開発を進めています。
Salesforce.com：「ベンダーロックイン」がなぜ嫌われているかの背景として個人的に思っていることがあります。「クラウドを使いたい」と相談されてくるお客さんの中には「今、動いているものをそのまま移したい」という考えが、まだ少なからずあるような気がしているのです。80年代にも、オフコンからオープンシステムに「今動いているシステムを移したい」という考え方はあったと思うのですが、そこには、過去に投資をして償却がすんでいない資産には「今後も価値がある」と思い続けたいという考え方があったのではないかと思っています。
Salesforce.comは、クラウドだけで13年近くビジネスを展開していますが、お客様が「クラウドを導入しよう」と思う場合には、単に今動いているシステムのお守りをIaaS上でするだけではなくて、ビジネスの仕組みそのものや、それに付随するシステムも、その時代にあったものに変えていく必要性を感じているケースが多いと思います。その場合、システムの可搬性だけをひたすら担保していても、あまり意味はないような気がしています。せっかくクラウドを使うのであれば、業務を中心に考えて、システムもより業務改善や生産性の向上ににつなげやすい、モダンなものに変えていくべきでしょう。業務の改善を、今よりも高いレベルで実現していきたいと考えているお客様のニーズには、すでにあるフレームワークに忠実に準拠するだけでは、応えられない。その視点で作り上げられてきたのが、Salesforce.comのサービスだと思っています。
Force.comは、ベンダーロックインされるかされないかで言えば、「される」部分のあるサービスだと思います。しかし、だからこそ、ロックインしないことを最重要視しているサービスよりも、より高度なシステムやサービスを提供できるという面もあるわけで、そこはトレードオフになるのではないでしょうか。ユーザーとしては、必要以上にベンダーロックインを恐れるよりも、クラウドを使うことで、どのようにイノベーションを起こしていくかに目を向けてほしいと思います。今行われている業務の内容に応じて、ベンダーロックインを完全に避けるか、部分的に受け入れるかを切り分けて考えるというやり方もあるのではないでしょうか。
NTTCom：ユーザーさんがなぜ極端に「ベンダーロックイン」を嫌うのかについての意見は、これまでのみなさんとおおむね一緒です。企業におけるPaaSの採用という点では、現場の担当者やスタートアップ企業は気軽に利用してくれるのですが、なかなかその先の本格的な採用につながっていかないという印象があり、それはどうしてなんだろうと考えることがあります。いろいろな状況からの推測になりますが、恐らくインフラの選択担当者が、PaaSのリスクを過大に評価して、一歩踏み出せないケースも多いようだと感じています。
そうした状況に対して、われわれは「選択肢」を提供しようと考えています。まず、アプリケーションのアーキテクチャについては、最大限オープンなものを提供し、ロックインを避けようと思っています。使える言語の選択肢も多く用意していますし、Cloud Foundryベースなので、万が一たまたま選んだサービスの品質が納得いかないものだった場合には、同じCloud Foundry同士であれば、デプロイツールの設定だけで、いつでも乗り換えができるという意味での選択肢も用意しています。
ただ、そのような選択肢で互換性を担保できるレベルのアプリケーションだけというわけではないというのも現実です。その点で、一歩踏み込んだお客様に対しては、より高いセキュリティレベル、より高品質なインフラを提供して「心地よいロックイン」を図りたいと考えています。どちらのケースでも対応できるようにしたいというのが、われわれのアプローチです。
ニフティ：ベンダーロックインに対する考え方は、これまでのみなさんとほぼ同意見で、だんだんということがなくなってきているのですが（笑）。どちらかと言えば「ロックインしているからこそセキュリティを保証し、サービスレベルを高められる」という側面もあるわけで、私も個人的にロックインが必ずしも悪いことだとは思っていません。それは、どのような用途にPaaSを使うかによっても、評価が変わってくるところでしょう。
別の視点で、各社のPaaSを使ってみて思ったのは、例えば特定のサービスの「ユーザーインターフェース」に慣れてしまうと、別のサービスが使いづらくなるということはあるかもしれません。そういう要素が、ユーザビリティを規定してしまうという側面もあるのではないでしょうか。
日本IBM：IBMは基本的に「オープンなほうがいい」と思っています。ただこれまで、堅牢さや使いやすさといった要素が「プロプライエタリ」であることとセットな場合が多かったんですね。「堅牢でないオープン」と「堅牢なプロプライエタリ」とどっちがいいかという究極の選択を、企業のIT部門はこれまで突きつけられていたという側面はあると思います。それが進むと「プロプライエタリで動けなくなってしまうと困る。では、自社で堅牢なPaaSを作ろう」といった選択を行うところまでいってしまうんです。
しかしそうなると、API、GUI、実行環境など、自社のビジネスに関係ないところまでユーザーが手がけなければならなくなる。これは、コストやワークロード的に見合わないので失敗するケースが多いんですね。すると、IaaSどまりでPaaSまで進むことができず、ビジネスのスピード感が上がっていかないというジレンマが出てきます。結果的に「オープンで使いやすく、なおかつ堅牢性を兼ね備えているのであれば、オープンなほうがいい」という結論になっているわけです。
オープンであることが求められるもう一つの理由として、サービスには「ライフサイクル」があるという点が挙げられます。スモールスタートで始めたサービスが成長してくれば、SLAの要件も変わってきます。また、将来的にセンシティブなデータを扱うようになったり、海外の拠点で展開したいといったさまざまな要因で、システム自体を移動させたいという要望が出る可能性があるわけです。「現時点ではどうなるか分からないが、とりあえず動かせるようにしておきたい」というニーズはあるでしょう。また、大企業の場合は外部を大規模に動かすことから、社内に移動させたほうがコストメリットが生まれる場合も出てきます。その意味でも、PaaSのオープン性やポータビリティに対するユーザーの要求は合理的なものだと思っています。
IIJ：ベンダーロックインにもレイヤの違いがありますよね。ビジネスプロセスまで行くと、人にロックインされるというケースもあると思います。ただ、インフラや開発環境については、基本的にオープンなプラットフォームが主流で、一世代前のようなハードウェアやOSなどにロックインされるようなものではなくなっていますよね。
現状、PaaSベンダーが競争する中で、差別化として打ち出している「付加価値」にロックインされていくことはあると思います。ただ、それはかつてのようにロックインしたベンダーが、それを根拠に値段を釣り上げていくようなロックインにはなり得ないので、決して悪いことではないだろうと思います。
ほかの要素として「データ量」によるロックインというのはあります。あるベンダーの仕組みの中で運用しているデータ量が増えていくと、いくら仕組み上はポータビリティが確保されていても、現実的には別のベンダーに移ることは難しくなります。IaaSでは特にその傾向が強いのですが、PaaSにおいても今後はそこがロックインのポイントになってくるのではないでしょうか。
マイクロソフト：「オープンかどうか」という観点では、先ほども少しお話しがありましたが「オープンスタンダード」と「オープンソース」が混同されているというのはあると思います。マイクロソフトは、基本的にはプロプライエタリな会社ですが、採用されたオープンスタンダードについては、できる限り準拠していくということをやっています。システム構成全体のポータビリティについては、まだまだ未成熟な部分も多いのですが、引き続き改善を続けています。
マイクロソフトのこれまでのコアビジネスは、Windowsをはじめとしたプロプライエタリなソフトウェアの販売です。なので基本的には、マイクロソフトのエコシステムの中で、ユーザーを気持ちよくロックインしていきたいという立場をとっています。これまで、オンプレミスのマイクロソフトスタックで動いていたシステムは、そのままWindows Azure上で動くこと目指していますし、Windows上でサポートされているフレームワークについては、オープンソースであっても、そのままWindows Azure上で動くよう全力でサポートしていきます。その点で、アプリケーションコードのポータビリティという点では問題ないレベルにきていると考えています。
吉田：みなさんのお話しを聞いていて気づいたのですが、「ロックイン」という意味では、組織の中で、システムの運用や開発をしている人に、システムそのものがロックインしているケースがそもそも多いのではないでしょうか。ユーザーは、「ロックイン」が外部のベンダーによって発生するものではなく、自社の中でも起き得ることだというのを意識する必要がありますよね。その場合はむしろ、ベンダーロックインを過剰に恐れるのではなく、外部のサービスを利用することで標準化が進み、より風通しの良い運用が確保できるということも、考慮してほしいと思います。
（後編につづく）
