「アジャイル・ユーザビリティ」無料サンプル版

アジャイル・ユーザビリティ目　次 Chapter 1 ▶▶▶ ユーザエクスペリエンスの時代1-1　UX と UCD 2 ❶エクスペリエンスの価値／❷ UX の構造／❸ UX の作り方1-2　新・UCD の 4 原則 9 ❶ユーザの声聞くべからず／❷ 1 人のためにデザインする／❸手を動かしなから考える／❹早期に失敗する章末 Column ■ペーパープロトタイピング原論 14 Chapter 2 ▶▶▶ ユーザテスト入門2-1　ユーザテストとは 22 ❶百聞は一見にしかず／❷思考発話法／❸ 3 つの観察ポイント2-2　ユーザテストの基本理論 26 ❶形成的評価／❷反証アプローチ／❸ 5 人のユーザ2-3　ユーザテストの実務基礎 32 目 ❶リクルート／❷テスト設計／❸実査／❹分析 / レポート／❺期間と費　次用 v2-4　DIY ユーザテストのすゝめ 37 ❶軽量化の波／❷ Do-It-Yourself! ／❸ 80 対 20 の法則／❹ DIY の基本原理／❺ユーザテストのアンチパターン

Chapter 3 ▶▶▶ リクルートとテスト設計 3-1　リクルート 46 ❶リクルートを始めるその前に／❷人脈でリクルート／❸あらゆる機会を活かす／❹リクルートのコツ 3-2　DIY テスト設計 53 ❶タスク設計／❷実査ツールの準備／❸インタビューガイドの作成／❹パイロットテストの実施章末 Column ■タスクにまつわるエトセトラ 68 Chapter 4 ▶▶▶ 実　査 4-1　簡易ラボ 72 ❶テスト会場／❷テスト機材／❸録画方法 4-2　インタビュー 83 ❶質問しない / 質問に答えない／❷実況中継してもらう／❸後で聞く 4-3　見　学 89 ❶ “ 目撃者 ” を増やす／❷見学マナー／❸観察テクニック章末 Column ■思考発話の理想と現実 94 目　次 Chapter 5 ▶▶▶ 分析と再設計vi 5-1　分　析 98 ❶ポストアップ／❷マッピング／❸インパクト分析

5-2　再設計 104 ❶レポートよりも対話を／❷問題解決／❸反復デザイン5-3　プライバシーと倫理 110 ❶個人情報保護／❷倫理的責任 Chapter 6 ▶▶▶ UCDを超えて6-1　非ウォータフォール UCD のすゝめ 116 ❶プロセスの違い／❷コミュニケーションスタイルの違い／❸「少しずつ」の意味の違い／❹アジャイル VS UCD6-2　アジャイル UX の潮流 121 ❶アジャイル UX 小史／❷アジャイル UX の基本原則／❸アジャイル UX の基礎理論6-3　アジャイル UX による開発 125 ❶コンセプト／❷計画／❸開発／❹リリース章末 Column ■ RITE メソッド 129参考文献 132　　　　　　　　　　　　　　　　　　　　　　　　　　　　　目　次 ▪ UX の国際規格 ……… 6 ▪もはや手遅れ ……… 12 ▪激安ユーザテストの系譜 ……… 43 ▪謝礼の相場 ……… 52 ▪ DIY 書画カメラ ……… 77 ▪ PinP ……… 81 ▪観察メモ ……… 87 vii ▪ユーザは本当に「お得」がお好き？ ……… 93 ▪タスク達成状況一覧表 ……… 102 ▪小さな変更、大きな成果 ……… 109 ▪勝手にテストしない ……… 113

│▶ Chapter 2 ユーザテスト入門

2-1 ユーザテストとは │ ❶─百聞は一見にしかず │ 　ユーザがパソコンと“格闘”する様子を、開発者やデザイナがマジックミラーで仕切られた“隠し部屋”から真剣なまなざしで観察している─『ユーザテスト（user testing）』の事例としてよく紹介される光景です（なお、ユーザテストは『ユーザビリティテスト（usability test）』と同義語です）。　日本でもこのようなテストが頻繁に実施されるようになりました。テストの対象はウェブサイトや携帯電話のほか、パソコン用ソフトウェア、OA 機器、デジタル家電など多岐にわたり、テスト手法も様々なものがありますが、その基本はとても単純なものです。　1.　ユーザにタスク（作業課題）を実行するように依頼する。　2.　ユーザがタスクを実行する過程を観察、記録する。 C h a p t e r　2 ユーザテスト入門 2 2 ユーザテストユーザテストの基本はとても単純─ユーザにタスク（作業課題）を提示して、その実行過程を横で観察するだけ

