1人目のデータアナリストとして分析基盤を立ち上げた話
（本記事は、2022年8月5日に下記Noteへ投稿した内容を転載しています）
こんにちは、株式会社カウシェでデータ分析を担当しているgoroです。創業間もないスタートアップでは、お金も時間も限られた中でデータ担当が1人いるかいないか、分析も分析基盤作りも両方やらなければいけない、けどそんなときに参考になる情報はそこまで多くはないと感じました。そのような境遇のデータ担当者に向けた記事を目指そうと思います。具体的にはこんなことを書きます。
- スタートアップで求められるのは安価で速いインサイトであること
- その要求に対して、一意のIDで繋げるデータを、3層構造の分析基盤に集めて応えたこと
- 具体的にはツールを使い倒した構造になり、意思決定にデータが介在する文化を作れたこと
スタートアップにおける分析環境の課題
最初はスタートアップにおいて分析基盤を作るときの課題、前提条件を共有します。
まずは人が居ない、足りないということです。創業半年ほどのタイミングで自分がカウシェに参加したときは、データ分析、基盤周りを見る人間は自分ひとりしか居ない状態でした。加えてマーケティングなどの他領域でも人が足りているとは言いがたい状態でした。結果的に半分は広告運用やCRM企画をやり、残り半分で分析と分析基盤の立ち上げをやるという、片足で靴を二足履くような状況でスタートしました。
また、それまで分析インサイトの貢献が多くなかった中で、成果の実感が小さい分析基盤に投資していくことは難しく、まずはすぐ出来る範囲で簡易なレポート業務をこなし、経営陣からの投資意向や他メンバーからの信頼を勝ち取る必要がありました（幸いにしてカウシェメンバーのデータリテラシーは高く、ここは大きな障害にはなリませんでした）
そしてなにより、求められるスピードは大きな企業のそれを上回るものがあります。具体的には、機能リリースから翌日にはその結果を見たい、翌週には継続可否や改善に向けたインサイトが欲しいなど、勝ちパターンが確立されていないPMF以前のサービスとして、定量的な評価をもとに高速に回す分析スピードが必要でした。
逆に言えばここのスピードと精度がそのスタートアップの成長確度を上げることが出来ます。いわば答えを見ながらテストを解くように、着実に前へ進む推進力を分析インサイトが生むことが出来るのです。このあたりの重要感をデータ担当者で信じること、また他メンバーへ理解してもらうことは分析基盤づくりが加速する鍵かもしれません。
やや蛇足になりましたが、改めてこのスピード感に応えるためには、分析基盤の立ち上げに要する時間と、データ追加や定義変更、分析実行に際する継続的な時間的コストを抑える分析基盤が必要となります。
前提としての条件を追加しておきます。まずはスタートアップにおいてはデータ量およびその種類が少ないです。また既に構築されたデータ基盤がないため、そこの調査や実務への影響範囲調査に悩まされることが少なく、大きなサービスよりも基盤作りが容易であることがよくあります。
また近年では、Saas等の性能向上も著しく、うまくツールを用いることでイニシャル、ランニング両面の人的、金銭的コストを抑えられるようになったことも重要な観点となりました。
どのように解決したか
さて、これまで共有してきた課題に対して、どのようなコンセプトで基盤作りを行ってきたかを書いていきます。
まずは「繋ぐ」ということです。ユーザごとのユニークIDなど、分析対象を一意に特定するキーは、データベースやクライアントログ、広告などのデータソースで共通して持つことが重要です。そうすることでユーザがサービスを初めて認識した時（広告等）からはじめて購入を行い、リピートを行い、サービスを使い続けるストーリーを追いかけることが出来ます。そうすることで局所的な指標（広告CTRや単発施策参加数など）の改善に終始することなく、LTVといった、プロダクトの提供価値を本質的に評価できる指標を計測できるようになります。
加えて、各所に散らばるデータを一ヶ所にあつめる重要性があります。そのメリットは多岐にわたります。まずはデータを探す手間が減ります。カウシェでは全てのデータをBigQueryに寄せており、「データ見たかったらBQ見てね」ということが出来ます。また属人的なデータ集計を廃し、整備された基盤上に集めることで、データ定義が氾濫することを避け、不適切なツールで分析を続けるためにかかる時間を減らすことが出来ます。
そして一箇所に集めた後に重要なのは、多層に分けておくということです。弊社では三層構造に分けており、ソースから持ってきたまま保存し、機械学習などに際する生データ参照用に第1層、よく使うするテーブル同士を予めジョインし、頻出のセグメント定義などを行う第2層、where条件での絞り込みを行い、各BIなど出力環境の要件に応えるため個別化されたクエリを備える第3層で構成されます。
ここで念頭に置きたいことは、サービス用のDBとは要件が違うということです。サービス用のDBは冗長性を廃することで管理やパフォーマンス性を求められます。一方で分析用には、一定以上のクエリ速度を維持した上で、人間による再利用、集計後の定義統一などが必要であり、理想的な形が異なります。
結果的に分析基盤はどのような構成になっていたか
結果としては以下のような構成になりました。
具体的な処理として、まず広告のアトリビューション計測ツールとして使っていたAdjustへ、データベースで使っているユニークキー（user_idなど）を返す Dynamic callback parameters 機能 利用をしました。
データ抽出に際しては、Firebase（アプリログ）、Firestore（RDB）、Shopify（注文情報）それぞれの拡張機能でBigQueryに転送しています。社内の業務上発生する手書きデータは、フォーマットをルール化した上でBigQueryのExternal Table機能で読み出しています。直接BigQueryに書き出せないデータについてはGoogleSheetやGoogle Cloud Storateなどを一時保存用に使い、そこから読み出しています。
BigQuery 上での中間テーブルの作成は Scheduled Queries で制御し、SQLさえ書ければ立ち上げられる簡易のワークフロー管理を実現しています。
実際にどんな成果が出たか
そして実際にどんなインサイトを出しているか。料理に例えれば、食材（データ）を料理人（アナリスト）が調理器具（分析基盤）を使って料理（インサイト）を作ります。そしてこの料理の美味さにあたるのが、そのインサイトによってどれだけ組織の意思決定を早く、効率化できたかであり、ここが分析基盤から分析実行、結果共有までの最終的な結果指標になります。
実際のデータ分析の結果について深ぼることは別記事に譲るとして、その影響を垣間見た例を紹介します。
上はカウシェSlackでの会話の一つです。とある機能の要否を議論していた際に「数値見て対応」という挙動になるのは、ファクト認識の重要性が十分に認知されていることはもちろん、見たいと思った数値が意思決定のスピード感に間に合う、ということが習慣的に行われている、つまりデータが欲しいときに出てくる信頼があることの結果であると考えられます。
ソーシャルECという未だ日本で誰も成功していないサービスを作っていくカウシェにおいて、どんな機能が必要とされるかは、実際に作ってリリースしデータを見ないと分かりません。そのような未踏領域にて、影響の大きさと変化の伸び代を見定め、限られたリソースの最適配分を果す、その道標をデータが生み出すことができます。
今後どうしていくか
いま、カウシェの分析基盤は進化が求められています。データ量およびその種類の増加に対して、ワークフロー管理の整備が必要です。また厳密な個人情報保護に対応したアクセス制御やユニークキー処理が必要です。そして、こちらの記事で書いたようにレコメンドシステムの開発と改善を進めるための基盤作りも、分析用途とは異なった知見を集めて実現していく必要があります。
これまでは分析と基盤作りを1人でやってましたが、今後はデータエンジニア、MLエンジニアの方にお願いしていきたい部分であり、採用強化中です。まずは以下のカジュアル面談よりお話してみませんか！よろしくお願いいたします！
他ポジションの募集についてはこちらから↓
