今年もHTML5 Conference 2017の展示ブースでは、私ことDJ KATOの特別ラジオをお届けしていました。今回はビジネス・アーキテクツ太田良典さんとサイバーエージェント原一成さんをゲストに迎え、「UIデザインとアクセシビリティ」テーマに語っていただきました。その再現レポートをお届けします。ぜひ、カンファレンスレポートの番外編としてお楽しみください！

まずは、どんな講演内容だったのか教えてください

「ビジネス・アーキテクツの太田です。普段はWebアクセシビリティ関連の活動を主に行っています。『多様なユーザーニーズに応えるフロントエンドデザインパターン』というタイトルで講演させていただきました。よろしくお願いいたします」

「サイバーエージェントの原です。アメブロのフロントエンド開発を中心に行っています。『“モダン” ウェブアプリケーション ～アメブロ5ヶ年計画～』という講演タイトルで、アメブロの “モダン化” 実例に沿った考え方や技術採用事例、今後の展望などをお話しました」

「お二人とも先ほど同じ時間に講演されてきたんですよね。どちらかのお話を聞いた人は、どちらかが聞けなかったと思うので、どのような話をされたか教えていただけますか」

「私は、11月4日発売の『インクルーシブHTML+CSS & JavaScript 多様なユーザーニーズに応えるフロントエンドデザインパターン』という書籍で紹介されている、アクセシビリティに配慮した実装手法について、例を挙げて紹介しました」

「どのような実例でご説明されたのでしょうか？」

「先ほどのセッションではサイトでの操作など、使いやすくするためにはどうするかという話をしました。例えば、商品のリストを値段の高い順や安い順に並べたり、最新順に並び替えるなどの機能も、基本的な要素を使ってマークアップしましょうという話ですね。絞り込みの機能を選択するのは高い順・低い順・古い順・新しい順が多いのですが、それは4個の中から1つを選ぶ機能なので、ラジオボタンで実装すればいいとか。

よくある問題は見た目がきれいになるからと、ラジオボタンじゃなくて<span>とか<div>で実装して、JavaScriptでクリックイベントをつけて操作できるようにするとか。それは、ラジオボタンで実装することによってキーボード操作であっても使いやすくすることができます。でもソフトキーボードでちゃんと使えるのか、スクリーンリーダーでアクセスしたときにちゃんと読まれるのかなど、いろんな問題があるわけです。なので、基本的にはちゃんと機能に合った要素を使って、見た目は後からがんばりましょうという話ですね」

「先に知っておけば、そういう落とし穴には落ちないということですね」

「HTMLをやってる人なら誰でも知ってるはずなんですけど、なぜか<div>とか<span>を使ってしまうんですよね。知っていることと実践できているかというのは別なんです」

「そうなってしまうのは、楽だからなんでしょうか」

「というか、『見た目から入ってしまう』からそうなるんですよね。見た目から入ると『枠で囲まれているから<div>かな』という考え方になりがち。後から結構スクリプトでできちゃうので、それなりに動くものができるんですよね。ただ、それがどんな環境でも使えるかというと、結構使えないことがあるのが問題です」

「そういったことをいろいろご紹介されていたんですね。チェックボックス以外のトピックも聞いてみたいです」

「リストや見出しをちゃんと使うことですね。あとJavaScriptやXHRを使ったパフォーマンス改善やアクセシビリティの話を中心にしていました。

アクセシビリティは『JavaScriptをできるだけ使うな』という議論になることが結構多いんです。でも、今普及してるUIはJavaScriptで動かしていることが多いのに、そんなこと言われても困るんですよね。今回ご紹介してる本ではこうすればできるという技法を紹介しています」

「ありがたいですよね。僕もJavaScriptを使いまくりなんですけど、実際のサービスを作る上ではやっぱり使わざるを得ない。さらに、ネイティブアプリとの差をなくしていったり、使いやすさを向上させるには必要な技法です。ピンク本と呼ばれる「デザイニング Web アクセシビリティ」という本があるんですが、毎週チームで読み会をしています」

「そのピンク本、ありがたいことに私の著書なんです(笑)」

「うちの会社にもあります。みんなは読んでいる本なんですけど、僕はどっちかっていうとエンジニアというよりディレクター寄りということもあって、まだ読んでいませんでした。すみません…」

「ディレクターさんにもすごくいい本ですよ」

「というか、ディレクターさんにもぜひ読んでいただきたいと思って書いた本です(笑)」

「なるほど！読みます！」

「実装だけじゃなくて、その上流から踏まえていきましょう、ということも結構書いているので、ぜひ読んでください」

「さっきのサイト制作の話に戻るんですけど、見た目から入っちゃうことが結構多くて。特にビジネスで評価する人って、この見た目がかっこいいとかから入っていきがちなんですよね」

「見た目と動きだけでしか評価できない人が多いという問題もありますね。見た目と動きがちゃんとしてればOKになってしまうことも多いんですよ」

「例えばディレクターがアクセシビリティを知らなくて、スクリーンリーダーなどの存在を知らなかったら、それだけで話が通じなくなりますよね」

「そうですね。それを解消するためにも、ぜひ！」

「まずこれを読むことで、関係者全員のしなくてもいい紛争が減ると」

モダンなウェブとアクセシビリティは両立できますか？

「原さんはモダンなウェブというテーマで講演されていましたが、アクセシビリティと両立するのは難しくないんですか？」

「難しくはないんですけど、ワークフローの中に組み込むのが結構大変ですね。プロジェクトは企画から始まって、デザインを作って…というように、見た目が前提なフローが多いので、どうしてもコードがわかる人はフロントエンドエンジニアくらいになるんですよ。評価できる人も」

「自然と優先度が下がっちゃう、というかんじですね」

「そうなんです。先程も言ったように『コードを知らない』って方もいるので、ピンク本は『JavaScript使うな』とは書いていないので、その辺もありがたいです」

「そういうことですか！」

「昔ながらのアクセシビリティをやってる人だと、『JavaScriptは使うな！』と言っちゃう人もいるんですよね。現場ではそう言われても困るので、なんとかしたいって思ってたんです。今回の本はそういう内容がたくさん書かれているので、いいなと思っているんですよね」

