Backlogの改善でわかった A/Bテスト を失敗に導くアンチパターン5選

こんにちは。ヌーラボの砂川です。ヌーラボのプロジェクト管理サービス「Backlog」のグロースハックチームとして働いています。さて、外から仕事内容が見えにくいこのグロースハックチーム。一体どのような仕事をしているかというと、Backlogがどのように使われているかを、トラッキングや様々な A/Bテスト 等を通じて定量化・定性化し、ユーザー体験の改善に役立てる活動をしています。

簡単に言うと、グラフや数字を眺めながらニヤニヤするお仕事です。

Backlogでは A/Bテスト を実施しています

どちらがいいのか比較する

ヌーラボのプロジェクト管理ツール「Backlog」では、今年に入ってからA/Bテストによる改善を導入しています。具体的には、一部のユーザーの方のみを対象に、サイトのボタンに表示する文章や一部の入力フォームの項目に変更を加え、その変更がユーザー体験の改善に繋がるかを評価しています。一部の熱心なユーザーの方は、時折アイコンの表示が変わったりしていることにお気づきかもしれませんね。

機能の使用率を改善した事例

先月の2017年6月から、課題詳細画面のアイコンに、機能を説明するラベルが追加されていることにお気づきでしょうか？

アイコンの意味が分かりやすくなりました

実はこの改善には、A/Bテストによる検証の結果が反映されています。

アイコンとラベルをどちらも表示するべきかどうかは、去年のUIリニューアルの際にも議論されました。しかし当時はグロースハックチーム立ち上げ直後ということもあり、議論のための定量的なデータがありませんでしたから、データを基にした議論はできませんでした。そのため、リニューアルコンセプトの「画面をスッキリさせる」というポイントに重点を置いて、アイコンのみのデザインに決定したという経緯があります。

UIリニューアル時にはアイコンのみにするという選択をしましたが、アイコンにラベルをつけるべきかどうか？という問題は、Backlogの各機能に留まらずほとんどのサービスに関わる重要な問題です。そこでA/Bテストを実施し、定量的に効果を検証してみました。

グループによって表示方法を変える

※ 数字は仮のものですが、改善率は実際の結果と大体合わせてあります。

これらの結果から「基本的ではない機能を持つアイコンにラベルを合わせて表示すると、ユーザーの使用率が上がる可能性がある」ということがわかりました。特にウォッチ機能と編集機能の改善率の差にわかりやすく出ていますね。

現在はこの結果や更なるA/Bテストを基にしながら、他の画面の改善も進めています。

A/Bテストを失敗に導くアンチパターン

結局どっちがいいの？

A/Bテストサイコー！　なんでもいいからA/Bテストしたいぞ！

……と言いたいところですが、実際はそう簡単ではありませんでした。やってみて初めて気付いたり、改めて実感した知見から、A/Bテストを失敗に導くアンチパターンをいくつか共有します。

アンチパターン 1: 仮説を設定しない

仮説は、テスト内容を決めたり、結果を評価する際の判断基準になります。テストを行う前に仮説を設定していないと、結果の評価が曖昧になってしまったり、そもそもやる意義の少ないテストになってしまったりするかもしれません。

例えば、先ほど挙げた事例では「アイコンの情報だけではユーザーが機能を理解するには不十分なのではないか？」が仮説です。この仮説を元に、ラベルをつけるボタンや評価に使う指標を決めています。

アンチパターン 2: サンプル数が少ない

統計データを扱う際には、必ず確率が付きまといます。結果を点ではなく幅で把握する必要があります。サンプル数が少ないと、それだけテスト結果は信頼しにくいものになります。

見込まれる改善幅にもよりますが、各グループにサンプル数が少なくとも500は欲しいところです。統計学の「符号検定」について調べてみるといいでしょう。

アンチパターン 3: 慣れを考慮しない

変更点以外の要因を除外しやすいのがA/Bテストの大きなメリットですが、変更点以外の要因について全く考慮しなくても良い訳ではありません。

ユーザーは機械ではありませんから、変更する内容によって戸惑ったり、逆に新鮮さを感じたりすることがあります。例えば、ある日突然入力フォームから項目が減れば、ユーザーは不安を感じてしまうでしょうし、見慣れないボタンが表示されればとりあえず押してみるでしょう。

これらの影響はA/Bテストにおいてノイズになる可能性があります。ユーザーの慣らし運転の期間を決めて、変更直後の数日間のデータは使用しない、といった調整をしたほうがいい場合があります。

アンチパターン 4: 一つの数値だけに注目する

A/Bテストは変更の結果をわかりやすく数値で表現してくれます。しかし、その数値だけを見て評価するのは危険です。例えば、ボタンに過激な文章を表示すればクリック率は上がり、この変更は良い結果をもたらした、と評価できるかもしれません。しかし、その結果サービスを長く使ってくれるユーザーが離れていってしまっては「木を見て森を見ず」となってしまいます。このような場合、「良い結果だった」という評価は果たして正しかったのでしょうか？

結果を評価する際は、広い視野を持つことが重要です。

アンチパターン 5: 都合のよいデータを信じる

機械学習などの隆盛もありますが、現時点では、データを解釈するのはあくまでも人間です。自分の中にある仮説を信じるあまり、悪い結果を無視したりしないように、常に気を配る必要があります。ある意味で一番避けるのが難しいアンチパターンかもしれません。

終わりに

いかがでしたでしょうか。A/Bテストはうまく使いこなせば専門外の方にもわかりやすい、強力なツールです。Backlogでは様々なデータを測定して意思決定に利用する専門のチームを作り、様々な試みを進めています。

ヌーラボではサービスを成長させるのが最高に楽しい！というグロースハッカーを募集しています。