先週の11月5日、Apache Cordova勉強会の第1回が開催されました。HTML5ハイブリッドアプリについて、実際の開発者によるプレゼンテーションが行われました。今回は、参加できなかった方のために、その勉強会のまとめを紹介したいと思います。

Cordova勉強会とは？

まず始めに、そもそも勉強会の目的から。Apache Cordovaというのは、PhoneGapやMonacaといった製品に組み込まれている、HTML5ハイブリッドアプリを開発するためのオープンソースなフレームワークです。このCordovaの技術情報を共有するために、「日本Cordovaユーザー会」として、月に1度のペースで勉強会を開く活動を行っています。今回は、その第1回となります（第1回の案内はこちら）。

• Twitterハッシュタグ: #cordovajp
• YouTube公開録画: 第1回Apache Cordova勉強会

Cordovaの最近ホットな話題

新しいbrowserプラットフォームは、ブラウザー上でデバイスAPIをエミュレーション動作

これまで、iOSやAndroidアプリの開発を目的としていましたが、ブラウザー用のAPIも整備が進み出しました。現時点ではまだ対応APIも少ないものの、今後は充実していくことになりそうです。

browserプラットフォームを使うと、ブラウザー上でCordova APIのエミュレーションが実行されます。ビルドはzip形式で圧縮します。

ChromeベースとGeckoベースの新しいWebViewエンジンを使えるように

Cordova 4.0では、WebViewエンジンを選択することができるようになりました。それに伴い、Intelが主導するCrosswalkプロジェクトではChromiumベースのWebViewエンジンが、MozillaはGeckoベースのMozillaViewエンジンが登場しました。これにより、下記のようなメリットが挙げられます。

1. ブレークポイントやプロファイリングなどの高度なデバッグ機能が利用可能に

Crosswalkを組み込むと、Chrome Dev Toolsを用いたデバッグができるようになります。PCブラウザーとほぼ同じデバッグ機能を、Cordovaアプリでも使えるようになります。

2. Androidのバージョン問題から解放される

同一Androidバージョンにおいても、端末メーカーが独自にカスタマイズするWebViewでは、細かな実装レベルに違いがありました。WebViewをCordovaアプリに内包することで、すべてのAndroid端末で、同じブラウザーエンジンを使うことができます（その分アプリサイズは大きくなります）。フラグメンテーションが全く存在しないAndroidネイティブアプリ開発が可能になります。

3. WebGLなどの最新機能が使える

最新のブラウザーエンジンが持つHTML5機能を利用できます。CanvasやWebGLを使った3Dグラフィックスもスムーズに動きます！

Cordova 3.5.0での脆弱性問題には速やかに対応を

Cordova 3.5.0にて脆弱性が発見されました。そのため、Google Playストアでは、古いCordovaアプリを利用している場合に警告メッセージが表示されます。速やかに最新版にアップデートしましょう（Google Playストアで非公開扱いされるリスクがあります）。

Cordova開発のベストプラクティスを学ぶ

要件定義が重要

下記のような内容について、クライアント（もしくは企画側）と話し合い、コンセンサスを得ることが重要です。

• OSバージョンはどこまで対応するか？
• Androidの動作保障端末は？
• Cordovaプラグインでどこまで実装するか？

これはCordovaに限った話ではありませんが、特にCordovaでは後々の方針変更は大きな痛手になる可能性があります。

UI設計はOSの違いを考慮する

プラットフォームごとにUI規約は異なります。それを理解したうえで、UI設計を行いましょう。

巨大なリスト構造はHTML5には不向き

巨大な数のDOM要素が入るようなUIはHTML5では難しいです。ページ送りなどで代用することも検討しましょう。

開発アーキテクチャーは「SPA」

いわゆるSingle-Page Application形式で開発するのがおすすめです。Onsen UIやIonic Frameworkなど、ハイブリッドアプリ用のUIを組み込んだSPAフレームワークが開発での候補になるでしょう。

コーディングサイクルを最適化

毎回コンパイルするのは時間の無駄です。browserプラットフォームを使ってPC上で確認したり、Monaca Localkitのような高速に実機に転送してくれるツールを利用しましょう。

ボトルネック探しはインスペクターを使う

JSの処理・CSSのマッチング処理・DOMリフロー・GPUへの転送・描画処理など、アプリのボトルネックの要因は様々です。こちらの資料を参考にしてください。GapDebugというツールも便利です。

DOMリークをきちんと対処する

DOMリークとは、解放されるべきDOM要素がJSから参照されたまま解放されない問題です。やっかいなのが、ドキュメントに含まれないDetatched DOMツリー自体がリークしてしまい、そこに含まれる画像などもメモリー上から解放されません。DOMリークを防ぐ方法として、必要に無くなったDOM要素の参照をきちんと切ったり、イベントリスナーをremoveすることが重要です。

実機がない端末はクラウドでテスト

たとえばRemote Test Kitというサービスでは、クラウドを通じて実端末を一定時間レンタルすることができます。自由にアプリをインストールすることができるため、機種問題で悩まされている場合は、こういったツールが非常に効果的です。

開発事例 〜iPad向け業務アプリ（サービスマン支援システム）〜

アルティザンエッジ合同会社の井上さんより、実際の業務アプリの事例と、そのなかで苦労した点や工夫した点を紹介して頂きました。

• Cordovaを採用した理由
• BackboneやjQuery Mobileを用いたアーキテクチャー
• ネイティブで開発した「Cordovaプラグイン」も数多い
• Cordovaアプリ開発でハマったこと
• メモリー消費量について

ぜひこのリンクより、スライドをご覧になってください。

次回の勉強会について

第2回Cordova勉強会は、12月2日午後7時より開始予定です。ご興味ある方は、ぜひ下記のリンクよりお申込みください。

第2回Apache Cordova勉強会（DoorKeeper）

2014年10月24日、米サンフランシスコにてPhoneGap Day US 2014が開催されました。3年前から始まった本イベントですが、これまでアメリカではオレゴン州ポートランドで開催されていて、残念ながら参加する機会がありませんでした。今年は同じくサンフランシスコで開催されたHTML5 Dev Conf 2014と同じ週となった関係で、両方のカンファレンスに参加することができました。

HTML5ハイブリッドアプリ開発として幅広く使われているPhoneGapは、またの名を「Cordova」と呼ばれます。CordovaはApache FoundationベースのOSSプロジェクトで、それをAdobeが製品として出している名称がPhoneGapとなります。そのため、PhoneGap Dayの内容も、主にCordovaに関するものがほとんどです。それもGoogleやMozilla、Microsoftなどに所属するCordova開発者のスピーチが多く、とてもオープンなカンファレンスとなっています。

司会は毎度ながらPhoneGap開発チームのリーダー的存在なBrian LeRoux。PhoneGap Desktop Appの紹介などが行われました。

.@Adobe's @brianleroux kicks off PhoneGap Day 2014 http://t.co/PJqfunCgwE #pgdayus14 #pgday14 pic.twitter.com/cIiYBoSYPP

— Eric Oesterle (@erico) October 24, 2014

ハイライト紹介

CrosswalkエンジンでAndroid WearでもCordovaが動いた

Joe Bowserの「Many Webviews on PhoneGap Android」より。Intelがオープンソースプロジェクトとして進めているCrosswalk Project。これは、Chromium互換WebViewエンジンをCordovaに組み込み、ハイブリッドアプリの大きな課題であるAndroidバージョン依存や実行パフォーマンス、JavaScriptデバッグ機能の強化などを解決してしまおうというものです。PhoneGap Dayに先立ち公開されたCordova 4.0では、WebViewをAndroid標準WebViewからサードパーティ製のものに切り替える仕組みが備わり、Crosswalkの導入も簡単になりました。これを使うと、WebViewを持たないAndroid Wearにおいても、Cordovaアプリを動作させることができるとのこと。メモリーの問題等で実用ではないらしいですが、面白い取り組みです。

Visual StudioでCordova開発。次バージョンでiOSにも対応

現在プレビュー公開されているMulti-Device Hybrid Appsですが、近日中にアップデートが行われ、iOSのビルドができる機能が搭載されるとのこと。Windowsローカル環境で具体的にどうやって実現するのかなと思ってみていると、どうやらMac上にエージェントを起動し、Visual Studioはそのエージェントに対して、ネットワーク経由でリモートビルドをかけることで対応するようです。これでMonacaを使わなくてもWindowsユーザーがCordovaでiOS開発ができるようになりますね！

Ionic Frameworkの正式リリースは11月末か？

モダンなUIフレームワークとして注目されているIonic Frameworkですが、11月末ごろに正式リリースされるという話がありました。これまで1年間ずっとベータ版のままでしたので、正式リリースでどのようになるのか楽しみです。

まとめ

他にも、PhoneGapアプリのデバッグをするツールや、Mozillaが開発中の新しいWebViewエンジン、iOS 8で登場したWKWebViewの話など、PhoneGap/Cordovaデベロッパーにとって非常に面白いテーマが目白押しで、個人的にとても楽しむことができました。それと同時に、HTML5ハイブリッドアプリの世界は、CordovaというOSSフレームワークを通じて、メジャーどころが共同で開発を担っていることが実感されました。今後、PhoneGap Blogではセッションの録画ビデオを掲載していくと思いますので、ぜひチェックしてみてください。

PR: Cordovaユーザー会で一緒に最前線を探索しませんか？

PRとなりますが、このたびHTML5ハイブリッドアプリ全般の技術を扱うためのオープンソースコミュニティ「Cordovaユーザー会」を立ち上げました。この会では、HTML5ハイブリッドアプリ、とりわけCordovaの普及に向けて、実際にアプリ開発を実践されている方々が積極的に情報共有をしていくことを目的としています。キックオフ第1弾として第1回Cordova勉強会を11月5日、午後7時から開催する予定です。ぜひ興味ある方はご参加ください。

P.S. Google Chrome Apps Mobileの方に、Monacaの紹介をしてもらいました。Cordovaプラグインを開発しやすくするためのツールを作っていきます。

最近のシステム開発の現場では、HTML5やモバイル、JSフレームワークなどの新しい道具が次々と登場してきます。「そうした新しい道具ってエンタープライズではどうなの？」「現場として受け入れられているの？」といったぶっちゃけトークを行う座談会が、8月11日に美人で有名なおだんみつさんのいる21cafeで開催されました。1時間半にわたる長時間のトークから特に盛り上がった話を紹介します。

　▲パネラーたち（左から株式会社クレスコ・小川充さん、グロースエクスパートナーズ株式会社・酒巻瑞穂さん、NTTコムウェア株式会社・川田寛さん）

日本のエンタープライズが抱える悩ましい問題とは

川田：世の中は技術革新で勉強会に行くとワクワクするんですが、でも皆さん本当に使ってますか？
私はあるところで「勉強会で紹介される技術ってお花畑だよね」「俺たちそこまでアグレッシブじゃないよね」って聞いてショックを受けたんです(笑)。とは言え、イケてるものは世の中にいっぱい出てきていて、OSS由来のベンダー製品も、モバイルもたくさん出てきています。でも日本のエンタープライズだと、結構悩ましい問題を抱えているように思うのですよ。

　▲日本のエンタープライズは世界のスタンダードと離れすぎている

（スライドを示して）そもそもですけど、エンタープライズって、エンジニアを取り巻くエコシステムが欧米と日本とで全然違いますよね。SIerなんかがまさにそれで、ユーザ企業さんのシステム費を下げようとして頑張るんですが、システム費が下がると受注費が下がるし、エンジニアが評価されないしで、利害がうまく一致せず難しい状況。