「極端ですけど例えば『危険だから家から出るな』みたいな話になっているんですかね」

「そうそう。何かあった時に『これとこれとこれを準備して』とか『こういうことに気をつけて』というのを示してくれるかんじなんです」

ところで、普段はどんなお仕事しているんですか？

「話は変わるんですけど、太田さんは普段どんなお仕事されてるんでしょうか？」

「ビジネス・アーキテクツという会社で、Webの仕事をしています。主に大きな会社のWebサイトを受託で作ることが多いです」

「企業の公式Webサイトですね」

「そうなんです。グローバル展開している日本の大手企業が多いのですが、そうした企業はアクセシビリティのガイドラインを持っていて、各国に配布したりしてるんですよね。各国にもそれぞれサテライトサイトがあって、全部統一させようと取り組んでいます。そういうアクセシビリティのデザインガイドラインの配布や取り組みに対して、お手伝いをしています。ひと言で言うと、Web制作ですけど」

「ひと言だとそうなんですけど、大変そうというか、慎重にやってかないと…。なんか、あまり軽いノリで作れないサイトってかんじですね」

「重すぎるノリっていうのも問題で、これやるなって言いすぎてもガイドライン無視されるだけなので、やっぱり現場で使えるようにしていかないと。実際に使えるものを作って、かつ運用できるようにしていくということがすごく大事なんですね」

「そうすると、基本のWebだけではなく、モダンな開発手法も知らないといけないですね」

「最近だとモバイル用のページをレスポンシブで作るのが当たり前になっていると思うのですが、そういうところも考えないといけないことがありますね」

「スマートフォンのモバイル用のページのことや、PC用ページではどうかとか、デスクトップのリーダーではどうかというのも書いてあって便利です」

「原さんは、どんなお仕事をされているのですか？」

「私は完全に開発者で、2004年からずっとアメーバブログを作っています」

「長いですね！」

「2015年にリニューアルをしていますが、サービスの歴史も長いですね。主にフロントエンドを担当しています」

「歴史が長いと今までに積み上げてきたものも多いと思います。社内で設計が大きく変わったりすると、かなり大変だと思いますが」

「その辺はエンジニアと協力しながらやっていますね。iOSならiOSの、AndroidならAndroidのエコシステムっていうか開発環境と作り方の基本があるんですけど、その上で他の人と会話しながら、モダン、モダンって言いながら開発してます。閉じこもった自分たちだけのライブラリばかりでは、存続が危うくなると思うので」

「お二人ともなんというか共通するところがあるっていうか、戦っているポイントが結構似ているかんじがします」

「かなり」

「そうですね」

お二人の情報収集や勉強方法を聞かせてください

「お二人はどのように情報収集や勉強されているんですか？」

「今まさに勉強しているつもりです」

「そうそう。かなり勉強してます(笑)」

「気がついたら置いていかれてた…っていうのは一番避けたいのですが、そのためにどんなことをしたらいいのでしょうか。ニュースサイトを見るとか？」

「それもありますが、周りの人と会話をすることも大事なんじゃないかと。最先端の技術者たちとコミュニケーションをとったり、彼らがTwitterなどで何をシェアしているのかを見ることで、どういうものが流行っているかを知ったりすることが多いですね」

「僕も一番簡単な情報収集はTwitterですね。フォローしておいて、その人がリツイートしているものを見るだけでも参考になります。あと、海外の情報も重要なので、英語が読めるだけでも大分可能性は広がります。ちょっと時間差はあるかもしれませんが、日本語に訳してくれる人をフォローするという手もありますね」

「Twitterはすごい情報数があふれているので、普段あまり使ってないんですけど…。どうやって情報の絞り込みをするんですか？」

「もちろん、全部を読むわけではないですよ」

「技術系のカンファレンスで気になったものをフォローしているので、そこからとか」

「良質なツイートをしている人が発信している情報を集めて、どんどんその濃度を上げていくみたいなかんじなんですね」

「あとは情報を発信している人のところに実際に行ってみるとか。そういう会社に入っちゃうというのもありますね」

「なるほど！」

「簡単に希望したところに行けるかはわからないですけど」

「そういう意味では、サイバーエージェントさんは大変いい環境ですよね」

「うちは情報が自然に入ってくる環境なので、勉強する必要がないっていうか。極論ですけどね(笑)」

「自然にっていうのがすごいですよね。周りの人との雑談がなんかマークアップの話になるとか？」

「ちょっと気持ち悪いかもしれないですね、普通の人からすると(笑)。技術に興味がある人が集まっている場所というか」

「でも、マークアップの話で盛り上がれるってすごく楽しいですよね。いや、『それ変態だ』って言われそうですけど(笑)」

アクセシブルなサイト設計・制作について教えてください

「簡単なアプリケーションだったら自分で作ったりもするんですけど、実際に開発始めてみると<div>とか<section>とか、途中で<h3>や<h4>がだんだん適当になってくんです。100行超えてくると『あれ？もともとどんなかんじに作りたかったんだっけ』というかんじになって、全体のことがあやふやになってくるんですけど、どうすればいいんでしょうか」

「それはいい質問だと思いますね！早い段階から見た目を気にして、その段階で増やそうと考えちゃってるんですよね」

「はい。で、書きながら実行してるんですよ」

「それは自然ではあるんですよね。悪いことではないんですが、基本的にオススメなのは、まずCSSを一切適用しない状態でHTMLだけで作ってしまうこと。結構しっかりした構造が作れると思います」

「完全に素のやつですよね」

「さらに言うと、見出しから作っていくとか。それがマークダウンなんですが、逆に難しいかな」

「以前僕が経験したものだと、先にデザインが決まり、デザインカンプが上がってきて、スライスしてCSSをあてる。で、インタラクションとかをJavaScriptでやるという順番でした。ちゃんと考えたつもりなのに、だんだん破綻していくんですよね。いきなりフロートからやるとか、順番がおかしいとは思ってたんですけど(笑)」

