ビジネス職が分析も担う事業部制組織でのデータ活用の仕組みづくり / Enabling Data Analytics in Business-Led Divisional Organizations

Data & Analytics 井戸端会議 #03 「データアナリストから見たデータ基盤」
https://data-analytics-idobata.connpass.com/event/356245/

1. ビジネス職が分析も担う事業部制組織での データ活用の仕組みづくり 財津大夏 (@zaimy) GMOペパボ株式会社 技術部データ基盤チーム 2025.07.11 Data & Analytics 井戸端会議 #03
2. 自己紹介 財津 大夏　ZAITSU Hiroka 技術部データ基盤チーム シニアエンジニア 2012年よりホスティングやECサービスのディレ クターとして、データ駆動のマーケティングや サービス運用改善に取り組む。2018年よりデー タサイエンティスト、2022年よりデータエンジ ニアとして、データ基盤の開発やその利用によ るサービス改善に取り組んでいる。
3. アジェンダ 本日お話しすること 1. ペパボとデータ基盤 2. これまでの経緯と困りごと 3. 改善の試み 4. 変わったこと 5. まとめ 3
4. ペパボとデータ基盤
5. GMOペパボ株式会社 "もっとおもしろくできる" という企業理念のもと、 "人類のアウトプットを増やす" ために様々なサービスを提供しています 5
6. GMOペパボ株式会社 6
7. ペパボで目指すもの DX Criteriaとデータ駆動 DX Criteria (v202506) - 企業のデジタル化とソフトウェア活用のためのガイドライン 5つのテーマのうちの1つが「データ駆動」 マーケティング自動化 データを元にサービスの振る舞いを変える、サービスの動的改善 意思決定の自動化 意思決定に必要な指標を計測可能・明確にして自動化を可能にする 例）統計的な判断 意思決定後のシステム挙動の変更も自動化する 例）バンディットアルゴリズム 7
8. ペパボで目指すもの いきなりデータ駆動にはなれない 実現を阻む一般的な課題 データを集める仕組みがない 集めたデータを分析する仕組みやスキルがない 分析したデータを活用する仕組みがない　etc... 8
9. データ基盤で目指すもの データ駆動になるための段階を整理する 収集: データが出力され、取りまとめられている段階 分析: 取りまとめたデータを可視化、一元的に分析できる段階 活用: データにより継続的なサービス改善を行える段階 9
10. データ基盤で目指すもの データ駆動になるためのレイヤーを整理する システム: データ活用の基盤とエコシステム リテラシ: データの解釈と活用のためのリテラシ 10
11. データ基盤で目指すもの 各段階においてシステムとリテラシによるデータ駆動を目指す データ基盤は主にシステムレイヤの各要素を扱いやすくすることで サービスの動的な改善と意思決定の自動化をサポートする 11
12. ペパボのデータ基盤「Bigfoot」 12
13. これまでの経緯と困りごと
14. これまでの経緯と困りごと ペパボ（事業部制組織）の特徴 事業部メンバーはドメイン知識が深い 一方で業務範囲が広い 事業部にデータ活用の推進者が不在 マネージャーやディレクターが 業務の一環としてデータ分析 データ活用の程度はさまざま エンジニアの横断組織はあるが、サービス 運営に関わるビジネス職の横断組織はない 14
15. これまでの経緯と困りごと データ基盤立ち上げ当初の状況 - 2016年 全社基盤として設計 当時大規模投資を行っていたminne事業部で開発 主な開発者: minneのシニアエンジニア1名 主な利用者: minneのディレクター1名（@zaimy） 開発者と利用者が同じ小さな組織の中にいてスキルセットも備わった状態 データを活用した施策の実行サイクルが回っていた 種々の情報の可視化や行動ログに基づくユーザーセグメントの利用など 15
16. これまでの経緯と困りごと 2019年頃から生じた問題 当初の開発者と利用者が別組織（研究所やデータ基盤チーム）に異動 同メンバーが別組織から主に作り込む形になった 機械学習による推薦, バンディットアルゴリズム, 行動ログの複雑な集計など サービスのアプリケーションの実装のみ事業部パートナーのエンジニアが担当 結果、以下の問題が発生 事業部（特にデータ分析者）にデータ基盤を使った何かのオーナーシップがない メンテナンスされずに施策ごと自然消滅 データ基盤は「よくわからない、難しいもの」という認知 16
17. これまでの経緯と困りごと 双方のジレンマ 事業部のパートナー: 「なんかすごそうだけどよくわからない」 データ基盤チームのパートナー: 「作ったものが継続的に運用されない」 根本的な課題 ドキュメント不足 不均一なリテラシ データ駆動を目指すという前提が浸透していない 17
18. 改善の試み
19. 改善の試み 実施した4つの取り組み 1. Team Topologiesの導入 チームタイプとインタラクションモードの見直し 2. ELTモデルに基づく責任範囲の明確化 データパイプラインの各段階での責任分担 3. Transform層のフレームワーク化 dbtへの移行とAirflow DAGのテンプレート化 4. ディレクターの基盤チーム加入によるサポート強化 利用者視点での支援とドキュメント・メタデータの整備 19
20. 改善の試み Team Topologiesの導入 - チームタイプ 組織のチーム構造を適切に設計する方法論 4つのチームタイプ 1. ストリームアラインドチーム: 価値の流れに沿って作業 2. プラットフォームチーム: セルフサービス機能を提供 3. イネイブリングチーム: 他チームの能力獲得を支援 4. コンプリケイテッドサブシステムチーム: 専門知識が必要なサブシステムを担当 20
21. 改善の試み Team Topologiesの導入 - チームタイプ 従来のチームタイプ認識 事業部からはコンプリケイテッドサブシステムチームに見えていた 「専門的なことはお任せしたいです」 しかしデータ基盤チームがサブシステム全てを担当するとスケールしない 改善後の認識 イネイブリングチームとして明確化 やること、やらないことを明確にした ELTの各ステップを境界に責任範囲を決定 21
22. 改善の試み Team Topologiesの導入 - インタラクションモードの見直し 3つのインタラクションモード 1. コラボレーション: 2つのチームが密に協力 2. X-as-a-Service: 一方が他方にサービス提供 3. ファシリテーション: 一方が他方の学習を支援 改善内容 従来はX-as-a-Serviceが主体 コラボレーション、ファシリテーションを増やした 22
23. 改善の試み ELTモデルに基づく責任範囲の明確化 改善前: ELTの責任範囲が曖昧 失敗時などは「事業部とデータ基盤チームで面倒を見る」という建て付け 実際はデータ基盤チームが対応することがほとんど 改善後: 責任範囲を明確化 Extract & Load: データ基盤チーム Transform & サービスアプリケーションへのReverse EL: 事業部 SaaSなどへのReverse EL: データ基盤チーム 共通化しやすい部分はデータ基盤チーム、ドメイン知識が必要な部分は事業部 23
24. 改善の試み Transform層のフレームワーク化 改善前: DWH上のTransformはすべてAirflow DAG Pythonコードを書けば何でもできる BigQueryなどGoogle Cloudサービスの実行、Pythonコードの実行など 柔軟性は高いが習得が困難 改善後: 用途に応じて最適化 DWH上のデータ変換のみ → dbt on Airflowに移行 DAGが必要だが再利用可能なパターン → DAGをテンプレート化 事業部別、やりたいこと別に10行程度のコード追加で生成可能にした 24
25. 改善の試み ディレクターの基盤チーム加入 従来: エンジニア向け基盤（X-as-a-Service的発想） コードサンプル, ドキュメントを読めばわかる 改善後: ビジネス職かつデータ分析経験者によるコラボレーションの追加 ビジネス職の中でデータ基盤を社内トップクラスに活用していた3名が加入 データ分析者の困りごとに近い立場でコミュニケーションできる データ分析者としてのスキルを各サービスに展開 25
26. 改善の試み ディレクター主導によるドキュメントとメタデータの整備 利用者向けドキュメントの整備 まちまちだったDAG、dbt modelのドキュメントを必須化 思想やオンボーディングのドキュメントで目指す方向性を共有 重要度の導入 全てのDAG、dbt modelのメタデータとして重要度を定義 重要度によって対応期限や対応方法を変える 例: ユーザー体験に影響する重要度ならばSlackにインシデントチャンネル作成 26
27. 変わったこと
28. 変わったこと 当たり前レベルが向上しはじめた 改善前: スプレッドシートにデータがある 集計ロジックも各所にある 集計されたデータを見て「こういう傾向がある」で終わりがち 改善後: SSoTなデータをもとに仮説と施策と検証のサイクルを回す まず仮説ありきで検証可能な施策を実行する データ作成の作業ではなくデータ活用にフォーカスする 28
29. 変わったこと チームの変化 データ基盤チームの変化 データ基盤からデータ基盤サービスへ XaaSを目指しつつ、営業・コンサル・コーチング的コラボレーション 事業部の変化 事業部パートナーによるTransformの新規作成とその活用 他事業部で既に行っているSaaS活用を実装コストなしで水平展開 データで困ったとき、やりたいことがあるときのデータ基盤チームへの声かけ増 29
30. まとめ
31. まとめ データ基盤からデータ基盤サービスへ Team Topologiesの活用 チームタイプの明確化 インタラクションモードの最適化 責任範囲の明確化 技術的な仕組みの整備 ELTモデルの責任分担 フレームワーク化による利用しやすさ 適切なドキュメント整備 31
32. まとめ 『人』と『仕組み』の両輪が大事 人的要素 利用者のプロフェッショナルとしてのディレクター 事業部との継続的なコラボレーション 結果としての当たり前レベルの底上げ 仕組み的要素 使いやすいツールの導入・フレームワーク化 明確な責任分担 適切なドキュメント 32
33. まとめ 各段階においてシステムとリテラシによるデータ駆動を目指す これまでデータ基盤はシステムレイヤと活用段階のリテラシレイヤに注力していた データ基盤サービスとして利用が進みデータ駆動になるためにはもう一つのセルも重要 33
34. データ活用で "もっとおもしろくできる" Ask the speakerでみなさんのお話も聞かせてください！