「グロースハック」とは、製品やサービスの利用方法・利用傾向などを調査し、その成果を製品・サービスの開発・改善にフィードバックするサイクルを繰り返すことにより、製品・サービスを大きく発展させる一連の手法のことです。
ユーザーテストの流れ
それでは、今回はユーザーテストの流れから説明を始めます。次の図はユーザーテストの流れを表したものです。
最初に行うのはタスク設計です。ここでは、課題であると思っていることや、追加する新機能、思ったように数字の上がらない画面などをタスク化します。ここでいうタスクとは、実際にユーザーに行ってもらう行動のことです。
タスクが設計できたら、それを使ってユーザーテストを行います。ユーザーテストでは、タスクを実際にユーザーに実行してもらってその様子を観察します。例えば「渋谷の居酒屋のバイトを探してください」というタスクを作ったとすると、ユーザーテストでは、ユーザーが渋谷の居酒屋のバイトをどういうふうに探すのか、実際に辿り着けるかどうか、探す中でどこに困っているか、ということを観察します。
ユーザーテストでは、思いもよらぬ使い方がいろいろと出てくるはずです。それらを課題としてとらえ、整理するのが次の作業です。
そして最後に、整理された課題から仮説案を作って検証します。検証のために実施するのがA/Bテストです。A/Bテストはこのような段階を踏んで行うと、より精度が高まります。
ユーザーテストは書画カメラとスカイプだけでOK
ところで、ユーザーテストに大げさな装置などは必要ありません。書画カメラ[1]とスカイプさえあればできてしまいます。僕らはこれをユーザーテストキットとしています。
こうしたユーザーテストキットを使っている理由は、スマートフォンです。ユーザーがスマートフォンをどういうふうに使っているのかを見る機会はなかなかありません。書画カメラでユーザーの行動を撮影すれば、タップの仕方から、スクロールのさせ方、片手で操作するか両手で操作するか、使い方に迷うしぐさまで細かく理解することができます。
また、被験者は周りに人がいると緊張してしまうものです。被験者が目の前にいなくても、スカイプなどを利用してコミュニケーションできる環境を準備しておけば、実際にユーザーに会っているような感覚が得られますし、サービスの課題も見つけられると考えています。
ユーザーテストの結果をどう整理するか
次に、ユーザーテストの結果をどう整理しているのかを説明しましょう。
基本的には、ユーザーテストに参加したメンバーも集まって課題を洗い出します。次の図の左側にある写真は、「ここでユーザーが困ったよね」「ここで一度止まったよね」とか、「ここが見にくかったのかな」「ここが分からなかったのかな」といったことを付箋に書いて貼り出した様子を撮影したものです。また、このタイミングで、「だったらこうした方がいいんじゃないか」みたいな改善案も出し合います。図の右下にある吹き出しなどは、そうして出た改善案を画面に貼り付けたものです。
付箋に書いた課題を表の形でまとめた状態が、次の図です。
表の2列目にある「カスタマーの不」列には、ユーザーである求職者の方が抱える課題や悩み、問題点というものをまとめてあります。そこから根本的な「不」の要因や原因は何だろうということを整理し（「不の根本的な要因」列）、本質的な問題点というものを洗い出します（「問題の本質」列）。
そして一番右の列に、問題点を解決するための「打ち手」を挙げています。単純な「ラベルのデザイン変更」という打ち手にも、フォントサイズなどA/Bテストにつながるようなものも出てきます。
こういった課題が明確になっていると、「そういえば機能テストを受けてくださった主婦の方は、こういうところにお困りだったよね」とか、「意外と操作が速かったから、サイズはこれくらいがいいんじゃないか」といったことを想像しながら、Webサービスを開発、改善できると思います。
A/Bテスト事例クイズ「一番良かったパターンはどれでしょう」
ここからは、僕らが実際に行ったA/Bテストの結果を使い、どれが一番成果が上がったパターンかをクイズとして、みなさんに考えていただこうと思います。
第1問：A/Bテストには足し算ではなく引き算の考え方もある
次の図をご覧ください。
オリジナルの画面を含め、図にある4つの画面のうちでコンバージョンレート（以下、CVR）が最も高かったのはどれだと思いますか？ なお、4つの画面はオリジナル画面に対し、ぞれぞれ次のように変更されています。
Aパターン：［WEB応募］ボタンと［電話応募］ボタンをなくし、［とりあえずキープ］ボタンだけにした
Bパターン：ボタンを全てなくした
Cパターン：［とりあえずキープ］ボタンを残し、［詳細を見る］ボタンを新規に追加した
第1問の正解
正解は、全く差がありませんでした。みなさんを騙したわけではありません。僕たちがA/Bテストを数多く行っている中で、差があまり出ない事例もけっこうあって、「3割当たればいいかな」という程度に考えています。ユーザーの気持ちになってもこういうことがあるので、差が出ないことがあってもめげないで続けてくださいというエールの意味でも、このような問題を出してみました。
すごく面白いのは、一番情報が少ないBパターンにおいてもCVRの有意差がないということは、実は必要のない情報をずっと出していたともいえます。この結果からは、A/Bテストには足し算ではなく引き算の考え方もあることを教えてもらいました。僕たちはけっこう学びのある事例だなと思っています。みなさんもいろんなA/Bテストをされるかと思いますが、いったん引いてみる、なくしてみると面白い結果が得られるかもしれません。
第2問 フラットデザインはCVRを増やすか減らすか
もう1つ、A/Bテストの事例を使ったクイズを出題しましょう。
左がオリジナルのパターン、真ん中がAパターン、右がBパターンです。変えているのは、画面上部にある職種名の表示方法です。
オリジナル：背景を凹ませて、リンクを表すアンダーラインを引いている
Aパターン：背景の凹みとリンクを表すアンダーラインともに削除した
Bパターン：背景の凹みをはずし、リンクを表すアンダーラインを残した
これら3つのパターンのうち、どれが一番CVRが高かったと思いますか？
第2問の正解
この事例ではちゃんと差が出ました。CVRが一番高かったのはBパターンでした。テキストにアンダーラインが引いてあると、ユーザーはそれがリンクであるとすぐ分かり「これ押せるんだな」と思うということが、学びとして得られました。
オリジナルのパターンはリンク部分を凸状にして、押したくなるデザインにしたのだと思うんですけど、それをなくしてみると、ユーザーの可読性が高まり、リンクであることがかえって分かりやすくなった。ただし、Aパターンのようにアンダーラインがないとリンクであることが伝わらないため、結果としてBパターンが一番CVRの高いデザインになりました。
これはクイズの第1問で紹介した「引き算のルール」が効いた事例といえるでしょう。みなさん、フラットデザインをどうしようか悩まれていると思うんですけど、そういうものにもトライしてみるのもいいのではないでしょうか。
2つの事例をクイズ形式でみなさんにご紹介しましたが、お伝えしたいのは「ユーザーの課題をしっかりと捉え、それをA/Bテストに反映していただきたい」ということです。また、先ほど述べたとおり、A/Bテストは思うような成果（差）が得られないことが少なくありません。めげずにがんばってください。
ユーザーテストとプロトタイプ開発
さて、A/Bテストによるユーザーテストを行って、課題などが集まりました。次は集まった課題を整理し、UIなどの形にしていく作業になります。
このときに、僕らは「プロトタイプ」を作ることに注力します。なぜかというと、関係者との意思の疎通が容易になり、課題を早期に発見できるといったことのほか、「なんか違うから変えたいよね」といった場合にも対応しやすいためです。また、A/Bテストの後に限らず、A/Bテストの前にプロトタイプを作ることもありますし、プロトタイプを作りながらA/Bテストを回すこともあります。
プロトタイプを作るのに、今までいろんなツールを使いましたが、「意思の疎通」という点では、手書きのプロトタイプが一番速くて強いですね。一覧も詳細も、また「こういう風に動くよね」とう動作イメージまで手書きし、全体図を全員で共有することをよくやります。紙に書くこともありますし、ホワイトボードに書くこともあります。ユーザーにも見せることもあります。とにかく手軽で強力ですから、まずは手書きでのプロトタイプ作りを試してみてください。
手書きのプロトタイプなどを使って課題の整理が進んだら、次にツールを使って実際にA/Bテストができるパターンを作成します。手書きでプロトタイプを作っている間にも、「どのパターンを実際に試そうか」と考えるのがよいでしょう。
A/Bテストできるパターンを作成するツールは何でも構いません。僕たちはたまにExcelでも作りますし、それこそ手書きを画像にしてみることもあります。
プロトタイプ開発のプロセス
先ほども述べたとおり、プロトタイプを作ることには意思疎通のほか、課題の発見というメリットもあります。ユーザーにプロトタイプで見せる段階でも課題がたくさん見つかります。僕らがプロトタイプ開発を行うのは、課題を見つけそれを改善するというプロセスでWebサービスやアプリを作りたいからです。
実際に、プロトタイプを使って16名へのユーザーテストをしながらアプリを開発したこともありますし、これが本当に使えるかの確認をアンケート調査も含めてやっています。特にA/Bテストをしにくい環境においては、プロトタイプを作り、ユーザーに実際に使ってもらって課題を把握するという手法も取り入れるとよいと思います。
参考までに、僕たちが使っているツールを紹介しましょう。1つは「FLINTO」です。リンクの設定がいろいろできまして、プロトタイプなんだけれども実際にユーザーがWebサービスやアプリを体験できます。また、Webサービスやアプリを開発する前に触ってもらうこともできますし、「実物はこうやってやっていくと、こう変化する」といったことも体験できます。
そのほか「POP」など、いろんな便利なアプリが出てきていますから、どんどん使ってみて試してみましょう。新しい発見があると思います。
まとめ：リクルートジョブズのA/Bテストの実施ルール
最後にまとめとして、僕らがA/Bテストを行う場合のルールをまとめた資料を見ながら、A/Bテストの流れを確認しておきます。
案件選定～テスト開始まで
まずは、どのテストを行うかの案件選定です。ユーザーテストやデータ分析、Google AnalyticsやAdobe SiteCatalystなどから仮説をどんどん集めて、案件を選んでいきます。
そうして選んだテストの案件の中で、実施の優先順位を付けます。同じ画面にたくさんの案件を盛り込んでしまうと、案件と結果の因果が分からなくなってしまうので、ちゃんと優先順位付けします。
そして、関係部署と調整しながら実際にテストを実施します。
テスト実施中
テストはあれこれ考えるより実際にやってみるのが早道ですね。テストを実施してみると、良い悪いが即日出たりします。もちろん、逆にじわっと結果が出るものもあります。この辺りはテストの特性によりますね。
とはいえ、僕たちはビジネスをしているので、テストがビジネスのKPIを毀損すると分かった場合には、すぐそのA/Bテストを止めます。
また、テストの結果に有意差があるかどうかを判断しなければなりません。「0.1ポイント上がりました」といった場合、結果が良かったのか、悪かったのかは有意差判定をしないと分かりません。それをテストツールで判定しながら、僕たちは日々日々、サービスを改善しています。
テスト終了後
テスト終了後には、良い結果が出たパターンをサービスの進化につなげつつ、さらなるA/Bテストを回していきます。
本講義は以上になります。まとめますと、Webサービスの運営はA/Bテストなどを行って、「ユーザーの課題をちゃんと捉えながら、グロースハックしていく」ことをベースに進めていくとより大きな成果が得られます。みなさん、ぜひいろんなユーザーを想定しながらサービスを作ってください。ありがとうございました。
≪次回は講義後に行われた質疑応答をお送りします≫
