樽本徹也・著「アジャイル・ユーザビリティ」無料サンプル版（第２章全文）です。なお、PDF版をダウンロードしてAdobe Readerで「小冊子」として「A4用紙に印刷」して「中綴じ」すれば、実物大（A5版）のサンプル版が出来上がります。ぜひお試し下さい。

3. ア ジ ャ イ ル・ユ ー ザ ビ リ テ ィ
目 次
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
目
❶リクルート／❷テスト設計／❸実査／❹分析 / レポート／❺期間と費
次
用
v
2-4 DIY ユーザテストのすゝめ 37
❶軽量化の波／❷ Do-It-Yourself! ／❸ 80 対 20 の法則／❹ DIY の基
本原理／❺ユーザテストのアンチパターン

4. 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. 5-2 再設計 104
❶レポートよりも対話を／❷問題解決／❸反復デザイン
5-3 プライバシーと倫理 110
❶個人情報保護／❷倫理的責任
Chapter 6 ▶▶▶ UCDを超えて
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 vii
▪ユーザは本当に「お得」がお好き？ ……… 93 ▪タスク達成状況一覧表 ……… 102
▪小さな変更、大きな成果 ……… 109 ▪勝手にテストしない ……… 113

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

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

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

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

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

12. 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 点以上は必要でし

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

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

15. は仮説を受け入れます。つまり「この製品はユーザブルである」と結論づける
のです。
ユーザテストは製品のユーザビリティを実証するものではありません。テス
トに合格したといっても、それはあくまで「今のところ反証がない」というだ
けのことです。だから、私たちは製品をリリースした後も、ユーザからのフィ
ードバックを積極的に受けつけて、絶えず反証の有無に注意し続けなければい
けないのです。
│ ❸─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 人を超える

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

31. 〈著者紹介〉
樽 本 徹 也（たるもと てつや）
利用品質ラボ代表。ユーザビリティエンジニア／ 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