　たったこれだけのことなのですが、ユーザテストはまさしく「百聞は一見にしかず」という体験を開発チームに与えてくれます。│ ❷─思考発話法 │　前述のように、ユーザテストの基本は非常にシンプルですが、1 つだけ“秘訣”があります。それはユーザに思ったことを口に出しながらタスクを実行してもらうことです。こうすることでユーザの認知プロセスが明らかになり、操作の失敗や不満の原因を論理的に分析できるようになります。これを『思考発話法（think aloud method）』といいます。あるファッション通販サイトにおける、女性ユーザの行動と発話の例 1.　商品の詳細ページで商品写真を閲覧している。　「このピンクのジャケットよさそうだな。これにしよう！」　「私のサイズはＭなので……」 2.　サイズ指定欄の [ Ｍ ] アイコンをクリックする。 3.　画面を下部までスクロールして首をひねる。　「あれ？　購入ってボタンがない？」　「……M サイズは品切れってことなのかな？　試しに L を押してみよう」 4.　サイズ指定欄の [ Ｌ ] アイコンをクリックする。 5.　画面を隅々まで確認する。　「やっぱり（購入）ボタンはない !?」 6.　首をひねりながら、何度も画面をスクロールする。　「もしかすると……ピンクは品切れなのかな？　試しに白を選んでみよう」１　 7.　カラー指定欄の [ 白 ] のアイコンを選択する。ユー　「あっ、購入ボタンが出てきた。でも本当はピンクがいいんだけど……」ザテス 8.　カラー指定欄の [ ピンク ] のアイコンを選択する。トと　「あっ、今度は購入ボタンが出ている。どうして？？？」は 2 ※このサイトではサイズと色の両方をユーザが指定しない限り購入ボタンが表示されない仕様 2 になっている。これは「誤購入を防ぐ」ためであるが、上記の例のように、デフォルトで表示される商品写真が希望する色と一致した場合、色を改めて指定しないといけないことに気づきづらい。

│ ❸─3つの観察ポイント │ 　ユーザテストでは“生”のユーザの言動を目の当たりにするので、開発者やデザイナは、その情報量の多さに圧倒されてしまうかもしれません。ユーザの行動を漫然と観察するよりも、ポイントを絞って観察した方が効果的です。ユーザテストの観察ポイントは 3 つあります。　1.　まず、ユーザは独力でタスクを完了できただろうか。もし完了できなかったとすれば、その製品は『効果（effectiveness）』に問題があるといえます。これは端的に言えば、その製品は「使いモノにならない」ということであり、もっとも深刻な問題です。　2.　次に、ユーザは無駄な操作を行ったり、戸惑ったりしなかっただろうか。独力でタスクを完了できたとしても、その間に、ユーザを考え込ませたり、遠回りさせたりするような製品は『効率（efficiency）』に問題があるといえます。　3.　さらに、ユーザは不安や不満を感じていなかっただろうか。たとえ、ユーザがほぼ想定ルートを通って独力でタスクを完了できたとしても、途中で不愉快な思いをさせるような製品は『満足度（satisfaction）』に問題があるといえます。ユーザは明示的に不満を表明する場合もありますが、表情や態度で暗示的に不満を表明している場合もあります。 C h a 　一般に、ユーザテストとは「効率問題（＝ユーザの無駄な操作や戸惑い）」 p t e r を発見することが目的だと考えている人が多いと思います。確かに、テストで　2 ユー発見される問題点の多くは効率問題です。ザテスト入　しかし、より深刻な「効果問題（＝ユーザがタスクを完了できない）」が潜門んでいる可能性を意識してテストを実施しないと、せっかく開発の初期段階か 2 2 らテストを行ったのに、結局は使いモノにならない製品をリリースしてしまうという結果になりかねません。

　さらに「満足度問題（＝ユーザの不安や不満）」を軽視してはいけません。満足度問題も程度によっては、ユーザがその製品を二度と使ってくれなくなるからです。ユーザビリティ３要素効果・効率・満足度─すべてを満たして、はじめてその製品はユーザブル（使用可能）であるといえる１　ユーザテストとは 2 2

2-2 ユーザテストの基本理論 │ ❶─形成的評価 │ 　期末試験、入学試験、就職試験、昇進試験、資格試験、etc。私たちは様々な場面で様々な評価を受けてきました。『総このような評価はその目的によって括的評価（summative evaluation）』と『形成的評価（formative evaluation）』に大別できます。　総括的評価とは、学習成果の総合的な達成度合いを“測定”することを目的とした評価です。総括的評価は、学校の期末試験のように一定の学習が終了した後に実施して、通常、得点化を行います。得点化したデータはさらに分析して、得点の分布や平均点を算出したりします。　形成的評価とは、小さい学習単位ごとに、どれくらい理解できているか、理解するためには何をしなければならないかをフィードバックするための評価です。形成的評価は得点をつけることが目的ではなく、理解度を“改善”することが目的です。 C h a p t 　皆さんは TOEIC（トーイック）を受験したことはあるでしょうか。TOEIC e r は英語によるコミュニケーション能力を評価する世界共通のテストで、特にビ　2 ユジネス英語能力の測定では定評があります。多くの企業が入社試験や海外派遣ーザ要員の選抜に用いており、管理職への昇進条件にしているところもあります。テスト入門　TOEIC テストの結果は 10 点から 990 点までのスコアで返されます。英語が 2 苦手で、TOEIC を受験するのが初めての人だと 400 点くらいしか取れないか 2 もしれません。国際化が進んだ現代のビジネス環境では、多くの企業で 600 点くらいは求められますし、海外で仕事をしたければ 800 点以上は必要でし

