【DeNA／PayPay／マネーフォワード】波乱万丈伝から学ぶ！成長企業におけるデータマネジメントの勘所～大規模データ分析基盤の変遷～ レポート

TECH PLAYさんのイベントです。
troccoでおなじみのprimeNumberが主催のイベントです。

今回もレポート書きます。

データマネジメント セミナーレポート

TECH PLAYさんのイベントで前回出たのは以下のイベント。

その他データマネジメント関連のセミナーに興味ある人はこちらから。

ペタバイト、30プロダクトを超えて成長を続けるデータ基盤の歴史

発表者

株式会社ディー・エヌ・エー　長谷川 了示

発表資料

（参加＆アンケート回答者のみ）

概要

DeNAの事業紹介

1999年にネットオークションの会社として始まって、現在はエンターテイメント領域と社会課題領域を行っている。

ビッターズ懐かしい…

DeNAデータ基盤の歴史

データ基盤が生まれる前

データ基盤が「データ基盤」と呼ばれる以前の世界でも、データをためたデータベースとデータ活用を行いプロダクトを改善することは行われていた。

専門組織は存在せず開発エンジニアが行っていた。

データ基盤の勃興

2010年ごろ、モバイルゲームの大ヒットに伴い、アナリストと分析基盤エンジニアが一体となった組織が作られた。
その時はオンプレミスのHadoopで運用されていた。

ゲーム事業の中にデータエンジニアとデータアナリストを抱えていた。

データ基盤の浸透

モバイルゲームでデータ基盤が活用されると、どんどん広がっていった。

・利用事業がゲーム以外に広がる。
・ゲーム運用専門の子会社が生まれた
・分析ニーズが高まった

データ基盤を共通基盤に拡張した。
全ての事業/プロダクトのデータを一つの基盤に同居させた。使い勝手のよいBIツールを内製で作った。

ゲーム事業から独立して、利用事業部全体を横串で見るデータ組織に分離した。
ただ、利用事業部＝必要なドメイン知識が増えてきてつらくなってきた。

データ基盤浸透に伴う課題

拡張するにしたがってシステムが肥大化し、運用のつらみが顕在化。
・システム安定稼働のための専門性高いスキルを多数アサインする必要が出てきた
・一つの重い処理が全利用者に影響
・自由度を与えすぎたことで、ユーザーが意図せず環境を壊してしまう
・増改築を繰り返したことによる技術的負債

データ基盤拡散期へ

オンプレミスのHadoopから、クラウドのBigQueryへ移行した。
運用がつらい所はクラウドベンダーに任せることが狙い。

ユーザーへの自由と、環境のガバナンスの両方が叶えられるような管理の仕方を実現した。

多領域のドメイン知識が必要という課題に対して、「チームトポロジー」の考え方を活用した組織に移行した。
事業と対面する人と、バックエンドを支える人に分ける事で組織が上手く回るようになった。

残った課題

横のつながり希薄化問題
横のつながりが希薄になりがちなので、輪読会や雑談会などを意識的に行わないとノウハウの共有、課題の共有ができる機会が減る

これ、どこのチームの担当だっけ問題
組織を再編したことによって、集中管理したほうがいいモノや、その他領域が出てきている。

プラットフォームを作り上げるためには、御用聞きになるのではなく、優れたプロダクトマネジメントが必要。
なんでもプラットフォーム化するとアジリティが下がってしまう。

コンウェイの法則というものがあり、データ基盤に合わせた組織になっているという事を実感している。

感想

最近はデータ活用がバブっているので、データ基盤を作ったら何か良いことあるんじゃないか、DXが実現できるのではないかという進め方があるが、ちゃんとニーズに応じてデータ基盤と組織を拡大しているのが良い進め方だと思った。

データ基盤を有象無象の何かを生み出す投資ではなく、ビジネスのためのインフラになっているのが良いですね～

データ基盤組織はデータ組織であることの課題よりも、プラットフォームを開発/運用するチーム共有の課題が起きているのではないかと感じました。

チームトポロジーを用いたデータ組織設計はdatatech-jp Casual Talks #5でMonotaROさんが話していたので、ある程度データ組織が成熟してきたらチームトポロジーを勉しようかなと思います。