そんな中で、ITで働き方をよくしようとか、エンジニアの技術で競争力アップに貢献していこうとか、そういう投資を提案していけるかんじにはなかなかなれず、海外とかと比べると日本はよくない方向に向かってる。エンタープライズは今とてもツラい状況に陥っているのではないでしょうか。そこで今日は前向きに企業のITをよくしていく方法を、フロントエンドという観点から、語り合えたらいいなと考えています。今日のアジェンダですがこの3つです。

• 古いシステムのツラいところ、例えばIE6/VB6とか
• これから結構使えそうなWeb技術
• どうやって新しい技術を入れるか、上司を説得するか

これらの課題を考えていく会にしたいと思います。早速パネラーに自己紹介してもらいましょう。

小川：エンタープライズ部の小川です。システム提案とか社内で利用するフレームワークの選定、エンジニアのトレーニングとかをやってます。

酒巻：同じくエンタープライズ部の酒巻です。前職ではHTML5関係の技術を仕事に取り入れてました。転職して直接HTML5関連は減ってるんですが、前職の経験からエッジの効いたエンタープライズっぽいところには関っている、という結構幸せな仕事をしてます(笑)。前職では小川さんと同じ社内標準の選定や、教育を含めてオープンソースの技術をどう使っていくのかという取り組みをやってました。

レガシーシステムとの付き合い方

川田：では、まず「古いシステムのツラいところ」から。

酒巻：自分の場合は、IE6やVB6でも苦しめられることがありますね。IE6ってXPと同時に死に絶えるかと思ったら、「サポート切れてるけど長期的に見て2年後にリプレース」みたいなところがあって。その資産とエッジの技術が今ぶつかってる。特に技術者が少ない部分、ActionScriptとかPrototypeJSとかに特有の癖などをよく知っている技術者が少ないんです。そういうニッチなことを知ってる人に負荷が集中してるのが、今よく見る状況ですね。VBも一緒だと思います。VBができるエンジニアって社内で貴重です。

川田：VB6知ってる人とか「神」扱いですよね。

酒巻：そういう人はたいていエッジなものも知ってるから、一人に対してよけいに負荷が集中してしまう。知らない人は定時で帰れるのに。

小川：私は今は幸いにIE6じゃなくIE8なんですけど、VBからIE6とJava EEに置き換わってという、まずはオープン系に置き換わって、その次のリプレースってのが多いですね。私は今日は話すほうよりも、皆さんからヒントをいただきたいので、いろいろ聞きたいんです。

──ここで川田さんが、会場にIEの案件をやっている人の挙手を募ったところ、意外と少ない結果に。さらにAndroid2.3標準ブラウザについても聞いてみると…

川田：Android2.3標準ブラウザだと、IE6とあまり変わらないくらいの存在ですね。IE8を使ってるということは、エンタープライズだとJavaなどが多いと思いますが、JSFあたりは拡張にいろいろと制約が出てきませんか？

小川：私の周りでは、そもそもJSFを使ってるケースがあまり例がありません。実際はまだJSPで作られているものが多くて、それを今のHTMLベースのアプリケーションに置き換える時に、BackboneなのかAngular.jsなのか、という議論です。

川田：JavaScriptフレームワークの活用に進んだのですね。小川さんは、ちなみにどっち派ですか？

小川：今はAngular推しなんですけど、どちらかというとSenchaのように、UIのコンポーネントを持っているもののほうがエンタープライズとしてはよいのではないかと思っています。

川田：エンタープライズの重要なポイントとしてサポートというのもあるけど、ちょっと安い案件はサポートなしでいこうかな、みたいなラインを狙ってるようですが、そのあたりどう思いますか？

小川：持続可能性を考えると、オープンソースだけタダだからって単体で使うのは、ちょっと違うなと思ってます。サポートがあるというのとは別に、いろんなものを組み合わせるとどこで不整合が起きるか分からないですし、ライセンスの問題もありますし、結構難しいんですね。そう考えるといろんなオープンソースを組み合わせて、一個のプロダクトにしているものの方がよいと思います。

川田：なるほど。話は変わりますけど、「古いIE向けのシステムはIE8や9でDocumentModeを使って動かせる」という神話があるんですが、実際に中身にはJavaアプレットがあったり、もう一つはFlash/Flexだったりするわけですね。そういうのを入れ替えたり、維持したりというのはありますか。

酒巻：2年くらい前の話なんですけど、その時に自分はネイティブを選んじゃったんです。2年くらい前だとFlashでやれることがHTMLではまだつらかった時期で、しかもIE7までサポートという条件があって。技術的にはできるんですよ、技術的には。ただ投資効果が…リプレース案件だったのでお金が出ないんですよ。それで一番安く上げる方法は…ってなるとFlashになっちゃう。自分はこれはHTMLでやったら面白そうだなとは思ってたんですが…。

──会場からJavaで画像を操作するところをFlashを使おうとしたが、許可が下りなかった話が投げかけられた。ソースや設計書もなかったが、動いたのだという。

川田：JavaアプレットとかFlashを置き換える案件、いい方法はありますか？

小川：作り変えた方がいいと思います。作られた当時のビジネス要件と今のビジネス要件では、状況が違いますから。お客さんにとっては、システム更改はグローバル化に代表される様々な変化と戦うための、新しいシステムを手に入れるチャンス。我々エンジニアとしてはそこに新しい技術を入れていく方法を考えていくべきかと。

酒巻：部分置き換えって長期的に見てコストがよろしくないケースのほうが多くて、会社レベルで業務計画の一環として古い資産を置き換えていくべきってのは、常に意識してます。

川田：この世界には、「三割改修は全入れ替えと変わらない」の法則がありますからね。

エンタープライズでも注目の最新Web技術

川田：これから先、ビジネスになりそうな技術を探っていこうかなと思うんですが、「この辺の技術要素はアツいぜ」ってのはありますか。

酒巻：鉄板ですが、Web ComponentsとServiceWorkerがすごく「来る」と思ってます。Web ComponentsのビジネスモデルとServiceWorkerのオフラインアプリケーションというのが、今の微妙に足りないHTML5プラットフォームにぴったり当てはまりそうな気がしてるんです。

小川：私の会社はWebだけでなく組込みやクラウドもやっていますが、その中で考えていくと、WebSocketですね。いろいろなデバイスがありますし、今後は薬の中にもセンサーが入るような時代になっていく。そうするとそれらのデータをどうやってWebやクラウドに上げて分析をしていくかが重要になっていて、今「何か」と「何か」をつなぐインフラとしてWebが一番適しているんですよ。そこで今注目している通信技術としてはWebSocketですね。

川田：私はやっぱり業界全体の流れに全力に乗っかろうということで、モバイルに期待していたりします。私はこれからは「モバイルファースト」じゃなく「モビリティファースト」になる説を推しています。実はブログ記事でも上げてるんですが。

小川：見ました。同感ですね。

川田：従来はデスクトップコンピューターに縛られたシステムだけです。それが今変わってきて、安価で汎用的なデバイスの中から、取捨選択しながらシステムを作っていく時代になると思うんです。デスクトップだけで完結したシステムを作るんではなく、いろいろなデバイスの中から適切なものを選んで、システムで業務フローを実現するような時代になっていくのではないかと。

酒巻：タブレットは結構もてはやされていましたが、仕事で要件とかワークフローを作っていくと専用機の方が優秀になることが多いんです。ワコムのペンタブレットとか、専用のUSBを挿すだけで動くような端末とかで。それがさっき小川さんが言ったWebSocketで通信する、API互換、Web標準でそういったマシンが繋がることがシステム開発の土台となってくれたら、すごい嬉しいなと思います。


　▲当日の会場は、テーブルには川田さんのおごりのビールが最初から並べられました

エンタープライズにUXって必要？

川田：モバイル絡みの話になりますが、エンタープライズにUX（への配慮）って必要だと思いますか？

──会場からの挙手はUXいらないと思う人、いると思う人が半々という結果に

（参加者）：ミスを少なくするというような観点で、誤解が少ないラベリングや紛らわしくないアイコンといったものは絶対必要。そういう理由で僕はUXは必要だと思います。

（参加者）：スマートフォンのOSを乗り換えるということがあるけど、たいていの人はすぐに使いこなせる。それはなぜかというと、UXがものすごく考えられていて分かりやすいから。でもエンタープライズの技術では新しいのになると「使わない」「使えない」って言われるのは、UXを考えてないからなんじゃないか。なので新しい技術で日々革新してことになったら、UXの部分だけは一本筋を通してあげないとダメではないかと…。

小川：UI/UXはお金にならないと言われる機会が多いです。例えば非常に使いにくいUIを変えたとき、現場の反応を見ると最初は大変評判が悪い。でも半年くらい経つと「使いやすい」と言われるようになる。その半年間の業務効率低下のコストと、そこで得たUI/UXが本当に等価だったのか自分は結構悩んでいて、WebとかであればUI/UXのベストプラクティスってあるんでしょうけど、企業システムの閉じた世界だと一般論では語れない何かがあるんではないかなと思ってます。

川田：私はUXは暫定的には儲からないんですけど、これから先は必要になると思ってます。エンタープライズとWebで公開されているサービスの大きな違いって評価軸で、Web系のサービスはたくさん利用してもらうことに価値がある。でも業務システムは嫌でも毎日使う。

ところが業務ってシステム化されているはずなのに案外現場に見にいってみると「使いにくい」あるいは「現場に合ってない」と思われるところをアナログに戻してるんです。そういう意味で今まであったものを置き換えるとなった時に、UXは重要なポイントになる。エンタープライズでは、モバイルとUXはセットだと考えているんです。

酒巻：UXじゃなくて、UIの話題の方がまだエンタープライズでは多いんですね。まだUIが出そろっていない「こういう時にこうする」っていうベストな選択肢が、まだ分かってない部分が多いんじゃないかなあと。

川田：エンタープライズは「ベストプラクティス」が好きですよね。

酒巻：むしろその言葉に安心して、みんな次の一歩へ進みたいっていうのがあるんじゃないかな。

小川：「モビリティ」の考え方は非常にありだと思っていて、例えば日本だとどんどん人口が減ってきていて、出産後の女性の活用、オフィスに縛られない働き方の中ではデバイスだったりノートPCが必要だけど、それは今までの業務システムの業務フローにないんです。そこで新しく再設計した上で、全部最適化されたら素晴らしい未来があると思ってますが、なかなかピンときてくれないんですね。ただ今後そういう企業や事例などが増えて、日本でもそういう働き方が普通になってくると思うので、そういうのを実現するための新しいテクノロジーはありだと思うんです。

酒巻：それは自分も夢に見ることがあるんですけど、そうなるために企業が何をするかっていうと「一部改修」「部分改修」で何とかしようって考えが多くて、それでコストが大きくなって結局取りやめようってケースが多かったんです。

小川：そこで相手側のステークホルダーを考え、「経営者の方に話すときは企業としての将来計画、ビジョンといったものをきちっと立てる」ことが必要だと思ってます。

オープンソースのフレームワークはどう？

川田：別の新しい技術の話も取り上げてみましょう。「オープンソースのフレームワークってぶっちゃけどうよ？」に何か意見はありますか？

酒巻：現在のエンタープライズで一番注目株といえば、Cordovaですね。お客様からのご要望で、ネイティブのファイルAPI、ローカルファイルにアクセスしたいっていう話が結構あるんです。「ActiveXなどで使えたのが同じWebなのに何で使えないの」って話が出てくるんですよ。そのための逃げ道として、Cordovaなどが出てきているんじゃないかと。ただ将来的に、Cordovaだけでやっていくのは怖いなって自分は思ってます。