ょう。　仕事で英語が必要だけれど、TOEIC のスコアが悪かった場合はどうすればよいでしょうか？　当然ですが、テストを繰り返し受験するだけでは、スコアはほとんど上がりません。TOEIC のスコアを上げるには、英語力をつけないといけません。そのためには、例えば英会話スクールに通って英語を勉強することになります。　英会話スクールでは、先生から様々な課題が与えられます。教室内で、先生は発音の間違いをその場で修正してくれます。ホームワークで作成した英文メールを提出すれば、文法やスペルの間違いを細かく添削してくれます。そうやって、具体的にどこが間違っているのか、なぜ間違っているのかを指摘してもらいながら、徐々に英語力を身につけていきます。半年、１年と英語の勉強を続けて、その後 TOEIC を再度受験すれば、TOEIC スコアは（かなり）アップするはずです。　TOEIC は典型的な総括的評価です。あなたの英語力を客観的なスコアで表して比較評価を可能にしてくれます。あなたは、スコアを履歴書に記載して転職に役立てたり、社内で昇進を有利に進めるために利用できますが、あなたの英語力について具体的に何が問題なのか、どうすれば上達するのかは教えてくれません。総括的評価を繰り返しても品質の改善にはつながりません。　一方、英会話スクールの先生が生徒の発音の間違いを正したり、英文メールを添削するのは形成的評価です。繰り返し行われる形成的評価を通じて生徒の　 2 ユ英語力（読む・書く・聞く・話す）は飛躍的に向上します。ただ、その能力がーザどれくらいなのかを第三者に客観的に証明するためには、総括的評価を必要とテストします。の基本理論　本書で紹介するユーザテストは形成的評価を目的としています。つまり、ス 2コアをつけることが目的ではなく、具体的にどこに問題があるのか、なぜ問題 2が発生したのかを明らかにして、製品の品質を改善することを目的としています。

│ ❷─反証アプローチ │ 　ユーザビリティを“実証”するのは困難な作業です。いったい何人のユーザで、何種類のタスクを検証すれば、その製品がユーザブルであることを証明できるのでしょうか。例えば、私が使っている携帯電話は主なメニューだけで 115 項目あります。そのすべてを限られた設計期間の中で検証するのは、コストとスケジュールの制約から事実上不可能でしょう。　そこで、まず「この製品はユーザブルである」という仮説を立てます。もちろん、何の根拠もなしに仮説を立てるわけにはいきませんが、ユーザ中心設計のプロセスに沿って設計された製品ならば、取り敢えず“ユーザブル（つまり、効果・効率・満足度いずれも阻害していない） ”であると仮定することは、それほど乱暴な議論ではありません。　次に、その仮説を検証するために、実際に何人かのユーザにその製品を使っていくつかの重要なタスクを実行してもらいます。これがユーザテストです。もし、ユーザテストで効果・効率・満足度を阻害している具体的な問題点が見つかれば、それは「仮説を否定する証拠＝反証」になります。つまり「この製品はユーザブルである」という仮説は崩れます。　仮説が崩れたからといって悲観する必要はありません。そもそもユーザテス C h トでは積極的に反証を見つけようとしているので、問題点が見つかるのは当た a り前のことです。それに、思考発話法によるテストならば問題点の発見だけで p t e r なく、その原因まで明らかになるので、開発チームはすぐに改善案の検討を始　2 ユーめることができます。そして、見つかった問題点をすべて改善すれば改めて仮ザテ説が成り立ちます。スト入門　一方、どんなにテスト結果を分析しても問題点が見つからなければ、評価者 2 2 は反証を提示できません。もちろん、もっと多くのユーザでテストしたり、他のタスクを実行すれば問題点が見つかる可能性はありますが、そのような議論を続けていては永遠に結論に到達しません。そこで、反証が見つからない場合

