「データを見る」を当たり前に。機能の検討・改善、CS、問い合わせ対応まで、全社でデータ活用に取り組む組織へ

9万組以上のクリエイターが登録するオールインワンプラットフォーム「MOSH」を運営するMOSH株式会社。事業成長を加速させるため、プロダクトチームだけでなくCS・サポート・営業まで、顧客接点を持つあらゆるメンバーがユーザー行動を自ら確認し、改善提案できる体制を目指してきました。

その基盤として導入されたのが、AIアナリティクスツール「Wicle」です。導入からおよそ1年。同社ではチーム横断でユーザーの実際の操作を確認する「みるみる会」が定着し、セッションリプレイのURLをSlackで共有するだけで改善検討が即座に進むなど、部署横断でデータをもとにプロダクト改善を進める文化が根づいています。

導入の背景にあった課題、浸透までのプロセス、そして組織に起きた変化について、担当者のみなさまにお話を伺いました。

課題

• GA4やBigQueryで定量データは把握できていたが、N=1のユーザー行動を詳細に確認する手段がなかった

• ファネル数値の変動は把握できても、「なぜ下がっているのか」の原因特定のハードルが高かった

• リリースした機能が実際にどう使われているか、データチームに頼らないと確認できなかった

• 月間約2,000件の問い合わせに対し、ユーザーの操作状況をスピーディに確認する手段がなく、対応に時間がかかっていた

解決策

• Wicleを「定性的なユーザー行動の可視化」を担うツールとして導入し、既存の定量ツール群を補完

• 社内勉強会の実施やNotionでのガイドページ整備により、多部門への浸透を推進

• 「みるみる会」と名づけた定期的なセッションリプレイ確認会を開催

効果

• Wicleベースで改善要望を共有し、開発側がそのまま改善検討に進むスムーズな連携が定着

• セッションリプレイにより、問い合わせ対応時のユーザー操作確認が迅速化。再現手順の特定やブラウザ・デバイス起因の問題を早期に発見できるように

• みるみる会で発見したゲスト登録動線の問題を、セッションリプレイURLの共有から約1週間で改善

大きな数字を見てもわからない、「なぜそうなった」が知りたかった

──まず、貴社の事業についてお伺いさせてください。

大東さん： 弊社は、クリエイター向けのサービス販売プラットフォーム「MOSH」を運営しています。予約や決済、オンラインサロンの会員管理からメッセージ配信まで、サービス販売に必要なすべての機能をオールインワンで提供しており、現在9万組以上のクリエイターの皆様にご利用いただいています。

直近ではAIを活用したページ作成サポートなども提供し、クリエイターがご自身の価値を収益化するプロセスを一気通貫で支援しています。

（https://mosh.jp/ より）

──Wicle導入前、どのような課題を抱えていましたか？

大東さん： 以前より、GA4やBigQuery上で定量データの分析はできていました。ただ、ユーザーの行動をつぶさに見にいきたいときや、実際の操作感などを確認したいときに、定量的なデータだけではわからないことがあり、定量データを補完できる分析ツールが必要だと考えていました。

──定量データでは見切れない部分を見たいというのがきっかけだったのですね。なぜユーザーの実際の操作まで見る必要があると感じたのでしょうか？

大東さん： BigQueryでマクロな数値を追うことは現在も行っていますが、実際のプロダクト改善や仮説出しのフェーズでは、大きな数字を見ているだけではわからないことが多いからです。たとえば、ファネルの数値が落ち込んでいることはわかっても、「なぜ下がっているのか」という理由はなかなかつかめません。

デプスインタビューを行ったり、プロトタイプを使ってもらったりはしているものの、実際にリリースしたものがどう反応されているのか、行った改善がどれだけユーザーの行動変容を起こせているのかは気づきにくいのが実情でした。その見えない部分を、Wicleを使って確認しにいきたいと考えて導入しました。

全社でプロダクト改善に取り組むため、国内産ならではの使いやすさを優先

──課題解決のために、ほかに検討したツールはありましたか？

大東さん： 利用するメンバーを増やす際に、海外ツールだとキャッチアップや運用が難しくなるケースがあるため、国内のツールを検討していました。近しいプロダクトはヒートマップ系や海外ツールなど幅広く存在しますが、やりたいことの軸で絞ると実質的にWicle以外の選択肢は見当たりませんでした。

