私はHTML5 Experts.jpで、過去2年ほどGoogle I/Oの情報を発信し、Web技術の変化についてお伝えしてきました。振り返るとGoogleは、2014年にモバイルWebの提唱と技術要素の拡大を図り、2015年からは「RAIL（モバイルWebが目指すべきパフォーマンス指標）」や「Progressive Web Apps（アプリのように振る舞うWeb）」といった、モバイルとの親和性が高いWebを作り出すための”考え方”を推し進めました。今年2016年は、さらにそれを踏み込んでいったという感じがします。

今回のI/Oで取り上げるのもそのひとつ。毎度お馴染みGoogle Developer AdvocateのPaul Lewis氏による 「High performance web user interfaces」です。彼は、モバイルにおいて、時にアプリのように振る舞うことが求められる昨今のWeb、すなわち「Progressive Web Apps」について、UIで起こりがちなパフォーマンス問題と、その改善方法について紹介しています。

※ この講演、動画無しでは説明が難しかったり、前提知識も多かったりするので、私でかなりアレンジ・要約して紹介しています。より詳細に内容を知りたい場合は、ソースをみることをオススメします！

Webは時として、モバイルアプリのような体験が求められる

モバイルにおいて、ホームスクリーンは重要な場所だ。人々はホームスクリーンから、目的を達成するためのアプリを起動する。Webは、Add to Homescreenを使うことで、ホームスクリーンからWebサイトへアクセスすることができるようになった。

するとどうなるか。このホームスクリーンをよくみてほしい。どれがWebで、どれがネイティブアプリなのかは見分けがつかないだろう。Google Mapsなんかはネイティブにみえるけれど、他はまったく想像がつかない。しかしこれらが、Google Mapsと同様にネイティブアプリにみえるなら、Webはネイティブアプリのように振る舞うことが求められている。

パフォーマンスモデル、インタラクションモデルの2つによって、Webはモバイルネイティブアプリのような振る舞いをえることができる。Progressive Web Appsを実現することができる。今日はこの2つのモデルのうち、パフォーマンスモデルの話をしたい。

昨年は、Paul IrishやIlya Grigorikなどの私のチームのメンバーが、「RAIL」というパフォーマンスモデルについて話した。RAILとは、Responseは0.1秒、Animationは16ミリ秒、Idleは50ミリ秒、Loadは1秒で動作すべきというもの。ただ、それを聞いた人々は、たまに勘違いをする。この4つの要素は、どれも全て、最も重要なこととして語ってしまうのだ。それは間違っている。

例えば、Webサイトにおいて、タップした時に求められるのは、4つの要素のうちLoadが重要になる。Idleが重要になることはそこまでない。そして、ホームスクリーンからタップして起動されるProgressive Web Appsでは、ResponseやAnimationが重要になる。Webサイトをつくるのと、Progressive Web Appsをつくるのでは、求められることが違う。

さて、このようにパフォーマンス面で求められることが異なるProgressive Web Apps。そこに、3つのコンポーネントがある。Side Navigation、Swipeable Cards、Expand an Collapse。これらを実現するセオリーを紹介しよう。

1. Side Navigation

まずは、このコンポーネント。メニューボタンをタップすると左からスライドインするバー。これは、2つのElementによって構成される。半透明の黒い背景と、サイドメニューを表示する領域だ。

このサイドメニューの部分のCSSは非表示の時、CSSにpointer-events: none;を指定する。そして、表示されたタイミングでpointer-events: auto;を指定する。

そしてここからが大事な話。左から右、あるいは右から左に移動させる際に、transformを使う。ブラウザがDOMの位置を変更する際に、CPUを使ったレイアウト変更してはいけない。GPUの力を借りて、描画位置を変更することで、最適なパフォーマンスを得ることができる。

例えば、一昔前。サイドメニューが左に消えている時にCSSは

.side-nav {
  position:       fixed;
  left:           -102%; /* DOMのレイアウト位置を左にずらしてメニューを隠す */
  top:            0;
  width:          100%;
  height:         100%;
  over-flow:      hidden;
  pointer-events: none;
}

と、left: -102%で隠す。これは一般的な方法だった。しかし、描画を高速に処理できるGPUの恩恵を受けたいなら、transformを使って以下のように記述する。

.side-nav {
  position:       fixed;
  left:           0;                 /* DOMのレイアウト位置は常に0のまま */
  top:            0;
  width:          100%;
  height:         100%;
  over-flow:      hidden;
  pointer-events: none;
  transform:      translateX(-102%); /* 描画の位置を左にずらすことでメニューを隠す */
  will-change:    none;              /* <- これは何！？ */
}

サイドメニューのDOMのレイアウト位置としては、x位置のleftもy位置のtopも、0のまま。横幅widthも縦幅heightも、100%ということで、全面を覆っているという扱いになる。しかし、transform: translateX(-102%);で描画の位置自体を、左に寄せている。

そして、ここで登場するのがwill-chanage: none；だ。

一昔前にtransform: translateZ(0);をCSSプロパティに指定して、パフォーマンスを改善するというハックが出回ったのをご存知だろうか。このCSSが指定されると、描画には必然的にGPUの力が必要になるため、強制的にGPUに描画を依頼することになる。GPUの恩恵を受けるために活用されたこのバッドノウハウは、will-chanage: transform；という新しいCSSプロパティをWeb標準として追加することによって、同様のことを実現できるようにした。(※注:実態はブラウザ対応の問題もあり、今もtransform: translateZ(0);を使うのが一般的)

ただ、transform: translateZ(0);やwill-chanage: transform；といったCSS指定は、常時ビデオカード上のRAMメモリーに描画結果をテクスチャーとして保存することになる。モバイル環境では、バッテリー消費などに悪影響を及ぼすことになる。動作するタイミングだけwill-chanage: transform；を指定し、動作しない時は無効化will-chanage: none；するといい。これが、バッテリー消費パフォーマンスと描画速度パフォーマンスのトレードオフ問題に対する、落とし所だ。

黒背景については、will-change: opacity;というプロパティがあり、transformと同様の方法で、高いパフォーマンスで描画させることができる。(※ JSの実装については、「2. Swipeable Cards」にノウハウが似ているので割愛)

2. Swipeable Cards

CSSを使ったパフォーマンス改善のテクニックの他に、注意しなくてはいけないのが、スワイプ操作時のコンポーネントの移動処理。ユーザーからの指の位置状況を入力し、それをスクリーン上に反映しなくてはいけない。この際、有用なのが「ゲームループ」のノウハウだ。

描画のイベントは常に、1/60秒ごとに発生する。対してスワイプのイベントは、常に一定には発生しない。描画のタイミングにはあわせてくれないのだ。

そこで、スワイプにより発生するイベントについては、変数に位置情報だけを記録する。そして、描画時のイベントでは、記録された位置情報を元に、CSSを通じて描画位置変更をおこなう。

スワイプの開始時・移動時・終了時は以下の通り。this.startX、this.currentX、this.targetXといった変数に、現在の位置や、移動すべき位置を記録している。

/**
 * スワイプ開始
 */
onStart(evt) {

  // スワイプの開始位置を記録する
  this.startX = evt.pageX || evt.touches[0].pageX;
  this.currentX = this.startX;

  // cardの移動が開始されたことを記録する
  this.draggingCard = true;

  // will-change: transform; を有効にする
  this.target.style.willChange= ‘transform’;

  // カード上の要素にイベントを伝播させないように
  evt.preventDefault();

  // アニメーションを開始する
  requestAnimationFrame(this.update);
}

/**
 * スワイプ移動時
 */
onMove(evt) {

  // スワイプの現在地点を記録する
  this.currentX = evt.pageX || evt.touches[0].pageX;

}

/**
 * スワイプ終了時
 */
onEnd(evt) {

  // cardを削除すべきかどうか判定する
  let translateX = this.currentX - this.startX;
  const threshold = this.cardWidth * 0.35;
  if( Math.abs(translateX) > threshold ) {

    // cardの移動先をスクリーンの外へ(※cardは削除)
    this.targetX = (translateX > 0) ? this.cardWidth : -this.cardWidth;

  } else {

    // cardの移動先を最初の位置へ(※cardは削除されない)
    this.targetX = 0;

  }

  // cardの移動が終了されたことを記録する
  this.draggingCard = false;
}

描画のタイミングにrequestAnimationFrameから呼び出されるコールバックで、先ほどの位置情報を元に反映していく。

/**
 * 描画内容の変更
 */
update(evt) {

  // 次の描画タイミングでも自身を呼び出す
  requestAnimationFrame(this.update);

  // スワイプ中の場合
  if( this.draggingCard ) {

    // 現在の位置を描画させる
    this.translateX = this.currentX - this.startX;

  // スワイプが完了している場合
  } else {

    // カードを削除するかしないかに応じて指定の場所に能動的に移動する
    this.translateX += (this.targetX-this.translateX)/4;

  }

  // CSSプロパティを経由してGPUに変更を伝える
  this.target.style.transform = `translateX(${this.translateX}px)`;
}

(※ この後の処理については、「3. Expand and Collapse」にノウハウが似ているので割愛。)

3. Expand and Collapse

タップすると、領域が広がり全体化されるUIコンポーネント。CSSではどうするのか？もちろん、ここまで説明してきた「transform」を活用する！では、JSについてはどうか？実は、「2. Swipeable Cards」とは異なり、スワイプ操作でなくタップによって、自動的にアニメーションする。この点で、より効率的な実装が求められる。

まず、アニメーションについて、動作中の状態はJS上で持たない。動作前後の状態だけを、CSSプロパティを通じてGPUに指示する。

// 変化量を計算する
invert.x = first.left - last.left;
invert.y = first.top - last.top;
invert.sx = first.width / last.width;
invert.sy = first.height / last.height;

// 変化後の状態をCSSプロパティを通じてGPUに指示
card.style.transformOrigin = ‘0 0’;
card.style.transform =
    `translate(${invert.x}px, ${invert.y}px)
      scale(${invert.sx}, ${invert.sy})`;

そのままでは、タップした要素は一瞬にして全体化されてしまう。どのようにして何ミリ秒もかけて徐々に広げていくか？その方法は、CSSで指定する。JSではない。原理的には、従来よく使われているCSSアニメーションだ。

.cards {
  transition: transform 0.2s cubic-bezier(0,0,0.3.1); // アニメーションさせる
}

ここまで、Progressive Web Applsのパフォーマンス改善の話をしてきたが、「Google DevelopersのRendering peformance」が役に参考になる。一読するといいだろう。

Progressive Web Appsのパフォーマンス改善。要はこう言いたかった

いかがでしたでしょうか？文字数の制限やコンテキストの高さもあり、多くのエンジニアに伝わるようかなりアレンジしてみましたが、ご理解いただけましたでしょうか？

Paul Lewis氏が言いたかったことは単純な話です。先ほどのGoogle Developersの記事にもありますが、Progressive Web AppsにおけるAnimationやReactionの課題は、いかにしてブラウザのレンダリング処理における「レイアウト」を減らすか、という話です。この講演は、そのTIPS集といえます。

