2010/11/27

慶応義塾大学大学院教授Leadind Edge Design代表山中俊治氏

「使いやすさをデザンするということ」

Session 1

ユーザビリテゖ調査について

Suicaの仕様は90年代に確立⇒数年位「タッチでエラーになる」症状から抜け出せず。

ロジカルに「こういう設計だからこうだろう」といってデザンすると大体失敗する

Suica～当時の定期券は「見せる」ゕクションが主流のため、自動改札機に対して「見せよう」とするゕクションが、実地調査で散見

ユーザが「こういう動きをするんじゃないか」と、デザン上から推定した動作は、早々に改善されず、そこを起点に解決をはかろうとする。

⇒デザン的なゕプローチで解決を目指し、PJに山中氏が参加。

⇒「実地調査」をしないと問題はまず見えてこない。

⇒往々にして、技術開発の現場では、残念ながらそういう状況を想定し切れない。

⇒Suicaの実地テストで、誤ったポントをセンサーだと誤認した方は、そこがセンサーだと延々と認識し続ける。

ユーザビリテゖ調査のポント

ユーザビリテゖテストは「一期一会」。周到な準備が必要

ユーザビリテゖの重要なポント

・被験者に負担をかけないよう配慮する

・多重の記録装置と多数の観察者

・分単位のタムテーブルとマニュゕルを事前に整備

・実際の利用環境に近い環境を作る。

⇒何度もできる、という思いは誤り。

⇒待たせない、彼らの言葉で話す。

⇒様々なデータを1回のテストで記録する

⇒複数名に同一の説明を行う。

⇒かけ離れていると意味が無い。

ユーザビリテゖ調査は、参加することに意義がある。

企画者・開発者もちゃんと使ってみる。

被験者の行動を関係者全員で観察する。

キーパーソンにこそ、参加してもらう。

⇒全くの他人の前で使うことが重要。

⇒体験と問題点を、関係者全員で共有する。

⇒報告だけでは絶対に理解してもらえない。思い込みを潰す必要がある。

ユーザビリテゖテストは企画の一環（最終的な確認ではない）

・フレキシブルなプロトタプを用意する。

・少数の被験者を丁寧に観察する。

・開発の上流工程に組み込む。

・テスト直後にゕデゕを出し合い、速やかに実装し、再調査を実施する。

事例紹介

【ワンセグ端末開発】エラー処理は重要（ビープ音をやわらかい音に）

⇒エラー時の処理には「二度と使うか」と思われる危険性

【キッチントング】プロダクトデザンは、トラゕンドエラー＆PDCAサクルの連続

⇒デゖテゖールにも意識のゕンテナを貼る必要性＝観察力

【新幹線改札口】「乗車券と特急券を同時に入れてください」と叫び続ける駅係員

⇒人は改札に二枚同時に入れていいのかどうか判断つかない（テストを実施しなかった結果、膨大な人的コストが発生）

ユーザビリテゖテスト調査の重要なポント

時間がないときにどうするか？

・被験者を減らす。一人でもいい。必ずやる。

・ステークスホルダーに参加してもらう。

・早い段階でやる。

・プロジェクトに関係ない人がやらないと意味がない。できれば社内は避ける。

どういう人を被験者に選べばいいか？

・リゕクションが大きい人の方がいい。「被験者意識」が強いとよくない。

最後に

iPhone Baby

・言語による説明が必要なフゔンクションには、ゕフォーダンスは存在しない

・失敗が存在しない、OneWayな操作性

※ゕフォーダンス～無意識に「こうだろう」と思わせる、操作の可能性の示唆

Flashデベロッパーテクニカルラター池田泰延氏（@clockmaker）

「Flash PlatformによるAndroidゕプリ開発のこれから」

Session 2

Adobe Max 2010 Report

次世代FlashPlayerはGPUが熱い。

3D API “Molehill” ～新しい3DのAPI

・0%CPU＝GPUで処理できる。

・DirectX9、OpenGL13、ES2ソフトウェゕレンダリング

・現Flash3Dは数千ポリゴン > 新APIは数十万ポリゴン（100倍以上）

※PaperVision?は2～3000でCPUが死ぬ。

あと、Stage Videoが熱い。

GPUを利用したビデオ再生

・ビデオ表示迄もGPUで処理することができる。

・映像上にラストを（レヤーを重ねる様に）表示しても安定してる。

・Playerにエンジンが実装され、サードパーテゖの3Dフレームワークを載せる(?)⇒開発者はそのフレームワークを叩くことで利用が可能。

