「必要とされるデータ基盤」であり続けるためにやってきたこと / What We've Done to Make a Needed Data Analytics Platforms Grow

レバテック Meetup～活用ファーストで考えるデータ基盤～ - connpass
https://levtechcareer.connpass.com/event/366066/

Transcript

1. 「必要とされるデータ基盤」で あり続けるためにやってきたこと 2025.9.4 in レバテックMeetup 株式会社ヤプリ ⼭本 雄太
2. SPEAKER 開発統括本部 プロダクト開発本部 データサイエンス室（以下、DS室） ⼭本 雄太 • 2023年に新卒⼊社 • dbt導⼊に際して、開発体制やリリースフローなどの 構築を担当 • pUG（旧TROCCOUG）の運営にも携わらせていただ いています
3. ノーコードのアプリ開発プラットフォーム「Yappli」 ヤプリの製品 • 750社以上で導⼊、 約900アプリを提供 • 50種類以上の機能で、 多様なシーンに合致した アプリが作成可能
4. Yappli導⼊顧客向けにアナリティクスサービスを提供 ヤプリの製品 CMSレポート Yappli 管理画⾯に表⽰される レポート画⾯ Yappli Data Hub アプリ内の⾏動データや属性データを ユーザ単位で分析を可能にする データ連携サービス Yappli Analytics アプリログを網羅した分析や、 機能別に特化した分析が可能な ダッシュボード 無償 有償
5. データ基盤は 必要とされ続けることが重要
6. ヤプリのデータ基盤は必要とされ続けている • プロダクト⽤データ基盤：Yappliのサービスデータを扱う ◦ 各アナリティクスサービスの提供 ◦ Yappliの機能開発の優先度づけの根拠 ◦ 顧客へのCS活動の補助 ▪ アプリの運⽤状況の把握、施策の効果検証、etc. ◦ 営業戦略の補助 ▪ アプローチをかけるべき業界の検討、etc. • ビジネス⽤データ基盤：Salesforce等のビジネスデータを扱う ◦ 経営指標のモニタリング ▪ 売上⾼、受注件数、チャーンレート、営業進捗、etc.
7. 必要とされ続けるために 何をやってきたのか？
8. INDEX ⽬次 1. 要望に応え続けした 2. エンジニアから集計の責務を剥がした — 3. 必要とされ続けることで起きること
9. INDEX ⽬次 1. 要望に応え続けした 2. エンジニアから集計の責務を剥がした → 要点だけ。⼤幅カット🙇   （詳細は後述の過去登壇資料をご覧ください） — 3. 必要とされ続けることで起きること
10. 要望に応え続けた
11. 「要望に”応え続ける”」には • 様々なデータ利⽤者からの「〜したい」を実現し続ける • データ利⽤者から要望が勝⼿に集まってくるようにすることが重要 ◦ ヒアリングしないと要望が出てこない場合、データ基盤がうまく活⽤されてない可能性あり ▪ ちゃんと活⽤されていれば要望（や不満）が⾊々出てくるはず 1. 要望に応え続けした
12. 要望が勝⼿に集まってくるようにするには？ • 「要望を⾔えば応えてもらえる」という信頼を得ること • カジュアルに要望が⾔える関係値を築くこと 1. 要望に応え続けした
13. 要望が勝⼿に集まってくるようにするには？ • 「要望を⾔えば応えてもらえる」という信頼を得ること • カジュアルに要望が⾔える関係値を築くこと 1. 要望に応え続けした
14. 要望が勝⼿に集まってくるようにするには？ • 「要望を⾔えば応えてもらえる」という信頼を得ること ◦ 要望にスピーディーに応える ◦ 直接叶えられなくても、代替案で可能な限り応える • カジュアルに要望が⾔える関係値を築くこと 1. 要望に応え続けした
15. 「要望を⾔えば応えてもらえる」という信頼を得るには 要望にスピーディーに応える • 早く対応してもらえると、シンプルにありがたい ◦ 弊社の場合、社内からの要望‧問い合わせはなるべく1営業⽇以内に対応 • すぐ対応できない場合は⼀次回答 ◦ リアクションを押したり、「ちょっと待ってね」を返信したり ◦ ⼀次回答がないと… ▪ 要望を送った側は「対応に時間がかかってる」or「⾒逃してる」がわからない → 地味にストレス ◦ ⼀次回答が早いだけでも信頼は少しながら得られる 1. 要望に応え続けした
16. 「要望を⾔えば応えてもらえる」という信頼を得るには 要望にスピーディーに応える • 要望‧問い合わせ対応を頑張ってたら、他の仕事できなくない？ ◦ 根本的な改善タスクに取り組めず、その場しのぎの対応しかできない… • 採⽤した新メンバーに根本的な改善タスクを任せる ◦ 元から在籍していたメンバー（1⼈） ▪ 引き続き、要望‧問い合わせ対応 ◦ 新たに⼊社したメンバー（3⼈） ▪ 根本的な改善タスクを担当 • dbt導⼊、RevOps基盤構築 1. 要望に応え続けした 要望に応え続けつつ、⼤元のデータ基盤をしっかり成⻑させる
17. 「要望を⾔えば応えてもらえる」という信頼を得るには 直接叶えられなくても、代替案で可能な限り応える • 応えられる要望の数は多い⽅が早く信頼が得られる • 要望をしっかり聞いてみると、そこまで正確性が求められてないこともある ◦ 代替案での近似で⼗分応えられるケースも全然ある ◦ 実際にあった事例） ▪ 要望: Yappliの機能の改修優先度をつけたいので、各機能の設定状況の変遷が知りたい • 各アプリでどの機能がどのくらい設定されてきたのか ▪ しかし、データが存在するのは「現在」の設定状況のみ… ▪ そこで、現存する機能の初回設定⽇で代⽤ • 改修優先度をつける⽤途であれば、⼗分代⽤可能 1. 要望に応え続けした
18. 要望が勝⼿に集まってくるようにするには？ • 「要望を⾔えば応えてもらえる」という信頼を得ること ◦ 要望にスピーディーに応える ◦ 直接叶えられなくても、代替案で可能な限り応える • カジュアルに要望が⾔える関係値を築くこと 1. 要望に応え続けした
19. カジュアルに要望が⾔える 関係値を築くには？ 1. 要望に応え続けした
20. 仲良くなる🤝 1. 要望に応え続けした
21. カジュアルに要望が⾔える関係値を築くには • 単純接触効果 ◦ オフィスで雑談する ◦ ⼀緒にご飯にいく ◦ 隣の席で仕事してみる（フリーアドレスの場合） ◦ Slackで#times-*チャンネルがあったら⼊って、リアクションしたり会話したりする • 仲良くなっていくと、相談ベースで要望がポロっと出てくることがある ◦ 例）「こういうデータって出せたりするの？」「こういうことってできたりするの？」 • ポロっと出た要望に応えると、次から相談‧要望を⾔ってもらいやすくなる • 「あの⼈に相談するといいよ」という認識が広がっていけば成功 1. 要望に応え続けした
22. カジュアルに要望が⾔える関係値を築くには 「あの⼈に相談するといいよ」という認識が広がって⼤成功した事例 • 24卒メンバーが⼊社後、ビジネス部⾨の⼈と積極的に交流 ◦ オフィスで雑談したり、ご飯に⾏ったり、隣の席で仕事したり（フリーアドレス） • その結果、オフィスで仕事をしていると席まで相談に来てくれるように ◦ 「今、ちょっと良いですか？」 • その後、RevOpsの波が到来＆社内でもビジネス部⾨の全体最適化が課題に ◦ → RevOps基盤の構築プロジェクトへ参画 1. 要望に応え続ける
23. この章のまとめ 必要とされ続けるために何をやってきたこと① • 要望に応え続けた ◦ データ利⽤者から要望が勝⼿に集まってくるようにする ▪ 「要望を⾔えば応えてもらえる」という信頼を得ること • 要望にスピーディーに応える • 直接叶えられなくても、代替案で可能な限り応える ▪ カジュアルに要望が⾔える関係値を築くこと • 仲良くなる ◦ 雑談、ご飯、隣で仕事、Slackでリアクション、etc. 1. 要望に応え続けした
24. エンジニアから 集計の責務を剥がした
25. プロダクト⽤データ基盤の誕⽣経緯 • CMSにレポート画⾯をつけるために構築された専⽤データ基盤 • エンジニアの持ち物として管理 ◦ 集計クエリのメンテナンスもエンジニアで担当 • まだデータ組織は存在してなかった ◦ ようやく1⼈⽬のデータ⼈材が⼊社したくらい 2. エンジニアから集計の責務を剥がした
26. 3年ほど運⽤して、課題が噴出 • CMSレポート以外のアナリティクスサービスが登場 ◦ Yappli Analytics、Yappli Data Hub • 既存のデータ基盤を増築して対応 →ガタが⾊々来てた ◦ クエリ費⽤、バッチの実⾏時間、リソースのメモリ上限、etc. • 2⼈⽬〜のデータ⼈材が⼊社し、「データ組織」が誕⽣ 2. エンジニアから集計の責務を剥がした
27. エンジニアから集計の責務を剥がした • dbtを導⼊し、エンジニアがメンテナンスしていた集計処理を移譲 ◦ 従来、集計処理を⾏っていた箇所は集計済みテーブルをSELECT * FROM tableするだけに • 集計の責務が無くなったことで、エンジニアの負担が⼤幅軽減 ◦ 増改築された数百⾏のSQLを⾒なくて良い ◦ データ量が増えてメモリエラーを起こすバッチと向き合わなくて良い ◦ 「集計がおかしい」というインシデントに対応しなくて良い ◦ etc. • データ基盤の良さ（＝必要性）を感じてもらえた ◦ 以後のコミュニケーションが円滑に 2. エンジニアから集計の責務を剥がした
28. 詳細はこちらの資料をご覧ください🙇 2. エンジニアから集計の責務を剥がした https://speakerdeck.com/yamamotoyuta/ci-no10nian-wozhan-er ufen-xi-yong-detaji-pan-gou-zhu-nodi-bu-dbtniyoruji-pan-shua-xi n-tokuerifei-yong-90-percent-xue-jian-henoqu-rizu-mi https://speakerdeck.com/yamamotoyuta/growth-strategy-of-data -analytics-platforms-from-a-product-perspective https://speakerdeck.com/yamamotoyuta/cross-team-impact-95-p ercent-off-raw-data-query-costs
29. 必要とされ続けることで 起きること
30. 何が起きるのか？ 3. 必要とされ続けることで起きること
31. 外部要因によって 急に追い⾵が吹いてくる📈 3. 必要とされ続けることで起きること
32. それによって、⼀気に事が進む💪 3. 必要とされ続けることで起きること
33. 追い⾵が吹いて⼀気進んだこと • プロダクト⽤データ基盤だと… ◦ プロダクト⽤データ基盤で⼀定の必要性を⽰せた事で、採⽤枠がもらえた ◦ 同タイミングでdbtが台頭してきた（＝外部要因） → 新メンバーをdbt導⼊に専念させる事ができ、データマネジメント強化が⼀気に進んだ • ビジネス⽤データ基盤だと… ◦ 24卒メンバーが⼊社後、ビジネス部⾨の⼈と積極的に交流 →しっかり関係構築 ◦ 外部要因: RevOpsの波が到来＆ビジネス部⾨の全体最適化の機運の⾼まり → RevOps基盤の構築が⼀気に進んだ 3. 必要とされ続けることで起きること
34. 「必要とされるデータ基盤」であり続けるよう頑張って、 吹いてきた追い⾵に乗って ⼀気に事を進めよう！ 3. 必要とされ続けることで起きること
35. まとめ
36. ヤプリのデータ基盤が必要とされ続けている秘訣 • ① 要望に応え続けた ◦ データ利⽤者から要望が勝⼿に集まってくるようにする ▪ 「要望を⾔えば応えてもらえる」という信頼を得ること • 要望にスピーディーに応える、直接叶えられなくても代替案で可能な限り応える ▪ カジュアルに要望が⾔える関係値を築くこと • 仲良くなる（雑談、ご飯、隣で仕事、Slackでリアクション） • ② エンジニアから集計の責務を剥がした ◦ 開発者体験の向上や考慮事項の減少により、データ基盤の必要性を感じてもらえた まとめ 必要とされ続けることで、外部要因によって急に追い⾵が吹いてくる → ⼀気に事を進めよう！