サーバー側はGoogle App EngineとAmazon EC2の組み合わせ
アスキー総研：「MCS 2011 Web版」のサーバー側はアスキー・メディアワークス側で用意し、APIとして仕様を提示してWebアプリケーションを開発していただきました。サーバーインフラは集計機能がGoogle App Engine（GAE）、グラフの描画機能とキャッシュ機能がAmazon EC2というクラウドサービスの組み合わせですが、開発上のメリット、デメリットはありましたか？
飯島：GAE側のAPIで全データを対象にクロス集計し、その集計結果を使ってAmazon EC2側でグラフを描画し、またなるべく集計処理を少なくするために、そのキャッシュ機構もEC2側でもつ、というのが「MCS 2011 Web版」の大まかな構造です。このEC2とブラウザーで実行するJavaScriptのプログラムをふむふむソフトで開発したわですが、やはりGAE側のAPI開発との役割分担が明確だったのがメリットではないでしょうか。
アスキー総研：すべて同じサーバーに集約して開発した方が楽だった、ということはありませんか？
飯島：集計データは、グーグルがGoogle AnalyticsのAPIなどで採用しているのと同様のXML形式でアプリケーションサーバーが受け取ります。サーバー構成がどうなっていても、データを集計して集計データとして出力し、どこかでグラフ表示用に集計データを加工することに違いはありません。仮にグラフをHTML5で描画する場合でも、Webブラウザー側でJavaScriptがデータを加工するか、描画に都合のよいデータに加工するサーバーが必要であることは同じです。
もちろん、データの集計とグラフ表示用の加工を同じプログラムで処理する方法もありますが、そうなると表示形式を少しいじるだけのために集計プログラム全体に手を入れる必要が生じるでしょう。クラウド側でデータを集計し、API経由でグラフを表示するサーバーに渡す、という今の形は通常のシステム設計の範囲内ですし、他の会社が「MCS 2011」のデータを使いたい、と思ったとき、APIを公開すれば済むメリットもあります。
アスキー総研：Google App EngineとAmazon EC2というクラウドサービスを組み合わせて運用するのはちょっと大げさな気もするのですが、デメリットは何もない、と思っていいのでしょうか？
飯島：もちろん、どちらかのサービスが止まればシステム全体が機能しなくなるデメリットはあります。しかし、「MCS 2011」のデータ集計には大きな計算力が必要ですが、Google App Engineであれば無料の範囲に収まってしまう。ハードウェアをあらかじめ用意しようとすると見積もりが大変なキャッシュサーバーのメモリー量は、パフォーマンスを見ながら徐々に増やせました。いろいろなメリットがデメリットを上回っているので、今回の方法は正解といっていいのではないでしょうか。
ただ、今回はHTML5を使わない前提で、画像をサーバー側で生成しました。もしHTML5を使ってもよい場合は、JavaScriptの方がデバッグが楽など、別の形態の方が開発が楽になる、つまりより短期間に安価に開発できる可能性は残っています。
アスキー総研：HTML5でWebブラウザー側でグラフを描画した方が、スピードが速くなるなどのメリットがありますか？
飯島：目覚ましく速くなるかはわかりませんが、現状では、Webブラウザーがグラフを描画した画像ファイルをどっさり受信していますので、キャッシュサーバーの性能がシステムの応答速度を左右します。集計結果からグラフを描画して画像を送るのと、集計結果をデータとして送るのでは、転送量がまるで違いますから、HTML5の方がパフォーマンスは上がると思いますよ。
また、今回は3重クロスや絞り込みなどの機能を見送りましたが、機能追加もHTML5で開発した方が楽だと思います。グラフを画像ファイルとしてキャッシュしていますが、Webブラウザーでグラフを描画するのであれば、キャッシュサーバーはグラフ描画用データのみ蓄えておけば済みますので、キャッシュサーバーの性能がシステムの応答速度を左右しにくくなるはずです。
iPadでMCSを操作するふむふむソフトの飯島代表
HTML5はWebアプリケーションに革命をもたらす？
アスキー総研：なるほど。今後の「MCS Web版」ではHTML5での開発をお願いするかもしれませんね。今回はiPad/AndroidアプリにするかWebアプリケーションにするかの選択でしたが、今後は従来型のWebアプリケーションにするか、HTML5を使ったWebアプリケーションにするかの選択になるんでしょうか？
飯島：そうですね。現時点では「こういう理由だからHTML5でいこう」と進む案件もあれば、「iOS/Androidアプリで」という前提で進む案件もあって、まさに過渡期状況です。ただ、どちらにも正当な理由があって、こちらの方が正しい、という話ではないと思うんです。
たとえばハードウェアに近い部分へのアクセスや、端末に特化したことはiOS/Androidアプリに強味があります。販売戦略上、どうしてもiOS/Androidアプリでないと困る、どんなに開発期間が短く安価に済むといっても、HTML5で作ったWebアプリケーションでは進められない、という案件もあるでしょう。
アスキー総研：販売戦略といったいわば「大人の事情」がない場合は、開発ノウハウが蓄積されていて作りやすいとか、AppStoreやAndroidマーケットがあって収入を得やすいという、作り手の事情が大きな要因になるんでしょうか。
飯島：1本85円から数百円のiOS/Androidアプリでも、当たればそれなりの金額になります。Webアプリケーションが収入を得にくいのは事実ですが、特にゲームの場合はネイティブに動作してパフォーマンスの出やすいiOS/Androidアプリでしか開発のしようがない場合もあると思いますよ。
ただ、将来はWebアプリケーションが今以上に速く実行できるようになるでしょう。ニッチ化なニーズを満たすのがアプリ、アプリ化の必要がなければHTML5+Webアプリケーションになっていくと思います。なによりHTML5はスマートフォンで弾みが付きました。以前は、たとえば「Firefoxを使っているから見られるけど……」みたいなモヤモヤした位置づけでしたが、iPhoneのSafariがサポートしてからは「スマートフォンでHTML5が動くのは当然」になりました。HTML5を実務レベルで使えるエンジニアはまだまだ少ないですが、今後どんどん増えていくことは間違いありません。
次はデータビジュアライゼーションに挑戦だ！
アスキー総研：「MCS 2011 Web版」から出発して話題がHTML5のWebアプリケーションまで及んでしまいました。話を元に戻して、アスキーを経てマイクロソフトでオフィス系の開発に携わったという華麗な経歴の持ち主である飯島さんにとって、「MCS 2011 Web版」の開発難易度は、10点満点でいうと何点だったでしょうか？
飯島：実は結構難しかったです。どんなお仕事でも毎回悩むのですが、今回は9点ぐらい。かなり高いです。理由のひとつは、提案の余地が広くて、どこから取り掛かればいいのか分からなかったこと。もうひとつは、MCSのWindows版やiPad用の「MCS Element」など、既存の製品よりもよいものにしたい、というプレッシャーがあったことです。
クロス集計用のアプリは「参考にできるもの」がすごく少ないですし、しょっちゅう作ったり、アイデアを温めておいたりする分野ではないですから、「これだ！」というUIにたどり着くまでが大変だった。言葉は悪いですが「これのマネしちゃえ」といえるような前例がないんです。最初の見せ方からして特殊なので、すべて自分自身で解決しなければならないのが難易度10点中9点の理由です。アプリの目的はシンプルだったから何とかなりましたが、何かのシステムに組み込んで使う、みたいな要件があったら、手に負えなかったかもしれません。
アスキー総研：実は、「MCS 2011 Web版」には、私たちの理想とする機能がすべて実装されているわけではないんです。しかし、簡単に操作できるクロス集計にはいろいろなニーズが隠れていたようで、いくつかの引き合いが来ています。データビジュアライゼーションの領域に本格的に参入したらどうでしょうか？
飯島：よい評価をいただけて非常にうれしいです。間違いなくわれわれの大きな実績にはなったと思います。グラフ描画は非常に奥が深いですし、手間もかかります。帯グラフや円グラフは、開発の蓄積がものをいう世界で、Excelのグラフ機能も長年の開発を経てあの形になっています。逆にいえば、Excelにはない、特化したグラフなら、差別化を図る余地がある、ということです。またお仕事をいただけるのであれば、グラフ表示をもっと工夫して、最高のクロス集計アプリケーションに育てていきたいですね！
株式会社ふむふむソフト
飯島進仁を代表取締役として2006年7月設立。業務委託でのソフトウェアやWeb開発を中心に、企画、制作、執筆活動などを行なっています。Silverlightなどを使った地味な研究や、日々の雑記、一部の方々に好評なガジェットなどをブログにて公開中。「ついまん。」も大好評！
撮影協力：「スパイス＆ベーグルカフェ Pan no me」
