見出し画像

導入だけで終わらないために...mybestが分析基盤の運用を初めてから1年が経ったので導入事例を共有します

こんにちは。マイベストでCTOをしている渡邊です。
最近は、採用・マネジメントを中心に稼働しつつ、遊撃的にいろんなことをやっていたりします。
実は、1年ほど前に、最近の取り組みとして「スプレッドシート or Redashで運用していたデータ分析をBigQueryに統合しています」みたいな記事を投稿していました。

今回は、この話を少し深掘り、分析基盤導入にあたって全社的に仕組みを浸透させていくためにどういった試みをしてきたのかを書きたいと思います。

前提

mybestでは、自社で商品を検証しそのデータを使ってユーザーの選択をサポートするようなサービス(https://my-best.com/)を運営しており、サービス運用の体制としてこのような特徴があります。

  • データを扱うメンバーが全社的(プロダクトを改善する人、コンテンツを改善する人、売上などの数値管理をする人)であること

  • 社内で分析を専門に担当する人・チームがないこと

  • 分析に利用するデータソースは複数サービスにまたがること

また、構築・運用にあたっては、現在も絶賛試行錯誤中なので優しい目で見ていただければ幸いです。

分析基盤導入前までの状態

mybestでは、分析用途に応じて複数のサービスを利用しながらデータ分析を行っていました。具体的には、

  • 検索順位:GRC(一部、Google Search Console)

  • ユーザー行動:Google Analytics、Google Optimize

  • 収益:各種ECサイトのレポートデータをGoogle スプレッドシートにエクスポートして加工

という感じです。またこの時のBIツールにはRedashがありましたが、データ分析は主にスプレッドシートを用いていました。

当時のデータ分析のイメージ

分析対象のデータ量がスプレッドシートで扱える程度で分析要件もそこまで複雑じゃない時期にはこの仕組みでも問題なく運用できていたのですが、サービスの利用者が増えるにつれて扱うデータ量が増えグロースや検証を目的とするプロジェクトが立ち上がり分析要件が複雑化してきたことで、以下のような問題が顕在化してきました。

  • 取得したいデータが一元管理できておらず、データ量も増えたことで分析データの準備に時間がかかる

  • データを扱うメンバーが増えたことで、データ抽出の基準が属人的になる

  • データの取り出し方に柔軟性がない形で作成していたため、複雑な分析要件に対応するのが大変

どれも分析基盤導入前の企業であればよくあるケースなのかもしれません。弊社ではこれらを放置しておくと、今後のプロダクト開発・運用のボトルネックとなり得ると判断し、問題を根本的に解消するために分析基盤を用意することにしました。

導入に当たって考慮したこと

分析基盤の導入に当たっては、弊社の現状を踏まえつつ以下の様な無理のないゴール設定をした上で、それを実現するための技術選定や導入後の社内への布教方法を検討しました。

  • データ準備のためのハードルをできるだけ下げるために、非エンジニア(SQLは書ける程度のスキル感を想定)でもデータマートの作成ができるようにすること

  • 作成したデータマートの運用が煩雑にならないような仕組みを事前に用意しておくこと

これらを事前に設定した目的は、分析基盤の導入というプロジェクトのゴールを、分析基盤の構築ではなく運用後のイメージを利用者・構築側が持てるところまで責任を持って進めることができるようにするためです。

どのような形で導入したか?

ここからは、この1年で導入するために具体的に行ってきたことをいくつか紹介します。

現在のユースケースを各部署にヒアリング

初めに、当時データ分析を担当していたメンバーに対して、以下の3つの確認を目的としたヒアリングを行いました。

  • 現状のユースケースに対応するための取得情報の棚卸し

  • 現状対応できていないが、ニーズの強い要件の把握

  • メンバーが手動で対応しているデータ準備の把握

対象メンバーへのヒアリングにはGoogle Formを利用し結果をNotionにまとめ、具体的なヒアリングはそれをもとに担当者と対面で行うことで、対応しなければいけないユースケースや要望に対して漏れなくカバーしています。

頑張りすぎない運用ルールを作成

各部署からヒアリングした情報と導入時に考慮した点を元に、運用ルールの草案を作り他のメンバー含めて議論してもらいました。

運用ルール作成にあたっては、分析基盤が既に導入されている同じような事業フェーズの企業の情報や業務委託として参画いただいているエンジニアの意見も参考にさせていただきできるだけ必要最低限の内容だけ決め
、あとは運用後の状況に合わせて更新しやすくすることを意識しました。

利用のハードルを下げるためよく利用されれるクエリのデータカタログを準備

今回ヒアリングを実施した際に、メンバーごとに同じ様な結果を抽出しているけどクエリはそれぞれが作成しているようなケースが散見されたため、よく利用されるクエリに関してはNotionの方にクエリカタログを用意しました。

これが作成されるまでは、Slackなどで抽出条件を聞かれる時に直接クエリを教えたりRedashで抽出できる結果を共有したりしましたが、これが作成された後にはできるだけこちらのページを教えるようにしています。

非エンジニアに向けてどういうことができるのか説明の場を準備

分析基盤を利用したことのないメンバーに対して、全体像や運用イメージを具体的に共有する場を設けました。

これは、

  • アンケートで回答したものがどのようにして解消されるのか?

  • 今後どのように利用できるのか?

などの全体像を主要メンバーに共有することで、分析基盤への期待値や認識を揃えることを目的に実施しました。

ハンズオン形式でデータマート作成のレクチャーを実施

プロジェクトに関わっていない開発メンバーに対して、ハンズオン形式の共有会を実施しました。

今回の基盤導入は自分と業務委託のデータエンジニアの2名体制で推進したということもあり、運用フェーズに入った時に実業務が暗黙知とならないように、とりあえずメンバーにさわる機会を持ってもらうことが狙いでした。事前にスライド資料を準備した上で、操作画面を共有しつつ各自で進めてもらう様な形式で進めたこともあり、実際運用開始後もほぼ問題なく利用してもらえる状態になりました。

どのような仕組みとなっているのか?

現在はBigQuery(DWH) + Trocco(ETL) + Redash or Data portal(BI)という構成でデータソースの全てをTrocco経由でBigQueryに連携するような形で運用しています。

BIには、引き続きRedashを利用しつつ、一部ではGoogleデータポータルを使ったダッシュボード作成なども行うようになりました。このあたりの話はまた別の機会に共有できればと思います。

導入までどれくらいの時間がかかったのか?

プロジェクト開始から導入・運用までどれくらい時間がかかったのか?に関しても参考までに残しておきます。かなりざっくりとしたものではありますがプロジェクト開始から本運用まで2ヶ月弱ほどかかりました。内訳はこんな感じです。

  • 他部署へのヒアリングと要求の作成:1週間

  • 技術選定と運用フローの作成:2週間

  • 分析基盤の構築:2〜3週間

  • テスト運用:2〜3週間

  • チーム・他部署への周知:1週間(本運用開始後は随時)

(分析基盤の構築はイベントの生データ取得対応も含まれているため、その辺りの対応がなければ1週間程度で終わるぐらいの規模感だったと思います)

分析基盤を導入してみてどうだったか?

今回の導入によって、課題となっていた「データ準備の時間」「データ取り出しの柔軟性」に関しては、今回の仕組みの導入で大きく改善されました!
運用においては、即時性のある施策(ABテストなど)や一定期間で検証するような施策を行うことができるようになり、データ準備に関してもTroccoのワークフローに一度登録してしまえば次からは準備不要でデータを用意できるようになったことで分析にかけられる時間も大幅に増えたと思います。

一方で、課題として、まだまだこの仕組みを当初のターゲットとしていたメンバーまで拡大することはできておらず、今後も地道に分析基盤を活用することのメリットや、使い方に関するフォローなど、草の根活動を頑張っていく必要がありそうです。

最後に

今回は、分析基盤立ち上げにあたり、その仕組みをどう浸透させていったか?を実例込みで紹介しました。
データを分析する仕組み自体は少しずつ整いつつあるものの、分析データの活用はまだまだ改善の余地が多く、冒頭で説明した通り社内で分析を専門に担当する人・チームもないのでこの辺りを積極的に推進していただける・ご興味があるという方がいましたらぜひカジュアルにお話させてください!


この記事が気に入ったらサポートをしてみませんか?