は仮説を受け入れます。つまり「この製品はユーザブルである」と結論づけるのです。　ユーザテストは製品のユーザビリティを実証するものではありません。テストに合格したといっても、それはあくまで「今のところ反証がない」というだけのことです。だから、私たちは製品をリリースした後も、ユーザからのフィードバックを積極的に受けつけて、絶えず反証の有無に注意し続けなければいけないのです。│ ❸─5人のユーザ │　ユーザビリティ工学の開拓者ヤコブ・ニールセン（Jakob Nielsen）は、テストする人数と発見できるユーザビリティ問題の数に関する公式を明らかにして、人のユーザでテストすれば、ユーザビリティ問題の大半（約 85％）を「5発見できる」という説を唱えました。 n　　　　N（１−（１− L）） N ：デザイン上のユーザビリティ問題の数（潜在的なものも含むので架空の値） L ：１人のユーザをテストして発見できるユーザビリティ問題が全体に占める割合（ヤコブ・ニールセンは経験値として 0.31 を提示） n ：テストするユーザ数　 2 ユーザ　例えば、この公式に L ＝ 0.31、n ＝ 5 を代入すると「0.8436N」となります。テスト仮に 100 個のユーザビリティ問題が潜在的に含まれている製品ならば、5 人での基本テストすると「84.36 個」の問題点が発見できると期待されます。理論 2　この公式をもとにグラフを描くと興味深い考察が得られます。1 人目のユー 2ザからは最も多くの問題点（全体の約 3 分の 1）が発見されます。2 人目、3 人目と回数を重ねるうちに新たに発見される問題点は減っていき、5 人を超える

と新たに得られる知見はほとんどありません。　実はユーザテストの現場では「3 人目くらいまでは新たな問題点の発見が続くが、4 人目以降では新たな発見は少なくなってくる」という経験則が以前から知られていました。ヤコブ・ニールセンは、これに数学モデルを当てはめて理論的に実証しようとしたのです。　この公式は、それまでの大規模な実験を前提とした学術的なユーザビリティに対して、費用対効果に優れた実務的なユーザビリティが普及するきっかけとなりました。膨大なコストと時間を費やしていたテストの 85％の成果が、わずか 5 人のユーザをテストするだけで得られることが明らかにされたのですから。　もちろん、この公式に対して他の研究者からは多くの反論がありましたが、開発の現場では徐々に支持が広がり、現在では、何十人もテストするのではなく 5 〜 6 人の小規模なテストを行うことが世界標準になっています。 C h a p t e r　2 ユーザテスト入門 2 3 ユーザテストは５人で十分ヤコブ・ニールセンは経験則に数学モデルを当てはめて、被験者数と問題点の数の関係を明らかにしようとした

　なお、ヤコブ・ニールセンは「5 人のテストを“1 回”やれば十分である」と言っているわけではありません。テストでわかるのは問題点です。発見された問題点を修正したうえで再度検証しない限り、その修正が本当に正しかったかどうか判断できません。そして、その再検証でさらに新たな問題が見つかるかもしれません。そのため、通常は 5 人のテストを 2 〜 3 回、つまり延べ 10 〜15 人のテストをします。 2 　ユーザテストの基本理論 2 3

2-3 ユーザテストの実務基礎 │ ❶─リクルート │ 　まずは協力してくれる『被験者（subject/participant）』がいないことにはユーザテストは始まりません。被験者を集めることを『リクルート（recruiting）』といいます。当然ながら、テストの被験者は誰でも構わないというわけではありません。ターゲットユーザで、かつ、今回のテスト目的に応じた条件を満たした人でなければなりません。そのうえ、テストはある特定の日時に行いますので、その日時に会場まで足を運んでくれる人という条件も加わります。　そういった条件を満たした人を探すために、通常、調査会社に依頼してパネル（登録モニタ会員）を対象に小規模なインターネット・アンケート調査を行います。複数項目のアンケートに回答してもらって、その中からなるべく条件を満たした人を抽出してアポイントを取ります。最終的には「被験者リスト」が調査会社から送られてきます。 C h a p t e r　2 ユーザテスト入門 2 2 リクルート求人広告のように、リクルート条件は簡潔にまとめることができる

│ ❷─テスト設計 │　ユーザテストでは被験者に何らかの作業をしてもらいます。例えば、オンラインショップで商品を購入してもらったり、会計ソフトを使って確定申告を行ってもらったり、携帯電話で音楽をダウンロードしてもらったりします。これ』といいます。タスク設計はユーザテストの成否を左右すを『タスク（task）る重要な要素です。　タスク設計を終えたら『インタビューガイド（interview guide）』を作成します。インタビューガイドには、被験者の入室から退室までの流れ、質問やタスクの提示順序、時間配分、そしてインタビューアが話す内容（スクリプト）がすべて記載されています。また、被験者がタスクを実行する上で必要な情報は、口頭で伝えるよりも、紙に書いて渡した方が確実に伝わるので「情報提示カード」も作成します。　なお、どんなに綿密にテスト設計を行っても、実際にテストを行うと予想外の事態が発生します。もちろん、被験者の行動が予想外なのは織り込み済みですが、インタビューガイドや情報提示カードの内容に問題が見つかることも少 3 　ユーザテストの実務基礎 2 2 インタビューガイドユーザテストは“台本”に従って進行する。インタビューガイドにはテストのすべてが記載されている

