この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アーカイブ」

この記事は、「Frontrend Conference The Final」の基調講演「Pragmatic Front-end Developer: From Artisan to Expert」についてのレポートです。

登壇されていたのはリッチメディアの斉藤祐也さん。HTML5 Experts.jpでも、No.10のエキスパートとして何度もご執筆いただいているので、ご存じの方も多いかと思います。

この講演タイトルは、アンドリュー・ハント氏の著作「The Pragmatic Programmer」をオマージュしたとのこと。「Pragmatic」というのは「実践的」という意味の単語で、フロントエンドという広大な分野における道標となるような、実践的なノウハウをたくさん紹介していました。

この記事は、斉藤さんの講演を聴講した筆者が、自分なりの言葉で内容をまとめてみたものになります（斉藤さんの言葉をそのまま書き起こしたわけではありません）。この講演のスライドはSpeaker Deckにて公開中です。そちらも合わせてご覧いただければ、より理解が深まるかと思います。

キーワードは「CARE」！

この講演におけるキーワードは、以下のトピックの頭文字を取って「CARE」。講演自体も、以下のトピックの順番に沿って進められていましたので、この記事もその流れに沿って書いていきたいと思います。

• Be Collaborative (問題は人と人の間にある)
• Be Adaptive (変化に対して寛容に)
• Be Responsible (作ったものに対して責任を持つ)
• Be (an) Expert (知ることに対して貪欲に)

Be Collaborative (問題は人と人の間にある)

HTML, CSS, JavaScriptといった技術は、専門家でなくても書けてしまうという気軽さがある代わりに、メンテナンス性に優れているとは言えません。ただ、そうしたテクノロジーは日進月歩です。メンテナンス性に欠ける、という弱点を補足すべく、様々な進化を続けています。そうした状況においては、コラボレーションにおける問題はテクノロジーそのものではなく、人と人の間にあるのです。

例えばコラボレーションを円滑に行うためには、コードスタイルのガイドラインが必要です。理想は、一つのコードベース上のコードは、一人の人間がタイプしたかのように見えること。そうした理想を追求するためのスタイルガイドとして、以下のようなことが挙げられます。

JavaScriptのコードスタイルガイド

JavaScriptのコードスタイルガイドについては、以下を参照するとよいでしょう。

• idiomatic.js
• jQuery Core Style Guidline
• Airbnb JavaScript Style Guide

CSSのコードスタイルガイド

CSSのコードスタイルガイドは、以下に挙げられたことが参考になります。これらのうち、どのガイドラインが優れているか、は問うべきものではありません。「自分たちのプロジェクトに、スタイルガイドが存在する」ということがまずは大事なのです（実際、セッション参加者に「コードスタイルガイドラインをお持ちの方」を聞いたら、1割程度だったそうです）。もしないのなら、これらを元に自分たちなりのガイドラインを定義するとよいでしょう。

• idiomatic.css
• CSS Guidelines
• Sass Guidelines
• Code Guide

コードスタイルチェックを自動化するツールたち

上記のようなコードスタイルガイドラインに準拠しているかどうかを、人間が目で見てチェックするのは容易ではありませんし、時間の無駄です。「貴重なレビューの時間を、コードスタイルチェックに費やしてはいけない」という斉藤さんの言葉は、非常に重みがありました。

• EditorConfig
• JSCS
• CSS LINT
• CSScomb

包括的なスタイルガイド

また様々な企業が、自分たちが使っている包括的なスタイルガイドを公開しています。上記のコードスタイルガイドよりもより粒度が粗く、実際のユースケースに沿った形で定義されていることも多いので、参考にするとよいでしょう。

• GitHub styleguide
• Starbucks style guide
• MailChimp Style Guide
• Website Style Guide Resources

ドキュメンテーションのためのツール

また開発者であれば、「ドキュメントは嘘をつく」という言葉には、深く同意せざるを得ないでしょう。 日々変更されていくソースコードに対して、ドキュメントはどうしても更新が追いつかないという状況に陥りがちです。以下のツールは、CSSのドキュメンテーションツールのうち代表的なものです。これらのツールを使えば、コードとドキュメントが、常に同期されているという理想的な状況を目指すことができます。

• KSS
• KSS Node
• hologram

プロトタイピングに役立つツール

また、コラボレーションを行う上で重要なのは「実際に見えるもの、動くものに対しての意見は言いやすい」ということです。貴重な時間をムダにしないためにも、まずはさっさと動くプロトタイプを作ってしまい、それを元に議論を進めましょう。

