プロダクト観点で考えるデータ基盤の育成戦略 / Growth Strategy of Data Analytics Platforms from a Product Perspective

登壇イベント: https://datatech-jp.connpass.com/event/335207/

Transcript

1. プロダクト観点で考える データ基盤の育成戦略 みんなの考えた最強のデータアーキテクチャ〜2025もやってきましょうSP！ 株式会社ヤプリ ⼭本 雄太
2. SPEAKER 開発統括本部 プロダクト開発本部 データサイエンス室 ⼭本 雄太 • 2023年に新卒⼊社 • dbt導⼊に際して、開発体制やリリースフローなどの 構築を担当 • 最近はデータカタログ拡充‧ドキュメント整備に取 り組み中 • pUG（旧TROCCOUG）の運営にも携わらせていただ いています
3. ヤプリの製品｜ノーコードのアプリ開発プラットフォーム「Yappli」 • 700社以上が導⼊、800アプリ以上を提供 • 40種類以上の機能が利⽤可能。多様なシーンに合致したアプリが作成可能
4. ヤプリの製品｜Yappli 導⼊顧客向けにアナリティクスサービスを提供 CMS ダッシュボード Yappli 管理画⾯のトップに 表⽰されるダッシュボード Yappli Data Hub アプリ内の⾏動データや属性データを ユーザ単位で分析を可能にする データ連携サービス Yappli Analytics アプリログを網羅した分析や、 機能別に特化した分析が可能な ダッシュボード
5. 今回お話しすること • ヤプリのデータ基盤の成り⽴ち • 「プロダクトの⼀部としてのデータ基盤」における育成戦略
6. ヤプリのデータ基盤の珍しい成り⽴ち 1. 社内でデータ活⽤のニーズが発⽣ 2. ニーズに応えることでデータ基盤が 誕⽣ 3. さらなるニーズ発⽣→対応を繰り返 しながらデータ基盤が成⻑ 1. YappliのCMSにダッシュボード機能 をつけるためにデータ基盤が誕⽣ 2. ダッシュボード機能を強化するため にデータ基盤を強化 3. ダッシュボード機能以外でも使われ るデータ基盤に成⻑ よくあるデータ基盤の成り⽴ち ヤプリのデータ基盤の成り⽴ち プロダクトの⼀機能として作られ育てられてきた
7. INDEX ⽬次 1. GA360期 2. 内製基盤：⽴ち上げ期 3. 内製基盤：安定期 4. データ基盤独⽴期 5. これまでを振り返って 6. まとめ
8. GA360期（2019年〜2021年） 1. GA360期 アプリの 操作ログ GA360 BigQuery 集計バッチ＆ ダッシュボード表⽰⽤DB Yappliの CMSダッシュボード GA360で操作ログをトラッキングし、 BigQueryへストリーミングエクスポート CMSにアクティブユーザ数の推移などを表⽰する ダッシュボード機能を提供 ポイント💡｜当時はまだ社内にデータ⼈材（データサイエンティストなど）はいなかった • PdM、エンジニアが設計‧実装 • BigQueryに蓄積されたデータはCMSダッシュボード以外には使われていなかった
9. 内製基盤：⽴ち上げ期（2021年〜2022年） • GoogleからGA360→GA4への移⾏アナウンスが出た • さらなる事業成⻑のため、YappliのCMSを刷新したい ◦ 開発速度やユーザ体験を向上させたい • アプリのプラットフォーマーとして、データを武器にしていきたい ◦ アプリのプラットフォーマーだからこそ、様々なアプリの利⽤ログを蓄積できる ◦ 1⼈⽬のデータ⼈材（データサイエンティスト）の⼊社 • YappliのCMS刷新※に併せてデータ基盤も刷新 ◦ トラッキング機構を内製して脱GA360 • 蓄積したデータを活⽤する新サービス「Yappli Data Hub」の提供を開始 ◦ CMSダッシュボード以外のデータ提供先ができた 2. 内製基盤：⽴ち上げ期 ※ … 詳細はこちら: https://whatweuse.dev/article/yappli
10. 新データ基盤の構成図 2. 内製基盤：⽴ち上げ期 アプリの 操作ログ 内製トラッキング機構※ BigQuery 集計バッチ＆ ダッシュボード表⽰⽤DB YappliのCMS ダッシュボード Yappli Data Hub 集計バッチ NEW!! NEW!! NEW!! ポイント💡｜DWH層は設けず、Data Lake層から1テーブル1クエリの⼀気通貫でMart層を作成 • 基盤の⽴ち上げ期はどんなトラブル‧問い合わせが来るかわからない → アーキテクチャをシンプルにして、トラブル発⽣時の影響範囲を⼩さくして対処しやすくした • デメリット: 同じ集計処理を何度も⾛らせることになる（＝時間、お⾦の無駄が⼤きい） → 新データ基盤＆刷新後のCMSダッシュボード‧Yappli Data Hubサービスをまずは軌道に載せる ※ … 詳細はこちら:    https://cloud.google.com/customers/yappli?hl=ja
11. 内製基盤：安定期（2022年〜2023年） 3. 内製基盤：安定期 アプリの 操作ログ 内製トラッキング機構 BigQuery 集計バッチ＆ ダッシュボード表⽰⽤DB YappliのCMS ダッシュボード Yappli Data Hub 集計バッチ Looker カスタムダッシュボード (Yappli Data Hub) TROCCO 社内問い合わせ NEW!! NEW!! NEW!! • 社内からの集計依頼や問い合わせが増加 • データ連携ツールとしてTROCCOを導⼊※ ◦ Yappli Data Hubにて、Lookerを使ったカスタム ダッシュボードの提供開始 ◦ 営業部⾨でLookerを使ったレポーティング開始 ポイント💡｜TROCCO上でデータモデリングが洗練されていった • 共通指標の誕⽣ ◦ アクティブユーザ数、PV数、プッシュ開封率、etc. • 共通データマート作成ワークフローの誕⽣ ◦ ＝DWH層の誕⽣ ※ … 詳細はこちら: https://primenumber.com/cases/yappli
12. データ基盤独⽴期（2023年〜） • シンプルさ重視で許容していた無駄が許容できなくなってきた（特にお⾦） • データ⼈材1⼈体制では回らなくなってきた • データ⼈材を増やしてデータマネジメントを強化 ◦ 2023年に2⼈（うち1⼈が私）、2024年に1⼈の新メンバーが⼊社 ◦ TROCCOで動いているワークフローのうち、共通データマート作成部分をdbtへ移⾏ ◦ Data Lake層から直接Mart層を作っていたCMSダッシュボードやYappli Data Hubに対して、 dbtで作ったDWH層への繋ぎかえを実施 4. データ基盤独⽴期 CMSダッシュボードのためのデータ基盤だったものが完全に独り⽴ち
13. 現在のデータ基盤の構成図（※取り組み中のものも含む） 4. データ基盤独⽴期 アプリの 操作ログ 内製トラッキング機構 BigQuery (Data Lake層) データ設置バッチ＆ ダッシュボード表⽰⽤DB YappliのCMS ダッシュボード Yappli Data Hub データ設置バッチ Looker カスタムダッシュボード (Yappli Data Hub) TROCCO (データ設置) 社内問い合わせ dbt※ BigQuery (DWH層/Mart層) NEW!! NEW!! UPDATE UPDATE UPDATE 集計ロジックはdbtへ集約 TROCCO (社内⽤途) NEW!! 社内からの集計依頼など柔軟性が求められるものは 引き続きTROCCOで対応 （要件が固まってきたらdbtへ移⾏） 元からあった各集計バッチはdbtが作成したデータマートを 各データ提供先へ設置するバッチに ※ … 詳細はこちら: https://tech.yappli.io/archive/category/dbt
14. これまでを振り返って 5. これまでを振り返って
15. 5. これまでを振り返って 1. 社内でデータ活⽤のニーズが発⽣ 2. ニーズに応えることでデータ基盤が誕⽣ 3. さらなるニーズ発⽣→対応を繰り返しながら データ基盤が成⻑ 1. YappliのCMSにダッシュボード機能をつける ためにデータ基盤が誕⽣ 2. ダッシュボード機能を強化するためにデータ 基盤を強化 3. ダッシュボード機能以外でも利⽤可能なデー タ基盤に成⻑ よくあるデータ基盤の成り⽴ち ヤプリのデータ基盤の成り⽴ち
16. 5. これまでを振り返って 1. 社内でデータ活⽤のニーズが発⽣ 2. ニーズに応えることでデータ基盤が誕⽣ 3. さらなるニーズ発⽣→対応を繰り返しながら データ基盤が成⻑ 1. YappliのCMSにダッシュボード機能をつける ためにデータ基盤が誕⽣ 2. ダッシュボード機能を強化するためにデータ 基盤を強化 3. ダッシュボード機能以外でも利⽤可能なデー タ基盤に成⻑ よくあるデータ基盤の成り⽴ち ヤプリのデータ基盤の成り⽴ち 社内ニーズを軸にSmall start, Quick winで育成 Yappli契約顧客を軸にSmall start, Quick winで育成 実は本質的には同じ育成戦略 どちらも「データ利⽤者を軸にSmall start, Quick winで育成」
17. そもそも育成戦略とか考えてなかった😇 • 元々YappliのCMSにダッシュボード機能を作るために作られたデータ基盤 • 当時はデータ⼈材がいない状況だった → データ活⽤推進を⽬的にロードマップが敷かれていた訳ではなかった • その場その場で「今できる最善策」を採り続けた結果、よくあるデータ基盤 と同じ育成戦略になった 5. これまでを振り返って 何をもって「最善」と判断していたのか？
18. 何をもって「最善」と判断していたのか？ • データ利⽤者が成功体験を積み重ねやすいこと ＝ 「最善」 5. これまでを振り返って データ利⽤者 成功したいもの やったこと ① GA360 Yappli契約顧客 （アプリ運⽤者） アプリの運⽤ （⾃社アプリのユーザの新規獲得‧育成 etc.） • CMSにダッシュボード機能をつける ② 内製基盤：   ⽴ち上げ期 Yappli契約顧客 （アプリ運⽤者） アプリの運⽤（もっと） （⾃社アプリユーザのロイヤルカスタマー化 etc.） • CMSダッシュボードの強化 • Yappli Data Hubの提供開始 ③ 内製基盤：   安定期 社内 （営業、CS etc.） ⾃⾝の業務 （より良い顧客提案、受注 etc.） • 社内依頼対応 ④ データ基盤   独⽴期 全てのデータ利⽤者 各々の今まで‧これからのさらな る成功 • データ基盤の独⽴ • データマネジメントの強化 データ利⽤者が成功体験を積み重ねる ＝ 信⽤貯⾦UP↑ → 貯めた信⽤貯⾦でデータ基盤を育成
19. 「今できる最善策」を採り続けるために • 負債の拡⼤を恐れない ◦ 後から負債解消に取り組んだ⽅が今取り組むより簡単なことがある ▪ ニーズ⾃体が消失して、そもそも負債解消が不要になった ▪ より良いソリューションが登場して、負債解消に取り組みやすくなっている • 特に、早すぎる共通化‧最適化に気を付ける（誘惑に耐える） ◦ データ利⽤者の成功にMUSTなことは「早く集計結果を届けること（正確であることは前提として）」 → 「その集計過程が綺麗に整ってること」はMUSTではない ▪ データ利⽤者が成功を積み重ねないと、データ基盤は成⻑しない ＝ 早くから共通化‧最適化に取り組んでもデータ基盤が成⻑しなかったら無意味 → 共通化‧最適化の誘惑に負けず、「正確な集計結果を”早く届ける”」を徹底する ◦ データ利⽤者の需要に追いつけなくなってきたくらいでようやく取り組み始める ▪ 何を共通化‧最適化すべきかの勘所が磨かれている状態 → 良いデータ基盤が設計できる 5. これまでを振り返って
20. 共通化‧最適化に取り組むにあたって 「データ利⽤者の需要に追いつけなくなってきたくらいでようやく取り組み始める」 → 余裕がない状況下でどうやって共通化‧最適化に取り組めば…？ ヤプリが良かったところ: • 新メンバーを採⽤し、既存業務ではなく共通化‧最適化業務に割り当てた ◦ 元から在籍していたメンバー（1⼈） ▪ 引き続きデータ利⽤者の需要に応え続ける ◦ 新たに⼊社したメンバー（2⼈） ▪ 共通化‧最適化に取り組む 5. これまでを振り返って データ利⽤者へのレスポンス速度を維持しつつ、 別業務の割り込みを抑えてスムーズに共通化‧最適化を進められた
21. まとめ 6. まとめ
22. まとめ • データ基盤は社内ニーズだけでなく、プロダクトの⼀機能から誕⽣すること もある • どのような誕⽣の仕⽅であっても、育成戦略は同じ • 育成のコツ: ◦ 最初はDWH層を設けずData Lake層から⼀気通貫でMart層を作ることで、データ利⽤者が早 く成功体験を積み重ねられるようにする（＝信⽤貯⾦を作る） ▪ 負債の拡⼤を恐れないことが⼤事。特に早すぎる共通化‧最適化の誘惑には耐えよう ◦ ⼀気通貫スタイルに限界が来たら、信⽤貯⾦を元⼿にDWH層を作って共通化‧最適化に取り 組む ▪ これまでの知⾒から、何を共通化‧最適化すべきかが⾒えるはず 6. まとめ ⽬指せ！⾃分の考えた最強のデータアーキテクチャ！💪