不動産DXを推進している株式会社Speee様。
2015年に当社取り扱いツールであるOptimizely（オプティマイズリー）をご導入いただき、その中でもトップレベルの実験数を行われるほどご活用いただいています。
今回、担当者である九島様のABテストに関する記事（「数打ちゃ当たるは的外れ。成果を生み出す「ユーザー中心設計」のABテスト」）をきっかけに、更なる深堀を実施すべくインタビューにご協力いただきました。
目次
・担当者様の領域やミッション
ーまずは貴社のサービスを教えてください。
Speeeは、マーケティングDXを推進しているMI事業本部と私たちがいるDX事業本部という、2つの基幹事業があります。
DX事業本部には、不動産売却・査定サービスの「イエウール」、リフォームのマッチングプラットフォームの「ヌリカエ」、介護施設のマッチングプラットフォーム「ケアスル 介護」のなどがあります。
その中でも、私はヌリカエを担当しています。
ヌリカエはリフォーム領域において、ユーザーと施工業者をマッチングするサービスをメインとしています。
例えば、一般のお客様が外壁塗装したいなと思った際Webサイト上のフォームを入力いただくと、弊社のCS（カスタマーサクセス）と施工をしたほうがよいかを相談することができます。相談後、必要に応じて業者をご紹介し、施工が完了するまでサポートを行うサービスです。
ー九島様の担当領域とミッションを教えてください。
私の役割は、いわゆる「グロース」です。
ユーザーへの価値提供のうち、特にユーザーが価値に触れるためのインターフェースの設計・改善が私のミッションになります。
株式会社Speee ヌリカエ事業部 ディレクター
九島 槇之介さん
ーどのような体制でプロジェクトを動かしていますか。
ABテスト施策を回すプランナーとしての役割、グロース全体への責任を持つプロジェクトマネージャーとしての役割と、これら事業全体への投資対効果の管理。この3つの役割を担っています。
チーム体制としては、施策を考えるプランナー、実装するエンジニア、デザイナーなどのメンバーで構成していて、私はプランナーを担当しています。ABテスト以外にも複数のマーケティング施策に携わっています。
・1000個の指標でユーザーを把握
ー今活用しているOptimizely（オプティマイズリー）の選定には関わっていないのですよね。
そうですね、私の入社が2017年なのですがOptimizelyはさらに前から利用していました。以前の担当者がABテストツールを比較・検討した際の資料も残っていましたが、コストは高くても、私たちのやりたいことが実現できるという点で最終的に選ばれた、と聞いています。
Googleオプティマイズの無料版もありますが、離脱していくポイント設定に上限があります。当社の場合、緻密にユーザーストーリーを設定して追っているので、Googleオプティマイズはマッチしませんでした。
Optimizelyの値を細かく取得できる点は魅力的だなと思います。現在は設定しているメトリクス（目標・指標）が1,000個くらいありますね。
ー1,000個ですか！？
はい。KPI設定は大変ですが、当社の場合、CVRがほんの少し上昇しても事業的なインパクトが大きいので、どんどん広告配信を増やすことができます。
現在は急成長期で一定のトラフィックがあるため、意味のあるサンプル数で分岐ができるのです。
例えば、今は訴求に応じた2種類のLPがあるのですが、しっかりと改善が進行するくらいサンプル数を保ちながら、週1回の頻度で改善をしています。それによってCVRが上がるので流量を増やせます。CVRが上がると、そこから更に分岐したくなる。分岐するとまたメトリクスが必要になる。
このような流れでどんどん数が増えていきました。
ー誰がその1,000個のメトリクスを管理していますか。
チームで管理しています。特にプランナーとフロントエンジニアですね。
エンジニアにはカスタムイベント（ユーザーが独自で定義するイベント）の設定もしてもらっています。
1つ1つの選択肢を全て取得し、ABテストのパターン別にCVを見ているので、かなり細かく結果を見ていると思います。
例えば、LP内に「工事箇所はどちらになりますか？」という設問があります。「外壁」というボタンを押したユーザーと「外壁と屋根」を押したユーザーを比較すると、傾向がまったく異なるのですよね。
こういったユーザー行動の変化や違いを、さらに流入媒体やデバイスで分割して、ユーザーインサイトを得ています。
1,000個もあると驚かれますが、適切に活用できていると思います。
・200施策で失敗した理由
ー記事を拝見しました。200施策やってCVRが上がらないって、相当苦労されましたね。
ありがとうございます。とても辛かったです。笑
ーそもそも当初からABテストツールを使い込まれていたのですか。
いえ、そんなことはありません。むしろ当初は、施策ありきのABテストを行っていました。
私が配属された2017年頃は、ヌリカエはまだ立ち上げフェーズでした。流入も少なく、本来であれば月1回のABテストが現実的なラインでした。しかし、とにかく施策を積み、優先度をつけて片っ端から試していくというスタイルで、週1回の頻度でABテストを行っていました。
勝ち筋もわからず、また最適なテストのサンプル数もわかりませんでした。その状況を考えると、最大限のリソースを注ぎ込み、最速でPDCAを回すというスタイルは、当時考えられるベストな進め方だったと思います。
ただ、私の考えた施策でテスト結果は改善しても、事業の数字が改善することはありませんでした。
Speeeの他事業でのABテストの改善実績を見ているので、「ヌリカエでも、すぐにCVRを上げられる」と周囲の期待値が高かったこともあり、200施策も行っても全くCVRが上がらなかったのは本当に辛かったですね。
結論、改善出来なかった背景としてはサンプル数が足りなかったのだと思います。立ち上げ期でユーザーインサイト（行動傾向）はたまっておらず、実際闇雲にABテストをしてもどうにかなるわけではありませんでした。
ーABテストそのものに期待値が寄せられてしまうのは、あるあるですよね。
そうですね。「ABテスト」という手段そのものの認知のされ方に、期待と実態のズレがあるようにも思われます。
立ち上げフェーズだと前後比でテストをすることや、N1インタビューなどで顧客の課題を掘り下げる手段もあると思います。
しかし、論理的に成果の出るメカニズムがわかりやすく、（色を変えるだけなどの）すぐに真似できそうな事例が多く、ツールが普及して手軽に見える「ABテスト」という手段に、期待が集まりやすいですよね。
また、プランナー以外でも施策に言及しやすいというのもあると思います。
「ちょこちょこっと変えたら2％ぐらい上がるんじゃないか」みたいな感覚的な相談をされることは今でもあります。
しかし、私も実際に行き詰まったときに競合のサイトの要素を学んだり、「ABテスト 成功事例」で見つけた施策を試したのですが、まったく成果につながりませんでした。
ー振り返ったときに、何が一番の失敗だと思いますか？
プランナーとして、「ユーザーに対して真摯に接することができなかった」ことだと思います。
立ち上げ期の事業では、様々な想定外のことが起こりなかなか計画どおりに進みません。そんなときこそ、遷移率を改善できるCVR改善って、魔法の杖に見えるようです。事業数字に対してすごくインパクトが出せるので。だからこそ、期待されます。
私は、期待に応えようとした結果、少ないサンプル数で一時的なCVRの上がりを「勝ち施策」と捉えました。でも、それはいつまでたっても事業の数値に返ってきませんでした。
これって、自分の評価されたいというエゴに負けて、ユーザーに対して真摯に接しなかったから起こっているのですよね。
・「ユーザー中心」に気づく
ー2~3年目にユーザーニーズを掴むことが糸口になったとありましたが、改善の経緯を詳しく教えてください。
はじめは、リスティングの広告文改善を実施しており、週1回の改善を半年間行いました。
リスティングはユーザーインサイトがはっきりしているため取り扱いやすく、また訴求の検証をプランナー1人でできるのが魅力です。
また、ちょっとした単語の違いで結果に差がでるため、2つの似たような広告文を入れても片方は改善して、もう片方は悪化するなんてことがよく起こります。そのときに、より深くユーザーに対して考えていないと説明がつかないのですよね。
こうやってユーザーに向き合いながら訴求検証を繰り返していたら、ユーザーに対する解像度がぐぐっと上がりました。
このユーザーに対する理解が引き上がったタイミングで、LPの改善に着手しました。
すると、どんどんCVRが上がり、1年で3倍くらいになりました。1年目のしんどさは何だったのかと。この当時、打率5割くらいだったと思います。驚異的ですよね。笑
ー上司と振り返りをされたとのことですが、どのような内容だったのでしょうか。
1番の気づきは、「CVRを大きく高めた施策は、“めっちゃすごい施策”ではない」ということでした。
一般的に、「LPOの当たり施策って、どんなすごいものなんだろう？」と考えると思うのですが、振り返ると改善幅の大きかった施策って大したことなかったのです。何文字かテキストを変えたり、要素を削ったりする程度のものでした。
改めて、このときのプロセスを振り返ると、次のとおりです。
・ユーザーの根本のニーズを理解する
・根本のニーズを満たすサイトを想像し、そのサイトに近づくよう少しずつ施策を実行
・細部を磨いているうちに、改善幅の大きな施策が生まれた
このことより、改善幅の大きかった施策が「大したことない」理由は
・ユーザーの根本のニーズを捉えられていた
・細部を磨いているうちに、どこかでユーザーが感じる閾値を超えた
・それがたまたま、テキストを変えたり、要素を削ったりする施策だった
だと考えています。
ーなるほど、だから「ユーザー中心設計」のABテストなんですね。
そうですね。
私は広告文改善からユーザー理解をし、ABテストのプロセスでも1,000個のカスタムイベントを用いてユーザーの行動を把握するスタイルでした。
その上で私にとってOptimizelyは欠かせないツールだったと思います。一度に設定できるカスタムイベントの数もそうですが、「モーダルが出たユーザーのうち、このボタンを押した人」などの細かい設定ができる自由度の高さも、ユーザー理解にはとても重要だったと思います。
ユーザー中心をもとにしたABテストの型が、以下の3つになります。
①最適化の方向性をコントロールする
②ユーザーに向き合って施策を回す
③事業数字と離れないように、モニタリングする
このあたりは、ぜひ記事を読んでいただきたいです。
※九島さんの取り入れている、「ABテストの型」。記事より引用。
・組織風土の後押し
ー最後に新しいツールを導入する際のアドバイスがあれば教えてください。
学習コストがかかるツールは導入のハードルが高いですよね、誰が習得して、誰につないでいくかまでを設計した導入イメージが必要だと思います。ただ当社の中でも以前と比較してもOptimizelyを使いこなせてる人たちが大幅に増えています。
これはツールの特性であるノーコードで対応できる、ということは大きいかもしれないですね。
ーそれは素晴らしいですね。まだ使ったことない方が使ってみやすくなるような、工夫をされていますか。
例えば、弊社がクライアントに入る場合は、スーパーユーザー的な方を巻き込んで社内に教えていく、という流れがよくあるパターンですが、貴社のケースではユーザーが増えたきっかけはありましたか。
Optimizelyはアカウントの従量課金がないため、新たなユーザーが始めるハードルが低く、またABテストを実施するフェーズではない小さなプロジェクトでも、「とりあえず使ってみたい」と、簡単に始められるというのは大きかったかもしれないです。
誰かがレクチャーするというはじめの取っかかりはありましたが、アカウントを渡した後は、事例や細かい設定方法のページを勝手に見て実践してくれる人がいたり、英語版の記事を見て、勝手にAPIを作る人もいたりしました。
ーそれは想像以上に特殊な環境ですね。
学習意識が高いといいますか、なかなかすごいです。
勉強するにせよテストするにせよ、現状動いている業務の上に乗ってくるので、なかなか手が回らないですし、自走することができない、というのがよく聞く話ですよね。
自走型の社員が多いというのもあるかもしれないですね。
例えば、経験の浅いプランナーに利用できる条件設定を限定した上で、これでやってみてって範囲が限定されたマニュアルを渡しても、スイッチが入るとどんどん興味が湧いて色々な所を触り始めます。
そこに乗じて、「実はこんなこともできるよ」って新しい手法を渡しつつ制約を開いてあげると「え、そうなんですか！やってみます」ってどんどん自走していくケースもありました。
ー実験やABテストなどに対する社内全体的な理解があると言いますか、敷居の低さを感じますね。
そうですね、どんどん挑戦しようっていうカルチャーがあると思います。
ー空気と言いますかムードは重要で、本来出来るものも出来なくなったりしますからね。
結構よく聞くのは、ABテストをやれば答え出るのに。「実際やってしまうと、あそこに影響がでるかもしれない」という話で止まってしまうケースです。
だから、テストなんですが…。会社のカルチャーが出ますね。
ハンドリングする人が、どれだけ失敗をコントロールできるかということも重要で、どこまでなら大丈夫か見えてるから、新人もチャレンジできると思ってます。設計をミスっていたとしても、リカバリーできる範囲でしか渡さないようにしていることも大事かもしれないですね。
ー大変参考になりました。今回はありがとうございました！