なくありません。そこで、事前に『パイロットテスト（pilot test）』を行います。 │ ❸─実　査 │ 　本番のテストは『ユーザビリティラボ（usability lab）』を使って行います。ユーザビリティラボはテスト専用の施設で、インタビュールームにはパソコン、カメラ、マイクなどが設置されており、被験者がタスクを実行する様子をマジックミラーで仕切られたモニタルームから観察、記録できるようになっています。　予定の時刻になると、被験者をインタビュールームに案内して、所定の席に座ってもらいます。インタビューの目的を簡略に伝えた後、撮影許可と情報開示禁止同意（NDA：Non-Disclosure Agreement）という 2 種類の契約を交わします。　テストでは、まず事前インタビューを行います。事前インタビューの目的の半分は、被験者との信頼関係構築（ラポール）です。会話することで緊張をほ C h a p t e r　2 ユーザテスト入門 2 2 実査当日の作業フロー実査当日は「受付〜お見送り」の手順を繰り返し行う

ぐし、なるべく平常心でタスクに取り組んでもらえるようにするのです。　そしてタスク実行観察に移行します。被験者がタスクを実行している間、インタビューアは横で観察を続けます。被験者の発話が止まったら、「今、何を考えているのですか？」「どうなると思っていたのですか？」といった質問を被験者に投げかけて、発話を始めるきっかけを与えます。　一通りタスクが終了したら簡単に事後インタビューを行います。所定の時刻がきたらインタビューを切り上げて、被験者に謝礼を渡して、お見送りします。│ ❹─分析／レポート │　実査が終わると、テストのビデオ映像を見直して記録を作成します。このようなユーザの行動と発話を記録したものを『プロトコル（protocol）』といいます。心理学の実験などで行うプロトコル分析は、被験者のちょっとした仕草ちゅうちょさや、躊躇した時間まで記録するといった非常に詳細なものですが、ユーザテストの記録ではそこまでの精度は求めません。　記録が作成できたら、被験者 1 人ずつのテスト記録を丹念に読み直して、ユ 3 　ユーザテストの実務基礎 2 2 プロトコル分析テスト映像からユーザの行動と発話を書き出して詳細に分析する

ーザビリティ問題を発見していきます。すべての問題点をリストアップして、それらを分類したり重要度を判定したりします。　最後に、これまでのすべての情報をまとめ上げてレポートを作成します。文字がぎっしり詰まった長文のレポートは非常に読みづらく、テストで発見された問題点のポイントが設計者に伝わりにくくなってしまいがちです。画面ショットやビデオクリップも用いて、なるべく「見てわかる」ように解説します。 │ ❺─期間と費用 │ 　ユーザテストのスケジュールは 4 週間前後が標準的です。・テスト準備　─リクルート：約 2 週間　─テスト設計：約 1 週間（※テスト設計はリクルートと並列で行います）・実査：2 〜 3 日・分析／レポート：1 〜 2 週間　このようにユーザテストは準備から完了までに、それなりの手間と時間がかかる仕事なので、評価対象が準備できてからテストの計画を始めたのでは手遅れになってしまいます。当初からテストを組み込んだプロジェクト計画を立て C h ておかないと、テスト結果を活用することはできません。 a p t e r 　また、ユーザテストの費用は決して安くありません。費用は基本的にはテス　2 ユート時間と被験者数によって決まりますが、リクルートの難易度（出現率の低いザテ被験者を集める場合など）や使用する設備（アイ・トラッキングシステムを使スト入う場合など）などによってかなり変動します。門 2 2 　正規のラボを使って１時間半のテストを被験者 10 人で行う場合、日本のコンサルティング会社にすべての作業を依頼すると、おおよそ 200 万円くらいの予算を想定しておけば、ほぼ間違いないと思います。

2-4 DIYユーザテストのすゝめ│ ❶─軽量化の波 │　ソフトウェア開発の新しい手法として、迅速で臨機応変な『アジャイル開発（Agile Software Development）』が急速に普及しています。アジャイル開発では製品を小さな機能に分割しながら、1 〜 4 週間という短期の開発＝『イテレーション（iteration）』を反復的に行います。各イテレーションでは設計、実装、テストといった開発に関わるすべての工程を行い、イテレーションの終了時点では小さいながらも「出荷可能」なレベルの機能を完成させます。　ところが、前述のように従来のユーザテストは約 4 週間を必要とします。アジャイル開発チームにとって 4 週間というのは少なくとも 1 イテレーション、場合によっては 4 イテレーションにも相当します。当然ながら、そんな“膨大”なリソースをユーザテストだけに費やすことは許されません。　また、Ruby on Rails のような生産性の高い開発環境や、クラウド・コンピューティングの普及によって、近年のソフトウェア開発プロジェクトはそれほど資金がかからなくなっています。例えば『リーンスタートアップ（Leanstartup）という起業手法では、』期間は 1 〜 3 ヶ月程度、費用も数百万円以内（数 4 　十万円の場合もある）で新たなサービスを立ち上げてしまいます。 I D Y ユー　このような小規模のプロジェクトでは、従来のコスト感覚のユーザテストはザテス事実上不可能です。例えば総予算が 500 万円のプロジェクトで、1 回のユーザトのすテストのためだけに 200 万円を投入することは、経営管理上あり得ないことだゝめからです。 2 2

