どこまで「オープン」なら、ユーザーは安心できるのか
吉田（モデレーター）：日本では、クラウド利用者に対して国として強くコミットしていると個人的に感じています。例えば、経済産業省からは「クラウドセキュリティガイドライン」というものが出ています。また、ISOなどの国際的な委員会などでも日本は非常に発言力を持って、海外の方々と議論を行っているように感じています。
IaaSであれば、ホワイトペーパーなどによる情報開示が重要になってきます。自分で作ったネットワークではないので、事業者からある程度情報開示がされていなければ不安であるというのはもっともだと思います。その範囲は、データセンターがどういったファシリティや設計思想を持っているのかといったことで、それが自分たちが利用しているデータセンターより優れたものであることが分かれば、納得感があるはずです。セキュリティやシステム全体を任せるというという点で「分からない」ということがユーザーに引き起こす「不安」というのは大きいのではないかと思います。
より抽象度が上がっているPaaSのレイヤになると、そうしたシステム全体の「透明性」が、さらに重要になってくるはずです。例えば、どうしても避けられない「障害」が起きた場合、どのような情報開示を行うのか。会員限定にするのか、完全に公にするのかといったところも含めて「透明性」のレベルの問題でしょう。
そこで、ざっくばらんに、こうした「ユーザーに対する情報開示」について、各社がどのようなお考えをお持ちか聞かせていただければと思います。
TIS：eXcaleでは、基本的に中身、実装面を含めて必要であれば可能な限り公開しようと思っています。それはプラットフォームのソフトウェアだけでなく、どのような場所で動かしているか、どのようにセキュリティや冗長性を担保しているかといったところも含めてです。そう考える理由は、いちエンジニアとして、自分自身が「ソースコードが公開されていないものを使うのは信用できない」と感じているからということもあります。ユーザーから信頼を得るためにも求められるものに関しては可能な限り公開していき、常にオープンでありたいと考えています。したがって、我々のスタンスとしてはエンジニアの方など中身にも興味がある人向けにそういった情報を公開しつつも、サービスとしてはユーザがそういったことを意識する必要なく、あまり詳しくない方でも簡単に使えるようにということに重点を置いています。
IIJ：その点については、私たちは別の考えを持っています。PaaSはインフラなどの内部実装が抽象化されています。私たちはPaaSの内部に対して必要に応じてブラッシュアップや設備更新を常時行っていますが、それらを利用者の方々が意識することはありません。もちろん、安心して利用していただくために、私たちが取得している公的認証などはバックグラウンド情報として出しています。しかし、アーキテクチャレベルの情報は必ずしも出す必要はないのではないかと。
アーキテクチャレベルでの情報開示というのが問題になるのは、利用者側の意識がまだPaaSまで抽象化されていないからではないでしょうか。日本のプログラマーの方などを見ていると、インフラレベルに対する知識や思い入れが強い方が多いような気がします。そうした方々にとっては、自分たちの「共通言語」まで抽象度が下がっていないと、十分に納得できないということも多いようです。 これからはPaaSユーザーの意識は、より上のレイヤに向けてほしいと考えており、そのために、私たち企業やサービスの信頼感の向上に務めたいと考えています。
ニフティ：うちも、セキュリティレベルやホワイトペーパーなどは出していますが、インフラレベルの詳細な情報については公開していませんね。やろうと思えばできることなんですが、そのレベルの情報を公開することで、利用するユーザーの満足度が大きく変わるかどうかは分からないと思っています。もちろん、アプリケーションの動作レベルに関わるものや、発生した障害の情報については積極的に公開を行っています。
あと、先ほどIIJの土岐田さんが「共通言語」というお話しをされていたのですが、たしかにそれはあると思います。ニフティではIaaSの「ニフティクラウド」と、PaaSの「ニフティクラウド C4SA」を提供していますが、特にIaaSのお客様については、何か障害が起こったときには「インフラのレベルで何が起こっているのか」つまり、お客様の得意とするレベルで説明してもらいたいとおっしゃる方が多いですね。一方でニフティクラウド C4SAのお客様は、より上のプラットフォームやデータベースのレベルで何が起こっているのかを詳しく聞かれたいケースが多いようです。お客様により納得感を持っていただくためにも、提供しているサービスの内容によって、情報開示の内容や方法を変えていく必要があるだろうと思っています。
Salesforce.com：今でこそ一般的になりましたが、サーバインスタンスごとに細かくクラウドサービスの稼働状況に関する情報をリアルタイムに公開したのは、恐らくSalesforce.comが初めてだったのではないかと思います。過去30日の間に、サーバインスタンスが正常に動いていたか、パフォーマンスはどうだったか、問題が発生した場合はどこに問題があったか、その原因は何かといった情報については、すべてWebサイト上で公開しています。
一方で、その問題箇所のソースコードの書き方や再帰処理がどうかとかいう情報は、知りたいギークはいるかもしれませんが、出したところで大多数のユーザーにはあまり利点がないのかなとも思います。サービスという観点であれば、停止した場合の事実やその原因がどこにあったのかといった、すでに公開しているレベルの情報が、最も適切だと考えています。
先ほど「PaaSにおける情報開示のレベルが変わっていってもいい」というお話しがあり、ちょっと考えたことがあります。「ベンダーロックイン」の話に戻るのですが、PaaSの時代では、プログラムの可搬性・オープン性といった部分よりも、その中で運用している「データ」の可搬性があるかないかが「ロックイン」の基準になるんじゃないかと思います。
実際にPaaSを活用する中で出てくるニーズとして、クラウドサービスを既存システムや他のクラウドと繋いで、データをうまく連携して活用したいというものがあります。その際には「API」がオープンスタンダードに準拠した、使いやすいものになっていることが重要です。もし、それが独自の方式で縛られてしまい、容易にデータ活用ができないということであれば、それがPaaSの時代における「ベンダーロックイン」なのではないかと。そう考えると、クラウド時代にはそれぞれのレイヤでの新たな「ロックイン」の定義があっていいのではないかという気がしました。
日本IBM：「オープン」であることについて、ソースコードの開示はたしかに重要なんですが、一般のユーザーにしてみれば、ソースコードを見たところで意味は分からないですし、何もできないですよね。また、ソースコードが分かる人にとっても、ソース自体はインプリメンテーションでしかないので、将来変わらない保証は何もないわけです。その意味では、今お話しがあったAPIや、システムのデザイン、アーキテクチャがオープンであることのほうがより重要だと思います。
PaaSのいいところは、インフラ部分を隠蔽していることですが、その隠蔽をどのレベルでやっていくかが大切ですね。Cloud Foundryのようにビルドパックを作り、ランタイムやサービスといったレベルでインターフェースを提供して使ってもらうものもあると思います。また、OASIS TOSCAのように、例えば「スケーラビリティ」についてはデクラレイティブに条件を提供すれば、ユーザーがどこまででも自分で把握できるような環境を提供するものもあるでしょう。これらは、用途によって使い分けられるべきものです。IBMとしては、抽象度の高いものと低いものの両方をサポートし、適材適所で連携させることが重要だろうと思っています。
NTTCom：うちはCloud Foundryなので、ソースコード、APIの仕様などについては、すべてオープンになっており、必要であれば自由に参照できます。データセンターやファシリティの詳細については、現在原則非公開です。障害情報については、お客様に対してのみ公開しています。
ただ、この開示方法が最も適切かと聞かれれば、必ずしもそうではないと思います。その点でも、われわれはお客様に「選択肢」を与えたいと考えています。今は「Cloudn」というブランドのサービスレベル水準に従ってやっているのですが、VPNを経由したオンプレミスとの連携などを考えた場合、PaaS側はインフラ非公開というわけにもいきません。われわれのPaaSは、IaaSに依存しない形で作っていますので、将来的には、われわれが提供する、もう一つのIaaSである「Bizホスティング Enterprise Cloud」を使っていただき、そこにPaaSを乗せ、ある程度インフラ部分に対する情報も公開できる形を選べるような展開も考えています。
マイクロソフト：マイクロソフトは先ほども述べたようにプロプライエタリなソフトウェアベンダーなので、ソースコードについても基本的に非公開です。お客様がソースコードを必要とする場合はお渡しはすることも場合によっては可能なのですが、自分でソースコードを直される方は皆無ですね（笑）。そこで、きちんとした情報提供と商用レベルのサポートサービスによって、満足度の高いロックインを行うというスタンスになります。情報公開については、ISO/IEC 27001:2005を始めとするグローバルな監査・認証プログラムに対するコンプライアンスに注力しています。
障害時の対応という点では、障害を解決した後に、具体的に何が問題で障害が起こったのかについての根本原因分析レポートを、普段はオープンにしていない内部アーキテクチャの詳細も交えながら一般公開することで、ご理解をいただくという対応を行っています。
Engine Yard：まずはじめに、Engine Yardは、AWS（Amazon Web Services）やWindows AzureなどのインフラパートナーのIaaS上でPaaSを展開しているため、IaaSとPaaSの両方を提供していらっしゃるベンダーと立ち位置が違うことを他社の皆さんのお話を伺う中で強く感じました。
Engine YardのPaaSを下支えするインフラ層には、高いセキュリティ認定を持った信頼性のあるIaaSを採用しています。また、Engine Yardが開発・提供するプラットフォーム層については、情報セキュリティの国際標準に基づいて内部評価を実施し、セキュリティプラクティスのホワイトペーパー（PDF）はWebページから開示しています。もちろん、何らかの問題発生時に情報を開示する必要がある場合については、国際標準に基づいてインフラパートナーと連携して提供しています。
Engine YardのPaaSを「オープンな設計」とお話しましたが、それはオープンソーステクノロジーを疎結合に組み合わせているという意味合いだけではありません。Engine Yardで構築するお客様のアプリケーション環境は、他のお客様のそれとは完全に切り離された、「シングルテナント方式」によるシステム環境を提供しています。そして、そのアプリケーション環境に管理者権限でSSHアクセスが可能な設計になっています。そのことこそが「オープンな設計」と言える最も大きな理由です。つまり、お客様はアプリケーション環境のシステム基盤とも言えるプラットフォーム層すべてを我が物にしていただけます。
因みに、お客様のアプリケーション環境の構築を制御する「Engine Yard Cloudダッシュボード」のソースコードは非公開ですが、アプリケーションのデプロイやメンテナンスを行うためのCLIはオープンソースとしてGitHub上で公開しています。
Salesforce.com：「ベンダーロックイン」や「オープン性」については、PaaSベンダーとカスタマーという関係の中でどうあるべきかという議論があると思うのですが、一方でデベロッパーとの関係性ではどうかという視点も捨て置いてはいけないと感じています。私自身も元デベロッパーで（個人的には今もデベロッパーだと思っているのですが）、OSSのカルチャーというか、自分で書いたコードの力でイノベーションを起こしたい欲求というのは、特にRailsやStrutsなどのフレームワークが普及して以降、デベロッパーの中に広がっていると思うんですね。そういうデベロッパーとPaaSベンダーがどのような関係性を築けるかというのは、今後のテーマとしてあるのではないかと思います。
Engine Yard：確かに今後の一つのテーマとしてありますね。Engine YardのPaaSをベースにしたWebサービスはさまざまありますが、直接PaaSをご利用になるのは基本的にデベロッパーの方々です。特にPaaSは運用担当の方々の悩みの種でもあるルーチンワークを軽減できる技術であることから、デベロッパーと運用担当とPaaSベンダーの三者間の関係性をどう築いていけばよいか、という点もテーマとしてあるように思います。
ところで、PaaSを既に利用しているデベロッパーの中で、「ベンダーロックイン」とはある種異なる「ロックイン」を見かけることがあります。それは、あるPaaSから他社のPaaSへの移行を検討しつつも、「PaaSのアドオン機能を多く用いていることで、他のPaaSへの移行が難しくなっているケース」、そして「PaaS上に稼働している既存アプリケーションのシステム設計によって思考がロックインされ、他のPaaS上でも同一のシステム設計を踏襲しようとすることが移行の阻害要因になっているケース」です。このような風変わりな「ロックイン」についても、われわれPaaSベンダーは指針を示す必要があるのではないかと思い始めています。
吉田：PaaSに限らずIaaSでもそうなんですが、ユーザー側に「設計」をちゃんとできる人がまだ少ないのかなというのは感じますね。例えば、PaaSを使ってサービスをスタートし、事業規模の拡大に合わせてデータセンターへ運用場所を移していくというプロセスがあるとします。ビジネスが成長していくプロセスに合わせて、最初にどういうシステム構成をとって、どのようにスケールさせていくというところを含めた「ビジネス設計」に近いシステム設計の感覚というのが、今の時代に非常に求められていると思っています。
社内の情報システムであれば、ビジネス現場とシステムのフィット＆ギャップをとると思うんですが、今後特に必要となるのは「事業」と「システム」との間のフィット＆ギャップをとって、ビジネス成長の過程の中で、最適なフレームワークやベンダーを選択し、活用できる力なのではないでしょうか。
皆さんのお話しを聞いて、それぞれのサービスの特長を把握して、事業の成長に合わせた設計と計画を考えられる人は、問題なくクラウドの時代を乗りこなせるのだろうなぁと感じました。日本の企業には、そのように、ビジネスのフェーズに合わせて、サービスに必要なリソースの調達方針と展開をどうすべきか考えられる人、つまり「ビジネス設計」と「システム設計」を両方考えられる人というのがすごく少ないのではないでしょうか。だからこそ、PaaSの重要性が増している一方で、知識や設計能力の不足から過剰にPaaSでの「ベンダーロックイン」を恐れる人々も出てきてしまっているという現状を生んでいるのではないかと思います。