今日のノウハウ、特に新しいというわけでもなく2年前には既に実践されていたことです。実際のところ多くの現場では、OnsenUIやIonicのようなUIライブラリを活用することになり、このあたりの話を意識することはないのでしょう。ただ、Webのサービスを作っているフロントエンドエンジニアにとっては、ライブラリの有無に関係なく知っておくべき知識のように思えます。サイドメニューについては、Webサイトであっても鉄板のUIコンポーネントなので、Progressive Web Appsか否かはもはや関係ないノウハウだったに違いありません。

Webがモバイルに順応していくことは、今後もさらに求められていきます。これは、フレームワークやライブラリに限った話ではなく、トータルにみたWeb、フロントエンドへの要求に変化を与えるに違いません。

今後も、モバイルとWebの関わりに、目が離せませんね。

最近、モバイルではネイティブ一強という状況にみえます。Webはあまり注目されません。今後も同じ状況が続くのでしょうか？そのことについて、Google I/O 2015のセッション「The Next Generation Mobile Web」が参考になります。補足を加えつつ翻訳してみましたので、どうぞご覧ください。

But What About Mobile

Webはパワフルな技術だ！これからも、ビジネスをもっと盛り上げていく。2014年、Eコマースは低く見積もっても1.5兆ドルの規模になった。そんな中、モバイルは何を変えたのか？ユーザにどんなインパクトを与えたのか？

モバイルは経済のシフト、デスクトップが担っていた領域の変化だ。パフォーマンスが求められるような動作も、従来のPCとは違い、バッテリーで動いているデバイス上で実現しなくてはいけない。必要とされる機能も完全に変わってしまった。プッシュ通知はモバイルのポテンシャルを高める上で重要なのだが、Webにそれはできなかった。結果、ネイティブの方が当然良く見えるわけだ。

しかし、我々は全てをネイティブアプリに置き換えるべきなのだろうか？ネイティブにはいいところがあるけれど、Webもまた負けないいいところがあるはずだ。

みなさんは、Chrome Dev Toolsがどれだけの人に使われているのかご存知だろうか？Androidは400万人/週だが、Dev Toolsは2,500万人/週に使われている。そして、素晴らしいことに、今もなお増加し続けている。全ての人が巨大で複雑なWebサイトを作っているわけじゃないし、中にはあまり上手くWebサイトを作れていない人もいる。けど、少なくともDev Toolsを使っているみなさんは十分にスキルが高い。今からするこの話は、そんなWebを愛する2,500万人のあなたたちに伝えたい。

Reach

Webサイトはツリー型だ。例えば以下の図だと、ノードにあたるのがPinterest.comみたいなサイトで、あなたたちのサイトはその葉にあたる。URLからURLへ、ノードから葉へ飛ぶ。異なるサイトであっても、リンクからリンクへ飛ぶことはそんなに難しいことじゃない。サイトの奥地へだって行ける。

人間が使うモバイルアプリは平均12から20と言われている。しかし一方で、アクセスされるWebサイトは、一ヶ月あたり100ドメイン以上だ。それはWebが、リンクを使って簡単にアクセスできるからだ。USにおいて、85%のリテーラーはモバイル上のトラフィックがWeb経由でやってくる。これがWebの持つパワーなのだ。

Performance

では、これらのリーチに対して、Webページはどの程度のパフォーマンスが必要なのか？ページの読み込み時間か？いや、それでは十分とは言えない。実際にはもっと様々なメトリクスがある。スクロールだってサクサク動かなくちゃいけないし、アニメーションも60fpsで動かすべきだ。ただ、どんなパフォーマンスをどれぐらい速くすれば十分なのかは、なかなかわからない。

その答えとして「RAIL」というコンセプト挙げている。Reaction、Animation、Idle、Loadの略称だ。RAILでカギとなっている考え方は「When is performance ‘Good Enough’? When the user can’t perceive it.(十分な速さとは、ユーザがそれを気にしないことだ)」だ。そしてそれを実現するために、60fpsを意味する16.67ミリ秒、100ミリ秒、1秒という時間に注目している。

RAILのR、Reaction Timeは、例えば画面にタップするなどのアクションに対して、100ミリ秒未満でリアクションすることを求めている。そうでないと、ユーザはそのアプリが、壊れているだとか遅いだとか感じるだろう。100ミリ秒未満で、ボタンの色を変えたりインジケーターを回したりすれば、フリーズしたようには見えない。

RAILのA、Animation Time。アニメーションは、16.67ミリ秒未満で動作することを求めている。RAILのI、Idle Timeについて。JavaScriptなどでデコードなどの重い処理を行うと、UIが固まってしまう。処理をチャンクを使うなどして分けて、Idleを作り出さなくてはいけない。その期間は50ミリ未満が望ましいだろう。そうすることで、RのReaction Timeの100ミリ秒未満は守られるだろう。

RAILのLは、みなさんもよく知っているLoad Timeだ。これは1秒未満が望ましい。ただ、これに関しては、Service Workerを使えば、読み込み時に動作中であることをユーザに伝えることができる。

Chrome開発チームには現在、約200人程度のエンジニアがいる。そしてその多くは、パフォーマンスを改善するために働いている。モバイルを良くしようと、様々な取り組みを行っている。その全てを深く語るには、時間が足りなさ過ぎている。一つだけ紹介すると、例えば「スケジューラー」。これはパフォーマンスを劇的に変えたと思っている。タスクの優先度が変わったことで、スクロールのパフォーマンスが大きく改善されたのだ。

パフォーマンス改善は、とても難しいことにみえるかもしれない。しかし臆することはない。博士号なんか取得していなくても、ちゃんとできる。Chrome Dev Toolを使って、サードパーティスクリプトであったり、リソースのパフォーマンスを計測して、問題を探るのだ。そして、RAILをゴールとして、パフォーマンス改善を行っていけばよいだろう。

Engagement

モバイルWebに欠けていたのは、エンゲージメントだ。しかし今、Webにはエンゲージメントを助けるたくさんの機能がある。ただ同時にそれは、セキュリティ面に大きな課題を抱えている。

例えば、background sync(Service Worker)なんかは、Webページを閉じていても簡単にコンテンツの読み込みや送信ができてしまう。あなたが一ヶ月に100のサイトへアクセスするとして、その全てでbackground syncが有効になることは望まないだろう。質の悪いWebページにアクセスしようものなら、Background syncが裏で動き続け、バッテリはどんどん消耗されるなんてこともある。バッテリー効率の悪いネットワーク処理を、ガンガン動かすことが可能だからだ。

誰しも、初対面の相手は簡単には信頼しない。Webサイトオーナーとユーザーとの関係は、ゆっくりと築かれる。ネイティブはアプリのコピーがWebほど簡単ではない。ストアがいて、その開発元も明かされているからだ。しかしWebはオープンだ。パーミッション機能は慎重に作られていなくてはいけない。ユーザに確認して、パーミッションをWebサイト側へ与えることで、初めてリスクの高い機能は使えるようにしている。

さて、これらの機能のうち、有益なものを2つ紹介しよう。

一つ目が「Add to homescreen」だ。例えば興味をもったWebサイトがあったとする。そこに手軽にアクセスしたい。そういう時に、ホームスクリーン上へアイコンを配置しておき、ネイティブアプリのように手軽にアクセスできるようにしておくと、簡単にWebサイトへ飛べる。

実は、古くからそのような機能がブラウザについているのだけれど、設定メニューの中に隠れていたため、手軽では使えなかった。しかし今は、それができるAPIを提供している。これをWebサイト上から呼び出せば、以前より手軽になるだろう。

モバイルWebでユーザ体験を高める場合、ネイティブアプリのような、オフライン対応も重要になる。以前は、「App Cache」がその役割を担っていた。しかしそれは、始めること自体は簡単なのだけれど、メンテナンスにやっかいな問題を抱えている。失敗すると、Webサイトは簡単に動かなってしまう。これを改善し、柔軟なコントロールが行えるようにしたのが「Service Worker」だ。

Service Workerはオフラインで動くスクリプトで、Webサイトにアクセスするとまずそこに問い合わせが行われる。Service Workerは何をすべきか判断し、必要であればネットワークを通じてリソースを取得し、キャッシュへ置くことができる。その振る舞いから、クライアントサイドのJavaScriptプロキシなんて呼ばれていたりする。

Google I/OのWebサイトなんかが良い例だ。Service Workerを使って、必要な全てのリソースをキャッシュに読み込んでいる。Gulpに「sw-precache」というプラグインがある。それを使えば、簡単にService Workerのインテグレーションを、あなたの現場のワークフローへ組み込めるだろう。

Service Workerは、Webページが複数のタブが開かれていても、その全てと通信できる。また逆に、一つも開かれていなくても内部で生存している。それはランダムに起き上がって動くようなことはせず、基本的にはイベント駆動だ。ネットワークなどのイベントを検知して、スクリプトはストレージ内からメモリ上へ移される。だいたい50ミリ秒程度だろうか。その後、Service Workerの処理が実行される。

モバイルであれば、ネイティブアプリのようにプッシュ通知を扱いたい考える事は必然であろう。Anish AcharyaはTechCrunchで「Notification Are The Next Platform(次のプラットフォームは通知だ)」と語っている。通知機能は、エンゲージメントを改革するのだ。

人々がアプリに長く時間を使うのは、人々が通知を受け取るからだ。モバイルの画面を見て、通知を受け取っているのを見て、そこでアプリを使う決断をする。ニュースサイト「The Guardian」はネイティブアプリを提供しているのだが、彼らは事件が起きた時に、そのニュースをプッシュ通知を通じて伝えると、40%のユーザがそこからやってきたそうだ。これはとても多い人数だ。

そんなプッシュ通知だが、今はブラウザから実行できるようになっている。一つの例として、The Guardianのある記事へアクセスした時に、その記事の更新をプッシュ通知を受け取ってみる。

通知の許可を、Webサイト上で行うことができる。

その後、Chromeを閉じ、ユーザは作業を再開する。そして、記事が更新されると・・・この通り！プッシュ通知が飛んでくる。これは他のネイティブアプリと、同じように扱われている。

じつは、今サンプルとして紹介したThe Guardianは、今後本当にプッシュ通知を対応させる予定だ。SNSのFacebookや、商品を扱っているebayやticketmasterでも対応する予定だ。今後も増えていくことだろう。

最後に

いかがでしたか？

Reach、Performance、Engagementは非常に重要であり、これらが効果を上げれば、モバイルWebは上手くいく、というのがGoogleらの答えなようです。

「Web vs ネイティブ」という議論は散々行われてきましたが、彼らはそういう見方をしていないようですね。モバイルの本質を考え、そこからWebの立ち位置を明確化してきたように見えます。

よくよく考えてみたら、モバイルのホームスクリーンはブラウザのブックマーク機能と、そのユースケースに大きな違いはありません。そして、最近のプッシュ通知もまた、アプリの状態を表示するものというよりも、エンゲージメントの高い情報を目立つ所にリスト化しているだけのようにみえます。それはWebのサービスにおいて、メールの通知によって補っていた機能です。いまさら、驚くようなことでもありません。従来デスクトップでもやっていたことを、モバイルのユーザビリティに合わせてきたと捉えられます。