「もしかすると、デザイナーさんもあまり整理できてないのかもしれないですね。うちではコンポーネント思考で、デザインから作っています。Webコンテンツをコンポーネントっていう単位で分割するんですよ。例えば見出しなら見出し、本文なら本文、リストならリストみたいなパーツに分割してデザインしてくんです。

それを組み合わせてWebページを作るというシステマティックなやり方をしています。ページごとにデザインするのではなく、パーツごとにデザインしたものを組み合わせてページを作るという考え方をデザインの段階からやっているんです」

「最初はみんな紙ベースというか、ペライチみたいなデザインで始めることが多いんですよね。紙って自由度が高いけど、文字や画像などのコンテンツをバラバラにすることはできなかったり、うまく区切れなかったりとか、Webとは考え方ややり方が違いますよね」

「逆にWebのやり方がわかっているデザイナーさんだと、『これは<h1>で』とか言ってくれたりするんですよ」

「あとは自分たちで共通部分を見つけてコンポーネント化していくとか」

サイトの構造やレイアウトデザイン、昔と今ではどう変わってますか？

「以前、コーディングは全然やらない人で完全にデザインだけやっている外部の人が、『こんな感じでよろしく』って送ってきたデザインが最悪だったことがあります。一方で、フロントエンジニア兼デザイナーをやっている人とやった時はすごくて、まずデザインの前にきちんと要件をはっきりさせてくれました。自分がちゃんと考えきれてなかったサイトの構造やボタンの位置にツッコミを入れてくれたりとか。みんながそれできるかっていうと厳しいですけど」

「今日登壇してる方たちもみんな通っている道ですね(笑)。めちゃくちゃのところからスタートして、だんだん良くなっていくという」

「それはあると思いますね。我々なんかの世代だとHTML3.2の時代からやっている人もいるので。以前はテーブルレイアウトというのがあって…」

「あー知ってます！昔やってましたよ、それ。一番最初にWebサイト作ったときに全部テーブルやりましたね」

「構造も何もあったもんじゃない(笑)」

「完全に見た目だけですよね。最近入社してきた若手なんかはテーブルレイアウト知らない世代でしたけど」

「ある意味うらやましいですね(笑)」

「昔はありだったんでしょうか」

「あるかなしかっていうと、なしだったんですけど。仕方がなかったっていうか」

「あれはフロートがなかったからとかそういうことだったんでしょうか」

「フロートがいつからあったかというのは難しい議論なんですけど、昔はブラウザのCSS周りの実装がボロボロだった時があって、IEでフロートすると横マージンが2倍になるとかありましたね」

「まぁ環境が整ってなかったというかんじですよね。だから一概にさっきの話も悪いとは言えないというか」

「Web標準が流行り出して、ブラウザの実装が統一されてきたのも、もう10年前くらいですね」

「モバイルが出てきてWebkitベースで確認できるようになって…」

「それ以前はもうぐっちゃぐちゃですよね」

「昔はできたデザインとマークアップした結果を重ねて、透過して1ピクセルもずれちゃいけないみたいな」

「ピクセルパーフェクトってやつですね！」

「聞いたことあります」

「昔は『全部のブラウザで同じ見た目にならないといけない』って時代があったんですよ。でも今はそういう時代じゃないですね、『デバイスによってちょっと違いますよね』ってのが当たり前になっているので」

「今はデバイスの種類がたくさんあるので、ピクセルよりも文字サイズはremとか、高さも%じゃなくてvwとか使うんでしょうか」

「状況によりますよね、使うべきときは使います。ちなみにそういう単位をどういうときにどれを使うのかという議論も、『インクルーシブHTML+CSS & JavaScript 多様なユーザーニーズに応えるフロントエンドデザインパターン』に書いてありますので、もしご興味があればぜひ！」

「ぜひ、勉強します！」

「CSSが一番難しいですよね」

「同じことを実現する方法が結構いくつもあって、でもやり方によって結果がかなり違ってくるとか」

「僕CSS書いたら1万行くらいいってしまったことがあって…。さすがにディレクターの人に『俺でも3分の1にはできるぞ、書き方おかしい！っていうか、全部に対してCSS書いてるじゃん』って言われたことがあるんです。その辺のベストプラクティスもあるんでしょうか」

「今はセレクターの値の設定やファイルの指定とか、いろいろな方法が考えられてます」

「CSSについても書いてありますか？」

「そこまで深くはないかもしれないですけど、それなりにCSSについての議論は書いてあります。楽しい本ですよ」

「ありがとうございます！個人的にはすっきりしてきました。なんかもやもやしてたことに明確に答えが返ってきて、なんだか気持ちいいです」

「そうですよね。他の人ととりとめない話をすることがすごく勉強になるみたいなこと、結構あると思うんですよ」

「いろんなカンファレンスありますが、純粋に技術の話できるというのは面白かったなあと思います」

UIを考える時に一番気をつけるべきことは何ですか？

「そろそろまとめというか『オチ』に入っていきたいので、最後に質問をさせていただきます。UIを考える時に一番気をつけないといけないことって何でしょうか」

「ユーザーのことを考えるというのが一番重要だと思います。これでユーザーが実際に使えるのか、どんなユーザーがいてどんな環境でどう使うのかを意識することが大事なことなんじゃないでしょうか」

「僕もユーザーですね。いろんなユーザーがいるということを、いかに自分の中で学ぶかということだと思います。一番いいのは、いろんなサービス使ってみたりして、自分がいろんなユーザーになれることですね。例えば、日本だと回線は速いけど海外だと遅いとか、性能の低いデバイスしか売ってないとか。こんな良い端末でこんないい回線使っている人は世界中にはそんなにいないですよと。そういったことを想像して、自分がユーザーとして変化できることも必要だと思っています」

「そのとおりですね！今日はとても勉強になりました。本当にありがとうございました！」

「ありがとうございました！」

しかし、2009年の「モバイルファースト」と、今の「モバイルファースト」は大きく中身が成長しました。モバイルフレームワークであるIonic 2も先日リリースされましたので、ここで改めて「モバイルファースト」とは何かを考え、モバイルの設計を見直していきます。

レスポンシブとモバイルファースト

モバイルファーストは、「モバイル環境に最適化した開発手法」と説明することができます。