小川：あれはまだ「闇」ですね(笑)。私もHTMLだけ作ればネイティブできますよっていうCordovaの甘い誘惑に誘われていったら、なぜかAndroidのネイティブ部分を触ることもあるという(笑)。技術の選択肢としてはありだと思いますけど、選定する側としてはメリット/デメリットをちゃんと把握した上できちんと利用するべきで、そのために一番大事なのは「味見」ですよね。

川田：弊社にはオープンソースの匠みたいな人がゴロゴロといるんですが、彼らが言うには「ここ最近の技術革新は早すぎる」。ここ10年くらいはゆっくり動いていたのに、滅茶苦茶早くなってしまった。そんな中で戦うために必要なのは、やはり「味見」だと思います。

酒巻：ブログや記事で紹介されている「光」の面だけ見て理解した気になり、とりあえず仕事に取り入れてみよう、というスタートはデスマのサイクルに陥る一因。その間に自分で味見やプロトタイプを作り、評価をするって課程が今後必要になってきますね、オープンソースをしっかり使う上では。

川田：「味見部」は何かやります？そこに html5j味見部部長の金井健一さんもいらっしゃるので…

金井：基本的に新しい技術が出たら味見をしています。なので「人柱」です。新技術がたくさん出てきても当たりなんて1割あるかどうか、本当にひと握りです。


　▲html5j Web先端技術味見部部長　AngularJS Japan User Group 管理人の金井健一さん

川田：エンタープライズのエンジニアがみんなユーザー企業にいるなら、システム費を下げればそれは直接自分たちの成績になるけど、日本では中間にSIerがいますからね。そこで新しい技術でできることとしてまず考えられるのは、「入れ替えの技術」。まず、「VB6とかFlashを使ってきたことを入れ替える技術は何だ」ってところからスタートして、その後モバイルでどうするのかを考えていくべきかと。

エンタープライズを「モダン」にするための技術

川田：最後にどうやって新しい技術を入れていくか、ぶっちゃけ「どうやって上司を説得するか」という話になります。酒巻さんはフレームワークを導入した時、どういう説得をしました？

酒巻：Angularを実際のそれなりの規模のあるシステムに取り入れました。何が大変だったかというと、エンジニアの下からの反発と、それで本当に見積り出せるのかという上からの反発ですね。

川田：見積りなんですか、上からは。

酒巻：これは何万円でできて、ウチに何万円の利益が出るかを最初にかなり正確に出したがるんです。フレームワークは前例がない。それに比べて、JSPで作ったらものすごく具体的に数値ができるんです。そこをいかに「最初に（見積もりを）作りあげるか」でしたね。

川田：Angularを入れるメリットは説明したんですか？

酒巻：はい。説明資料もかなり作りました。自分もBackboneとかEmberとかの当時エッジなJSフレームワークを味見して、最初にいけると思った唯一のフルスタックがAngularだったんですよ。

川田：一つで完結できるってことですか。

酒巻：テストとCIまでが、Angularのページに「こうすればいい」と載っています。Angularの基礎の部分を一回理解すると、それをそのまま設計に転用できるというのがすごく大きい。特にバックエンドのノウハウをそのまま使ったクラスコード、モジュール設計をできたのは上司を説得する上での説得材料になりました。

それをもとに実際に部下たちにAngular.jsを触らせて、実際できたら「できるじゃん」というノリですよね。言いかたが悪いですけどサラリーマンプログラマの人たちは安定した技術、昨日やっていたことを今日もやりたいと思う人が多いんで、それをどう切り替えさせるのか、「ほら簡単だよ」「やったらできるでしょ」さらに「こんなに楽になるよ」というのを教えてあげる、体験させてあげるっていうのが重要かなと思います。

小川：同感です。その点、Angular.jsはいいフレームワーク。後はUIフレームワークですね。SenchaやKendoUIなども検討してみてもいいと思います。

あとマイクロソフトのWinJS、これが正式にリリースされたら結構インパクト大きいと思います。企業システムのHTML5化をする上で一番ネックなのが、バックエンドの既存システムをどうやってWebAPIにするかという点です。バックエンドの話で言うと、マイクロソフトの.NETの技術はかなり素晴らしいですね。そことペアになる、マイクロソフトのサポートがあるUIフレームワークが出てきたら、乗っかってもいいかなと思っています。

川田：最近のエンタープライズでは、OSSよりベンダー製品の方が明らかに尖ってきていますよね。新製品の選定をOSSで縛ると、できないことが多すぎて困ってしまうのですが。

酒巻：自分は、Angularは入れましたけど、実際にガンガンやっていくんであれば、SenchaとかEasyUIの方が安心はできますよね。



川田：ほかにこの辺りが来るんじゃないってのはありますか？

金井： Angular.jsユーザー会会長だからAngularを推しているわけじゃないんですけど、Build 2014というマイクロソフトの技術者カンファレンスでも「.NET系とAngularの相性がすごくいい」とめちゃくちゃ盛り上がってました。マイクロソフト系列のKnockoutの話が全然出てこなかったんですよ。

小川：ちなみにJavaOne TokyoでもAngularが取り上げられていたそうです。エンタープライズJavaとの組み合わせでも、Angularは注目されているのかもしれない。

金井：たぶん、JavaScriptを書きたくないんですよね。Angularを使えば、JavaScriptの記述量をかなり減らせるから。

川田：私も「みんなJavaScriptなんか書きたくないんじゃないか」と思ってるんですよ。jQueryは「jQuery」っていう言語で、JavaScriptとは言いがたいじゃないですか。ひょっとするとここにいる皆さんも、本当はJavaScriptが嫌いなんじゃないんですか！？

(会場から) え～(笑)

川田：で、新しい技術をどう入れていくかの一歩前に戻るんですけど、フロントエンドってJavaScriptを書かない方向に行くんじゃないですか？

金井：JavaScriptにWeb Componentsが実装されると、苦手な人はわざわざJavaScript書かなくていいよっていうふうに、未来はなってます。

小川：コンポーネントが安定的に提供されて、JavaScriptに慣れないエンジニアでも大規模なものが作れるようになればいいなあと思いますね。

川田：思ったよりモバイルとフレームワークの話に行きましたよね。モバイルとフレームワークは非常に関心が高いのだと思います。モバイルに関しては「適用方法はいくらでもあるけど、提案する方法が見つからない」なのですが、フレームワークの場合は「良さは分かっているけど、お客さんにその良さを伝えられないというのが苦しい」のだと全体的に感じました。

ということで、90分にわたりいろいろ議論していただいてありがとうございました。最後にもう一度乾杯で締めましょう。乾杯！

5月29日、30日にかけてMicrosoftの開発者向けイベントである「de:code」が開催された。本記事では、Microsoftのエバンジェリストである西脇資哲氏のセッション「de:code参加者に捧げる最新Microsoftデモ・プレゼンの極意」について紹介する。

プレゼンテーション・デモとは

プレゼンテーションでは相手に、話をする、画像・動画・デモを見せる等を行う。このプレゼンテーションにおいて、重要なことはまず相手に伝わること、そして相手に伝わった結果、さらに重要なのが相手が動いてくれることだ。相手が動いてくれるとは、例えばプロジェクトについて説明した結果、相手が人・お金のリソースを出してくれる、ということだ。

このプレゼンテーションのテクニックとして、本セッションでは2つのテクニックを紹介する。1つはスピーチのテクニックで、もう1つはデモのテクニックだ。

スピーチのテクニック

スピーチのテクニックとは、魅力がある話し方・相手に伝わる話し方のテクニックである。

プレゼンテーションはテクニックである

世の中にはプレゼンテーションが上手い人・下手な人がいるが、上手い・下手を決めている要因は、生まれ持った能力ではなくテクニックである。

一般的に、「カリスマ性の高い人はプレゼンテーションが上手い」と言われることがあるが、それは逆で、プレゼンテーションが上手くなる努力をしており、プレゼンテーションが上手いから、カリスマ性が高く見えるのだ。

以下では、プレゼンテーションが上手くなるためのテクニックを紹介する。

最初の言葉と最後の言葉だけは決めておく

プレゼンテーションの最初の言葉は上手な人が多い。しかし、締めの言葉が下手な人がいる。一番最後の言葉が、ビシッと決まるプレゼンテーションを実施している人は非常に印象が良い。そのため、最後の言葉を決めておくとよい。例えば、「ご清聴ありがとうございました」でもいいし、会社でユニークな、製品にまつわるものでもいい。

事実(Fact)と意見(Opinion)

プレゼンテーションやデモで述べる内容には、事実(Fact)と意見(Opinion)がある。このうち、意見(Opinion)を伝えるのがプレゼンテーションだ。例えば、「情報漏洩は年間5万件起きている」と単に述べるのではなく、「情報漏洩は年間5万件おきており、これは大変な脅威ですね」と、意見を伝えるようにする。

プレゼンテーションでは必ず引用する

プレゼンテーションは、どうしても自分本位になりがちである。それは時には良いこともあるが、自分のプレゼンテーションのときこそ、周りや前後を引用する。

例えば、「私も先ほどの人と同じように…」のように述べる。もし、発表順でトップバッターであれば、「皆さんをはじめ、多くの人があまり経験のない…」のようにすると、プレゼンテーションが上手に聞こえる。

絶対時間と相対時間を織り交ぜる

時を表すセンテンスには、絶対時間と相対時間がある。絶対時間とは、例えば「2016年6月」という表現で、相対時間とは今を基準にした「2年後」のような表現である。

相対時間は言葉づかいのマジックの1つであり、相手の立場に立った表現となるため、相手に強い印象を持たせられる。例えば、「2時間後の今日9時に」は、相対時間と絶対時間を織り交ぜた表現となる。

言葉を修飾をせよ

センテンスは、名詞と修飾する言葉でできている。プレゼンテーションでは修飾する言葉を伝えるのだ。例えば、「皆さんは」とだけ言わない。「非常にスキルの高い開発者である皆さんは」と述べる。これにより、プレゼンテーションがカッコよく、リッチに聴こえる。

このテクニックは日常でも使われている。レストランにいくと、メニューには単に「サラダ」とは書かれておらず、「シェフの気まぐれサラダ」というように修飾されている。

3つの語尾

プレゼンテーションでは、センテンスの語尾が重要になる。

体現止め

名詞でビシっとセンテンスを止める方法だ。例えば、「我々はこうやって危険性を指摘してきたのです」ではなく、「我々が行ってきたのはとても重要なことです、そう、危険性の指摘」のように述べる。

質問と回答

自ら質問して、自ら答える方法だ。例えば、「今日はなぜiPadを使っていると思いますか？　カメラとして使うのです」のように述べる。

魅力の語尾

魅力的な言葉をセンテンスの最後に残す方法だ。例えば、「1024段階の筆圧感知をするスタイラスペン」は、普通の言い方だが、「こちらのスタイラスペン、1024段階、高精密・高精細です」とすると、魅力的なキーワードが最後に残る。

催眠効果を植え付ける

プレゼンの中盤や後半で、「だんだん皆さん理解して、わかりやすくなりましたよね」と話すと、相手が理解が深まったかなぁ、というように感じる。これはTV、情報番組でよく利用されるテクニックだ。

もし、相手に伝わってなかったら、相手は質問してくる。相手に伝わったという印象を持ってもらうほうが重要なのだ。

一般的にやってはいけない事項

若い男性に多い行為で「たとえばー」「今日はー」のように、単語の後の母音強調があると、だらしなく聴こえる。

また、エンジニアに大変多いのは「はいっ」と述べてしまう癖だ。スライドがめくれるたびに「はいっ、続いては…」のように、話すとカッコ悪く聴こえる。これを、直すのに便利なテクニックとして、スライドが先ではなく、しゃべりを先にする方法がある。

