DeNAのデータエンジニアが語る、事業プロダクトを横断するデータドリブンな組織設計、社内データの利活用、データマネジメントとは

アーカイブ動画

DeNAがデータエンジニアの組織変革に取り組む背景

最初の登壇者、城谷氏は2019年9月にDeNAに中途入社。ゲーム事業・ライブストリーミング事業におけるデータ基盤構築および組織マネジメントに従事。現在は、データエンジニア全体の組織・採用戦略の立案・実現を総括している。

DeNAはゲーム事業やスポーツ事業のほか、ライブストリーミング事業、ヘルスケア・メディカル事業など、エンターテインメント領域と社会課題領域の両面を狙った事業を展開している。これら多岐に渡る事業の意思決定場面で、活用されているのがデータである。

DeNAのデータエンジニアの活動概要は、次の図のようになる。データの発生源から様々なデータを収集し、利用可能な状態を作る。さらにガバナンスを利かせ、データ活用の生産性を向上させる土台を構築する。

データ基盤に対しては、アナリストをはじめ、マーケティング、カスタマーサポート、会計、HR部門などがアクセスしている。

「DeNAが手がけるサービス全てにおいてデータ活用は必須であり、事業活動におけるインフラとなっている。つまり、サービスローンチ時には提供必須となっています」（城谷氏）

だが、社内外で環境の変化が発生した。一つはクラウドジャーニーによるオンプレミスの撤廃である。あらゆる基盤をクラウドに移行することになり、データ活用基盤も移行した。そのため、データ活用（分析/AI）プロジェクトが200以上の環境に分散されたという。

もう一つの変化は、ゲーム事業以外の急成長や新規事業が勃興したこと。Pocochaをはじめとするライブストリーミング事業は、まさに急成長した事業の一つだ。また、アライアンスビジネスを含む新規事業の立ち上げも複数発生した。

データ分析からデータ活用へ民主化が進んだことも大きな変化の一つである。従来はKPIの分析やモニタリングが中心だったが、「今では様々なロールのメンバーが様々な要件でデータを活用している」と、城谷氏は言う。

そして、メンバーの入れ替わりである。10年に構築されたデータ基盤は、細かい文脈や背景は引き継ぐたびに薄くなっていった。このような環境の変化に対して、徐々に組織の中でひずみが生まれ始めた。例えば、急激なサービス増加に対してリソース効率重視でアサインすることによって、対応する業務範囲が拡大していく。

「複数プロジェクトやサービスに同時アサインされることはもちろん、提供するインタフェースやステークホルダーが多種多様になり、データエンジニアの役割が不明瞭になっていきました」（城谷氏）

その結果、要望を解決することが優先されてしまい、メンバーのモチベーションが低下したり、属人化が進んだ事で、結果的に事業への価値貢献の活動が縮小するなどの弊害が生まれた。

そこで組織構造やマインドをアップデートし、持続可能な開発組織へ再組成することとなる。アップデートの内容は大きく2つ。

一緒に貢献する仲間を作る活動と、仲間が貢献と成長ができる環境作りだ。 一緒に貢献する仲間を作る活動をする理由は、全体的にエンジニアリソースが足りないことが大きい。だが採用をしようと思っても、データエンジニアという職種への理解があまり得られていないため、苦労することとなる。

「そこで我々は今従事している仕事を構造化して3つのポジションに分解し、それぞれのジョブディスクリプションを作りました」（城谷氏）

それをまとめたのが以下の表だ。アナリティクスエンジニアは近年注目されているロール、そしてデータアナリティクスエンジニアを支えるのが、データソフトウェアエンジニアとデータアーキテクトである。

ポジションを明確にしたことで、求職者への訴求力や業務理解が向上した。また、採用担当や関係する人材エージェントの理解も深めることが出来た。さらに、採用戦略を立案。基本戦略をもとに、各施策を体系立てて着実に実行していったのだ。

次に仲間が貢献と成長できる環境作りにおいては、図のようなキャリアデザインを策定。各ポジションをベースに深化・発展を支援するようなデザインにした。

ポジションごとに目安となるキャリアラダーを設け、スキルレベルを言語化。定期的なメンタリングの中で、キャリアの方向性や上位レベルとのギャップができ、議論しながら成長を促すような仕組みができた。

開発体制についても再構築を実施。開発体制の戦略は、フローの効率を高める事でリードタイムの短さを重視する戦略と、リソース効率を高める事で開発リソースの最大活用を重視する戦略がある。

「直近の傾向として、小さなスコープで探索しながら成長させるプロジェクトが増えてきており、高いフロー効率が求められるようになりました。その事から、リソース効率を優先したアサインは限界だと感じました。」（城谷氏）