モバイル（多くはiPhoneを指しました）は解像度が低く、操作方法もPC文化と異なり、かつ通信速度も遅いという制約があります。イベントひとつとっても、onclickでは待機時間があるから、jQueryのtapイベントを使う、というようにPCとモバイル開発の乖離をどのようにするかの課題があります。

モバイルファーストがいわれはじめた2009年当時は「PC版を作ったあと、MediaQueriesを使ってモバイルでも表示させる」というワークフローが主流でしたが、これではPCとモバイル開発の乖離にアプローチするのが難しかったため、「先にモバイル版をつくる」ワークフローを取り入れる現場が多く生まれました。PCよりもモバイルを優先させるので、「モバイルファースト」だったわけです。

その頃は、モバイルファーストとレスポンシブデザインの区別がつかない議論を度々聞きましたが、もうここらへんの誤解は整理された感があります。

Googleが提示する「次のモバイルファースト」

モバイルからのアクセスが主流になる中で、Googleは「次のモバイルファースト」として、2つの選択肢を提示しました。AMP（Accelerated Mobile Pages）と、PWA（Progressive Web Apps）です。

簡単に概要をいうと、AMPは超高速でWebサイトを表示することができます。HTMLやJavaScriptは高速化を妨げるものは使えなくなっており、またCSSはインラインのみでの表示でありと、ひたすらページ表示速度をあげるための仕様です。 PWAは「Webのアプリ化」を標榜したもので、インストール型のアプリと同様にWebを使うことができます。代表的な内容でいえば、Webをアプリとしてインストールしたり、オフラインでも表示することができたり、プッシュ通知を受け取ることができるようになります。

Googleはこの2つの仕様により、

• 普通のWebサイトなら、超高速化するためにAMP
• いろいろな機能を実装するなら、PWAでWebをアプリ化

という2つの「次のモバイルファースト」を提示しました。これは、今の「レスポンシブにしてモバイルで表示できればOK」から大きな変化であり、これからのモバイル体験を大きく変えるものになるのではないでしょうか。

UIデザインのモバイルファースト

PWAの標榜する「Webのアプリ化」は、UIデザインにおいても「次のモバイルファースト」を生み出す可能性が高いです。 皆さんご存知の通り、PCと（現在の）モバイル、そしてモバイルアプリはUI文化が異なります。PCとモバイルのWeb表示はレスポンシブデザインによって多くの共通化されたモジュールが使われていますので似通っておりますが（便宜上、これらを「現行WebUI」といいます）、モバイルアプリUIは別物に近いといっていいでしょう。

例えば、「現行WebUI」では、HeaderのロゴはクリックしてHOMEに戻るという文化があります。ほとんどがこのUIを採用しています。しかしながらモバイルアプリはHeader部にロゴは入れませんし、入れていてもクリックさせない場合が多いです。 また、「現行WebUI」ではクリックできる場所は明確にするしきたりがあります。例えばカードデザインでも下に「詳しくみる」と注釈をつけてクリックを促したりします。しかしながら、モバイルアプリUIでは「カードはとりあえずクリックしてみるよね」という風潮があります。

モバイルファーストで考えた時、Webがアプリ化する前提でのUIの再設計も必要になってくるでしょう。その時に、各デバイスが発表しているデザインガイドラインはとても有用です。

• iOS Human Interface Guidelines（日本語版）
• マテリアル デザイン
• Windows 10 アプリ UX デザイン ガイド（Modern UI）

AMPのように表示速度に最適化したWebはまた異なるUI文化が生まれてくるのでしょうが、「Webのアプリ化」を標榜するPWAはモバイルWebのUIもアプリサイドに寄せていくことになりそうです。 　

デバイスの作法に寄り添うために

WebのUIもアプリサイドに寄っていくことを考えた時、一番大きなハードルになるのは前挙した「各デバイス毎のデザインガイドライン」をどのように吸収するかです。モバイルでは、デバイスの文化に寄り添うUI設計が最もユーザの学習コストが低く、適切なUI,UXを提供することができます。iPhoneはフラットデザイン、Androidはマテリアルデザイン、WindowsPhoneはModern UIを提供するために1リソースで複数デザインパターンを用意して保守し続けることはハードルが高く現実的ではありません。

そのハードルに対して、適切にソリューションを提供してるモバイルフレームワークのひとつに、Ionic 2があります。

Ionic 2は、2017年1月にリリースされた、Angular 2を使って構築するモバイルフレームワークです。現在、（著者が確認する範囲では）唯一のPWA対応を標榜したモバイルフレームワークとなっております。

Ionic 2のWebComponents

よくモバイル開発で使われるComponents（CardやFabitなど）を、フラットデザイン、マテリアルデザイン、Modern UIのパターンを用意し、フレームワークが判断して自動的にデザインをデバイスに合わせます。

Ionic 2は、デフォルトで用意しているUIパターンは、複雑になりがちなHTMLを「Web Components」という技術によってカスタムタグを用意して、コーダーの負担を減らす工夫をしています。例えば<button ion-button>Login</button>というボタンがあると、これをフレームワークが自動的に展開して、ユーザには

<button block="" ion-button="" class="button button-md button-default button-default-md button-block button-block-md">
    <span class="button-inner">Login</span>
    <div class="button-effect" style="transform: translate3d(392px, -91px, 0px) scale(1); height: 240px; width: 240px; opacity: 0; transition: transform 552ms, opacity 386ms 166ms;">
    </div>
</button>

と表示されます。手元のソースコードはシンプルですので、可読性が高く、またデバイス毎の表示に困ることはありません。2017年3月現在、28のコンポーネントがデフォルトで用意されています（コンポーネント一覧は公式リファレンスをご覧下さい）

また、フレームワークが直下に<ion-app>というタグを生成してくれており、そこにデバイスを示すclass（iPhoneだとios、Androidはmd、WindowsPhoneはwp）をつけてくれます。なので、もしも自分自身でカスタムデザインを用意したい場合、それを親にしてCSS設計することが可能です。

Ionic 2のオフライン表示

GoogleのPWAのガイドラインの中で「Progressive Web App Checklist」を提供しています。Webをアプリ化するために、これだけはクリアしてねというチェックリストです。

