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

tarumoto

スタンプ

目　次

v

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

❶リクルート／❷テスト設計／❸実査／❹分析 / レポート／❺期間と費用

2-4　DIY ユーザテストのすゝめ 37

❶軽量化の波／❷ Do-It-Yourself! ／❸ 80 対 20 の法則／❹ DIY の基本原理／❺ユーザテストのアンチパターン

アジャイル・ユーザビリティ目　次

vi

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 ▶▶▶分析と再設計

5-1　分　析 98

❶ポストアップ／❷マッピング／❸インパクト分析

目　次

目　次

vii

5-2　再設計 104

❶レポートよりも対話を／❷問題解決／❸反復デザイン

5-3　プライバシーと倫理 110

❶個人情報保護／❷倫理的責任

Chapter 6 ▶▶▶U C D を超えて

6-1　非ウォータフォールUCDのすゝめ 116

❶プロセスの違い／❷コミュニケーションスタイルの違い／❸「少しずつ」の意味の違い／❹アジャイル VS UCD

6-2　アジャイルUXの潮流 121

❶アジャイル UX 小史／❷アジャイル UX の基本原則／❸アジャイルUX の基礎理論

6-3　アジャイルUXによる開発 125

❶コンセプト／❷計画／❸開発／❹リリース

章末Column■ RITE メソッド 129

参考文献 132　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

▪ UXの国際規格 ……… 6▪もはや手遅れ ……… 12▪激安ユーザテストの系譜 ……… 43

▪謝礼の相場 ……… 52▪ DIY 書画カメラ ……… 77▪ PinP ……… 81▪観察メモ ……… 87

▪ユーザは本当に「お得」がお好き？ ……… 93▪タスク達成状況一覧表 ……… 102

▪小さな変更、大きな成果 ……… 109▪勝手にテストしない ……… 113

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

ちょうどジャケットが欲しかったので…

このサイトでお好きな商品を1点購入してください。

ユーザテストユーザテストの基本はとても単純─ユーザにタスク（作業課題）を提示して、その実行過程を横で観察するだけ

22

Chapter

2　

ユーザテスト入門

ユーザテストとは2-1

│ ❶─百聞は一見にしかず� │　ユーザがパソコンと“格闘”する様子を、開発者やデザイナがマジックミラーで仕切られた“隠し部屋”から真剣なまなざしで観察している─『ユーザ

テスト（user testing）』の事例としてよく紹介される光景です（なお、ユーザテストは『ユーザビリティテスト（usability test）』と同義語です）。

　日本でもこのようなテストが頻繁に実施されるようになりました。テストの対象はウェブサイトや携帯電話のほか、パソコン用ソフトウェア、OA機器、デジタル家電など多岐にわたり、テスト手法も様々なものがありますが、その基本はとても単純なものです。

　1.　ユーザにタスク（作業課題）を実行するように依頼する。　2.　ユーザがタスクを実行する過程を観察、記録する。

１　

ユーザテストとは

22

　たったこれだけのことなのですが、ユーザテストはまさしく「百聞は一見にしかず」という体験を開発チームに与えてくれます。

│ ❷─思考発話法� │　前述のように、ユーザテストの基本は非常にシンプルですが、1つだけ“秘訣”があります。それはユーザに思ったことを口に出しながらタスクを実行してもらうことです。こうすることでユーザの認知プロセスが明らかになり、操作の失敗や不満の原因を論理的に分析できるようになります。これを『思考発

話法（think aloud method）』といいます。

あるファッション通販サイトにおける、女性ユーザの行動と発話の例

1.　商品の詳細ページで商品写真を閲覧している。

　「このピンクのジャケットよさそうだな。これにしよう！」

　「私のサイズはＭなので……」

2.　サイズ指定欄の[Ｍ]アイコンをクリックする。

3.　画面を下部までスクロールして首をひねる。

　「あれ？　購入ってボタンがない？」

　「……Mサイズは品切れってことなのかな？　試しにLを押してみよう」

4.　サイズ指定欄の[Ｌ]アイコンをクリックする。

5.　画面を隅々まで確認する。

　「やっぱり（購入）ボタンはない!?」

6.　首をひねりながら、何度も画面をスクロールする。

　「もしかすると……ピンクは品切れなのかな？　試しに白を選んでみよう」

7.　カラー指定欄の[白]のアイコンを選択する。

　「あっ、購入ボタンが出てきた。でも本当はピンクがいいんだけど……」

