Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DeNAデータエンジニアの組織・データエンジニアキャリアについて

 DeNAデータエンジニアの組織・データエンジニアキャリアについて

2022/10/06 に開催された
「DeNA流 データ組織の整え方 ~総データ量数ペタバイト!約30プロダクトを横断するデータ本部のデータドリブンな組織設計・継続運用のノウハウ~」
での データ本部データ基盤部データエンジニアリング第三グループ 城谷 信一郎の登壇資料です。

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

DeNA_Tech

March 15, 2023
Tweet

More Decks by DeNA_Tech

Other Decks in Technology

Transcript

  1. 株式会社ディー・エヌ・エー (2019 年 9 月 〜) • データエンジニア・マネージャー • 2020/10〜:ゲーム・ライブストリーミングのマネジメント

    • 2022/4〜:データエンジニア統括 • 2022/10〜:ヘルスケアドメインのストリームチームを担当 城谷 信一郎 (ジョウヤ シンイチロウ) Speakers

  2. 3

  3. 4

  4. 5

  5. 取り組みの背景 DeNAのデータエンジニアの活動概要 サービスデータ ・ログ ・データベース 社内データ ・会計・人事データ ・アンケートなど 社外データ ・協業先のログ

    ・SNS ・外部の蓄積データ データを収集し利用可能な状態を作る データ活用の生産性を向上させる土台 アナリスト マーケティング カスタマーサポート 会計部門 HR部門 データの発生源 利用者
 実現すべきこと ・データパイプラインの提供 ・レポート開発(アナリストと連携) ・共通環境・ツールの提供 ・データマネジメント環境の構築 ・運用ルール等の整備 etc... etc...
  6. 取り組みの背景 DeNAのデータエンジニアの活動概要 サービスデータ ・ログ ・データベース 社内データ ・会計・人事データ ・アンケートなど 社外データ ・協業先のログ

    ・SNS ・外部の蓄積データ データを収集し利用可能な状態を作る データ活用の生産性を向上させる土台 アナリスト マーケティング カスタマーサポート 会計部門 HR部門 データの発生源 利用者
 実現すべきこと ・データパイプラインの提供 ・レポート開発(アナリストと連携) ・共通環境・ツールの提供 ・データマネジメント環境の構築 ・運用ルール等の整備 etc... etc... DeNAが手掛けるサービス全てにおいて、データ活用は必須 事業活動におけるインフラとなっている つまり、サービスローンチ時には提供必須となっている
  7. 取り組みの背景 利用者に寄り添うマインドと体制 • 社内の専門家と利用部門とのコラボレーションによる探索とシステム化 ◦ 利用部門やその先のユーザーの課題解決までをフローと考える エンジニア アナリスト サイエンティスト 利用部門

    ・課題定義 ・目標と上流設計 ・KPI設計 ・データ探索 ・モデリング ・開発 ・デリバリー ・保守、運用 支える手段・技術 • OKRによる目標管理 • リーン思考、MVP、PoC • アジャイル、スプリント • KPTによる振り返り、改善
  8. 取り組みの背景 高い認知負荷とコンテクストスイッチによる生産性の低下 • 横断部署の性質上、様々なProjectに同時並行で関わる 事業A 事業B 事業C 事業D エンジニア ・課題定義

    ・目標と上流設計 ・KPI設計 ・データ探索 ・モデリング ・開発 ・デリバリ ・運用・保守 ・課題定義 ・目標と上流設計 ・KPI設計 ・データ探索 ・モデリング ・開発 ・デリバリ 設計 開発 QA 保守 探索型チーム ウォーターフォールProject
  9. データエンジニアのリ・デザイン データエンジニアの業務を分析・構造化し3つのポジションに分解 データアナリティクス エンジニア(AE) データソフトウェア エンジニア(SWE) データアーキテクト(DA) プロダクト・ツールから貢献 • BIなどプロダクトを提供

    • データ活用の生産性・質を向上 • AE,DAと連携したプロダクト開発 フルスタックな開発 • フロント〜インフラの広い開発 アーキテクチャ・インフラを支える • 横断的な施策による貢献 • アーキテクチャの刷新や各種機能・ 手順の提供により底上げ 高難易度のパイプライン開発 • リアルタイムデータなど高難易度案 件を支援 データマネジメント・セキュリティ • データ基盤の安定稼働 • データ品質の担保 • セキュリティの担保 事業に入り込むポジション • 事業最適化を追い求める • ドメインやデータ構造を熟知 • データマートやレポート。その他、 データ利用部分で事業に貢献 他のポジションと連携 • DA,SWEと連携 • 要件定義にも大きく貢献
  10. データエンジニアのリ・デザイン データアナリティクスエンジニアは近年注目されているロール データアナリティクス エンジニア(AE) 事業に入り込むポジション • 事業最適化を追い求める • ドメインやデータ構造を熟知 •

    データマートやレポート。その他、 データ利用部分で事業に貢献 他のポジションと連携 • DA,SWEと連携 • 要件定義にも大きく貢献 • US, 日本のテック企業でロールとして明確化 • クラウドやSaaSの浸透により、データ基盤を中央集 権で管理する事が少なくなった • 事業が活用しやすいデータモデリングやマートの開 発をdbtなどのツールを活用し実現 • その他、データの定義を整備したり、利用者へのト レーニングなどを行う
  11. 各ポジションの期待値と相互補完の関係を言語化 事業部A データアナリティクスエ ンジニア 事業部B データアナリティクスエ ンジニア 事業部C データアナリティクスエ ンジニア

    データアーキテクト データソフトウェアエンジニア 事業・データを熟知し 事業最適化を図る データ活用の底上げ・ 効率化を図る ドメイン間の移動 ポジション間の移動 ポジション間の移動
  12. 採用戦略の立案と施策の実現 採用における戦略作りと各施策を体系立て着実に実行 施策 詳細 必要な作業 リファラル採用の強化 ・会食などを経て、求職者とタッチポイン トを持つ ・役割や期待値を伝えつつ Willを醸成

    ・予算確保 ※今回はHR予算 採用関連ドキュメントを整備 1. アサインポジション一覧 2. 詳細な判定基準を人材のレベル 毎に整備 3. 採用プロセスの定義 ・各種ドキュメント整備 分析環境の整備 ・求人票へのアクセス解析を行うダッ シュボードを整備 ・Google Dataportalダッ シュボード整備 外部露出施策の実施 ・メディア媒体やイベントへの登壇 ・Twitter広告の配信 ・各媒体記事準備 ・イベント登壇準備
  13. キャリアの考え方 リ・デザインされたポジション毎にキャリアデザインを設計 データアナリティクス エンジニア(AE) データソフトウェア エンジニア(SWE) データアーキテクト(DA) プロダクト・ツールから貢献 • BIなどプロダクトを提供

    • データ活用の生産性・質を向上 • AE,DAと連携したプロダクト開発 フルスタックな開発 • フロント〜インフラの広い開発 アーキテクチャ・インフラを支える • 横断的な施策による貢献 • アーキテクチャの刷新や各種機能・ 手順の提供により底上げ 高難易度のパイプライン開発 • リアルタイムデータなど高難易度案 件を支援 データマネジメント・セキュリティ • データ基盤の安定稼働 • データ品質の担保 • セキュリティの担保 事業に入り込むポジション • 事業最適化を追い求める • ドメインやデータ構造を熟知 • データマートやレポート。その他、 データ利用部分で事業に貢献 他のポジションと連携 • DA,SWEと連携 • 要件定義にも大きく貢献
  14. キャリアの考え方 各ポジションをベースに深化・発展を支援する様にデザイン ジュニア アナリティクスエンジニア データアーキテクト ソフトウェアエンジニア アナリティクスエンジニア 経験2-3年位までは、アナリティ クスエンジニアとしてデータ活 用の現場を理解

    ※年数は目安 経験3年目以降は、各ポジショ ン毎に以降でキャリアを深化さ せる ミドル〜シニア以降は、キャリアは個人のもの。 Mgrと壁打ちしながら本人が決める アナリティクスエンジニア特化 データアナリスト×データエンジニア エンジニアリングマネージャー テックリード データ活用コンサル・ PM
  15. 認知負荷の低い開発体制の構築 探索と早い変更フローによる素早い価値の提供と学習 • 探索的型のチームが増えてきており高いフローの効率が求められる 事業A 事業B 事業C 事業D エンジニア ・課題定義

    ・目標と上流設計 ・KPI設計 ・データ探索 ・モデリング ・開発 ・デリバリ ・運用・保守 ・課題定義 ・目標と上流設計 ・KPI設計 ・データ探索 ・モデリング ・開発 ・デリバリ 設計 開発 QA 探索型チーム ウォーターフォールProject 保守
  16. 認知負荷の低い開発体制の構築 リソース効率 と フロー効率 の戦略と指標 Project A Project B Project

    C Project C Project B Project A • 価値提供の単位で多職種でチームを編成 • 価値を提供するリードタイムの短さを重視 • 探索的な開発に向いており、フロー効率と比べて スケジュールは重視されない • 職種毎にチームを編成 • 開発リソースの最大活用を重視 • 固定的な開発に向いており、リソース効率と 比べてスケジュールを重視する BIZ BIZ ANL DS ENG BIZ ANL DS ENG BIZ ANL DS ENG ENG ENG ENG BIZ BIZ ANL ANL ANL DS DS DS フロー効率
 リソース効率

  17. 認知負荷の低い開発体制の構築 リソース効率を優先したアサインに限界 • 一人がドメインも文脈も違うプロジェクトにアサイン ◦ 絶え間なく事業が立ち上がる環境だからこそ • リモートワーク化もありプロジェクト毎に倍々に増える会議 • プロジェクト間でつける事の出来ない優先度

    • データ活用を通じて、事業やその先のユーザーに価値を 
 届けることにリソースと認知を集中したい 
 • その価値提供を、スピード感を持って実現し学習サイクルを 
 回し続けたい

  18. 認知負荷の低い開発体制の構築 チームトポロジーを活用した開発体制を組成中 チームトポロジーとは • 顧客への価値提供のフローを最大化させるためのの組織設計論 • 組織の形がソフトウェアアーキテクチャに影響を与えるコンウェイの法則を逆 手に取った逆コンウェイ戦略でチームを組成する • LeanとDevOps

    を補完・補強する理論 • チームの認知負荷・コミュニケーション負荷を改善し以下を狙う ◦ コミュニケーションコストの最適化 ◦ チームファーストでの責任境界の明確化 ◦ ブロック・非効率な開発フローの改善 ◦ メンバーのモチベーション改善
  19. 認知負荷の低い開発体制の構築 チームトポロジーを活用した開発体制を組成中 事業ドメイン単位でチームを分割しフロー効率を高める • 事業ドメインの中でのデータ活用に注力 ◦ これをストリームアラインドチームと呼ぶ • 他のチームとは弱い依存関係を作り認知負荷を下げる ◦

    ストリームアラインドチーム内で顧客価値まで自律して届ける • ストリームアラインドチームを支えるチームも組成 ゲーム事業 ライブストリーミン グ事業 ヘルスケア事業 社内利用部門 支援チーム プロダクト チーム 各事業に向くチームフロー効率を高めるために以下を実施 ・技術、方式のレクチャーを行う ・データ活用で利用するプロダクトを提供する 一定水準以上のレベルで、データ活用を引っ張る チームを組成する
  20. 認知負荷の低い開発体制の構築 チーム・インタラクションマトリクスの整備と運用 チームA チームB コラボレー ション • お互いの専門性を共有しながら、新たな探索 の実施
 •

    目的、期限を設け密にコミュニケーションしプ ロジェクトを実施
 
 チーム名 コミュニケーション方法 目的 チームA-チームB コラボレーション ◦◦ チームB-チームC ファシリテーション △△ • コミュニケーションのインタフェースと目的を一 元で管理 • ロギングすると共に、課題認識や振り返りに 活用