こんにちは、編集長の白石です。

昨日（2015年8月27日）、「IoT / WoT」をテーマにした「第59回 HTML5とか勉強会」に参加してきました。 この記事では、イベントの模様や参加した感想をレポートしたいと思います。

ちなみに、「IoT」（Internet of Things）はバズワードなのでご存じの方も多いと思いますが、「WoT」というのは「Web of Things」の略です。「IoTのWeb版」と言えばわかりやすいでしょう。個人的には「WoT」という言葉にはどうも「IoTブームに乗ってやれ」という（何者かの）意図があるような気がしていて、ちょっと懐疑的でした。リソース食いだし、デバイスの機能を自由に使うこともできないWeb技術は、IoTとは相性悪いんじゃないか…と。

しかし、今回のイベントに参加して、そうした疑いは晴れました。「Web×デバイス」の勢い、まがい物ではなさそうです。そしてその勢いをさらに推し進める一員になりたいな…と思ったのも正直な気持ちです。それくらい、最先端では楽しいことが起きている。

では、前置きが長くなりましたが、イベントの内容を簡潔にご紹介していきたいと思います。 イベント自体の内容が盛りだくさんでしたので、今回のレポートでは前半の2セッションのみのご紹介となりますがご容赦ください。

また、講演資料はアップされたのを確認次第、追記していきます（現在のところ、2つ目のセッションに関する資料しか見当たりませんでした）。

「myThings開発者のMaker Faire Tokyo体験記」

1つ目のセッションは、ヤフー株式会社の河合将臣氏と畑元氏による 「myThings開発者のMaker Faire Tokyo体験記」でした。

「myThings」とは、2015年7月にヤフージャパンがリリースしたプロダクトです。 複数のWebサービスやデバイスを自由自在に繋いで、いろんなことをオートメーションさせられるサービス／モバイルアプリです。

と、この説明を聞くと「それってIFTTTと何が違うの？」と思ってしまうのが自然な流れ（？）。

このセッションでは、その疑問にもしっかり答えていました。いわく、

• 日本語対応
• Yahoo! Japanのサービスが使える。特に、通常API経由では利用できないサービスやデータを使えるのは強み
• 国内で展開されているサービスも利用できる。代表的なのははてなブックマーク。

だそうです。

また、IDCF Cloudというプラットフォームも用意されており、自作のガジェットとmyThingsをつなぐことも可能。MQTTやWebSocket、REST APIに対応しているそうで、Web技術者でも簡単に扱えそうなのが魅力。

セッションの後半では、Maker Faireにヤフーさんが出展された時の（もちろんmyThingsとIDCF Cloudを使った）デモアプリを、内部設計や作業工程も含めて情報共有していただきました。

Web技術者がハードウェアの設計・製造まで行ったということで、その過程で気づいたことを以下のようにわかりやすくまとめています。

「WebController for V-Sido CONNECT：WebRTCとWebGLで作る人型ロボット遠隔操縦システム」

２つ目のセッションは、株式会社アトモスデザインの児玉 哲彦さんによる「WebController for V-Sido CONNECT：WebRTCとWebGLで作る人型ロボット遠隔操縦システム」でした。

第59回 HTML5とか勉強会 ーIoT/WoT発表資料「Web Controller for V-Sido CONNECT：WebRTCとWebGLで作る人型ロボット遠隔操縦システム」

このセッションのウリは、とにかく「ホンモノのロボットをWebブラウザで動かせる！」という点。Google Chrome上で動作するWebアプリから、ロボットの手を動かしたり足を動かしたり、果ては怒らせたり。

「JavaScriptでロボットを動かす」なんて、数年前では考えられなかった事態に感動です。

そもそもV-Sido CONNECTというのは、人型ロボットを作るためのOS（そんなのがあったのか…）である「V-Sido OS」用のマイコンで、公式HPによると「シリアルサーボモーターをつなぐだけでロボットを作ることが可能です。」「V-Sidoの一部機能がマイコンに搭載されているので初心者でも簡単にロボットを動かすことができます」とのこと。

今回の児玉さんの発表は、この「V-Sido CONNECT」をWebブラウザ上から制御できるというプロダクトの紹介というわけです。 このWeb Controllerはどう動作しているかというと、Webアプリとスマホアプリを連動させ、スマホからBluetoothでロボットの制御信号を送っているとのこと。先ほどのmyThingsといい、スマホがIoTデバイスのハブになるという流れなのは間違いなさそうです。

また、Webアプリとスマホアプリの通信はWebRTC（及び、NTTコミュニケーションズのSkyway）を使用しているそう。WebRTCを使う決め手となったのは、映像や音声を扱うことができるから（ロボットのカメラから映像を受信したりできる）。

以下の比較表は中々興味深いです（写真ボケててすいません）。

WebRTCのおかげで、なんとドイツから日本のロボットを動かすといったような接続性を確保できたとのこと。地球狭い。

そして、Webエンジニアであれば気になるコーディング方法ですが、以下の表に示すように、非常に簡潔なAPIです。たったこれだけでロボットに複雑な制御を行わせることができるというのは、Web技術者にとってはありがたい限りです。

2000年代の「ユビキタスコンピューティング」に足りなかったものは今は揃っており、WoT時代の幕開けを感じさせてくれるセッションでした。

まとめ

今回紹介しなかった後半の内容（MozillaのFirefox OSベースのマイコン「CHIRIMEN」や、NTTコミュニケーションズ小松さんによるRaspberry PiとWebRTCを連動させた話）も非常に興味深かったので、気になる方はTwitterでイベントの様子を確認してみてください。

イベント全体の模様をを動画でご覧になりたい方はこちらからどうぞ。

このIoTブームの中、「Web技術者にできることを広げようとしている人たちが多く存在する」「Web技術者にできることはたくさんある」ということを実感させてくれる、非常にバリエーション豊かな内容でした。

毎年6月第2土曜日に開催される＜htmlday＞。日本のWebを盛り上げようというお祭りで、日本全国でWebに関する27ものイベントが開催され、イベント参加人数は総勢1233人にも及んだ。

東京では懇親会を含め22時で終了する「第58回 HTML5とか勉強会」が、＜htmlday＞の最後を締めくくるイベントとなった。そのトリを飾った勉強会で発表された「Google I/O 2015」と「de:code 2015」の最新技術情報をダイジェストでレポートする。

Google I/O 2015の会場は非常にオープン

最初に登壇したのはGoogleの鈴木拓生氏。セッションタイトルは『Google I/O 2015 レポート』。鈴木氏はGoogle I/OにGoogle社員として参加。I/Oはお客さま優先なので、社員は控え室で見ている。キーノートをパブリックビューイングするのだそう。「今年のI/Oは雰囲気が変わった」と鈴木氏。

これまでは個別の部屋に入ってセッションを聞くスタイルだったのが、今年は半分オープン、半分クローズな場所でセッションが行われた。例えば「このセッションは少し自分が聞きたかったものと違うかも」と思えば、すぐに出られる、面白そうだと思えばのぞけるようになっていたという。

このようなオープンなコンセプトは会場全体を包んでいた。CodeLabsも「オープンなスーペースに設置した」と鈴木氏。そうすることで「コードで詰まっている人を見かけると、僕たち社員がサポートする。これまでのような一方通行で聞いていただくという形式ではなく、フランクに深い話ができるような環境になっていた」と写真と会場の雰囲気を紹介した。そして、Google I/Oで発表された話題の紹介へ。

Google I/Oで発表された注目の話題とは

まずはAndroidについて。Androidは世界で10億台以上売れており、毎日150万台以上の新しいアカウントができている。昨年1年間でGoogleプレイを通じて開発者の人たちにGoogleが支払った金額は70億ドルにも上る。

「AndroidのOSはタブレットから始まり、ウェラブル、テレビなどへと広がっている」と鈴木氏。スマートフォンでは新しいAndroid Mというデベロッパープレビューを公開。それに伴いパーミッションやNow on Tap（今までのGoogle Nowを進化させたもの）、App Link（検索のときに何かアプリがクエリーに反映する）などが追加された。

2014年6月に発表したAndroid wareも粛々と進化している。14年12月にWatch Faceが作れるようになったこともその一つ。これにより、多種多様のAndroid wear端末に対して、さまざまなWatch Faceが作ることができ、自分好みのウェラブル端末を手にすることができるようになった。AndroidTVについてもI/O周りでアップデート情報が語られたという。

Polymerが1.0にアップデートされたことで、Google I/Oでは「OSの話が多かったのでは思われたかもしれない。しかし今年のI/Oで一番伝えたかったメッセージは、Adaptive UIだ」と鈴木氏は語る。

Adaptive UIとは何か。例えばモバイルとPCでWebサイトを見たときにUIが違ったり、ネイティブアプリで見たUIとPCでみたUIが違ったりすることはよくある。そういったユーザーエクスペリエンスを途切れさせないようにするというのがAdaptive UIである。

つまり「Design for device independence：Mobile+Web、Portrai+Lndscape：複数のデバイスやポートレート、ランドスケープごとに適切なデザインにする」ということだ。今後ますますさまざまな人がさまざまなデバイスで情報にアクセスする世界になる。

だからこそAdaptive UIのセッションに時間を割いたのだそう。そしてAdaptive UIに重要な役割を果たすのがPolymer1.0である。実は今年のGoogle I/OのサイトはモバイルWebで見てもPCで見ても同じになる。これはフルPolymerのデザインを適用しているからだ。

• 【参考】Polymer 1.0最新情報！ Polymer 1.0とPolymer Catalog、活用事例／Google I/O Web Appの作り方、Polymer Starter Kitで始めるMaterial Designほか

またデバイスごとのスクリーンサイズ、画角、dpiが一覧でき、それぞれのデバイスごとに適切なグリッドを表示したDevice Metrics Toolの提供を開始したり、icon Setの拡充も図っている。「Polymer1.0からはマテリアルデザインで使っているアイコンがすべてWebフォントで活用できるようになった。すでに750個ぐらいが、オープンソースで利用可能」と鈴木氏は説明する。

Google I/Oを体験してみたいという人は、Code labはすべて公開しているので、ぜひこのURLにアクセスしてよう。

鈴木氏がお勧めしたのは、「Web Animations Transitions and Playback Control」というCode lab。「これを使うとモバイルWeb、デスクトップでいい感じのアニメーションやトランジション、エフェクト作れる。ぜひ、楽しんでほしい。またCode labのサイトもフルPolymerで実装されている。ソースコードを見てどんなことをやっているか、参考にしてほしい」

Google Polymer1.0で何が変わるのか

次に登壇したのは、NTTコミュニケーションズの小松健作氏。セッションタイトルは『There’s an element for that!! Now, get ready for Polymer 1.0!!!』。登壇するまでにビール5本ぐらい飲んでしまったという小松氏。この日は昼にも同場所でセッションを行っていたため、そのおさらいから始まった。

PolymerはWebコンポーネンツを使いやすくするためのcustom tagやテンプレート、shadow dom、html importなどのライブラリ、さらにクロスブラウザでも使えるようpolyfillというライブラリを提供している。

では、Polymer1.0になり、どう変わったのか。それは「Production ready（実用的になった）であるということ」と小松氏はいう。例えばCodeが35パーセント削減されるという。この背景にあるのが、Shady DOMを見直したことである。またThemingでテーマの変更が容易にできるようにもなったという。そして0.5と1.0の互換はない。

「Angular.jsなどのフレームワークとPolymerの違いはどこかと聞かれることが多いが、Polymerはフレームワークとは違うポジションを取っている」と語る。それは次の図を見れば一目瞭然だ。

つまり、jQueryやReact、Angularなどのフレームワークと、元々ブラウザが持っているネイティブAPIの間を埋めるような役割を果たしているということ。

「Google I/Oのセッションの中で、たびたび出てきた言葉がある」と小松氏。それは「There’s an element for that」。これは「こういうものが欲しいということがあればすべてエレメントとして提供する」という意味。それがPolymer Catalogだ。そこではGoogleが提供しているサービスについても、Webコンポーネントとしてすでに提供。Polymerを使ってWebアプリケーションを作っていくためのテンプレートもスターターキットとして提供されている。

Polymer Catalog、Polymer Starter Kit、Shady DOMの使い方

「Google I/Oのセッショントークについては、今のおさらいがすべて。これからは次に挙げるトピックを説明する」と語り、本セッションの本題へ。まずは説明したのはPolymer Catalogの使い方について。先述したようにPolymer1.0になり、カテゴリー別にさまざまなWeb Componentsが提供されている。

実際に開発する際にこれらをどうやって使っていくか、Paper Elementsの「Paper-button」の適用方法について、デモを行った。

「まずはブラウザ左側にある『Add to Collection』をクリックします」と小松氏。次に右上に表示された「星型のボタン」をクリックし、ダウンロードボタンする。あとは「Bower Command」に表示されたコードをコピーして、HTMLインポートという形で適用していくだけだ。

Polymerをうまく使えるような仕組み（デザインテンプレートや開発ツール）が提供されているのが、Polymer Starter Kitである。Polymer Starter Kitのページにアクセスし、zipファイルをダウンロードすれば使えるようになる。

「どんなテンプレートがあるか」。小松氏がよく触りそうなモノとしてピックアップしたのが以下だ。

• index.html
  　● SPAのHTML
• styles/app-theme.html
  　● アプリのテーマデザインCSS
• scripts/app.js
  　● フロントHTMLのJS
• elements
  　● elements.html : importするPolymer element
  　● my-list / my-greeting : サンプルのカスタムpolymer
  　● routing.html : SPAのルーティング by page.js
  
• test/
  　● web components test

また、オフラインWebのときに使うのが、Service Workerである。これを使うと、非常に簡単にコードが書ける。

3つ目のトピックスはShady DOMについて。Shady DOMとはShadow DOMのPolyfillを実装でしたもの。これまでShadow DOMで独立したコンポーネントのDOMツリーを作るとなるとかなりつらく、モバイルでは遅いというのがネックだった。それを早くするため提供されたのがShady DOMである。

Shadow DOMとShady DOMの違いは次の通り。

「ただし、注意点がある」と小松氏。Shady DOMは普通のDOMとして展開されているので、Textnodeで以下のように書くと、中のDOMをすべて壊してしまうので動かなくなるので注意が必要だ。

最近の傾向として、ブラウザで提供されるAPIが提供するのはLow Level APIなので、使うのが難しいという問題がある、と小松氏は指摘する。例えば、オフラインキャッシュ。それを簡単に書く方法としてApplication Cacheがあったが、特定用途じゃないと使えなかった。ブラウザを作っている人はC、C++がメイン。高レベルインタフェースに何が必要かは、Web開発者でないとわからないからだ。

そこでブラウザでは低レベルAPIを用意し、Web開発者が実際に役立つ高レベルAPIを作ることで、Webの進化を促進していこうというのが最近の考え方であり、それがExtensible Webである。

例えば、先のオフラインキャッシュもService Workerを使って書くと次のように簡単に書ける。

つまり、オフラインキャッシュがカジュアルに使えるようになるということ。「今後もブラウザベンダはLow level APIを提供し、それを一般のWeb開発者に対して利用可能なものと知るために、High level APIとして知識のある企業が提供していく流れは続いていくだろう」と小松氏は語る。
「そして、その中核の役割を果たすのがWeb ComponentsやPolymerなのだ」

なぜモバイルWebがダメダメと言われるのか

3番目に登壇したのは、川田寛氏。セッションタイトルは『The next generation mobile web!』。冒頭「Google I/Oではあまりモバイルの話が出てこなかったと言われているが、次世代のモバイルの開発がどういう風にしていくかという話をしていく」と語り、セッションをスタート。

モバイルWebばっかりエンジニアの川田氏は、「モバイルWebがダメダメ過ぎて生きるのが辛い」と嘆きながらも、「モバイルWebで頑張りたい」と語る。

では、なぜモバイルWebがダメダメと言われるのか。その理由の第一はブックマークが役に立たないことだ。デスクトップPCの場合、個々のアプリの機能は大きく、1つで多くのユースケースをカバーしていた。ブラウザのブックマーク機能も仕組みは同じ。つまりPC上のアプリの扱われ方と相性が良いため、違和感がなかったというわけだ。

一方のモバイルはアプリがユースケースごとに分かれている。つまり一つのアプリが一つのユースケースになるというわけだ。ブラウザのブック機能はモバイルのアプリの使われ方と合わないのである。

第2の理由がブラウザは閉じられると何もできなくなるということ。例えばデスクトップPCだと使うときだけ起動しており、ブラウザも同じタイミングで使われていた。つまりPCとその上のアプリとはライフタイムがほぼ同じで、そこに乖離はなかった。

一方、モバイルは作業していない間も起動している。そのためアプリ側が新しい情報をユーザーに通知したいと思えばいつでも通知でき、その通知をきっかけにユーザーが作業を開始するという使われ方をする。しかしブラウザだとそうはいかない。「閉じられたら何もできない。モバイルの使われ方とは合わない」と川田氏は言う。

第3の理由はパフォーマンスの悪さ。モバイルは省エネが求められ、制限が多い。Webのオーバーヘッドは時に邪魔になるのだ。

Google I/O2015で見えたモバイルWebの可能性

このように駄目な理由が多いWebだが、「自由な世界で人々にサービスを提供していきたい」と力強く語る。Googleもその答えを探っているという。Google I/Oのセッション「The Next Generation Mobile Web」では、モバイルWebの可能性を示されたという。「そのセッションのトピックスを紹介する」と川田氏。

