第22章 プロトタイプの検証
製品のアイデアを実際のユーザーの前でテストする
これまでの章で、私が、ハイフィデリティプロトタイプをどう位置づけているかはわかってもらえただろう。ハイフィデリティプロトタイプというのは、作るべき製品を表現して説明するためのいちばん基本的な方法であって、従来の紙ベースの仕様書よりも、製品開発チームにとってははるかに役に立つものだ。でも、このメリットは、あくまでもおまけのようなものにすぎない。ハイフィデリティプロトタイプを作るいちばんの目的は、製品についての理解をより深めて、最終的には、製品のアイデアを実際のユーザーといっしょに試すことにある。これをあらかじめやらないと、製品がその目的を果たせるかどうかを確実に証明できるものがない状態のまま、そんな製品をエンジニアリング部門に何ヶ月もかけて作らせることになってしまうからである。
この章では、プロトタイプのテストのやり方について説明する。この章はかなり長くなるので、あらかじめお断りしておく。とにかく、プロダクトマネージャーとしていちばん大切な仕事を 1つだけ挙げるとすれば、おそらくそれは、製品のアイデアを実際のユーザーといっしょにテストすることである。
もし、プロダクトマネージャーであるあなたの会社が大会社で、自前のユーザビリティテストのチームを抱えているならば、ぜひ、そのチームが、あなたのプロジェクトのためにできる限りの時間を割いてくれるようにしてほしい。仮に十分な時間を取ってもらえなかったとしても、こういうチームの人というのはものすごく使える人たちなので、ユーザーリサーチやユーザビリティテストの担当者と仲良くしておけば、大きな助けになることは間違いない。
会社として、こういう業務で外部のサービスを利用するための予算がとってある場合は、複数の優れた業者の中から 1社を選んで、ユーザビリティテストをやってもらうこともできる、でも、こういう業者を使うと、1回のテスト (ふつうは10人程度のユーザー) に 1～2万ドルはかかるので、たぶん、製品化までに必要なテストを全部外注できるほどの余裕はないだろう。
たいていの会社は、人手も資金も限られている。でも、それであきらめてはいけない。現実のユーザーでアイデアを試すことは、絶対にやらなければだめだ。最初にも言ったが、プロダクトマネージャーの仕事としては、まず間違いなく最重要任務なのだから。
そこで、自分たちでプロトタイプをテストする方法を説明しよう。ただ、誤解しないでほしいのだけれど、訓練を積んだ専門家のようにはうまくはできないだろうし、何回かやらないとコツを掴めないだろう。それでも、たいていの場合、製品に深刻な問題があれば、このテストで見つけることができるし、それが何よりも大切なことなのだ。
ここで注意してほしいことがある。ユーザビリティ、つまり、使用感 (人々が製品を実際にどうやって使うかを理解できるかどうか) をテストすることがとにかく重要なのだけれど、製品が有益で有用かどうか (人々が実際に使いたいと思うかどうか) をテストすることも必要なので、ここでは、この両方の面について議論したい。
テスト参加者を見つける
プロトタイプをテストする前に、テストに参加してくれる人を集めなければならない。業者を使う場合は、彼らがユーザーの募集もスケジュール調整もやってくれるので、ものすごく楽だ。自分たちでやる場合は、何通りかの方法がある。
• 第15章「ユーザーモニター制度」で説明したような仕組みがすでにあるならば、すぐ引き受けてくれそうなユーザーをそれなりの数でそろえられるだろう。こういう仕組みがまだなければ、それを作ることから始めよう。
• 企業向けの製品の場合、製品展示会は、ターゲットとなる顧客と出会うのに格好の場所となるだろう。
• 最近急激に増えているのが、地域情報のコミュニティサイトにテスト参加者を募集する広告を出す方法だ。参加要件は、具体的に書いてしまうのではなくその一歩手前ぐらいにしておいて、興味を示した候補者に参加確認する段階で、ふさわしい人を選抜すればいいだろう。
• 一般消費者向けの製品の場合は、自分の友達や家族の人脈が使える。でも、自分に近すぎる人でない方がいいし、製品のターゲットがハイテク業界でない限りは、ハイテク業界の人もなるべく避けた方がいいだろう。また、友人や家族の人脈を使った場合は、そういう人脈とは関係ない人も入れるようにしてほしい。
• すでにユーザーのメールアドレスのリストを持っているなら、そこから選んでもいい。マーケティングチームが候補者の絞り込みを手伝ってくれることもある。
• 会社のウェブサイトでボランティアを募集することもできるし、実際、主なウェブサイトの多くがそうしている。ただ、いずれにしても、応募者を選抜するときにきちんと確認して、アーリーアダプター系の人 (新しい商品やサービスなどを早い段階で導入するタイプの人) に偏らないように注意しなければならない。
• 中堅企業や大企業であれば、たとえば隔週金曜日というように定期的なプロトタイプテストの場を設けて、毎回 10～20人程度のユーザーに会社に来て 2～3時間テストをやってもらう、というやり方がお勧めだ。プロダクトマネージャーもその時間帯は同席して、ユーザーごとに複数のプロトタイプを試してもらう。この方法がお勧めなのは、参加者の手配や選抜をやる人が 1人いれば、製品開発チームとしては、決まった顔ぶれのテストユーザーがいてくれると当てにできるからだ。
• 路上でテストする、ユーザーが集まりそうな場所に行く、という方法もいつでも使える。Eコマース商品なんかであれば、ショッピングモールに行くという手もある。スポーツ関係の製品なら、スポーツバーに行く。製品がニーズをきちんと捉えているものであれば、みんな、そう問題なくちょっとの時間つきあってくれるはずだ。感謝の気持ちを表すちょっとしたプレゼントも持っていこう。そして、みんながそれぞれに信じていることを変えようとしている、などと思われないように振る舞おう。
• ユーザーに足を運んでもらう場合、特に企業向け製品であれば、おそらく時間に応じた報酬を支払う必要があるだろう。一般消費者向けの製品やサービスであれば、会社のロゴの入った帽子なんかを添えて、きちんと感謝の気持ちを伝えることで十分だろう。というのは、人々は、純粋に製品を作り出すことに貢献したいという思いがあって、好きな会社の製品であれば、なおさらそうしたいと思うからだ。
• テストのために足を運んでもらうように段取りしても、実際には来てくれない人の割合はかなり高いことも心得ておこう。それが現実だ。来ない人の割合が30％ にもなってしまうことがあるが、テストの前の日に 1人1人に電話することで、これを 5～10％ のレベルまで減らすことができる。留守番電話にメッセージを残すだけでも効果はある。ただ、電子メールを送る方法では、同じような効果はあまり期待できない。
テストの準備
ユーザビリティ (使用感) についてテストしたいタスク (ソフトウェアの作業項目) や、製品の価値を調べるためのインタビューで質問したいことを決めておく必要がある。
• あらかじめ、どのタスク (作業) をテストするか一通り決めておこう。ふつうは、どういうタスクであるかはかなりはっきりしている。たとえば、製品がメールソフトなのであれば、ユーザーは、メッセージを作る、新着メールを読む、メッセージを整理する、などの作業をする必要がある。他にも細々とした作業があるだろうけれど、主な作業、つまり、ユーザーがほとんどの時間を使うことになる作業に絞って進めてほしい。時間があるなら、あまりしょっちゅうはやらない作業も試すのも結構だが、主要な作業をしっかりとテストすることが大切だ。
• ユーザーとテストできるのは、各ユーザーとも 1回限りである。これは、今この製品がなかったとしたら、ユーザーはこの問題をどう思うのかを知るチャンスである。たとえば、新しいオンラインのレストラン評価サービスをテストするとしよう。その時、ユーザーには、プロトタイプのホームページからではなく、通常のまっさらな状態のブラウザーから始めてもらって、何をするのかを見るようにしよう。みんな、レストランについてはふだんどの評価・レビューサイトを見ているのか。レストランを探すのに、Google で検索するのか、Yahoo! で検索するのか、それとも OpenTable や Zagat のような情報サイトを見にいくのか。場所が近いかどうかで検索するのか、料理のタイプか、それとも、値段か。こういうものすごく貴重な情報は、プロトタイプのホームページから始めてしまうと手に入らない。プロトタイプには、どうしても、いろいろな前提条件が設定されてしまっているためだ。テスト参加者がプロトタイプでちょっとの間操作してしまうと、他と比べてプロトタイプのどこが気に入ったかを話してはくれるが、もはや、初めてそのサイトにアクセスしたときに感じたようには問題を考えることはなくなってしまう。
• さて、いよいよ参加者にプロトタイプを操作してもらうのだが、その前にまだやらなければならないことがある。テスト参加者がプロトタイプのホームページやランディングページを見たときに、それが何なのかがわかるか、特にどういうところに価値や魅力を感じたかを言えるかどうか、確認してほしい。もう一度言うが、テスト参加者は、いったんプロトタイプで操作を始めてしまうと、そのサイトに初めてアクセスするという状況はもはやなくなってしまう。だから、初めてアクセスしたときの反応を観察できるという機会を無駄にしないでほしい。ランディングページは、サイトに対する期待感と実際にそのサイトでできることとのギャップをつなぐ上で、思っている以上に重要なものだということがわかるだろう。
• テストの対象となる作業のやり方をユーザーが理解できたと確認したら、その時がそのユーザーと話すのにちょうどいいタイミングだ。1人で構成されるフォーカスグループであると考えてほしい。ふだん、その人は、同じことをやるために、別の製品やサイトを使っているのか。あるいは、それを手作業でやっているのか、それともネットを使わずに済む方法でやっているのか。このプロトタイプを使うと、その人がふだん使っているものと比べて、どのぐらいよくなるか。そして、お約束の質問、ネットプロモータースコア (NPS) も忘れずに聞いてみよう。自分がこの製品を友達に勧めようと思うかどうかに点数をつけたら、何点になるか。ユーザーは、プロトタイプをいじったので何が問題なのかを理解していて、プロダクトマネージャーは、その問題についてそのユーザーとものすごく中身のある話をすることができる状態だ。何よりも、そのユーザーが製品をどの程度評価しているか、判断することができる。
• 質問を数値化すること、たとえば 10点満点で何点かを答えてもらう、大まかな数値で答えてもらう、といったやり方も使える。これをやると、どのぐらい改善しているかを平均値の推移で追っていくことができるようになる。製品の価値を測定するのに私が気に入っているやり方は、実際は使用料金を取るつもりのないサービスであっても、いくらだったら払ってもいいと思うかを聞いてみることだ。これは、価値を測定する方法であり、また、特に、プロトタイプを変更していくたびに、その平均値がどの程度上がったり下がったりするかをたどることもできる。
• テストを始めるためには、完全なプロトタイプができあがるのを待つ必要はないことを覚えておいてほしい。主な作業から始めて、プロトタイプの別の部分まで来てそれ以上操作ができなくなったとしても、それで構わない。ユーザーが行き詰まったところで、「もしそこをクリアできるとしたら、その後どうなることを期待しますか？」と聞けばいい。行き詰まった先の方向性がすでに決めてあるかどうかに関係なく、この質問をするのはものすごくいい。方向性が決めてあるならば、それがユーザーの期待と合っているかどうかがわかるし、まだ方向性が決まっていなければ、次をどうするかについての重要な情報を手に入れられる。
テスト環境
次に、テスト環境をどのように準備するかについて説明しよう。
• 本格的なテストルームは、通常、マジックミラーかビデオモニターの他に、プロトタイプの画面とユーザーの正面を捉えることのできるカメラのような設備を備えている。これがあれば言うことはないけれど、非常に有益で価値のあるテストをするためにはぜひ必要、というものでもない。私はといえば、スターバックスで何度こういうテストをやったことだろう。ラップトップコンピューターが置けるほどの小さなテーブルと三脚の椅子があれば、十分テストできたものだった。実際、ある意味では、こういうやり方の方がテストルームよりもいい。この方が、ユーザーは実験用のネズミのように感じなくて済むし、もっとありのまま包み隠さずに答えてくれるかもしれない。
• 他にテスト環境としてぴったりなのが、ユーザーのオフィスだ。こちらが出かけて行ってテストのためのセットアップをするのは時間がかかるかもしれないけれど、ユーザーのオフィスに 30分いるだけで、いろんなことがわかる。ユーザーは、自分のオフィスだと、勝手知ったる場所なので、自然な態度でいろいろ話してくれることが多い。また、オフィスの中には手掛かりがたくさんあるので、ユーザーは、ふだんの実際の仕事の中でどうやって製品を使うかを思い浮かべながら話すことができる。テストしにいく側としては、オフィスがどんな感じかを観察するだけで、いろいろとわかることがある。スクリーンモニターはどのくらいの大きさか、コンピューターやネットワーク接続の速さはどうか、同僚とは仕事をしながらどんなふうにコミュニケーションしているのか、といったことだ。
• この手のテストを遠隔でやれるツールもある。ユーザーのマウスがどこにあって、ユーザーは何をクリックしているかを見ることもできるけれど、ユーザーの目の動きや身振りをじかに見るのと同じというわけにはいかない。基本的に、テストをたくさんやるのはいいことだけれども、遠隔でやるテストは、直接顔を合わせてやるテストの代わりにはならない。
• プロダクトマネージャーとしては、すべてのテストに参加する必要がある。これを人任せにしてはいけない。このテストの本当の意義は、できるだけ多くのユーザー、それも、製品のアイデアにじかに触れて何がしかの反応見せるユーザーと、直接話すことにある。外部の業者にテストの準備や運営を任せる場合でも、テストの最中はその場にいてほしい。プロダクトマネージャーほど製品を知っている人は他にいないからだ。それに、ユーザーのほんのちょっとしたためらいや困惑の表情からわかることもあるし、質問のニュアンスから、テスト参加者が製品の概念モデルや特定の機能を理解していないことがわかる場合もある。それに、業者がまとめた報告書では、おそらく重要な洞察がいくつか漏れているかもしれない。
• プロダクトマネージャーは (そしてインタラクションデザイナーも) 製品に近すぎるので、この手のテストを客観的にやるのは無理で、テストの成り行きや結果に傷つくか、自分が聞きたいことしか耳に入らない、といったことになるのではないかと考える向きもあるようだ。私は、優秀なプロダクトマネージャーやインタラクションデザイナーであれば、こういうことはすぐに克服すると思う。彼らは、最初のうちは製品の作りに問題があるものだということ、つまり、製品を最初から正しく作れる人はほとんどいないということを知っている。また、こういうテストから何かを得ることが、みんなをワクワクさせる製品を作るための近道であることも心得ている。だから、私は、うまくいかないリスクよりも、メリットの方がはるかに大きいと思っている。
• 理想的なのは、1人にテストを進めてもらって、別の人にメモを取ってもらうのがいい。2人が同じ場面に立ち会って同じ結論となることを確かめるのに、後で確認できる人がいるとものすごく助かる。とは言うものの、今ちょうど自分しかいないけれど、ラップトップもあって、テストもできる状態で、協力的なターゲットユーザーが目の前には待ち構えているという場面なのであれば、テストしてしまおう。問題はない。
• プロダクトマネージャーの他に、ユーザーリサーチャーかユーザビリティエンジニアもいっしょにいるなら、その人にテストをやってもらって、プロダクトマネージャーがメモを取るといい。そういう人がいない場合は、おそらくプロダクトマネージャーがテストをやることになるので、製品開発チームのだれかを呼んでメモをとってもらえばいい。ふつうはインタラクションデザイナーがいいが、ビジュアルデザイナーや他のマネージャー、あるいは、特にエンジニアなど、他のだれかに頼んでもいい。彼らにとっても、こういう経験から得られるものはたくさんあるだろう。
プロトタイプをテストする
さて、プロトタイプも準備できて、テスト参加者も決まり、テストの対象となるタスクと参加者に質問することも決まったところで、実際のテストをやるためのヒントやコツを説明しよう。
• テスト参加者を温かく迎え入れ、コーヒーかミネラルウォータ－のペットボトルを渡したら、なるべく早くプロトタイプの操作を始めてもらう方がいい。テスト参加者には、プロトタイプを試してもらった後で話を聞かせてほしいのだけれど、まずはまっさらな印象を教えてほしい、ということを伝えよう。事前に話せば話すほど、より多くの手掛かりを与えてしまうことになるので、その人にとっての本当の第一印象からはかけ離れてしまう。もし、ユーザーがプロトタイプの操作を始めるまでに 5分以上経ってしまったら、テストをする人たちはしゃべりすぎだ。
• テスト参加者を温かく迎え入れた後に、次のようなことをきちんと伝えよう。
(1) これはプロトタイプにすぎず、かなり初期段階の製品のアイデアであり、まだ現実の製品でもなんでもないこと。
(2) いい悪いにかかわらず、正直な意見を言ってもらっても、それでテストをする側が気分を害することはないこと。
(3) プロトタイプをテストするのであって、テスト参加者がテストを受けるわけではないこと。
合格したり不合格になったりするのは、テスト参加者ではなく、プロトタイプの方なのだ。
• テストをやるときは、ユーザーが「ユーザーモード」であって「批評家モード」にならないようにするために、できる限りのことをしてほしい。大切なことは、やるべきタスクをこなすために、ユーザーが簡単に操作できるかどうかであり、ユーザーが製品の価値を認めてくれるかどうかである。ユーザーは、ウェブページ上にある何かが見苦しいとか、外したほうがいい、変えたほうがいい、などと思うかもしれないけれど、そういうことはどうでもいい。時々、テストをやる人が見当はずれで、「このページで 3つ変えるとしたら、どこを変えたらいいか」などとユーザーに質問してしまうことがある。私にしてみれば、ユーザーがたまたまインタラクションデザイナーでもない限り、そういった質問に対する答えにはあまり興味はない。自分が本当にほしいものは何かをユーザーが知っているのであれば、ソフトウェアを作ることはずっと簡単だろう。だから、ユーザーが何を言うかではなく、何をするか、もっと注意して観察してほしい。
• テスト中に必要なスキルとして身につけておかなければならないのは、黙って見ているということだ。だれかがもがいているのを見ると、思わず手助けしたくなるものだけれど、ここはぐっとこらえないといけない。テストの間は、ひどく会話下手で、沈黙が苦にならない人間になりきろう。
• テストの結果として出てくるのは、主に次の 3つのケースだ。
(1) ユーザーは、まったく問題なく、だれの助けも借りずに作業を終えた、
(2) ユーザーは、多少もがき苦しんだりうめいたりしながらも、どうにか作業を終えた、
(3) ユーザーは、イライラを募らせて途中であきらめた。
時として、人は案外あっさりとあきらめてしまうこともあるので、ユーザーを元気づけてもうちょっとだけ頑張ってもらうようにする必要があるかもしれない。でも、ユーザーが本当にプロトタイプのサイトを離れて競合サイトに移ろうとしていると判断できる状況になったら、その人については、その時点で実際に操作を続けることをあきらめた、と記録すること。
• 一般的に、助け舟を出したり誘導尋問をしたりすることは、どんな方法だろうとやめた方がいい。ユーザーが、ページを上へ下へとスクロールしていて明らかに何かを探しているようなら、具体的に何を探しているのか尋ねるのは構わない。というのは、その答えはものすごく有益な情報となるからだ。ユーザーに考えていることをひっきりなしにしゃべらせる人もいるが、そんなふうにしゃべり続けること自体が自然な行為ではないので、ユーザーを評論家モードにしてしまう場合が多いようだ。
• オウムのように振る舞おう。これはいろんな意味で役に立つ。まず、相手を誘導してしまうことを防げる。もしテスト参加者が黙り込んでしまって、もはや沈黙に耐えられなくなったら、その人がやっていることを言葉にしてみよう。「今、右側にあるリストを見ているのですね。」 こうすることで、何をしようとしているのか、何を探しているのか、などについてユーザーに話すように促すことにもなる。逆に、質問された場合は、誘導するような返事を返すのではなく、質問の内容をオウム返しに言おう。「ここをクリックすると、新しいエントリーを作れるのですか？」、というように。そうやって問いかけられると、テスト参加者は、質問に答えたいような気になるので、そこから操作を続けることになって、「ええ、作れると思います。」と答えるかもしれない。オウム返しは、価値判断を誘導してしまうことも避けるのにも役に立つ。「よくできました！」と言いたくなったら、代わりに「新しいエントリーを作ることができましたね。」と言おう。最後に、重要なポイントをオウム返しすることによって、メモを取る人が大事なことを記録する時間を稼ぐこともできる。
• 基本的には、ここでやろうとしていることは、ターゲットユーザーが問題をどう考えているかを把握して、ソフトウェアが提供しているモデルとユーザーによる問題の捉え方との間で食い違っている部分や相容れない部分があるとすれば、それはプロトタイプの中のどの部分なのかを特定することである。ユーザーの直観に反するところ、と言ってもいい。幸いなことに、こういう部分を見つけたとしても、ふつうは修正するのは難しくないし、こういう課題を克服することは、製品の大成功につながる可能性がある。
• 身振りや声のトーンからもたくさんのことがわかる。テスト参加者が製品のアイデアを気に入らない場合は、嫌というほど明らかにわかるし、本当に気に入ってくれた場合もはっきりわかってしまう。試してみたプロトタイプが気に入った場合は、まず間違いなく、製品が発売になったらメールで知らせてほしいとお願いされる。うんと気に入ってもらえた場合は、一般公開の前に手に入れたがるものだ。私は、ドイツで顧客とのプロトタイプテストに参加したことがあるが、問題が何なのか、どのアイデアが気に入られて、どれがそうでないのかは、ドイツ語がしゃべれない私にもはっきりわかった。
プロトタイプのアップデート
このプロトタイプテストでポイントとなるのは、プロトタイプのどの部分を修正すればもっと価値を高めてもっと使いやすくすることができるのか、を見つけることだ。というわけで、できるだけ早く問題を修正しよう。
• 1回のテスト (ふつうは 6～8人のユーザーでやる) に使うプロトタイプと、テスト対象となるタスクやインタビューで質問することについては、結論が出るまでは変更するべきでないと考える人もいるが、私はそう思わない。経験的に、テスト参加者からのフィードバックにさっさと対応することによって、優れた製品までたどり着くプロセスを大いに早めることができることがわかっているからだ。何か大きな問題を修正しなければならないとわかるのに、何も8人のユーザーに立て続けに頭を殴られ続ける必要はない。とにかく前に進むことだ。問題を見つけたと思ったら、まだ 2、3人しかテストしていなくても、さっさと修正してしまおう。それよりもっと難しいのは、いつテストが終わったと判断するかだ。ふつうは、製品の価値を理解して高く評価してくれて、主なタスクをやり終えたユーザーが 6人続けば、テストはうまくいって、無事終了といえる。
• 製品化によって解決しようとしている問題に対して興味を示してくれる人がなかなか集まらない、あるいは、どうすれば製品をわかりやすく使いやすいものにしてターゲットユーザーに価値を認めてもらえるのか、どうしてもわからない、という判断になることがあるかもしれない。そんな時は、そこで中止して、アイデアを棚上げしよう。これを大きな失敗と思ってしまうプロダクトマネージャーもいる。私から見れば、市場で勝てない製品を作って発売するという無駄なコストをつぎ込むことから、会社を救っているのだ。言うまでもなく、その機会コストは、代わりにエンジニアリングチームが作ることができたであろう製品からの収益を逃さずに済んだ、ということでもあるのだ。
こうしてプロトタイプテストの進め方を一通り見ていくと、ややこしくて難しそうに感じるかもしれないが、実際やってみると、思ったよりもずっと簡単で効果がある。これは、自分で確かめて納得するのがいちばんなので、自分の製品かプロトタイプをラップトップに入れて、まだそれを見たことがない人のところに持っていって、さっそく試してみよう。
ここで、2つほど重要な情報源を紹介したい。みなさんにとってもきっと役に立つと思う。
まずは、スティーブ・クルーグ (Steve Krug) の「ウェブユーザビリティの法則」(中野恵美子訳、原題は Don’t Make Me Think) である。この本は主にインタラクションデザインについて書かれたものだが、後半3分の1は、ここで説明したようなインフォーマルテスティング (非公式に行われるテスト) の必要性を説いていて、役に立つヒントがたくさん書かれている。私は、ずっと、プロダクトマネージャーとデザイナーにこの本を読むように勧めてきたが、みなさんもぜひ買ってじっくり読んでみてほしい。
次に、私のお気に入りの製品テスト会社である Creative Good (www.creativegood.com) だ。この会社は、「リスニングラボ」というテスト法を専門にしている。これは、アドホックテスト (ad hoc testing または undirected testing) の中でも効果の高い手法で、製品の問題、特に機能や、デザインの大きな問題を検出することができるので、業績の劇的な改善につながるのである。多くのテスト会社は、製品をタスクごとにテストするが、この会社は製品の全体像を見ることに長けている。いちばん効果的な改善をするには、全体像を捉えることが大事なのだ。この章で説明した手法の一部は、この会社のテスト手法から採用させてもらった。
Inspired日本語版 