その中で「オフラインでも表示される」というものがあります。普通のWebサイトでは、キャッシュを持っていてもオフライン環境で更新すると「オフラインです」とエラーがでます。しかしながら、Service Workerという技術を使うと、オフライン環境では自動的にキャッシュを返すことができます。

オフライン対応を有効するのはとても簡単で、src/index.htmlの17-24行目のコメントアウトを外すだけです。

<script>
    if ('serviceWorker' in navigator) {
      navigator.serviceWorker.register('service-worker.js')
        .then(() => console.log('service worker installed'))
        .catch(err => console.log('Error', err));
    }
  </script>

このことによって、Service Workerが対応している場合はservice-worker.jsを読み込み、オフライン対応が行われます。回線が安定してるPCとは異なり、トンネルの中であったり山中であったりでも安定してコンテンツを提供するためには必須の機能です。
Ionic 2では、sw-toolbox.jsを利用しておりますので、詳細に興味がある方は「sw-toolbox」をご覧下さい。拡張すれば、いろいろなオフライン時の挙動を制御できます。

Ionic 2のmanifest.json

PWAでは、Webをアプリストアのアプリ同様にHOME画面にアイコン付きで登録することができます。manifest.jsonは、その時のアイコンであったりとか、起動した時のヘッダー部の配色であったりを定めることができます。 初期では以下の通りです。

{
  "name": "Ionic",
  "short_name": "Ionic",
  "start_url": "index.html",
  "display": "standalone",
  "icons": [{
    "src": "assets/imgs/logo.png",
    "sizes": "512x512",
    "type": "image/png"
  }],
  "background_color": "#4e8ef7",
  "theme_color": "#4e8ef7"
}

これを設定すると、Androidで表示された場合に自動的に「ホーム画面に追加」というバナーがでてきて、ユーザに対してWebをアプリとして扱うことを提案することができます。

他のProgressive Web App Checklist

他のProgressive Web App Checklistは以下の通りです。Webをアプリとして扱うことを考える時に、ぜひご配慮下さい。

• SSLで提供されている
• モバイルに表示が最適化されている（レスポンシブデザイン）
• 10秒以内に最初のページが表示される
• Chrome、Edge、Firefox、Safariで動作する
• 各ページはURLを持っている

おわりに

GoogleがAMPとPWAというふたつの選択肢を提示しました。これは、既存のモバイルから設計するデザインワーク中心の「モバイルファースト」から、モバイル体験中心をWebを中心として再設計する新たな「モバイルファースト」を生み出す可能性を秘めています。Webの設計、デザイン、技術の大きな見直しの転換点となるのではないでしょうか。 そこで、ぜひともいちはやく「PWAのサポート」を発表したIonic 2を試していただき、この流れとWebのこれからを体験していただければと思います。

Ionic 2 の日本語コミュニティあります

今では随分改善されましたが、Ionic 2はリリース前（特にβ版時代）はとても日本語情報が少なかったので、知見を共有するためにslackのオープンチャンネルを開設しました。分かる方がいれば有志が回答する形ですのでレスポンス速度はあまり高くありませんが、ご活用いただけましたら幸いです。

Ionic 2 slackチーム

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

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

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

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

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

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

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

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

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

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

1. Side Navigation

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

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

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

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

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

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

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

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

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

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

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

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

2. Swipeable Cards

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

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

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

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

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

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

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

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

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

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

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

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

}

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

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

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

  } else {

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

  }

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

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

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

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

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

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

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

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

  }

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

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

3. Expand and Collapse

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

この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デザイナーは不要どころか、今後ますます求められる存在となることがわかった。ビジュアルデザインが得意なら、開発側からも転身ができる。これからの注目の職種と言えるのではないだろうか。

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月17日、日本マイクロソフトの品川本社オフィスにて、第45回HTML5とか勉強会を開催しました。今回は「ユーザーエクスペリエンスとペーパープロトタイピング」というテーマで、安藤幸央さんのご講演およびワークショップといういつもとは違った試みを行っています。

参加枠も100人の定員がすぐに埋まり、140人もの応募がありました。普段のHTML5とか勉強会に比べると、デザイナーの方の参加率が高いことが印象的ですが、エンジニアの方も興味を持って参加されていて、職種を問わず多くの方が興味を持っているテーマだということを感じました。

前半はスライドを見ながら　「ユーザーエクスペリエンス」に関してご講演頂きました。
まずは有名なサイトのプロトタイプを見て、どのサービスのプロトタイピングかを考えるということから始めました。

プロトタイプ制作でのポイント

今回は紙を使用してプロトタイプを作成します。
なぜ紙で作るのでしょうか？紙で作成すると以下のようなメリットがあります。

紙とペンでの試作のメリット

• 素早くできる
• コストが少なくてすむ
• やり直しが簡単
• 失敗してもリスクが少ない
• でき上がった感じがしない （ Photoshopだとでき上がったと勘違いされやすい）
• 余計なことを作り込めないので重要な所に集中できる
• 目と指で感じる感覚を得られる
• 紙とペンは潤沢に使えるツール

逆に欠点としては、

• また完成していないので、想像しながら試す必要がある
• アニメーションは確認できない
• 理解するのには空想力が必要かもしれない

等の欠点があるそうです。

プロトタイプの法則

それでは実際にプロトタイプを作成する場合の法則には、どのようなものがあるでしょうか。

1 画面を見直すと気づきがある

画面を見直すといろいろなことに気づきます、普段アプリなどを使っていて使いづらい、使いやすいシーンがあったら、なぜ使いやすいのか・使いづらいのかを分析してくことで気づきが生まれてきます。

2 道具にこだわろう

例えばクロッキー帳やポストイット、インターネットで入手できるUIテンプレート、ペンなどの道具や、ペンの太さを2種類に変えて、押せる部分と押せない部分をわかりやすく表現するなどTIPSなど。実際に安藤さんが使用されている用紙が文具を見本にわかりやすい作り方のポイントも解説されました。

3 アウトプットの質はインプットの質と量に比例する

良いものを作りたいのなら、いいものをたくさん見るーつまりアプリの場合はたくさんのアプリをみて使ってみることが大事です。