まずは次のような図を示した。モバイルに適したWebを作るために開発者が行うべきことは3つ（ステップ1～3）あるという。

ステップ1は「モバイルに適したUIで扱おう」。それがMobileUIだ。セッションでは「Add to homeScreen」と呼んでいたが、ホームスクリーンへランチャーアイコンを配置して、それをモバイル専用のUIで起動させるというもの。

またコードは次のようになる。

このように書くことで次にタップして開始するhtmlの場所を変えることができる。Webサイトを見ていたときはWebサイトに特化したサイト、モバイルのときはモバイルに特化したサイトを呼び出すこともできる。

ネイティブアプリっぽい見た目にするためにブラウザのUIをなくすこともできたり、ランドスケープを封印することもできる。

これによりWebだがネイティブアプリケーションに近いサービスが実現する。「詳しくは『Add to Homescreen』というサイトを見てほしい」とのこと。

ステップ2は「Webをモバイルに適したライフタイムで動かそう」というもの。「これからのプラットフォームは通知機能だ」という。通知機能はコンバージョンに影響を与える機能で、「Googleのチームは40パーセント影響があるといっているが、もっと影響があると思う」と川田氏は説明する。

ブラウザが閉じられてもバックグラウンドで待機させて、何か起きたときにユーザーへそれを通知する。これを実現するのが、Service Workersだ。

• Service Workers：バックグラウンドでイベントを受け付けて何かしらの処理を実行できるWeb標準。
• Push API:プッシュサービスからプッシュイベントを受け付けてメッセージを読み込めるWeb標準。
• Notifications API：モバイルの通知を実現するLiving Standard。Permission APIの仕様が固まるとWeb標準になるだろう。

イメージは次の通り。

Step3はモバイルパフォーマンスの話。「十分なパフォーマンスとはユーザーがそれを意識しないことである」とドン・ドレイバーの有名な言葉がある。ではそれをどうやって実現するため、ChromeのチームではモバイルWebを速くしようと戦っている。

では開発者が実践すべきことは何か。それはRAILと言うキーワードで表すことができる。RAILは以下の4つの略。この4つのパフォーマンスを改善すれば、ユーザーはストレスフリーになれるという。

• R:Reaction（一昔前はResponseと呼ばれていた）
• A:Animation
• I:Idle
• L:Load

Reactionはタップやスクロールしたときに10ミリ秒未満で終わらせようという考え方。Animationは16.67ミリ秒（60fps）未満で動かしてくださいということ。この改善方法については、CSS Animationsもしくは Web AnimationsをGPUで使うと「幸せになれる」と川田氏。Idleは50ミリ秒未満で応答しようというもの。中には「100ミリ秒と言う人という人もいる」。Load（読み込み）は100ミリ秒未満で。これは「無理ではないか」と思っているとのこと。

「もっと詳しいことを知りたい人は、gihyo.jpの連載をぜひ読んでほしい。モバイルWebの未来はダメダメじゃない。特にコンテンツ系はネイティブしなくてもよいのでは」こう会場の参加者に呼びかけ、セッションを終了した。

日本マイクロソフトが開催する開発者向けイベント「de:code」

最後に登壇したのは、日本マイクロソフトの物江修氏。セッションタイトルは『Windows 10のあたらしいWebブラウザについて』。

セッションは「de:code」の紹介から始まった。米Microsoftでは開発者のためのイベント「build」が開催されている。Windows8のリリースから開催され、今年で3回目。チケット代は2045ドルで20万円超える値段だったが、発売と同時に45分で売り切れてしまうほどの人気イベントだ。

一方の「de:code」は去年から始まった日本マイクロソフトのイベントである。「今年で2回目。去年は完全に開発者向けイベントとして開催したが、今年は開発者とIT技術者というかたちで集客した」と物江氏は説明する。「ブレークアウトセッションはまだ昨年のモノしか見られないが、Webで公開しているので見てほしい。来年は会場でお会いしましょう」と語り、「de:code」の紹介は終了。

Windows10が搭載する2つのブラウザIE11とEdge

続いて、本セッションのテーマであるWindows10の新しいWebブラウザの紹介へ。「このセッションの内容は時期Internet ExplorerのTechnical Preview時点での情報。仕様は固まっていないが、ほぼほぼこの形で出てくると思う」と物江氏は前置きし、紹介を続けた。

Windows10はWebブラウザが2つ搭載される。1つはInternet Explorer11（IE11）、もう一つはEdge。ではどういう違いがあるか。

IE11は、旧バージョンのIE向けに作られた企業内のWebシステムなどに、後方互換性を提供する目的で搭載される。基本的にはWindows 7や Windows 8.1と同じものだが、Media Capture APIなどの機能が若干だが追加されている。ActiveXを使う場合もIE11となる。

一方のEdgeは新規に開発されたWebブラウザ。「IEとはまったく違うブラウザとなった」と物江氏は語る。EdgeはIE固有の機能をすべて取り除いているという。Web標準に準拠しており、「他のブラウザとの相互互換性に注力した」と語り、会場の笑いを誘う場面も。

「EdgeはUniversal Windows Platformで作られているので、PC版と同じものがスマホでも動く」と物江氏。モバイル向けコンテンツもターゲットとしているため描画は Webkit、Blinkに準ずるように多大な投資を行った。そのためWebサーバーが、IEや、その他の想定外のブラウザ向けのコンテンツを返されると都合が悪い。それの問題を解消するため、EdgeのuserAgentは以下のようになっている。

• Mozilla/5.0（Windows　NT6.4;WOW64）
• AppleWebkit/537.36（KHTML,like Gecho）
• Chrome/36.0.1985.143 Safari/537.36 Edge/12.0

つまり「Edge対応どうしましょう？と言われたら、Chromeで動くようにすればOK」と物江氏はにっこり。

EdgeとIE11の違いはレンダリングエンジンが異なる。Edgeのレンダリングエンジンは、EdgeHTML.dllに対して、IE11はMSHTML.dll。Edgeは旧バージョンのIEとの互換性はなく、ActiveXやVBScript、Browser Helper Object（BHO）、Vector Markup Language（VML）、DirectX Filters and Transitionsなどは一切動かない。

一方、FlashやAcrobat（PDF）などはプラグインで動く。「Edge自身、アドビと一部一緒に開発を行っている。従って、AcrobatのアップデートはWindowsアップデートで行うようになる。つまりEdge自体がFlashプレイヤーであり、Acrobatリーダーになるというわけだ。さらにChrome、Firefoxのプラグインが動くようになる予定だという。

とにかく「相互運用性への意気込みは強い」と物江氏は強調する。相互運用性を遵守するので、正しく動かないのであれば仕様を変えるので連絡してほしいという。

話題はEdgeの新しい機能について。Edgeにはお絵かき機能や注釈機能が付く。そして画面をリーディングリストという形でローカルに保存できる。もちろん次に呼び出したとき、メモなどの内容は、オフラインでも見ることができる。共有を選ぶと、Facebookやメールで送ったりもできる。リーディングビューをクリックすると、タブレットで読みやすいように成型してくれる。

画面ショットを取りたい場合は、切り取りボタンを選んで取りたい場面を囲みクリックすれば取れる。

　　　▲CodeIQ MAGAZINEトップページの画面ショットを使ってお絵かき機能や注釈機能をデモ

新しいブラウザをいち早く使う方法についても物江氏は説明する。一つはWindows10 Technical Previewをダウンロードする。それができない場合はRemoteIEを利用するという方法だ。後者の場合はリモートデスクトップのエージェントさえあれば使用できるので、Mac、iOS、Androidからも使用可能だ。「iPhoneからも接続して試せる」と物江氏。

IE11の新しくサポートされる機能については、status.modern.ieで実装状況を公開している。一方、Edgeでサポートされている機能については、dev.modern.ie/platform/status/で確認できる。

ただし、これらの機能はプレビュー版ではそのままでは使えない。URLにabout:flagsと入力すると隠しメニューが出てくるので、無効になっているところをチェックして有効にすれば使えるようになる。

最後にEdgeの注意点について。Edgeではローカルホストでデバッグができないため、コマンドプロントにてコマンドを実行するという。

CheckNetIsolationLoopbackExempt-a -n=Microsoft.Windows.Spartan_cw5n1h2txyewy

これで接続できるようになる。将来的にはメニューで設定できるようになると書いてあるのだそうだ。

そのほかにも「この機能を正式に採用してほしい」という場合は、リクエスト（Vote）機能を有効に使ってほしいという。リクエストはMicrosoft Edge Deveroperから投票ができるようになっている。

もちろん、Microsoft Coneectでは現状のIEについてのフィードバックを受け付けている。「日本からのフィードバックが少ないとか言われているので、ぜひ皆さん、フィードバックやリクエスト送ってください」と呼びかけ、物江氏のセッションは終了した。

Google、マイクロソフトともに、よりモバイル（マルチデバイス）に対応すべく、Webテクノロジーの開発が進められている。今後の動向も引き続きレポートしていく予定なのでご期待ください。

今回の勉強会資料

• 第58回 HTML5とか勉強会 – HTML5最新情報@Google I/O, de:code 2015 イベント当日の動画および資料・イベント写真など

関連ページ

• Google I/O 2015レポートはこちらから
• de:code 2015レポートはこちらから

UIデザインを追求するコミュニティ「UI Crunch」。今回のテーマは、「スマートウォッチ」のUI開発や知見などについて。スマートウォッチ向けのアプリの開発は、スマートフォンのアプリの開発とどう違うのか。5人のクリエイターが、自身の開発体験などを踏まえて語り合った。

「自己帰属感」がこれからのUI設計には欠かせない

今回第5回となるUI Crunchが、東京・渋谷ヒカリエDeNA社内のサクラカフェにて開催。GoogleからAndroid Wear、アップルからApple Watchが発売されたことで注目が集まっている「スマートウォッチ」。まだまだ事業でこれらのウェラブル端末向けの開発を行っているところは少ないことから、同勉強会には多くの参加者が集った。

最初に登壇したのは、明治大学総合数理学部でメディアサイエンス学科の教員、渡邊恵太氏。渡邊氏は学生時代からヒューマンインターフェースについて研究をしてきた。
セッションタイトルは「身体性とインタラクションデザイン」。

2015年1月に発行された同氏の著書「融けるデザイン～ハード×ソフト×ネット時代の新たな設計書」は、iPhoneはなぜ気持ちよいのか、iPhoneのサクサク感の原因はなんなのだろうということをさまざまな研究を通して論じた本。その結果一つの答えが導き出されたという。

それは、iPhoneの気持ちよい使用感には自己帰属感が大いに関係しているということだ。

自己帰属感とは「この（手）は他人のではなく自分の（手）である」という感覚」のことである。例えばカーソルには自己帰属感があるのか。それを調べるために「マルチでダミーカーソル実験を行った」と渡邊氏は言う。偽物のカーソル（動いているモノ）を複数表示させて、自分のカーソルを見つけてもらうのである。50個のダミーカーソルを表示させても、5.4秒で発見できたというのだ。

つまり、カーソルに自己帰属感があるということである。では、iPhoneはどうか。iPhoneの場合、画面そのものの動きが指と連動する。「画面全体がカーソルであるとも言える。ここが自己帰属してくる状態だと考察した」と渡邊氏は説明を続ける。

そしてもう一つ自己帰属感にとって重要になるのが、指の動きと画面の動きが同期していること。「同期が高いと自分がやっている感が高く、気持ちよいと感じられる。同期度合いが減ると気持ち悪さが進む。乱れて自分の動きと同期しなくなると、他人として認識したり、さらに進むとアニメーションになってしまう。だからこそデザインに自己帰属感が必要になる」と渡邊氏は言い切る。

とはいえ、自己帰属感を考えてUI設計したからといって買う理由にはならない。しかし気持ち悪さが続くと、使い続けるのをやめる理由になるからだ。身に付けるウェラブルデバイスの場合は、「自分の身体の拡張となるようなUIの設計をしなければならない」と渡邊氏は指摘する。気づきのデザインとしての通知の機能はいいが、今後はいかに通知の仕方を体に近い形で表現していくかが課題だという。

例えば触覚をうまく使うもその一つだ。これはタプティックエンジンを使うことで可能になった。
「新しいコミュニケーションのあり方が考えられるはず。自己帰属感が新しい道具の設計軸になっていくと考えている。ぜひ、これを参考に新しいモノ作りを模索してほしいと思っています」

watchOS2、注目したい3つの新機能とは

2番目に登壇したのは、iOS専業のフリーランスエンジニア・堤修一氏。堤氏はこれまでさまざまな有名プロダクトの開発に携わってきた。

例えば電動車いす「WHILL」、ウェラブルトイ「Moff Band」、真鍋大度氏との共同プロジェクト「Music For the Deaf」（電気信号を送ることで聴覚障害者が踊れるようになるモノ）などはその一例。Watch関連では「WatchME」（動画を使ったメッセージングアプリ）、「よしだっち」（鷹の爪の吉田君を育成するアプリ）などの開発にも協力している。

「UI/UXに影響の大きいwatchOS2の新機能3つ」というセッションタイトルからも分かるとおり、今回の堤氏のセッションは、堤氏が着目したwatchOS2の3つの新機能について。watchOS2は、6月8日より米サンフランシスコで開催された開発者向けのカンファレンス「WWDC15」。そこで発表されたのがApple Watch用OSの新バージョン「watchOS2」だ。

前バージョンとの最大の違いは、「ネイティブ動作するアプリが作れるようになったこと」と堤氏は語る。以前のウォッチアプリは、iPhone側で処理を行い、その結果をウォッチ側に転送して描画していた。watchOS2からは、アプリの処理自体もウォッチ側で行われるようになった。「ネイティブ動作するアプリとはウォッチ側で処理されるアプリ」ということ。これに伴い多くの新機能も追加された。

watchOS2の新機能はまだデベロッパー向けのβ公開なので、堤氏の話も公開ドキュメントで書かれていることである。数ある新機能の内、堤氏がピックアップしたのはウォッチアプリのUI/UXに大きく影響する、以下の3つの新機能だ。

1.Complication（Clockkit）

ウォッチフェイスのためのモジュール。ClockkitはComplicationを作成・管理するためのフレームワークがwatchOS2で新たに追加されたことで、サードバーティもComplicationの作成が可能になった。これにより、アプリ起動不要、Glanceのようにスワイプも不要になる。ユーザーにとって最も利用ハードルが低く、Apple Watchの実用度向上が期待できる。

• 技術的な参考資料：WWDC15セッション209
  「Creating Complication with Clockkit」。堤氏はこちらでサンプル集を公開。

2.Watch Connectivity

ペアリングされたiPhoneとWatch間通信を行うためのフレームワーク。バックグラウンド送信や双方向メッセージングなどの機能を提供する。バックグラウンド送信とはコンテンツをバックグラウンドで送信できる機能で、3つのタイプがある。

• Application Context
• User info Transfer
• File Transfer

バックグラウンドで新しい情報を更新しておけるので、「ユーザビリティが向上する」というわけだ。Watch App起動時点でデータをPhone側と同期しておける。「Glanceにこの機能は合うと思う」と堤氏。

また双方向メッセージングが可能になることで、iPhoneとWatch間で相互にメッセージやデータを送れるようになる。これにより以前はできなかったiPhoneからWatchの制御が可能になる。ただメッセージ送信が可能なケースは決まっている。両者共にフォアグラウンドにあること、もしくはiOS側だけバックグラウンドある（Watch側はフォアグラウンドで起動している）ということだ。

3.センサーへのアクセス

watchOS2では次のセンサ・アクチュエータへのアクセスが可能になった。

• 加速度センサーの値
• 歩数情報（ウィッチだけ持って歩いても変化する）

※制約つきで利用可能なもの

• Taptic Engine（用意されている9種のタイプから選択できる）
• マイク／スピーカー（既成UIから利用可能）
• Bluetooth Headsetからのオーディオファイル再生
• 心拍数はHelthkitからデータ取得可能（※watchOS1の頃から可能）

これらが可能になることで、「アプリの企画の幅が広がるはず」と堤氏は期待を寄せていた。

アダプティブ・デザイン手法を用いたアプリ「KOLA」

3番目に登壇したのは、リクルートメディアテクノロジーラボの新谷和久氏。新谷氏はエンタメに特化したキュレーションアプリ「KOLA」のクリエイティブディレクター、UIデザイナーを務めている。セッションタイトルは「WatchAppから考えるアダプティブ・デザイン」。

KOLAとはネット中の情報（Twitter、Instagram、チケット情報）の中から良い情報を引っ張り出し、ユーザーにキュレーションするサービス。好きなモノだけに浸れる音楽体験を提供することに加え、アーティストのまとめやレコメンドをするなど、興味を広げるような設計にしている。「スマートフォン以外で移動中にKOLAに触れられる体験ができるよう、Watch用アプリの開発を手がけることになった」と新谷氏は開発の経緯を語る。

アダプティブ・デザインとは、Webデザインの形式の一つ。Webデザインにはレスポンシブデザインもあり、今はこちらが主流で語られるコトが多い。レスポンシブデザインは無段階で可変してどのデバイスでも均等に見られるようなデザイン手法。一方、アダプティブ・デザインは無段階ではないが、ある程度は決まったデザインで見せ、ある領域からは違う見せ方になる手法のことを一般的に指す。

