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

2022/10/06 に開催された
「DeNA流 データ組織の整え方 ～総データ量数ペタバイト！約30プロダクトを横断するデータ本部のデータドリブンな組織設計・継続運用のノウハウ～」
での データ本部データ基盤部テクノロジーイネーブリンググループ 深瀬 充範の登壇資料です。

イベントページ：https://techplay.jp/event/873773?pw=2a2k6wQp

Transcript

1. 社内データ利活用の推進と
   技術的負債の解決に向けた取り組み
   深瀬充範
   データ本部データ基盤部テクノロジーイネーブリングG
   兼 データエンジニアリング第二G
   株式会社ディー・エヌ・エー
   © DeNA Co.,Ltd.
   

   View Slide

2. 2
   自己紹介
   深瀬 充範
   ● 前職は大手通信企業 (2014/04 ~ 2020/01)
   ○ バックエンドエンジニア
   ■ データ系多め
   ● 株式会社ディー・エヌ・エー (2020/02 ~)
   ○ データエンジニア
   ○ 最近はエンジニアリングマネージャー
   データエンジニア
   @norif
   実家の猫
   

   View Slide

3. 3
   本セクションの流れ
   DeNAにおける社内データ利活用の流れ
   技術的負債？
   データ活用推進への取り組み
   結果とこれから
   1
   2
   3
   4
   

   View Slide

4. 4
   DeNAにおける社内データ利活用の流れ
   201x 2022
   2020
   前身となる分析組織にて特定事業向けの
   SNSデータ基盤を開発・運用
   会計領域 / 人事データ　⇒　活用が進まず・停滞
   部門ごとにデータ整備・活用PJを実施
   → 保守エンジニアの異動・離職などが発生
   改善要望・保守対応が進まない
   

   View Slide

5. 5
   DeNAにおける社内データ利活用の流れ
   CS VOC分析
   部門ごとにデータ整備・活用PJを実施
   データエンジニアリンググループ
   データの民主化・データ活用水準向上
   201x 2022
   2020
   前身となる分析組織にて特定事業向けの
   SNSデータ基盤を開発・運用
   他事業への展開・ニーズ拡大
   * 法務観点でのチェック済・プライバシーポリシーを遵守
   会計領域 / 人事データ　⇒　活用が進まず・停滞
   新規領域 データ分析推進
   SNSデータとの連携*
   分析効率化
   人事データ利用種別拡大
   予実管理・見込分析の強化
   → 保守エンジニアの異動・離職などが発生
   改善要望・保守対応が進まない
   

   View Slide

6. 6
   「データの民主化」に向けた活動内容
   データエンジニア組織が主体となり、新規データ利活用案件を積極的に推進
   CEDEC 2020
   ● ネットワーク科学で挑戦するゲームマーケティング改革
   (cesa.or.jp) (Slideshare)
   CEDEC 2022
   ● 【レポート】広告識別子に依存しないエンタメ広告運用～
   SNSの”キーワード”に着目した最適化〜 #CEDEC2022
   #classmethod_game | DevelopersIO
   ・Twitterデータ収集基盤構築〜案件・業務でのデータ利活用のサポート
   ・経営管理データの分析ダッシュボード化（予実管理・見込・分析 etc…）
   ・カスタマーサポート VOC分析データパイプライン・BI化サポート
   ・人事データ 組織満足度アンケート集計分析効率化 etc…
   バックオフィス系（社内）データ利活用推進
   SNS・マーケティング系データ利活用推進
   

   View Slide

7. 7
   データ利活用を推進すると何が起こるか？（光）
   Fさん！
   これお願い！ やっていき
   部署要望
   提案活動
   データエンジニア
   Fさん
   もっとデータ
   利活用を推進
   させるぞ！
   データ利活用が未開拓・エンジニア不在である組織へのアプローチを開始
   ↓
   社内部門が抱えるデータ利用についての課題をヒアリング
   データエンジニアによるコンサルティングや、ツール開発によるPoCを実施
   ↓
   データ活用要件の明確化し、潜在的ニーズを引き出したプロダクトを提供
   ↓
   KPIを駆使したデータドリブンな業務運営へのシフトを促進
   便利です！
   ありがとう！
   神！
   追加要望あり！
   

   View Slide

