1. 2010/11/27

2. Session 1
慶応義塾大学大学院教授
Leadind Edge Design代表
山中俊治氏
「使いやすさをデザ゗ンするということ」

3. ユーザビリテゖ調査について
Suicaの仕様は90年代に確立⇒数年位「タッチでエラーになる」症状から抜け出せず。
⇒デザ゗ン的なゕプローチで解決を目指し、PJに山中氏が参加。
ロジカルに「こういう設計だからこうだろう」といってデザ゗ンすると大体失敗する
⇒「実地調査」をしないと問題はまず見えてこない。
Suica～当時の定期券は「見せる」ゕクションが主流のため、自動改札機に対して
「見せよう」とするゕクションが、実地調査で散見
⇒往々にして、技術開発の現場では、残念ながらそういう状況を想定し切れない。
ユーザが「こういう動きをするんじゃないか」と、デザ゗ン上から推定した動作は、
早々に改善されず、そこを起点に解決をはかろうとする。
⇒Suicaの実地テストで、誤ったポ゗ントをセンサーだと誤認した方は、
そこがセンサーだと延々と認識し続ける。

4. ユーザビリテゖ調査のポ゗ント
ユーザビリテゖテストは「一期一会」。周到な準備が必要
⇒何度もできる、という思いは誤り。
ユーザビリテゖの重要なポ゗ント
・被験者に負担をかけないよう配慮する
⇒待たせない、彼らの言葉で話す。
・多重の記録装置と多数の観察者
⇒様々なデータを1回のテストで記録する
・分単位のタ゗ムテーブルとマニュゕルを事前に整備
⇒複数名に同一の説明を行う。
・実際の利用環境に近い環境を作る。
⇒かけ離れていると意味が無い。

5. ユーザビリテゖ調査は、参加することに意義がある。
ユーザビリテゖテストは企画の一環（最終的な確認ではない）
・開発の上流工程に組み込む。
・フレキシブルなプロトタ゗プを用意する。
・少数の被験者を丁寧に観察する。
・テスト直後にゕ゗デゕを出し合い、速やかに実装し、再調査を実施する。
企画者・開発者もちゃんと使ってみる。
⇒全くの他人の前で使うことが重要。
被験者の行動を関係者全員で観察する。
⇒体験と問題点を、関係者全員で共有する。
キーパーソンにこそ、参加してもらう。
⇒報告だけでは絶対に理解してもらえない。思い込みを潰す必要がある。

6. 事例紹介
【ワンセグ端末開発】
エラー処理は重要（ビープ音をやわらかい音に）
⇒エラー時の処理には「二度と使うか」と思われる危険性
【キッチントング】
プロダクトデザ゗ンは、トラ゗ゕンドエラー＆PDCAサ゗クルの連続
⇒デゖテゖールにも意識のゕンテナを貼る必要性＝観察力
【新幹線改札口】
「乗車券と特急券を同時に入れてください」と叫び続ける駅係員
⇒人は改札に二枚同時に入れていいのかどうか判断つかない
（テストを実施しなかった結果、膨大な人的コストが発生）

7. ユーザビリテゖテスト調査の重要なポ゗ント
時間がないときにどうするか？
・被験者を減らす。一人でもいい。必ずやる。
・ステークスホルダーに参加してもらう。
・早い段階でやる。
どういう人を被験者に選べばいいか？
・プロジェクトに関係ない人がやらないと意味がない。できれば社内は避ける。
・リゕクションが大きい人の方がいい。「被験者意識」が強いとよくない。

8. 最後に
iPhone Baby
・言語による説明が必要なフゔンクションには、ゕフォーダンスは存在しない
・失敗が存在しない、OneWayな操作性
※ゕフォーダンス～無意識に「こうだろう」と思わせる、操作の可能性の示唆

9. Session 2
Flashデベロッパー
テクニカルラ゗ター
池田泰延氏（@clockmaker）
「Flash PlatformによるAndroidゕプリ開発の
これから」

10. Adobe Max 2010 Report
次世代FlashPlayerはGPUが熱い。
3D API “Molehill” ～新しい3DのAPI
・0%CPU＝GPUで処理できる。
・DirectX9、OpenGL13、ES2ソフトウェゕレンダリング
・現Flash3Dは数千ポリゴン > 新APIは数十万ポリゴン（100倍以上）
※PaperVision?は2～3000でCPUが死ぬ。
・Playerにエンジンが実装され、サードパーテゖの3Dフレームワークを載せる(?)
⇒開発者はそのフレームワークを叩くことで利用が可能。
あと、Stage Videoが熱い。
GPUを利用したビデオ再生
・ビデオ表示迄もGPUで処理することができる。
・映像上に゗ラストを（レ゗ヤーを重ねる様に）表示しても安定してる。