この考え方が、一日でも速く現場にも浸透してほしいですね。そのためにも、「Windows XPの悲劇の再来」にも見えるAndroidのフラグメント化が、一日でもはやく改善してくれることを祈っています。

前々回、前回と業務アプリのフロントエンドについて主に説明しました。今回は、バックエンドに焦点を当てて説明を行います。

業務アプリの多くは、ブラウザーを通じて利用されるWebアプリ方式で提供されます。この場合、サーバー側でJavaやPHP、Rubyといった言語を用いてサーバーサイドプログラムが実行されます。もちろんHTML5やJavaScriptを用いてリッチなWebアプリを実現することができますが、その場合においてもビジネスロジックのほとんどはバックエンドに記述されてます。

一方、モバイルアプリの世界では、この割合が大きく異なります。たとえば、バックエンドの機能は、フロントエンドと連携するためのAPI機能が中心となります。フロントエンドについては、HTML5で開発しようと、ネイティブで開発しようと、バックエンドから受け取ったデータを表示したり、データを編集してバックエンドに送信するといった機能が必要とされます。

異なるスキルセットが必要

処理がバックエンドとフロントエンドに分散する問題点の一つは、アプリ開発のスキルセットが異なることです。フロントエンド開発では、ユーザビリティに関する知識や、HTML5やJavaScriptといった言語の理解が必要となります。一方、バックエンド開発では、ビジネスロジックの理解と、フロントエンド開発とは異なるサーバーサイド言語の知識が必要です。エンジニアが両者を一手に引き受けるのは簡単ではありません。

また、バックエンドにおいても、モバイルアプリに特化した機能を求められるケースがあります。たとえば、任意のタイミングでアプリに情報を送信するプッシュ通知や、App StoreやGoogle Playストアを経由せずにアプリを配信する機能、モバイルアプリからユーザー認証を行う機能などです。これらはネイティブ機能を用いて実現され、フロントエンド側にも対応する機能が実装されている必要があります。

さらに、業務アプリを考える上でバックエンドに求められる最も重要な機能は、既存システムとの接続です。これは、既存の業務システムやイントラネットに配置されたデータベースと連携するために必要です。そのためには、ファイアーウォール内に配置された各種システムにインターネットを経由して接続する仕組みを構築する必要があります。

こういったモバイル特有の課題を実現するために、専用のバックエンドをゼロベースで開発することは非現実的です。そのために、クラウドやパッケージ形式でモバイルバックエンドを提供するソリューションが存在します。これらのソリューションを使うと、フロントエンドの開発者はバックエンドの知識に乏しい場合でも、安全に業務システムに接続したり、モバイルアプリの機能を実現することができます。

既存システムとの接続

業務システムの運用では、社内ネットワーク（イントラネット）だけでなく、ハイブリッドクラウドやSaaSといったクラウドサービスを利用しているケース、そして両方を使い分けているような場合も考えられます。まずは、こういった多彩なシステムに対していかに接続するか、という観点が重要になります。

接続先として考えられるのは、ERPやCRMといった基幹系システム、Active DirectoryやLDAPといったユーザー管理システム、グループウェアやメールシステムといった情報系システムが挙げられます。B2Cアプリのバックエンドに求められる、FacebookやTwitterなどのソーシャル連携や、広告配信システムなどとは大きく異なることが分かります。

企業モバイルの典型的な接続先

開発後の運用基盤

また、アプリ運用時の基盤についても考慮する必要があります。具体的には、アプリケーションの配布や更新を管理する機能、ユーザーやデータの権限を管理する機能、そしてエラーログや利用状況などを一元的に把握する機能などが挙げられます。

アプリのインストール数が数万台を超えるB2Cアプリと比べて、B2BやB2Eアプリは数十から数千台が中心となります。端末やアプリ管理を集約することで、運用にかかる工数を抑えることができます。

MEAPはスモールスタートに向いていない

モバイルエンタープライズの開発・運用基盤として、これまで中心的な存在であったのはMEAP製品です。MEAPとは、Mobile Enterprise Application Platformの略で、2008年にガートナー社が提唱した概念です。

MEAPは、エンタープライズ向けモバイルアプリに要求される、長期的な開発～運用を担う総合的なソリューションの総称です。MEAPソリューションの具体的な例としては、IBMのWorklightやKonyといった製品が挙げられます。

MEAPの大きな機能の1つに、クロスプラットフォーム開発が挙げられます。実はどの製品も、第1回で紹介したCordovaフレームワークをベースにしており、HTML5ハイブリッドアプリとして開発されます。

MEAPにも問題点があります。それは、オールインワンとしての利用が前提となるため、どうしてもソリューションとしての規模が大きくなってしまい、それに伴い、値段も上がってしまうことです。特に、モバイルプロジェクトはスモールスタートすることが多いことから、MEAPは向いていないと判断される例が少なくありません。

また、モバイルアプリの開発では、様々なツールやサービスを組み合わせてアプリを作っていくことがよくあります。たとえば、プッシュ通知やテスト配信、アプリ管理などに特化した専用ツールが提供されています。MEAPを利用した場合に、こういった外部ツールとの連携がとりづらくなり、結果としてオープンな環境で開発できないといった懸念があります。

エンタープライズ向け次世代モバイル基盤

その中で、次世代モバイル基盤とも言える、新たなエンタープライズ向けのバックエンド基盤が登場しています。2013年末に発表された米Yankeeグループの調査結果によると、サービス形式でバックエンド基盤を提供するMBaaSプロバイダーは既に一般的な存在になっており、より優れた技術を持ち、顧客ベースが確立している成長企業が今後主役になるだろうとしています。

エンタープライズ向けモバイルバックエンド

その中の1社であるKidoZen社を紹介したいと思います。KidoZenはエンタープライズに特化したバックエンドを提供しており、クラウドだけでなくオンプレミスでの運用にも対応しています。イントラネット内で稼働する各種ユーザー認証基盤やデータベース製品に接続できるだけでなく、Salesforce.comやOffice 365といったクラウドベースのサービスとも連携できます。データ仮想化によるセキュリティ向上や、バックエンドの利用統計といった機能も搭載されています。

今後は、こういった単体でも利用でき、様々なツールと組み合わせて活用できるバックエンド基盤ソリューションが普及すると考えられます。使い勝手の面や、導入や運用コストが、従来のMEAP製品と比べて優位であるためです。

ただし、こういった製品には開発機能が含まれていません。そのために、HTML5開発プラットフォームであるMonacaやアプリカンといったソリューションと組み合わせた開発が広がっています。実際に、ガートナーは2013年、MEAPに代わってMADP（Mobile Application Development Environment）という概念を紹介し、開発機能とバックエンド運用機能を別軸で捉えはじめています。

モバイルソリューション全般に言えることですが、バックエンドもテクノロジーの進化が早く、ともすると大きな投資の結果、半歩遅れのものができあがるということも考えられます。一方で、エンタープライズ向けのモバイルアプリ開発ソリューションの選択肢も広がってきました。ツールやサービスを組み合わせることで、開発と運用効率を高めることが、今後も求められることになるでしょう。

スマートフォンやタブレットが普及する中で、エンタープライズ分野でのモバイル活用が注目を集めています。特にモバイルファーストという掛け声のもと、B2E（Business to Employee）やB2B（Business to Business）において、スマートデバイスを活用する動きが広まっています。

私としても「多くの企業ではモバイルを活用するのかしないのか」という議論から、「いつモバイルを始めるのか？」「どのように実装するのか？」という内容に論点が移っていることを実感しています。

もう一つの大きな特徴は、事業部門がモバイル化を先導している一方、情報システム部や総務部はセキュリティリスクやBYOD等の対処を迫られていることです。企業モバイル先進国であるアメリカでは、モバイル化を前提として業務の見直しを進めながら、上手くアプリを活用している事例が多く見受けられます。

企業のモバイル活用はカスタムアプリへ

モバイル化を進める上で重要なことは、モバイルでの業務範囲を見定め、その範囲に最適化したアプリを設計することです。モバイル活用レベルに応じて課題も変わってきますが、下記の3フェーズに分けて考えるとイメージしやすいと思います。

エンタープライズのモバイル化における3フェーズ

それぞれの段階によって、必要となる基盤が異なります。フェーズ1や2では、MDMやVPN、セキュアブラウザーといったセキュリティ対策や管理用ツールがその中心的な存在となります。実際に、現状では話題の多くがこの状況を反映しているのではないでしょうか。

今後、モバイル化がさらに推進され、業務をよりモバイルに最適化していく中で、カスタムで開発するアプリの重要性が一層高まっていきます。その中でHTML5が重要な技術として位置づけられ、フロントエンドに採用されていくことでしょう。また、その場合のバックエンド技術についても検討が必要です。

まずは技術的な側面から、エンタープライズモバイルの特徴を紹介したいと思います。

エンタープライズ分野におけるモバイルアプリの技術要件

大きくフロントエンドとバックエンドに分けて、エンタープライズモバイルの技術的な課題について紹介します。

クロスプラットフォーム

App Store等で配信するアプリでは、通常iOSやAndroidといった特定のプラットフォームに向けて開発されるネイティブアプリが主流です。ユーザーエクスペリエンスを高め、ユーザーから高い評価を得ることが最優先されるためです。

一方で、エンタープライズアプリはクロスプラットフォームが選択の中心となります。その背景として、従業員が自分のプライベート端末を業務でも使用する、BYOD（Bring Your Own Device）が挙げられます。企業がBYODを選択すると、マルチプラットフォームでアプリをサポートすることは必須要件になるためです。

また、業務システムは5年～10年という、一般のコンシューマーアプリと比較しても長いライフスパンで使うことが前提となります。そのため、現時点で採用されたプラットフォームに限定したシステムは、メンテナンスのリスクが伴います。移植性がより重要視されるわけです。

開発効率

技術選定の際には、評価軸としてアプリの実行速度よりも開発効率が重要になります。特に、モバイルアプリ開発エンジニアの確保と育成のしやすさ、Webやサーバーサイドといったテクノロジーとの親和性も重要なポイントです。

UIの作りやすさ

モバイル開発全般に当てはまりますが、アプリはビジネスロジックが比較的少ない一方で、ユーザーインターフェースの品質が使い心地に直結します。そのため、ワイヤーフレームやモックアップという形でプロトタイプを作りながら、ユーザーの視点で使い勝手を評価していく開発スタイルが好まれます。

業務アプリと言えども、ユーザーはB2Cアプリの使い心地に慣れているため、コンシューマー向けの開発フローを参考にすることが望まれます。ヌルヌル、キビキビ動く必要はありませんが、PC版の画面から表示項目数を落としてモバイルアプリ化するといった配慮が必要です。

メンテナンスコスト

端末の性能もさることながら、OSとその周辺環境は驚異的なペースで進化しています。その結果、WebやPC版のアプリと比較しても、TCO（Total Cost of Ownership）の中でメンテナンスの占めるウェイトが高く、リリースしてからの改修、改善をいかにスムーズに行っていくかが重要です。その中で機能改修や新バージョンへの対応のしやすさだけでなく、アプリのアップデートのしやすさも大きなポイントになります。