8.　カラー指定欄の[ピンク]のアイコンを選択する。

　「あっ、今度は購入ボタンが出ている。どうして？？？」

※このサイトではサイズと色の両方をユーザが指定しない限り購入ボタンが表示されない仕様になっている。これは「誤購入を防ぐ」ためであるが、上記の例のように、デフォルトで表示される商品写真が希望する色と一致した場合、色を改めて指定しないといけないことに気づきづらい。

22

Chapter

2　


│ ❸─3つの観察ポイント� │　ユーザテストでは“生”のユーザの言動を目の当たりにするので、開発者やデザイナは、その情報量の多さに圧倒されてしまうかもしれません。ユーザの行動を漫然と観察するよりも、ポイントを絞って観察した方が効果的です。ユーザテストの観察ポイントは3つあります。

　1.　まず、ユーザは独力でタスクを完了できただろうか。もし完了できなかったとすれば、その製品は『効果（effectiveness）』に問題があるといえます。これは端的に言えば、その製品は「使いモノにならない」ということであり、もっとも深刻な問題です。

　2.　次に、ユーザは無駄な操作を行ったり、戸惑ったりしなかっただろうか。独力でタスクを完了できたとしても、その間に、ユーザを考え込ませたり、遠回りさせたりするような製品は『効率（efficiency）』に問題があるといえます。

　3.　さらに、ユーザは不安や不満を感じていなかっただろうか。たとえ、ユーザがほぼ想定ルートを通って独力でタスクを完了できたとしても、途中で不愉快な思いをさせるような製品は『満足度（satisfaction）』に問題があるといえます。ユーザは明示的に不満を表明する場合もありますが、表情や態度で暗示的に不満を表明している場合もあります。

　一般に、ユーザテストとは「効率問題（＝ユーザの無駄な操作や戸惑い）」を発見することが目的だと考えている人が多いと思います。確かに、テストで発見される問題点の多くは効率問題です。

　しかし、より深刻な「効果問題（＝ユーザがタスクを完了できない）」が潜んでいる可能性を意識してテストを実施しないと、せっかく開発の初期段階からテストを行ったのに、結局は使いモノにならない製品をリリースしてしまうという結果になりかねません。

効果

効率

満足度

ユーザビリティ３要素効果・効率・満足度─すべてを満たして、はじめてその製品はユーザブル（使用可能）であるといえる

１　

ユーザテストとは

22

　さらに「満足度問題（＝ユーザの不安や不満）」を軽視してはいけません。満足度問題も程度によっては、ユーザがその製品を二度と使ってくれなくなるからです。

22

Chapter

2　


│ ❶─形成的評価� │　期末試験、入学試験、就職試験、昇進試験、資格試験、etc。私たちは様々な場面で様々な評価を受けてきました。このような評価はその目的によって『総

括的評価（summative evaluation）』と『形成的評価（formative evaluation）』

に大別できます。

　総括的評価とは、学習成果の総合的な達成度合いを“測定”することを目的とした評価です。総括的評価は、学校の期末試験のように一定の学習が終了した後に実施して、通常、得点化を行います。得点化したデータはさらに分析して、得点の分布や平均点を算出したりします。

　形成的評価とは、小さい学習単位ごとに、どれくらい理解できているか、理解するためには何をしなければならないかをフィードバックするための評価です。形成的評価は得点をつけることが目的ではなく、理解度を“改善”することが目的です。

ユーザテストの基本理論2-2

　皆さんはTOEIC（トーイック）を受験したことはあるでしょうか。TOEIC

は英語によるコミュニケーション能力を評価する世界共通のテストで、特にビ

ジネス英語能力の測定では定評があります。多くの企業が入社試験や海外派遣

要員の選抜に用いており、管理職への昇進条件にしているところもあります。

　TOEICテストの結果は10点から990点までのスコアで返されます。英語が

苦手で、TOEICを受験するのが初めての人だと400点くらいしか取れないか

もしれません。国際化が進んだ現代のビジネス環境では、多くの企業で600

点くらいは求められますし、海外で仕事をしたければ800点以上は必要でし

2　

ユーザテストの基本理論

22

　TOEICは典型的な総括的評価です。あなたの英語力を客観的なスコアで表して比較評価を可能にしてくれます。あなたは、スコアを履歴書に記載して転職に役立てたり、社内で昇進を有利に進めるために利用できますが、あなたの英語力について具体的に何が問題なのか、どうすれば上達するのかは教えてくれません。総括的評価を繰り返しても品質の改善にはつながりません。