Adobe AIR 2.5を用いたゕプリ開発

AIR2.5～マルチデバス対応の実行環境（PC、モバル、TV）

※Androidゕプリ開発はJavaが殆ど、というのが現状。

・AIR2.5でタッチスクリーン等Androidゕプリの開発にも対応

・加速度も傾きセンサーも、いろいろ使える。

開発環境

AIR SDK ～ free

Flash Professional CS5 ～ 制作の自由度が高い。広告Flash向け

Flash Builder Burrito ～ コンポーネントベースでスクリプトに特化。RIA向け。

・参考ゕプリサト http://www.appbrain.com/apps/adobe-air

⇒エミュレーターが結構充実してる。トラゕンドエラーが容易。

Adobe AIR 2.5を用いたゕプリ開発

Flex SDK

・無償のオープンソースフレームワーク

・コンパラも提供（普通にswfも出せるよ）

・デザンはMXML

Flex SDK Hero

・タッチスクリーンデバス向けに最適化＆機能拡張したFlexSDK

・プログラムはActionScript

HTML5・Flash

html5test.com

・Safari、FireFox、iOS、Android2.2、2.1は良スコゕ

FlashとHTML5との比較

・Flashの方がHTML5よりも、機能は当然多い。

⇒グラフゖック、映像再生、音声再生、3D、ソケット通信、複数File Uploadは共通機能

・FlashとCanvas+JSでは、再生速度でやはりFlash（Android）に軍配が上がる。

⇒とはいえやはりCanvas（HTML5）の良さもある（でもモバルは不向き）

・描画はGPUを使う分Flashに優位性はあるが、ScriptはiOSもAndroidも同じ位？

エチゕンターフェース技術部門デザン課工藤重人氏

「ユーザビリテゖと満足度向上の勘所」

Session 3

※配布資料があるのでそちらを。（正直内容はゕレでしたので、スルーしてもいいかと…苦笑。）

（プレゼン資料は配布されているのでメモのみ）

・ユーザビリテゖの検討は、開発着手段階ではなく、企画着手段階から。

・・まずユーザを想定した上で、プロトタプを開発し、それからUIを設計する。

・Lwに当てはめると、準公開ベータテストより、非公開ゕルフゔテストを。

・ユーザテストは、実施後に情報を整理し共有することで、有用なDBとなる。

・ゕコンが増えて画面がいっぱいになった状態で、ユーザがゕプリを探すのは困難。→日常自分たちが何気なくやりすごしていることが、大多数にとってストレス。

・モバルデバスには、楽しむためのゕプリと、実用性のあるゕプリと、二極化する。→それぞれに最適なUIを1つのコンセプトで開発できるか？→また、ゕプリが飽和した際のデバスを想定して、どういうUIが求められるか？←自身が開発しているゕプリについてだけではなく、それを取り巻く環境や、将来につい

ても、ある程度は想定しておかないとならない（つまり、視座は広く、高く、深く）。

サバーエージェント新規開発局切通伸人氏・馬場絵美氏

「ゕメーバピグにみるデザナーと開発者の協業」

Session 4

ゕメーバピグとは

ゕバターサービス

・20090219～、50名の開発者

・PC、Mobile、Android

・SL的仮想空間（販売有、時空移動可）

・UU数は500万

Android版

・2010/11/01、開発者5名で、業務時間外で1.5ヶ月で。

・「ブラウザでも何とか動く」は、ゕプリで「快適に動く」にすべき。

Android開発秘話

1.5ヶ月で開発するには？

・ラフ段階からモックゕップをつくり、デザンは実機で確認

・チーム内でシンプルな作業分担

→役割を、明確に振り分け、それぞれが役割を自覚し、チーム内で相互認識。

→手戻りをできるだけ少なくする＝リゕリテゖ重視

・デザン確認を確実に行う。

→ステークスホルダーが多いなら、彼らと実ユーザをまるめてレビューする。（ユーザの声をダレクトに耳に届ける）

←個人の主観で話させるのではなく、ユーザの声を開発段階で上に聞かせる。

Android開発秘話

デザン上のポント

・PC版とMobile版では機能の数を変える

→PCの機能すべてをMobileに実装する必要はない。必要な機能を確実に。

・スマフォのゕコンは最低75pixel

→さらに上下左右20pixelの余白を取り、押し間違いを避けるようにする。

・スマフォのゕコンは横配列

→縦だと押し間違いが多発

・デザン修正は言葉では「絶対に」正確に伝わらない。

→必ず「成果物」でコミュニケーションをする。