だが、アダプティブ・デザインはデバイスにマッチさせることだけではなく、もう少し「広い意味がある」という。「ユーザーの文脈に応じて最適な情報を状況に適したデバイスでどう見せるかということだと思っている」と新谷氏は語る。

これまでスマートフォンのサービスの開発において新谷氏が疑問に思っていたのは、「個人も特定できて、時間も指定できて、端末の特性も違うのに出す情報が一緒なのはおかしい」ということ。ウェラブルでは、その疑問を解消することが当然求められるようになると考えているのだ。例えばGoogle Now。これは時間と場所とユーザーの嗜好に合わせて出る情報が違う。そして学習もする。

またApple Storeアプリ。これも店外と店内で起動するのでは、表示される情報が異なる。「こういうアプリの設計手法がアダプティブ・デザインだと思う」と新谷氏は説明する。KOLAはアダプティブ・デザインを採用して開発された。例えばContextのところでは「どこで」「いつの」情報を出すか。Contentsのところでは「どんな」コンテンツを「誰に」向けに加工して出すかを考えて設計した。KOLAが取り扱っている情報は動画と音楽とニュース、アーティストのイベント情報、SNSなど。スマートフォン向けにはこれらすべての情報を扱えるが、Watchの場合は個人に最適化にした情報に焦点を当てて扱えるようにした。

通知が来て開くと、新しい動画が見られるような形にするためにはどういう形が一番良いのか。iPhoneアプリのようにホームからコンテンツをたどっていく形は、Watchの形態から適していない。そこでヒューマンインターフェースガイドラインを参照し、「Glance」を使うことにしたという。Glanceを使うことがアダプティブ・デザインにフィットすると考えたからだ。

Glanceで表示される情報をクリックすると、アプリが立ち上がり、コンテンツの中身が読める。アーティストの情報を遡りたいというユーザーニーズにも対応。「ここまでWatchでできるようにしたことで、iPhoneの存在が少し小さくなった。これは面白い体験になった」という感想も。

Glanceは、情報がないときは出さなくてもいいので、KOLAではユーザーが登録しているアーティストの情報があれば出すが、ないときは今日の動画のランキングを見せるようにしているという。これにより「全体の興味を拡げるというところもGlanceで補っている」と新谷氏。

UIデザインについてはヒューマンインターフェースデザインガイドラインのホリスティックデザインという項目を参考にした。ホリスティックデザインとは、ハードとソフトの境目を意識させないようデザインするということ。

KOLAもこれを意識したUIにした。またHand Offの機能もお勧めだという。これは「Watchを対象にした機能だと思う」と新谷氏。Hand Offなしの場合だと再生画面を起動するのにロックを解除してホームからKOLAのアプリを選んでタップするというステップが必要だが、Hand Offに対応していると、その複数の手間をすることなく画面を立ち上げることができるからだ。

今回、Watch向けアプリの開発に挑戦してみて新谷氏は「iPhoneアプリをWatch向けにするのではなく、WatchからiPhoneのデザインを作っていくのがシンプルなのではということ思った」そう。つまりこれからは「ウェラブルファースト」がスタンダードになるではというのだ。

「今はブルーオーシャンなのでやりたい放題できる。デザイナーの人には挑戦してほしい。いろんなアプリが登場するのを楽しみにしている」

Android Ware向けウォッチフェイスアプリの開発

4番目に登壇したのは、GoodpatchのAndroid Developer、橋本泰氏。セッションタイトルは「Android Wear」。今回唯一のAndroidのウェラブルデバイスAndroid Wearについてのセッションとなった。まずはGoogle I/Oで発表された新機能について。大きく「always on」「wrist gestures」「emoji recognizer」「launcher」の4点になるという。

always on

例えばGoolemapをAndroid Wearで立ち上げると、アンビエント・モード（省電力モード）になっても、マップをモノクロで表示するということ。Google Keepというメモ帳などもアンビエント・モードで立ち上げられる。

wrist gestures

通知が来たときに、手首をスナップさせることで通知カードを表示、また手首をダウンさせることで通知カードを非表示にできる昨日。

emoji recognizer

これまでは音声でしか返信できなかったが、emoji recognizerでは絵文字で返信できるようになること。

launcher

Android5.0のlauncherは1画面だったが、5.1になったことで3画面になった。最初の画面はアプリのショートカット。真ん中が電話帳（自分が発信した履歴から出ている）。最後の画面は設定画面。「アプリケーションを初めの画面を持ってきたということは、Android Wear上でもアプリをバンバン使ってほしいという気持ちの表れなのかと思う」と橋本氏。

橋本氏が最初に開発したAndroid wearアプリは、2014年11月にリリースした「Moon Watch Face」。当時は「ウォッチフェイスの公式ドキュメントがなく、大変だった」と振り返る。例えば画面サイズに合わせてデザインを作るとずれる。通知カードがシグネチャーアプリケーションだと通知カードが大きくしかでない、充電アイコンやホットワードの位置変更ができない、RoundとSquareでの表示領域の調整が必要だったり、アンビエントモード（消費電力モード）で白黒になったときの考慮が必要だったのだそう。

12月にサードパーティ製のウォッチフェイスが公式サポートされ、Googleがサンプルアプリを出してきたことで作り直し。それを参考にしたことで、Moon Watch Face Ver2は1週間～10日で作れたという。これにより設定画面が明確化され、通知カード、充電アイコンやホットワードの位置変更が可能になった。

次に橋本氏が手がけたのは「COLOR WALK」。FIT API連携、WatchFaceをタップできるようにしているのがポイントのアプリだ。本来、GoogleはWatchFaceのタップは不可にしている。それを可能にするため、システムアラートウィンドウを生成し、強制的にタップを取ることを行っているという。moto360で中心点がずれることもわかった。というのは下のところに30ピクセル分のセンサーが付いているからだ。同アプリは「Google Fit developer Challenge」に応募し、金賞を受賞した。

続いて「SCANIMATION」をリリース。これはアンビエントモードからの5秒間を有効に使うことにこだわった、加速度センサーを使用したウォッチフェイスだ。moto360が1ピクセルしが表現できず、拡縮をすると歯車が廻らないので大変だったと語る。

また「レイアウト構成にも配慮した」と橋本氏。あくまでも時計なので文字盤が見えないと意味がないが歯車で遊んでほしいので、時計の位置などにも考慮が必要だったというわけだ。さらに加速度の精度が良いので、その速度調整も必要だったという。

これからのWearはどのように使われていくか。Google I/OでBrillo（IoTで使う小さなAndroid）についても語られたが、これからのWearはIoTを制御するモノとしても重要な役割を担っていきそうだ。Brilloを搭載しているエアコンと通信し、スイッチを入れたり切ったりするということも考えられる。まだリリースされてから1年弱。「Apple Watchとともに、これを使うことで生活が少し便利になることに貢献できればいいなと思う」と語り、セッションを終えた。

Apple Watch用アプリ「Dingbel」開発で学んだUI

最後に登壇したのはGoodpatchのUIデザイナー、笹山健志氏。「DingbelのWatch UIデザイン」というタイトルでセッションを行った。

「Dingbel」はDeNAが開発したApple Watch用のアプリ。Goodpatchが同開発プロジェクトに協力することになり笹山氏が参加した。初めからWatch専用、ウェラブルファーストなアプリを作り、他のアプリと差別化を図ろうと考えたという。そしてWatchの仕様に特化したUIを追究していくことを行った。DingbelはApple Watch発売と同時リリースして、狙い通りAppStore Featuredを獲得した。

Dingbelは「ハイコンテキストコミュニケーションツール」という名が付いており、送れるのはポジティブとネガティブ2種類のみ。そして送ってきた相手との距離がわかるというアプリだ。ポジティブなメッセージは緑、ネガティブなメッセージは赤で表示される。また同時に相手の距離も表示する。

当初、2種類のメッセージを送る方法として、送りたいユーザーの写真をタップしたときに2種類のボタンを表示させ、どちらか選んでタップして送信するというUIも考えたと笹山氏は言う。しかしそれだと即時性が保てないため、1タップでポジティブ、2タップでネガティブなメッセージを送信できるようにしている。

またApple Watchの限られた表示領域に対して、タップする領域を大きく確保することで識別しやすい、ウォッチを操作するときにでも相手を識別しやすく、押しやすい（画面のどこをタップしても大丈夫）ことにもこだわったという。

送る相手が複数いるときはユーザーの写真が縦に並んでスクロールする仕様にしているため、「タップ領域を大きくしたことで、誤送信するのでは」と不安を持つかもしれないが、そんな心配は不要だ。

Apple Watchは、デジタルクラウンでスクロールできるからだ。またWatch用のアプリとして機能もできるだけ絞った。ノーティフィケーションは、「誰から、どんな、いつ、どの辺からと言う必要な要素をファーストビューで一瞬に判断できるようにしている」と笹山氏は説明する。

もう一つDingbelでこだわったところがある。それは送受信画面のアニメーション。アニメーションを使ったのは「送った感の演出をするため」だという。しかしアニメーションには次の制約があった。一つはイメージシーケンスで実装すること。イメージシーケンスとは、画像を複数枚使って、パラパラ漫画のように切り替えて動いているようにみせることだ。もう一つがフレームレート5～8fpsしか出せないこと。

「これには頭を悩ませた」と笹山氏は振り返る。一般的なゲームのフレームノートは30～60fps。アニメ・映画で24fps。8fpsは1963年に放映されたアニメ「鉄腕アトム」と同等のレベルだったからだ。しかしその制約内でfps以上の滑らかさを表現するために採用した方法が、座標を移動させないこと。オブジェクトの座標を移動させてしまうと滑らかに動かそうとしても、ワープしているように見えるのだ。

移動させない方法の一つの答えとして点滅を使うこと。点滅を使えばフレームレートの荒さが気にならなくなるからだ。もう一つは脳内保管をさせること。「これが一番大事」と笹山氏。脳内保管とはフレームとフレームの間の存在しないフレームを人の頭の中で補ってもらうこと。そこでモーションブラーという効果を多用し、フレームとフレームの間のない部分をごまかしているという。このアニメーションの作成には、「After Effects」を使ったという。

これだけの苦労をして制作したアニメーションだったが、実機では60fpsで動いたという。ただ、使う画像が増えることでメモリの使用容量が増えたりアプリの容量に影響がでることを考慮し、5～8fpsが推奨としているのではないかとのこと。

今回のバージョンでは「ユーザーごとのスナップ」「pull to reflesh」「オートロード」「Custom Long Lookからの返信」「送受信サウンド」などは実装できなかった。中でも「Custom Long Lookからの返信」が実装できなかったことは「非常に残念」と笹山氏。しかしwatchOS2がリリースされたことで、実装できるものもある。「次の仕様でさらにウェラブルファーストなアプリに成長すると期待している」と語った。

スマートウォッチは今後、大画面になっていくか？

5つのセッション終了後、5人の登壇者に対する質疑応答時間が設けられた。例えばウォッチは今後、大画面になっていくかという質問には、「邪魔になるので、大画面にはならないのでは。ウォッチはスマートフォンの代わりではなく、別のデバイスとして成長していくのでは」（笹山氏）という回答が。

また歩きスマホが問題になっていることから、「ウォッチを見過ぎないような設計にしていくことも今後求められていくのでは」といった話題が展開された。

今後はよりウェラブルの方向に進んでいくのは間違いなさそうだ。まだブルーオーシャンなウェラブルアプリの開発。いち早く手がけてウェラブルファーストなアプリ作りのノウハウを身に付けてみてはいかがだろうか。

　▲UI Crunch名物のDeNA和波里翠さんによるグラフィックレコーディング作品

７月4日（土）九州では3回目2年ぶり鹿児島では初となるHTML5カンファレンスが「国立大学法人鹿児島大学 郡元キャンパス共通教育棟2号館1F」で開催されます。IoTをはじめどこにでもある当たり前の技術になり、徐々に浸透してきているHTML5ですが、実際にプロダクトとして利用するにはこれからという状況でもあります。また、「Extensible Web」という考え方や「WebAssembly」からもわかるように、まだまだ発展し続けている技術でもあります。そんな魅力的なHTML5に触れられ、聞け、近づけることができるカンファレンスです。

見どころ

HTML5というキーワードがだいぶ静かになりましたが、冷静に考えるとHTML5についてどのくらい知見がありますか？意外と知らないことが多いのではないかと思います、しかもまだ発展している。Microsoftの本気モードもMAXになりその動向がきになるところですし、Firefox OSがテレビに搭載されたり、Firefox OS採用の開発ボードOpen Web Boardが存在したりと。Google I/OでもPolymer 1.0が発表されるなどまだまだ目が話せない状況です。そういった15セッションの中からあえて4つセッションを上げろと難題を出されたら、次のものを涙ながらに注目のセッションとして選びたいと思います。

注目のセッション：

Windows 10 に搭載される Web ブラウザーについて
– 日本マイクロソフト株式会社 物江修 氏

“There’s an element for that!!” Now, get ready for Polymer 1.0!!!
– NTTコミュニケーションズ 小松健作 氏

Web Audio API、 Web MIDI API を使ったWebサウンドプログラミング
– ヤマハ株式会社 河合良哉 氏

Firefox エコシステム ー Mozilla が創る Web of Things 時代の技術とプラットフォーム
– Mozilla Japan 浅井智也 氏

セッション以外にも展示ルームがあり実体験としてHTML5に触れることもできます。体感できるHTML5をお楽しみください。詳しいご案内はHTML5カンファレンス鹿児島の特設サイトがありますので、そちらをご参考にしていただきたいと思います。

http://kagoshima.html5j.org/html5conference.2015/

歩き方

HTML5カンファレンス鹿児島ですがオープニング/クローズを含む全17セッションから成り立っています。デザイナーからWebエンジニア、エンタープライズ技術者まで幅広くターゲットにしたイベントですので聞くものを選ぶのも難しいところです。そんな皆様に筆者が当日の聴講すべきセミナーをプランニングしてみました。

トップエンジニア向け

トップエンジニアであるあなた。そうです、やはり最先端技術に触れておくべきところだと思います。html5j代表でもある吉川徹氏の「いまさら聞けないHTML5概要」でまずはHTML5に脳みそを浸し、Microsoft Edge、Polymer、Web MIDI、Forfox OSとエッジな話に舌鼓されてはいかがでしょうか？

1. ルームA: いまさら聞けないHTML5概要
2. ルームB: Windows 10 に搭載される Web ブラウザーについて
3. ルームA: “There’s an element for that!!” Now, get ready for Polymer 1.0!!!
4. ルームB: Web Audio API、 Web MIDI API を使ったWebサウンドプログラミング
5. ルームA: Firefox エコシステム ー Mozilla が創る Web of Things 時代の技術とプラットフォーム

エンタープライズ向け

エンタープライズに所属しているみなさんは実用的なシステムを作る上でこれから何をすべきかを考える必要があります。WoTやCordova、Polymerなどは技術として知っておくべきところだと考えます。外してはならないのがMicrosoft Edge。そうです、エンタープライズには欠かせないMicrosoft社のブラウザーのお話です。好き嫌い関係なく必須項目のひとつです。

1. ルームB: はじめてのWeb of Things
2. ルームB: Windows 10 に搭載される Web ブラウザーについて
3. ルームA: “There’s an element for that!!” Now, get ready for Polymer 1.0!!!
4. ルームA: Cordova開発者が知っておきたいレンダリングエンジンの話
5. ルームA: Firefox エコシステム ー Mozilla が創る Web of Things 時代の技術とプラットフォーム

デザイナー向け

デザイナーはHTML5の基本事項を再確認し、その後、トップデザイナー秋葉秀樹氏の「ぼっけもんデザイナーへの道」を聞くべきです。セッション案内でもありますが、「『ぼっけもん』とはチャレンジ精神に溢れ、勇気のある人の意味を持つ鹿児島弁です」ということですので、デザイナーとしての考え方を身につられるチャンスだと思います。その後WebRTCの実例や、今後デザイナーとしても必要になるだろう「音」に対するWebの取り組み、デザイン技術のイロハを聞かれてはどうかと思います。

1. ルームA: いまさら聞けないHTML5概要
2. ルームA: ぼっけもんデザイナーへの道
3. ルームC: Webと電話を繋げよう！Twilioを使った簡単アプリの作り方 & オンラインコミュニケーションを支えるHTML5
4. ルームB: Web Audio API、 Web MIDI API を使ったWebサウンドプログラミング
5. ルームB: 入門HTML5/CSS3

初心者向け

あまりHTML5はよくわからないという初心者には、HTML5の全容を確認し、HTML5の実例を聞くというのがおすすめです。きっとHTML5の魅力に触れることができるのではないかと考えます。

1. ルームA: いまさら聞けないHTML5概要
2. ルームC: 協働現場でのHTML5
3. ルームB: はじめてのWebRTC/ORTC
4. ルームC: ファブ時代のHTML5。IoTとWoT、あとロボット。
5. ルームC: Bootstrap超入門 & フロントエンドエンジニア1年生が語る『画面設計とCSS設計のポイント』

とは言っても、なかなか選ぶのが難しいのではないでしょうか。この原稿を書きつつ、これだけのセッションが並ぶと迷うのも当たり前ではないかと思っています。是非HTML5カンファレンス鹿児島のサイトを見ていただき、十分迷ってもらえたら幸いです。

開催日時・場所