フロントエンド技術の本命はHTML5

さて、コンシューマー向けのアプリとは明らかに性格の異なる要件が連なっていますが、実際の開発技術には変わりがありません。ネイティブアプリやWebアプリなど様々な方式があり、どれも長所と短所を備えています。

その中で、エンタープライズモバイルの要件を満たす最有力候補となるのは、ネイティブアプリにもWebアプリにも対応できるHTML5です。では、なぜエンタープライズ向けフロントエンド技術の本命がHTML5なのか、次回に解説を進めていきたいと思います。

こんにちは、川田です。今日からHTML5 Experts.jpでは「エンタープライズ開発特集」を始めます。第一弾の今回は、HTML5とエンタープライズITについてのオーバービューを語ります。サーバサイドのお話はわりとよく見ますが、フロントエンドにフォーカスしているというのは珍しいようにも思えますね。

IT自体が幅広い分野のビジネスや製品に変わりつつある昨今、「エンタープライズITの話をするぞ！」と言うと、いろんな方面の人からこう問われます。

「そもそも、エンタープライズって何？」

エンタープライズ、正式には「エンタープライズシステム」になりますが、直訳すれば「企業向けシステム」。一言で言うなら「企業のビジネスを支えるための仕組み」を意味します。企業の業務の効率化を進めたり、経営戦略や問題解決を進めるためのワークプロセス(仕事の進め方)と道具(アプリやインフラ)のことです。

エンタープライズのエンジニアの仕事は、技術的な観点から、経営を良くする方法を提案したり、業務の進め方を設計したり、そのために必要な道具(アプリやインフラ)も調達したり、なければ自分たちで開発したり。サーバからクライアントまで、必要なら机の配置の一つまでデザインする(ネットワークも！)。ぶっちゃけ、ITじゃない方が合理的なら、IT化しないなんてのも提案する。スーパーのレジだって「効率化とかどうでもいいから最安値で作って」と言われたら、ソロバンを薦めてしまうという。それが私たちの仕事です。「SCM」とか「CRM」というキーワードで検索すると、そのニュアンスが伝わるかもしれません。

さて、ここで定義したエンタープライズ（システム）において常に関心が高いテーマとしては、「1.システムの運用」「2.業務の効率化」「3.アーキテクチャ」が挙げられると思います。これらの観点から、「HTML5」という技術要素が、これから先の企業のITをどのように良くしていけるのかをみてみましょう。

1. 「システムの運用」はどう変わるのか？

古今東西、エンタープライズは、システムをできる限りいじらずに、長く運用させることがビジネスとして成立する市場です。欧米においても、古いものは企業と政府に最後まで残り続ける傾向にあるというのが、共通の認識になっています。日本ではInternet Explorer（以下、IE）が高い影響力を持っており、多くの企業がIEの特定のバージョンをサポート期間ギリギリまで使い倒すという方法に走りがちです。しかし、今それが変わることを求められています。

マイクロソフトのサポートは基本は最低10年というルールですが、IEにおいてはもはやそのルールは全く通用しません。昨年、Windows8.1発売時にWindows 8版IE10のサポート期間が短縮化され、そして今年の7月にはとうとう、2016年1月12日以降、最新のバージョン以外はサポート対象外とするというアナウンスを行いました。これは、Google Chromeと同じアップデートのポリシーで、システムはこれからIEの最新バージョンがリリースされる都度、IEのバージョンを上げ続けることが求められています。現時点では、約1.5年周期ぐらいになりそうです。

マイクロソフトは、エンタープライズもコンシューマーも、どちらであってもIEが常に最新のバージョンで運用されるよう改善を進めてきています。その成果として、現在の最新のIEはHTML5に準拠し、高い相互運用性を確保しました。これはつまり、バージョン間の動作の違いが非常に小さいということを意味します。彼らとしては、ブラウザの「バージョンアップ」が、従来の「サービスパック適用」や「セキュリティアップデート」程度のものとして扱われればという狙いがあるようです。

Windows XPのSP2は、元々Vistaになる予定の全く別ものなOSと言われていたのですが、それが運用の中でうまく適用できたというのであれば、これはほんの些細な問題なのかもしれません。運用の進め方さえうまく定着すれば、業務システムのクライアント部分は、OSやミドル、ハードウェアのライフサイクルから開放され、セキュリティ・信頼性・パフォーマンスが最適化された状態で、長期に渡り利用することが可能となります。これはエンタープライズITにとって、HTML5がもたらす大きな価値の一つと言えるでしょう。

最新のIEへの移行、HTML5化を進めるには、以下の機能・ツールが有用です。欧米ではユーザー企業だけで音頭を取って進めていけるため、そのモチベーションは非常にシンプルです。しかし、日本はSIerがシステム開発の中心にいるため、調整にはかなり苦戦するかもしれません。2016年1月までと非常に期間は短いのですが、ユーザー企業・SIerの両方が一丸となりこの取り組みを進め、ユーザー企業のシステム費用の最適化と成長に貢献できればよいですね。

• modern.IE：IEのマルチバージョンテストや、問題点を検出するツール。無償のものが多い。何千台も端末がある場合、段階的に最新バージョンのIEへ移行を進めていくにあたり、このツールが有用になる。
• Enterprise Mode：IE11以上で、暫定的にIE7/8の動作をエミュレートさせる機能。最新のIEに移行した後も、古いIE特化のアプリを動かすことができる。
• Compat Inspector：IE8以下の依存性の高い作り込みを検出するツール。Enterprise Modeも長くはサポートされる保証がないため、最新のIEへ移行した後、このツールを活用して改修を進め、Enterprise Modeをなくしていくことが求められる。

2. 「業務の効率化」はどう変わるのか？

近年、デスクトップPC以外のコンピュータのポテンシャルが注目を集めています。ノートPCにタブレット、スマートフォンにウェアラブルと、デスクトップPCにはない機能、ワークフローのモデルを持ったコンピューターを活用することで、従来の業務をより効率的に変えていこうという考え方が、欧米で広がりをみせています。最近のアンケート結果を見ていると、日本でもモバイルの業務活用に抵抗感がなくなりつつあるようですので、恐らくこれから広がっていくことでしょう。

例えば、ホワイトカラーの場合、マネージャーの決裁をリアルタイム化させるという用途が有名です。スマートフォンに決裁イベントの発生を通知させ、内容を表示し、タッチで完了させるというワークフローを実現させるというものです。部下にも使えるものだと、スケジューラとの連携です。これからミーティングが始まるということを、移動時間も含めて計算し、事前に通知するという仕組みです。このような、様々な種類のデバイスを連動させた業務の設計方法を「モビリティ」と呼びます。

モビリティは、単純にWebアプリをタブレットやスマートフォンで見えるようにするだけでは意味がありません。コンピューターが持つ特性に合わせて、設計することが求められます。例えば、先ほどの決裁のシステムにおいて、「通知」という機能がなかったらどうなるでしょうか？タッチ操作に最適化されていなかったらどうなるでしょうか？

使いにくくて、結局デスクトップ型やノートPC型のコンピュータを使うようになるのがオチです。UXへの理解がないことには、導入がうまくいかないのがモビリティなので、モバイルの活用とUXは、多くの場合セットとして扱われているはずです。業務系のUXは、Webのサービスのようにリピーターを増やすためのものではなく、毎日使う道具を効率化させることに意味があり、このあたりの評価軸の違いにも注目すべきでしょう。

また、スマートフォンやタブレットといった道具側にも工夫が必要です。企業向けとして利用する場合、セキュリティの考え方、開発効率にも意識しなくてはいけません。セキュリティについては「MEAP(Mobile Enterprise Application Platform)」が、「IBM Worklight」「SAP Mobile Platform」「Oracle ADF Mobile」などなど、数えきれない程の製品によって、実用化もコモディティ化も進んでいます。一方で開発効率については、HTML5によるハイブリッドアプリケーション開発が注目を集め、これを実装するための「Apache Cordova」がMEAP製品の間でも独占的シェアを得ています。HTML5自体、そもそもモバイルから注目を集め出したわけで、そこまで想像に難くないはずです。

3. 「アーキテクチャ」はどう変わるのか？

最後に、統合化を目指したアーキテクチャについてです。ここでのアーキテクチャとは、個別のシステムにおけるものではなく、全体最適化の観点におけるアーキテクチャです。一つの業務をこなすのに、いくつものログインを繰り返す煩わしさ、複数のシステムに同じ情報を投入しなくてはいけない状況など、連携できていない状況の改善という意味です。

以下3つのポイントが、これからのアーキテクチャを決定付けているように思えます。

• 業務ロジックがAPIを持ち始めている：出足はやや遅れましたが、私の感覚として日本の企業でもパッケージの活用が進んでいるように見えます。パッケージ製品は、SAP NetWeaverやSalesforce APIsといったAPIを持つのがもはや当たり前で、標準としてはODataが広がっています。インフラもAWSのAPIがデファクト標準化しつつあり、認証基盤ですらもSAMLやOAuth(OpenID Connect)のような標準のAPIへとシフトしています。OneAPIやBONDIみたいなモバイル向けアプリ開発の世界観も気になるところです。スクラッチ開発においても、ライブラリ/フレームワークも豊富になり、REST(like)を中心としてAPIの実装コストも落ちていくことでしょう。
• APIを活用する製品が増えている：IBM CognosやOracle BIなどのBIツールや、Apache Camelのようなルーティングエンジン、Backbone.jsやAngularJSといったJavaScriptフレームワークでさえもREST(like)に対応するのが当たり前という状況です。サーバでAPIを繋げるApigeeや、クライアントでAPIを繋げるIFTTTなんかも面白い傾向です。例えスクラッチ開発であっても、アプリは標準的なAPIで繋げた方が、長期的に見てできる事の幅が広がっている時代に突入しています。
• 開発ツールがモバイルファースト化している：モバイルはネットワーク環境が不安定であることが前提であり、サーバサイドとは疎結合にしてクライアントで処理をすることが求められています。こうした中、マイクロソフトの「Mobile-first, Cloud-first Development」、IBMの「Mobile First」と、各製品ベンダの開発ツールがどんどんモバイルファースト前提に変わっています。個人的には、Oracle BI Mobileみたいな、完成された製品でさえもモバイル前提なことに、未来を感じさせられます。

このような状況を鑑みると、世の中のアプリケーションはC/Sモデルへと回帰しているように見えます。クライアントは多くの場合、やはりHTML5のエコシステムの恩恵を受けたくなるはずです。本メディアでも過去に取り上げたような、佐川夫美雄氏の考えるWebベースのリッチアプリケーション開発もその一つと言えます。現在はまだ、APIの集約はBIツールなどを活用してサーバサイドで行うのが一般的なようですが、これから先は、徐々にクライアント側へと移っていくことも想像に難くないはずです。