つまり、自分が話し始めてから、ほんの少し遅れてスライドが表示されることで、自分がプレゼンテーションをリードするようにする。なぜ、こうするかというと、先にスライドを出すと、相手はスライドを先に読んでしまい、スピーカーの話を聴かなくなってしまうからだ。

デモの極意

これまで、スピーチのテクニックについて説明してきたが、デモのテクニックについても説明する。

Touch Feedbackを利用する

Touch Feedbackとは、指でどこを押しているところが分かるという、Windows OSの持つユニークな機能である。TouchFeedbackで、コントロールパネルから設定可能だ。本機能はWindows Phone8.1でも設定可能だ。

ピクチャーパスワードを設定する

ピクチャーパスワードとは、Windows8の特徴的なパスワード機能で、線や丸、タップといったタッチ操作の組み合わせで、ユーザー認証を実現する仕組みだ。画像には、動物や圧倒的に美しい景色を入れてほしい。

デモは画面の上半分でデモをする

人間の特性として、画面の上のほうでおきていることは、素早く綺麗に見える。そのため、デモは画面の上半分で行うべきだ。

画面の下に目がいくと、タスクバーに目が行きがちになるので、画面上部での操作が良い。

より自然に見せるため拡大と蛍光ペン

Windowsの標準機能や、ZoomIt等の拡大の機能を用い、さらに蛍光ペン（マジカル・ペンシル等）を用いて、視点誘導することで、デモンストレーションが綺麗に見える。

マウスは動かしすぎない

マウスを動かしてはいけない、なぜならば見ている人が追ってしまうからだ。講演者が緊張するとマウスを動かしがちだが、説明しているときはなるべく動かさない。

タッチは一瞬で行わない

タッチは一瞬で行わず、場所を特定するようにすることで、相手が何を押しているかわかるようになる。たった一秒のテクニックだが、デモが上手いように見える。

画面を読み上げよ

デモの上手い人は「画面にあるオレンジ色のタイルであるムービーショータイムを…」のように具体的に述べる。その結果、プレゼンテーションが分かりやすくなり、デモが上手く見える。単に「映画を見てみようと思います」とは言わない。

ショートカットはみせよ

Ctrl+Cなどのショートカットは便利だが、右クリックでメニューを出して、コピーをする。なぜならば、ショートカットを使うと、見ている人がわかりにくいからだ。

プレゼンテーションでは、見ている人が何をやっているか分からないと意味がない。

プレゼンテーション・デモ中は空白は作らない

空白を作ると、「製品が遅い、止まっちゃった？」という緊張感を相手に与える。また、それにより自分にも緊張感を与えてしまう。

プレゼンテーション・デモ中では、話していれば話しているほど、相手は早く感じる。

競合製品は使わせていただく

「Aの機能はBの機能より劣っているからダメ」というように比較するのではなく、機能の有無の違いやコンセプトを説明する。時には競合製品の方が出来が良くてもいい。

機材の特性、技術の特性を伝える

例えば、Bluetoothを使うのであれば、ケーブルレスであることを強調する。

また、データの転送が何秒でされるか事前に把握して見せる、相手に機材の特性・技術の特性を伝える。

単純なことでも大胆に、華麗に

例えば、プレゼンスという機能がある。退席中をLyncのプレゼンスを出すために、実際に、ノートブックを閉じる作業を見せることで、Lyncのプレゼンスがオフラインになるのを、見せる。

最後に

本セッションでは、スピーチのテクニック、デモのテクニックについて、お伝えした。本セッションの内容が皆様のお役に立つことを願っている。

(編集部注釈)

本記事は実際にプレゼンテーションを行った西脇氏の許可のもと作成されています。

この記事では、html5j パフォーマンス部 第一回勉強会の模様をライブでお届けします。勉強会に参加したくても参加できなかった方は必見です！

はじめに

html5jでは部活動という形で様々な分野の勉強会が活発に行われています。今回の勉強会を主催するパフォーマンス部もその一つで、昨年暮れに構想が持ち上がり、今回第一回目の勉強会開催となりました。今回の会場はDeNAさんの会議室です。

本日の勉強会はWebパフォーマンスの最前線でどのような事が行われているのか、３名のスペシャリストが余すことなくしゃべります！

開会の挨拶＆5jcupの告知

はじめに、html5j管理人の白石さんから、開会の挨拶と今絶賛開催中の5jcupの告知が行われました。

5jcupにはWebパフォーマンス部でも「Webパフォーマンス賞」という賞を提供しています。この賞は応募されたWeb作品のパフォーマンス計測を実際に行い、パフォーマンスへの配慮を怠っていないWebサイト、Webアプリケーションに対して賞を提供するというものです。イベントの最後に、Webパフォーマンス部部長の竹洞さんから、現在は「副賞なし」となっていますが、現在、副賞を用意する方向で検討しているとの追加コメントが有りました。興味がある方は是非応募してみましょう！　

Session 1.【総論】Webパフォーマンス事始め

html5jパフォーマンス部部長の竹洞さんのセッションです。竹洞さんは、元々は司法書士事務所で働いていて、そこからIT業界にキャリアチェンジし、VMwareやAKAMAI、Verizonを経て現在は、Keynoteという1995年に世界ではじめてパフォーマンス計測（クライアントはヤフー）を行った会社の日本代表をされています。

今回のセッションでは、欧米ではどのようなWebのパフォーマンス管理がなされているのか、国内企業のWebサイトのパフォーマンスの現状を紹介しつつ、Webパフォーマンスの最前線の手法や考え方について説明がありました。

日本のWeb・パフォーマンスサイトの現状

日本の主要なWebサイトのパフォーマンス計測結果が示されました。現在、アメリカの主要なWebサイトのトップページは読み込みが１秒きっており、それと比べれば、日本のサイトは軒並み遅いという現状が有ります。このスライドは日本のデスクトップサイトのパフォーマンス測定結果（正規分布図を箱ひげ図に変換）です。

パフォーマンスを見る際に統計学の観点で重要なことは、複数の測定データを用いて平均値からどの程度離れているか（偏差）を算出し比較することになります。平均値を単純に比較してはいけません。偏差が離れていれば離れているほどばらつきが多い（成績が悪い）といえ、逆に偏差が短いほどサイト品質が良いといえます。この偏差を基に標準偏差を算出し、正規分布図に落とし込み、複数のデータを重ねて見やすいように箱ひげ図に変換したものが、上記画像となります。グラフ左側のひげから右側の箱まで（全体の７５％）に本来は全てのデータが収まることが望ましいのですが、右側にひげとしてそれに収まりきれていない２５％のデータが出ているのがわかります。

※統計学の基礎知識含めて竹洞さんが詳しく説明していますので、もっと知りたい方はYoutube動画をご覧ください。

Webサイト品質管理

Webサイト品質管理の為のパフォーマンス計測は定常的に観測を行うことが大切です。FirefoxやChromeの計測ツールで図るのはもちろんOKですが、一時的なデータではなく、継続して計測しなければ、「遅い」というパフォーマンスの情報は見えてきません。先述した箱ひげ図の右側２５％のデータがどういう状況で発生するのか、どのようなパターンでこのデータが変化するのかを定常的な観測データから把握し、Webサイトのパフォーマンス問題を特定していくことが重要となります。

パフォーマンス計測の手法

大きく分けると以下３種類あります。日本ではServer-Side Monitoringが主流ですが、世界的にホットになっているのはReal User Monitoringとなります。しかしながら、どれか特定の方法で取得するのではなく、３種類全てを活用する必要があります。

• Server-Side Monitoring
• Synthesis Monitoring
• Real User Monitoring（RUM）

Server-Side Monitoringで測定したサーバサイドでのパフォーマンス値、Synthesis Monitoringで測定したISPでのパフォーマンス値、Real User Monitoringで測定したエンドユーザ側でのパフォーマンス値を適切な手法で計算することで、パフォーマンス問題の原因を特定することが可能になります。どれか一つに手法を絞るのではなく、それぞれの手法の特徴を理解し組み合わせることが重要となってきます。

尚、パフォーマンスデータの取り方については、統計学で「実験計画法」という手法が確立しています。実験計画法を利用するにあたっては３つの原則「局所管理化」、「反復」、「無作為化」があります。

また、「観測者効果」の問題も考慮する必要があります。Google Analyticsのコードを入れて安心してはいけません。それが測定結果にどのような影響を与えるのかを把握する必要があります。

竹洞さんのセッションはかなりのボリュームです。詳しく知りたい方はYoutube動画をご覧いただくか、後日公開される発表資料をご覧ください。

Session 2.【各論1】JavaScriptの高速化

続いては株式会社ディー・エヌ・エー坊野さんのセッションです。坊野さんはもともとWebブラウザの開発を行っていたということです。

今回のセッションでは、Webブラウザ開発者の視点から、どのようなJavaScriptを書けばWebブラウザが高速に実行できるのかという観点で様々なテクニックの解説がありました。また、本題に入る前に、DeNAがなぜHTML5にてアプリケーション開発に取り組むのか、具体的にはどのようなことをやっているのかについても簡単に説明がありました。

HTML5アプリケーション開発と最適化

HTML5でのアプリケーション開発は以下の様なことが一般的に言われます。

• コンパイル不要
• 遅い
• メモリ使用量が多い

しかし、最近のブラウザはJavaScriptのコードも機械語にコンパイルして実行するため、Javaなどと比較してなぜ遅いのか？率直な疑問が出てきます。

JavaScriptのコンパイラの動き

まず、JavaScriptのコンパイラの動きについてについて見ていきます。ブラウザにおけるJavaScriptの実行プロセスは以下のとおり。

1. JavaScriptコードを解析
2. 中間言語に変換
3. コードブロック解析
4. 機械語コードに変換
5. 実行
6. 実行結果を基にして最適化コードを作成し、実行

最近のJavaScriptコンパイラは複数回のコンパイルを行います。（上記プロセスだと5と6が該当）なぜか？静的解析だけではJavaScriptコードの最適化は困難なので、一度最適化なしのコードを実行、プロファイラを用いて最適化の可能性などについて判定を行い、その結果を用いて最適化されたコードを生成、再コンパイルしているのです。

JavaScriptコード最適化の観点

ブラウザ開発者からみたJavaScriptコード最適化の観点は、以下の通りとなります。JavaSciptコンパイラが出力する機械語コードを最適なものにするように、JavaScriptのコードを変えてあげればいいのです。また、JavaScriptコンパイラの出力のみにある余計なコードは全て最適化を阻害するものとなるため、極力排除する方がよいでしょう。

次に、具体的にどのようなものが最適化を阻害するオーバーヘッドになるかを見ていきます。

JavaScript APIのオーバーヘッド、例えばDate.now()・・・

HTML5 APIのオーバヘッド、例えばdocument.createElement(‘canvas’)・・・

これらの処理は複数の工程処理を行う必要があり、実行するにあたってはオーバヘッドになってしまいます。

JavaScript関数の最適化

最適化にあたっては、先ほどの観点にならってまず、同一のコードをJavaScript関数とC++関数で実行し速度を比較してみます。今回の例では、前者は183us〜828us（ブラウザにより差分有り）、後者は0.6usという実行結果の差ができました。次に、相違点を列挙し、コードを最適化するというプロセスを実施します。

Web開発者が最適化の美味しいとこどりをするには？

これまで説明してきたようなことをブラウザ開発者はやっていますが、Web開発者の皆さんは美味しいところだけうまく取り入れて下さい。 具体的に、最適化のやり方として「関数のインライン化」や「変数名の短縮」などはツールを活用すればできるため、オススメしません。おすすめの手法は以下の通りです。

• ソーシャルネットワークを活用して有識者に聞く（そのためにはわかりやすいコードを書こう）
• JavaやC++と比較しやすいコードを書く
• API Proxyを使う
• Assertionを用いて型チェックを行う