　一方、英会話スクールの先生が生徒の発音の間違いを正したり、英文メールを添削するのは形成的評価です。繰り返し行われる形成的評価を通じて生徒の英語力（読む・書く・聞く・話す）は飛躍的に向上します。ただ、その能力がどれくらいなのかを第三者に客観的に証明するためには、総括的評価を必要とします。

　本書で紹介するユーザテストは形成的評価を目的としています。つまり、ス

コアをつけることが目的ではなく、具体的にどこに問題があるのか、なぜ問題

が発生したのかを明らかにして、製品の品質を改善することを目的としていま

す。

ょう。

　仕事で英語が必要だけれど、TOEICのスコアが悪かった場合はどうすれば

よいでしょうか？　当然ですが、テストを繰り返し受験するだけでは、スコア

はほとんど上がりません。TOEICのスコアを上げるには、英語力をつけない

といけません。そのためには、例えば英会話スクールに通って英語を勉強する

ことになります。

　英会話スクールでは、先生から様々な課題が与えられます。教室内で、先生

は発音の間違いをその場で修正してくれます。ホームワークで作成した英文メ

ールを提出すれば、文法やスペルの間違いを細かく添削してくれます。そうや

って、具体的にどこが間違っているのか、なぜ間違っているのかを指摘しても

らいながら、徐々に英語力を身につけていきます。半年、１年と英語の勉強を

続けて、その後TOEICを再度受験すれば、TOEICスコアは（かなり）アップ

するはずです。

22

Chapter

2　


│ ❷─反証アプローチ� │　ユーザビリティを“実証”するのは困難な作業です。いったい何人のユーザで、何種類のタスクを検証すれば、その製品がユーザブルであることを証明できるのでしょうか。例えば、私が使っている携帯電話は主なメニューだけで115項目あります。そのすべてを限られた設計期間の中で検証するのは、コストとスケジュールの制約から事実上不可能でしょう。

　そこで、まず「この製品はユーザブルである」という仮説を立てます。もちろん、何の根拠もなしに仮説を立てるわけにはいきませんが、ユーザ中心設計のプロセスに沿って設計された製品ならば、取り敢えず“ユーザブル（つまり、効果・効率・満足度いずれも阻害していない）”であると仮定することは、それほど乱暴な議論ではありません。

　次に、その仮説を検証するために、実際に何人かのユーザにその製品を使っていくつかの重要なタスクを実行してもらいます。これがユーザテストです。もし、ユーザテストで効果・効率・満足度を阻害している具体的な問題点が見つかれば、それは「仮説を否定する証拠＝反証」になります。つまり「この製品はユーザブルである」という仮説は崩れます。

　仮説が崩れたからといって悲観する必要はありません。そもそもユーザテストでは積極的に反証を見つけようとしているので、問題点が見つかるのは当たり前のことです。それに、思考発話法によるテストならば問題点の発見だけでなく、その原因まで明らかになるので、開発チームはすぐに改善案の検討を始めることができます。そして、見つかった問題点をすべて改善すれば改めて仮説が成り立ちます。

　一方、どんなにテスト結果を分析しても問題点が見つからなければ、評価者は反証を提示できません。もちろん、もっと多くのユーザでテストしたり、他のタスクを実行すれば問題点が見つかる可能性はありますが、そのような議論を続けていては永遠に結論に到達しません。そこで、反証が見つからない場合

2　


22

は仮説を受け入れます。つまり「この製品はユーザブルである」と結論づけるのです。

　ユーザテストは製品のユーザビリティを実証するものではありません。テストに合格したといっても、それはあくまで「今のところ反証がない」というだけのことです。だから、私たちは製品をリリースした後も、ユーザからのフィードバックを積極的に受けつけて、絶えず反証の有無に注意し続けなければいけないのです。

│ ❸─5人のユーザ� │　ユーザビリティ工学の開拓者ヤコブ・ニールセン（Jakob Nielsen）は、テストする人数と発見できるユーザビリティ問題の数に関する公式を明らかにして、「5人のユーザでテストすれば、ユーザビリティ問題の大半（約85％）を発見できる」という説を唱えました。

　　　　N（１−（１−L）n）N ：デザイン上のユーザビリティ問題の数（潜在的なものも含む

ので架空の値）L ：１人のユーザをテストして発見できるユーザビリティ問題が

全体に占める割合（ヤコブ・ニールセンは経験値として0.31を提示）