そこで、この10月からチームトポロジーを活用した開発体制の組成に取り組み始めた。チームトポロジーとは、顧客への価値提供のフローを最大化するための組織設計論である。

「今は立ち上げのフェーズですが、ガイドラインを設けながら運用を進めています。最終的には組織の危機で感じた思いをカルチャーに落とし込んでいきたい。仲間の活躍を外部発信し、ブランディングを図る。その結果、新たな仲間を呼び込み、DeNAのデータ活用を発展させるサイクルを作りたいと思います」（城谷氏）

社内データ利活用の推進、技術的負債の解決に向けた取り組み

株式会社ディー・エヌ・エー
データ本部データ基盤部　データエンジニアリング第二グループ
グループリーダー　深瀬充範氏

続いて登壇した深瀬氏は、「DeNAではデータの民主化・データ活用水準が向上しており、人事や経営、カスタマーサポートの領域などで、幅広くデータ活用が進んでいる」と語る。

DeNAの社内データ利活用は、以下のように発展してきた。2010年代は部門ごとにデータ整備・活用してきた。そして2020年頃、データエンジニアリンググループによるデータの民主化・データ活用水準向上の取り組みが加速し始めた。

データの民主化に向けた活動の軸は大きく2つある。まずはSNSやマーケティング系データの利活用推進である。これはTwitterデータ収集基盤を構築し、案件・業務でのデータ利活用をサポートするというものだ。

【参考】
・CEDEC2020 発表資料：ネットワーク科学で挑戦するゲームマーケティング改革

・CEDEC2022：【レポート】広告識別子に依存しないエンタメ広告運用～SNSの”キーワード”に着目した最適化〜

もう一つが、バックオフィス系（社内）データ利活用推進である。これはエンジニアがいない組織でも、データの利活用ができるよう要件を満たす活動である。

「社内部門が抱える課題をヒアリングし、データエンジニアによるコンサルティングやツール開発によるPoCを実施。KPIを駆使したデータドリブンな業務運営へのシフトを促進しました」（深瀬氏）

これが光の効果だとすると、闇もできる。例えば、新規データ利活用に向けたタスクを、特定メンバーや暫定チームで担当するようになる。エンジニア不在のため、メンバーや自部署の工数負荷・運用割合が増加。さらにデータ利活用のニーズが加速し、チームの工数不足・属人化した開発が多発するなど、「工数爆発という状況に陥った」と深瀬氏は明かす。

そこでチームを作ることになった。現在の取り組みでは、ほぼ類似したスキルセットと機能開発が要求されるため、一つのチームへ集約し、運用を含めて包括的にリソース管理をすべきだと考えた。

もう一つは技術的負債の問題だ。これは持続可能なチーム開発を実現し、負債の解消・抑制を進めていくことにしたという。技術的負債は非効率な開発プロセスや、複雑な設計、継ぎ接ぎされたアーキテクチャ、不適切なコード・不十分なテスト、エンジニアのスキル不足、属人化、ドキュメンテーション不足などから生まれる。

「負債を発生させないことは難しいのですが、借り入れを抑えることはできると考え、チームプロセスを整備し、明文化して定着させるところから始めました」（深瀬氏）

チームビルディングにおいては、タックマンモデルに従って進めていった。チームを組成して3カ月から半年ぐらいまでで、共通規範を形成する統一期を目指す。さらにチームのパフォーマンスを高めることに取り組んでいった。

そこで着目したのはスクラムの導入。だがいきなりスクラムを導入するのは難度が高い。そこでテンプレートに当てはめつつ、ややカンバンよりにカスタマイズして実施した。具体的なやり方は次の通りである。

1スプリントは1週間。デイリースクラムは毎週月曜のみZoomで実施。それ以外は特定の時間にSlackスレッド上での報告を実施した。レトロペクティブはアジェンダを定め、50分間という時間厳守を意識して実施した。またチケットのルール整備も実施したという。

「特にステータスの基準については言語化して明確にする。スプリントポイント基準など、曖昧さに対するチーム基準を設置しました」（深瀬氏）

技術的負債解消のための取り組み

タスク管理はClickUpを活用した。スプリントごとのタスク状況をモニタリングするためにBIツール(Looker)へ連携する機能を整え、さまざまな指標をダッシュボード上でまとめて確認できるようにした。次にチーム文化の定着に並行して、共通開発ルールの整備とデータ活用推進を実施し、開発スタイルの統一を行った。

