Cloudへの期待は大きい。スピード経営、コスト削減、グローバル化、モバイル。各々の会社で持っている課題を解決する方法として一つの選択肢である。企業の規模によってその意見も様々であるが、システムは全てCloudに置き換えるということは難しい。もし、何十年というスパンでそうなったとしても、その過程の段階では、社内のシステムとクラウドのシステムは共存するということを前提としなければならない。 一方、ITベンダーは来るべきCloud時代に向けて、虎視眈々と準備を進めている。マイクロソフト、Amazon、 Google、 IBM、Salesforce、SAP、Oracle... 数えきれない数のベンダーが顧客向けの便利なサービスを提供してきている。これらの便利なサービスは、広告モデルという資本に支えられて開発されている為、顧客には安価に提供される。 端末もAndroid、Google Chrome OS、iPad、iPhone、Linux、Windows ...と様々な環境が提供されてきている。これまでのようにWindows一色ではない。むしろ、OSよりもブラウザの機能の方が重要になってきている。（注１：筆者はクラウド時代の開発言語としてHTML5に注目しているが、今回はフォーカスがずれるので、いずれ違う機会に話をするつもりである）クライアント端末としては、OSを選択するのではなく、ネットワーク環境やブラウザを選択するという時代になってきた。そして、その端末が、どのサービスを利用することができるのかというのが重要になっている。 この様な環境下で顧客はどう対応をしていけばいいのか？端末とサービスの組み合わせはかなりの数になる。しかも、得意分野のサービスのいいとこどりをすると考えれば、顧客は無限大の選択肢の中から、自社に適したサービスを組み合せることになる。私はこれを「クラウドカオス」と読んでいる。テクノロジーの進化は早い。選択をする為にはむしろ企業側がしっかりとしたITアーキテクチャを選択することと、それをマネージメントができるアーキテクトを育てる必要がある。

例えば、営業支援システムはSalesforce、グループウェアはGoogle、業務アプリケーションはWindows Azureと顧客が業務内容によって別々のSaaSを選択することができる。この場合、利用者は個々のSaaSを別々にアクセスして利用することになる。このような状況は現在、社内の業務システムの中でも、ユーザの利便性を考えた場合大きな問題になりつつある。ユーザは単一のポータル画面から全てのシステムに入っていけることを望んでいる。クラウド化がすすむことで、この問題はよりいっそう顕著になってくる。利用者としては、一つのポータル画面に一度ログインをすれば、社内システムと、契約をしているSaaSのアプリケーションがシームレスに利用できることを望んでいる。 データはどうだろうか？クラウド上のデータを社内システムで利用したいと考えるだろう。又は、社内のシステムで利用しているデータをクラウド上でも利用することができるようにしないと不便である。殆どのクラウドベンダーはその為のAPIを用意している。クラウドベンダーはそのAPIを利用してデータを抽出し、変換をし、そして投入をすればいいという。しかし、複数のクラウドを利用する場合に、企業内のシステム部でそれらのアーキテクチャを把握してそれに対応するということは大変難しい。冒頭で述べたように、スピード経営を行いたい為にあえて臨機応変にSaaSを利用するということが考えられるが、社内のシステムとの連携に時間がかかっていると、スピード経営そのものができなくなる。この問題の解決にアーキテクチャやアーキテクトが必要なのだろうか？答えはYesである。社内のシステムのアーキテクチャとクラウドのアーキテクチャを把握した上で、どのように対応をすればいいかをあらかじめ知っておくことは大変重要である。 例えば、Google App Engineで利用される言語はPythonが標準である。Javaも使えるようにはなったが、Rubyを使いたいと思うと、Java VM上で利用できるJRubyを利用することになる。一方Windows Azureはどうだ。もちろん.NETである。SaaSではWebアプリケーションが中心になるので、.NET ASPになるだろう。他言語も使えないことはないが、生産性を考慮すれば.NET ASPが順等である。Force.comではAPEXという言語で開発することになる。APEXはJavaによくにた言語だと言われているが、基本的にはプロプラエタリーな言語である。この様に、どのプラットフォーム上でアプリケーションを利用するかによって、どの言語を基本とするのかが違ってくる。社内のアーキテクトはそれぞれのPaaSの特徴をとらえながらどういうアーキテクチャを採用するか検討する必要がある。 SaaSでも同じである。CBAでも様々なSaaSベンダーがサービスを提供している。このSaaSベンダーがどのようなAPIを提供していて、どういうアーキテクチャで利用できるかは、社内システムとの連携を行う上では不可欠である。そして、そのAPIは自社で必要としているデータにアクセスできるのかどうかによって、SaaSのベンダー選択にも必要となる。例えば利用部門が、AというSaaSベンダーを使いたいと言っても、利用部門が必要としているデータが取り出せないとなると、システム部は違う選択肢を利用部門に提案すべきである。このような対応を考えると、利用部門に先立って SaaSアプリケーションの特徴をとらえておく必要がある。よく聞く話としては、利用部門がSaaSベンダーと契約をしてから、社内のIDとSaaSの IDの同期をとってほしいという要望がシステム部門にやってくる。これらを未然に防止する為にはあらかじめ業界標準の連携方法を把握した上で、どの SaaSが標準を採用して、どのSaaSは標準ではない方法を採用しているのかが解っていれば、利用部門の決定に主体的に関わっていくことができる。 私は、クラウド時代にはいると、企業システムを企画、運用していく為には、逆にITに詳しい人材が不可欠になると考えている。そしてそういう人達は、業界標準を十分に理解した上で、アーキテクトとして社内のITインフラの標準化に大きな役割を果たして行くことになる。業界標準や動向にセンシティブでなければクラウド時代を乗り越えられなくなることは言うまでもないだろう。 次回はOpenSocialという業界標準について説明する。

戌亥稔 (いぬいみのる)

（株）ビーコンIT　執行役員　グローバル／クラウドビジネス本部長

1米国フロリダ州フロリダ工科大学コンピュータサイエンス修士課程卒。二十数年のIT 業界での経験の中で、米国赴任、製品開発、ユーザ企業のシステム構築経験をもとに幅広い 視野で情報システム部のあり方を提唱する。Beaconユーザ会幹事も兼任しており、ユーザ企業との太いパイプをもつ。 出版物：実践XMLデータベース構築（2001/5） TwitterID:minoru61

（ビーコンIT）