最後に、大事なことは「コンパイラの気持ちになってコードを書く！」ということ。

Session 3.【各論2】ブラウザにやさしいHTML/CSS

最後は、株式会社レイハウオリ 猪狩さんのセッションです。猪狩さんはWebサイトの開発、高速化、HTMLの構造化などをかなり突き詰めてやっていて、雑誌執筆などもされています。

Webの高速化を行うためにはブラウザの仕組みを理解する必要があります。下のサイトをみればだいたい把握できるそうですが、内容はかなり難しいということ。そのため今回は、高速化に繋がる部分を簡単に紹介するとともに、沢山のデモを交えた体感型のセッションとなりました。

http://www.html5rocks.com/ja/tutorials/internals/howbrowserswork/

ブラウザにモテるHTML/CSSとは

よく言われるWeb高速化の３原則に、「少なくする（数）」、「軽くする（量）」、「近くする（距離）」があります。 具体的には、以下のようになります。

少なくする（数）

• CSSスプライト
• ファイル結合

軽くする（量）

• 縮小化
• テキスト圧縮
• キャッシュ利用

近くする（距離）

• CDNを利用する

これら基本的なテクニックについて、もっと詳しい理解を得て応用力をつけ、有用に活用できるようにする必要があります。

Webページが表示されるまでを知ろう

Webページを表示するまでの大まかな流れは以下のとおりです。

1. HTTPリクエスト① – HTMLのみをリクエストする
2. DNSで名前解決 – ドメインからIPアドレスを調べる
3. TCP接続 – サーバに接続を行う
4. HTTPリクエスト② – HTMLのパース結果に基づき各リソースをリクエストする

※ これが繰り返されます

HTTPリクエスト②では、HTMLの中身をパースして個別のリソースをサイトの上位から順に取得していきます。 ダウンロードは並列で逐次的に行われます。最大並列数はブラウザによって異なります。

１ホストあたりの各ブラウザの同時接続数

IE6〜IE7は同時に２本なので他のブライザに比べかなり時間がかかります。

HTMLが読み込まれた後、表示されるまでのプロセスは以下のとおりです。HTMLのパース結果からDOM treeが作られて、それからRender treeが作られます。最後はそれを画面に描画します。

レンダリングプロセスの中でも、特定のCSSを利用するとLender Layerが生成され、その中でも特にGraphic Layerの動きに注目します。

CSSセレクタマッチングについても取り上げます。

JavaScriptの実行については以下のとおりです。

ブラウザとユーザの気持ちになる

ブラウザの視点に立ってみると、レンダリングプロセスを実行する上で重要となる点は以下の通りです。

• 見た目から表示したい -> 順序の最適化
• 時間がかること大変なことは、できるだけ避けたい -> リクエスト、サイズ、消費メモリの最小化
• いろんなこと一変にしたくない -> 消費メモリの分散化
• 他のブラウザいなくなれ（こっそりｗ）

ユーザーの気持ちはどうでしょうか？

• 早くコンテンツを見たい -> 順序の最適化
• 待ちたくない -> リクエスト、サイズ、消費メモリの最小化
• スムーズであって欲しい -> 消費メモリの分散化

それぞれに共通な「順序の最適化」、「リクエスト、サイズ、消費メモリの最小化」、「消費メモリの分散化」の観点で、それぞれの手法（アプローチ）をライブデモで紹介します。これは、低スペックな端末で見るとより効果がわかりやすいと思います。

デモで分かるブラウザにやさしいHTML/CSS

ライブデモはこちらのサイトにまとまっています。

http://goo.gl/zA4ZvQ

ID : tech , PASS : tech-lab

DNSプリフェッチ

リソース読み込み順序

OKパターン

NGパターン

JSアニメーションとCSSアニメーションの違い

原則として、JSアニメーションよりCSSアニメーションの方が高速なので、CSSアニメーションを利用するようにしましょう。 特にモバイルでは重要になってきます。 また、モバイルでのCSSアニメーションにおいては、アニメーションする要素はposition absoluteにしなければパフォーマンスで問題が出てきます。

※ライブデモの詳細はYoutube動画をご覧ください。

イマドキのHTML/CSS高速化って？

最後に、イマドキのHTML/CSS高速化ってどうなってるの？とよく聞かれるため、昔と変わってきたことに着目して幾つか取り上げます。

CSSスプライトはしない

メンテナンスコストの方がパフォーマンスにおけるメリットを上回るため仕様はおすすめしません。特にモバイルでは、回線の品質がまちまちまので、スプライトして画像をまとめるとそこがボトルネックになることもあるため、例えば、１ページの画像数が１０個いかであれば、分割しておいたほうがメリットが大きいのではないでしょうか。

＊比較デモがあるため興味がある方はYoutube動画をご覧ください。

CSSセレクタのパフォーマンスは気にしない？

最近はブラウザのCSS実行エンジンが早いので気にしません。よく使います。

可能な限りベクターでコーディング

デザインはCSSで極力再現しましょう。CSSでできない場合はSVG、それが難しいようであればPNGでやりましょう。Webフォントも良いアプローチです。

PCのみ、モバイルのみ、レスポンシブの区分けが大事

それぞれのターゲットによって設計方針は変えていくべきです。

パフォーマンス < メンテナンス

メンテナンス性を犠牲にしてパフォーマンスを追求するのはよくありません。

Webパフォーマンス部の今後の予定

Webパフォーマンス部では、第２回から第１１回まで予定がすでに決まっています。

日本企業が世界に進出するためにはWebサイトのパフォーマンスは大事です！ 今回の勉強会に参加できなかった方は、是非次回以降の勉強会に参加してみては如何でしょうか？

勉強会の動画配信はこちら

＊この勉強会は一見の価値有りです。参加できなかった方は是非一度全編通して見てみることをオススメします。

ライブライティングについて

この記事は、イベント開催中にライブライティングしたもので、改訂履歴は以下の通りとなります。

• 2014/5/9 18:40 – 最終版記事に更新完了
• 2014/5/8 22:00 – イベント終了（この時点では記事は書きかけ）
• 2014/5/8 19:00 – 記事公開

パフォーマンス部ロゴデザイン：Kaori Nishino (@kanishionori)

Test the Web Forward (TestTWF)とは、W3Cの仕様を実装・勧告させるために必要なテストケースをみんなで書こうというイベントです。Adobeが中心となり世界各国で開催され、その成果を認められ昨年秋にW3Cに取り込まれました。

日本でも昨年6月にTestTWFが開催され、成功を収めました。この活動を続けていこうと始めたのがhtml5jテスト部とTestTWF Meetup (仮)です。昨年9月に第1回目を開催しています。

少し間が空いてしまいましたが、4月12日、Test the Web Forward Meetup (仮), Tokyo #2を開催しました。

今回はAdobeさんに会場をご提供いただきました。おしゃれオフィスでした

3つの仕様のテストに挑戦

前回のTestTWF Meetup (仮)では、対象とする仕様を特に決めていませんでした。これはスタッフ側がテストについてあまり知らず「とりあえず書いてみよう」という話から始めたイベントだったため、準備ができなかったことがあります。

しかしそういう状態ではテストのレビューも仕様の理解もできず、満足できませんでした。というわけで、今回は対象となる仕様を決め、さらにそれらの仕様に明るい方をお呼びすることにしました。今回は次の3つを選びました。

• CSS Text Decoration
• ルビ（HTML、CSS）
• Shadow DOM

仕様のEditorやエキスパートに恵まれたため、なかなか先端技術的なセレクションになりました。

午前中はreftest, testharness.jsといったテストの書き方についてセッションを行いました。

testharness.jsの説明はACCESSの関口さんにしていただきました

CSSテストのエキスパートGérardさんも参加

今回はさらに、CSSのテストのエキスパートであるGérard Talbotさんをお招きしました。Gérardさんは数年前からCSSのテスティングに関わり、数千ものテストケースをレビューしたり、テストケースを提供したりしているCSSテストのエキスパートです。

Gérard Talbotさん。モントリオールからいらしてくださいました

Gérardさんには、CSSのテスト用フォント「Ahemフォント」について解説していただきました。Ahemフォントはプラットフォームごとに異なる書体が使われるフォントの差異を埋めるテスト用のフォントで、文字の幅やベースラインからの高さがわかりやすい数値に固定されています。文字も矩形に塗りつぶされるので、組み合わせることで図形を描けたりします。

Ahemフォントで「É p X」を表示したもの。幅は同じ1emでも、高さやベースラインからの位置が違います

他にも「テストの説明文は技術的すぎないこと（たとえば「box」という単語は避けるように注意されました）」「“not ***”などの表現を使う際はそこを太字にすると良い」といった、テストのスタイルに関する助言もいただきました。テストのレビューでは膨大なテストケースを短い時間で処理しなければならないため、簡単に、そしてだれでも判断できる表現が重要とのこと。

Gérardさんとお話していて感じたのは、テスティングへの熱意やひたむきさです。テストに関わる秘訣をお聞きしたところ「情熱をもって取り組むこと。そうすると忍耐強くテスティングに関われる。また、本当にテストが正しいのかを追求する姿勢も大事だ」とおっしゃっていました。彼が「最高傑作」としたテストとして vertical-align の挙動を確かめるテストケースを紹介してもらったのですが、制作には2年もかかったそうです。すべてのテストにこれだけかかるわけではないでしょうが、忍耐強さ、重要ですね……

午後はグループごとにレクチャー＆テスト書き

午後はCSS Text Decoration、ルビ、Shadow DOMとグループに分かれ、テストに必要な知識について学んだり、テストを書いたりしました。

CSS Text Decorationの部屋。Editorである石井さんがW3Cのプロセスから説明しています

ルビの部屋では、積極的に関わっている川幡さんによるHTML/CSSのルビに関するふかーい説明がありました

Shadow DOMの部屋。一番右のGoogle坂本さんに来ていただきました。また、W3Cの会議終了直後で西海岸にいらっしゃるShadow DOMのEditor夷藤さんにもGoogleハングアウトで参加していただきました

仕様もエキスパートの方も参加者も違いますので、それぞれ異なる進み方をしていました。Shadow DOMの部屋はテスト環境構築に少し手間取ったため提供されているドキュメントに追記したり、古いShadow DOMのテストを修正するなど、アクティブな方が多かった印象です。CSS Text Decorationはreftestでテスト可能な機能があるかを探すのに一苦労。Gérardさんの助言などもあり、ひとつの機能について皆で分担してテストケースを書いていました。テスト書きやGitの操作でも助け合っていました。

ルビは仕様で要求する機能が複雑なため、まずはじっくりと時間をかけた説明がありました。それから、シンプルなテストケースを皆で写し書きし、それができたら少しだけ難しくするというステップバイステップなアプローチをとっていました。

テスト部はまだまだテストの書き方について教えるノウハウが足りていません。こうした異なるアプローチを見たことで、いろいろなやり方ができるなあと思いました。今後の活動に活かせればと思います。

イベントも終わりに近づき、みなさんスパートを始めます。今回は合計18件のpull requestが投げられました。またイベント後もレビューコメントの対応をしていただいています。

テスト部の今後

昨年6月のTestTWFはもちろん9月のMeetupでも「人が集まるのかなあ、面白いのかなあ」など、この活動に不安を持っていました。しかし、標準化に貢献できることや仕様の勉強を楽しんでもらえる方が多く、それが活動を続けるモチベーションとなっています。

とはいえ、その場でレビューやテストのマージといった、本家Test the Web Forwardが提供するよさはMeetupには持ち込めていません。レビューやテストのカバレッジなど、本家が持つ課題について、今後はもう少し関われればと思います。また、テスト部とMeetupならではの企画ができないかなども検討していきたいと思っています。

