定量データの活用で「ユーザーの声」の裏にある真実を見つける！

私はもともと、SIerでシステムエンジニアをしていました。その後、制作会社のWebデザイナーに転身し、Fablicには、2番目のデザイナーとして2014年に入社しました。

弊社は、2012年に創業したフリマアプリ「フリル（FRIL）」を運営するスタートアップです。

Fablicでは、ユーザーの期待を超えるという理念のもと、ユーザーからのご意見など、定性的な情報を非常に大事にするという文化があります。

例えば、弊社のカスタマーサポートは、もともとフリルのユーザーだった人を採用しています。ユーザーでもあったメンバーに、いつでも「これ、どうですか？」と聞ける環境にあるので、アプリのQA（品質管理）テストを行う際にも意見をもらっています。他にも、ユーザーさんへの電話インタビューやアンケートも頻繁に行っています。

そこでユーザーさんから直接出てくる声は、目に見えてわかる使いやすさ、わかりやすさの改善要望が多くなります。しかし、こうしたユーザーさんの声ばかりに着目してしまうと、真実を見落としてしまう恐れがあるんです。

▼デザイナーの山口 有由希さん

これは一例ですが、「花柄　スカート」とフリル内で検索した際、実際にはフリル内に1,000品の商品が登録されているのに、検索システムの問題で10品しかヒットしなかったとします。

ユーザーさんはもちろん、フリル内に花柄スカートが全部で何点あるかはわからないので「1,000品あるはずなのに10品しかヒットしなかった」とは気付きません。すると、「フリルには花柄スカートが10品しかなかった」と判断してしまいます。

この場合、ユーザーさんの声として上がってくるのは「欲しかった商品の品数が少ない」という意見になります。これをそのまま鵜呑みにしてしまうと、もっと品数を増やそうという発想になりますよね。

でも実際には検索システムの不備が問題で、品数を増やさずとも、システムを改善すれば解決できることでした。こうした事実は、ユーザーさんの声だけでなく、検索結果からのヒット率やアクション率といった「定量データ」も併せて見ることで、始めて気付くことができます。

「ユーザーの声」の裏に隠された真実に気づくためには、定性的なデータに加え、定量的なデータも並行して見ていく必要性がある。そう感じ、定量データも重視する文化に変わっていきました。

デザイナーが自らデータを取得できるように、エンジニアがサポート

データドリブンなデザインチームづくりは、Fablicの共同創業者であり、最初のデザイナーでもある竹渓と一緒に進めていきました。

まずはエンジニアメンバーと相談しながら、デザイナー自身が必要なデータにアクセスできる環境を整えていきました。

「Google アナリティクス」のデータを見ていくところからはじまり、最近ではより様々なデータを調査できるように「Re:dash（リダッシュ）」を導入したんです。

※Re:dashの使い方について説明している記事はこちら

Re:dashは、BigQueryなど様々なDBに接続することができ、取得したデータの可視化もできる無料ツールです。

Re:dashでは、誰が書いたSQLでどういう結果が出ているかもログとして残っているので、それを参考にカスタムすれば、ゼロからSQLを書かずに済みます。そういった手軽さが、勉強を始めるには良かったんです。

▼他の人が書いたSQLを参考にしながら、欲しいデータを取得することが可能

導入後は、気軽にエンジニアに相談できるような環境を作っていくことで、デザイナーが自らデータを取得できるようサポートしていきました。

具体的には、エンジニアを中心にデザイナーや企画などデータ分析を行うメンバーで運営している「分析委員会」というチームを作り、データの抽出に困った際はこのチームのメンバーに気軽に相談ができる組織体制にしたんです。

例えば、SQLのことやデータ抽出について質問できる専用のSlackチャンネルを作りました。そこに自分が書いたSQLを貼ると、「こういうふうに集計したらいいよ」と、手の空いたメンバーが教えてくれます。

▼Slackの専用チャンネルで気軽に相談できるように

また、分析委員会主導で、初心者向け、中級者向けとレベルをわけた社内勉強会を開催するなど、データ分析の敷居をさげる取り組みも行っています。