なるべく使いやすいものが理想でしたし、サポートやヘルプページを含めて日本語で提供されている点は非常に大きかったですね。

（大東さん）

──特にWicleのここが良いと感じたポイントを教えてください。

大東さん： 大きく3つあります。 1つ目は、イベントログを都度仕込まずに分析できる点です。機能のリリース後に「ここの動きも見ておくべきだった」と気づくことは少なくないのですが、Wicleならビューやクリック、エラーなど必要なデータがだいたい網羅されています。イベントをわざわざ発火させなくても、後から条件を絞り込んで柔軟に分析できる。「この前リリースした機能は、どう使われてる？」という会話から、数分で実態を確認できるのは非常に助かっています。

2つ目は、イベントベースとユーザーベースの両方の軸で分析でき、前後の動きやジャーニーが線でつながって見える点です。N=1の深い観察から少し視野を広げ、傾向をドリルダウンしていくことも可能です。

3つ目は、それらを補足する「セッションリプレイ」が一気通貫でつながっている点です。イベント計測、ユーザーの絞り込み、実際の動きの確認がすべてシームレスにつながっていることが、私たちが今一番価値を感じているポイントです。

──導入するにあたり、意識したことはなにかありましたか？

大東さん： 特に意識したのは、プロダクトマネージャー（PdM）やデザイナーだけに用途を閉じないことです。エンジニアはもちろん、カスタマーサクセスやサポート、営業といったメンバーも自らデータを見にいき、気づきを得て、プロダクトの改善要望をあげる。全社でプロダクトフィードバックループを回すために、なるべく多くの人に触ってもらいたいと考えていました。

──導入時に懸念はありましたか？

大東さん： メンバーのオペレーションや日々の運用にしっかり溶け込めるかどうかは少し不安でした。分析ツールは導入して終わりになりがちなので、ほぼ無意識に使うレベルまで浸透させられるかがカギだと思っていました。まだチームによってばらつきはありますが、確実に活用は進んでいます。

──導入を決めてから、軌道に乗るまでどのように進めていきましたか？

大東さん： まずはさまざまな機能をとりあえず使ってみることを推奨し、そこで得られた驚きを成功体験にしていくことを意識しました。導入時に各チームで勉強会を実施したのですが、「こんなところまで見られるのか」という驚きの声があがっていました。

また、データを眺めるだけでは意味がないので、目的を持ってデータを見るよう促しました。各チームのリーダーシップに委ねつつ、私からは折に触れて「Wicleで見てみたら？」と声をかけるようにしていました。こうした積み重ねを通じて、徐々にプロダクトの利用がチームに浸透していきました。

チーム全員でリプレイを見る「みるみる会」で、データを見る習慣が定着

──現在、具体的にどのようなタイミングでWicleを活用されていますか？

渡邉さん： プロダクト開発チームでは、リリース後に確認することがよくあります。新たにリリースしたプロダクトがどう使われているか、セッションリプレイを見るのが主な使い方ですね。

加藤さん： リリース前の課題発見でも使っています。たとえば、ファネルでアカウント作成からサービス作成までの流れをイベントとして設定して、どこがボトルネックかを見る。PdMとして「このデータがほしい」というときに都度イベントを設定して見るような使い方をしています。

（加藤さん）

奥山さん： CSはチーム全員でセッションリプレイを見る「みるみる会」を実施しています。例えば、オンボーディングフローが大きく変わったタイミングで、オンボーディングに乗っているユーザーのN=1の様子を手分けして確認し、想定していない挙動が発生していないか、スムーズに利用できているか、利用にはどれぐらい時間がかかっているか、戸惑いがないか……といったところを見ていきます。

──みるみる会は、具体的にどのような流れで行われているのですか？

奥山さん： リリースのタイミングなどに合わせて、テーマを決めてお客様の行動履歴を見に行くという形で設定しています。みるみる会を実施することで、普段の業務上もちょっと気になることがあったら見に行くという習慣づけになります。定期的に見るよりは、何かのタイミングでちゃんと機会を作ってみんなで確認することが大事だなと感じています。

──みるみる会を開催して、なにか発見はありましたか？

奥山さん： 直近では、オンボーディングフローに乗っているユーザーの動きをチームメンバーで確認した際、ゲスト（クリエイターのレッスンやサービスを利用するユーザー）が意図しない形でクリエイターの登録動線に流れてきてしまっている現象を発見しました。