最後に、参加者のみなさん、スピーカー・エキスパートのみなさん、スポンサーのみなさん、スタッフのみなさん、本当にありがとうございました。

関連エントリなど

• Test the Web Forward Meetup (仮) , Tokyo#2 にお邪魔して、text-emphasis-style のテストを書いてきました | Same Old Lucky Day
• Test The Web Forward（アルバム）

Photo credit：仲尾毅、水嶋彬貴

HTML5 Rocksは、開発者向けのHTML5周辺技術に関するリソースを公開しているサイトです。Googleによって運営されており、記事が多言語に対応しているものもあります。

html5j英語部の今回のイベントでは、いくつか記事をピックアップし、グループに分けて翻訳を行いました。

今回翻訳対象としてピックアップした記事：

• User Timing API: Understanding your Web App – HTML5 Rocks
• Avoiding Unnecessary Paints: Animated GIF Edition – HTML5 Rocks
• Avoiding Unnecessary Paints – HTML5 Rocks
• High Performance Animations – HTML5 Rocks
• Scrolling Performance – HTML5 Rocks

英語部名物・ライブ翻訳

前回と同じく、今回も英語部・部長の斉藤さんによるライブ翻訳がありました。

今回のライブ翻訳で挙げたポイントは、次のような斉藤さんが翻訳するときの手順についてです。

抜粋元：JavaScript Promises

In browsers, JavaScript shares a thread with a load of other stuff.

頭から順に訳していきますが、はじめからきっちりと、きれいな日本語に置き換えようとはしません。まず主語（S）と動詞（V）を見つけます。この一文でいえば、「JavaScriptは共有する」というが重要です。その上で具体的に訳していきますが、最初はラフな日本語で大丈夫です。それからきれいな日本語に整形します。

1. 「JavaScriptは共有する」
2. 「JavaScriptは共有する、ひとつのスレッドを、他のものの読み込みと一緒に」
3. 「JavaScriptは、他のものの読み込みと一緒に、ひとつのスレッドを共有します」
4. 「ブラウザーにおいては、JavaScriptも、他のものの読み込みと一緒にひとつのスレッドを共有します」

翻訳の難しさは、英語にあるのではなくて、日本語にあると部長は言います。
英語が得意な人でも、英語のままとしての意味はわかったとしても、それを日本語として意味を違えずに表現することは難しいです。英語部では、オフライン/オンライン問わず、翻訳の経験者による監訳サポートがあるので、翻訳の初心者であっても、アドバイスをもらいながら進めることができます。

HTML5 Rocksの翻訳フロー

今回会場提供をしていただいたグリーの宮崎さんからは、HTML5 Rocksの翻訳フローについてのLTを行ってもらいました。

スライド: HTML5 Rocks translation

宮崎さんは、すでにHTML5 Rocksの7つの記事を翻訳した経験があります。
ちなみに宮崎さん曰く、HTML5 Rocksの記事の単位はrockだ、ということで、7rocksを翻訳したということになります

HTML5 Rocksの翻訳フローは、Git/GitHubを使ったプロダクト開発と同様で、Pull Requestを通して翻訳済みのドキュメントを取り込むという流れになっています。

1. HTML5 RocksのWebサイトのレポジトリをForkする
2. 翻訳したい記事を見つけ、コピーをして/ja/ディレクトリで展開、翻訳をする（詳細は後述）
3. Fork元にPull Requestを送る（送り先はmasterブランチ）
4. Reviewを受けて、Feedbackがあれば対応、問題なければ取り込まれる
5. サイトに公開（liveブランチにマージされる）

未翻訳記事の見つけ方

翻訳したいとおもっても、その記事がすでに日本語訳されていたり、もしくは進行中である場合は、残念ながら翻訳しても載せてもらうことはできません。

翻訳済みの記事は、Localizationsに翻訳された言語へのリンクが存在していますので、その記事は翻訳できません。（もし翻訳内容に誤りなどがあれば、それはそれで修正してPull Requestを送るとよいでしょう）

まだ公開はされていないけれど、進行しているものはIssuesおよびPull Requestsを確認するとわかります。Openのものだけでなく、Closeして公開待ちのような記事もあるかもしれないので、Closeの中も確認しましょう。

翻訳の進め方

記事ページは/content/の中に格納されています。

翻訳したい記事のURLを確認し、該当のディレクトリを探っていくと、/en/ディレクトリが確認できるはずです。その中に原文のindex.htmlがはいっているので、/en/ディレクトリをコピーし、/ja/ディレクトリをつくったら、その中のindex.htmlを翻訳します。 （/ja/ディレクトリがある例）

翻訳対象はこのHTMLファイルだけでなく、/conf/locale/ja/にもある場合があります。記事タイトルはこちらにも含まれている時があるので、該当の記事をみつけたら、msgstrに日本語訳を書きましょう。

また翻訳者のクレジットを残すこともできます。クレジットは、下記のフォーマットで記事内に差し込むことで追加されます。

{% block translator %}
<div class="translator">
  <strong>翻訳:</strong> <a href="https://github.com/hiloki/">Hiroki Tani</a>
</div>
{% endblock %}

翻訳者クレジットが差し込まれている例

その他、翻訳やページの追加に関することは、下記のドキュメントに記載されているので、一度目を通しておくことをおすすめします。

• LOCALIZATION.md（日本語訳）
• CONTRIBUTING.md

翻訳しながら技術的に学ぶ

HTML5 Rocksが素晴らしい技術記事が充実したサイトということもあり、英語を翻訳する経験と力をつけるとともに、技術的に新しく学べるという点で、翻訳のしがいがあると思います。

今回オフライン活動のひとつとしてHTML5 Rocksをグループで翻訳しましたが、引き続きオンラインでも継続しておこないます。

本レポートやhtml5j英語部の概要をみて興味を持ち、また監訳などを受けながら翻訳したい方がいればぜひ参加してください！その際には英語部リポジトリのHTML5 Rocksの内容を一読ください。

もし不明なことがあればIssuesやGitterに連絡をください。

最後に大事なことを伝えておくと、html5j英語部はあくまでも有志による翻訳コミュニティです。 オリジナルであるHTML5 Rocksとは関連はなく、全てのHTML5 Rocksの日本語訳が本コミュニティを通じて行われているわけではありません。HTML5 Rocksの翻訳をしたい！という方は個人でどんどん翻訳をしてもらえれば良いのではないかと思います。

今回会場をお貸しいただいたグリーの皆さん、ありがとうございました！

2014年3月22日、リクルートメディアテクノロジーラボ (MTL) にて、デザイナーとエンジニアでつくるWebプロトタイプとユーザーテストを行うイベント「デザイニアン002」が開催されました。

プロトタイピング作成の意味と利点とは

プロトタイプ作成で得られる利点は、早い段階で設計を多様な角度から検証し、企画や機能を実際に体験することでユーザーからフィードバックを得て問題解決に役立てられることです。

可能な限り早期に問題を見い出して、制作の工程を最終的には早くて手戻りのないものにする。そして、検証結果から多くの問題を修正することで、ユーザー体験をより理想の形に近づけることが可能となります。

はじめに部長の秋葉さんより、イベントの趣旨／本日の流れ等の全体の説明が行われました。

以前ご紹介した「html5jデザイン部が目指す、ユーザー体験も含んだデザインを実体験で学べるイベントとは」と同様、「JRの新幹線予約サイト『えきねっと』を、目的の新幹線チケット購入までたどり着きやすくする」を課題にし、

1. 課題のサイトの問題の洗い出し
2. 情報整理と仮説
3. プロトタイプ作成
4. ユーザーテスト
5. ヒアリング　

の流れで行いました。

エンジニアの方には、デザイン部エンジニアが少ない時間の中で、できるだけ早く進められるようイベント用に用意したテンプレートを渡し、作業してもらいます。

説明の後に、デザイナーとエンジニア2～3名ずつのチームを作り課題に入りました。

前半はそれぞれのチームでディスカッション。

後半は、デザイナーとエンジニアが各々の担当分を制作していきます。

18時には、テストユーザーの皆さんが到着。各チームに1人テストユーザーが着席し、課題で作成したプロトタイプを操作していきました。

一通りテストが終わったところで、各チームごとに何に問題を感じ、どのようなコンセプトでつくったのかをプレゼンテーション。テストユーザーの方には、操作した感想を発表していただきました。

チーム1）　不必要な機能を削除し、画面をわかりやすく

どんなふうに到達するのが違和感ないのかを考え、不必要な機能を消し必要な機能のみで作ることにした。制作者側として画面の流れはわかりやすくなったかと思いましたが、デザインを適用する時間が足りなかった。乗車する日にち選択で、テストユーザーの方の「iPhoneの”ドラムロールUI（※1）”はわかりづらい」という意見が参考になった。

※:iPhoneの”ドラムロールUI
　正しくはDate Pickersと呼ばれているUI。HTMLのselect要素を使ったときに出てくるUIを本記事では「ドラムロールUI」と呼称しています。

[テストユーザーの感想]
ビジュアルとしてはっきりしておらず、薄い線などで見にくいと操作がしづらい。iPhoneのドラムロールUI式カレンダーは使いにくい。ネットに慣れていない人間は緑の窓口で購入する機会が多く、自分の記憶の中から勝手に窓口でのイメージを求めてしまうため、券売機に近いデザインの方がエンドユーザーには使用しやすい。

チーム2）　無駄なスペースを削り、スクロールを減らす

入力フォームの項目に関しては縦並びにせずに、画面の横につめられる内容のものはつめて、少ないスクロールで必要な情報を見られるようにした。検索結果のボタンの色が変えて、わかりやすくと考えた（時間不足で未実装）。

[テストユーザーの感想]
チケットの有無を「○」「△」「×」で表示する方がわかりやすい。
検索結果に時間が何時から何時と出ているのがわかりやすかった。料金の比較もあるとわかりやすい。
自分が医療関係者なのでその視点で考えると、障碍者は対人コミュニケーションを避ける傾向があり、窓口での購買よりもスマホ使うことが多いと思う。白内障や色盲の人には白と黄色の組み合わせが判別しにくいので、スマホサイトに背景が黄色で文字が白、といった組み合わせは避ける方が好ましい。

チーム3）日付と時間をわかりやすく設計

ユーザーが何をしたいのかを重要視した。日付と時間がわかりやすいことが重要と考えて、画面一番上にした。クリックしたら表示されるようにしたが、反映しきれなかったので迷わせてしまった。
流れを直感的に予約できるようにし、必要な情報をしぼることを心がけた。時間がなくデザインが当て込めなかったが、ユーザーは意外にわかってくれるということもわかった。

[テストユーザーの感想]
最初つまづいたが、使っているうちにわかった。時間不足で機能していないボタンがあったので、どうとればいいかわからなかった。

チーム4）操作しにくいラジオボタンから、押しやすいボタンに

検索画面のわかりやすさを考えて操作順にタブ式に選択できるようにした。スマートフォンではラジオボタンでの操作はしにくいという判断をして、ボタンとして押しやすいように制作した。
往路を購入する場合は一度に往復を購入するのではなく、まず往路を購入し、片道を購入してから復路を買うボタンと完了ボタンを作り、ユーザーが動線を迷わないようにした。

[テストユーザーの感想]
やっぱりiOSのドラムロールUIの操作がわかりづらい。Androidの方が日にちを選びやすい。

チーム5）　ぱっと見た瞬間に空席が表示される

UIの要素を極力減らしてシンプルにする方向にし、不要な要素は削除した。ぱっと見た瞬間に必要な情報がある程度出るように考え、席がどの程度空きがあるかを表示するようにした。階層的に選べるようにした。