n ：テストするユーザ数

　例えば、この公式にL＝0.31、n＝5を代入すると「0.8436N」となります。仮に100個のユーザビリティ問題が潜在的に含まれている製品ならば、5人でテストすると「84.36個」の問題点が発見できると期待されます。

　この公式をもとにグラフを描くと興味深い考察が得られます。1人目のユーザからは最も多くの問題点（全体の約3分の1）が発見されます。2人目、3人目と回数を重ねるうちに新たに発見される問題点は減っていき、5人を超える

100%

85%75%

50%

25%

0%0 3 65

被験者の数

発見されるユーザビリティ問題

9 12 15

被験者5人で85％

ユーザテストは５人で十分ヤコブ・ニールセンは経験則に数学モデルを当てはめて、被験者数と問題点の数の関係を明らかにしようとした

23

Chapter

2　


と新たに得られる知見はほとんどありません。

　実はユーザテストの現場では「3人目くらいまでは新たな問題点の発見が続くが、4人目以降では新たな発見は少なくなってくる」という経験則が以前から知られていました。ヤコブ・ニールセンは、これに数学モデルを当てはめて理論的に実証しようとしたのです。

　この公式は、それまでの大規模な実験を前提とした学術的なユーザビリティに対して、費用対効果に優れた実務的なユーザビリティが普及するきっかけとなりました。膨大なコストと時間を費やしていたテストの85％の成果が、わずか5人のユーザをテストするだけで得られることが明らかにされたのですから。

　もちろん、この公式に対して他の研究者からは多くの反論がありましたが、開発の現場では徐々に支持が広がり、現在では、何十人もテストするのではなく5 〜 6人の小規模なテストを行うことが世界標準になっています。

2　


23

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

リクルート求人広告のように、リクルート条件は簡潔にまとめることができる

22

Chapter

2　


│ ❶─リクルート� │　まずは協力してくれる『被験者（subject/participant）』がいないことにはユーザテストは始まりません。被験者を集めることを『リクルート（recruiting）』

といいます。当然ながら、テストの被験者は誰でも構わないというわけではありません。ターゲットユーザで、かつ、今回のテスト目的に応じた条件を満たした人でなければなりません。そのうえ、テストはある特定の日時に行いますので、その日時に会場まで足を運んでくれる人という条件も加わります。

　そういった条件を満たした人を探すために、通常、調査会社に依頼してパネル（登録モニタ会員）を対象に小規模なインターネット・アンケート調査を行います。複数項目のアンケートに回答してもらって、その中からなるべく条件を満たした人を抽出してアポイントを取ります。最終的には「被験者リスト」が調査会社から送られてきます。

ユーザテストの実務基礎2-3

○○に関するインタビュー

インタビューガイドユーザテストは“台本”に従って進行する。インタビューガイドにはテストのすべてが記載されている

3　

ユーザテストの実務基礎

22

│ ❷─テスト設計� │　ユーザテストでは被験者に何らかの作業をしてもらいます。例えば、オンラインショップで商品を購入してもらったり、会計ソフトを使って確定申告を行ってもらったり、携帯電話で音楽をダウンロードしてもらったりします。これを『タスク（task）』といいます。タスク設計はユーザテストの成否を左右する重要な要素です。

　タスク設計を終えたら『インタビューガイド（interview guide）』を作成します。インタビューガイドには、被験者の入室から退室までの流れ、質問やタスクの提示順序、時間配分、そしてインタビューアが話す内容（スクリプト）がすべて記載されています。また、被験者がタスクを実行する上で必要な情報は、口頭で伝えるよりも、紙に書いて渡した方が確実に伝わるので「情報提示カード」も作成します。

　なお、どんなに綿密にテスト設計を行っても、実際にテストを行うと予想外の事態が発生します。もちろん、被験者の行動が予想外なのは織り込み済みですが、インタビューガイドや情報提示カードの内容に問題が見つかることも少

実査当日の作業フロー実査当日は「受付〜お見送り」の手順を繰り返し行う

受付

撮影許可とNDA

インタビュー

タスク実行観察謝礼とお見送り22

Chapter

2　


なくありません。そこで、事前に『パイロットテスト（pilot test）』を行います。

│ ❸─実　査� │　本番のテストは『ユーザビリティラボ（usability lab）』を使って行います。ユーザビリティラボはテスト専用の施設で、インタビュールームにはパソコン、カメラ、マイクなどが設置されており、被験者がタスクを実行する様子をマジックミラーで仕切られたモニタルームから観察、記録できるようになっています。