│ ❷─ Do-It-Yourself! │ 　設備の整ったユーザビリティラボに加え、大規模な登録モニタや、心理学や人間工学の知識を持った専門のインタビューアを取りそろえて、テストの企画からレポートまで一貫したサービスを提供してくれる専門の会社もあります。　予算が確保できるならば、そういった専門の会社にテストを依頼するのは無難な選択肢だと思います。被験者のリクルーティング、タスクの設計、インタビューの技術、プロトコル分析、ビデオ編集……、専門家が使うノウハウを数え上げればきりがありません。こういった複雑な業務を専門の会社に依頼できれば、あなたは心おきなく製品の開発に専念できます。　しかし「予算がないからテストはしない」という選択肢だけは選んではいけません。開発者が机上で意図したとおりには、ユーザは製品を使用してくれません。テストしないということは、「使いモノにならない製品をリリースする」という大きなリスクを犯すことになります。　予算がなければ Do-It-Yourself! ─自分たちでやりましょう。それほど心配することはありません。人脈を駆使すれば被験者は見つかります。社内の会議室にビデオカメラを設置すればラボの代わりになります。高度なインタビュー技術を使わなくても、黙って横で観察するだけで「百聞は一見にしかず」とい C h う発見があります。そして誰も読まない分厚いレポート作成に時間を費やすよ a りも、開発チームみんなで改善案を検討し、素早く問題点を修正するのです。 p t e r　2 ユー　そもそも私たちのゴールは「テストを実施」することではありません。私たザテちの本当のゴールは「製品を開発」することです。ユーザテストは手段の 1 つスト入に過ぎません。ですから、どんなに見た目が貧相なテストであったとしても、門製品の品質向上に貢献すれば“それで十分”なのです。 2 2

│ ❸─ 80 対 20 の法則 │　8 割は 2 割からもたらされる─パレートの法則とも呼ばれている経験則です。この法則を「要素の 8 割は価値が低いので不要である」と解釈するのは全くの誤解ですが、割の価値をもたらす 2 割の要素にもっと注目しよう」とす「8るのは正しいアプローチです。すべてに 100％を求めていては、ヒト・モノ・カネはいくらあっても足りないからです。　本書で紹介する Do-It-Yourself（DIY）方式のユーザテストは決して“安物”ではありません。無駄は排除しますが、本質的な価値を損なうような無謀な簡略化ではありません。ユーザテストの企画から完了までのプロセス自体は変わりませんし、テスト設計の内容も全く同じです。しかし、例えば見学時の“豪華な弁当”や、マジックミラーで仕切られた（暗くて眠くなる）観察室はユーザテストの本質的な価値ではないでしょう。　また、DIY ユーザテストの成果は正規の“八掛け”ではありません。被験者数が同じであれば、発見される問題点の数は理論的に同じですし、開発チームの技量が同じならば、解決案の水準においても何ら差は生じません。それどこ 4 　 D I Y ユーザテストのすゝめ 2 2 正規ユーザテストと DIY ユーザテストの比較

ろか、短期間・低コストというメリットを活かせば、これまでテストを行えなかったプロジェクトでもテストが可能になったり、同じ予算ならば多くの回数のテストが行えるので、総合的に見れば正規のテストよりも大きな成果が期待できるのです。 │ ❹─ DIY の基本原理 │ 　DIYユーザテストの基本原理は代用です。ただし、それは正規品を“まがい物” に置き換えるという意味ではありません。本質的な価値を見極めて、それをもっと短期間・低コストで実現するように柔軟に発想するのです。 ◎人脈を活かす　「友達の友達のさらに友達……を 6 回繰り返せば地球の人口を超える、つまり私たちは世界中のどんな人とでも（間接的には）つながっているのだ」という説があります。これは『シックス・ディグリー理論（six degrees of separation）』と呼ばれており、ソーシャルネットワークサービスの原点だとも言われています。もちろん、現職の大統領や人気絶頂のアイドルと友達になることは現実には不可能だと思いますが、本気になって人脈をたぐっていけば、想像以上に幅広い人々とつながりがあることに気づくでしょう。　DIY ユーザテストでは、あなたの人脈を使ってリクルートします。個人の人 C h 脈に頼るというと随分と狭い世界をイメージするかもしれませんが、年賀状を a 100 枚くらい出していれば全く心配いりません。なぜならば、１ディグリーで p t e r 100 人、2 ディグリーで 1 万人、3 ディグリーで 100 万人─この時点で既に日　2 ユー本最大級の調査会社の登録モニタ数に匹敵するからです。ザテスト入 ◎手近な品を活用する門　私たちは普段、専用品だけを使って生活しているわけではありません。例え 2 3 ば、ドアストッパーの代わりに材木の切れ端を使ってみたり、サイドテーブルの代わりに丸椅子を使ったりします。確かに専用品は洗練されていますが、代用品でも機能としては大差がないということは少なくありません。

