アクセス解析の数字だけでは見えない「理由」がある

ここまではアクセス解析の数字、つまり定量データを軸にお話ししてきました。数字は頼りになりますが、数字だけでは判断がつかない場面が必ず出てきます。

ここからは、アクセス解析だけでは拾いきれない情報を手に入れるための「定性的なテスト」についてお話しします。

分かりやすい例が、滞在時間です。滞在時間が短いのは、興味がなかったからなのか、それとも内容が分かりやすくてすぐ理解できたからなのか。数字だけを眺めていても、ここは判別できません。「短い＝悪い」と決めてしまうと、せっかく良い状態になっているページまで手を入れ始めてしまうことがあります。

Web解析は「定量データ」と「定性データ」を行き来しながら進めると、判断の精度がぐっと上がります。数字を見て「こうに違いない」と決めてしまう前に、実際の利用者の反応を確かめる。その道筋として役に立つのが、これからお話しする「ユーザーテスト」です。

ユーザーテストとは何か

一言でいえば、実際にWebサイトを使ってもらい、その様子を観察することです。後ろから見てメモを取るだけのシンプルな形もあれば、アイトラッキング用のメガネで「どこを見ていたか」まで把握する方法もあります。

ただし、最初から盛り込みすぎると確認したいことがぼやけてしまうので、まずは大まかに「どこで迷うのか」「何が伝わっていないのか」をつかむところから始めるのがおすすめです。

ユーザーテストは、次の流れで進めると整理しやすくなります。

テスター（実際にWebサイトをテストする人）を探す
テスト環境を整える
実際にテストを行う
結果をWebサイトにフィードバックする

最後は必ずWebサイトへの改善材料として扱うところまでがワンセットです。それぞれのステップを順に見ていきましょう。

テスターを探す

最初のステップは、テスターになってくれる人を探すことです。選ぶポイントは「想定している利用者」と共通点が多いかどうか。年代や性別によって見ているところや気になる点は変わりますし、とくに性別で反応が変わりやすい傾向があるため、可能であれば性別はそろえておきたいところです。

社内の人でもまったく問題ありません。ただし、商品知識が豊富な人やサイトの構造を知り尽くしている人は避けてください。ユーザーテストで見たいのは「初見の人がどこで立ち止まるか」です。そこは割り切ったほうが、結果がきれいに出ます。

テスト環境を整える

特別な設備は必要ありません。パーティションで区切ったスペースに一般的なパソコンを置いて、後ろからメモを取る。これだけで十分です。記録を残したい、あとでチームに共有したいというときは、後ろから家庭用のビデオカメラで撮っておくと助かります。

極端な話、他の部署の人を自分のデスクに呼んで、その場でやってもらうくらいの気軽さでも始められます。形式にこだわるあまり腰が重くなるよりも、まずやってみることのほうが大切です。

テストを実施する際のポイント

実際にテストを行うとき、押さえておきたいポイントが二つあります。

一つ目は、テスターに「目標」と「状況」を渡してあげることです。ただ「とりあえず使ってみてください」とお願いしても、意味のある結果はなかなか出ません。Webサイトにアクセスしてくる人の行動を知るためのテストですから、事前にこのような状況設定を伝えます。

「○○さんは、こういう家族構成の中のこういう立場の人で、大体使えるお金はこれくらいあって、その中でこういう目的でサービスを探している。そしてその中でこのサイトにたどり着いた」

状況が具体的になるほどテスターも迷いにくくなりますし、こちら側も「どの情報が不足していたのか」を読み取りやすくなります。

二つ目は、頭の中でつぶやいたことまで口に出してもらうことです。普段パソコンでネットを見ている人は無言ですから、そのままだと「マウスとキーボードを操作している様子」しか残りません。そこで、こう伝えてみてください。

「このサイトの悪いところを見つけたいので、思いついたことを文章にならなくてもいいので、全部口に出してください。『ふーん』でも『よく分からない』でも、全部です。」

これだけで、利用者の気持ちが驚くほど見えるようになります。「えーと」「なるほど」「ん？」といったひと言があるかないかで、読み取れる情報の質が大きく変わるのです。

ただし、悪い点を指摘するのは誰でもためらいが出るものです。罪悪感を減らすために、たとえば「この場にはWebサイトを実際に作った人間はいないので、遠慮なく言ってください」と添えたり、「10個以上悪い点を見つけてくれたら、ちょっとした謝礼を差し上げます」とゲーム感覚を持たせたりすると、率直なフィードバックが出やすくなります。

改善すべき点をまとめる

テストで得られた改善すべき点は、まず箇条書きレベルで構いませんので一度まとめます。この段階で急いで解決策まで作る必要はありません。それよりも先に、似た内容をグループ分けしてみてください。ふたを開けてみると、同じ原因から発生している指摘が固まって出てくることがよくあります。

改善点には、重要なものもあれば「これは後でもいいな」というものも混ざります。場当たり的に片付けるのではなく、限られた時間の中で問題点を裁く順番を決めていくことが大切です。なぜなら、改善点は山のように見つかりますし、手を入れたところが新しい改善点を連れてくることもあるからです。優先順位がないまま走ると、体力だけが削れてしまいます。

「プライオリティ付け」と「トリアージ」で疲弊を防ぐ

改善の作業量に飲み込まれないために必要なのが、「プライオリティ付け（優先順位付け）」と「トリアージ（限られた時間で優先度をつけて処理すること）」です。この二つの視点が抜けると、あなたとあなたのチームがデスマーチ、つまり終わりの見えない過密状態に陥りかねません。判断力が落ちたチームでは、成果はまず望みにくくなります。

また、判断できるサンプル数が集まる前に結論を出してしまい、あとから見れば元に戻るような変更を繰り返して疲弊してしまうケースもあります。テストも変更も比較的手軽にできるWebサイトだからこそ、落ち着いて一つひとつ積み上げていきたいところです。

調査を自社サイトの中だけで終わらせない

もう一つ、見落とされがちですが大事なことがあります。それは、調査を自社サイトの中だけで完結させないことです。私は、競合サイトも対象に入れて同じようにテストすることをおすすめしています。

自社サイトだけを見ていると、どうしても「自社サイトの中での改善」に閉じてしまいます。競合と比べなければ、それが市場全体の中で見て改善すべきレベルなのか、すでに十分なのかが判断できません。すでに良いサイトであれば、出てくる改善点は「90点を95点にする」程度の話かもしれません。逆に課題の多いサイトの場合、「大した改善点が出なかった」と感じても、実は「10点を50点にする」ような大きな改善余地が隠れていることもあります。

競合と並べて見てはじめて、自社サイトの立ち位置を正しく評価できます。テストを依頼するときは、自社サイトを含めて複数サイトで試してもらうようにすると、手を入れる順番がぐっと見えやすくなるはずです。

第11章：ユーザーテスト