みるみる会直後に、セッションリプレイのURLをエンジニア側に共有しながら、「この人は様子を見る限りゲストだが、クリエイター側の登録導線に乗ってしまい、戸惑いながらも登録を進めている。もしくはそこで離脱して購入に至れなかった」と伝えました。

事象の共有がすぐにでき、その後1週間ぐらいで開発側と連携しながら改善を進めていきました。実際のユーザーの動きをファクトとして改善に動けたので、 社内の連携もスムーズに進みましたね。

説明不要で誰でも操作でき、課題認識が揃うことでスピーディに改善へ

──Wicleを活用して、特に良かったと感じている点を教えてください。

奥山さん： 操作のハードルが低いところですね。誰かが使っているのを見れば、自分もある程度操作できます。たとえば、私たちが「この人の動きを見て」とWicleのURLを渡したときに、渡した人があまりWicleに慣れていなくても、セッションリプレイをすぐに再生して確認できます。こうした共有のハードル、利用のハードルが低いプロダクトだと感じています。

渡邉さん： ページビルダーというプロダクトをリリースした際、ページ作成のサポートのためにテンプレートを用意していたのですが、実際は想定よりもテンプレート機能にたどり着いていなかったり、気づいても活用せず離脱して自分でつくり始めているユーザーも一定いました。

また、モバイルは非推奨の機能だったためバナーでお知らせを出していましたが、それも気づかれず作成画面まで進んでしまっていることも発見できました。こういったユーザーの行動を確認でき、現象が起きる理由の解像度を上げられるところがすごくいいなと感じています。

（奥山さん）

奥山さん： カスタマーサクセスとしては、クリエイターからいただいた課題や質問をプロダクト開発側に届けるのですが、クリエイターからのご要望は抽象度が高いことも多いんですね。

Wicleで確認することで、具体的にどの画面で困っているのか、何をしようとしていてなぜできていないのか、といった「つまずきポイント」がわかる。開発側にWicleのURLを共有することで、課題の共有がしやすく、改善のアクションもスピーディになりました。

たとえば、新機能が出た後のエンプティステート（何も編集していないときの画面）に関して、デザイナーは「できる限りシンプルなUIにしつつ、その機能の役割を簡単に説明する画面にしたい」と考えていたのですが、Wicleでみるとユーザーは次のページにすぐ飛んでしまっていて、何をしたらいいかわからず離脱してしまっているようでした。そこで、機能の説明だけではなく利用のメリットやヘルプへの導線を記載する、という改善につなげることができました。

特に意識をせず、日々の動きのなかで「データを見る」が当たり前に

──チームの働き方に変化はありましたか？

大東さん： ポジティブな意味で、みんな「データを取りに行く」という意識をしていないかもしれないですね。「データを取りに行く」って心理的に重たいアクションな印象がしますが、現状チームのみんなが日々の動きのなかで当たり前のようにWicleを見ており、結果として実際のデータを踏まえた仮説構築や施策検討を行えている状態です。

奥山さん： 改善要望もWicleを使って共有することで、調査や検討で滞留することがほぼなく、スムーズに進められています。

渡邉さん： カスタマーサポートでも、ユーザーから不具合に関する問い合わせが発生した際、Wicleを見て実際に起こっている事象を確認しています。

ユーザーの勘違いだったケースもありますし、問い合わせの通りのバグが発生していて、そこから不具合共有や障害報告を迅速に連携するケースもあります。問い合わせ対応では、「まずWicleを見に行く」ということが定常化しています。

また、トップクリエイターへのハイタッチCSにおいては、特定LPへの流入後の動きやファネルを見たいというニーズにも対応できています。このような個別の分析環境の構築はとても大変だったのですが、Wicleならすぐに見られるので、さまざまなクリエイターの分析ニーズに対応できています。

（渡邉さん）

──今後、Wicleの活用をどのように広げていきたいとお考えですか？

大東さん：今後はメンバーも増え組織が大きくなっていくので、それに伴ってWicleを使う人・チームはさらに増やしていきたいと思います。

使い方については、カナリアリリースや一部のユーザーにだけ提供している機能について、パターンごとにユーザーの動きを比較できるといいなと考えています。

また、大局的な利用状況や事業上の重要KPIから別のダッシュボードでざっくりと仮説出しをして、それを踏まえてWicleでユーザーの動きを見に行くというのは、さらに取り組んでいきたいですね。