例えば「モバイルウェブの見本を集めているサイトなどを見て、自分の気に入るテイストや案件に合うサイトを調べてみる」、「アプリストアのランキングなどをチェックしなぜ人気なのかを考える」こともおすすめだそうです。

安藤さんの情報収集方法として、実際に参考となるサイトをスマホでキャプチャしたあとに、インターネットの書籍作成サービスで自分のミニ本を作成されているのだとか。クライアントの打ち合わせ時に手軽に見せて打ち合わせをしたり、手軽にまとめてみられるのが便利なのだそうです！

安藤さんのMinibook

アンテナを研ぎすませて新しいことを常にキャッチする姿勢とともに、自分の仕事やスタイルに合わせて、情報のまとめ方や生かし方を工夫することも、質を高めるために必要なことだと感じました。

4 素早く試して、素早く失敗しよう

5 本当に大切な2.3の機能を作ろう

すべての機能をたくさん試すよりも、まずそのアプリの中で重要な2つ3つの機能から考えてみることが大切です。

6 凝りすぎない。作り込みすぎない

紙で書くだけで大雑把で、ここに時間をかけすぎて開発時間が減るのは本末転倒です。素早く試しましょう！

7 完璧を目指さない、失敗を受け入れる

どんな人でも失敗するのは当たり前。早く失敗して良かったと考えましょう。

8　実際の環境で検討するのが重要

実際にスマートフォンで画面表示を試すにしても、会社のデスクで試すのではなく、会社の中を歩き回りながら使うだけでも違います。

例えば　車関係のアプリであれば実際車の動いている時や乗り降りに使うので、その環境に近い状況で試してみることが重要です。

9　客観的に見る、時間をおいて見る

使うであろうユーザーの立場に立って切り替えてみてみることが大切です。また、ずっと開発やデザインをしているとゲシュタルト崩壊というのか、良いのか悪いのか判断がつかなくなることがあります。その場合は時間をおいて確認しましょう。

10　素晴らしい試作も、本物ではない

リソースをかけすぎない。試作は試作と割り切って、ある段階になったら次の段階に進めるように考えると良いと思います。

手を動かしてわかる、プロトタイピングの効果

後半では2～3人でチームを作成し、自己紹介タイムの後にプロトタイプ作成に入りました。 テーマサイトは「Esty.com」通販サイトです。

PC用のサイトを見ながら要素を10個以上書き出しました。その中からスマートフォン用に表示させる内容を選んで行きました。まず各々がPICK UP！　そのあとチームで話し合って意見交換。

最後にチームの中から一人代表を選んでコンセプトと合わせて発表します。
それぞれのチームごとにさまざまな解があり、そのコンセプトを聞くことで自分の考えに凝り固まらずに、気づかなかった視点を認識します。

各チームのプロトタイプを見た後に、Esty.comの実際のスマホサイトが実際にどのようになっているかを確認。各々のプロトタイプとの違いを確認し合い、イベントを終了しました。短い時間でしたが、プロトタイプ作成でのポイントから考え方、制作まで体験することができ、続きもぜひ作りたいという声も聞かれ、有意義な時間となりました。

イベントの動画はこちら

イベント資料はこちら

デザイニアンプレイベントのご報告とVOL2のお知らせ！

最後に今回のHTML5とか勉強会・チューターの秋葉秀樹さんより、1月に行われたデザイニアンプレイベントを動画を交えながら報告、そして次回のイベント開催の告知が行われました。（プレイベントのレポート記事はこちら）

このイベントでは実際のサイトをテーマにHTMLのテンプレートを使用しエンジニアとデザイナーがチームを作りプロトタイプを作成します。3/22（土）に開催です、ぜひご参加ください！

＜デザイニアン 002＞

• 開催日:3/22（土）
• 開催時間:12:00会場 12:30より開催予定
• 定員:デザイナー15名 コーダー／プログラマー（ノートPC持参）15名　計30名
• 会場:メディアテクノロジーラボ（日比谷、銀座）
  　　　 東京都中央区銀座7-2-6 リクルートアネックス1ビル B1F　MAP
• イベントの詳細はこちらで紹介しています

2014年1月12日、株式会社ツクロアの事務所にhtml5jデザイン部スタッフが集まり、3月開催予定のイベントの打ち合わせを兼ねたプレイベントを行いました。どのようなチームで、どのように課題サイトの設定やテストを行ったのか。イベントの予告を兼ねたレポートをさせていただきます。

「デザイニアン Vol.2」で目指すもの

デザインという言葉から想像するものはどんなものでしょうか？

一般的には多くの方がPhotoshopやFireworksで作成したデザイン画像を想像されるかもしれません。しかしデザインとは「画面の意匠」という意味だけではなく、ユーザーが抱えている課題を解決するために思考や概念を組み立て、展開する媒体に応じた表現をし、さらなる問題解決を図ることです。

WEBやスマートフォンのアプリの場合、ユーザーが操作することで目的に到達します。つまりサービスから得られる体験を設計する事もデザインに含まれています。

Webデザイナーの通常業務の中で納期や予算の関係などから、プロトタイピングを制作し検証する機会がない方も多いのではないでしょうか。このイベントではサンプルとなるサイトを課題にして現状の問題点を分析し、プロトタイピングを作成し「ユーザー体験」まで含めた設計を行う、これが今回のイベントが目指すところです。

プレイベントの流れ

課題のサイトは、一般の利用経験者が比較的多いと考えられるJRの新幹線予約サイト「えきねっと」に設定しました。新幹線の予約を課題にいかにスムーズに情報を伝え、目的となるチケット購入までたどり着けるかをテーマに、

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

の流れで進めます。

1. 課題のサイトの問題の洗い出し

課題のサイトは、一般の利用経験者が比較的多いと考えられるJR東日本の新幹線予約サイト「えきねっと」に設定しました。

新幹線の予約を課題にいかにスムーズに情報を伝え、目的となるチケット購入までたどり着けるかをテーマにします。

まずは、デザイン部スタッフ一同で課題サイトの問題点を洗い出します。