　予定の時刻になると、被験者をインタビュールームに案内して、所定の席に座ってもらいます。インタビューの目的を簡略に伝えた後、撮影許可と情報開示禁止同意（NDA：Non-Disclosure Agreement）という2種類の契約を交わします。

　テストでは、まず事前インタビューを行います。事前インタビューの目的の半分は、被験者との信頼関係構築（ラポール）です。会話することで緊張をほ

プロトコル分析テスト映像からユーザの行動と発話を書き出して詳細に分析する

3　

ユーザテストの実務基礎

22

ぐし、なるべく平常心でタスクに取り組んでもらえるようにするのです。

　そしてタスク実行観察に移行します。被験者がタスクを実行している間、インタビューアは横で観察を続けます。被験者の発話が止まったら、「今、何を考えているのですか？」「どうなると思っていたのですか？」といった質問を被験者に投げかけて、発話を始めるきっかけを与えます。

　一通りタスクが終了したら簡単に事後インタビューを行います。所定の時刻がきたらインタビューを切り上げて、被験者に謝礼を渡して、お見送りします。

│ ❹─分析／レポート� │　実査が終わると、テストのビデオ映像を見直して記録を作成します。このようなユーザの行動と発話を記録したものを『プロトコル（protocol）』といいます。心理学の実験などで行うプロトコル分析は、被験者のちょっとした仕草さや、躊

ちゅうちょ

躇した時間まで記録するといった非常に詳細なものですが、ユーザテストの記録ではそこまでの精度は求めません。

　記録が作成できたら、被験者1人ずつのテスト記録を丹念に読み直して、ユ

22

Chapter

2　


ーザビリティ問題を発見していきます。すべての問題点をリストアップして、それらを分類したり重要度を判定したりします。

　最後に、これまでのすべての情報をまとめ上げてレポートを作成します。文字がぎっしり詰まった長文のレポートは非常に読みづらく、テストで発見された問題点のポイントが設計者に伝わりにくくなってしまいがちです。画面ショットやビデオクリップも用いて、なるべく「見てわかる」ように解説します。

│ ❺─期間と費用� │　ユーザテストのスケジュールは4週間前後が標準的です。

　このようにユーザテストは準備から完了までに、それなりの手間と時間がかかる仕事なので、評価対象が準備できてからテストの計画を始めたのでは手遅れになってしまいます。当初からテストを組み込んだプロジェクト計画を立てておかないと、テスト結果を活用することはできません。

　また、ユーザテストの費用は決して安くありません。費用は基本的にはテスト時間と被験者数によって決まりますが、リクルートの難易度（出現率の低い被験者を集める場合など）や使用する設備（アイ・トラッキングシステムを使う場合など）などによってかなり変動します。

　正規のラボを使って１時間半のテストを被験者10人で行う場合、日本のコンサルティング会社にすべての作業を依頼すると、おおよそ200万円くらいの予算を想定しておけば、ほぼ間違いないと思います。

・テスト準備

　─リクルート：約2週間

　─テスト設計：約1週間（※テスト設計はリクルートと並列で行います）

・実査：2 〜 3日

・分析／レポート：1 〜 2週間

4　

DIYユーザテストのすゝめ

22

│ ❶─軽量化の波� │　ソフトウェア開発の新しい手法として、迅速で臨機応変な『アジャイル開

発（Agile Software Development）』が急速に普及しています。アジャイル開発では製品を小さな機能に分割しながら、1 〜 4週間という短期の開発＝『イ

テレーション（iteration）』を反復的に行います。各イテレーションでは設計、実装、テストといった開発に関わるすべての工程を行い、イテレーションの終了時点では小さいながらも「出荷可能」なレベルの機能を完成させます。

　ところが、前述のように従来のユーザテストは約4週間を必要とします。アジャイル開発チームにとって4週間というのは少なくとも1イテレーション、場合によっては4イテレーションにも相当します。当然ながら、そんな“膨大”なリソースをユーザテストだけに費やすことは許されません。

　また、Ruby on Railsのような生産性の高い開発環境や、クラウド・コンピューティングの普及によって、近年のソフトウェア開発プロジェクトはそれほど資金がかからなくなっています。例えば『リーンスタートアップ（Lean

startup）』という起業手法では、期間は1 〜 3 ヶ月程度、費用も数百万円以内（数十万円の場合もある）で新たなサービスを立ち上げてしまいます。

