デベロッパの観点や業務モデルの違いから見たクラウド
デベロッパーの立場で変わること
各社の紹介後、ディスカッションでの最初の話題は「デベロッパという観点として どう変わっていくか」とし、データベースのモデル（Key-Value）やスケール手法、トランザクションの違いといった技術者としての意見交換が行なわれた。
松尾氏は「Google App EngineでBIGTableのAPIをRDBと思って使おうとすると、痛い目にあいます。JOINができないなど、集約の関数が使えません。SQLに慣れている人は戸惑うでしょう。もともとスケールするためのデータストアなのでつくりが違います。そこに気をつける必要があるでしょう。一応トランザクションを使えますが、データが近くにあるものである必要があります」と指摘した。
萩原氏は「クラウドの場合は、トランザクションの単位は、テーブルの一つの行単位になるので、JOINやSQLが持っているような組み込み関数を使いながら非常に大きなデータのグループに対しトランザクションをかけるということは、まず性能上問題が出てきます。Key-Valueは、一つの表の行のように見えますが、実際には各行が物理的にクラウド上のマシンに分散していますので、例えばテーブルスキャンをすると、クラウド上のマシンに要求が広がってしまいます。いかにトランザクションを使わずにアプリケーションの中で設計を進めるかが重要です。SaaSのような製品の場合はそういった点は隠蔽されていますが、開発者としてはSaaSアプリケーションを作る人は、うまくキューイングとか非同期を使う必要があります」と解説した。
及川氏は「SalesforceはRDBと同じイメージでデータストアを提供しています。実際はマルチテナンシーで行なっていますので、確かにテーブルスキャンをするとアウトになります。ただし、実証データが豊富にあるので、開発者はクエリープランなど気にせず開発できます」と応えた。
業務モデルに与える影響
米持氏は続いて、「プログラミング手法や性能という面ではなく、エンジニアがどんなことをすると役に立つのか」といった業務モデルの違いについて各氏に聞いた。
及川氏は、顧客の成功を実現するには、顧客の仕事を知る必要があるため、その時の顧客からの要求に応じて対応するだけでは、将来性がないと指摘。「顧客の仕事の上流工程の視野を持つ必要があるでしょう」と顧客の本来のゴールを目指した提案の必要性を語った。松尾氏も同様に、Google App Engineは、インフラの安定性は保障されているので、よりビジネスロジックに注目すべきであるとし、萩原氏も「業務の戦略と戦術があって、システムへの要求が決まります。確かに及川さんの言うように、その元になる問題や目標を知らないといけないでしょう」とした。
米持氏は「IBMの場合はこれまでインフラごと塊で納品するスタイルが主流でした。住宅で言うと戸建ての一軒家です。それと対比してクラウドは、マンションと言えます。これからは家を建てる人ではなく、マンションの各部屋の中のものを作る人が必要となっていくと思います。この数は非常に多くなってくると思いますのでその点に注目しなければならないと考えています」と、より上位の業務に注目する必要があるとまとめた。
クラウドが創出する新たなビジネスの形
ディスカッションの最後では、各氏からのメッセージが語られた
松尾氏：「Google App Engineは、クラウド時代の象徴的なサービスですのでぜひ使ってみてください」
及川氏：「今日はスーツ着てきましたが、技術を追い求めてはいけないということではありません。ただ、ビジネスで使う以上は、自分が係わっているビジネスに対して幅広い仕事に目を向けてください」
萩原氏：「クラウドはビジネスチャンスです。例えば、アプリケーションをどう配置するかという手法は決まっていません。法令上の制約や時差、電力消費などを考慮した再配置などを考えると、これからどんどん仕事は増えていくでしょう」
米持氏は最後に「クラウドに限らず、新しい技術が出た際、古い技術に置き換わるわけではなく、利用範囲が広がる場合が多いと思います。道路や橋をつくることで都市が発展していきます。大きい橋はそれなりに予算をつけて作りますが、これはメインフレームの開発に近く、今後もなくなることはないでしょう。クラウドは、今までコスト的な問題から、コンピュータを使えずにいた領域に、安いコストで導入できるというものなので、小さい橋をいろいろな場所に作っていくイメージです。堅牢性やスケールを考えるのではなく、ちょっとしたことでも、何をやったらどれくらい効果があるかを考えることが重要になるでしょう」と語りディスカッションを締めくくった。