具体的にはPythonを主流としたコード規約・開発時の推奨ルールを整備している。実際に活用している推奨ライブラリのうちの1つとして紹介されていたのがpydanticである。

「pydantic導入前は各開発者の裁量でデータモデルを定義しており、技術負債の一因となっていました。pydanticを導入することで、Typingというバリデーションという機能が使えるので、統一的な実装ができるようになります。またJSONからコード生成により、開発品質の向上が期待できます」（深瀬氏）

データ基盤をユーザーへ提供するためのアーキテクチャパターンも説明しており、権限やクエリコストを分散する要件であればAuthorized Viewを活用したアーキテクチャを採択する。具体的には、案件ごとにGCPプロジェクトを作成し、必要なユーザーが必要なデータだけを参照できるようにしている。またBIツールからのデータへのアクセスにおいては行レベルセキュリティの活用も効果的であり、担当部署や役職などに応じて閲覧できるレコードを制限できる。

こうした文化作り・ガバナンス整備の取り組みによって、技術的負債を完済することはまだまだ厳しいが、従来に比べてドキュメント・ナレッジの共有が大きく進んでいることで返済は進み始めている状況。加えて、チーム学習の成果として新技術のキャッチアップを通じて実プロダクトへの導入が進んだり、新規相談に対するデリバリー速度が増加してデータ利活用が活発化してきたと深瀬氏は語る。

これからは社内での更なるデータ利活用を支える組織として、今年4月から１つのチームから組織となり、今後はドメインの多さによる負荷＝認知負荷を低下させる活動へもシフトしていく。

「今後は持続可能なエンジニアリング体制を提供するための探索が必要になるでしょう。他チームへのチーム組成、チーム運営の伝播にも注力していきたいと思います」（深瀬氏）

『Pococha』におけるデータマネジメント実例を紹介

株式会社ディー・エヌ・エー
データ本部データ基盤部
データエンジニアリング第一グループ　長谷川了示氏

最後に登壇した長谷川氏は、2016年、DeNAに入社後、一貫して全社のデータ分析基盤の設計・構築・運用に従事。最近はPocochaを含むライブストリーミング事業のデータ基盤を担当している。

DeNAでは事業の状況に応じてデータエンジニアの役割が変わる。新しい事業におけるデータエンジニアの役割は分析基盤の提供のみ。レポートの作成などは事業部側で実施する。

一方、ゲームやライブストリーミングのような主要事業は、データが大規模化・複雑化しているため、使いやすい形に整える作業が重要になる。そこで、データエンジニアは分析基盤に加え、データ・レポート整備もアナリストと協働して推進する体制を取っている。

Pococha事業は新興事業だったため、データエンジニアはデータ基盤を提供するだけの関わりだった。しかし急成長するに伴い、アナリストの業務負荷が増大していった。

この背景には、分析やレポーティングのニーズと重要度が急増したことと、分析対象のデータの量と種類が急増し、データ整備の負荷が増大したという要因があった。

「データの欠損や不整合の問題が目立つようになり、ライブストリーミング事業担当のデータエンジニアがアサインされ、主要事業モデルに移行しました」（長谷川氏）

現在、3つの取り組みを推進しているが、今回はデータマネジメントの推進が紹介された。 データマネジメントの推進を行った背景にあったのは、先述したようにデータ品質に関する問題が顕在したこと。具体的には、プロダクト側のデータモデル変更に起因する問題や、データウェアハウス、データマートの品質担保が十分でなかったという問題等が生じていた。そこで、データ・レポートの設計標準策定、データ品質チェック、利用状況のモニタリングをという3つの取り組みを行った。

データ・レポートの設計標準策定では、データ基盤（BigQuery）のデータを分類。またBIツール上のレポートは保守対象とそうでないものに区分した。その上で依存関係のルール化を行った。

データ品質チェックでは、ウェアハウス、マートについて、「期待される制約条件を満たしているか」「テーブル間で整合しているか」という観点でチェック。日次でシステム監視をする仕組みを構築した。それが以下のシステムである。

また、利用状況のモニタリングを実施し、設計標準に準拠しているか、どのくらい頻繁に利用されているかをチェック。使われていないテーブルやレポートは廃止してコスト削減を図り、頻繁に使われている生データがあれば、ウェアハウスやマート化を検討している。

具体的な仕組みとしては次の図のように、BigQuery、BIツールのメタデータを収集・活用し、可視化している。詳細はオウンドメディアでも紹介している。

今後はより高度なデータマネジメントを実現するため、データ品質チェックの仕組みの改善を計画。現状のメトリクスを収集する部分は内製だが、dbtなどのツールの利用を検討している。