「あの企業みたいに、こういう経営情報を可視化したい！」「こういうコスト削減を目指したい！」となった時に、「世の中の道具が全く何も使えない！」なんてことにならないためにも、少しずつでよいので世の中の流れに乗っていけるといいですね。素直に新しいベンダ製品を活用していたら、勝手にこんな作りになるわけですが、いかんせんOSSによるコスト最適化、マルチベンダ化、大量のレガシー資産などの要因が邪魔して、そうも簡単にいかないというのが厄介なところでしょう。

さてさて、今回「UX」に「MEAP/ハイブリッドアプリ開発」に「業界標準フォーマット」に「ツール/フレームワーク」と、フロントエンドに関わるいろんなキーワードが出てきましたが、これらをより深堀りしたものが、本メディアにて「エンタープライズ特集」として取り上げられます。企業のビジネスを技術面から良くする、ヒントを与えてくれるに違いありません。

どうぞ、お楽しみに！

ハイブリッドアプリ開発の手法のひとつして、Chrome Appsをモバイルアプリに変換するApache CordovaベースのChrome Apps on mobileについて解説します。これによって、Chrome Appsとして作成したWebアプリがAndroidやiOS向けのネイティブアプリとして公開、インストールすることができるようになります。

Chrome Apps on mobileは、まだデベロッパープレビュー版で、GitHub上でプロジェクトが公開されています。まだデベロッパープレビュー版ということで、Chrome AppsのすべてのAPIを利用できるわけではありませんが、順次対応される予定です。本記事では、そもそも「Chrome Appsとは何なのか？」というところから、Chrome Apps on mobileの開発環境の構築やビルド、実行までひと通り見ていきます。

Chrome Appsとは？

Chrome Appsとは、単にChromeで動作するWebアプリというわけではなく、Chromeウェブストア上で配布・販売できるアプリケーションプラットフォームです。通常のWebアプリをChrome Appsとしてそのまま公開することもできますし（若干のマニフェストファイルを書く必要はあります）、Chromeに実装されている高機能なAPIを利用して、よりリッチなWebアプリを作ることもできます。

Chromeウェブストア

例えば、通常のWebアプリをChrome Appsとして公開する場合（Chrome独自のAPIを利用しないケース）、次のようにマニフェストファイル「manifest.json」とバックグラウンドで動作するJavaScriptファイル「background.js」を記述し、Webアプリのファイル一式と同梱することによって簡単にChrome Appsとして動作させることができます。

ChromeAppSample （任意のフォルダ）
      ├── index.html （Webアプリ本体一式を同梱する）
      ├── manifest.json
      └── background.js

{
  "name": "Chrome App Sample",
  "version": "0.1",
  "app": {
    "background": {
      "scripts": ["background.js"]
    }
  }
}

chrome.app.runtime.onLaunched.addListener(function() {
  chrome.app.window.create('index.html', {
    'bounds': {
      'width': 400, 'height': 500
    }
  });
});

また、Chrome Apps上では、独自のChrome APIを使って、さらにリッチなWebアプリを作ることも可能になっています。Chrome Appsの作成方法についてのより詳細な情報は、公式ページの「What Are Chrome Apps?」にまとまっていますので、参考にしてください。簡単に試してみたいという場合は、「Create Your First App」を試してください。

開発環境の構築

まずは、Chrome Apps on mobileの開発環境を構築します。Chrome Apps on mobileは、iOSのバージョン6以降、Androidのバージョン4.0以降を対象にしています。どちらを対象にするかによって必要なツール・ライブラリが異なりますので、対象に合わせて準備しましょう。いずれの環境でも必要なのは、Node.js (バージョン0.10.0以降)です。既にインストールされている場合は必要ありませんが、まだの場合はWindows、Mac（またはLinux）いずれでも、こちらからダウンロードしてインストールしておきましょう。さらに環境によって次のようなツール・ライブラリが必要になります。

Androidの場合

• Java JDK7 以降
• Android SDK 4.4.2 以降（ sdk/tools と sdk/platform-tools をPATHに追加する）
• Apache Ant（ apache-ant-x.x.x/bin をPATHに追加する）

iOSの場合

• Xcode 5 以降
• ios-deploy（iOSデバイスにデプロイする際に必要です）
  > npm install -g ios-deploy