データマネジメント組織の立ち上げ方

発表者

PayPay株式会社　三重野 嵩之

発表資料

（参加＆アンケート回答者のみ）

概要

データマネジメント部の歴史

PayPayの特徴
・プロダクトが１つ
・設立当初からBigQueryがあり、業務に使われていた
・データマートもデータマネジメントチームがある前から作られていた

PayPay設立初期はプロダクトチームがBigQueryを入れていて、開発部門が使っていた。

Userも業務を回したい強いニーズがあり、使える環境がBigQueryしかなかったため業務メンバーがSQLを覚えて、活用されていた。

2021年4月にデータマネジメントチームが設立された。データマネジメントチームが生まれて、データマートの管理をやり始めた。プロダクトチームが行っていたBigQueryの部分を請け負った。

データマネジメントチームを立ち上げる際に起きた課題と対応

課題：各部署でどんな分析しているかわからない
対応：利用チーム10チームくらいにヒアリングしていった
結果：各部署の分析や概要と、データマネジメントチームに求めていることが明確になった

課題：個人で作成していたデータマートが広まり、保守されない状態になる
対応：airflowで作成しなおして、依存をきれいにして層を分けた
結果：開発、運用がやりやすくなった

課題：データマネジメントチームに小さな依頼が増える
対応：業務部署同士をつなげ手お互いで解決できるように立て付けた。
結果：ある程度自前で解決できるようになった。また小さな依頼に対応数工数をあらかじめ確保した

課題：チームが本来やるべきタスクが進まない
対応：ロードマップを見直して、リソース配分を気を付けた
結果：やるべきタスクと、差し込みのタスクがこなせるようになっ

感想

PayPayのデータマネジメントチームについては以前のTECH PLAYのイベントでも見たことがあり、なじみがあった。

データ組織を立ち上げるときにステークホルダーとなりうる事業部にヒアリング行くのは自分も何回もやったことがあり超重要だと考えている。

ドメイン知識を得て、データ基盤に反映するためというのが大義名分だが、事業部にデータ組織の名前を売り込んでおくことで次につながる可能性があるので、必ず名前と組織を覚えてもらいましょう。

小さな依頼が増えて、自前で解決できるようにSlackチャンネル作るというのも、やったことがあり親近感を感じました。

自分がやったときはデータ組織＋事業部のデータに詳しい人を入れて、問い合わせいただいたらデータ組織から事業部のデータ詳しい人にフルみたいなことをやってました。

こういう事をやるためにも成果を出すこと、成果を周知すること、名前と組織を売り込むことはめっちゃ大事。

組織とともに成長するデータマネジメント
〜データマネジメントに立ちはだかる「壁」〜

発表者

株式会社マネーフォワード　太田 泰弘

発表資料

（参加＆アンケート回答者のみ）

概要

分析基盤の変遷

2018年：有志が分析
2019年：分析推進室が立ち上がる。
202年：セールス・マーケティング活動や広告運用内製化のためのBigQuery活用が始まる
2021年：データエンジニアリング専業のチームが立ち上がる
2022年：チームメンバーを増員し、データパイプラインの見直し。データカタログの内製化、ML基盤の改善
2023年：今に至る

立ち上げ黎明期の壁

有志が分析しやすい環境をそれぞれ作って、自分の事業領域のための分析を行っていた。そのためかなりサイロ化されていた。

経理の管理会計の属人化排除と自動化に向けて分析推進室が立ち上がった。

経営陣の見る数字がこのならないように、Lookerを導入して、Single Soure of Truthの実現
ETL等の管理主体を明確にして、中央集権的に管理できるようにした

データの民主化の壁

管理会計の管理から、各事業部のKPIの可視化で見える結果を残し、各事業部のKPI管理へと拡大していった

・各事業部での活用に従って、データ量が激増した
・データ自体の管理や権限の管理が煩雑化した
・手が回らなくなってきた

自走化を目指してEmbulk定義をデータが欲しい人が書くなど、基本的な業務分散を図った。

データ組織分離の壁

アナリストが増えた。ML/AI領域に向けた基盤の高度化