• 開催日時：2015年7月4日（土）
• 開催場所：国立大学法人鹿児島大学 郡元キャンパス共通教育棟2号館1F
• 事前登録はこちらからどうぞ！
• 入場料：無料

本イベントは懇親会も用意されていて、参加費無料です。講師陣とコミュニケーションを取るチャンスでもありますのでご参加ください（噂ですが美味しい焼酎が無料で提供されるかもしれません）。それでは当日鹿児島でお会いしましょう！

こんにちは、編集長の白石です。

2015年5月20日、第57回 HTML5とか勉強会「UI/UX」に参加してきました！簡単で恐縮ですが、レポートとまとめをお届けします。

チームでつくるUIデザイン

最初のセッションは、Goodpatch社の小島芳樹さん、ひらいさだあきさんによる「チームでつくるUIデザイン」です。

彼らが日々の業務で実践している、UIデザインやプロトタイピングについてのTipsが紹介されました。

チームでつくるUIデザイン

マシュマロ・チャレンジで理解する、プロトタイピングの重要性

まずはマシュマロ・チャレンジというワークショップについて、TEDで動画が公開されているプレゼンテーションを引き合いに出しつつ、プロトタイピングの重要性を強調。マシュマロ・チャレンジとは、スパゲッティの乾麺をテープで組み合わせて上にマシュマロを置き高さを競う、という（ただそれだけの）チーム作業ですが、意外にも難しい。ここで興味深いのは、幼稚園児のチームが意外にも好成績を収めるとのこと。

なぜなら大人たちは、計画を立ててから最後にマシュマロを置こうとしがちなのにたいして、幼稚園児たちはいきなりマシュマロを上に置きたがり、失敗を繰り返すことで、結果的に良い結果を収めるとのことです。 つまり、プロトタイピングを繰り返すことで結果的に良いものができるということですね。

カスタマージャーニーマップを4コマ漫画で！

そして、よくあるカスタマージャーニーマップですが、作るのに苦労する割に、一旦作ったらあまり見られることもないままになってしまいがち。小島さんはそれを4コマ漫画にしているとのことで、確かに顧客に与える価値がものすごくわかりやすいと感じます。

UI Flows

また、37Signalsが提唱したUI Flowsという手法を使って、（画面遷移というより）UIの遷移を表すという手法を使っているそうです。画面はいきなり作らずにまずは言葉だけで整理するのが大事。

prottの紹介

最後に、Goodpatchさんが作成されているprottを引き合いに出しつつ、プロトタイピングをまずは行ってみることの重要性を協調していました。

0から始めるUXデザイン

次は、NTTコミュニケーションズ株式会社の金智之さんによる「0から始めるUXデザイン」というセッションでした。

この講演では、UXデザインそのものではなく、「0からUXデザインの組織を作る」ことについての様々な知見、体験談を紹介されていました。

0から始めるUXデザイン

金さんはNTTコミュニケーションズという大きな（そして固い）会社で、4年間にわたりUXデザインの重要性を説き、啓蒙や組織づくりに尽力されていたとのこと。おっとそういえば、このHTML5 Experts.jpの運営母体も、NTTコミュニケーションズでしたね！:-)

もともと金さんがUXデザインに取り組んだきっかけは、自分で考えたアイデアを実際のビジネスに落としていくにあたり、悶え苦しんだことだそうです。それを救ってくれたのが以下の二冊の書籍。ただし、「ペルソナ作って、それからどうするの？」のほうは絶版のようです。

年間20ほどのプロジェクトに関わりながら、社内にデザイナーという「新しい職種」を根付かせようと奮闘。 例えば、トランクにユーザビリティテストの機材を一式詰め込んで、ゲリラ的にテストを行って現実を担当者に突きつける…なんてこともされていたそうです。すごい。

そのかいあってか、今年「鶴の一声」によりUX向上が全社的な課題となり、大きく動き出したそうです。何事も、継続していくことで開ける道があるものですね。まとめは以下。大きな会社の組織を変えていくご苦労が忍ばれます…。

カヤックHTMLファイ部のUI・UX

イベントのトリを務めたのは、面白法人カヤック HTMLファイ部リーダーの藤澤伸さんです。

「カヤックHTMLファイ部のUI・UX」と題して、（Web業界では有名な）カヤックHTMLファイ部の現状と、彼らが特に手がけることの多い「ペライチサイト」に関するUI/UXについて紹介がありました。

カヤックHTMLファイ部のUI・UX (第57回 HTML5とか勉強会 / 2015.5.19)

カヤックHTMLファイ部はもともと、HTML5のブームに乗って設立されたチームですが、時代の流れとともに、Webに限らずネイティブ技術も使用するようになっているとのこと。結局、お客様のご要望をいかにして満たすかが重要であって、HTML5はその一手段でしかないということですね。

後半は「ペライチサイトのUI・UX」。UXというと、スマホアプリやWebサービスの文脈で語られることが多いですが、カヤックHTMLファイ部はランディングページ（ペライチ）を手がけることも多い。そういうページにおけるUI/UXでは、「どうやってボタンを押させるか」「どうやって印象に残すか」「どうやってシェアさせるか」など、「一度しか来ないユーザーを、どうやって捕まえるか」が重要です。

例えば「どうやってボタンを押させるか」という課題においては、とにかく目立つ「押したくなるボタン」を配置する。

「どうやって印象に残すか」という課題については、ユーザの滞在時間を伸ばすのが重要で、触って気持ちのよいインタラクションを各所に配置するのが重要。

このスライドで紹介されているページはもうアクセスできないそうですが、ソーシャルボタンや「トップに戻る」ボタンなど、様々なものがインタラクティブに動作するのが印象的でした。

「どうやってシェアさせるか」においては、話題になる体験を作ることが重要。こちらのスライドで紹介されている「NARUTO展」のページは、画面最下部の「トップへ戻る」ボタンを押すと、すごいことがおきます。

「ペライチサイトのUI/UXを考える」というトピックは、今まで深く考えたことがなかった点で、とても面白かったです。

プロトタイピング、組織づくり、ペライチサイトというバリエーション豊かな視点からUI/UXを考えるという、とてもおもしろい体験でした。今回登壇された方々に共通していたのは、なんだか「ぶっちゃけ」感が強かったこと。「それ言って大丈夫？」みたいな発言もちらほら…だからこそ面白かったのですが、レポートやスライドではお伝えしきれないのが残念。

ライブの雰囲気を少しでも味わいたい方は、こちらの動画からどうぞ！

ほか、雀巽さんのブログはとても詳しく、よくまとまっていらっしゃってオススメです。 第57回HTML5とか勉強会 －UI/UX特集－ に参加しました！

ひろみつさんのグラフィックレコーディング結果も載せときますね。

今日がんばって手持ちのノートとペンでなんちゃってグラレコをしてみたんだけど、筋肉なさすぎて難しかった…!!! #html5j

@hiromitsuuuuuが投稿した写真 – 2015 5月 19 9:18午前 PDT

3月14日に特定非営利活動法人Web Directors Forum（以下、WDF）とHTML5 Experts.jpの共催企画として、WDF Vol.17 with HTML5 Experts.jp「アクセシビリティとUX」が金沢にて開催されました。この記事では、その勉強会のセッションの模様をレポートします。

ユーザーの期待に応えるクックパッドのUI/UXー元山 和之

イベント最後のセッションは、クックパッドでデザイナーをされている元山和之さんです。今回のセッションでは、クックパッドが実践するユーザーファーストなサービス開発の様子を紹介していただきました。

余談ですが、クックパッドさんのプレゼンテーション資料、さすが美味しそうですね。

まずは自己紹介

元山さんは、クックパッドのユーザファースト推進室というところに所属するデザイナーで、クックパッドのiOS/Androidアプリのデザインなどを手掛けているということです。

今日話すこと

サービス開発では、仮説検証のPDCAサイクルを繰り返して回すことが重要です。最近、アジャイル開発やリーンスタートアップ、デザインスプリントなど、様々な手法が出てきています。これらはそのPDCAを上手く回すためのツールでしかありません。クックパッドでは、ユーザーファーストという考え方を大事にしながら、仮説検証のPDCAサイクルを回しています。今日は、ユーザーファーストに関するクックパッドの取り組みとサービス開発における仮説検証の進め方の一部を紹介します。

ユーザーファーストであるために

クックパッドには「毎日の料理を楽しみにする」という理念があり、それを実現するために、レシピ情報を提供しています。

また、クックパッドは生活インフラを目指してサービス領域などを拡大しています。そのため、食だけにとどまらない、生活全体の課題解決に繋がるサービスの提供や、情報発信にもチャレンジしています。

ユーザファースト推進室

そんな生活インフラである各種サービスを開発する際に、全社的にユーザーファーストを考えてものづくりを行うということを推進しています。そのために存在するのが、「ユーザファースト推進室」という部署です。ユーザファースト推進室では、開発するサービスがユーザーファーストになるためには、どうすればいいのか？を常に考えて、様々な啓蒙活動を行っています。

ユーザファースト推進室は、もとは、デザイン部という部署でした。デザイン部からユーザファースト推進室になるにあたって、部署が目指すもの、目標が右図の通りに見直されました。ユーザファースト推進室では、ユーザー体験を向上させることが最重要課題なのです。

尚、デザイン部時代の送客数という定量的な目標に比べ、定性的に見えるかもしれませんが、ユーザー体験が向上したかどうかを数値で確認できるように工夫し、数値目標も意識しています。

ユーザファースト推進室の役割

では、具体的な役割について見ていきます。

1. 各事業部のデザイン作業

社内のデザイナーはほぼすべてユーザファースト推進室に集約されました。よって、デザイナーがいない部署もあるため、ユーザファースト推進室所属のデザイナーが、各事業部のデザイン作業を担当します。

2. ユーザー体験の向上のための新規開発・改善

これが、いわゆる本業です。エンジニアとデザイナーが協力して各サービスについて、新規機能を提案したり、継続的な改善を行ったりします。

3. デザイン開発環境の整備、社内デザイン思考の啓蒙

クックパッド社内はデザイナーの人数が少ないので、デザイナーがいなくても、各事業部の業務がある程度回るように、インフラとして様々なモノを整備しています。ここでは、2つの例をご紹介します。

Ⅰ. Github Design Review

GitHubのプルリクエスト機能を利用して、GitHub上でデザイナーとのレビュー・改善を繰り返す営みを定着させています。変更前後のデザインを比較できるように掲載し、細かな調整などはこのプルリクエスト上で行っていきます。

Ⅱ. UIデザインフレームワーク「Sara」

クックパッドらしいUIデザインができる、UIフレームワーク「Sara」を社内向けに制作し提供しています。フレームワーク内では、カラーコードに統一感をもたせ、変数定義することで、様々なサービスに利用できるような工夫がなされています。また、ボタンなどのUIパーツの共通化や、スマホ向けUIコンポーネント、Cookpad Symbols（ベクターのシンボルフォント）なども提供しています。それ以外にも、必要に応じてWebフォントの制作も行うことがあります。右下の図は、特売情報というサービスで利用するために作成した、「チラシっぽいWebフォント」の例です。

カラー変数の利用

スマホ向けUIコンポーネント

Cookpad Symbols

チラシっぽいWebフォント

4. ユーザーテスト、インタビュー

ユーザファースト推進室の重要なミッションの１つに、ユーザーテスト・インタビューがあります。ユーザーインタビューする際は、料理のことはもちろんですが、それ以外のこと、生活全体のことをインタビューするようにしています。そうすることで、以外な問題点を発見することができます。インタビュー結果はタイプ別にマッピングし、サービス開発に活用します。

5. クックパッドファンを増やす

最後に、これも重要なミッションです。

サービス開発における仮説検証のススメ方

次に、仮説検証のススメ方についてお話します。まず、仮説検証はなぜ必要なのでしょうか？

クックパッドでは、仮説検証のサイクルを「できるだけ、多く・早く・何回も」回すようにしています。それは、リリース前にできるだけ失敗の回数を増やすことが、精度を高め、良いサービスに繋がると考えているからです。次から、その具体的な手法を見ていきます。

仮説を立てるー価値仮説

仮説をたてるためのフレームワークとして、クックパッドでは「価値仮説」というやり方を取り入れています。開発するサービスがユーザーにとって本当に価値あるものかどうかを検証するために、まずは価値があるとする仮設を立てます。

アプリケーション定義ステートメント

次に、開発メンバの意識合わせを行うために、アプリケーション定義ステートメントを作成します。このステートメントもGitHubのIssueでレビューを重ねながらブラッシュアップしていきます。それによって、開発メンバの意識があい、全体の方向性がブレずにサービス開発を進めることができます。また、重要な事ですが、「実現すること」だけではなく、「諦めること」こともきちんと定義されています。

シナリオライティング

ユーザーがそのサービスをどういう時に使うのか、物語としてシナリオを複数パターン書き出します。「やりたいこと」とそれに対する「アクション」がセットになっていることがポイントです。

シナリオライティングのメリットには以下の様なことが有ります。

• こういう時にこういう機能が必要で、どのような優先順位なのかが分かる
• こういうシチュエーションだと、こういう機能が必要だというのが分かる
• 検証のためのユーザーテストにも使える

プロトタイピング

仮設を立て、アプリケーション定義、ユーザーシナリオを作った後は、関係者で思考を共有するために、プロトタイピングを行いながら機能やデザインを思考します。プロトタイピングはアウトプットを重ねながらブラッシュアップしていきます。プロトタイピングの流れを紹介します。

1. スケッチ＆ペーパーモック

まずは、書いてすぐに消せるホワイトボードを利用して、ペーパーモックをスケッチします。スケッチにはある程度の太さのマーカーを利用し、細かいところは書かない、ざっくりと書くことを意識して行います。細かいところを書くと変なところにこだわりが出たりして、プロトタイピングになりません。

2. 画面遷移図

次は、ペーパーモックを画面遷移図に落とし込みます。画面遷移を書くことで、コア機能などがちゃんと使ってもらえるところにあるかどうかを確かめることができます。細かくやり過ぎないように注意が必要です。

3. 動作モック

画面遷移図ができたら、次はツールを使って、ペーパーモックをそのまま取り込んだ動作モックを作っていきます。利用するツールとしては、モバイルアプリ系であれば、flintoや、prottがオススメです。Webサイトにも対応する必要がある場合は、inVisuion等があります。これらのツールでは、作成したペーパーモックをそのまま取り込んで、実際に動かすことができます。触って確かめることができるため、利用者のイメージをかき立てることが可能です。

これらのツールをクックパッドでは、ユーザーとのコミュニケーション手段として使ったり、デザイナーじゃないひとがデザイナーに作ってもらいたいものを伝えるため等、コミュニケーションを円滑にするためにも活用しています。

4. インタラクションモック

スマホアプリなどでは、インタラクションモックと呼ばれる、画面のアニメーションなどを再現するためのモックを作成することも有ります。Webであれば、HTMLなどを書いて作ることをイメージすると思いますが、Kyenoteを利用して簡単に作ることもできます。

仮説検証

作成したプロトタイプを基に、本当に良いものかを検証します。検証するためには、仮説を検証するための指標を作成する必要があります。まず、クックパッドで指標を立てる際の2つの例を紹介します。

指標を立てる（例１）

ユーザファースト推進室の事業部としての目標は、「ユーザーファーストなサービス、ユーザーファーストな文化を作るための活動を行うこと」です。この目標が達成できたかを評価するためには、携わったサービスが「ユーザーファーストなサービスになっているか」を評価する必要があります。そのための指標を以下のロジックで導きます。

「何度も使ってくれるユーザーが増えれば、それはユーザーファーストになっているってことじゃないかな」
　　　↓
　「そんなファンユーザーを増やせればいいね」
　　　↓
　「ファンユーザーが増えれば、クックパッド指名使いのユーザー数に影響するよね」
　　　↓
　「『クックパッド』で検索してきたUU（ユニークユーザ数） クックパッドアプリのUUを見れば影響が分かるね」

この場合、最後のUUが評価指標となります。

指標を立てる（例２）

クックパッドアプリが解決したい一番の課題は「今晩何作ろうの問題」です。この課題を解決できているかを測るための指標として、レシピ決定に貢献できているかを評価する「レシピ決定率」という指標を導入しています。レシピ決定率は「レシピを保存した」、「1分以上レシピを見ている」、「シェアした」、「プリントアウトした」といったユーザーの行動から算出します。

実際に検証する

指標を立てたら実際に検証します。検証は、社内ユーザーや一般ユーザーに対して、インタビュー、ユーザーテスト、ユーザービリティテストを組み合わせながら行います。検証にはツールを活用します。

例えば、上記例では、「GoogleAnalutics」と社内製ログ集計ツール「hakari」、アクセス解析ツールの一種である「Mixpanel」を用いて実際のログを解析します。Mixpanelはシナリオベースに実際の数値を検証できるツールです。

この検証結果は、また、次の仮説検証に反映され、新しいPDCAサイクルが回ります。

終わりに

本記事まで3回に渡りお送りしてきた、WDF Vol.17 with HTML5 Experts.jp「アクセシビリティとUX」のイベントレポートですが、いかがだったでしょうか？とても面白く、ためになるものばかりでした。

左から、元山さん、村岡さん、木達さん

登壇された、木達さん、村岡さん、元山さん、そしてイベントを主催いただいたWDFのスタッフの皆さん、お疲れ様でした！