• 目的の切符を買いづらい、
• 空席情報がわかりづらい、
• 往復チケットが買えない、
• 動線がわかりづらい、
• 押す場所がわからない、

など、さまざまな課題が見つかりました。

デザイン部スタッフが課題をテストしながら、同時にイベントの進行や時間配分、参加者の方にやっていただける内容・段取りも検討していきました。

2. 情報整理と仮説

次に課題サイトの情報を付箋に書き出して細分化し整理分類します。

その中から必要な機能や不要なものを取捨選択しカテゴライズしながら、目的への流れの中で発生するユーザーの動きを考えていきます。

3. プロトタイプ作成

フロントエンジニアとデザイナーが担当ごとに分かれて、プロタイプを作成していいきます。プロトタイプを作ることで トライ＆エラーを素早く繰り返すことができ、”自分たちの分析した内容が正しいのか？”をより早く検証することができます。

4. ユーザーテスト

サービスを作る時、誰のためのサービスを考えて、使用する人の目線で問題解決することが必要になります。しかし、制作に携わる側は開発しているサービスに慣れてしまい、ユーザーの目線でとらえられなくなります。

設定ターゲットに近い2名の方に来ていただいてプロトタイプの検証を行います。

• Aさん（女性　ITリテラシーは低め　新幹線には乗るが、予約サイトでのチケット購入経験はなし）
• Bさん（20代男性 普段はiPhoneを使用する程度の利用。Webサイトでの購入経験はなし）

課題の「えきねっと」と合わせて、JR西日本の新幹線予約サイト「JRおでかけネット」も比較対象として検証します。さらに新幹線の乗車券と特急券を、提示した2パターンで予約を取ってもらい、その手元の動きを動画で撮影します。

5. ヒアリング

サイト検証の終了後は、録画した動画を見ながらレビューを行います。どの段階で操作が詰まったか、何がわかりにくかったのか、コントリビューターのお二人に細かく説明していただきました。

操作中の声も記録されているので、言葉からも何を迷っているか把握できました。

• ボタンかと思っておしたらアイコンで、操作に迷った。
• 一見しただけでは指定席を取っているかがわからなかった。
• ボタンの色が赤だったので警告なのかとおもったら違っていた。
• ボタンのテキストを「確認する」など次の動作がわかる言葉に変えた方が押しやすい。

etc — たくさんの問題点が浮き彫りになります。私たち制作に携わる側が当然だと思い込み、気がつかなかった点や問題点、予想していなかったユーザーの行動など知ることができました。

“求める解に近づく力を体験から培う”イベントに参加しませんか？

この日のプレイベントはこちらで終了しましたが、スタッフは引き続きイベントに向けて準備を続けています。

3月開催予定のデザイン部イベント「デザイニアン Vol.2」では、エンジニアとデザイナーがチームを作り、スタッフの行ったプレイベントと同じ流れで課題サイトのプロトタイプを作成し、ユーザーテストを行います。仮説を立て試行錯誤しながら一緒に考えるイベントです。

みなさんも一緒に学びませんか？

イベントの詳細は以下です。募集に関してはhtml5jのメーリングリスト（ML)にてお知らせします。 ご興味のある方はぜひご参加ください！！！

• イベント名：　デザイニアン002
• 開催日：　3/22（土）
• 開催時間：　昼12時会場 12:30より開催予定
• 定員：　デザイナー15名　・　コーダー／プログラマー15名　計30名
• 会場：　メディアテクノロジーラボ
• 会場住所：　東京都中央区銀座7-2-6 リクルートアネックス1ビル B1F　http://mtl.recruit.co.jp/access/
• 参加資格：　スキルは問いませんがワークショップがあります
• イベントの募集について：　html5jメーリングリストでお知らせします

タイムテーブル：

• ◎チーム編成　…　13:00〜13:30
• ◎ワークショップ　…　13:30〜18:00
• ◎ユーザー評価　…　18:30〜20:30
• 終了後、任意参加で打ち上げ

「HTML5 Conference 2013」では「モバイルフロンティア よりよいモバイルUXを生み出すためのデザインガイド」を翻訳したメンバーによる、ユーザーエクスペリエンス講座「モバイルフロンティア：フロントエンジニアとデザイナーのためのモバイルユーザーエクスペリエンスのセッションが行われた。

2013年4月に発売された「モバイルフロンティア　よりよいモバイルUXを生み出すためのデザインガイド」は、モバイル中心の世界が急速に変化しつつある今、既存のサービスの焼き直しや単なる移植ではない、モバイルならではのユーザー体験を創り出すための指南書だ。

ただ「つくる」だけでなく良い体験をデザインすることが重要な開発フローと認識され始めている近年、ネイティブアプリ・Webアプリ関係なく「体験のデザイン」を考えるテーマとして注目されている。今回のセッションでは、実際に翻訳を担当したメンバーが、内容を構成する1～9章それぞれの中身に関して、簡潔に紹介してもらったので、そのダイジェストをまとめた。

1章いかりを上げる 2章モバイルNUIパラダイムの登場
────────────────────清水かほる氏

昔の携帯は、機能拡張を繰り返すうちにいわゆる「ガラパゴス携帯」と揶揄されるようになったが、実は開発側にとっても制約が多く発生したり、開発環境が複雑化することで開発しにくいものになっていった。そこに登場したのが「iPhone」などのスマートフォン。必要最小限のアプリや直観的UIといった、ユーザーにとって非常に使いやすい新たなデバイスの登場は、開発側にとっても制約のない理想的な開発環境が出現した。いわば「モバイル黄金時代」が本格的に到来したといえる。事実、デスクトップからモバイルに世の中のトレンドは大きく移行しているのだが、両者の開発環境に関して改めて比較したい。

• デスクトップ───標準化が進んだ入力手法　学術的研究結果が豊富　開発者やデザイナー
• モバイル───まだ上記のような開発環境がない上、デスクトップ環境での開発手法が使えない

このようにそれなりの歴史の中で培ってきたノウハウを生かせるデスクトップ環境と比べ、モバイル環境はこれからルールを作っていかなければならない。この状況はとらえ方によっては「苦労」ではなく「チャンス」があるといえる。すなわちそのチャンスこと、本題になっている「モバイルフロンティア」というキーワードに結びついているのだ。

