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

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

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

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

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

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

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

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さん

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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担当者(権限なし) ? ! プロジェクトへの アクセス権限なし

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

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

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

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

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

No content