3月14日に特定非営利活動法人Web Directors Forum（以下、WDF）とHTML5 Experts.jpの共催企画として、WDF Vol.17 with HTML5 Experts.jp「アクセシビリティとUX」が金沢にて開催されました。この記事では、その勉強会のセッションの模様をレポートします。

アクセシビリティについて最近考えていることをざっくばらんに話すよー村岡 正和

イベント2つ目のセッションはエキスパートの村岡 正和さんです。村岡さんといえばIoTという方も多いと思います。HTML5 Experts.jpでも記事を執筆されています。

今回のセッションでは、タイトルの通りアクセシビリティについて考えていることをざっくばらんに語っていただきました。そのセッションの模様を紹介します！

まずは自己紹介

村岡さんのセッションはまずスライド10ページ分の自己紹介からスタート（笑）。本業としては神戸を拠点に、Webアプリケーション開発、IT業務システムの設計/開発、Webサービス導入/事業戦略コンサルティングなどをされているそうです。

それ以外にも…

薄い本の執筆

FirefoxOSの薄い本を執筆しているそうです。興味あれば。（あ、表紙に騙されちゃダメですよ、中身は文字ばっかりだとか）

本の監修

書籍「Webアクセシビリティ事例集」

html5jマークアップ部＆Markup Cafeを主催

また、村岡さんは、コミュニティ活動として、html5jマークアップ部を主催しており、マークアップ部の活動の一環として、Markup Cafeという参加型イベントを全国各地開催しています。Markup Cafeは予め与えられたお題に対して、どのようなマークアップが考えられるかをチームで考えるというものです。例えば、ページネーションをどうマークアップするか…（考え出したら1時間じゃ足りないらしいですよ）

最初のセッションで登壇された木達さんもMarkup Cafeには注目しており、インスパイヤされて社内マークアップ部を立ちあげられたとか。Markup Cafeに興味関心がある方は、イベントレポートが掲載されているので、ぜひご覧ください。

ということで、本題に入ります。

OnePageスクロールサイトのalt属性で喜ばれた件

はじめは、Webアクセシビリティへ対応でお客様に喜ばれた事例の紹介です。お客様は知財務株式会社様（情報コンサルティング業）です。

知財務株式会社様Webサイト（http://www.chizaim.com/）

このサイトにはOne Page ScrollというjQuery Pluginが利用されています。ワンページスクロールのサイトは、キャッチコピーや画像だけを印象に残るように配置したデザインが多いのですが、今回のサイトの場合、それだけでは、なんとなくテキストが不足していて視覚以外の閲覧で情報が不足するのではないかと感じていました。

そこで、情報不足を画像のalt属性に説明文を付け足すことで補ってみました。

この件について、後日お客様から「情報を扱う会社だからアクセシビリティに配慮しているというのは、お客様に対して良い話題になる」とお礼の言葉をいただきました。WCAG2.0では、alt属性の指定はimg 要素の alt 属性を用いるがあります。この実装例は印象、雰囲気のみを伝えるような画像には必要ないと解釈することもできますが、今回のように画像の説明があったほうが、好感度があがるケースもあります。アクセシビリティ対応を行うことで、ビジネス的メリットが発生する可能性を感じた良い事例です。

モバイルフレンドリーなサイトである必要性

次はGoogleの検索アルゴリズム変更についてです。アクセシビリティという観点で最近、こんなニュースが話題になっています。

http://internet.watch.impress.co.jp/docs/news/20150227_690424.html

このアルゴリズム変更により、ウェブサイトのモバイル対応度が、検索結果の表示順決定により大きく影響するようになります。マルチデバイスへの対応において、レスポンシブデザインフレームワークなどを利用したマークアップは自然とアクセシブルなマークアップになるケースがあります。このような点を含めて、Webアクセシビリティとモバイル対応の関係を注目しておくべきではないでしょうか。

Webフォントとアクセシビリティ

次は、Webフォントについてです。最近のWebサイトでは文字の表現の幅を広げる手段として、画像文字の代わりにWebフォントがよく利用されるようになりました。先ほどのalt属性の設定でもし悩むようなことがあれば、画像は極力排除してWebフォントを利用するのもオススメです。例えば、この画像にどうやってalt属性を当てますか？

1枚の画像としてではなく、Webフォントを活用して表現することでalt属性の心配はなくなりそうですね。とても、納得のいく事例でした。例えば、写真上の値段や写真下の説明書きをテキストにし、Webフォントで装飾すれば画像文字に比べてアクセシブルになります。さらに写真の料理の説明をalt属性で記述すれば、よりページの情報量が多くなりますね。

また、Webフォントはベクター画像なので、以下のように拡大しても綺麗に見えます。

日本語のWebフォントを利用する際は、料金的なコストが発生するなどトレードオフが必要になることも有りますが、使えるならば使ったほうが、Webサイトがよりアクセシブルになります。

Webアクセシビリティは習うより慣れろ！

次は、Webアクセシビリティに関するスキルをどう身に付けるかという話です。「Webアクセシビリティ技術は全てのWebクリエイターにとって必須の技術」と言っても過言ではありません。では、どうやって勉強したらいいのでしょうか？

必要な資料は全てWebで公開されている

