はじめに
heyのデータチームで働いている田島です。
2021年の上半期、heyのデータチームは、エンジニアとアナリストが協力して統合データ基盤をゼロから作り上げてきました。
なぜゼロから作る必要があったか説明するために、簡単にheyの成り立ちとサービスを紹介します。heyは、中小企業や個人事業者にサービスを提供する3社が統合されてできた会社であり、現在では、ネットショップ開設・POSレジ・キャッシュレス決済・オンライン予約システムと、お店のデジタル化をまるっとサポートするための、4つのサービスをSTORESブランドのもと展開しています。
データチームの役割は、これらのサービスを横断して様々な切り口で分析し、オーナーさん（お店を運営する企業や個人の方を社内ではオーナーさんと呼んでいます）と事業にとって望ましい方向へ進むように意思決定をサポートします。社内の様々なチームのミッションに寄り添い、意思決定の不確実性を下げることで、オーナーさんに提供できる価値を最大化することを目指しています。多様な業種・地域の、購入・決済・予約といったダイナミックなデータを縦横無尽に分析する必要があることが、heyのデータ分析の難しいところであり、面白いところでもあります。
heyは3社が統合されてできた会社であるため、各サービス個別のデータ分析環境は存在しているのですが、横断的な分析の難易度が高い状況にありました。この課題を、統合データ基盤を開発することで解決しています。
今回は、特に社内のメンバーの目に触れやすいデータマートとBIツールについて、横断的な分析を実現するための工夫をお話します。データマートを運用している方や、これから作りたいと思っている方の参考になれば嬉しいです。
なお、統合データ基盤全体のアーキテクチャに興味のある方は、こちらのブログもぜひご覧ください。
分析を行う上での困難
私が入社した2021年初頭は、正確なデータを簡単に得られないためにデータ分析のハードルが高い状況でした。以下の3つが主な要因です。
KPIの不整合が頻繁に起きている
SQLを書くメンバーによってKPIの不整合が発生しやすい状況でした。サービス開始から年月が経つうちに、当然サービスのデータ構造は変化していきます。それに合わせて、正しいKPIを算出するために必要な条件、いわゆる”おまじない”が増えていき、基本的な事業数値であっても正確なSQLを書くことが難しい状況になっていました。
また、BIツールよりもスプレッドシートで数値を管理するケースが多く、スプレッドシート同士で数値が合わないという大変つらい状況が散見されていました。このような不整合は、ほっておいても気持ち悪いが、莫大な労力がかかる割に解決しても特に嬉しくないというやりたくない仕事リスト上位にランクインする類のものです。
データ構造の学習コストが高い
サービスのDBをもとに作られたデータウェアハウスは、当然ながらサービスの機能や歴史的経緯、データ構造に習熟していないと正しい分析ができません。heyの場合はそれが4サービスあり、かつheyとして統合される前は独自に運営されていたため、設計コンセプトや運用に様々な違いがあります。それらを学習しないと、heyの強みである「お店のデジタル、まるっと」を実現するための横断的な分析ができません。
また、スプレッドシートは、インタラクティブに数値を管理してシミュレーションするには最適ですが、多くのメンバーが日常的にチェックするべきKPIダッシュボードには向きません。まず、グラフでビジュアルに状況がわからないと見る気を失いますし、数値の算出方法を知るために、何枚ものシートを渡り歩くスプシ考古学スキルが必要となっていました。
サービス横断の分析が一箇所でできない
サービス横断の分析を阻んでいたものは学習コストだけではありません。そもそも使用しているBIツール、クエリエンジンがばらばらであり、分析環境に連携されていないSaaSやスプレッドシートだけで管理している情報も大量にありました。サービス横断で分析するためには、各ツールで算出したデータをCSVで落としてからスプレッドシートに集約して整形しなくてはなりません。これを繰り返していくと、学習コストもKPI不整合もより高まっていくことが予想されました。
データマートとは
これらの課題を解決するために、横断的にデータを集約するデータウェアハウスとBIツールを用意しただけでなく、その間に新たにデータマート層を設置しました。
データマートの定義は組織によって異なると思いますが、heyの場合は、データウェアハウスから抽出され、ニーズに合わせて正規化された分析用のデータベースといった感じでしょうか。その実体はBigQueryのデータセット群であり、データマートを構築するSQLはすべてGitHubで管理され、テーブルはCIで自動更新されています。
heyのデータマートの狙いは、横断的な分析を行うハードルを極力下げることです。
欲しいデータがある場所が容易に分かり、得られたデータの正確性が担保され、サービス横断でオーナーさんと事業のことが理解できる。各チームはSQLを書かなくともデータを容易に取得でき、顧客の解像度を高めることや意思決定の不確実性を減らすことに集中できる。データアナリストはデータ抽出のために似たようなSQLを何度も書かずにすみ、専門知識を活かした分析ができる。そんな状態が理想的です。
運用方針
目指すべきデータマートのイメージが湧いたところで、実現するための運用方針を定めていきます。
SQLはできるだけデータマートを生成するために書く
別の言い方をすると、BIツールにはロジックを書かず、データマートのビジュアライゼーションに特化させるということです。
エンジニアやアナリストにとって、データを可視化するときにはささっとBIツールにSQLで書いちゃうのが一番楽になりがちです。しかし、大事なロジックを含むSQLがいろいろな場所に散らばっていると管理が大変ですし、SQLが得意な人しかデータに触れなくなってしまいます。そこで、よく使うテーブルや指標は、前処理して正規化した上でデータマートに格納し、BIツールでデータマートを組み合わせることで表現します。そうすることで、BIツールだけでなく、スプレッドシートのデータコネクタ機能や、Google Colab といった様々な環境から集計済みで正確な指標を手に入れやすくなります。
この運用は社内に強制しているものではなく、チームにSQLが得意な人がいればもちろんBIツールにSQLを書いてかまいません。影響範囲の広いKPIを扱うデータアナリストが気をつけているルールです。具体的には、BIツールのGUIを使う縛りを課しており、GUIでは複雑なロジックを実現できないことが多いので、自然とデータマートが充実していきます。
SQLが苦手な人でも、データアナリストが作ったグラフのGUIを通して、データ構造の理解を深め、自力で分析できる機会が増えるはずです。
命名と構造は、サービスDBよりもデータマートの一貫性を優先する
BIツールのGUIでは、データマートしか参照できないようにしています。分析によく使うテーブル・メトリクスは基本的にすべて前処理したうえでデータマートにしているため、できるだけデータマートを参照することでKPI不整合を防ぐためです。もちろん、サービスDBのすべてをデータマートにしているわけではないので、依頼頻度の高いものから順にデータマートを作っています。
そのときに、テーブル名、カラム名やデータ構造は、サービスDBよりも、データマートの一貫性を優先するようにしています。なぜならば、もとのサービスDBを優先してしまうと、せっかく一箇所に集めたのに学習コストが個別にかかってしまうためです。データマート自体のテーブル名やカラム名に一貫性をもたせることで、一つのサービスのデータマートの構造がわかれば、学習コストをかけずの他のすべてのサービスに対しても同様な分析ができるようになります。
データチームが正確性を担保するダッシュボードを分ける
データマートを使う対象は社内のメンバーであり、求められるサービスレベルがそこまで高いわけではありません。また、集計元のデータはウェアハウス層にあり、マートを生成するSQLはGitHubで管理しているため、データ自体や算出SQLが失われることもありません。
そのため、将来より利便性の高い構造にするために、データマートに破壊的な変更をすることを恐れないようにしています。BIツールやスプレッドシートにエラーが起きることもありますが、現在の規模ならば、利用している人がデータチームに教えてくれたり、アナリスト自身が直して回ったりするくらいの運用で問題ないだろうと思っています。
そのとき、グラフやダッシュボードは、放っておくと無秩序に増えていって、どのダッシュボードがメンテナンスされているのかわからなくなりがちです。そのため、heyではBIツールのコレクション機能（階層を作ってグラフやダッシュボードを整理する機能）を用いて、データチームが責任を持ってメンテナンスする重要ダッシュボードと、各チーム・個人が自由にいじる場所を区分しています。ダッシュボードやグラフのオーナーを階層構造によって示し、メンテナンスのレベルを分けることで、データチームが気にすべき影響範囲を限定しつつ、heyのメンバーにとっても信頼できるデータがどこにあるかわかりやすいようにしています。
データマートの命名と構造
ここからは実際のデータマートを紹介しつつ、運用方針で触れた一貫性とはどのようなものなのか見ていきます。
データセット
データマートは、以下のデータセットを中心に構成されています。
mart_common: サービス横断のデータを格納mart_ec: STORESのデータを格納mart_payments: STORES 決済のデータを格納mart_reserve: STORES 予約のデータを格納mart_regi: STORES レジのデータを格納mart_ga4_owners: オーナーさん向けWebサイトのデータを格納
これらは、様々なチームの方が使用する想定のデータセットです。これに対して、一つのチームに限定されたテーブルをアナリストがオーダーメイドで作るときは、_tailored という接尾辞のついたデータセットに格納して、データセットの中身が増えすぎて理解しにくくなることを防いでいます。
テーブル
それぞれのデータセット内には、基本テーブルと時系列テーブルが存在します。
ネットショップ（STORES）について具体例を見ながら説明していきます。
基本テーブルは、各サービスで主な関心の対象についてのデータを整理しています。
ネットショップであれば当然「ストア」が関心の対象であり、store_を接頭辞としたテーブルが該当します。
stores: ストアの属性と現在の状態を整理store_onboarding: ストアの最初の状態の変化を整理store_route: ストアの獲得経路を整理store_metrics: ストアに関する事業指標（過去1ヶ月の売上等）を整理
時系列テーブルは、一定の時間間隔で集計されたデータを整理しており、daily_ / weekly_ / monthly_ のいずれかの接頭辞がつきます。
daily_store_summary: 日次の開設ストア情報を整理daily_order_summary: 日次のオーダー情報を整理daily_store_order_detail: 日次のストアごとのオーダー情報を整理daily_kpi_forecasting: 日次のKPI予測情報を整理
以上で説明したデータマートはごく一部ですが、この命名規則は他のサービスでも成り立ちます。例えば、STORES 予約では、主な関心の対象を「マーチャント」と呼称し、注文ではなく予約するサービスです。そのため、STORES 予約のデータマートには、mart_reserve.merchant_onboarding や mart_reserve.monthly_reservation_summary が存在します。このように同じ命名規則を用いているので、一つのサービスに慣れれば他のサービスの分析をする際にも、どこに欲しいデータがあるか類推しやすくなっています。
この一貫性を保つために、もとのサービスDBのテーブル構造には従っていません。そのおかげで、ストアの属性と現在の状態を知りたいとき、サービスDBのテーブルでは何個もテーブルを結合しなくてはならないのに対して、データマートでは mart_ec.stores さえ見れば足ります。さらに、データチームが store_id で一意になっていることを担保し、各種の前処理をしているので、安心して使うことができます。
また、KPIを見たいときも、たいていの見たい数値はすでに集計されて時系列テーブルに格納されているので、そのままグラフにしたり、日付で他のデータと結合することができます。
カラム
テーブル名だけでなく、それぞれのカラム名やその中身にも一貫性を持たせています。
- datetime型のカラム名には必ず
_atという接尾辞をつけ、date型のカラム名には必ず_dateという接尾辞をつけ、すべてJSTに直しておく - 最初の状態変化を示すカラム名には必ず
first_という接頭辞をつける - 数字で定義されたステータスはすべて文字列に変換しておく
- 「先月の売上」は
last_month_gmvと表記するなど、極力サービス間で同じ英単語を使う
もとのサービスDBで使われている名前から乖離しすぎるとそれもまた意味を類推しづらくなるため、バランスを見ながら一貫性に気を使っています。実際にデータマートを生成するためのプルリクをレビューするときも、カラム名やテーブル名は一緒に悩むことが多いです。
これらの前処理のうち、ウェアハウス層で行うものとマート層で行うもので、いかに責務を分割するかはまだ探り探りではあり、今後変更されるかもしれません。その際も、データマートが提供するインターフェイスが変わらなければ既存のSQLへの影響は最小限に抑えることができます。
実際に使われている様子
整備されたデータマートが実際に活用されている事例として、マーケティングチームが頻繁に実施している指差しワークがあります。
指差しワークとは、オーナーさんのストアURLやSNS 、獲得経路、売上、初売上にかかった日数、所在地などの情報を1件ずつ指差しで辿っていき、感じたことや考えたことを元にわいわい会話しながら、オーナーさんについてみんなで掘り下げる、施策のアイデア出しまでやる会です。情報の抽象度の高い統計値だけでなく、1つのストアの具体的なデータを通して課題を考えたりすることで、理解を深めていきます。
この会を実施するためには、多面的な情報がストアごとに集約されたダッシュボードが必要となりますが、データマートを駆使することで、SQLを書かなくともBIツールのGUI（上図）で作成することができます。この活動により、短時間で大量の情報を得て勘所をつかみやすくなるので、直接インタビューしたり訪問したりする活動と合わせて、マーケティングチームは顧客起点の施策を推進しています。
また、普段はBIツールに触る機会が少ないデータエンジニアからも、データマートの使いやすさは好評でした。
今後の課題とこれから
データマートの整備によって、データ取得にかかるコストは大きく減少しました。また、1度データマートを作ってしまえば、後々発生する面倒な繰り返し作業を回避できることがわかっているため、健やかなメンタルで仕事ができます。
今後はこの統合データ基盤を使って、データ分析で解決しうるスケーラブルな問題を設定することで、事業にもたらすインパクトを高めていきたいと考えています。heyのプロダクトではデータサイエンスが直接売上に貢献する機能（レコメンド等）がまだ少なかったり、精度の高い因果推論・モデリングやランダム化比較試験をするコストが合わなかったりすることもあります。しかしながら、非常に多様な業種やオーナーさんについての理解を得るために、ちょうどよい抽象度のラベリングをしてサポート体制に反映したり、多くの投資が必要な施策について初期からデータ分析を行うことでインパクトを推定するといった成長余地がまだたくさん残っています。
さらに、必要なデータを各チームが自力で取得して業務フローを効率化し、オーナーさんの課題解決にリソースを配分するために、データカルチャーをもっと育てていかなくてはなりません。そのためには、データマートやダッシュボードを一回作って渡すだけでなく、各チームが本当に求めているものをいつも提供できるように、統合データ基盤の設計や運用をフェーズに合わせて進化させていくことも欠かせません。
最後に、もしheyのデータチームに興味のある方がいましたら、このブログで話したような環境がすでに整いつつある今がチャンスです。日本各地のこだわりのあるお店を、持っている技術や経験を活かして、テクノロジーで支えていきましょう。
