「HTML Conference 2013」で行われたセッションから、株式会社サイバーエージェント大谷剛氏と船ヶ山慶氏による「現場の実例から学ぶ、最新鋭のWebアプリケーション開発フローとアーキテクチャ」の模様をお伝えします。

「なぞってピグキッチン」とは

今回作ったWebアプリケーションは、「なぞってピグキッチン」に使っている基本的な技術は、HTML、CSS、JavaScript。これにCanvasなど、他のフレームワークを組み合わせていますが、基本は前者の3つです。これをスマートフォンのブラウザ上で動かし、ネイティブのアプリと近い状態を作り上げたサービスです。

基本的な流れは、例えば（画面上の）ボタンをタップすると、背景色や文字色が変化する。さらに、せっかくCSS3が使えるのだから、角丸やシャドウを付けてみる。さらにアニメを付けてみる。――さらには画面全体を動かして、ぱっと見、ネイティブアプリのようなものを頑張って作りましょう、という流れです。

これが、HTML、CSS、JavaScriptですべて作られている基本の画面です。

左下に自分のアバタがあり、中央にキッチンがある。キッチンをデコレーションし、レシピを並べ、友達に料理をふるまい、キッチンを核にやっていこうと。それを楽しむゲームです。下のボタンを押せばモジュールが開きますが、モジュールからモジュールへとたどっていくのが基本の動きです。基本のURLは一つで、ページのリロードはせず、hashの部分のみで見た目を切り替える仕組みです。

ゲームの流れとして、パズルをして料理に必要な素材を収穫し、それを使って料理をします。制作チームのメンバーは、プロデューサー、エンジニア、デザイナー、ディベロッパーの大きく4つの職種があり、各職種にリーダー的なの人がいます。

フレームワークについて

フレームワークは世の中にたくさんあるのですが、それぞれ特性があります。例えばjQueryなどは有名ですが、スマートフォンで使うには、通信帯域が狭い中でファイルサイズが大きく厳しい。このように、どれがサービスに合っているのか、適性を見極める必要があります。

今回、「なぞってピグキッチン」に使用したフレームワークは「beez」と呼ばれるもの。現在は社内でしか使えませんが、近く社外にも公開する予定なので、その際には試していただければと思います。「スマートフォン開発をスピーディに進めるための、中・大規模クライアントブラウザ向けのフレームワーク（開発ツールキット）」というのが、beezの基本的立ち位置です。

ここで「開発ツールキット」とあるのは、スマホに特化したライブラリ、相性のいいライブラリをまとめてラップしたというのが大きな特徴だからで、そのためbeezを使う場合はbeez専用の言語、書き方ではなく、既存のライブラリの組み合わせで効率よく書けるようになっています。

主に先ほどのライブラリの中から、クライアントが主に触ると思われるものが以下の7つです。

＜１＞ Backbone.js

＜２＞ Underscore.js

＜３＞ Zepto.js

＜４＞ RequireJS

＜５＞ Handlebars

＜６＞ Stylus

＜７＞ bucks.js

簡単にまとめると、Backboneがbeezの中では全体のフレームワークを担い、HandlebarsがHTML、StylusがCSS、ZeptoがDOM操作、Underscoreがユーティリティ、Requireがモジュールを担っています。beezは、これら既存のライブラリに追加する形で、Manager、Controllerという概念を持っています。

Managerは、viewに関しては、グローバルに必ず1つしか存在しない、viewを必ず監視している立ち位置にあります。しかもviewが必要なくなったタイミングで、それを全部破棄しメモリ上から消したり、また必要になった場合には再復帰させたりします。特にスマートフォンの場合はメモリ制限が厳しいので、こうしたマネージメントを行うのが、beezの中のManagerの概念です。

beezは、ツリー構造でviewを管理しています。これはBackboneとかではなく、beez独自のものです。

Controllerの概念は、まずRouterというもの――これはBackboneのものなのですが、hashのフラグメントを常に監視しています。これがモジュール単位で、「クエスト」といったhashに書き換わると、クエストのControllerが呼ばれて、複数のviewとmodelを一気に作成します。そのうえで、クエストが必要としているCSS、i18nのファイルをロードします。

アーキテクチャ

M（Model）とV（View）とR（Router）、これにプラスして、beezのM（Manager）、C（Controller）。この5つの構造で、アプリケーションは成り立っています。

全体の流れとしては、Routerが会社に例えれば社長のような立場にあり、hashを常に監視していて、hashが変わったタイミングで、Controllerという部長クラスに指示を出します。Controllerは、その指令に従って、各社員にあたるModelに指令を下ろす。Modelは更に下のViewに指示。こうしてアプリケーションの見た目に反映される。このようなトップダウンの仕組みで、ボトムアップは基本NGですが、ViewからModelへは、ユーザーがタップした際のアラーム的なものは出ます。

これをまとめると、一番最初にログインした段階で、hashが何であれ、強制的に#mypageに書き換えます。それをRouterが捉え、該当するController（MyPageController）を呼び出します。MyPageControllerはViewとModelを作成。それぞれをひもづけて、いわば社員の“人員配置”をします。ここでユーザーがタップ操作をすると、それがModelに伝わり、Modelが上に伝える。例えば「area」というボタンがタップされたとすると、「#area」というhashに変えてくれというリクエストが行く。#hashに変わってからの流れはまた同様です。

共通機能群

最後に共通機能の部分について。先ほどから何度も登場しているアバターはCanvasで描かれていて、好きなところに移動もできますし、好きな服を着せてやることもでき、動作のバリエーションを登録しておけば、好きな動きをさせることも可能です。

服情報は、アバターの動きに合わせて服の位置等も変わるので、それに合わせてシート化されたものが用意されています。下に一見、横線のように見えるものがありますが、これは画像のデータを持っていて、腕の回転中心の座標情報などがここにあります。

あとは下から開いて左右に移動するなどといった、いかにもスマートフォンアプリっぽい画面制御。これもカスタマイズすれば、一部を固定し部分だけガリガリ動くといったことも可能です。

ポップアップもよく使いますが、これも基本形を作っておいて、それを適宜カスタマイズ。また、リロードが発生したときにエラーデータをキャッチし、ポップアップを自動で表示させるといったことも可能です。

【講演資料・セッション映像】