全プロダクト横断で分析できる、MySQLマルチレプリのストレージ逼迫に見舞われて、データ基盤チームのリソースを食いつぶすため分析用DBのリプレースが喫緊の課題になった。

リプレースに集中せざるを得ない状況だったため、ユーザーの声が届きづらい状況になった。

基盤改善の壁

MySQLマルチレプリの分析DBをBigQueryに置き換えた。
人が課題であることに気が付き、採用に力を入れた。

旧システムの撤退をするために、並行転送をして、ユーザーへ新データセットを参照するように促す日々が続いた。

Dmemoというものを運用していたが、ガバナンスがとれてなかった。
データカタログの需要が高まり、yamlベースでメタデータを管理してBigQueryのメタデータとして更新する仕組みを作った。
メタデータを参照するための社内サイトを構築した。これによって分析はしないもののデータの所在地を知りたい人のニーズに答えられた。

まとめ

まずはクイックウインを積み重ねて分析文化の浸透を図る。
分析が積み上がりデータエンジニアの要望が増えることを見据えて、先手を打って採用を行うことが重要。

データエンジニアリングを行っていくと、データマネジメントの重要性に気が付く。データマネジメントを支えてくれるマネージドなサービスを選定することは重要になる。

大規模刷新に注力すると他の事ができなくなるので、そうなってしまわないように先手を打つ。

感想

3社とも、ビジネス活用のための分析が先に走ってデータエンジニアリング敷いてはデータマネジメントが必要になってくるという流れが一緒でいい流れを作っているなぁと感心しました。

教訓になったのは、爆発するまで負債を抱えてしまうと解消するためにそれなりの代償を伴うということで、先手先手で取り組んでいかなければならない。

データカタログはメガベンチャーでしかうまくいく気がしないとこの前つぶやいた通りで、マネーフォワードはメガベンチャーなのでうまくいきそう。

管理会計から広げていくというのはあまり聞いたことはなかったが、一番スポンサーとなりうる人かつ、広報しやすい人のテーマを行うのは、データ組織立ち上げのとっかかりとしては最善なのではと思う。

質疑

Q.データ品質で行っている取り組みは？
A.毎朝集計のバッチが動いた後に品質チェックのバッチが走る。Lookerの通知機能が走ってSlackに通知するという事をやっている（DeNA）
A.重要レポートはデータの正しさのチェックを行っている。ユーザー側がjsonを書いてデータチームが取り込むという事をやりたいと考えている（PayPay）
A.クラウドDLPを用いてセンシティブのデータを見ている。データマートを生成するときにdbtを使ってテストを走らせている（マネーフォワード）

Q.サイロ化する懸念は？
A.サイロ化については課題感はない。大規模なサプライチェーンを持っている会社だと置きそう。しいて言うならば部門横断でデータを見る事はあるが、GCPだと違うデータセット間を結合できるので問題なくできている（DeNA）
A.個人向け家計簿、法人向け会計など様々なサービスはあるがサイロ化していても問題ない。横串で見る必要があるサービスについてはデータレイクがあるのでデータレイクを利用している。（マネーフォワード）

Q.モダンデータスタックで注目している技術は？
A.fivetran,dbtとか。fivetranは使っている。dbtは使いたいがairflowとどう使い分けるか検討中（PayPay）
A.dbt/dataformは活用したい。Digdagを使っている。非エンジニアでも使えるツールを入れていきたいという思いはある（DeNA）
A.モダンデータスタックと言われる技術は見ているが、データクオリティのモニタリングツールであるパイプライダーのライブラリを組み込めないか検討している（マネーフォワード）

Q.データマネジメントを進めるための組織設計やメンバーでのインセンティブ設計をどうするか？
A.データマネジメントを進めることで自部署の利益が見えているので自然とインセンティブを感じてくれている。ただ、メタデータ管理はあるといいなと思うが、難しい所はある。（DeNA）
A.今日のイベントを通して会社の事業体によってチーム編成が変わることを実感した。データマネジメントはデータエンジニアとデータアナリストが協業するところがあり、そこが難しい。キャリアをよく考えないといけない事が悩みどころ（PayPay）
A.インセンティブ設計は明確な回答が無いが、分析組織の立ち上げタイミングからデータマネジメントに取り組んでいる。横断的な分析チームがいないとサイロ化して管理主体がわからなくなるので中央に立つデータ組織が必要だと思っている（マネーフォワード）