　例えば、会議室を可動式のパーテーションで仕切れば、即席のユーザビリティラボになります。テスト用のマシンは社員共有のノート PC です。差し当たり手元にある iPhone でも動画の撮影は可能ですし、家に帰れば年に数回しか使わないビデオカメラと三脚が押し入れの奥にしまってあるかもしれません。このように、ちょっと想像力を働かせて自分の周りを見回せば、テスト機材はゴロゴロ転がっているのです。◎アナログに分析する　高価な専用の分析ソフトウェアを使って、複雑なマクロを組んでデータを解析する─「データ分析」というと一般にそういうイメージが強いですし、確かに定量データの場合はあながち的外れではありません。しかし、定性データ（質的データ）の場合は全く状況が異なります。　定性データは演算できません。作業の効率化のためにパソコンは活用しますが、本質的にパソコンでは分析できないのです。そこで専門家はデータを断片化してカードに書き出して、壁やホワイトボードに貼ってソート（並び替え）するという“超”アナログな作業＝ KJ 法を今でも使っています。DIY ユーザテストでは、あなたも専門家と同じようにアナログに分析すればよいのです。◎対話を重視する　画面ショットやビデオクリップを駆使して、データ編も含めれば一抱えもありそうな立派な報告書が 2 週間後に到着。しかし、製品の開発に直接携わって 4 　いる開発者やデザイナにとって、それは無用の長物ということは少なくありま I D Yせん。テストを見学した彼らは、既に自分たちで改善案を検討して設計変更にユー取りかかっているからです。ザテストのす　DIY ユーザテストでは、関係者には必ずテストを見学してもらいます。そゝめして、誰も読まない分厚いレポートの作成に時間を費やすのではなく、開発者 2やデザイナと一緒になって問題点の解決方法を考えることに時間を費やすので 3す。ユーザテストのゴールは製品の品質向上です。レポートの枚数と製品の品質は全く関係ありません。

│ ❺─ユーザテストのアンチパターン │ 　DIY ユーザテストは製品の品質向上に大きく貢献してくれます。ただ、未経験の人が陥りがちな“落とし穴”も少なくありません。ここでは代表的な失敗パターンを指摘しておきましょう。　製品ができあがってからテストする─開発者やデザイナには一般的に悪い癖があります。それは、テストの実施時期を遅らせたがることです。「中途半端なものをテストしても意味はない。デザインやコーディングが完了してからテストすべきだ」と考えるのです。しかし、これは大きな間違いです。製品が完成してからテストして、もし製品の基本設計に関わるような問題が見つかった場合、もはや修正は不可能です。どうせ失敗するのならば「早期に失敗」するべきなのです。　初心者でテストする─被験者が初心者の方が、より多くの問題点を発見できると考えるかもしれませんが、それは全くの間違いです。マウスやキーボードがまともに操作できない初心者をリクルートしてしまうと、それはテストではなく“パソコン教室”になってしまいます。テストには十分な技量とモチベーションを持ったユーザに来てもらいます。そういった“当然できるはず”のユーザが悪戦苦闘するからこそ、開発者やデザイナは大きな衝撃を受けて、根本的な製品仕様の変更を決断できるのです。 C h a 　グループインタビュー形式でテストする─マーケティングリサーチで用い p t e r られるグループインタビューと勘違いして、5 人のユーザを 1 部屋に集めて同　2 ユー時にテストしてはいけません。ユーザテストでは必ず 1 人ずつ個別にテストしザテます。現実の場面でも、ほとんどの場合、ユーザは 1 人で製品を操作しているスト入のですから。門 2 2 　ユーザに質問する─ユーザに「どこが悪いと思いますか？」「どう改善すればよいと思いますか？」といった質問をしてはいけません。ユーザは分析者でもなければ、デザイナでもありません。製品の何が問題で、それをどう改善