　このような小規模のプロジェクトでは、従来のコスト感覚のユーザテストは事実上不可能です。例えば総予算が500万円のプロジェクトで、1回のユーザテストのためだけに200万円を投入することは、経営管理上あり得ないことだからです。

DIYユーザテストのすゝめ2-4

22

Chapter

2　


│ ❷─Do-It-Yourself!� │　設備の整ったユーザビリティラボに加え、大規模な登録モニタや、心理学や人間工学の知識を持った専門のインタビューアを取りそろえて、テストの企画からレポートまで一貫したサービスを提供してくれる専門の会社もあります。

　予算が確保できるならば、そういった専門の会社にテストを依頼するのは無難な選択肢だと思います。被験者のリクルーティング、タスクの設計、インタビューの技術、プロトコル分析、ビデオ編集……、専門家が使うノウハウを数え上げればきりがありません。こういった複雑な業務を専門の会社に依頼できれば、あなたは心おきなく製品の開発に専念できます。

　しかし「予算がないからテストはしない」という選択肢だけは選んではいけ

ません。開発者が机上で意図したとおりには、ユーザは製品を使用してくれま

せん。テストしないということは、「使いモノにならない製品をリリースする」

という大きなリスクを犯すことになります。

　予算がなければDo-It-Yourself! ─自分たちでやりましょう。それほど心配することはありません。人脈を駆使すれば被験者は見つかります。社内の会議室にビデオカメラを設置すればラボの代わりになります。高度なインタビュー技術を使わなくても、黙って横で観察するだけで「百聞は一見にしかず」という発見があります。そして誰も読まない分厚いレポート作成に時間を費やすよりも、開発チームみんなで改善案を検討し、素早く問題点を修正するのです。

　そもそも私たちのゴールは「テストを実施」することではありません。私たちの本当のゴールは「製品を開発」することです。ユーザテストは手段の1つに過ぎません。ですから、どんなに見た目が貧相なテストであったとしても、製品の品質向上に貢献すれば“それで十分”なのです。

活動の主体

正規ユーザテスト DIYユーザテスト

被験者

活動の場所

成果物

その他

専門のコンサルタント

調査会社の登録モニタ

マジックミラー付きの専用ラボ

立派なレポート（動画付き）

見学時には豪華弁当付き！

あなたと同僚

友達の友達の友達…

会議室や空きスペース

メモ書き程度のレポートと対話

コーヒー飲み放題！

正規ユーザテストとDIYユーザテストの比較

4　


22

│ ❸─80対20の法則� │　8割は2割からもたらされる─パレートの法則とも呼ばれている経験則です。この法則を「要素の8割は価値が低いので不要である」と解釈するのは全くの誤解ですが、「8割の価値をもたらす2割の要素にもっと注目しよう」とするのは正しいアプローチです。すべてに100％を求めていては、ヒト・モノ・カネはいくらあっても足りないからです。

　本書で紹介するDo-It-Yourself（DIY）方式のユーザテストは決して“安物”ではありません。無駄は排除しますが、本質的な価値を損なうような無謀な簡略化ではありません。ユーザテストの企画から完了までのプロセス自体は変わりませんし、テスト設計の内容も全く同じです。しかし、例えば見学時の“豪華な弁当”や、マジックミラーで仕切られた（暗くて眠くなる）観察室はユーザテストの本質的な価値ではないでしょう。

　また、DIYユーザテストの成果は正規の“八掛け”ではありません。被験者数が同じであれば、発見される問題点の数は理論的に同じですし、開発チームの技量が同じならば、解決案の水準においても何ら差は生じません。それどこ

23

Chapter

2　


ろか、短期間・低コストというメリットを活かせば、これまでテストを行えなかったプロジェクトでもテストが可能になったり、同じ予算ならば多くの回数のテストが行えるので、総合的に見れば正規のテストよりも大きな成果が期待できるのです。

│ ❹─DIYの基本原理� │　DIYユーザテストの基本原理は代用です。ただし、それは正規品を“まがい物”に置き換えるという意味ではありません。本質的な価値を見極めて、それをもっと短期間・低コストで実現するように柔軟に発想するのです。

◎人脈を活かす

　「友達の友達のさらに友達……を6回繰り返せば地球の人口を超える、つまり私たちは世界中のどんな人とでも（間接的には）つながっているのだ」という説があります。これは『シックス・ディグリー理論（six degrees of