Q.セキュリティ面の取り組みはどうしている？
A.権限については社内システムの仕組みに乗っかって楽をしている。業務ツールとしてGoogle Workspaceを利用しているのでGoogleに乗って管理できている。（DeNA）
A.PayPayでもGoogle Workspaceを使っていてGoogleのIDを持っているのは同じところ。BigQueryのデータセット単位でデータオーナーが管轄し権限を振ることをしている。（PayPay）
A.課題を感じている。セキュリティを担保しながらユーザーの利便性を両立するのが難しい。セキュリティレベルの高いデータについてはVDIの環境において持ち出しできないようにしている。一段階低いデータはDeNAとPayPayと同様にGoogle Workspaceを使っている。（マネーフォワード）

Q.DeNAさんはプロダクトごとに基盤を分けているとおっしゃっていたが、それによる課題は？
A.プロダクト横断でデータ分析をあまりやっていない。一緒に使うべきデータは一か所にあるべきだと思っている。一緒に分析する単位で環境も一緒にするのが良いと考えている。分けたことによる課題は環境が増えると運用が大変になるというのはあり、スケールする仕組みが重要だと考えている（DeNA）

おわりに

自分の知識をまとめるためと今後誰かがデータマネジメントをやってみたいと思った時のきっかけとなるためにnoteを書くことにしました。
モチベーションのために役にたったという人はぜひ、フォロー＆スキをお願いします。

ツイッター（@yoshimura_datam）でもデータマネジメントに係る情報をつぶやいてますので、よろしくお願いします。

データマネジメントを学ぶ人が抑えておきたい本

今すぐわかるデータマネジメントの進め方
著者のDMBOKを用いてCDO室を立ち上げデータマネジメントを推進した経験を基にデータマネジメントの進め方をまとめたkindle本を執筆しました。

データ組織立ち上げ編 ＡＩ事務員宮西さん
著者のデータ組織の立ち上げ経験をマンガ＋コメントでまとめてみました。立ち上げ編は組織を立ち上げてやることが決まるまでのストーリーです。
無料公開のため0円となります。
データ組織の立ち上げに関係する方は是非読んでみてください。

DXを成功に導くデータマネジメント
DXを成し遂げるために必要なデータをどうマネジメントしていけばよいかが書かれている。
データ環境より、セキュリティの観点であったり、プライバシーの観点であったりといった非技術者向けの内容が多く書かれている。
データマネージメントに興味を持った人はまずは読んでみるとデータマネジメントでなすべき概要が理解できる。

実践的データ基盤への処方箋
データ利活用を行うために必要なデータ基盤の考え方と、利活用するためにはデータをどのようにマネジメントしていけば良いかを具体的な例を用いて説明されている。
技術が中心になるので現在データ技術に係る人がデータマネージメントに興味を持った時には、まず手に取ることをおすすめする。

個人データ戦略活用 ステップでわかる改正個人情報保護法実務ガイドブック
個人情報保護法を順守するための基本的な考え方が実務ベースで書かれている。2022年4月に施工される改正個人情報保護法で新たに追加される概念も同様に記載されている。
政府の出しているガイドラインよりも俯瞰的に読めるためデータプライバシーにかかわる人、データを使ったビジネスを推進する人は読んでおくとスムーズに業務が進められる。

データマネジメント知識体系ガイド（DMBOK）
自分も要約・解説記事を書いているDMBOK。データマネジメントに興味を持った人がまず手に取ると挫折することは間違いないほどのボリュームがある。
読めば読むほど味が出てくるので、データマネジメントを進めようとしている人は各家庭に1冊は是非買っておきたい。

データマネジメントが30分でわかる本
著者もDMBOKを読むためには非常にボリュームが多く読み解くには苦労するので、かみ砕いた解説書をまとめたと書いてある通り、DMBOKを独自解釈してわかりやすく書かれている。
DMBOKを技術者目線で読み解いた内容になっているので、実践的データ基盤への処方箋と同様データ技術に係る人におすすめする。