すべきかを考えるのは、当然ながら“あなた”の仕事です。ユーザテストにおいても「ユーザの声聞くべからず」なのです。激安ユーザテストの系譜　ディスカウント・ユーザビリティの元祖はヤコブ・ニールセンです。学術的なユーザビリティが支配していた時代に、彼は 5 ユーザテストやヒューリスティック評価法を用いた実用的なユーザビリティ＝ディスカウント・ユーザビリティエンジニアリングを提唱しました。　ただし“ディスカウント”といっても、それは「研究室にこもった白衣を着た博士と助手に頼むよりは安い」というレベルです。実際、彼が代表を務めるニールセン・ノーマン・グループの価格表を見ると◎専門家評価：$38,000、 ◎ユーザテスト：$25,000、◎ユーザテスト講習会：$23,000 ＋旅費……、私たちの感覚では決して“安い”と言えそうにありません。　これを見て「海外はユーザビリティの予算が何百万円もある！　日本は遅れている！　我々にももっと予算を！」と誤解してはいけません。海外でもユーザテストに 200 万円使えるプロジェクトはごく僅かです。　では、どうしているのか？　Do-It-Yourself! ─その第一人者がスティーブ・クルーグ（Steve Krug）です。「Dont Make Me Think（邦題：ウェブユーザビリティの法則）」の大ヒッ 4 　トで一躍人気者になった彼は、そのノウハウを軽妙な語り口で全米に伝道して D I 回っています。 Y ユーザテ　そんな彼の第二弾が「Rocket Surgery Made Easy」です。風変わりなタイストトルですが、「ロケット手術」とは“すごく難しい（と誤解されている）コト” のすゝを皮肉った彼の造語で、要するにユーザテストを指しています。つまり、タイめトルを意訳すれば「お手軽ユーザテストガイドブック」・といった感じでしょう。 2 2 　彼の主張は 3 点に集約できると思います。 ◦定期的（月イチ／朝イチ）に小規模（被験者 3 人）なテストを繰り返そう！

◦関係者にテストを見学してもらおう！ ◦問題解決では最善を“尽くさない”ようにしよう！　彼特有の“受け狙い”の感もありますが、その内容は私たち実務家から見ても納得できるものです。特に、関係者に見学してもらうことの重要性と、そのためのノウハウ（例えば“おやつ”をケチらない）は参考になりました。　このようにディスカウント・ユーザビリティの主役はニールセンからクルーグに代わりましたが、実は大本の原則は少しも変わっていません。 ◦どんなテストでも、やらないよりはマシ ◦早い段階（プロトタイプ）でテストする ◦繰り返しテストする　そして、これは今後も永遠に変わらないと思います。スティーブ・クルーグ激安ユーザテストの伝道師。「Rocket Surgery Made C Easy」は風変わりなタイトルだが、的確に本質を突い h a た彼独自の実用的ユーザテスト論が展開されている p t e r　2 ユーザテスト入門 2 2

〈著者紹介〉樽本徹也（たるもと　てつや）利用品質ラボ代表。ユーザビリティエンジニア／ UCD コンサルタント／アジャイル UX コーチ。ユーザビリティ工学が専門で特にユーザ調査とユーザビリティ評価の実務経験が豊富。現在はプロのコンサルタントとして、組込みシステムからウェブアプリケーションまで幅広い製品のユーザインタフェース開発に携わっている。寄稿や講演も多数。•認定人間中心設計専門家•認定スクラムプロダクトオーナー（CSPO）• NPO 人間中心設計推進機構理事•アジャイル UCD 研究会共同代表〈公式サイト〉・『人机交互論』　http://www.usablog.jp/〈著　書〉・『ユーザビリティエンジニアリング─ユーザ調査とユーザビリティ評価実践テクニック』（オーム社　2005 年 10 月）・『これだけは知っておきたい組込みシステムの設計手法』（技術評論社　2009 年 10 月　共著）〈連載記事〉・ウェブ担当者フォーラム「ゼロ円でもできる！？　省コストユーザビリティ向上術」（2008 年 12 月〜 2009 年 6 月）　http://web-tan.forum.impressrd.jp/l/3066・EnterpriseZine「アジャイル UX の潮流〜米国発アジャイル開発の新しい波、只今日本に接近中 !?」（2010 年 11 月〜 2011 年 2 月、共著）　http://enterprisezine.jp/article/corner/160本文イラスト◆中西隆浩 ● 本書の内容に関する質問は，オーム社出版部「（書名を明記）」係宛，書状または FAX（03-3293-2824）にてお願いします．お受けできる質問は本書で紹介した内容に限らせていただきます．なお，電話での質問にはお答えできませんので，あらかじめご了承ください . ● 万一，落丁・乱丁の場合は，送料当社負担でお取替えいたします．当社販売管理課宛お送りください． ● 本書の一部の複写複製を希望される場合は，本書扉裏を参照してください．アジャイル・ユーザビリティ─ユーザエクスペリエンスのための DIY テスティング─平成 24 年 2 月 20 日　　第１版第１刷発行著　者樽本徹也発行者竹生修己発行所株式会社オーム社郵便番号 101- 8460 東京都千代田区神田錦町 3-1 電話 03 3233）（代表）（ 0641 URL http://www.ohmsha.co.jp/© 樽本徹也 2012印刷　エヌ・ピー・エス　　製本　協栄製本ISBN978-4-274-21160-7　Printed in Japan

「アジャイル・ユーザビリティ」無料サンプル版

by Tarumoto Tetsuya on Feb 06, 2012

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 1

Statistics

「アジャイル・ユーザビリティ」無料サンプル版 — Document Transcript