[テストユーザーの感想]
空席を探した時に「○」「△」「×」が表示され残席数がおおよそわかる点が良かった。指定席の空席がないとわかった時点で、そこから再検索できれば使いやすいと思う。
ボタンが小さくて狙ったところを押せないとストレスになるので、大きめのボタンの方がよかった。ロード中にロードしていることがわかるようになっていると良いと思いました。

チーム6）カレンダー表示やボタンサイズの拡大

日付の予約は、カレンダーで表示させた。縦横表示できるようにした。席選択のボタンを色分けし、見てすぐ判別できるようこだわり、スマホで選択しやすいようボタンサイズを大きくした。
配布テンプレートに戻るボタンを追加し、動線をわかりやすくした。機能の取捨選択をすることが大事だと思った。こういった場があったことを感謝しています。

[テストユーザーの感想]
乗車駅と降車駅がドラムでの選択でなく、キーボードで1文字入れると予測結果が表示される方が、個人的に使いやすい。
ラジオボタンは小さすぎて親指で隠れ押しにくいので、大きい方が良い。人数をテンキーで入力する仕様でつくられていたが、使いやすくて良い。
検索結果がたくさん表示されるより、精度のよいデーターが絞り込まれて出るほうがいい。選択項目を色分けしているのがわかりやすくて良かった。

イベントを終えて

テストユーザーの方には、iOS 7とiOS 6両方で比較してもらいました。iOS 7ではシンプルに線が細くなっていますが、iOS 6のドラムの方が線も文字もはっきりし、選択するとチェックが出るのでわかりやすい、という意見も出ました。

短い時間の中で、各チームのデザイナーとプログラマが課題に対して問題解決を図るアイデアを出し合う。多様なアプローチで試行錯誤することで、さらなる問題解決の可能性を見い出せた印象を抱きました。

イベントを運営した我々デザイン部一同、参加者の皆さんやテストユーザーの皆さんから学ばせて頂く機会となったことに感謝するとともに、 デザイン部では今後も積極的に取り組んでいきたいと思います。

2014年2月28日にhtml5jエンタープライズコミュニティ主催で「Enterprise x HTML5 Web Application Conference 2014」が開催されました。オープニングパネルディスカッションの模様を中心に、HTML5とエンタープライズITの過去、現在、そして未来についての熱い議論をここにまとめます。

HTML5はエンタープライズITにおける3つのニーズを解決する

はじめに、html5jエンタープライズコミュニティの部長である川田氏からカンファレンス開会宣言が行われました。その中で、川田氏は、エンタープライズ分野でHTML5は次の3つのニーズを解決してくれると期待していると述べています。

ニーズ1「多様化するクライアント環境に対応する」

業務系システムでは、クライアント側の環境を中央集権的に管理することが求められます。そのため、クライアント環境は機種を限定した専用マシン、ミドルウェアについてもソフトウェアやバージョンを限定したものを用意して、カッチリと管理することが一般的に行われます。しかし、昨今のスマホやタブレットの普及によって、クライアント環境は大きく様変わりしています。モバイル環境にフォーカスすると、十分とはいえないデバイス管理機能、デバイスのフラグメンテーション、通信環境の多様化、セキュリティへの配慮の難しさなど、業務系システムを動作させる上でのハードルはかなり高くなっています。

そのような課題に対処するためのソリューションとして登場したのが、MEAP（Mobile Enterprise Application Platform）というアーキテクチャです。MEAPは、エンタープライズ向けのモバイルアプリの開発・管理を一元的に実現するサーバサイドの仕組みとクライアントサイドの仕組みを提供するプロダクトのことで、様々なベンダーから製品が提供されています。MEAPについては、ビジネス＋ITさんのサイトにわかりやすく解説されていますので、興味がある方はご一読下さい。以下、MEAPとはについて、一部引用させていただきました。

提供ベンダーによって機能も異なるが、モバイルの開発環境、配布・デプロイ、アプリケーション運用・管理のほか、アクセス認証、ユーザー管理、ログ管理、テスト環境、基幹系との連携などの機能が提供される場合もある。

引用元：ビジネス＋IT – MEAPとは（http://www.sbbit.jp/article/cont1/27694）

ニーズ2「ネイティブアプリライクなリッチアプリケーションを作成したい」

業務系システムの開発ではjQuery Pluginがよく利用されています。ベンダー製品も豊富に出ており、開発者が手軽に扱えることがメリットの一つとなっています。また、昨今では、クライアントサイドの開発のための様々なJavaScriptフレームワークが登場しています。これらを活用することで、Webアプリケーションでありながら、大規模かつ、ネイティブアプリライクなリッチアプリケーションを手軽に開発することが可能になりました。しかし、手軽といっても、JavaScriptフレームワークは、jQuery Pluginに比べ学習コストは高めなので、導入する上では検討が必要となります。

ニーズ3「営業から運用までトータルでサポートして欲しい」

HTML5を活用したアプリケーション開発では、以下のとおり、営業から開発・運用に至る全てのフェーズにて、作業を改善するための様々なツールが登場しています。これらを活用することで、開発効率を向上させることができます。

• 提案フェーズ：ノンプログラミング・ツール、GUIツールの活用
• 設計フェーズ：UIコンポーネント、JSフレームワークの活用
• 実装フェーズ：Gruntなどのタスクランナー、HTML5開発対応IDEの活用
• テストフェーズ：画面テスト、JSテストの自動化支援ツールの活用
• 運用フェーズ：MEAPの活用

エンタープライズITにおける次世代アーキテクチャの5大要素

開会宣言の最後に川田氏は、HTML5がどのようにエンタープライズITのアーキテクチャに影響をあたえるのか、次の5つのレイヤに分類しまとめました。

エンタープライズITにおける次世代アーキテクチャの5大要素

この中で、とりわけ重要なのは通信レイヤーの存在で、通信レイヤーに何を利用するかによって、システム全体のアーキテクチャや利用するベンダ製品が決まってくることが多いとのこと。また、今はWebSocketの利用が前提になってきているとも、付け加えました。

カンファレンス開会宣言の資料はこちらで公開されています。

HTML5とエンタープライズについて白熱した議論が！

開会宣言に続き、パネルディスカッションが行われました。パネリストに、日本マイクロソフト株式会社のUXエバンジェリストでRIAコンソーシアム理事の春日井良隆氏、株式会社オープンウェブ・テクノロジー代表でhtml5jファウンダーの白石俊平氏、html5jエンタープライズコミュニティ部長でNTTコムウェア株式会社技術SE部の川田寛氏を迎え、モデレーターは私、仲裕介が務めました。パネルディスカッションでは、HTML5とエンタープライズITに関して、過去と現在そして未来について、以下の様な流れで議論がなされました。

• HTML5はなぜここまでウケたのか？
• HTML5の現状はどうなっているのか？
• HTML5はエンタープライズの現場をどう変えるか？

ここでは、パネルディスカッションでの議論の模様を筆者の独断で要約してご紹介します。当日の様子はYouTubeのhtml5jチャンネルで公開中（動画へのリンクは記事末尾参照）です。参考までに議論が行われた動画上の再生時間を併記していますので、議論の詳しい内容が気になる方は、記載した再生時間を参考に動画を視聴してみて下さい。

HTML5はなぜここまでウケたのか？（動画では19:07頃）

【春日井氏】HTML5の登場で、FlashやSliverlightなどのプラグインの代わりに、Video要素やCanvas要素を活用したビデオ再生やWeb上での様々な表現が可能になった。最初に注目が集まったのはそういった部分だと思う。エンタープライズの分野では、Internet Explorer(以下、IE)9やIE10からHTML5に関連した様々なAPIが充実しはじめ、アプリケーション開発に十分に活用できるようになったことから、流行り始めた。また、開発者はオープンソースが好きで、基本的にどこかのベンダーにコミットするということはあまり好まない。そういう点からも、オープンなWeb技術であるHTML5は心理的に受け入れやすかったと思われる。

【白石氏】Web画面をリッチにしたいというニーズは昔からあり、IEではContent EditableやXHRなどの先進的な機能をIE5やIE6の頃から実装していた。しかし、Web標準が追いつかず世の中に浸透しなかったため、各ベンダーがプラグインを活用しそのニーズに答えていった。そこに、Web標準の舞台でWeb画面をリッチにするというニーズに答える、HTML5という技術が登場したため、ここまでウケたのではないか。

【川田氏】HTML5のムーブメントが起きるきっかけは、「プラグイン古いね、使いにくいね」という議論が出てきた2010年頃と記憶している。その後、マルチデバイス対応のニーズが高まり、MEAPというアーキテクチャを取り入れたベンダー製品が登場した。そのようなムーブメントにエンタープライズは大きく影響を受けるとともに、プラグインが使えない状況で、Web上でリッチなUIを作りたいというニーズが高まり、jQuery PluginやJavaScriptフレームワークが充実していき、昨今のHTML5のムーブメントにつながったのではないか。

ここで白石氏より、MEAPを活用しているかどうか来場者へ質問が行われた。結果、活用していると答えた方は０人。また、知っていると答えた方は3人ほどにとどまったため、ここで、川田氏によるMEAPの説明が行われました。（動画では26:30頃）

HTML5の現状はどうなっているのか？（動画では30:28頃）

【春日井氏】別の勉強会の発表資料によれば、昨年末の段階で、東証一部上場企業（約2000社）のコーポレートサイトでDOCTYPE宣言をHTML5で行っている会社は9.4%しかなく、専用サイトやレスポンシブデザインによるスマホ対応を行っているサイトは14.9%にとどまっている。普及という意味ではまだまだな印象。発注側やWebマスターサイド、それぞれの諸事情により、対応は進んでいないと思われる。

ここで白石氏から、来場者へHTML5への対応状況についての質問が行われた。結果、HTML5対応、スマホ対応を行っていると答えた人は3名ほど。統計情報通りだという結論になりました。

【川田氏】これでもまだHTML5は導入されている方ではないか。エンタープライズにおけるHTML5導入は今年が元年だと思っている。HTML5をエンタープライズに適用させるための各種プロダクトを含めた環境、技術者育成の仕組みなどが回り始めたのは2013年に入ってからであり、これから適応事例が増えてくると考えている。

HTML5はエンタープライズの現場をどう変えるか？（動画では38:20頃）

オープン系技術の導入において開発用ツールの選定は非常に重要

【川田氏】HTML5はオープン系技術。技術がベンダー系からオープン系に変わると開発難易度は高くなり、現場としてはしんどくなることも。しかし、コストメリットに押されてそれを採用せざるを得ない状況になる。設計については、Visual Basicが流行った頃のように、UIにもサーバ側にも業務ロジックがあるようなタイプにシフトするのか、現状のjQuery Plugin利用程度に留まるのか、まだ行く末の判断はできない。

【春日井氏】HTML5を活用した開発に関しては、開発用ツールを使うことが非常に重要になってくる。ベンダー製品のメリットはプラットフォームとセットで開発用ツールを出しているところにある。Microsoft製品であればSilverLightとVisual Studio Expressionみたいな。しかし、オープンソース製品では開発用ツールはバラバラなので、ツールの選定は開発においてとても重要になる。

【白石氏】昔エンタープライズでJavaを書いていた経験から、ベンダー系とオープン系では開発用ツールに関するアプローチ方法が異なると考えている。Java開発用のリッチな開発用ツールは様々なプロダクトが出ては消え出ては消え…結局は手書きに落ち着くということも経験した。それに比べ、Microsoft製品であれば、バックエンドからフロントエンドまでMicrosoft製のツールで固められるので、開発がすごく楽な印象があり、とても幸せそうな世界に見えた。