8. 8
   新規データ利活用に向けたタスクを特定メンバーや暫定チームで担当
   ↓
   エンジニア不在の組織へのアプローチであるため、
   メンバー＆自部署の工数負荷・運用割合が増加
   ↓
   更にデータ利活用のニーズが加速する。
   チームの工数不足・属人化した開発が多発する。
   ↓
   ＿人人人人人人＿
   ＞　工数爆発　＜
   ￣Y^Y^Y^Y^Y^Y^￣
   データ利活用を推進すると何が起こるか？（闇）
   Fさん！
   これお願い！ やっていき
   A案件 B案件 C運用
   D部署要望
   E提案活動
   A運用 B案件
   C運用
   A運用 B案件
   C運用 D運用 E運用
   Fさん！
   またお願い！
   F追加要望
   G提案活動
   ！？
   データエンジニア
   Fさん
   

   View Slide

9. 9
   データ利活用での業務改革を推進しているが
   自分たちもなんとかするべきでは？🤔
   

   View Slide

10. 10
    そうだ、チームを作ろう。
    

    View Slide

11. 11
    チームビルディングのモチベーション
    ● 現在の取り組みでは、ほぼ類似したスキルセットと機能開発が要求される
    ○ APIを用いてデータ収集をしてほしい。分析用のダッシュボードがほしい
    　⇒　１つのチームへ集約し、運用含めて包括的にリソース管理をすべきでは？
    ● 技術的負債の課題
    ○ 属人化によりレビュー体制が殆どない。コード品質が良くない状態
    ○ オレオレ設計で煩雑、ましてやドキュメントがないことも多々
    　⇒　持続可能なチーム開発を実現して、負債の解消・抑制を進めていく
    ref. 扱うデータは多種多様。
    DeNAならではのデータエンジニア活躍の場と働き方
    | フルスイング - DeNA
    

    View Slide

12. 12
    ・「負債」＝ 利子が発生する ⇒ 返済を怠ると、複利で膨らんでいく
    ⇒ 返済に追われ、価値創出に注力できなくなる（デリバリー低下）
    　　例：ユーザー「Fさん、このデータも使いたいんだけどどうでしょう？」
    　　　　エンジニア「うーん。（コード読解・整備も加えると…）工数〇〇日かかります…。」
    　　　　　⇒ 後任者が連帯保証人となり返済させられる（組織力低下）
    

    View Slide

13. 13
    技術的負債の生まれ方
    ・非効率な開発プロセス
    ・複雑な設計、継ぎ接ぎされたアーキテクチャ
    ・不適切なコード・不十分なテスト
    ・エンジニアのスキル不足
    ・属人化、ドキュメンテーション不足
    負債を発生させないことは難しいが、借り入れを抑えることはできるはず
    ⇒　チームプロセスを整備・明文化して定着させるところから始める
    

    View Slide

14. 14
    チームビルディングのステップ（タックマンモデル）
    成果
    時間
    形成期 混乱期 統一期 機能期
    チームが
    形成された
    ばかり
    意見の衝突 共通規範の形成 成果が
    出てくる
    

    View Slide

15. 15
    チームビルディングのステップ（タックマンモデル）
    成果
    時間
    形成期 混乱期 統一期 機能期
    チームが
    形成された
    ばかり
    意見の衝突 共通規範の形成 成果が
    出てくる
    スクラムの導入
    チーム文化の定着
    

    View Slide

16. テンプレートに当てはめつつ、ややカンバン寄りにカスタマイズして実施
    ・ 1 スプリント = 1 週間
    　　⇒　案件数・変化の多い状況なので短期間が適切と判断
    ・デイリースクラム
    　　⇒　毎週月曜のみZoomでの実施。
    　　　　月曜以外は、特定の時間にSlackスレッド上での報告を実施。
    ・レトロペクティブ：アジェンダを定め、50分間での時間厳守を意識して実施
    　　⇒　案件状況シェア10分 / Spring振り返り20分 / バックログリファインメント20分
    16
    スクラムの導入
    

    View Slide

17. ルールから文化へと浸透させるため、ドキュメントを充実させた
    17
    スクラムの導入
    

    View Slide

18. ・チケットのルールを整備
    　・ステータス基準
    　・スプリントポイント基準
    　・「適量」は属人化の元として
    　　 曖昧さに対するチーム基準を設置
    18
    スクラムの導入
    

    View Slide