separation）』と呼ばれており、ソーシャルネットワークサービスの原点だとも言われています。もちろん、現職の大統領や人気絶頂のアイドルと友達になることは現実には不可能だと思いますが、本気になって人脈をたぐっていけば、想像以上に幅広い人々とつながりがあることに気づくでしょう。

　DIYユーザテストでは、あなたの人脈を使ってリクルートします。個人の人脈に頼るというと随分と狭い世界をイメージするかもしれませんが、年賀状を100枚くらい出していれば全く心配いりません。なぜならば、１ディグリーで100人、2ディグリーで1万人、3ディグリーで100万人─この時点で既に日本最大級の調査会社の登録モニタ数に匹敵するからです。

◎手近な品を活用する

　私たちは普段、専用品だけを使って生活しているわけではありません。例えば、ドアストッパーの代わりに材木の切れ端を使ってみたり、サイドテーブルの代わりに丸椅子を使ったりします。確かに専用品は洗練されていますが、代用品でも機能としては大差がないということは少なくありません。

4　


23

　例えば、会議室を可動式のパーテーションで仕切れば、即席のユーザビリティラボになります。テスト用のマシンは社員共有のノートPCです。差し当たり手元にあるiPhoneでも動画の撮影は可能ですし、家に帰れば年に数回しか使わないビデオカメラと三脚が押し入れの奥にしまってあるかもしれません。このように、ちょっと想像力を働かせて自分の周りを見回せば、テスト機材はゴロゴロ転がっているのです。

◎アナログに分析する

　高価な専用の分析ソフトウェアを使って、複雑なマクロを組んでデータを解析する─「データ分析」というと一般にそういうイメージが強いですし、確かに定量データの場合はあながち的外れではありません。しかし、定性データ

（質的データ）の場合は全く状況が異なります。

　定性データは演算できません。作業の効率化のためにパソコンは活用しますが、本質的にパソコンでは分析できないのです。そこで専門家はデータを断片化してカードに書き出して、壁やホワイトボードに貼ってソート（並び替え）するという“超”アナログな作業＝KJ法を今でも使っています。DIYユーザテストでは、あなたも専門家と同じようにアナログに分析すればよいのです。

◎対話を重視する

　画面ショットやビデオクリップを駆使して、データ編も含めれば一抱えもありそうな立派な報告書が2週間後に到着。しかし、製品の開発に直接携わっている開発者やデザイナにとって、それは無用の長物ということは少なくありません。テストを見学した彼らは、既に自分たちで改善案を検討して設計変更に取りかかっているからです。

　DIYユーザテストでは、関係者には必ずテストを見学してもらいます。そして、誰も読まない分厚いレポートの作成に時間を費やすのではなく、開発者やデザイナと一緒になって問題点の解決方法を考えることに時間を費やすのです。ユーザテストのゴールは製品の品質向上です。レポートの枚数と製品の品質は全く関係ありません。

22

Chapter

2　


│ ❺─ユーザテストのアンチパターン� │　DIYユーザテストは製品の品質向上に大きく貢献してくれます。ただ、未経験の人が陥りがちな“落とし穴”も少なくありません。ここでは代表的な失敗パターンを指摘しておきましょう。

　製品ができあがってからテストする─開発者やデザイナには一般的に悪い癖があります。それは、テストの実施時期を遅らせたがることです。「中途半端なものをテストしても意味はない。デザインやコーディングが完了してからテストすべきだ」と考えるのです。しかし、これは大きな間違いです。製品が完成してからテストして、もし製品の基本設計に関わるような問題が見つかった場合、もはや修正は不可能です。どうせ失敗するのならば「早期に失敗」するべきなのです。

　初心者でテストする─被験者が初心者の方が、より多くの問題点を発見できると考えるかもしれませんが、それは全くの間違いです。マウスやキーボードがまともに操作できない初心者をリクルートしてしまうと、それはテストではなく“パソコン教室”になってしまいます。テストには十分な技量とモチベーションを持ったユーザに来てもらいます。そういった“当然できるはず”のユーザが悪戦苦闘するからこそ、開発者やデザイナは大きな衝撃を受けて、根本的な製品仕様の変更を決断できるのです。

　グループインタビュー形式でテストする─マーケティングリサーチで用いられるグループインタビューと勘違いして、5人のユーザを1部屋に集めて同時にテストしてはいけません。ユーザテストでは必ず1人ずつ個別にテストします。現実の場面でも、ほとんどの場合、ユーザは1人で製品を操作しているのですから。