また現状はテーブル・カラムごとにすべてのチェック項目を設定する必要があるが、NULLチェックなど、すべてのテーブルやカラムで実行したい項目は、設定せずに自動でチェックできるようにし、メトリクス収集とアラートを一元管理できるようにする予定だ。

「複雑度の指標として想定しているのが集計クエリの行数、参照テーブル数など。頻繁に類似した複雑なクエリを発行している場合、ウェアハウスやマートのリファクタリングや新規追加で、より使いやすく改善できると考えています」（長谷川氏）

【Q&A】多数寄せられた質問に答えるセッションを紹介

Ｑ．自社以外のデータ組織で興味深い会社はあるか

城谷：日本のスタートアップ企業で、BtoB向けECサイトを運営しているMonotaRO（モノタロウ）やECプラットフォームを運営している10xはデータ活用に力を入れており、我々も参考にしています。

長谷川：Airbnbは、データメッシュ(チームトポロジー的な考え方をデータ基盤の活用に適用した手法)をかなり忠実に実践しているとブログで紹介しており、刺激を受けています。

Ｑ．他プロダクトの事例や、複数プロダクト横断のデータマネジメント事例について

城谷：DeNAは分析環境が多く、コスト系の管理の優先度が高い点が特徴です。全社にGCPドクターという役割を整備しており、様々なメトリクスを集めて分析してコスト改善を促す活動があります。

深瀬：カスタマーサポートは複数のサービス・複数のドメインに関わるため、担当者別に提供するデータは異なります。Lookerの機能を使い、集権的なモデルを1つ作り、そこからドメインを横断して情報を提供する仕組みを提供しています。

長谷川：ゲームの事業も近い仕組みがあります。どのタイトルでも閲覧する共通KPIはデータモデルも共通化しています。レポートはLookerで共通化したものをタイトルごとに継承して使っています。

Ｑ．データパイプラインの中間テーブルとデータ加工クエリのバランスは、どのようにマネジメントしているか

長谷川：主要事業モデルは、事業のドメインを熟知するアナリストがアサインされるので、アナリストが分析しやすいように技術的なアドバイスをしながら設計しています。一方で、アナリストの属人的な知見に依存している面もあるので、形式知化にも取り組んでいます。

Ｑ．BIツール等を利用したレポーティングは各事業部で行っているのか

城谷：レポーティングは事業部で行っていますね。

深瀬：社内データ活用については、当初はデータエンジニアで作っていましたが、ナレッジシェアを進め、利用部門でレポート作成できるようになってきています。

Ｑ．テスト環境はどのように整備されているのか

深瀬：ゲーム系はサンドボックス環境を構築してテストしていますよね。

長谷川：サンドボックス環境でのテストは実行していますが、本番のデータを使わないとテストしづらいし、そもそも入力データに異常が発生するリスクもあるので、やはり本番環境での品質チェックが重要だと考えています。

深瀬：会計では異常な伝票データのパターンを作ってテストするといったことはやっています。

城谷：グローバルにリリースしているゲームだと開発ラインが何個もあり、QA環境毎に分析環境を作って欲しいと依頼され、非常にコストがかかって悩ましいです。IaC や BigQuery のテーブルクローン等を駆使して開発環境を作っていくのが重要かなと思います。

Ｑ．事業部から来る数多くの相談や依頼をどのように優先度をつけているか

城谷：事業の大きさ、会社としての注力状況などから総合的に判断して、優先度を決めています。今後はチームトポロジーという概念をもとに、ビジネス優先度、事業の影響度を見ながら優先度をつけていく予定です。

Ｑ．データ基盤に入る前に、データソース側のデータモデルが乱雑になっている場合、どのような改善アプローチをとっているか

城谷：データソース側に手を入れるというアプローチも取ることもありますが、そのまま分析基盤に取り込んだ先で、うまく抽象化していくアプローチを取ることが多いです。

長谷川：DBのテーブルは、サービス側の都合でトランザクションをうまくさばけるようにデータモデルを作っているので、分析用に変えていくことは難しい。ウェアハウスやマートを整備することが常套手段だと思います。

株式会社ディー・エヌ・エー
https://dena.com/jp/

株式会社ディー・エヌ・エーの採用情報
https://dena.com/jp/recruit/

株式会社ディー・エヌ・エーのデータ・AI領域の募集職種一覧
https://herp.careers/v1/denacareer/requisition-groups/e39b56aa-5120-477f-9f28-29ec286b9dcf

株式会社ディー・エヌ・エーのデータ組織の紹介ページ
https://engineering.dena.com/team/data/dataengineering/