19. 19
    技術負債解消の時間はどうするの…？
    

    View Slide

20. 20
    技術負債解消の時間はどうするの…？
    KAIZEN バックログの設置
    タスク状況の定期モニタリング
    

    View Slide

21. 21
    KAIZENバックログの設置
    ・スプリント期間の１〜２割は改善業務に充てる
    　・モブプログラミング
    　・ナレッジシェア
    　・ドキュメンテーション作業
    　・リファクタリングなど
    ナレッジシェアの基本
    

    View Slide

22. 22
    モブプログラミング
    週次で、１〜２時間のチームモブプロ時間を設置した
    ● 以下のルールで運用
    　　・解決したい課題・テーマを事前申告で持ち寄る
    　　・データエンジニアリング・分析に関連する技術検証
    　　・新規案件、属人状態のタスクを優先的にチームで解決させる
    

    View Slide

23. 23
    タスク状況の定期モニタリング
    ● スプリント期間中のタスク状況可視化を以下のように実現
    ○ タスク管理には ClickUp を利用
    ○ Integromat を利用して BigQuery へタスクデータを日次 Insert 処理
    ○ Looker ダッシュボードを準備
    

    View Slide

24. 24
    膨大なデータ利活用案件下での属人化排除の工夫
    アサインしている案件・タスクの種別割合を可視化
    アサイン工数割合の標準偏差を算出し、タスクのバランスを確認
    割合も
    チェック
    

    View Slide

25. 25
    チームビルディングのステップ（タックマンモデル）
    形成期 機能期 さん
    散会期
    成果
    時間
    形成期 混乱期 統一期 機能期
    チームが
    形成された
    ばかり
    意見の衝突 共通規範の形成 成果が
    出てくる
    スクラムの導入
    チーム文化の定着
    

    View Slide

26. 26
    チームビルディングのステップ（タックマンモデル）
    形成期 混乱期 統一期 機能期
    チームが
    形成された
    ばかり
    意見の衝突 共通規範の形成 成果が
    出てくる
    成果
    時間
    スクラムの導入
    チーム文化の定着
    共通開発ルール整備
    データ活用推進
    

    View Slide

27. 27
    開発スタイルの統一
    Pythonを主流としたコード規約・開発時の推奨ルールを準備
    ● パッケージマネージャー : pipenv
    ○ requirements.txt からの移行が多かったため採択。poetryへの移行も検討中
    ● Linter / Formatter : flake8, isort, black ⇒ 統合的に扱える pysen を採択
    ● Test : pytest
    ● 推奨ライブラリ/ フレームワーク
    ○ pydantic / FastAPI / Streamlit etc…
    ● CI : CircleCI
    ○ Linting / Formatting / Testing のチェック自動化のテンプレート準備
    ○ ビルド・デプロイ自動化を推奨
    

    View Slide

28. 28
    pydantic によるデータモデル定義の統一化
    pydantic 導入前は各開発者の裁量でデータモデルを定義していた・・・
    ● オレオレクラス、dataclass、Dictでの定義(!?) etc…
    ○ 統一性が一切なし / 保守性にも欠けている状態
    ○ そもそもPythonの型ヒントは型厳密ではない
    ■ モデル変更に弱い・異常データの考慮不足など、負債の一因となっていた
    

    View Slide

29. 29
    pydantic によるデータモデル定義の統一化
    pydantic 導入によってできること
    ● Typingによる型のバリデーションが可能となる
    ○ 意図しないデータであればエラーを返す、かつ高速なライブラリ
    ○ dataclassで実現する場合、バリデーションの実装が複雑になるケースがある
    ■ pydantic での開発簡略化・一定水準への統一化も出来る
    ● また、datamodel-codegen を利用すれば既存データからモデル自動生成も可能
    

    View Slide

30. 30
    BigQuery承認済みビュー(Authorized View)の活用
    これまではプロジェクトごとにデータ基盤を構築し、それぞれの環境でデータを取得していた。
    Build project
    ProjectA
    ProjectA
    ProjectA
    ProjectB
    ProjectB
    ProjectB
    ProjectC
    ProjectC
    ProjectC
    廃止
    ／(^o^)＼
    

    View Slide