　ユーザに質問する─ユーザに「どこが悪いと思いますか？」「どう改善すればよいと思いますか？」といった質問をしてはいけません。ユーザは分析者でもなければ、デザイナでもありません。製品の何が問題で、それをどう改善

4　


　ディスカウント・ユーザビリティの元祖はヤコブ・ニールセンです。学術的

なユーザビリティが支配していた時代に、彼は5ユーザテストやヒューリステ

ィック評価法を用いた実用的なユーザビリティ＝ディスカウント・ユーザビリ

ティエンジニアリングを提唱しました。

　ただし“ディスカウント”といっても、それは「研究室にこもった白衣を着

た博士と助手に頼むよりは安い」というレベルです。実際、彼が代表を務める

ニールセン・ノーマン・グループの価格表を見ると◎専門家評価：$38,000、

◎ユーザテスト：$25,000、◎ユーザテスト講習会：$23,000＋旅費……、

私たちの感覚では決して“安い”と言えそうにありません。

　これを見て「海外はユーザビリティの予算が何百万円もある！　日本は遅れ

ている！　我々にももっと予算を！」と誤解してはいけません。海外でもユー

ザテストに200万円使えるプロジェクトはごく僅かです。

　では、どうしているのか？

　Do-It-Yourself! ─その第一人者がスティーブ・クルーグ（Steve Krug）で

す。「Don't Make Me Think（邦題：ウェブユーザビリティの法則）」の大ヒッ

トで一躍人気者になった彼は、そのノウハウを軽妙な語り口で全米に伝道して

回っています。

　そんな彼の第二弾が「Rocket Surgery Made Easy」です。風変わりなタイ

トルですが、「ロケット手術」とは“すごく難しい（と誤解されている）コト”

を皮肉った彼の造語で、要するにユーザテストを指しています。つまり、タイ

トルを意訳すれば「お手軽ユーザテスト・ガイドブック」といった感じでしょう。

　彼の主張は3点に集約できると思います。

◦定期的（月イチ／朝イチ）に小規模（被験者3人）なテストを繰り返そう！

激安ユーザテストの系譜

22

すべきかを考えるのは、当然ながら“あなた”の仕事です。ユーザテストにおいても「ユーザの声聞くべからず」なのです。

◦関係者にテストを見学してもらおう！

◦問題解決では最善を“尽くさない”ようにしよう！

　彼特有の“受け狙い”の感もありますが、その内容は私たち実務家から見て

も納得できるものです。特に、関係者に見学してもらうことの重要性と、その

ためのノウハウ（例えば“おやつ”をケチらない）は参考になりました。

　このようにディスカウント・ユーザビリティの主役はニールセンからクルー

グに代わりましたが、実は大本の原則は少しも変わっていません。

◦どんなテストでも、やらないよりはマシ

◦早い段階（プロトタイプ）でテストする

◦繰り返しテストする

　そして、これは今後も永遠に変わらないと思います。

スティーブ・クルーグ激安ユーザテストの伝道師。「Rocket Surgery Made Easy」は風変わりなタイトルだが、的確に本質を突いた彼独自の実用的ユーザテスト論が展開されている

22

Chapter

2　


平成 24 年 2 月 20 日　　第１版第１刷発行

著　者樽本徹也発行者竹生修己発行所株式会社オーム社郵便番号 101-8460 東京都千代田区神田錦町 3-1 電話 03（3233）0641（代表） URL http://www.ohmsha.co.jp/©樽本徹也 2012

アジャイル・ユーザビリティ─ユーザエクスペリエンスのためのDIYテスティング─

印刷　エヌ・ピー・エス　　製本　協栄製本ISBN978-4-274-21160-7　Printed in Japan

● 本書の内容に関する質問は，オーム社出版部「（書名を明記）」係宛，書状または FAX（03-3293-2824）にてお願いします．お受けできる質問は本書で紹介した内容に限らせていただきます．なお，電話での質問にはお答えできませんので，あらかじめご了承ください .

● 万一，落丁・乱丁の場合は，送料当社負担でお取替えいたします．当社販売管理課宛お送りください．

● 本書の一部の複写複製を希望される場合は，本書扉裏を参照してください．

〈著者紹介〉

樽本徹也（たるもと　てつや）

利用品質ラボ代表。ユーザビリティエンジニア／ 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

本文イラスト◆中西隆浩

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

Design