▼社内勉強会の様子

数値に基づき、デザインの改善策を提案できるようになった

こうしたエンジニアメンバーの協力のおかげで、デザイナーをはじめ、様々な職種のメンバーが自らデータを主体的に取っていくようになりました。

デザイナーは、自分が出した仮説に基づいたUIを作ると同時に、それによって数字がどう付いてくるのか、どういった数値で検証できるのかまでを設計するようになりました。

デザインの実装をエンジニアに依頼する時に、「ここが使いにくいとのことなので」という主観な意見だけではなく、「ここが使いにくいとの声があり、確かにクリック率が悪く、実際あまり活用されていないようなので」という形で提案ができるようになり、より説得力ある提案ができるスタイルになりましたね。

例えばフリルのWebページのリニューアルにあたっては、もともと商品が閲覧できるだけで、それを購入したいユーザーはアプリに誘導され、登録を促すという形になっていました。

ユーザー体験として、Web上からそのまま会員登録できて購入できる方がスムーズなことは明白でした。しかし、それを実現するには当然、開発コストがかかります。

そこで、開発コストをかけてでもWebから会員登録できるようにリニューアルすべきか、これまで通りアプリに誘導する方針を続けるべきかを判断するため、現状のフリルのWebページにおける新規会員の獲得率を調査し、アプリでの登録までの離脱率の調査を行いました。

あわせて、公開されていたECサイトの平均コンバージョン率を参考に、Webから会員登録できるようになった場合の新規会員の見込みを試算し、比較を行いました。

結果、現状の登録率を遥かに上回る登録が見込めることから「ユーザーにとっても利便性が高まり、KPIへの貢献度からみても開発コストを払う価値がある」と、データを持って提案しました。

結果的にはアプリに誘導していたリニューアル前と比べ、会員登録率は80倍以上となり、ユーザーの利便性もあがり、KPIにも大きく貢献できる改善を行うことができました。

このようなデータドリブンな考え方は、自分の考えに加え、データという強い味方をつけることができるので、デザイナー自身のモチベーション向上にも繋がります。数字をもとに仮説を立てて、自ら挑戦することができるので、そういったところに共感して入社してくれたデザイナーもいましたね。

一方で、数字だけに頼ると失敗に繋がることも…

ただ、データドリブンに考えすぎると、選択を間違えそうになることもあります。

例えば、Webの商品一覧画面を、2カラムと3カラムのどちらにすべきか検討する際、一覧画面の先の商品ページへの遷移数で判断しようとしたことがありました。

このケースでは、3カラムのほうが遷移数が多いという結果が出たのですが、実は3カラムの方ではレイアウト上、商品に関する一部の情報を削っていたんです。

▼参考：商品一覧画面のカラム（列）を増やすと、1商品に対して表示できるスペースが狭くなる

そのため、単純な比較はできない状態になっていたんです。3カラムのときに数値が高く出たのは、その削られた情報を知るために商品ページに遷移していただけで、実はユーザーさんに余計な手間をかけているだけという可能性もありました。

ですので、ひとつの数値の良し悪しだけで判断するのではなく、ユーザーさんの考えもヒアリングしながら、定性データと定量データをバランスよく見ていくことが重要だと考えています。

日々データに触れる環境で、「中毒的な」サービスづくりを目指す

「データを見て常に改善していく」という意識付けは、まだまだ動き出したばかりです。今後はさらにその意識を徹底していき、全員で数値を追える状態を作っていきたいです。

例えば、チームのOKRに関わるデータを毎朝の朝礼で全員が確認し、みんなで数字を追っていくという意識付けをしています。また、少しずつですが、個々の施策の効果に関しても、日々全員で経過を追えるような体制を整えています。

このように、データへの意識付けを高めることで、チーム全員が一丸となってユーザーの声の裏にある真実を見つけ出し、「ユーザーが中毒的に使ってくれるようなサービス」を創っていきたいと思っています。

より多くのユーザーさんにフリルを使ってもらい、かつ売り上げも伸ばしていけるように、これからも情熱を持って挑戦を続けていきたいですね。（了）