ここで春日井氏から「本当に幸せなんです！」というツッコミとともに、川田氏から、今の開発では、フロントのUIコンポーネントをドラッグ・アンド・ドロップで作成すると、サーバサイドまで自動で実装されるようなリッチなIDEが大手ベンダーなどから登場していると、コメントが付け加えられました。

【白石氏】HTML5の登場以前はサーバサイドレンダリングが主流だったが、HTML5の登場によってクライアントサイドでのMVCが実現できるようになった。ネイティブアプリ開発と同様にリッチな開発用ツールを活用した、ドラッグ・アンド・ドロップによる開発も十分に可能になると考えている。

開発プロダクトにおける責任の所在の変化

【春日井氏】ベンダー系技術を利用すれば開発における全てのフェーズにおいて、ある一定以上をベンダーの責任として責任転嫁することも可能だが（実際に、全てMSのせいだといわれることも…）、オープン系技術を利用する際は、自分たちで最後まで責任を取る必要がある。その反面、W3Cなどに積極的にコミットすることで、自由に仕様を作っていけるというメリットも享受できる。

春日井氏のコメントを受けて川田氏からは、オープン系技術であってもRed Hatなどそれをサポートするベンダーが存在する。白石氏はそれを受けて、オープン系技術であってもある程度のサポートを行って欲しいというニーズが存在し、それを請け負うことでサポートビジネスが成り立っていると、付け加えられました。

Web Componentsの登場が今後の開発現場に与える影響

ここで白石氏から、Web標準で議論が進んでいるWeb Componentsについての話題が出ました。来場者の認知度は4割ぐらいで、結構高い印象。白石氏から春日井氏へ、マイクロソフトとしてコミットしようとしているのかという質問。

【春日井氏】HTML5LabsでWeb Componentsは取り上げられており、現在、研究開発部門でどうやってブラウザや開発ツールに実装するのか、検討されている。

【白石氏】Web Componentsが出てくると、それを開発するツールはベンダー独自だが、そのコンポーネント部分はWeb標準という面白い状況になる。

ブラウザのバージョンアップサイクルの変化

【春日井氏】運用という観点では、ブラウザのバージョンアップサイクルが早く、ChromeとFirefoxは6週間、IEは2年に1回バージョンアップを行っている。6週間に1回出てくる新しいブラウザを検証するのは現実的ではない。そういった現状をふまえると、サポートを行う・行わないという線引をある程度決めていく必要があるのではないか。

ここで白石氏から、素早いバージョンアップで後方互換性を維持したまま、セキュリティアップデートや最新機能が提供されることに、エンタープライズITとしてはメリットを感じないのか、という問いかけがありました。

【川田氏】短いサイクルでのセキュリティアップデートは問題ないが、機能改善を行うところは問題。また、サイクルが短くなっているという点で言えば、WindowsXPでは、標準ブラウザ（IE6）のサポートはXPのEOLまで有効だったが、現在のWindows8は、サービスパックが出た時点で標準ブラウザもバージョンアップしてしまう。つまり、ベンダーサポートのライフサイクルが短くなっている点に注意する必要がある。同じブラウザを使い続けられなくなるため、運用という観点では、難しい時代が始まる。

【白石氏】Web標準に準拠したアプリケーションであれば、あるべき論を言えば、ブラウザが変わろうとも、Web標準のこの技術を使っている限りは正常に動くことを担保できなければならない。Web標準のルールはそういうことではないか。

【川田氏】IE6の頃と比べると、プラグインレスになり仕様もWeb標準に準拠したものになってきているので、エンタープライズも今後はそうなっていくのではないかと考えている。

【春日井氏】マイクロソフトのIE開発チームが目指すべき方向、理念はそれと全く同じである。IE11でSame Markup（同じマークアップをしたらブラウザが違っても同じように動作する）という考え方を打ち出したように、現在のブラウザ開発はその理念に基づいて行われている。しかし、エンタープライズでは、IEを勝手にアップデートしたくないというニーズもあり、それに答えるためのブロッカーツールや、ブラウザを個別にカスタマイズしたいというニーズに答えるための、IEAK（Internet Explorer Administration Kit）というツールも提供しており、利用をおすすめはしないが、今までどおりのライフサイクルに近い形でIEを利用する環境も整えている。

会場からの質問タイム（動画では01:02:02頃）

三者によるディスカッションが終了した後は、会場からいくつか質問を受け付けました。

• 質問1「XPのEOLに伴い、IE8をミニマム標準とする考え方は見直されるのか？」

【川田氏】IE8よりも、知らない方もいるかもしれないが、IEに搭載されているドキュメントモードのお陰で動いているWebアプリが、今も結構世の中にあることに注意する必要がある。しかし、Windows7 EOL（2020.01.14）以降のブラウザはドキュメントモードが存在しない。したがって、そういうシステムのEOLは必然的に決まってしまっている。そこを見据えた提案をSIではこれからやっていく必要がある。

【春日井氏】マイクロソフトとしては、IE6という、かつて皆様に愛されたブラウザを収束させることに現在は重点を置いている。IE8のクロージングについては、その後に検討する課題として捉えている。

ここで春日井氏から、IE11は過去のIEとの互換性を保ちつつ、今後のあるべきWeb技術のサポートの両方を目指す新しい考え方のブラウザになっているとコメントがありました。

【川田氏】ドキュメントモードをIE11から非推奨にしたという点について、大変良い判断だった考えている。非推奨になった機能はだいたい2バージョン後に消えているので、5年後、つまりはWindows7のEOL時期目前でドキュメントモードが廃止される計算になる。

• 質問２「HTML5で業務システムをガリガリ開発している先進的なユーザ企業はどこか？」

NTTコミュニケーションズでSenchaを活用した事例などが飛び出しましたが、その場では具体的な企業名は出てきませんでした。春日井氏によれば、先進的な事例を日本の開発ベンダーは大事にされるので、教えてほしいという要望はたくさんいただく、ということらしいです。

当日のセッション動画

パネルディスカッションを含む本カンファレンスの全てのセッションはこちらで視聴することができます。再生リストから再生したい動画を選択して下さい。

全セッションの資料

動画と合わせて全セッションの発表資料についても、以下カンファレンス公式サイトに掲載していますので、興味がある方はご覧ください。

Enterprise x HTML5 Conference 2014 – エンタープライズIT向けWeb標準技術のソリューション展

カンファレンスのレポート記事

カンファレンスに関するレポート記事が公開されていますので、ご紹介します。

• なぜエンタープライズITでHTML5が注目されているのか？Web業界のキーパーソンが議論（ビジネス＋IT）
• エンタープライズの課題解決を考える「Enterprise x HTML5 Conference 2014」レポート（おやつ問題解説付き）（CodeIQ MAGAZINE）
• エンタープライズ開発現場が知っておきたいHTML5の4つの意義（＠IT）

photo credit: Miyuki Baba

会場は多くの参加者でいっぱいとなった

このイベントは世の中で行われているITやWeb系の勉強会やセミナーとは大きく趣向が異なり、拙作「HTML5KARUTA」を使ったゲームの大会を中心としたミートアップのような、宴会のようなイベントでした。企業同士のトーナメントをお酒を飲みながら観戦したり、談笑したり、用意されたブースで遊ぶこともできるというカジュアルなスペースを作ったつもりです。来場された方も通常のWeb系のイベントとは違う雰囲気に驚かれたかもしれません。

イベントではいくつかのブースを設置していた

イベントの様子はhtml5jのYoutubeチャンネルでも録画・配信されています。
HTML5KARUTAイベント問題の正解発表と解説は、CodeIQ MAGAZINEで公開中です。

そもそもなぜ「カルタ」なのか

HTML5KARUTA

HTML5KARUTAは、HTML5をこれから勉強するデザイナーやディレクター、学生や新卒採用者の学習の入り口として、マークアップエンジニアの再学習のためのツールとして作ったものです。すでにHTML5要素について理解の深い熟練者は読み手として参加し、ゲームをしながら解説を入れる役割を担うことで自分が正確な理解ができているのか再確認をすることもできます。

私がこうしたゲームによるHTML5の学習の手段を作ろうと考えたのは、実は有名な「桃太郎電鉄」というテレビゲームシリーズの影響によるところが大きかったと思っています。

このゲームはすごろく形式で日本各地の物件を買って周り資産を増やすゲームなのですが、勝利することまたは楽しむにはどこになんという名前の駅があるか、どんな産業があるかの理解が必要とされます。学生の頃地理に詳しかった人はこのゲームを遊んでいたのではないかと思いますし、同じようなことは歴史における戦略シュミレーションゲームにも言えると考えます。ゲームに熱中している間に知識が増える、これはとても良い学習の形だと思うのです。

読み札が要素の説明、取り札には各タグが書かれている

カルタの読み札は各HTML5の要素の説明となっており、どの要素のことを言っているかわかったら、そのタグが書かれている札を取ります。カルタというゲームの形をとっていますが、これは言ってしまえば単語帳を読んでいるようなものであり、プレイヤーはゲームに参加する上でその全ての説明を聞かされることになります。構造的に、説明が頭に入り、理解しやすいゲーム性になっているのです。

技術者、利用者同士の共通言語となり得るHTML

今回のイベントでは、Google、日本マイクロソフト、アドビ システムズといったWebの中心的企業のほか、クリエイター集団であるカヤックやチームラボに、NHN PlayArt、はてな、グリーのようなサービス運営、そしてLIG、プライム・ストラテジーというWeb制作会社の全10社に参加して頂きました。企業自体もバラエティに富んでいますが、それぞれの企業から名乗りを上げて頂いた方々一人ひとりの職能も、エンジニアであったりコーダーであったり、デザイナー、アプリ開発エンジニアなど様々です。

決勝戦の様子。様々な職域の制作者が一緒に遊んでいる

これら全ての業務領域の違う制作者の皆さんにとっての共通言語となり得るものは、やはりHTMLだと思います。そしてもちろん、今回参加してくれた技術者や開発者のようなプロフェッショナルでなくともHTMLは書きますよね。ブロガーやマーケターのような人でも同じゲームで遊び、ライトに学ぶことができます。

このゲームではHTML5を題材としていますが、もちろんCSSやJavaScriptで同じようなゲームを遊ぶことができるでしょう。

イベントや活動の意義について

HTML5KARUTAは2012年の12月に生まれ、13年の1月には全国のコワーキングスペースでこのカルタで実際に遊ぶイベントを開催しました。その後も各地のイベントの余興として、専門学校のイベントとして、または社内勉強会やレクリーションなどのために使われています。

各地で行われたカルタ大会

HTML5の仕様は現時点では勧告候補という状態にあります。現時点で販売している最新版のHTML5KARUTAには2013年8月時点で削除されたcommand要素とmenu要素が収録されており、その際追加されたdata要素は未収録です。2014年HTML5は勧告に達する予定ですが、その際にはこのカルタも完璧な形にできるのではないかと考えています。

前述の通り、HTML5KARUTAは「遊べる参考書」です。カルタを遊ぶことで自然と要素の意味が覚えられ、知識が深まり、プレイヤー同士の議論やコミュニケーションを促すことができます。一式遊ぶことで、全ての要素を知ることが可能です。

今回のイベントのように、ときには楽しいイベントとして学習を扱うこともあってよいのではないでしょうか。

ちなみに現在はHTML5KARUTAのオンラインゲームも公開しています。一人で遊ぶことが可能なので、こちらで修行するのもいいと思います。

ゲームで一人で練習してみるのもアリ

今後も大小様々なイベントを開催していくと思いますし、カルタを購入された方がこれを使ったイベントを行うことも自由です。この活動を皆さんにも応援頂けると嬉しいですね！