• WCAG2.0実装方法集（http://waic.jp/docs/WCAG-TECHS/Overview.html）
• JIS X 8341-3:2010 解説(http://waic.jp/docs/jis2010/understanding.html)

無料ツールも結構ある

• Accessibility Developer Tools – Chrome Extension
• Webアクセシビリティ簡易チェックシートと検証ツール（村岡さんお手製）

事例集もある（再掲）

• Webアクセシビリティ事例集【2012年度版】

テストも出来る

• JIS X 8341-3: 2010 テストファイル 等級A

このように、その気になればWebで全部学習できるようになっています。しかし、ただ学習するだけじゃ意味がありません。中途半端な知識でも構いません、アクセシブルな実装は習うより慣れろ、が鉄則です。実際に作らないとアクセシブルなページを制作する技術が身に付きません。

また、実際の制作物のWebアクセシビリティ対応方法が、テストケースと完全一致するケースは稀です。過去の事例が使えない場合、達成基準やアクセシビリティの基本理論をもとに、自分で実装の妥当性をしっかりと検討し、根拠を持つ必要があります。

知識だけだとWebアクセシビリティの本質を曲解しやすく、ユーザの利便性を考慮していない頭でっかちな実装になり、結果的にお客様に迷惑をかけることになるので、気をつけて下さい。

ウェアラブルデバイスとアクセシビリティ

次は話題を変えて、ウェアラブルデバイスについてです。今年になって様々なウェアラブルデバイスが登場してきています。これらウェアラブルデバイスがWebに与えるインパクトはかなり大きいと考えています。

Myoというデバイスはご存じですか？このデバイスは、腕の動きを感知し、動きに合わせて様々なモノを操作できるジェスチャーコントローラーです。

Myo – https://www.thalmic.com/en/myo/

これらのデバイスは、ウェアラブルデバイスが一般常識化した頃には、Webページに対して入出力を行う新しいインターフェースとなっている可能性が考えられます。これからは、Webアクセシビリティは、マウス・キーボードに加えてこのような新しい入力デバイスへの配慮が必要になるかもしれません。

また、逆に、ウェアラブルデバイス上でWebサイトが動作するようになった場合は、どのようなWebアクセシビリティが適しているのか、ということも考えていかなければなりません。例えば、スマートグラス上で表示するのに適したWebデザインってどんなデザイン？というように。

ウェアラブルデバイスを軸にしたWebアクセシビリティの議論はこれからますます活発になります。私も参加している日本ウェアラブルデバイスユーザー会の中で、そのうちアクセシビリティWGを作りたいと考えています。

IoT/WoTとアクセシビリティ

最後は、IoT/WoTとアクセシビリティについてです。昨今様々なデバイスが登場しています。そして、それらはWeb技術を利用してWebを介してつながることができます。個人的には、IoTという言葉は抽象的すぎるため、WoTに注目しています。

デバイスがWebでつながる？と疑問に思われた方は、まずは、村岡さんの記事をご覧ください。

イベント当日は、WeIOというデバイスを例に取り上げられました。

WEIO – http://event.shoeisha.jp/eva/20150511

このデバイスは、例えば、以下のようにHTMLとJavaScriptでプログラムが書けてしまいます。

<!DOCTYPE html>
<html lang="en">

<head >
    <!-- import weioLibs and link css style -->
    <script data-main="www/libs/weioLibs" src="www/libs/require.js"></script>
    <link rel="stylesheet" type="text/css" href="myStyle.css">

    <script>

        // This fucntions is called when DOM is loaded and web socket opened
        function onWeioReady() {
            hertzs();
        }

        // init variable hertz
        var hertz = 0;

        function hertzs() {
            // update displayed phrase with variable hertz
            $("#phrase").html("FREQUENCY FOR TONE FUNCTION = "+ hertz);
            // get tone with "hertz" frequency on pin 23
            tone(23, hertz);
            // increment hertz variable
            hertz = hertz+50;
            // Reset hertz variable at 18000
            if(hertz > 18000){
                hertz=0;
            }
        }

    </script>

</head>

<body>
    <p id="phrase" onclick="hertzs()"></p>
</body>

</html>

これからはHTML5でハードウェア開発が可能になるため、つまり、開発されたデバイスもWebアクセシビリティに配慮する必要が出てくる可能性があります。この分野はまだ出てきたばかりなので、現行のWAI-ARIAで対応できないことが出てくるのか？そもそもWebページとの相互運用性を確保する必要があるのか？など、まだまだわからないことが多いのは事実です。

次回予告

次回のレポートでは、元山和之さんのセッション「ユーザーの期待に応えるクックパッドのUI/UX」をレポートします。お楽しみに！

3月14日に特定非営利活動法人Web Directors Forum（以下、WDF）とHTML5 Experts.jpの共催企画として、WDF Vol.17 with HTML5 Experts.jp「アクセシビリティとUX」が金沢にて開催されました。この記事では、その勉強会のセッションの模様をレポートします。

これからのWebデザインに求められるアクセシビリティとの向き合い方ー木達一仁

最初は、株式会社ミツエーリンクスのCTOでありエキスパートの一人でもある、木達一仁さんによるセッションです。木達さんはWebアクセシビリティに関して、様々な取り組みをされている方です。別の企画でもロング・インタビューしているので、合わせてご覧ください！

今回のセッションでは、Webアクセシビリティの初心者向けに、そもそも「Webアクセシビリティって何？」というところから、Web制作者は今後どのようにWebアクセシビリティに向き合えばよいかを、丁寧に解説してもらいました。そのセッションの模様を書き起こしていきます。

Webアクセシビリティとは何か？

「アクセシビリティについて語るには、まずその定義、前提をシェアすべき」という語りかけから、セッションは始まりました。そもそもWebアクセシビリティとは何なのでしょうか？その答えをアクセシビリティの定義、ユーザビリティとの違いという2つの観点から解説されました。

アクセシビリティの定義

アクセシビリティという言葉は「アクセス」と「アビリティ」から成ると捉えることができ、対象にどれだけアクセスできるかの度合いを示します。Webアクセシビリティとは、さまざまにあるアクセシビリティの一分野という位置付けになります。

アクセシビリティとユーザビリティの違い

アクセシビリティに似た言葉にユーザビリティがありますが、あえて両者の違いを強調して表現するならば、次のようになります。

• アクセシビリティ　→　すべての人々にとっての利用できるかどうかの度合い
• ユーザビリティ　→　特定の人々にとっての利用しやすさの度合い

しかし、ユーザビリティが低すぎる課題は、アクセシビリティ上の課題として扱うこともでき、両者を明確に分けることは困難です。アクセシビリティはユーザビリティにとっての土台、前提のようなものと捉えることができ、ユーザブルである前にまずアクセシブルであるべき、と言えます。

これまでのWebアクセシビリティの捉えられ方

障害者・高齢者のためだけの対応？

WebアクセシビリティのJIS規格の名称に「高齢者・障害者等配慮設計指針」とあることからも、Webアクセシビリティと言えば、障害者や高齢者のための対として捉えられがちでした。確かにそのような側面はありますが、障害者・高齢者のためだけに必要なわけではありません。例えば、後述するWebアクセシビリティのガイドラインのWCAG2.0（日本語訳）に、ブロック・スキップという項目があります。これは、Webページ中のメインコンテンツより前にあるブロックをスキップできるメカニズムを指し、視覚障害者が音声でコンテンツを利用する場合に有用ですが、視覚障害者でなくとも、キーボードでコンテンツをユーザーにも有用です。

オプション扱い？

Webデザインという業務の見積もりにおいて、アクセシビリティ対応がオプション扱いにされてしまう場合がありました。オプション扱いでは、価格交渉（値引き）の材料にされてしまう可能性があり、結果的にアクセシビリティ対応の優先度が下がってしまいかねません。もしも、先に述べた「Webアクセシビリティは障害者・高齢者のため」という意識がWebデザインの発注者側にあったなら、なおさらです。アクセシビリティの確保は、Webのデザインプロセスと本質的に不可分であって、オプション扱いにすべきではありません。

デザイン上の制約？

Webアクセシビリティを確保することが、デザイン上の制約でしかないなどと考えている制作者がいます。しかし、あらゆるデザイン行為に制約なり条件は付きものであって、アクセシビリティを確保することで殊更にデザイン上の自由が奪われると考えるのは、バランスを欠いていると思います。そもそも、Webの閲覧環境はハードウェア、ソフトウェアともに多様化しており、あらゆるスクリーンにおいて制作者の意図した通りコンテンツを表示させることなど不可能です。それでもなお、コンテンツにある情報の伝達や機能の利用を担保できるのがWebの利点であり、アクセシビリティを確保すべき理由でもあります。Webデザインにおいては、その種の変幻自在さは制約であると同時に、大きなメリットでもあるでしょう。

アクセシビリティ＝品質

私は、アクセシビリティをWebに欠かせぬ「品質」であると考えています。そして品質であれば、それを測る基準なり一定の標準が必要になります。その一つが、Webアクセシビリティの国際規格としてW3Cより2008年12月に勧告されたWCAG 2.0（2012年にはISO/IEC 400500として標準化）であり、そのなかで4つの原則と12のガイドラインが定められ、都合61の達成基準や3つの達成等級（A/AA/AAA）が定められています。国内の規格としては、JIS X 8341-3という規格が2004年に公示されていましたが、WCAG 2.0と整合する形で2010年に改定されました（2010年版を「JIS X 8341-3:2010」と書き表します）。ちなみに、今年2015年にも改定の予定があり、現在それに向けた作業が進行中です。

Webアクセシビリティ確保の現状

次に、Webアクセシビリティの確保が昨今、どれだけ取り組まれているのか見てみましょう。総務省は「みんなの公共サイト運用モデル改訂版（2010年度）」という、公的機関のWebサイト向けにアクセシビリティ確保の具体的な手順をまとめたドキュメントを公開しています。その中には、以下のような目標や目標を達成する期限の目安が示されています。

• 既存サイト
  • 2014年度末までに JISX8341-3:2010の等級AAに準拠すること（試験結果公開）
• 新規構築サイト
  • 構築前に「ウェブアクセシビリティ方針」策定
  • 構築時にJISX8341-3:2010の等級AA（試験結果公開）

取り組みはまだ道半ば

Webアクセシビリティの確保・向上を図るべく発足したウェブアクセシビリティ基盤委員会（WAIC）では、ウェブアクセシビリティ方針の策定と試験結果の表示について、定期的に実態調査を行なっています。

公的機関におけるウェブアクセシビリティ方針の策定と試験結果表示の実態調査結果（2014年11月）

上記は主要な公的機関に対象を限定した調査の結果ですが、取り組みはまだ道半ばであることが窺えます。WAICは、一般企業に対しても同様に調査を行っており、結果は以下の通りです。

一般企業におけるウェブアクセシビリティ方針の策定と試験結果表示の実態調査結果（2014年8月）

一般企業においても、その取り組みはまだ本格化していないようです。今なおWebアクセシビリティ確保の取り組みが盛んではないように見受けられる背景として、以下のような要因が考えられます。

• Webデザインの発注側の意識がアクセシビリティに向いていない
  • 意思決定層に対する啓発や教育が足りない
  • WebアクセシビリティのROI（投資対効果）が計測しにくい
• Webアクセシビリティの確保が盛んな海外と異なり、日本では法制化されていない
• 受注側であるWeb制作者に向けた、アクセシビリティ関連の情報共有の場や学習機会が少ない

こと法制化に関連して、最近注目すべき動きがあります。アメリカの法律であるAir Carrer Access Act（ACAA）が、日本の航空会社にも影響を及ぼし始めているのです。そのような状況は今のところ航空業界だけのようですが、今後のグローバルビジネスの進展に伴い、他の業界においても同様の状況が生まれないとも限りません。そうなればますます、国際競争力という文脈においてWebサイトのアクセシビリティを重視せざるを得なくなるでしょう。

また日本でも、国連の障害者権利条約に批准したことに端を発し、障害を理由とする差別の解消の推進に関する法律（いわゆる「障害者差別解消法」）が2013年に制定されました。この法律には2016年4月に施行の予定で、2015年2月にはその基本方針が閣議決定されたばかり。基本方針には「情報アクセシビリティ向上」や「障害者による円滑な情報の取得・利用・発信のための情報アクセシビリティの向上」といったくだりがあることから、Webが障害者差別解消法の対象範囲に含まれることは確実と思われます。

今後ますます重要になるWebアクセシビリティの確保

法制化の動向はそれはそれとして、Webにアクセスする際に使われるデバイスの変化や、Web技術の高度化・複雑化という変化からも、Webアクセシビリティの確保は今後ますます重要になってきます。

マルチデバイス時代と機械可読性

今やPCのみならずスマートフォン、タブレット、さらにはウェアラブルデバイスに至るまで、さまざまなデバイスから自在にWebを利用する時代。そこで、Webコンテンツの機械可読性（ソフトウェアのような機械がコンテンツを読み取れるかどうか）という価値に注目が集まってきます。つまり、Web上のコンテンツをソフトウェアが読み取った結果を、ユーザに対しどれだけ便利に提供できるかが重要になってきているのです。機械可読性を確保することは、Webアクセシビリティを確保することとほぼ同義です。

Web技術の高度化・複雑化

Webの技術は日進月歩の勢いで進化し、改善され続けています。しかし、最新の技術が常にアクセシビリティに配慮されているとは限らない点に注意が必要です。アクセシブルにするための技術なり対応が「後追い」で生まれてくることは珍しくありませんが、Web技術がますます高度化・複雑化していくなか、それが社会に深刻な情報格差をもたらすことのないよう、アクセシビリティへの対応状況に常に注視する必要があります。

結局のところ、誰もがWebアクセシビリティを必要としている

誰もが、いつでも、どこでも、どんなデバイスでも、自分好みの設定でWebを使いたいと思っているはずです。加えて、誰もが一時的な障害者になり得ますし、また誰もが歳を取っていずれは高齢者の立場になるでしょう。Webが、障害者や高齢者を含む誰もが自由自在に使えるWebであるために必要不可欠な要素、それがWebアクセシビリティです。この先10年、20年経っても便利で「使える」Webを創るには、積極的にアクセシビリティを確保し続ける必要があります。

これからのWebアクセシビリティとの向き合い方

Webアクセシビリティを確保したWebデザインを実践していくための、いくつかの提案があります。

1. 想像力を働かせる

ターゲットユーザーばかりが、ターゲットブラウザーのみで、常に意図したコンテキストでコンテンツにアクセスするとは限りません。想像力を働かせ、さまざまなユーザーが、さまざまなデバイスで、さまざまなコンテキストからアクセスしてくることを意識してデザインしましょう。

2. WCAG2.0を読み理解する

とかく難解で分かりにくいと言われるWCAG 2.0ですが、文字量は恐れるほどではありません。日本語訳が公開されていますから、まずは読んでみましょう。あえて特定の技術に依存しないような書きっぷりゆえ抽象度がやや高いので、最初は書かれていることのすべてが理解できなくても当然だと思いますし、隅から隅まで全てを読み通す必要はありません。原則は4つ、ガイドラインは12しかありませんから、まずはそれらを知りましょう。

すべての原則とガイドラインをランダムでつぶやくTwitterアカウントがあります。たまにつぶやきを眺めることで、意識付けになるかもしれません。よろしければフォローしてみてください。

• Webアクセシビリティ・ファーストのTwitterアカウント、@a11y1st

3. 実現できることから着手する

Webアクセシビリティの確保に0点も100点もありません。自身にとって取り組みやすい、実現が比較的容易なことから、取り組んでみてください。欲張ってあれもこれもと手を広げなくても、Web標準の仕様に準拠するだけで、かなりアクセシブルにコンテンツを実装することができます。

たとえば例3に挙げたマークアップの妥当性は、W3Cの提供するバリデーターサービスで簡単に確認することができます。是非確認してみてください。

• The W3C Markup Validation Service

4. 継続できる取り組みを増やす

着手したWebアクセシビリティ確保の取り組みを、ワークフローの一部に組み込んでルーチン化しましょう。ルーチン化することが効率化につながり、対応のための時間的コストを下げることにもつながります。またWebアクセシビリティの取り組みに、周りの人たちを積極的に巻き込みましょう。さまざまなな立場の方からの協力が、より高いアクセシビリティ品質の達成に不可欠です。そして最終的には、WCAG 2.0のAレベル相当の対応を「当たり前」の品質にしましょう。最初は高すぎるハードルに映るかもしれませんが、継続的な取り組みを徐々に増やしていくうち、Aレベルであればそれほど難しくもないということに気づくはずです。

5. 足し算だけでなく引き算の視点ももつ

公的機関のWebサイトでは特に、文字サイズや色合いの変更ボタン、文字読み上げボタンなどが設置されているのを見かけます。しかし、そうした機能を提供しなければコンテンツがアクセシブルにならない、と考えるのは間違いです。もちろん提供してもよいのですが、提供するからには、それが本当にユーザーの利便を向上させる実装になっているか、しっかり検証すべきです。そもそもブラウザーのネイティブな機能や支援技術、ユーザーのリテラシーは進化し続けています。コンテンツを提供する側で用意すべき機能かどうかは、足し算の視点だけではなく、引き算の視点ももってWebアクセシビリティを捉えましょう。

6. 「守り」から「攻め」のWebアクセシビリティへ

Webはこれまでも、これからも進化し続けます。古くなった書籍や、Web上の更新されていない古い情報に惑わされたり、あるいは思考停止をしないでください。Webアクセシビリティ確保の大原則は変わらずとも、個々のテクニックのアップデートは随時必要となります。そうして積極的にWebアクセシビリティを確保することで、将来的に発生し得るコストやリスクを回避しやすくなります。例えば、iPhoneでFlash非対応が話題になった時、Webアクセシビリティの観点から代替コンテンツを提供していた制作者は慌てませんでした。似たような話で、レスポンシブWebデザインを採用しマルチスクリーンに対応すれば、現在と異なるスクリーンサイズが主流になっても、きっと慌てることはありません。徐々にでも「守り」から「攻め」に発想を転換し、今後も続く環境変化に耐えうる、アクセシブルなWebサイトをデザインしていきましょう。

最後のメッセージ：なぜWeb業界で働き、Webデザインに携わるのか？

Webには、社会をより良くするための変革をもたらす力があると思います。大げさに言えば、人類の発展に貢献することだって可能でしょう。Web業界で働き、Webデザインに携わるなかで、誰もがWebにアクセスし続けられるようアクセシビリティの確保に取り組むことは、より良い社会の形成、人類への貢献そのものだと自分は信じます。Webの創始者、Tim Berners Lee氏は次のように述べています。

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.

アクセシビリティは、Webの提供する本質的な価値なのです。それを忘れることなく、Webアクセシビリティの確保を通じ、共により良い社会の実現を目指しませんか。

次回予告

次回のレポートでは、村岡正和さんのセッション「アクセシビリティについて最近考えていることをざっくばらんに話すよ」をレポートします。お楽しみに！

この1～2年、Webサービスやスマートフォンアプリの開発現場では、早い段階から評価・検証により課題を洗い出し、制作の効率化を図るプロトタイピングがさまざまな手法・ツールによって試されている。

「UI Crunch」第3回となる今回のテーマは、「今、プロトタイピング開発に求められること」。講座は、元山和之氏（クックパッド）、吉竹遼氏（Standard Inc.）、村越悟氏（グリー）、土屋尚史氏（Goodpatch CEO）デザイナー各氏によるスピーチ、および坪田朋氏（DeNA）を加えたパネルディスカッションを通じて考え、深めていくという構成で行われた。

チーム開発におけるKeynoteを使ったプロトタイピング

最初のセッションは、クックパッドのデザイナー元山和之氏による「チーム開発におけるKeynoteを使ったプロトタイピング」。Keynoteをサービス開発・改善のプロトタイピング・ツールとして活用して得られた、メリット、デメリットを含めた知見について語った。

プロトタイピングの目的は「時間とコストを削減する」「ユーザーを理解する」ところにあるが、さらに言えば、その利点は、「思考」「共有」「検証」の3点だという。

• 試作品としてアウトプットすることを通し、客観視し「思考」を深められる
• それをメンバーとコミュニケーションし、「共有」できる
• さらに最も重要な点として、「検証」することができる

実際のkeynoteを使ったプロトタイピングにおける大きなメリットは以下の3点。

1. 誰でも使えるツールであること
例えば、デザインは簡単なスケッチ（ペーパープロトタイピング）から入ることが多いが、Photoshop、Illustrator、Sketchなどのグラフィックツールは、エンジニアにはちょっと使いづらい存在。しかしKeynoteであれば、比較的誰でも扱うことができる。また、グラフィックに関し高性能過ぎない分、余計な作り込みに力を割いてしまわないという副次的な効果もある。

2.より円滑にイメージを伝えられること
プロトタイピングはメンバーとコミュニケーションをとる手段でもあり、ただの絵や言葉だけでは伝わりにくい部分も、アニメーション、トランジションを使うことで、より明確に伝えることができる。

3.検証のためのインタラクティブな動作
ボタンをタップした時のクリッカブルな動きなど、インタラクションを表現したいこともある。Keynoteはもともと、こうしたものを作るツールではないが、実は表現可能。

動作まで含めたデザインのプロトタイプを、専門家以外でも簡単に作成できるのがKeynoteの利点。しかしその一方で、「実際に使ってみて、これは無理だなと思う欠点もある」と本山氏は語る。

• 画面遷移やインタラクションを複雑に作りこむのは無理
• デバイスなど、手元で確認するのに向いているとは言えない

「すべてをKeynoteでやるのは無理があるが、逆にそこまでやる必要はない」という元山氏。クックパッドではGoodpatchが開発したプロトタイピングツール「Prott」を使っており、keynoteと組み合わせて使うと効果的なのだそうだ。

プロトタイピングの助走と飛躍

続いては、スマートフォンアプリやWebサイトのUIデザインに特化したプロダクションとして活動する、Standard Inc.のデザイナー吉竹遼氏。「プロトタイプはツールだけでは終わらないし、できるものではない」と語り出した。

「プロトタイピング」という言葉をあまり限定的に考えず、「試行錯誤」と捉える。その場合、「試行」がいわゆるプロトタイプ、トライ＆エラーを繰り返す錯誤の部分まで含めてプロトタイピングと言えるのではないかという。その「プロトタイピング＝試行錯誤」を、吉竹氏は「あくまで自分の経験に基づいたもので、個々の現場により、差は出てくるかも」としつつ、このように図解する。

「試行錯誤」といっても多くのフェイズがあり、さまざまなことを考えて要るのだが、ここでのポイントは「勇気を持って試行錯誤しよう」ということ。大事なのは、以下に挙げる3点であり、試行錯誤とは勇気を伴う行動なのである。

• 早い段階で周りと共有する
• 捨てる勇気と変えない勇気
• 言いなりになれというわけではない

ここまでをプロトタイピングの「助走」と考え、では、今後どのように「飛躍」していけばよいのか。
吉川氏はWebデザイナーやUIデザイナーがデザインしているのは「体験・物語」であり、Webやアプリケーションは、あくまで体験や物語を伝えるためのインタフェースの一つだという。

そうした中で、｢プロトタイピング」が広範囲に及んだ際に、基点となりえる考え方を「一つは、さまざまなフェイズの広範囲にわたってきちんと考えること。もう一つは『人に寄り添う体験や物語を届けるために、人への興味を持ち続けること』が大事」と語り、これからの時代を考えるデザイナーや、プロトタイピングという考え方に欠かせない以下の要点を挙げて、セッションを締めくくった。

• 試行錯誤し続けよう
• 勇気を持ち続けよう
• 人間への興味を失わずにい続けよう

プロトタイピングにおける「段階」

次のセッションは、グリーのJapanGame事業本部Art部UXデザインチームマネージャー・村越悟氏。2014年までユーザーテストの仕組み化・ツール化に携わり、今年2015年の自らのキーワードとして選んだのが「プロトタイピング」。現在社内で進めている取り組みをベースに、「プロトタイピングにあるさまざまな手法を、どのような段階を踏んで行っていけばよいのか」を語った。

村越氏は以下のスライドを示し、イメージ、コンテキスト、コミュニケーションの真ん中にあるのがプロトタイピングなのではと語る。また、プロジェクト進行、管理に携わってきた経験が長く、特にその視点から捉えたものとして、チームビルディング（組織進化）モデル「タックマンモデル」をベースに、プロトタイピングの「段階」へと話を進めた。

さらに、最後の散会を除く各段階で生じる関係者間の「ズレ」、およびその現場で起こりえる例と対策はこのようになるという。

1.イメージのズレを埋める
「スッと指でなぞるだけ！」という表現だけでは、人によってイメージされるものが違ってくる。もちろん認識の齟齬がプロジェクトが進行してから発覚するようではダメで、それを埋めるためにペーパープロトタイピングを使い、それぞれ簡単にスケッチしてもらい、それを比較する。

2.要件・認識のズレを埋める
プロジェクトがある程度進んできた段階で起きる要件・認識のズレは、「Prott」「Sketch」の2ツールを併用。「全員が中間成果物を共有」「デザインコンテキストを共有」する。

3.全体品質への意識のズレを埋める
プロジェクトが後半にさしかかってきたところで生まれる全体品質への意識のズレは、「Unity」などで実装プロトタイプを作成。Unity上でかなりインタラクティブなプロトタイプを作り、パラメータやレベルデザインを調整していく。

これらによって、ユーザにとって、作り手にとって最善であること、最適な「体験」がユーザに提供できているか、価値基準――ゲームであれば難易度の設定や、きちんとプロダクトとしての成長曲線をたどっているか、最終的な製品としての品質を達成しているかなどの判断をチームで共有することができる。

主に使用するツールを、各段階にあてはめて整理すると、このようになる。

コンテキストの共有から文化は生まれ、文化の中から良いプロダクトは生まれてくる。つまり、プロトタイピングはイメージを会話するための「言語」でもある――と締めくくった。

Prott Story – Prottができるまで

最後はGoodpatch CEOの土屋尚史氏による「Prott Story – Prottができるまで」。「Prott」はGoodpatchが提供するプロトタイピングツールで、2014年10月に正式ローンチされて以来、世界中のユーザーに使われ、エンタープライズ利用としても、さまざまな企業で導入が進んでいる。2月18日には「Prott」PC Web版がリリースされ、プレスリリースサイトのPR timesで閲覧数トップに立ったのだとか。その注目の高さが伺われる。

2013年春にUIデザインを担当したGunosyのヒットを受け、GoodpatchはiOSの案件は次々に舞い込むという状況だったという。社内のリソースだけでは足りず、パートナー会社のiOSエンジニアと仕事を進めていくことになったのだが、ここで問題が発生。パートナーのiOSエンジニアとのコミュニケーションである。

まずはディレクターが仕様書を作り、デザイナーが静的なデザインを作り、エンジニアに渡す。しかし、それでは動きの部分はうまく伝わらない。その結果として手戻りが多い。さらに実装してみたら、何か違う……。そんなもどかしい事態が頻発したのだ。ちょうどその頃、「Flinto」というプロトタイピングツールがβローンチ。Goodpatchはこれを使い始め、デザインプロセスは一気に変わったそうだ。

利点を整理すると次のようになる。

• 設計段階から、動かしながら考えることができる
• デザイナーが動きや遷移、ストーリーを想像しやすくなった
• クライアントや開発エンジニアとのコミュニケーションが劇的に改善

しかしその一方、「Flinto」を使い込んで行く中で、若干の不満も出てきたのだという。

• チームでプロジェクト共有がしづらい
• フィードバックがプロトタイプ上で返せない
• さらに言えば、ワイヤーもツールで書けるのが望ましい

そこであらゆるプロトタイピングツールを調べてみたのだが、結局行き着いたのは、「自分たちで理想的なプロトタイピングツールを作る」こと。だが、「Prott」ができるまでには、数々の事件があった。

• 【事件簿その1】プロジェクトはスタートしたのに、エンジニアがいない！
• 【事件簿その2】実はデザイナーが乗り気じゃなかった！
• 【事件簿その3】競合ツールでプロトタイピング！
• 【事件簿その4】イケてると思ったUIが、実装してみたら全然使いづらい！
• 【事件簿その5】ろくなキャラクターが上がってこない！
• 【事件簿その6】バグが多すぎる！
• 【事件簿その7】iOSアプリなかなかでき上がらない！
• 【事件簿その8】ランディングのデザインをパクられた！

こうした数々の試練の中、ユーザーインタビューと改善を繰り返し、2014年10月に正式ローンチ。登録ユーザー数は約1万7000人。世界38カ国、1658都市で利用されている。

ユーザーに求められるプロダクトを作るには、コミュニケーションが活発なチームが必要であり、そのためにも、プロトタイピングは非常に重要なプロセスとなる。日本のデザインプロセスにプロトタイピングを浸透させ、素晴らしいプロダクトをより多く生み出せる土壌を作る。それが自分たちの使命であり、さらには、「Prott」を日本発のサービスとして世界で使われるようにしたい――と、土屋氏は今後の抱負を語った。

現場でどのようにプロトタイピングを回してる？

2部のパネルディスカッションは、DeNA坪田氏による司会進行で進められた。

坪田：まずは、現場でどのようにプロトタイピングを回しているのか、エンジニアやプロダクトマネージャーの理解はどうなっているのかについて、聞かせてください。

村越：グリーのゲーム開発現場では、割とプロトタイピングを実施していると思います。ただ、Unityでグリグリと操作できる状態でのプロトタイピングが多かったりします。やりすぎると最初から具体的になりすぎるので、デザイナー主体の場合はペーパープロトを使ったり、Sketch上でワイヤーフレームを切るほうにシフトするようにしています。Prottを使ったプロジェクト数も増えてきていて、いろんな人が使っている感じになってきました。

元山：今日はKeynoteの話をしましたが、吉竹さんの「試行錯誤がプロトタイピングの役割」というところは僕も同感です。クックパッドでは、グラフィックの前の部分やコンセプトを考える部分で、アプリケーション定義ステートメントシートといったものを最初に書いて、メンバー間でのすり合わせを行い、実際のビジュアルに起こしていきます。Sketchするなり、Prottに落とし込んでいったり、というところですね。

吉竹：前職での話になりますが、僕は個人的にプロジェクトに使っていました。「簡単に確認ができるので、実装に入る前に早めにこれで確認しましょう」と提示することが多かったですね。特殊な例としては、営業が会社の売り込みツールとしての活用。案件を取る前にBriefsでプロトタイプを作り、営業に持たせて提示してもらうと、客先で結構喜ばれたりしました。

坪田：それ、めっちゃいいですね。受注する前に、ある程度動いたり触れたりするものを作って営業していたということですか？

吉竹：そうです。前職では、いきなりフルでデザインして持っていく慣例があったので、「だったら、動かせるものを見せたほうがいいんじゃない？」という感じでした。

土屋：ウチはもう、プロトタイピングは文化になっています。普通にプロジェクトを進める場合、例えば、答えの出ない議論にはまってしまう時ってあるじゃないですか。そんな時は「じゃあ、まず動かすものを作ろうぜ」ということになる。

昔はそれで煮詰まってしまって長期間滞ってしまったものが、すごく話が進めやすくなるんですよね。そこで声の大きい人間の意見が優先されるとかではなく、きちんとパターンを作って、ユーザーに触ってもらって比較検討ができる。そうしたプロトタイピングの姿勢が一つの案件ではなく、「まずトライしよう」という会社の文化として定着したと思っています。

坪田：確かに開発スタイルの文化を変えた、というのは大きいと思います。

使えるプロトタイピングツールは何？

――ここで会場に集まった人たちに、坪田氏が「現在プロトタイピングの手法を導入しているか」を確認すると、およそ3割という結果に。

坪田：これは多いのか、少ないのか……。ちなみにDeNAでProttを使って開発しているデザイナーの数は、アカウントベースで20～30くらいでしょうか。導入前後で比較すると、コミュニケーションが非常によくなっています。コミュニケーションツールとしても有用だし、スクラップ＆ビルドする分、いいものができる。会場で、まだ導入していない方も、本当に簡単に導入できるので、ぜひ使ってみてください。

坪田：ところで土屋さん、最近「Pxiate」とか、プロトタイピングツールでアニメーションまで再現できるものも登場していますね。そういう（Prottの）競合ツールに対してどう考えていますか？

土屋：出てくるのは海外が主ですが、本当に、この2年で増えましたね。吉竹君は僕と同じくらいウォッチをしていて、ブログに全部。かなりわかりやすくまとめてくれていたりしますが――だいぶ増えたよね？

吉竹：増えましたね。たぶん30から40はあるんじゃないですか。最初ブログにまとめ始めた頃は18くらいだったと思います。

土屋：海外のツールは今、詳細なアニメーションを作る方向にいっていますね。ただ、Prottはコミュニケーションツールという位置付け。作りこむところよりも、全体のストーリー設計と、それを元にコンセンサスを得るところ、そしてすぐに早く作れる、ということを重要視しています。ですから、それらは競合というより、プロトタイピングという全体の中でレイヤーが違うと捉えています。

坪田：わかります。僕、Pxiateとかも使っているんですが、めちゃくちゃアニメーションが作りやすいんですよ。ですから、アニメーションを作りこむならPxiate、早く作るならProttみたいな使い分けをしています。

吉竹：アニメーションに関しては、今名前の出たPxiateがいいのかな。ただあれは月額なんで、僕は個人でも会社でも使っていなくて、個人的には、Facebookは開発したOrigamiというライブラリを使っています。おすすめかと言われるとちょっと難しいけど、Framerとかのほうがいいかもしれません。

土屋：でもQuartzコンポーザーもOrigamiも、ほぼプログラミングなのでハードル高いよね。デザイナーだと、作れる人は限られてきちゃう。

吉竹：そうですね（笑）。僕もそこは結構使い分けをしていて、ちょっとだけ伝える、ということなら、AfterEffectsを使ったり。反復の動きを確かめたいときには、Origamiで確認したりします。

プロトタイピングの意思決定権は誰が持つべきか？

坪田：「プロトタイピングの結果に対しての意思決定権は誰が持つべきか」という質問が来ていますが、これは皆さんにお伺いしたいですね。

村越：やはり意思決定者は、プロダクトオーナーだと思うんです。プロトタイピングで思考のプロセスもちゃんと共有して一緒に議論していけば、プロダクトオーナーが「これでいこう」と言った時に、周りが「マジかよ！？」というふうにならない――それは可視化することのメリットだと思います。

坪田：意思決定はプロダクトオーナーがするにしても、プロセスで、もうある程度皆の方向性は定まっているので、最終的にひとつにまとまりやすいということですね。その後で、社長が出てきてひっくり返したりということはないんですか。

村越：ありますね（笑）。そこはまあ、もう一回組み上げていくしかない。

坪田：質問の内容が変わってしまうかもしれないんですが、元山さんにお聞きしたい。現場でプロトタイピングしながら作っているメンバーと、トップとの意思疎通が取れていなかった時に、ミスリードしていたりするとマズイ事態になってしまいますよね。そういうことって、現場で起きていませんか。

元山：クックパッドでは、開発プロセスの中に「デザインレビュー」というのを挟んでいて、それはGitHub上で行っているんです。そこで皆で共有して、後々大きくひっくり返らないようなプロセスで進むようにしています。

土屋：それは対面レビューということですか？それとも上がっているものを見て、ということでしょうか。

元山：対面の場合は少ないですね。必要があれば、当然対面でということもあります。

土屋：ちょっとずれてしまいますが、皆さんは対面レビューの重要性というのはどうお考えでしょうか。ウチの場合、なるべく対面で行うことにしているのですが。やはりどうしても、テキストだとニュアンスがうまく伝わらない部分もあると思うので。

元山：テキストのみの場合、弊害はやっぱりありますね。意図がうまく伝わっていない部分などは、どうしても出てくると思います。ただ、時間的な制約もあるので、GitHub上がメインという感じですかね。

吉竹：僕はクライアントとの間ではやりますが、チーム内で定例的にというか、頻繁にやるということはないですね。でもまあ、対面のほうが個人的には好きです。

村越：今僕がコミットしているプロジェクトでは、スプリントごとに対面で集まってレビューというのもやります。プラスして、何かあった時に、GoogleDocsで意見を集約できるようにもなっています。対面と文章、2パターン併用ですね。

坪田：僕の場合は、対面レビューする案件としない案件がありますね。本題の意思決定に関しては、プロダクトオーナーがするんですけど、意思決定よりもプロセスが大事……ところに着地しました（笑）。受託だとなおさらそうかもしれませんが、意思決定者を早めに巻き込むことは重要かもしれません。

今後プロトタイピングツールに欲しい機能は？

坪田：プロトタイピングツールなど、何らかのツールを使ってデザインしていくわけですが、その時、アニメーションの実装では、Pxiateとか、AfterEffectを使う。それが、そのままiOSやAndroidに実装できるコピペボタンがあったら欲しいですね。これは結構切実なので、今後の、アニメーションやデザイン、プロトタイピングの分野の課題かなと思っています。

土屋：プロトタイピングツールではないですが、プロジェクト管理ツールは欲しいですね。僕はプロジェクト管理ツールフェチなんですけれど、未だにしっくりくるものがない。これはやっぱり自分たちで作るしかないかなあ、と思っていたりします。

吉竹：僕も坪田さんと同じで、アニメーションをエンジニアにちゃんと渡せるのがいいですね。あとは、ユーザーテストの時に役立ってくれるようなプロトタイピングツールが欲しい。今は普通に触っているだけですが、そこからいろいろ取得できるようにすると、またプロセスが変わってくるのではと思います。

土屋：そのままユーザーテストにかけるというのは、Prottでやる予定ですよ。

吉竹：楽しみにしています。

元山：今は静止画を動かすUIやユーザビリティのプロトタイピングが主ですが、クックパッドの場合、ユーザーに向けたサービスを作っているので、そのユーザーがどう受け取っているのかが最も気になります。もっと早い段階で検証できるプロトタイピングのツールや手法が確立されていくといいですね。

村越：僕もプロジェクト管理ツールはいいものが欲しい。でも結局いろいろ試した挙句に、GoogleDocsに落ち着くとか。プロトタイピングのツールでいうと、今後Prottに実装されますが、ワイヤフレームを書く機能は待ち遠しい。ワイヤーフレーム大好き人間なので、ワイヤーフレームから直接プロトタイピングとか、打ち合わせの場でライブでできたらいいなと。そういう、リアルタイム感のあるプロトタイピングをやってみたいと思ったりします。

こうして非常に中身の濃い、約2時間の講座は終了した。イベント募集開始後30分で満席となり、ここでは紹介しきれないほど質問も寄せられ、その関心度の高さを示したプロトタイピング。日本では実際に導入している事例はまだ少ないが、Prottの登場や現場での試行錯誤を繰り返すことによって、現場が抱える課題を解決できる可能性を感じた。今後もプロトタイピングの動向には注目したい。

＜関連資料＞

• UI Crunch 03 『プロトタイピングの助走と飛躍』
• UI Crunch#3：「プロトタイピングにおける『段階』」
• Prott Story 「Prottができるまで」
• UI Crunch #3 渋谷ヒカリエから生放送！「schooアーカイブ」

DeNAとGoodpatchの現役クリエイターが中心となって立ち上げられた、UIデザインを追求していくコミュニティ「UI Crunch」。11月27日に開催された第2回目の勉強会のテーマは「UIデザイナー不要説について語る」。

サービスやプロダクトを作る上で大きな差別化要因となっているUIデザイン。とはいえUIデザインに携わるUIデザイナーが、業界や企業において高い評価を受けているわけではない。そんな状況にもやもやした状況からネット上では「UIデザイナー不要論」まで飛び出すことに。「UI Crunch #2」はそのホットな話題「UIデザイナー不要説」について、徹底討論が繰り広げられた。

「UIデザイナー不要説」を書いた真意

最初のスピーカーとして登壇したのは、今回のイベントテーマとなった「UIデザイナー不要説」というブログを書いたTaiki Kawakamiさん。スピーチタイトルは「UIデザイン最終防衛マニュアル」。KawakamiさんはWebサービスUI設計やフロントエンド実装を行っているデザイナー。また個人でもTwitterクライアント「YORUFUKUROU（夜フクロウ）」のUIデザインを作ったり、Λ Structure Designというブランドを立ち上げたりしている。

　▲Taiki Kawakami（@seabream）さん

そんな中、UIデザインについてもやもやしている気持ちから「UIデザイナー不要説」という記事を書いたところ、業界に「波紋を起こした」と語る。「UIデザインが不要だとは思っていない。しかし企業としては投資しても短期的に大きなリターンが得られるものではない。だから投資されづらいという趣旨の記事だ」とKawakamiさんは極端な例を挙げて説明を続けた。

あるWebサービスにおいて、これまでの経験から1カ月で10個の新機能をリリースすれば5000万円の売上が上がると見込まれるとしよう。1カ月に10個リリースするには最低限のデザイン。しかしデザインに時間をかけると5個しかリリースできない。

その場合、経営者はどっちを選ぶかというと前者となる。そんな状況の中で、デザイナーは後者の方が、価値があるんだよとどうやって説得すればよいのか。このような状況からすぐ脱却できる方法について、Kawakamiさんが示したのは4つ。

1.革命：何らかの方法で社内にUIデザインの必要性を認知させる

例えば、簡単に作れるプロトタイピングを提出して議論をしたり、自主的にUIデザインが優れたものを作ったりして、数値測定をしてみるのも一つの手だ。ただ数値測定については「UIデザインを変更すると、これまでのユーザーの慣れにより数値が一時的に落ちることがあるので諸刃の剣になることも」とKawakamiさん。それでもダメなら上司、上層部に掛け合うことだ。

2.転職：よりUIデザインを重視している企業へ転職する

自分がこのプロダクトがいいなと思っている企業など、優れたアウトプットができている企業かどうかで判断するのである。もし分からない場合は、転職エージェントに相談するのも一つの手だ。

3. 独立：起業するかフリーランスになる

自由になるが、何もかも自分で考える必要があり、毎月固定の給料が入るわけではないので、生活が苦しくなることもある。

4. 趣味：仕事ではなく趣味でUIデザインを重視したものを作る

「僕の場合はこれ」とKawakamiさん。今日のスピーチも趣味で引き受けたのだそう。趣味なら自分でやりたいことを単純に追求できるし、アウトプットしていると「いろいろお願いされるので副業になることがある」のだという。あまり大きなことはできないが、1から3番と両立することができるので、「今いる環境に不満のある人は試してみるといいのでは」とアドバイス。

長期的な解決方法としては、「UIデザインの重要性を啓蒙していくことだ」と言う。そのためには「エンジニアがコードをどんどん公開して議論しているように、デザイナーもUIに隠されたデザインコードを公開し、どうしてそういうUIを作ったのか意図も含めて議論していくことだ」と語る。

いろいろ議論することは、自らの成長にもつながる上、会社の広報にもなるとも言う。もちろんコンプライアンスなどもあるが、公開することで、非デザイナーもUIデザインへの理解が高まっていく。Kawakamiさんは最後に「UIデザイナー不要説なんて見向きもされない世の中を目指しましょう」と締めくくった。

丸裸になって自分がやりたいUIデザイナーを考える

続いて登壇したのは、nanapi CCO デザイナーの上谷真之さん。スピーチタイトルは「風呂場で考えるUIデザインの未来」。

　▲株式会社nanapi CCO デザイナー　上谷真之さん

UIデザイナー不要説について語ると、どうしてもUIデザイナーの市場価値や求められるスキル、さらにはUIを生み出す価値などが話題となるが、これらは組織や業界のトップダウン的な考え方。

またUIデザイナーと一口に言っても、所属している企業やその人が描いているキャリアイメージによってそれぞれ異なる。統一的な指標やフレームに当てはめて議論にすると大抵は不毛に終わる。そこでここでは既存の考え方から解き放って考えたい」と上谷さんは言う。それが「風呂場で考える」ことなのだ。

風呂に入るときは、みんな裸になる。つまり既存の考え方（衣服）を脱いで、ゼロベースで話し合い、キャリアについて俯瞰していこうというのである。「思考のリフレーミング。枠組みを外して考える」を行うというわけだ。

思考のリフレーミングは「こわす」「ならべる」「もどす」の3つを行って整理することで可能になる。

1. こわす

今置かれている組織や肩書きを外すのである。例えば上谷さんもnanapiや職種などすべてを外してしまえば、33歳の単なる独身男性という状態になる。

2. ならべる

壊した状態、フレームを外れた状態で自分のキャリアについて見直してみるのである。上谷さんの場合は、UI設計、ユーザーリサーチ、組織作り、情報設計、サービス改善、企画などのスキルを並べ、さらに「心に届くデザインで世界を変えたい」という自分のビジョンやライフテーマも挙げた。

3. もどす

自分の目指すキャリアややりたいことを社会や組織に戻してみるのである。自分を起点にして社会や組織にこんなキャリア、こんな価値を届けていきたい、それができるよう組織、社会にアジャストさせていくことを考えるのである。こういう手法を使い、UIデザイナーとはどういう仕事なんだろうということが、整理できる。

「業界や社会が求めるUIデザイナーを気にしすぎるのは時間がもったいない。誰かに合わせて決めるのではなくて、自分がやりたいように決めるのが重要だ」と上谷さんは強調する。

* 誰かが決めたUIデザイナーという肩書きはいらない
* 自分がやりたいことをやろう

「デザインを楽しんですばらしいサービスを作ってほしい」と語り、スピーチは終了した。

B2Bアプリ・サービスにおけるUIデザインの価値とは

3番目に登壇したのは、トレタ COOの吉田健吾さん。スピーチタイトルは「UIデザインの価値」。

　▲株式会社トレタ COO 吉田健吾さん

吉田さんは自身のブログ「Parallelminds」にKawakamiさんの「UIデザイナー不要説」のアンサー記事「UIデザインの価値」を書いた一人。この業界に所属して13～14年。2014年7月より「トレタ」という飲食店向けの予約台帳サービスを提供している会社で、COOを務めている。

「UIデザインに価値はないのかと問われたとしても、もちろんあると答えるしかない」と吉田さんは言い切る。その理由は、「ユーザーが触れるところはUIであり、そこが良くなければ優れたビジネスモデルも高い技術力も評価されないと思う」からだ。UIはユーザーのアプリに対する印象に加え操作感も決定づける重要な要素である。従って「UIデザインは競争力の源泉になると考えている」というのだ。

「ただUIデザインよりも他の要素が優先されるケースはある」と指摘する。その一つは価格訴求力が強い場合。またポイントが付くなど、デザイン以外の何か強力の魅力がある場合。さらにB2Bアプリで多いのが、デザインの善し悪しで利用可否が決まらない場合。「自分の例で言うと会社で使っている勤怠申請のサービスは使いにくいが、決められているので使うしかないというようなことがそれだ」と吉田さん。

つまりUIデザインは数ある要素の一つである。ビジネスの結果を出すために万能ではないが重要なもの。先述したように、特にデザインの善し悪しで利用可否が決まらないケースが多いのが、B2Bアプリ・サービスである。そこでB2BのおけるUIデザインの価値とは何か。

トレタが提供している飲食店向け予約台帳サービスは、仕事のために使うアプリである。飲食店は非常に忙しい。操作に迷ったり、ミスを誘発したりするようなUIは大きなコストにつながる。

そのため、「B2Bの現場でのUIの価値は大きく説明しやすい」と吉田さんは言う。とはいえ、「1年も使っていれば慣れる」というセリフがまかり通るのもB2Bの世界ならでは。特に稟議を回すときは「高機能、多機能、低価格」なものほど通りやすい。

つまりUIが優れていることの価値について、稟議を通すのは容易ではないのだ。そこで「シンプルで簡単であることがどれだけ重要かを伝えるようにしている。UIデザインにちゃんと価値があることを伝えている」と語る。

同じようなB2Bアプリが登場している中で、一番差別化できるポイントがUIデザインなのだ。最後に「UIデザインを競争力としてその価値を証明していきたい」と語り、スピーチを締めくくった。

過去を振り返りUIデザイナーの必要性を考える

ラストに登壇したのはBASEのCTOである藤川真一（えふしん）さん。スピーチタイトルは「経験に基づくUIデザイナーの必要性」。

　▲BASE株式会社 取締役CTO　藤川真一（えふしん）さん

製造業の技術者としてキャリアを積んできたえふしんさんは、2000年にネット業界に転身。2004年頃に在籍していた会社では、UIデザイナーという職種がなかったという。「その頃の話をしたい」と語る。当時のWebの制作はどんな状況だったのか。

1. 営業部門でWebの重要な仕様が決まっていた

2. もう言っちゃったから、今さらやめられない。どうにか実現せねば。

3. 案の定、制作部門が不満たらたら

（営業やディレクターが起こした簡単なパワポを下にデザインを起こしていくので、不備が出てくる）

4. 制作部門は納得いかないので、自分たちのコストで作り直してしまう

（アーキテクチャ不在。作った階段を自ら壊す）

5. 開発チームがとばっちりを受ける

そのときに思ったのが、「Webの設計は誰がやるの」ということだったという。えふしんさんは当時書いたブログを披露してスピーチを続けた。

Webを設計する人は技術者でもないしビジュアルデザイナーでもない。その中間の人だ。いずれデザイナー的な側面の人か技術者的側面のいずれかの人が傾倒し、そういう職種の人が登場してくるだろうということを予言していたという。

だが、業界はそうではなかった。だからこそ当時のえふしんさんは「設計の重要性がそこまで認知されておらず、誰もWebサイトの実現性に責任を持てない状況であること」「スキルセットが不足しており、とりあえずデザイナーやディレクターにアサインされてしまう状況を問題視していたのだ。

そして今もこのような状況があるという。当時から役割として必要だなと思っていたのは、情報の設計=Web UIデザインに責任を持つ人、プリセールスとポストセールスに関わる人（受託の場合）、そしてチームの一員としてWebサイトが目標とするフィロソフィーを円滑に実現する役割を担う人（楽しさ=UX、ユーザビリティ、実用性）である。

しかし「そんな人材いないよね」という説が登場する。もちろん「すべてができる人材を求めているわけではない」し、「チームとして補えればいい」というのだ。またこういう役割が「職業分野としてFIXしているとは思っていない」とも言う。

「お母さんでも使えるネットショップ」+「モノを売るたのしさ」が味わえるサービスを提供しているBASEではどういう人を求めているのか。成果の原資として必須なのが、ビジュアルデザインのスキルである。次に論理的思考。つまり物事を順序立てて考えられ、ちゃんと説明できること。第三にネットがすごく詳しい人もしくはすごく興味がある人だ。

「UIのスキルはぼくたちがカバーできる」えふしんさん。BASEというサービスがチャレンジなので、ジョインする方にも会社と自分を成長させていく人がくればいいというのだ。その中で「UIデザイナーは不要なのか。その存在意義をついて改めて考えていきたい」こう語り、スピーチを終えた。

「UIデザイナー不要説」をテーマに語り合う

10分間の休憩を挟み、UIデザイナー不要説について語り合うパネルディスカッションが始まった。パネラーはゲストスピーカーとして登壇した4人にDeNAのUI Designerの坪田朋さんの5人。そしてGoodpatch CEOの土屋尚史さんがモデレータを務めた。

　▲左から、DeNA デザイン戦略室室長 UI/UXデザイナー坪田朋さん、株式会社グッドパッチ 代表取締役 土屋尚史さん

土屋：なぜ「UIデザイナー不要説」という記事を書こう思ったのでしょう。UIデザイナーが不要だと思ってないですよね。

Kawakami：不要と書くと逆に必要だという議論ができると思ったんです。

土屋：そしてKawakamiさんのブログを見て書いたのはアンサー記事を吉田さんが書いた。

吉田：タイトルを読んだ感想となんかイメージが違ったんです。

土屋：その頭の整理のために、えふしんさんが記事を書いた。

えふしん：けんごっち（吉田さん）が書いた記事を読んで、そういうことあるよね、と思いつつ、UIデザイナーや開発者を募集しているので、そこで思っているとことを書いたんです。そもそも、当社でも募集するときに職種名の出し方をどうするか、WebデザイナーかUIデザイナー、フロントデザイナーなのか工夫していたんです。でもなんかはまらないなと思っていたときに、そういう記事が上がったんです。

土屋：みなさんの会社にUIデザイナーと呼ばれる方は何人いますか？DeNaの坪田さん。

坪田：クリエイターは200人ぐらいいますが、UIデザイナーと呼んでいる人は20～30人です。当社のUIデザイナーのミッションはUIの設計はもちろん、プロトタイプまでも回す人。ディレクターとグラフィッカーとタッグを組み、UIデザインを開発していきます。

上谷：うちはUIデザイナーがゼロです。単にデザイナーはデザイナーと呼んでいる。うちのエンジニアはプロトタイピングまでを作るので、UIという言葉をあまり意識していないのかもしれません。デザイナーは僕を含めて6人。

デザイナーの仕事はかなり広くてビジュアルデザインはもちろん、マークアップ、UIの設計、情報設計、数字にもかなりコミットする。もちろん、一人で全てに責任を持つのではなく、特異な分野アサインしています。

土屋：Kawakamiさんの会社は、UIデザイナーは何人いますか？

Kawakami：10人ぐらいですね。デザイナー全体だと50人くらいいます。

土屋：その中でKawakamiさんはUIデザイナー。デザイナーになったのは？

Kawakami：2013年です。もともとは別の会社でWebデザイナーとして経験を積み、今の会社でUIエンジニアを経てUIデザイナーになりました。社内で必要だと言う風潮が高まったことがきっかけです。

吉田：トレタは20人ぐらいの会社ですが、デザイナーは一人。その彼はUIデザイナーだけをやっている。いわゆるWebデザインは外注にお願いしています。アプリを担当しているデザイナーしかいません。

えふしん：BASEはデザインを担当しているのは3人です。そのうちUIデザインを設計するのは1人です（2014年12月からは2人）。人それぞれ得意分野が違うので、パーソナリティに応じてお願いしている。いちばん広い職域の人はデザイン、UI設計、マークアップ、さらにはPHPのテンプレートまでいじってもらっています。

土屋：うちはデザインの会社なので、UIデザイナーは12～3人います。元々はWebデザイナーとグラフィックデザイナーだった人たちが、現在、UIデザイナーとして活躍しています。

UIデザイナーが持つ権限について

土屋：プロジェクトの中でUIデザイナーはどのくらいの決定権を持っているのでしょうか。

坪田：プロダクトの最終の意思決定権はプロデューサーが持つべきだけど、サービスを作る人、つまりUIデザイナーがハンドリングやコントロールの意思決定権を持つべきだと思います。

土屋：UIデザイナーが最終の意思決定権を持つ人になってはいけないんですか？

坪田：僕は昔サービスを造ったときにプロダクトオーナーとしてUI設計をしたこともあるので、ケースによってはあってもいいかなと思う。僕はある程度の意思決定権がないとサービスを作りたくありませんね。

土屋：nanapiはどうですか？

上谷：うちはデザイナーの意思決定権は一般的には強いと思っている。最近、新規開発を行っているチームはデザイナーとエンジニアのみで構成されており、KPIも全員が持っている。そんなプロデューサー、ディレクターはいないチームが何チームもあります。KPIを達成するための施策は承認がいらないんですよ。

土屋：承認がいらないんですか？　デザイナーがこうしますと言ったことが実装されるということですか。

上谷：新規開発はスピードが優先されるので、意思決定で遅くならないように権限を移譲しているんです。

土屋：Kawakamiさんの会社ではデザイナーはどんな立ち位置ですか。

Kawakami：非常に権力が弱い状態です。だから不要説を書いたということもある。本当に自分必要なのと感じるぐらい低い。

土屋：もう少し具体的に話してくれますか。

Kawakami：元々、デザイナーがUIを考えるという工程がないんです。ディレクターのつくったそれほど凝っていないパワポから画像を作り、それをエンジニアがそれを組み込むという感じです。ただ、最近は徐々に改善してきており、僕自身がワイヤーフレームを書いたりするようになりました。

吉田：うちは権力というか権限ということで言うと、代表の中村がプロダクトオーナーを兼務しているので、最終的な意思決定は全部彼が担います。中村は飲食店の現場にいた経験があるので、彼以上にユーザーに近い人材はいないんです。

土屋：BASEはどうですか？

えふしん：うちも代表の鶴岡がクリエイティブディレクターという立ち位置なので、最終の意思決定権は彼が担っています。ただ、当社では機能マターではなくデザインマターで開発するように言われています。つまり使いやすさ、楽しさが先になかったら、機能を追加しても仕方ないという考え方があるんです。

土屋：まさにデザインドリブンですね

えふしん：そうです。

UIデザイナーとして求められる人材とは？

土屋：デザイナーの募集条件について教えてください。

坪田：すごくグラフィック勉強してきましたとかデッサン力ありますと言うより、作ったものをきちんと自分たちで自己否定して、何がユーザーに刺さるのかという思考を巡らすことができる人ですね。

今は2Dだけでなく、アプリケーションの開発はアニメーションやレイヤー、トランジションなども含めて、機能としてデザインしていくことが求められます。それらを頭の中でシミュレーションしてUI設計できる人ですね。総括するとユーザーが本当に使うかどうか、機能を選別してディレクションできる人です。

土屋：そんな人はいません（笑）。

坪田：全てできる必要はないんです。足りないことはコミュニケーションできて、ユーザーを意識しながら頑張る人。楽しみながらプロトタイプを回せる人です。えふしんさんとも話していたけど、UIデザイナーはスタートアップ時のCTOと似ていると思うんです。名称は魅力的だけど、やることは何でも屋さん。

上谷：うちはUIデザイナーではなく、デザイナーを募集しています。重視しているのは情熱と視座の高さ。この2つがあればスキルは付いてくると考えているからです。

吉田：同じような答えだが素養や姿勢が大事だと思っている。デザインに対して、代表の中村が全身全霊をかけて聞いてきます。そのときに、なぜこういう風にしたかを自分の中でロジックを立ててちゃんと説明できることが大事になるからです。

えふしん：UIの担当で言うと、普通に採用するときはいいビジュアルデザインができるかどうかを見ます。Webもアプリもぱっとみて使えなければ、その後ろにどんな高機能があっても使えないからです。かっこいいデザイン、魅力的なデザインがあって、その後ろに使い勝手があると考えています。

だからビジュアルデザインを見るんです。次に重視するのは論理的思考です。物事を順序立てて説明できる、ユーザーにとってどうハッピーかを議論できること。そういうデザイナーであれば育成できます。あとは度胸のある人ですね。スキルはできなくても立ち向かう勇気が必要だからです。

土屋：と企業は言っていますが、Kawakamiさん、いかがでしょう。

Kawakami：そんなに募集しているんですね。デザイナーの需要があるということは、もっと発信していってほしいと思います。

土屋：Kawakamiさん周りにいるデザイナーさんたちは、どういうところで働きたいと思っているのでしょうか。

Kawakami：それなりの権限が与えられており、意思決定に携われて、給与も平均以上ぐらいもらえる会社ですね。

デザイナーの給料は上がるのか？

土屋：以前、Webデザイナーの給与が非常に安いという議論がありました。デザイナーの給与はどうやったら上げられるんでしょう。

えふしん：マネジャーになれば上がります（笑）。というのはさておき、成果物の評価が難しいんですよね。

土屋：デザインは定量的（数字に換算できない）な評価ができないことが多い。これをやったら売上がこれだけ上がるという証拠が提示できませんからね。こう点が、デザイナーが冷遇される要因になっていると思うんです。

吉田：ぼくはもっと単純に考えていて、需給関係の問題だと思います。UIデザイナーが採れないというのであれば、UIデザイナーの給与は高く出さないと来ないと言うこと。Webデザイナーは供給が多いか、できる人、できない人の判別ができていないからではないでしょうか。

社内の対策としてはえふしんさんがおっしゃったように、上級職を作っていくということもありますが、評価軸もデザイナーたちで作っていくという動きがあればよいのかなと思っています。前職（ペパボ）にいたときに、エンジニアが上級職制度を作ったんですよ。みんないろんなアウトプットしてもらって、業界的に上がっていくのでは。

えふしん：Goodpatchさんが単価を上げて公開すると、「デザインってこんなにコストがかかるんだよ」というというのがわかるようになるのでは（笑）。業界としてこれぐらいのクオリティを保つにはこれぐらいかかるよというのを示してください。

土屋：今、それをやろうと思っているんですよ。そしてデザイナーの評価制度も今、作っています。デザインの単価はこの1年半で人月単価が倍になっているんです。

坪田：デザインの受託会社は、グラフィックのみ納品しており、プロセスは納品していないんです。グラフィックだと人月単価でそこそこの単価で出せるし、相見積もりをとると他の会社が安く出すと平均値を取られてしまう。デザイナーも強気に言っていった方がいい。

土屋：ソーシャルゲームが流行ったことで、それに携わるエンジニアの給与はかなり上がりましたからね。今はデザイナーでも同じことが起きようとしているということですね。

坪田：あと1年ぐらいしたら、デザイナーにオファーレターがたくさん届く時代がくるのではないでしょうか。そのときに大事になるのは自分のプレゼン力。海外のデザイナーは自分のプレゼンがうまいんですよね。自分はこれだけ高い価値を持っているしポートフォリオを持っているからちゃんと高く評価してくれないと仕事をしないというスタンスなんです。

土屋：低い給料で働いてしまっているデザイナーさん達にも問題があるということですね。

Kawakami：今日は本当に勉強になります。

稼げるデザイナーになるために

土屋：稼げるデザイナーになるためにはどうすればよいでしょう。

Kawakami：ぼくは稼げていないので、教えてほしいですね。

坪田：オリジナルのUIデザインをなぜこのUIにしたのかという理由とともに、毎月、BehanceやDribbbleに上げていくんです。おそらく1年以内に200万ぐらい給料を上げられるオファーが来ると思います。自分で発信してプレゼンして目立つ人は、企業からオファーが来るんです。だまされたと思って、半年やってみてください。よければぼくがスカウトしますので。

土屋：日本では自分でデザインを作っても公開できないみたいな風潮があります。坪田さんは会社のデザイナーでも全部、公開しようとしているんですね。

坪田：自分でつくったものは言いたいじゃないですか。言えない環境は不健全だと思うんです。そこで当社では仕事で作ったものをBehanceやDribbbleなどで発信していこうという文化に変えました。企業努力すれば変えられます。それが優秀な人材を確保することに、そして企業の存続にもつながるからです。

吉田：オープンソース活動と同じです。有名になった人に仕事以外にも話がくる。これはみんなが努力をすれば登れる山です。エンジニアはソースコードを公開することができるが、デザイナーは最終のアウトプットだけ出してもダメなので、意図なども出していくとこの人はちゃんと話が通じるデザイナーだと見えるようになりますよね。

土屋：Kawakamiさん、個人でも仕事を受けていますよね。個人だとある程度、単価を上げて出しますか。

Kawakami：出しますけど、値切られることが多い。

土屋：負けちゃダメですよ。こんなに価値を出すのでといって、言い切れるのが重要だと思います。

デザイナーはプロダクトをリードできる立場になれるのか

土屋：デザイナーがプロダクトをリードできる立場になれる時代が来るのでしょうか。

坪田：その人次第ですが、そういう環境はすでにできています。

えふしん：スマートフォンのアプリはデザイナーがリードしないと作れませんしね。

土屋：とにかくこれから1～2年、UIデザイナーはスター状態だと思います。

坪田：もし今の環境がデザイナーの価値を感じてくれていないのであれば、別の価値を感じてくれる場所に行くべきだと思います。

会場からの質問はもちろん、スクーでの受講者の質問にも答え、盛り上がったまま終了時間を迎えた「UI Crunch #2」。UIデザイナーは不要どころか、今後ますます求められる存在となることがわかった。ビジュアルデザインが得意なら、開発側からも転身ができる。これからの注目の職種と言えるのではないだろうか。