斉藤さんがオススメする「プロトタイピングに役立つツール」は以下になります。

• BrowserSync・・・コードとブラウザ、もしくは異なるデバイス上で実行中のブラウザの状態を同期してくれます。開発時の結果確認が非常に迅速になるだけではなく、デバッグやプロトタイピングの用途にも活躍します。
• JS Bin・・・HTML/CSS/JavaScriptのコードをWebブラウザ上で記述し、共有できるサービスです。
• Google Chrome Canary・・・言わずと知れた、Google Chromeの最新＆安定性が保証されていないバージョン。斉藤さんによれば、「打ち合わせ中、ブラウザでダイレクトにお客様のご要望をコーディングしていき、その反応を得るのはとても楽しい時間」とのこと。

Be Adaptive(変化に対して寛容に)

様々なスクリーンサイズやデバイス上でWebサイトが利用されることは既に当たり前で、プログレッシブ・エンハンスメントの重要性はこれまでも何度も取り沙汰されてきました。

斉藤さんはプログレッシブ・エンハンスメントの考え方について、エスカレーターの例えを用いて説明されていました（とてもわかりやすい！）。

エスカレーターは、例え止まってしまったとしても階段として機能するため、「違う階に人を運ぶ」という機能自体が失われることはありません。

一方エレベーターは、止まってしまうとただの箱。この違いが、プログレッシブ・エンハンスメントを実践しているサイトとそうでないサイトの差に近いものがあります。

なぜこれほどまでにプログレッシブ・エンハンスメントが重要かというと、Webは（ある形の決まった）プラットフォームではなく、継続して変化し続けているあやふやなものだからです。ブラウザも、デバイスも、ネットワークも、将来的には全く違ったものになっているかもしれないのです。

この変化し続けている環境では、しっかりと自分の哲学を持ってディテールにこだわりを持ちつつも、前提条件が変わった時にそのこだわりを潔く捨て去ることが、優秀なエンジニアには求められているのです。

Be Responsible(作ったものに対して責任を持つ)

そして、これまで紹介してきた様々なスタイルガイド、ツール、プログレッシブ・エンハンスメントといったものは、技術者が自分の作ったものに対して責任を持つために必要不可欠なものです。

Webという常に進化し続ける環境において堅牢なプロダクトを作ること、そしてその堅牢さに常に疑問を抱き、「もし」をしつこいくらい重ねること。それらを手助けするのが上記のツールだというわけです。

また、プロダクトの堅牢さという点では、パフォーマンスは非常に重要です。例えば著名なMVCフレームワークがパフォーマンスに与える影響を調べたこちらの記事によれば、初回ロードにかかる時間が1,000msを下回ったものはなかったそうです。

Webアプリのパフォーマンス改善に関する取り組みは、様々なところで行われていて、例えばEmber.jsはfastbootという仕組みを提唱していたり、Flipboardが採用したReact-Canvasは、ReactによってDOMではなくCanvasにレンダリングするという仕組みで、ネイティブと比べても遜色ないくらい高速な描画を実現しているそうです（ただし、当然ながらアクセシビリティは一切考慮されておらず、それが議論を呼んでいるとのこと）。

Be (an) Expert(知ることに対して貪欲に)

「CARE」の最後は、「エキスパートになろう」ということ（HTML5 Experts.jpとしては、応援すべきフレーズとしか言いようがありません）。以下の様なことを普段から心がけて常に知識を取り込み、エキスパートを目指しましょう。

• 「できない」と言わない。オプションを提示する。
• 壊れ窓の中で仕事をしない
• 「十分」がいつなのかを知る
• 知識を増やすための時間を定常的に設ける

フロントエンドはこれからも重要であり続ける！

講演の最後に、斉藤さんは「フロントエンドはこれからもWebに必要とされるのか？」という問いかけに対して「YES!」と力強く答えていました。

Webという環境は変化しますし、ビジネスの世界もめまぐるしく動いている中、フロントエンド技術者の仕事もどんどん変化していくことは避けられません。ですが、「フロントエンド」という分野の重要性そのものは、これからも高まり続けることでしょう。

フロントエンドはどこにもいかない！

イベント動画

イベントの模様はYoutubeで公開されています。よろしければ、ご覧ください。

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
• 終了後、任意参加で打ち上げ