• モバイルNUIパラダイムの登場───これまでの開発手法は、3つの段階を経ている。

＜第1段階＞
●コマンドラインインターフェース（CLI）
●コマンドを覚えて、テキストベースのインターフェースに打ち込む

＜第2段階＞
●グラフィカルユーザーインターフェース（GUI）
●ユーザーにコマンドを見せて選ばせる
●フォルダなどオフィスをまねたメタファーを利用することで親しみやすいUIを実現

＜第3段階＞
●ナチュラルユーザーインターフェース（NUI）
●ユーザーの状況に応じて表示される情報が変化
●タッチパネル操作が可能

現在、第2段階のGUIと第3段階のNUIの間にいるが、その理由としてまだNUIに対応できてないユーザー多いことが挙げられる。スマートフォンやタブレット端末の急速な普及でNUI環境が普及している一方、まだGUI環境に慣れた考え方が多い状況だ。

3章_デンバーのピーナッツバター
────────────────────脇坂善則氏

モバイルデバイスは、根本的にPCとは利用体験が異なる。トイレや電車の中、はたまた教会など「いつでも、どこでもつながる。つかえる」ことが前提。また何かをしながら使える、つまり「ながらつかえる」ということを前提にデザインする必要がある。それが「モバイルならではの体験にフォーカス」するということ。

例えば、その場で流れる音楽を聞かせて検索することで曲名を調べるといった、音声入力。カメラ機能を利用して撮った画像をその場でアップ、共有。現在地から検索する位置情報入力。一方で、モバイルならではの体験によるデメリットとして、注意が散漫になったり、行動がさえぎられることが挙げられる。

そこでそうした認知的負荷・機会費用を減らすためのデザイン、つまり「モバイルUX」を新たに創っていくことが今、求められている。

4章_形態の変化
────────────────────羽山祥樹氏

モバイルユーザーは、常に「つながりの中」にいる。これまではこちらが提供するサービスや機能に対して、ユーザーが理解した上で、使いこなす。つまりユーザー側がサービスに合わせてくれていたが、モバイル環境の今、「ユーザーが何かしたいことの途中にあなたのウェブサイトがある」。つまり「コンバージェンス」な状況で、使われている。

また「エコシステム」と呼ばれる様々なものがつながって価値を生むのがモバイル環境の大きな特徴。

• 一人もいないフェイスブック
• 一人もフォローしていないツイッター
• 接続できないネット

これらはそれがどんなに高機能かつ良質なサービスであったとしても、つながっていなければ意味をなさない。iPhoneが多くのユーザーから支持されたのも、デバイスとしての機能だけではなく「アップルストア」という存在が大きかった。

デバイス・アップルストア・アプリ開発者・ユーザーすべてがつながることで、価値が生まれる。そのため、モバイル環境におけるデザインを考えたとき、誰もが利用しやすい「参加型デザイン」が望まれる。

5章_モバイルUXパターン
────────────────────野澤紘子氏

モビリティのためのデザインには大きな特徴がある。モバイルは決して「小さなPC」ではない…「PC」は積むデザイン、「モバイル」はデザインパターンを広げることにある。

• コンテンツがＵＩになる──────NUI（ジェスチャーとスーパーリアル）

その上で、モバイルならではの入力方法（カメラ、QR、加速度センサ、GPSなど）を活用するUXが必要。これまでPCなどを利用する目的は、何か作業することがメインだった。しかしモバイルを利用する目的は、「使い続けること」。それによって価値が増えていく。

そこでユーザー視点でついついいじりたくなるような感覚を察し、ユーザーの状況に応じて適切なアウトプットを創り上げていく必要がある。

6章_モバイルプロトタイピング
────────────────────佐藤伸哉氏

「アイデアが広がる」→「アイデアを実現する」。この間でプロトタイピングが行われる。未知の探求や、ユーザーフィードバックの収集、デザインアイデアやエクスペリエンスの伝達共有、アイデアの微調整等の目的で行われるプロトタイピングには、大きく2つの方法がある。

• 戦術的プロトタイピング──スケッチ　ペーパープロトタイピング、実機上でのインタラクティブプロトタイプ
• 体験的プロトタイピング──ストーリーボーディング、ボディストーミング、スピードデート法、コンセプトビデオ

その中でモバイルプロトタイピングを成功させる条件、それは「適度な忠実度で行う」というもの。

• 完璧主義者にならない　
• 失敗を受け入れる　
• 勇気をもって次のアイデアに進む

つまりプロトタイピングは万能薬ではないということを認識した上で取り組むことが重要だ。

7章_モーションとアニメーション
────────────────────安藤幸央氏

世界中の人に愛されるディズニーのアニメーションには、UI UXの向上の観点から、「命を吹き込む魔法」が存在している。

例えばスクロールの動かし方一つとっても、「少しずつ動き出し、徐々に加速。その後少しずつとまる」といったような動かし方。また動かす直前に少しだけ後戻りする「予備動作」をつけることで、感覚的に「これから動くんだ」とユーザーが予測できるので、よりスムーズに操作できる。このような手法は「アンチシペーション」や「ステージング」等現在、主なもので12の手法がある。 　 他にも実際にどういう動きをすると見やすいか？
ディズニーアニメで検証するのは非常に効果的。こうしたアニメの原則をモバイルUI・UXに活かす方法として、以下のようなものがある。

• いいアプリたくさんさがし、使い込むことで事例の引き出しを増やす
• いいものがいいのか？要素分析・分解
• 常用するアプリが更新されたら、前のバージョンとどこが変わったか比較

8章「感覚の目覚め」／9章「新しいモバイルの形」

またほかにも「第8章 感覚の目覚め」では、タッチやジェスチャー、音声などこれまで主に利用してきた「視覚」以外の感覚を活用することで「より押しやすい」「タッチしやすい」コンテンツ制作が求められること。

「第9章 新しいモバイルの形」では、腕時計型やペン型などモバイルデバイスの新しい形の登場や、モバイルが銀行の代わりになるなど、「コンピュータと身体・環境との境界」が明らかに変わってきている点が紹介された。