• ios-sim（iOSシミュレーターにデプロイする際に必要です）
  > npm install -g ios-sim`

※ Appleストアに公開する場合は、iOSデベロッパー登録が必要です

ccaコマンドラインツールのインストール

最後に、Chrome Apps on mobileのツールとしてccaコマンドラインツールをインストールします。

> npm install -g cca

既に、ccaがインストール済みでアップデートをする場合は、npm update -g ccaを実行しましょう。ccaのインストール後に、次のコマンドでAndroidおよびiOSの開発環境が揃っているか確認できます。

Android SDK detected. Xcode detected.

「Android SDK detected.」と「Xcode detected.」という結果が表示されればOKです。片方のみの環境であれば、いずれか片方だけが表示されます。例えば、Android環境のみの場合は、「Android SDK detected.」だけが表示されます。

プロジェクトの作成とビルド、実行

開発環境の構築が終わったら、実際にプロジェクトを作成してビルド、実行してみましょう。ccaコマンドツールを使って次の手順で行います。

プロジェクトの作成

• 新規にプロジェクトを作成する場合 > cca create ChromeSampleApp カレントディレクトに ChromeSmapleApp というフォルダが作成され、プロジェクトが作られます。

• 既にあるChrome Appsを元にプロジェクトを作成する場合

既にChrome Appsを作成済みであれば、オプションでそれを指定します。指定方法には、次の2種類があります。

> cca create ChromeSampleApp --link-to=path/to/manifest.json

作成済みのChrome Appsのマニフェストファイルの場所を指定します。 path/to/を皆さんの環境に合わせて置き換えてください。--link-toオプションでは、指定したフォルダへのシンボリックリンクでプロジェクトが作成されます。

> cca create ChromeSampleApp --copy-from=path/to/manifest.json

--copy-from オプションでは、指定先のフォルダをコピーしてプロジェクトが作成されます。

ビルド、実行

プロジェクトの作成が終わったら、いよいよビルドし、実行してみます。こちらも非常に簡単で、プロジェクトのルートフォルダ上で、次のようにccaコマンドを実行するだけで済みます。

• Androidのエミュレータで実行

> cca emulate android

※ Androidのエミュレータが設定されていない場合、android avdコマンドでセットアップする必要があります

• Androidの実機で実行（デバイスをUSBデバッグモードで接続します）

> cca run android

• iOSのシミュレーターで実行

> cca emulate ios

• iOSの実機で実行（デバイスをUSBで接続します） > cca run ios

それぞれの環境に合わせて、cca emulate または、cca runで簡単にビルド、実行することできます。単純にビルドするだけであれば、 cca buildで可能です。是非試してみてください！

iOSシミュレーターで実行

Chrome App Developer Tool

Chrome Apps on mobileには、実際のデバイス上でChrome Appsを動作させつつ、開発（修正）＞ビルド＞実行のイテレートを高速に回すことができる開発ツール「Chrome App Developer Tool」が用意されています。

Chrome App Developer Toolは、モバイルアプリですので、実機にインストールする必要があります。Androidの場合は、こちらからapkファイルをインストールして使用することができます。（iOSの場合は、ソースコードからビルドする必要がありますので、公式サイトの「Building from Source (iOS or Android)」を参考にインストールしてください）

Androidの場合、Chrome App Developer ToolをインストールしたデバイスをUSBデバッグモードで接続し、次のようにコマンドを実行します。

> adb forward tcp:2424 tcp:2424

cca push

adb forwardコマンドは、デバイスを接続後に1回だけ実行します。その後cca pushコマンドで、Chrome App Developer Tool上でChrome Appsが動作します。これは、ビルドせずにChrome AppsをそのままChrome App Developer Toolに転送して動作するため非常に高速です。

Chrome App DevTool起動

cca push後

Chrome App Developer Toolで動作しているChrome Appsを終了するには、2本指で同時にダブルタップします。

また、cca push --watchコマンドでプロジェクトに変更があれば自動的にpushするということも可能です。ソースコードを修正しながら実機で逐次、動作確認できるのでおすすめです。

まとめ

Chrome Apps on mobileは、デベロッパープレビュー版ということで、まだまだこなれていない面もありますが、Chrome Appsがそのままモバイルで動作するということで非常に楽しみなプラットフォームです。単なるWebアプリをモバイルアプリにするのであればPhoneGapなどの方が簡単ですが、Chrome APIを利用したパワフルなChrome Appsを作って、Chrome Apps on mobileにチャレンジしてみてください！

現在対応している・今後対応するChrome APIのステータスは、こちらから確認することができます。高機能なAPIの多くは、これからの対応に期待ですが、ぜひ楽しみにしていただきたいと思います。

概要

Google I/O 2014のセッションの1つ「Making music mobile with the Web」のレポート記事です。Officialに公開されているYouTubeはこちらです。

OpenWeb 技術であるWebRTC、Web Audio APIは一度は耳にしたことのあると思います。この2つの技術、そして標準化が始まったばかりのWeb MIDI API（電子楽器とブラウザを直接接続するAPI）を利用した音楽制作アプリケーション「Soundtrap」。これらを使って、実際にセッションのオーディエンス、遠隔地の人とコラボレーションをして、Google I/Oのテーマ曲を作成するデモンストレーション中心のセッションでした。本レポートと合わせて映像もぜひご覧ください！

このセッションでは、主にモバイル端末（Nexus 7、Nexus 5）を使って進行されました。Webアプリといえば、JavaScriptでの構築を想像される方も少なくないので意外でした。しかしながら、「Soundstrap」はDartで開発されていたところでした。(開発言語にDartを選択した理由も、後ほど説明していきます)

それでは内容を見ていきましょう。

※2014/7/4にDartは、ECMA標準仕様として承認されたと発表がありました。

音楽制作

音楽制作にはいろいろな進め方がありますが、このセッションでは以下の順で録音が進められました。

1. リズムの選択 (1:49-)
2. Bass の録音 (3:02-)
3. Guitar(メロディー)の録音 (15:11-)
4. Keyboard(伴奏)シーケンスの作成 (16:28-)
5. Vocal の録音 (23:30-)
6. Mix Down (34:55-)

1. リズムの選択

曲のベースとなるリズムを決めます。Soundtrapにあらかじめ用意されているLoop素材を追加し、リズムを聴きながら「ん～」とか「もっとRockしてるのがいいな～」とかコメントしながら選択を終えました。

2. Bassの録音

Bassの音はあまり耳には聞こえませんが、実は曲の重要な土台となる低音パートです。 Bassの録音をすると、リズムしかなかった曲の輪郭がモヤっと見えてきます。

Bassを録音する様子

Media Capture APIの1つである、getUserMedia()を使って録音します。

getUserMedia()は、マイクからのInput、WebカメラからのビデオStreamを取得する時に使います。マイクからのInputを取得する時は、スピーカーからの出力をマイクが拾わないようにAEC(Acoustic Echo Canceling)、またマイクからのInputのレベルを保つために AGC(Auto Gain Control)を行うことが可能です。マイク以外の入力を取得する場合（Line入力：ギター、シンセサイザー等）は必要ないので、今回もOffにします。コードは以下のように書きます。

navigator.getUserMedia({audio:{echoCancellation: false}}).then((stream) {
  // 実際の処理をここに書きます
});

then() が見慣れない書き方かもしれませんが、これはDartに実装されている Futureという並列処理デザインパターンです。streamを得た時にどんな処理をするのかを、then()の中に書きます。

3. Guitar（メロディー）の録音

Guitarで主旋律パートを録音します。主旋律ですので向かう方向がハッキリします。

Guitarの録音をする様子

Bassの録音と同じく、getUserMedia()を使って録音します。

特にギターの場合、エフェクターという専用の信号処理機械を通して音を作ることが多いです。エフェクトの種類は音を遅らすDelay、音程を微妙にズラすことで複数でコーラスをしているかのようなハーモニーを作るChorus、音を歪ませることで音に角を付け、いわゆるエレキギターと聞いて想像する音を作るFuzz、Distortion、Overdriveがありますが、これらのエフェクトもブラウザで行ってしまいます。（セッション内でのデモ）

これらのエフェクトは、以下のように接続します。

Input(getUserMedia()からのAudioStream)をWebAudioで作成したEffectsを通し、WebAudioでの音声の出力口であるDestinationに接続します。

Delayエフェクトの接続方法を例にとって、実際に説明をします。

Guitarの音(Input)を直接Destination、またDelayに接続します。Delayで任意の時間遅らせて発音した音を、Gainに接続して音量を絞ります。最後にDelayで遅らせ、音量を絞った音をDestinationに接続します。結果としてギターで弾いた音は、山に向かって「ヤッホー」と叫びやまびこを楽しんでいる人の隣で聞いているかのような効果、つまりEffectが得られるのです。

この接続をコードにすると、以下のようになります。

var context = new AudioContext();

// getUserMediaのAudioStreamをWebAudioに接続する
navigator.getUserMedia({audio:true}).then((stream){
  var guitar = context.createMediaStreamSource(stream);
  var speaker = context.destination;
  guitar.connect(speaker);
});

// Delayエフェクトの接続
var delay = context.createDelay();
guitar.connect(delay);

var gain = context.createGain();
delay.connect(gain);

// Delayエフェクトをかけた音を、出力口のSpeaker(Destination)に接続
gain.connect(speaker);

4. Keyboard(伴奏)シーケンスの作成

そして、Keyboardで伴奏パートのシーケンスの作成を行います。伴奏が入ると曲がハッキリし、各楽器通しでハーモニーが生まれます。

左下小窓がMoscone Center West、全体がGoogle San Francisco OfficeからWebRTC でStreamingしている様子

WebRTCを使って、上の画像のように遠隔地から行います。Google I/Oの会場であるMoscone WestとGoogleさんのSan Francisco Officeを接続し、シーケンスを直接Soundtrapに作成します。Keyboardの演奏はWeb MIDI APIを使い、Keybord（電子楽器）とブラウザを接続して演奏データはMIDI Messageの形式(音声データではなく、「どの音を、どの強さで鳴らせ/止めろ」というような指示を表現したメッセージ)で時間と一緒に記録（シーケンスの作成）を行い、再生する時には記録された時間通りにMIDI MessageをSoundtrap上にあるSoftwearシンセサイザーに送信して、Softwareシンセサイザーが音を出しています。

セッションの中で説明はありませんでしたが、Web MIDI APIを使って電子楽器とブラウザを接続するコードを以下に紹介させていただきます。

// 電子楽器と接続
navigator.requestMIDIAccess({sysex:true}).then(successCallback, errorCallback);
function successCallback(access){
　// 入力として利用可能な電子楽器のリストをConsoleに出力
　var inputs=access.inputs()
  console.log(inputs);

　// 入力として利用可能なindex=0の電子楽器から受信したMIDI MessageをConsoleに出力
  inputs[0].onmidimessage=function(event) {
    console.log(event.data);
  }

　// 出力として利用可能な電子楽器リストをConsoleに出力
  var outputs=access.outputs()
  console.log(outputs);

　// 出力として利用可能なindex=0の電子楽器にMIDI Messageを送信
  // A4(ラ：440hz、MIDI Key番号：0x45(69))を最大音量(7F(127)で発音させる例)
  outputs[0].send([0x90, 0x45, 0x7f]);
}
function errorCallback(msg) {
  // 何らかの問題で電子楽器との接続ができなかった場合、Consoleにエラーメッセージを出力
  console.log(msg);
}

※JavaScriptでの書式になります。 .then()に関して、書式はDartとJavaScriptで同じですが、Dartでは Futureという並列処理デザインパターン、一方JavaScriptではPromiseという並列処理デザインパターンですので、内容は正確にいうと異なりますのでご注意ください。

次に、WebRTCの接続についてです。WebRTCは、RealtimeにPeer to PeerでAudio、Video、Dataの3種類のStreamを使ったコミュニケションができるAPIです。接続には、PeerConnectionを使います。Soundtrapにてビデオチャットを行いながら音楽制作を行うためには、ビデオチャットを行うWebcam stream、音楽制作用に楽器のステレオ音声を送るStereo music streamが必要になります。

ビットレートはそれぞれStereo music Streamが128Kbps、Webcam streamがVP8 HD 2Mbpsで、PeerConnectionを使ってStreamしています。

5. Vocalの録音

録音の最後はVocalです。これで曲のメイン素材の録音、作成が完成です。

Nexus 5を片手に会場で歌声を録音する様子

Vocalの録音はNexus 5(携帯電話)を使用して、getUserMedia()を使って録音を行います。実際に歌うのはセッションのオーディエンスです！！（私の声も聞こえるかもです）マイクではなく、携帯電話をマイク代わりにして、Soundtrapに直接録音を行います。

6. Mix Down

「マスタリング」とも呼ばれ、各パート毎に音量の調節、音程の音量調節(Equalizing)、また残響(Reverb、Echo)の調節を行うことで各パートの音のバランスをとり、ハーモニーを深め、そして際立たせます。

SoundtrapはCloud型の音楽制作Webアプリケーションですので、インターネットに接続できる環境があればどこからでも音楽制作に参加することができます。もちろん、Mix Downをすることも可能です。セッションでは、Keyboard を弾いていた場所(GoogleさんのSan Francisco Office内で、セッションはMoscone Westです)でMix Downが行われました。

SoundTrap上に各パートが録音された状態

その結果、Google I/Oのテーマ曲はこのように仕上がりました。（下の画像をクリックすると視聴できます）

波形をWebGL表示した背景と共に再生されました

こちらは Soundtrap内に保存されている音源をそのまま視聴できます 。試聴する

開発言語にDartを選択した3つの理由

冒頭に、Soundtrapの開発にDartが採用されたことに触れました。以下の3点が、Dartを選択した理由だそうです。

親しみやすさ(Familiarity)

Dartはとにかく簡単に学べるようにと考えられて作られいて、Class や単一継承にセミコロン、中括弧を使うところがJavaScriptや、Java、C++にとても似ているので開発者にはとても親しみやすい。

拡張性(Scalability)

Webアプリの開発はとても小さなスクリプトから開始し、それが成長して大規模で複雑なアプリになっていく。従って大規模になった時のことを考えると、スケールアップができる環境で開発を開始することが望まれる。DartではそれをLibrary、またPackageという形で実現している。

Soundtrapの開発は、これらのDartの拡張性によってアプリが大規模になった時でも、開発のスピード（生産性）を落とすことなく進めることができたそうです。

生産性(Productivity)

Dartで開発する時は、Dart Editorを使うことができます。このEditorではコードを静的監視しているので生産性がとても高いです。例えば、静的監視されているので、アプリを動作させなくても、Unitテストを走らせなくても構文エラーをリアルタイムに知ることができるのできます。つまりDart Editorは、世の中にある熟れたIDEと同じような機能が搭載されているツールになっているので、不自由はなく、生産性高く進めることが可能です。

まとめ

Soundtrapは、OpenWeb技術であるMedia Capture、Audio Processiong、Real-time CommunicationのAPIの紹介にはとてもよいアプリケーションです。今回はChrome上で動作させて紹介しましたが、これらの技術はOpenWeb技術ですので、デスクトップ、モバイル環境にある別のブラウザでも動作させることが可能です（可能になるでしょう）。また、これらの技術を使うことのできる世の中のデバイス数は、以下の通りです。

• Web Audio 20億のデバイス（10億がモバイル）
• WebRTC 15億のデバイス（3億がモバイル）

そして Android LのWebViewではChrome V36相当になりますので、Web Audio、WebRTCがほぼすべてのAPIをサポートされた形で使えるようになります。30日でのアクティブユーザ数が10億のAndroidという環境ですので、ものすごく多くのユーザーに対して、これらを使ったアプリケーションの提供が可能になるため、そのインパクトは絶大です。

Q&Aで質問が出た項目

Q. Android LでのAudioのLatencyについて教えてください。

A. 数値の約束はできないが、改善に向けて真剣に取り組んでいる。ICS、JB、Kitkatで20msまでLatencyを短縮することはできた。しかしながら、我々としてもまだまだ満足はしていないので改善していくだろう。

Q. MIDIのサポートについてどこまで進んでいるのか教えてください。

A. Web MIDI APIはOpenWebStandardとして標準化が始まったばかりで、Chromeは先行して実装を行った。次期、またはその次のVersionでは全ての機能の実装を行い、さらにFlagの設定なしでの動作させる予定です。セッション内でSoundtrapで利用しましたが、もちろんセッション内だけなく、Soundtrap内ではMIDIの接続も利用することが可能です。
Chrome以外のブラウザでのサポートに関しては、現状様子見を行っています

Q. Mix Downはクライアントサイドで行っているのか、サーバーサイドで行っているのか教えてください。

A. 音源はクラウド上のサーバー側にあって、再生をクライアントで行っています。サーバサイドはJavaとScalaで利用可能なPlay Frameworkを使っています。クライアント側で再生する時は、サーバー側でMix DownしたMP3ファイルを作成し、それをSoundtrapというクライアントアプリ側で再生をするという仕組みになっています。

セッションを終えて感じたこと

Before Web Audio/MIDIの時代では、DAW（音楽制作用ソフトウェア）を購入し、Audio I/F、キーボード、マイク等のハードウェアを揃えながら満足できる音楽制作の環境を整えるまでには、いささか道のりが長く時間がかかるのが常識で、またそこを楽しむこともありました。

しかし、Webブラウザで、デスクトップはもちろん、モバイルデバイス上での制作、さらには遠隔地とつないで、誰でも手軽に音楽制作に手を伸ばすことのできる時代（味見も含めて）なのだなと改めて感じました。制作はもちろんですが、ツールの作成、エフェクトの作成等、少し頑張れば、かゆいところに手の届くいわゆるオレシステムを作り上げることもそこまでハードルは高くないと思います。

今やアマチュアバンドとはいってもホームページを持ち、そこには自ら制作した楽曲、さらに自らで制作したであろう、とはいえクロリティの高いプロモーションビデオまでも揃えて公開する時代。昔はインスピレーションを得たらその場でフレーズやパターンの作成ができ、モバイルできる音楽制作専用ハードが流行した時もありました。

これからはインスピレーションを得たらポケットからさっとモバイルな汎用デバイスを取り出し、ブラウザを立上げDAWのURLに接続をし、その場でフレーズのみならず全体の流れを録音し楽曲にまとめることも容易になるでしょう。そして、遠隔にいる友人にバッキング、Mix Downしてもらい、その場でプロモーションビデオまで制作する一連の流れを即興でできてしまう、なんていうアマチュアでもプロ顔負けの音楽制作環境を持てる、素晴らしい時代が確実に来るだろうと感じました。同時に、これらの音楽制作に欠かせない技術と他のOpenWeb技術を連携させることでどのような新しい表現方法、また価値、文化が生まれるのかワクワクを膨らませてきた次第です。

W3Cの一員として標準化を進めているWeb MIDI API。今回は少しだけ登場し、スライドとしての説明はありませんでしたが、音楽を制作をする上ではコアになる技術です。標準化までこぎつけられるように強く推進をしていかねばとも感じました。

紹介されたURL等

• Soundtrap：デモで使われたOpenWeb上に構築された音楽制作環境
• Getting Started with WebRTC：WebRTCのチュートリアル（英語）
• Getting Started with the Web Audio API：Web Audio APIのチュートリアル(日本語)
• Get Started with Dart：Dartのチュートリアル（英語）

こんにちは、川田です。Googleはここ最近、デスクトップ向けWebに対して、ほとんどの関心を失っているように見えます。HTML5ブームも過ぎて、やることがなくなってしまったのでしょうか？……いえいえ、そうでもありません。昨今の待ったなしで進む技術革新の中で、彼らは「ある問題」と戦っているようです。

Webは「モバイル」中心の時代へ移っていく

Google Inc. First Quarter 2014 Results

すでにご存知の方も多いと思いますが、GoogleのビジネスモデルはWebに強く依存しています。2014年1Qの決算で、Googleは全売上の約68%が自社のWeb系サービスの広告収入であり、約22%はAdsenseなどの他のWebサイト向けの広告であると報告しました。Webに依存したビジネスが実に9割を占め、1日に約120億円の収入をWebから得ています。もっと簡単に言えば、Webだけで、タイの国民全員の給料分ぐらい稼いじゃってます。当然、Webの進化をやめてしまうなんてことは、考えにくいでしょう。

彼らにとって、利用者がどこからWebにアクセスするのかは、とても重要な情報となります。むしろ、Googleに限らず、Webでサービスを提供している全ての人にとっても重要なことでしょう。人々は普段、どんなコンピュータを使っているのか？どのようなデバイスからインターネットにアクセスするのか？そのことが、私たちのビジネスにとって大きな意味を持ちます。

そしてここ最近、Googlerがいろいろな発表の場でよく口にしているのが「モバイル」というキーワードです。これから先、Webの利用者はモバイルからやってくると、Googleは考えているようです。そのことを証明するかのように、現場の開発者からマーケティング・経営者まで一丸となって、これからやって来るモバイルの時代に向けた取り組みをアピールしています。

“AndroidとChrome、2つの巨大なオープンプラットフォームについて。スマートフォンは2013年4Qに、3.15億台の出荷があった。Androidは毎年利用者が倍増しており、現在は10億ものアクティブユーザがいる。将来的にはAndroidを、50億人にリーチしたいと考えている。” —— Google 経営者 Sundar Pichai (Google I/O 2014 – 2014.06.25)

“2014年1月に、ChromeのレンダリングエンジンであるBlinkをどう変えていこうかという話し合いをした。結果としては『モバイルが大事』ということになった。デスクトップよりもモバイルの方が売れているし使われる。しかし開発者の立場から見ると、残念ながらWebよりネイティブの方が多いという状況だ。我々はHTML5の問題点をヒアリングし、改善を進めている。” —— Google Chrome開発者 及川卓也 (HTML5 Night – 2014.06.14)

“アメリカの成人の34%にとって、主要のインターネットアクセスはスマートフォンだ。モバイルのトラフィックは増加しており、来年にも過半数のユーザがモバイルでインターネットを利用することになる。” —— Google Webコンテンツ開発者 Paul Lewis (Google I/O 2014 – 2014.06.26)

モバイルであることが前提の、Webとパフォーマンス

モバイルは、Web開発者/制作者にとっては厄介な存在です。動作環境が増えるのですから、デザインにコーディング、動作テストと、やらなくてはいけない作業も増えてしまいます。Googleは、その手間をできる限り省き、コンテンツ制作に専念できるようにしようと考えています。その成果の一つが、「Material Design(マテリアル・デザイン)」です。

UXの向上を図る上で、デザインは重要です。ただ、デザインだけではどうにもなりません。「パフォーマンス」も欠かすことのできない重要な要素なのです。Google I/Oでは、多くのエンジニアが「Polymer」「Material Design」「Android」など、宝物のような名前がついたキーワードに目を奪われました。実際にメディアでも、これらのキーワードが大きく取り上げられています。しかし、冷静に見るとそれなりの数の「パフォーマンス」をテーマとしたセッションが開かれています。パフォーマンス改善はすごく地味だけど、すごく重要な取り組みと彼らは認識しているのです。

Googleでは「PageSpeed Insights」と呼ばれるサービスを提供しています。イベントに参加していると、割と頻繁に目に入りました。Paul Lewis氏のセッション「Mobile Web performance auditing」では、その活用方法についてかなり具体的なアイデアと共に紹介しています。その内容を見てみましょう。

「PageSpeed Insights」とは、Webに公開しているページのURLを与えると、そのページの問題点、改善方法を提案してくれるGoogleのサービスです。競合するものとして、マイクロソフトの「modern.IE site scan」が挙げられますが、こちらはWebコンテンツのポータビリティを評価する方向に力を入れています。パフォーマンス改善という観点では、Google側の方がより尖っているという印象です。タブが「Mobile」が最初になっている点からも、彼らの作るツールがモバイルファーストの思考で動いているというのを感じとれます。

さっそく、私がはてなで運営しているブログをPageSpeed Insightsで評価してみたところ、Mobile-60点/Desktop-28点/UX-99点という結果でした。Paul Lewis氏いわく、それでは全然ダメとのこと。PageSpeed Insightsでのスコアは、大体目安として、Mobile-85点以上/Desktop-90点以上/UX-100点が望ましいそうです。いくつか日本のブログサービスでテストしてみたのですが、この条件が満足できているのを見つけることができませんでした。それどころか、Google自身が提供しているサービス「Blog Spot」ですら、この条件を満足できていません。そこまで頑張らなきゃいけないのかと、その必要性に疑いの目を持ってしまいます。

ところが、Paul Lewis氏いわく、200ミリ秒の遅延が0.3%の機会損失に繋がると。パフォーマンスの改善が、そのまま収益に結びつくのだと強く主張しています。Webは速ければ速いほど、価値を発揮するのです。もちろん、それを実現するにはそれなりにコンピュータ科学の知識を必要とするわけですが、私たちエンジニアによる純粋な技術による改善で、利用者の増加に貢献できることが残されているというのは、大変喜ばしいことでしょう。

パフォーマンスの問題について、Paul Lewis氏は「Page Speed」と「Runtime」の2つの観点から、その対策方法について紹介がありました。この2つを軸に、他のGoogle I/Oのセッションの内容も交えながらその考え方について見つめてみましょう。

Page Speedはどのように改善するのか？

Page Speedの改善とは何か？単純に言えば「Webページの表示を3秒以下に抑えよう」ということです。そのための方法として、Paul Lewis氏は以下の方法を提案しています。

1. リソースを最適化せよ(Optimize resources.)

Webページを構成するデータのうち、平均63%が画像ファイルです。最適化が必要となります。画像ファイルの圧縮を改善すると、データ量は大きく削減されます。CSS/JavaScriptについても、不要なスペースなどを削って圧縮(Minify)するとよいでしょう。

(補足：のちに説明がありますが、これらはプリプロセッサーの活用を習慣付けるとよいでしょう。人間の手でやっていてはキリがないので、徹底的に自動化させてしまうことです。)

2. リクエスト数を減らせ(Reduce the number of requests.)

リクエストはWebページの表示をブロックさせることがあります。リクエスト数が減るとそれだけ表示が速くなことを意味します。

(補足：SPDYやHTTP2.0が関わってくると、リクエスト数だけでなく、コネクション数も重要になってきたりしますね。いずれにせよ、少ないことはよいことです)

3. リダイレクトをやめろ(Avoid redirects.)

リダイレクトにはDNSの名前解決、TCPコネクションの接続など、Webページの表示までに要する時間が長くなります。パフォーマンスを意識するなら、リダイレクトさせてはいけません。

(補足：モバイルの場合、よくあるのは「m.〜〜」というURLにリダイレクトされるケースです。当然ですが、その処理を行うためにWebページ読み込みのパフォーマンスは劣化することになります。日本の場合は、モバイル網のDNSサーバのパフォーマンスが問題となることも少なくありません)

4. レンダリングの順序に優先度をつけろ(Prioritize for the critical rendering path.)

Webページ全てを読み込んだ時間よりも、見えている領域の読み込み完了(Visually Complete)に、利用者は関心を示します。そこに優先度を高く持っていくべきです。

(※補足：実際に、W3CのWeb-perf WGでも、Resource Prioritiesという仕様の検討が進められていますね。jQueryだと、LazyLoadプラグインがあり、画像ファイルの読み込み順序をコントロールすることができます)

一連の作業は、GruntやGulpが助けてくれます。利用してみるとよいでしょう。

Runtimeはどのように改善するのか？

Runtimeの改善とは何か？単純に言えば「Webページを60FPSで動かそう」ということです。一般的なディスプレイ(スクリーン)は約1/60秒周期で内容が更新されるため、アニメーションなどの処理はその特性に合わせていくことで、滑らかな動きを実現することができます。そのための方法として、Paul Lewis氏、Paul Irish氏は以下の方法を提案しています。

1. 変形や透過によるアニメーションは制限しろ(Restrict animations to transforms and opacity.)

処理コストの高い描画計算処理は控えるべきです。DOMの形状が変わるとLayout処理のコストは増大するし、透過処理などはPaint処理をコスト増大させます。このような「Expensive Animations」は、約1/60秒以下での処理に収まらないことがあり、注意する必要があります。

2. requestAnimationFrameを使え(Use requestAnimationFrame.)

画面のリフレッシュレートに合わせて、アニメーション処理は実行させるようにしましょう。例えば、setIntervalなどを利用し、16ms周期でコールバックさせ擬似的にリフレッシュレートを合わせようとすると、タイミングがズレて無駄が起きます。画面のリフレッシュレートに合わせるには、requestAnimationFrameと呼ばれるAPIを利用する必要があります。

3. レイアウトの値を読み込んでから書き出せ(Read layout values, then write.)

レイアウト(DOM)の値は変数のように扱ってはいけません。横幅などの取得が必要であれば、最初に取り出してキャッシュしておきましょう。読→書→読→書を繰り返すと、無駄なLayout処理が何度も発生するという「Layout Thrashing」という現象が起きます。読→読→書→書が理想です。

4. メモリ効率の高いJavaScriptを(Write fast, memory-efficiant Javascript.)

メモリを消費するようなJavaScriptの記述方法は、Garbage Collection処理が発生し、1/60秒以内での処理が完結しなくなることがあります。JavaScriptの書き方に、工夫が必要です。

モバイルChromeの解析は、「chrome://inspect/」でできます。お試し下さい。

難しくなってきている、なんて思いませんか？

これまではデスクトップPCが一つあればなんとかなっていたWeb開発も、作るための環境と動かすための環境が分離されて、どんどん複雑になってきているなぁという感触を得ています。プレゼンの時も、わざわざカメラを切り替えてモバイルのスクリーンを表示したりなんかしてて「エレガントさに欠るなぁ」「面倒くさいことやってるなぁ」なんて思ったりもしました。もっと言えば、デモしている姿を見てて「モバイル、めちゃくちゃ使いにくそうに扱ってますよね！」「本当はPCでやりたいとか思っていませんか？」なんてことも、率直な印象として感じました。

こういう不満を感じられることは、本当の本当に幸せに思えたりもします。Googleが悪いとかAppleが悪いとかMicrosoftが悪いとかじゃなく、IT業界全体として、まだまだ発展途上にいると感じさせられるのです。これからもっとよくしようと、動き出せるきっかけがいくらでもあるように思えるのです。もっともっと、進化しますよ！

みなさんはどう思いますか？私はWebの未来に、夢を見過ぎでしょうか？

アプリカンは、純国産のハイブリッドアプリフレームワークです。いつも使っているエディタだけでアプリが作れるので、開発環境のOSも選びません。

アプリカンは2013年末に公開され、ハイブリッドアプリフレームワークとしては後発ですが、他のフレームワークとは異なるアプローチとして、様々なパートナー企業のサービスのSDKを組み込み、AR機能や、位置情報連動サービスなど複雑なサービスオプション機能を JavaScriptから簡単に呼び出せるようになっています。

基本は無料で利用できますが、前述の高機能なオプションを使ったり、無料ビルドしたアプリに表示される広告バナーを外す場合には有料となります。

アプリカンの開発に必要なもの

• エディタ
• 好奇心

アプリカンの開発には、IDEを用意する必要はありません。 テンプレートとなる web.zip をアプリカンのサイトからダウンロードして開発マシン上で解凍し、そのフォルダの中に HTML5、JavaScript、CSSを作り込んでいき、できあがったものを zipで圧縮して、サーバーにアップロードするだけです。

デバッグは、iOS、Androidそれぞれのアプリマーケットからダウンロードできる アプリカンシミュレータで行います。

Hello アプリカン World

それでは実際にアプリカンでお約束のHello Worldを作ってみましょう。

アプリカンでのアプリ作成は3ステップ

1. アプリカンサイトにユーザ登録
2. HTML5、CSS、JavaScriptでコンテンツを作成
3. ZIP圧縮して、アプリカンサイトにアップロード

この3ステップで、iOSアプリとAndroidアプリを同時に開発することが可能です。

1. アプリカンにユーザ登録を行う。

アプリカンサイトにユーザ登録します。

ユーザー登録、ログインが完了したら、基本になるテンプレートをダウンロードしましょう。

ユーザー画面の左サイドバーのメニューから各種ライブラリをクリックし、新しく開いたウィンドウから【シンプル】をダウンロードしましょう。

2.HTML5、CSS、JavaScriptでコンテンツを作成

ダウンロードしたweb.zipを解凍すると、index.html、applican-config.xml、jsフォルダの中には applican-1.5.jsが出てきます。

今回はHello Worldを表示するだけなので、 index.htmlを編集します。いつもお使いのエディタで index.htmlを開き、“タグの中の”SAMPLE”を “Hello World”に書き換え保存して終了します。

3.ZIP圧縮して、アプリカンサイトにアップロード

webディレクトリごと ZIPファイルに圧縮できたら、それをサイトにアップロードします。先ほどのアプリカンサイトにログインした状態から、プロジェクトを作成します。

[新しいプロジェクトを作成]をクリックし、プロジェクト名、対象デバイス、プロジェクトの説明を入力し、作成ボタンをクリックします。

プロジェクト一覧に先ほど作成したプロジェクトができているので【選択】ボタンをクリックします。

プロジェクト画面で【アップロードへ】を選択し、画面の指示に従って先ほど作成した ZIPファイルをサーバにアップロードします。

アプリカンで作成したアプリは、本番ビルドをかける前に、シミュレータ上で動作確認を行うことができます。iOS端末、Android端末でそれぞれのストアを開き、「アプリカンシミュレータ」を検索しインストールしてください。

アプリカンサイトに登録したユーザー名、パスワードを入力すると、先ほど作成したプロジェクト名が表示されるのでそれをタップし、Hello Worldが表示されることを確認してください。

アプリカンならではの魅力

アプリカンには、オプションサービス（有料）として、パートナー企業の提供するサービスのSDKを組み込んだベースアプリが用意されています。

現在用意されているサービスには、 – Remote TestKit (アプリ検証サービス) – app C cloud (CPI広告) – ARAPPLI PLUS (ARアプリ開発) – popinfo (PUSH通知サービス) があります。 これ以外にも、高速なデータ転送を実現するプロトコルスタックオプションや、OCR機能を実現するオプションなどが順次リリースされる予定です。

PhoneGapの概要と歴史

PhoneGapとは、ハイブリッドアプリのフレームワークです。つまり、HTML5コンテンツをラッピングして、いろんなデバイスやOSでネイティブアプリとしてインストール可能なアプリケーションを作成できる技術です。元々は2009年にiPhoneDevCamp（ハッカソンのようなイベント）で生まれ、Nitobiという会社によって開発されました。2011年にアドビがNitobiを買収し、同時にPhoneGapのソースコードをApache Foundationに寄付して、Apache Cordovaというオープンソースプロジェクトが作られました。

現在では、Cordovaという下層のフレームワークの上に、アドビのサービスに連携するPhoneGapのレイヤーが乗っています。しかし使い方はほぼ同じであるため、PhoneGapとCordovaは大体同じものという認識で問題ありません。

ゼロ（環境設定）からHello Worldまで

PhoneGap/Cordovaは、Node.jsで使うコマンドラインアプリケーションです。ゼロから始める手段は下記の通り：

1. Node.jsをインストールして、ターミナルで使えることを確認します：

> node -v
v0.10.13
>

2. Node.jsのパッケージマネージャー npm（上記ステップでインストールされます）を利用して

cordova

をインストールします：

> npm install -g cordova
npm http GET https://registry.npmjs.org/cordova
npm http 200 https://registry.npmjs.org/cordova
...
>

※ Macでは、多くの場合には

sudo

> sudo npm install -g cordova
Password: 
npm http GET https://registry.npmjs.org/cordova
npm http 200 https://registry.npmjs.org/cordova
...
>

3.

cordova create

のコマンドを使って、新規プロジェクトを作ります。コマンドのパラメータとして、フォルダ名、アプリID、アプリ名を渡します。

> cordova create testapp com.example.test "Test App"
Creating a new cordova project with name "Test App" 
and id "com.example.test" at location "~/testapp"
>

4. 新規プロジェクトのフォルダに移動します：

> cd testapp/
>

5.

cordova platform add

のコマンドで、作りたいアプリのプラットフォームをプロジェクトに追加します。この例ではAndroidを使います：

> cordova platform add android
Creating android project...
...

6. デバイスをマシンに接続して、アプリのビルドと動作確認します。

> cordova run android
Generating config.xml from defaults for platform "android"
Preparing android project
...

cordova run ...

cordova build

cordova emulate

cordova help

注意：ビルドを行うためには、各プラットフォームの仕組みが必要となります。例えばAndroidの場合はAndroid SDK、iOSの場合はXCodeのインストールが完了している必要があります。SDK不要のビルド方法については後ほど説明します。

PhoneGapアプリの構成について

cordova create

1. ルートにある

   config.xml

   は、アプリのメタデータ（アプリ名など）を定義します

2. /www

   フォルダはHTMLアプリのソースです。

   cordova create

   によって参考用のサンプルコードが作成されますが、編集・削除・上書きを自由にします。このフォルダの

   index.html

   がアプリの初期画面になります。

上記2点以外のコンテンツは、編集する必要は通常ありません。

ところで、新規プロジェクトに生成される参考用の

index.html

cordova.js

script

cordova.js

cordova.js

プラグインについて

標準のHTMLでは、デバイスの機能（カメラロール、ノーティフィケーションなど）にアクセスできない場合があります。その際は、PhoneGapプラグインを使います。基本的な手順は：

1. Pluginレポジトリでプラグインを探します。この例ではノーティフィケーションのプラグインを使います。
2. ターミナルで

   cordova plugin add [ID]

   で追加します：

   > cordova plugin add org.apache.cordova.dialogs
   Fetching plugin "org.apache.cordova.dialogs" via plugin registry
   ...

3. アプリソースのJSから、プラグインのAPIを呼びます：

   navigator.notification.prompt("hoge");

JavaScriptで定義されたプラグインのAPIが呼ばれると、各OSの対応するネイティブコードが各デバイスの機能を呼び出す仕組みになっています。その際、デバイス機能がAndroid/iOSなどで仕組みが違っていても、プラグインのインターフェイスは共通なのでPhoneGapアプリのソースを別バージョンに分ける必要がありません。しかしデバイス側の機能がプラットフォームによって実装が変わる場合もあります。その場合は、アプリの動作を各OSの挙動に合わせる必要があったりしますので、各プラグインのドキュメンテーションにある「Quirks（方言）」セクションに目を通しましょう。

クラウドで行うアプリ作成サービス「PhoneGap Build」

 アプリのビルドを行う際に、各プラットフォームのSDKが必要と説明しましたが、それが難しい場合もあります。例えばiOSのSDKはMacでしか動きませんので、Windowsでは利用不可能です。

この場合、アドビのクラウドビルドサービスPhoneGap Buildの利用をオススメします。Android、iOS、そしてWindows 8アプリをSDKの準備なしでビルドできます。PhoneGap Buildの使い方で前述の解説と異なるところは主に次の２点です。

1. cordova

   ではなく

   phonegap

   コマンドを使用
2. クラウド側で実行するコマンドに

   remote

   というキーワードを追加

具体的には次のような流れで利用できます：

> sudo npm install -g phonegap
...
> phonegap create test com.example.test2 Test
...
> cd test
> phonegap remote build android

初回はPhoneGap Buildのユーザ名、パスワードを要求されます。既存のAdobe IDでログインするか、アドビのWebサイトでAdobe IDを新規作成（無料）してください。その後、アプリがクラウド側でビルドされます。アプリの確認、インストールなどをPhoneGap Buildサイトでできます。

まとめ

PhoneGap/Cordovaは非常に軽量なフレームワークです。HTML5コンテンツのアプリ化に特化しており、他フレームワークとの競合も少なく、比較的導入し易いフレームワークだと言えます。HTMLコンテンツからモバイルアプリまでの最短経路だと思いますので、ぜひお試しください！