31. 31
    BigQuery承認済みビュー(Authorized View)の活用
    Data Warehouse
    Text Data
    Extract &
    Transform Data
    Call Function
    Invoker
    Cloud Functions
    Prediction Pipeline
    Vertex AI Pipeline
    Digdag Cluster
    Kubernetes Engine
    Transform &
    Load Data
    Output
    Cloud Storage
    Load Data Raw Data
    BigQuery
    Predicted Data
    BigQuery
    Data collection pipeline
    Triggering NLP pipeline runs
    Run workflow
    Authorized View
    BigQuery
    Business
    Intelligence
    Looker
    Project A
    Authorized View
    BigQuery
    Business
    Intelligence
    Looker
    Project B
    Authorized View
    BigQuery
    Business
    Intelligence
    Looker
    Project C
    中央集権型のデータ収集サービス 適切なデータ / クエリコストの分散
    ・・・
    ref. データ基盤におけるエンジニア主導の低コストな自然言語処理パイプライン構築 | DeNA×AI WORKS https://dena.ai/works/nlp/
    where project = "A"
    where project = "B"
    where project = "C"
    B担当者
    B担当者(権限なし)
    ?
    !
    プロジェクトへの
    アクセス権限なし
    

    View Slide

32. 32
    行レベルセキュリティの活用
    社員デー
    タ
    組織
    データ
    各種
    情報
    source wh
    mart
    データマート層で
    ユーザ情報を付与した
    テーブルを生成
    担当部署や役職等に応じて閲覧権限の異なるデータ利活用ではRLS(行レベルセキュリティ)を活用
    マネージャー
    (社員番号100000)
    1
    2
    3
    4
    A部
    B部
    B部
    C部
    …
    …
    …
    …
    123456
    100000
    100000
    543210
    No 部署 … 社員番号
    B部に関するデータだけの
    ダッシュボードが利用可能
    https://cloud.google.com/looker/docs/admin-panel-users-user-attributes
    

    View Slide

33. 33
    の活用によるデータ品質向上
    新規でのデータパイプラインではdbtを活用
    - SQLがあればパイプラインが構築可能
    - 依存関係をSQL上で from {{ref('xx')}} のように指定
    - テスト定義が容易に可能
    - Unique / NOT NULLチェック
    - 特定の値を含むか
    - 必要であればカスタム定義も可能
    

    View Slide

34. 34
    dbtを活用したデータパイプライン（Doing）
    xx
    データ
    yy
    データ
    zz
    マスタ
    内製
    ツール
    source wh
    mart
    外部
    シート アサーションでの異常通知
    ユーザーがデータを
    安心・安全に扱える状態を
    常に保っていく
    パイプライン・サービスの
    保守・運用を効率化
    コードの負債も抑制していく
    

    View Slide

35. 35
    結果、どうだった？
    ● 技術的負債を解消「していく」から「している」へのシフト
    ○ 負債を完済するのはまだまだ厳しい（プロダクトが多い）
    ○ 従来に比べてドキュメント・ナレッジの共有が大きく進んでいる
    ● チーム学習の成果
    ○ 新技術キャッチアップ ⇒ プロダクトへの適用事例創出(dbtなど)
    ● 新規データ利活用が活発化
    ○ 提案でのデータ活用推進からユーザーによる能動的なデータ利活用へ
    ■ 社内で評判を聞いて相談が来たことも・・・
    ● チームリソースに対するドメインの多さによる負荷が課題
    

    View Slide

36. 36
    これから
    ● 社内での更なるデータ利活用を支える組織として
    ○ 今年の４月からチームから組織（グループ）となった
    ■ 社内でのデータ利活用の重要度も増している
    ○ ドメインの多さによる負荷＝「認知負荷」を低下させる活動にもシフト
    ■ もはや「社内」では収まらない状態に近づきつつある
    ● 場合によってはチームを分割・移譲するなど節理面の見直しも肝に
    ■ 「社内データ利活用の芽を絶やさない、持続可能なエンジニアリング体制を提
    供すること」
    ● 他チームへのチーム組成・チーム運営ナレッジの伝播にも力を入れる
    ○ （自分含め）一部のチームメンバーが新規に立ち上がる支援チームへ
    ■ 技術支援・チームの自律性向上などチーム外へも知見を広げていく
    

    View Slide

37. View Slide