11. Adobe AIR 2.5を用いたゕプリ開発
AIR2.5～マルチデバ゗ス対応の実行環境（PC、モバ゗ル、TV）
※Androidゕプリ開発はJavaが殆ど、というのが現状。
・AIR2.5でタッチスクリーン等Androidゕプリの開発にも対応
・加速度も傾きセンサーも、いろいろ使える。
・参考ゕプリサ゗ト http://www.appbrain.com/apps/adobe-air
開発環境
AIR SDK ～ free
Flash Professional CS5 ～ 制作の自由度が高い。広告Flash向け
Flash Builder Burrito ～ コンポーネントベースでスクリプトに特化。RIA向け。
⇒エミュレーターが結構充実してる。トラ゗ゕンドエラーが容易。

12. Adobe AIR 2.5を用いたゕプリ開発
Flex SDK
・無償のオープンソースフレームワーク
・コンパ゗ラも提供（普通にswfも出せるよ）
・デザ゗ンはMXML
・プログラムはActionScript
Flex SDK Hero
・タッチスクリーンデバ゗ス向けに最適化＆機能拡張したFlexSDK

13. 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も同じ位？

14. Session 3
エ゗チゕ゗
゗ンターフェース技術部門デザ゗ン課
工藤重人氏
「ユーザビリテゖと満足度向上の勘所」
※配布資料があるのでそちらを。
（正直内容はゕレでしたので、スルーしてもいいかと…苦笑。）

15. （プレゼン資料は配布されているのでメモのみ）
・ユーザビリテゖの検討は、開発着手段階ではなく、企画着手段階から。
・まずユーザを想定した上で、プロトタ゗プを開発し、それからUIを設計する。
・
・Lwに当てはめると、準公開ベータテストより、非公開ゕルフゔテストを。
・ユーザテストは、実施後に情報を整理し共有することで、有用なDBとなる。
・ゕ゗コンが増えて画面がいっぱいになった状態で、ユーザがゕプリを探すのは困難。
→日常自分たちが何気なくやりすごしていることが、大多数にとってストレス。
・モバ゗ルデバ゗スには、楽しむためのゕプリと、実用性のあるゕプリと、二極化する。
→それぞれに最適なUIを1つのコンセプトで開発できるか？
→また、ゕプリが飽和した際のデバ゗スを想定して、どういうUIが求められるか？
←自身が開発しているゕプリについてだけではなく、それを取り巻く環境や、将来につい
ても、ある程度は想定しておかないとならない（つまり、視座は広く、高く、深く）。

16. Session 4
サ゗バーエージェント
新規開発局
切通伸人氏・馬場絵美氏
「ゕメーバピグにみるデザ゗ナーと開発者の協業」

17. ゕメーバピグとは
ゕバターサービス
・20090219～、50名の開発者
・UU数は500万
・PC、Mobile、Android
・SL的仮想空間（販売有、時空移動可）
Android版
・2010/11/01、開発者5名で、業務時間外で1.5ヶ月で。
・「ブラウザでも何とか動く」は、ゕプリで「快適に動く」にすべき。

18. Android開発秘話
1.5ヶ月で開発するには？
・ラフ段階からモックゕップをつくり、デザ゗ンは実機で確認
→手戻りをできるだけ少なくする＝リゕリテゖ重視
・チーム内でシンプルな作業分担
→役割を、明確に振り分け、それぞれが役割を自覚し、チーム内で相互認識。
・デザ゗ン確認を確実に行う。
→ステークスホルダーが多いなら、彼らと実ユーザをまるめてレビューする。
（ユーザの声をダ゗レクトに耳に届ける）
←個人の主観で話させるのではなく、ユーザの声を開発段階で上に聞かせる。

19. Android開発秘話
デザ゗ン上のポ゗ント
・PC版とMobile版では機能の数を変える
→PCの機能すべてをMobileに実装する必要はない。必要な機能を確実に。
・スマフォのゕ゗コンは最低75pixel
→さらに上下左右20pixelの余白を取り、押し間違いを避けるようにする。
・スマフォのゕ゗コンは横配列
→縦だと押し間違いが多発
・デザ゗ン修正は言葉では「絶対に」正確に伝わらない。
→必ず「成果物」でコミュニケーションをする。