プロダクト開発と伴走するデータ活用

はじめに

こんにちは。STORES株式会社でデータアナリストをしています、satoyuです。

STORESでは2025年3月に新たな料金プランを発表・リリースしました。またリリースに合わせて、事業者がSTORES製品を使い始める際のオンボーディングフローを統合しました。これにより、各製品ごとの開設オンボーディングが不要になり、1つのSTORES製品として利用開始できる環境が整いました。

しかし、新しいオンボーディングフローの導入により、以前と比較して体験が悪化していないか、オンボーディング中に事業者の離脱がないかなど、プロダクトリリース後の評価において考慮すべき点が複数生じました。

このようなプロダクトリリースの状況をモニタリングするため、データチームとして必要な環境を整備しデータに基づいた定量的なフィードバックを提供してきました。今回はその取り組みについてご紹介します。

プロダクト開発とデータ活用の向き合い方

統合されたオンボーディングの開発は、最初のリリース以降も継続的に改善され、日々大量のプルリクエストが作成されています。このようなスピーディーな開発をデータでサポートする上で重要だと感じた点をいくつかご紹介します。

依頼に素早く応える

「依頼に素早く応える」というポイントは、これまでのデータチームの働き方とは異なる意識改革が必要でした。これまではGitHubで依頼を受け、優先度を決め、期限を設定して対応するというのが基本的な流れでした。アウトプット提供まで1〜2週間、長いものでは1ヶ月かかる依頼もありました。しかし、プロダクト開発に寄り添うには、このスピード感では到底間に合わないことが明らかでした。ニーズが生まれた翌週に提供しても、その頃にはニーズが薄れていたり、プロダクトが改善され仕様が変わっていることが多いためです。可能であれば即日、遅くとも2〜3営業日以内にアウトプットを出すことが重要だと感じました。

このスピード感で分析・可視化を行う上で最も意識したことは、細かい定義のすり合わせを極力省くことでした。意思決定に影響を及ぼすような定義のズレは起きてはいけませんが、結果に大きな影響を与えない細かい定義については分析者が判断することで、とにかくアウトプットの初速を上げることを重視しました。

とはいえ、提供スピードだけを求め単に数値を羅列するだけでは解釈が難しいため、解釈しやすい形に可視化することも同時に意識しています。

例えば、オンボーディングの各ステップの流入数や遷移率を提供する際、最も早いのは図1のようにスプレッドシートで集計値をそのまま提供することです。しかし、数字の羅列では決して解釈しやすいアウトプットとは言えません。これを図2のように事業者が実際に行うオンボーディングフローに合わせて可視化することで、どのステップで離脱率が高いのかを解釈しやすくなります。

図1. スプレッドシートで可視化する場合

図2. Looker Studioで可視化したダッシュボード

PM・エンジニアとの連携を深める

「PM・エンジニアとの連携を深める」ことは、上述したデータ提供スピードを高める上で重要なポイントでした。具体的には、対面でのコミュニケーションを増やすことを実践しました。STORESはフルリモートを前提とした働き方を推進してきましたが、3月のリリースに関わるPM・エンジニア陣は、意思決定と開発の速度を上げるために出社頻度を高めていました。開発に寄り添ったデータ活用を行う立場として、これまでのリモート前提の働き方ではプロダクトのキャッチアップやデータ提供スピードを高められないと判断し、私自身も出社頻度を高めることにしました。

ここで重要だと気づいたのは、連携を深める最善の手段が私の場合には出社でしたが、必ずしも出社だけがその手段ではないということです。データチームには地方在住のメンバーもいるため、チーム全員が気軽に出社できるわけではありません。そこでデータエンジニアのメンバーはプロダクトの開発メンバーが利用していたSpatialChatに参加することで、エンジニアとの連携を深めていました。普段であれば後日確認に回してしまう内容も、テキストや口頭で直ぐに確認する意識付けが重要なポイントだと再認識しました。

重要なテーマを捉える

「重要なテーマを捉える」ことは、分析課題の優先順位付けに大切なポイントでした。STORESでは今年から経営陣が全社の重要なプロジェクトに対してレビューする会が毎週設定されています。経営陣や部門長、プロジェクト関係者をはじめ、誰でも参加し議論できる場として活用されています。この会に参加することで、全社で何が重要なトピックであるかを把握できます。また、経営陣などの意思決定層が何に対して興味や課題を持っているのか、その興味や課題に対してどのようなデータとアクションを提供できるかを考えることができます。これにより、日々多くの分析・可視化依頼が来る中で、今向き合うべき課題の優先順位付けを行うことができています。

課題に感じたこと

急速なプロダクト開発に寄り添う中で、データ活用におけるいくつかの課題も見えてきました。

計測できていないデータ

今回のリリースでは、STORESのサービスサイトの設計も大きく変更されました。それに伴い、事業者のサイト訪問やオンボーディングのログデータの一部が正しく取得できないケースが発生してしまいました。これらのデータが計測できていないことは、リリースの成果だけでなく、マーケティングの投資対効果を正しく評価できないことにも繋がり、大きな課題でした。この課題については、データエンジニアがプロダクトサイドのエンジニアやマーケティングチームと連携して要因調査と解決に尽力してくれたため、非常に助かりました。

今後は、リリースに伴う影響をデータ取得の観点から事前に把握した上で、可能な限り計測できていないデータを減らすような取り組みを進めていきたいと思います。

SSOTの難しさ

2つ目は「SSOT（Single Source of Truth）の難しさ」です。分析のスピード感を追求する一方で、各所で発生する類似の依頼に対して複数のアウトプットが作成されてしまうケースが散見されました。また、そのアウトプットの定義が異なることで、どちらのデータを信頼すればよいのか、いわゆるSSOTが担保できていない状況が一定程度生じてしまいました。

この課題については、データ基盤のさらなる整備と全社的なモニタリング環境の整備を通じて、全員が同じ指標を見ながら事業運営できるような状態を目指していきたいと思います。

まとめ

これまでのSTORESのデータチームは、Issueベースで対応するいわゆる社内受託型のような進め方を主としてきました。これ自体は悪いことではなく必要なことですが、今年に入ってからはより高速にデータ提供と意思決定を回すための新しいデータチームの関わり方が見えてきたと感じています。プロダクト開発と伴走したデータ活用はさらに加速しており、直近ではビジネスサイドを含め、あらゆる部署とデータチームが一体となって取り組む形も進んできています。

今後もSTORES製品の価値向上と事業者の売上向上のために、データによる支援に取り組んでいきます。