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

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

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

Transcript

1. DeNAデータエンジニアの組織
 データエンジニアキャリアについて
 株式会社ディー・エヌ・エー 城谷 信一郎

2. 株式会社ディー・エヌ・エー （2019 年 9 月 〜） • データエンジニア・マネージャー • 2020/10〜：ゲーム・ライブストリーミングのマネジメント • 2022/4〜：データエンジニア統括 • 2022/10〜：ヘルスケアドメインのストリームチームを担当 城谷 信一郎 （ジョウヤ シンイチロウ） Speakers

6. 全社横断でのデータ活用を支援
 • データ本部は全社横断組織 • 各事業や社内組織に向けてAI/分析など データ活用の支援を実施
7. DeNAのデータ活用を引っ張るデータエンジニア組織として • 利用者に寄り添うをキーメッセージに日々開発・運用 • しかし、様々な環境の変化により寄り添う事が非常に難しい自体に • 挑戦中の取り組みも含めて、どう組織やデータエンジニアのロールを アップデートしているか。その概要をお伝えします。 このセッションでお伝えすること
8. 取り組みの背景

9. 取り組みの背景 DeNAのデータエンジニアの活動概要 サービスデータ ・ログ ・データベース 社内データ ・会計・人事データ ・アンケートなど 社外データ ・協業先のログ ・SNS ・外部の蓄積データ データを収集し利用可能な状態を作る データ活用の生産性を向上させる土台 アナリスト マーケティング カスタマーサポート 会計部門 HR部門 データの発生源 利用者
 実現すべきこと ・データパイプラインの提供 ・レポート開発（アナリストと連携） ・共通環境・ツールの提供 ・データマネジメント環境の構築 ・運用ルール等の整備 etc... etc...
10. 取り組みの背景 DeNAのデータエンジニアの活動概要 サービスデータ ・ログ ・データベース 社内データ ・会計・人事データ ・アンケートなど 社外データ ・協業先のログ ・SNS ・外部の蓄積データ データを収集し利用可能な状態を作る データ活用の生産性を向上させる土台 アナリスト マーケティング カスタマーサポート 会計部門 HR部門 データの発生源 利用者
 実現すべきこと ・データパイプラインの提供 ・レポート開発（アナリストと連携） ・共通環境・ツールの提供 ・データマネジメント環境の構築 ・運用ルール等の整備 etc... etc... DeNAが手掛けるサービス全てにおいて、データ活用は必須 事業活動におけるインフラとなっている つまり、サービスローンチ時には提供必須となっている
11. 取り組みの背景 利用者に寄り添うマインドと体制 • 社内の専門家と利用部門とのコラボレーションによる探索とシステム化 ◦ 利用部門やその先のユーザーの課題解決までをフローと考える エンジニア アナリスト サイエンティスト 利用部門 ・課題定義 ・目標と上流設計 ・KPI設計 ・データ探索 ・モデリング ・開発 ・デリバリー ・保守、運用 支える手段・技術 • OKRによる目標管理 • リーン思考、MVP、PoC • アジャイル、スプリント • KPTによる振り返り、改善
12. 取り組みの背景 内外で様々な環境の変化が発生する 1. クラウドジャーニーによるオンプレミス撤廃 a. 中央管理から分散管理へ b. データ活用（分析／AI）プロジェクトが200環境以上に分散 2. ゲーム事業以外の急成長や新規事業の勃興 a. Pocochaを始めとするライブストリーミング事業の急成長 b. アライアンスビジネスを含む新規事業の種まきが複数発生
13. 取り組みの背景 内外で様々な環境の変化が発生する 3. データ分析からデータ活用へ民主化が進む a. 様々なロールのメンバーが様々な要件で活用 4. メンバーの入れ替わり a. 細かい文脈・背景は引き継ぐ度に薄くなる
14. 取り組みの背景 環境の変化に対して徐々に歪が生まれ始める • 急激なサービス増加によるリソース効率でのアサイン ◦ 複数プロジェクト・サービスに同時アサインされることによる ◦ 同時にOKRを定義した内部改善のProjectも走る • 対応する業務範囲が拡大 ◦ 提供するインタフェースやステークホルダーが多種多様に ◦ データエンジニアロールの役割が段々と不明瞭に
15. 取り組みの背景 高い認知負荷とコンテクストスイッチによる生産性の低下 • 横断部署の性質上、様々なProjectに同時並行で関わる 事業A 事業B 事業C 事業D エンジニア ・課題定義 ・目標と上流設計 ・KPI設計 ・データ探索 ・モデリング ・開発 ・デリバリ ・運用・保守 ・課題定義 ・目標と上流設計 ・KPI設計 ・データ探索 ・モデリング ・開発 ・デリバリ 設計 開発 QA 保守 探索型チーム ウォーターフォールProject
16. 取り組みの背景 結果、要望を解決することが優先されてしまい様々な弊害を生む 1. メンバーモチベーションの低下 a. 煩雑なコミュニケーション。頭の切り替え負荷 2. 個人商店化・属人化 a. 実装品質の低下やバラツキ b. 困難な引き継ぎ。実装の文脈や背景が失われることも 3. 事業への価値貢献の活動が縮小 a. めぐって本来価値の活動も制限されることに
17. 10年以上運用の中で積み重ねられた 負債と失われた文脈 組織構造やマインドをアップデートし、持続 可能な開発組織へ再組成したい
18. データエンジニア組織のアップデートに向けて 組織を再組成するには仲間づくりと貢献・成長できる環境づくりの両面が必要 一緒に貢献する仲間を作る活動 ・データエンジニアのリ・デザイン ・採用活動を移譲・効率化し、組織 のことにする 仲間が貢献と・成長出来る環境作り ・キャリアとラダーのデザイン ・認知負荷の低い開発体制の構築
19. 一緒に貢献する仲間を作る活動

20. データエンジニア組織のアップデートに向けて 組織を再組成するには仲間づくりと貢献・成長できる環境づくりの両面が必要 一緒に貢献する仲間を作る活動 ・データエンジニアのリ・デザイン ・採用活動を移譲・効率化し、組織 のことにする 仲間が貢献と・成長出来る環境作り ・キャリアとラダーのデザイン ・認知負荷の低い開発体制の構築
21. データエンジニアのリ・デザイン まず採用活動の強化を図ったがデータエンジニアの解像度が低い状態 • データエンジニアというロールが一般的で無く採用ターゲット定義に苦戦 採用エージェント HR（採用担当） データエンジニア データエンジニア 募集要項 • 日本では、比較的新しい職種 • 対応範囲も広く、要求人材や優先度 が不明瞭に • データエンジニア側にも、共通のコン テクストが無く、解釈にブレ
22. データエンジニアのリ・デザイン データエンジニアの業務を分析・構造化し３つのポジションに分解 データアナリティクス エンジニア(AE) データソフトウェア エンジニア(SWE) データアーキテクト(DA) プロダクト・ツールから貢献 • BIなどプロダクトを提供 • データ活用の生産性・質を向上 • AE,DAと連携したプロダクト開発 フルスタックな開発 • フロント〜インフラの広い開発 アーキテクチャ・インフラを支える • 横断的な施策による貢献 • アーキテクチャの刷新や各種機能・ 手順の提供により底上げ 高難易度のパイプライン開発 • リアルタイムデータなど高難易度案 件を支援 データマネジメント・セキュリティ • データ基盤の安定稼働 • データ品質の担保 • セキュリティの担保 事業に入り込むポジション • 事業最適化を追い求める • ドメインやデータ構造を熟知 • データマートやレポート。その他、 データ利用部分で事業に貢献 他のポジションと連携 • DA,SWEと連携 • 要件定義にも大きく貢献
23. データエンジニアのリ・デザイン データアナリティクスエンジニアは近年注目されているロール データアナリティクス エンジニア(AE) 事業に入り込むポジション • 事業最適化を追い求める • ドメインやデータ構造を熟知 • データマートやレポート。その他、 データ利用部分で事業に貢献 他のポジションと連携 • DA,SWEと連携 • 要件定義にも大きく貢献 • US, 日本のテック企業でロールとして明確化 • クラウドやSaaSの浸透により、データ基盤を中央集 権で管理する事が少なくなった • 事業が活用しやすいデータモデリングやマートの開 発をdbtなどのツールを活用し実現 • その他、データの定義を整備したり、利用者へのト レーニングなどを行う
24. 各ポジションの期待値と相互補完の関係を言語化 事業部A データアナリティクスエ ンジニア 事業部B データアナリティクスエ ンジニア 事業部C データアナリティクスエ ンジニア データアーキテクト データソフトウェアエンジニア 事業・データを熟知し 事業最適化を図る データ活用の底上げ・ 効率化を図る ドメイン間の移動 ポジション間の移動 ポジション間の移動
25. データエンジニアのリ・デザイン ポジションを明確化することで解像度があがり共通のコンテクストで会話 • ◦◦の事業に対応出来るデータアナリティクスエンジニアがターゲット といったより具体的な会話が実現 採用エージェント HR（採用担当） データエンジニア アナリティクス エンジニア 募集要項 • 選考フローの効率化 • 求職者への訴求力、業務理解の向上 • 採用ターゲットや期待値の明確化 データアーキテクト 募集要項 データソフトウェア エンジニア 募集要項
26. 採用戦略の立案と施策の実現 採用における戦略作りと各施策を体系立て着実に実行 基本戦略 • あらゆる採用のタッチポイントを狙うがリファラルを最優先に実施 • 選考業務をチームメンバーにも移譲することで当事者意識を芽生えさせる • 媒体やイベントなどへの露出も積極的におこない、母集団を形成する • 選考業務が過度な負荷にならないように言語化・プロセス化に務める
27. 採用戦略の立案と施策の実現 採用における戦略作りと各施策を体系立て着実に実行 施策 詳細 必要な作業 リファラル採用の強化 ・会食などを経て、求職者とタッチポイン トを持つ ・役割や期待値を伝えつつ Willを醸成 ・予算確保 ※今回はHR予算 採用関連ドキュメントを整備 1. アサインポジション一覧 2. 詳細な判定基準を人材のレベル 毎に整備 3. 採用プロセスの定義 ・各種ドキュメント整備 分析環境の整備 ・求人票へのアクセス解析を行うダッ シュボードを整備 ・Google Dataportalダッ シュボード整備 外部露出施策の実施 ・メディア媒体やイベントへの登壇 ・Twitter広告の配信 ・各媒体記事準備 ・イベント登壇準備
28. 採用戦略の立案と施策の実現 ポジション毎に各指標をモニタリングし施策改善を実施
29. 採用戦略の立案と施策の実現 現場サイドでの選考業務の自走化と振り返りによる施策実施が実現 • ドキュメントやノウハウが磨かれていき選考プロセスの質と速度が向上 • Twitter広告やイベント前後での求人票へのアクセス解析と振り返り ◦ 具体的に以下の改善を実施 ▪ 遠隔地勤務可能のアピール ▪ ポテンシャル枠の準備
30. このパートのまとめ データ活用の人材確保は非常に困難。チームの総力が必要 • HR・採用担当に委任するのでは無く深く関わり伴走 ◦ 戦略と優先順位。それに基づく施策の重要性 • チームを作るのはマネージャーだけの仕事ではない。チームの仕事 ◦ 適切な移譲こそ採用力強化や言語化が進む • 外部への露出による認知が広まるのは徐々に。失うのは瞬く間に。 ◦ 今回改めて認知を再度広げることの難しさを知る
31. 仲間が貢献と・成長出来る環境作り

32. データエンジニア組織のアップデートに向けて 組織を再組成するには仲間づくりと貢献・成長できる環境づくりの両面が必要 一緒に貢献する仲間を作る活動 ・データエンジニアのリ・デザイン ・採用活動を移譲・効率化し、組織 のことにする 仲間が貢献と・成長出来る環境作り ・キャリアとラダーのデザイン ・認知負荷の低い開発体制の構築
33. キャリアの考え方 リ・デザインされたポジション毎にキャリアデザインを設計 データアナリティクス エンジニア(AE) データソフトウェア エンジニア(SWE) データアーキテクト(DA) プロダクト・ツールから貢献 • BIなどプロダクトを提供 • データ活用の生産性・質を向上 • AE,DAと連携したプロダクト開発 フルスタックな開発 • フロント〜インフラの広い開発 アーキテクチャ・インフラを支える • 横断的な施策による貢献 • アーキテクチャの刷新や各種機能・ 手順の提供により底上げ 高難易度のパイプライン開発 • リアルタイムデータなど高難易度案 件を支援 データマネジメント・セキュリティ • データ基盤の安定稼働 • データ品質の担保 • セキュリティの担保 事業に入り込むポジション • 事業最適化を追い求める • ドメインやデータ構造を熟知 • データマートやレポート。その他、 データ利用部分で事業に貢献 他のポジションと連携 • DA,SWEと連携 • 要件定義にも大きく貢献
34. キャリアの考え方 各ポジションをベースに深化・発展を支援する様にデザイン ジュニア アナリティクスエンジニア データアーキテクト ソフトウェアエンジニア アナリティクスエンジニア 経験2-3年位までは、アナリティ クスエンジニアとしてデータ活 用の現場を理解 ※年数は目安 経験3年目以降は、各ポジショ ン毎に以降でキャリアを深化さ せる ミドル〜シニア以降は、キャリアは個人のもの。 Mgrと壁打ちしながら本人が決める アナリティクスエンジニア特化 データアナリスト×データエンジニア エンジニアリングマネージャー テックリード データ活用コンサル・ PM
35. キャリアの考え方 定期的にキャリアの大きな方向性も確認 Individual contributor(IC) Tech lead(TL) Engineering manager(EM) 今後のキャリアの方向性は？ ・直近はICとしてプロジェクトに貢献 ・２年後は、EMとして組織立上げやマネ ジメントも経験したい OK。目標設定もそれを 意識しましょう 御意に
36. キャリアの考え方 各ポジション毎にキャリアラダーを設け成長観点での目安を設ける ジュニアレベル
 ミドルレベル
 シニアレベル
 今ココ 1on1などで定期的にメンタリング • キャリアの方向性確認 • 上位レベルとのギャップ確認 • 成長できる環境をすり合わせ ◦ 今後発生するProjectでチャレンジ ◦ 提案しチャレンジする Project
37. 認知負荷の低い開発体制の構築 探索と早い変更フローによる素早い価値の提供と学習 • 探索的型のチームが増えてきており高いフローの効率が求められる 事業A 事業B 事業C 事業D エンジニア ・課題定義 ・目標と上流設計 ・KPI設計 ・データ探索 ・モデリング ・開発 ・デリバリ ・運用・保守 ・課題定義 ・目標と上流設計 ・KPI設計 ・データ探索 ・モデリング ・開発 ・デリバリ 設計 開発 QA 探索型チーム ウォーターフォールProject 保守
38. 認知負荷の低い開発体制の構築 リソース効率 と フロー効率 の戦略と指標 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 フロー効率
 リソース効率

39. 認知負荷の低い開発体制の構築 リソース効率を優先したアサインに限界 • 一人がドメインも文脈も違うプロジェクトにアサイン ◦ 絶え間なく事業が立ち上がる環境だからこそ • リモートワーク化もありプロジェクト毎に倍々に増える会議 • プロジェクト間でつける事の出来ない優先度 • データ活用を通じて、事業やその先のユーザーに価値を 
 届けることにリソースと認知を集中したい 
 • その価値提供を、スピード感を持って実現し学習サイクルを 
 回し続けたい

40. 認知負荷の低い開発体制の構築 チームトポロジーを活用した開発体制を組成中 チームトポロジーとは • 顧客への価値提供のフローを最大化させるためのの組織設計論 • 組織の形がソフトウェアアーキテクチャに影響を与えるコンウェイの法則を逆 手に取った逆コンウェイ戦略でチームを組成する • LeanとDevOps を補完・補強する理論 • チームの認知負荷・コミュニケーション負荷を改善し以下を狙う ◦ コミュニケーションコストの最適化 ◦ チームファーストでの責任境界の明確化 ◦ ブロック・非効率な開発フローの改善 ◦ メンバーのモチベーション改善
41. 認知負荷の低い開発体制の構築 チームトポロジーを活用した開発体制を組成中 事業ドメイン単位でチームを分割しフロー効率を高める • 事業ドメインの中でのデータ活用に注力 ◦ これをストリームアラインドチームと呼ぶ • 他のチームとは弱い依存関係を作り認知負荷を下げる ◦ ストリームアラインドチーム内で顧客価値まで自律して届ける • ストリームアラインドチームを支えるチームも組成 ゲーム事業 ライブストリーミン グ事業 ヘルスケア事業 社内利用部門 支援チーム プロダクト チーム 各事業に向くチームフロー効率を高めるために以下を実施 ・技術、方式のレクチャーを行う ・データ活用で利用するプロダクトを提供する 一定水準以上のレベルで、データ活用を引っ張る チームを組成する
42. 認知負荷の低い開発体制の構築 開発体制の組成は道半ば 1. 現時点ではチームを分割し立ち上げのフェーズ 2. チームトポロジーの理念・概念の輪読会・勉強会を実施 3. チーム立ち上げに際し以下のガイドラインを設け運用を進める a. チーム・インタラクションマトリクスの整備と運用 b. チーム立上げ〜終了までのサイクルにおけるガイドライン
43. 認知負荷の低い開発体制の構築 チーム・インタラクションマトリクスの整備と運用 チームA チームB コラボレー ション • お互いの専門性を共有しながら、新たな探索 の実施
 • 目的、期限を設け密にコミュニケーションしプ ロジェクトを実施
 
 チーム名 コミュニケーション方法 目的 チームA-チームB コラボレーション ◦◦ チームB-チームC ファシリテーション △△ • コミュニケーションのインタフェースと目的を一 元で管理 • ロギングすると共に、課題認識や振り返りに 活用
44. まとめ

45. まとめ 組織を再組成するには仲間づくりと貢献・成長できる環境づくりの両面が必要 一緒に貢献する仲間を作る活動 ・データエンジニアのリ・デザイン ・採用活動を移譲・効率化し、組織 のことにする 仲間が貢献と・成長出来る環境作り ・キャリアとラダーのデザイン ・認知負荷の低い開発体制の構築
46. まとめ • ようやく組織改善に向けて１歩を踏み出す。しかし、大きな１歩 • 今後は、組織・チームに魂（整合性の取れたルール・運用）を込める ◦ 今回の組織危機で感じた思いと改善への熱量を文化に変える • 仲間が活躍し外部に発信しブランディングを行う。その結果、新たな仲間を呼び込 み、DeNAのデータ活用を発展させる。そのサイクルを作る
47. We are Hiring!!! DeNAではデータ活用の課題を共に解決に導く仲間を募集しています • チームは変革期 • 様々なデータ活用の課題を共に解決しませんか？ DeNA データエンジニア TEAMの紹介ページにアクセス可能です ↓検索はこちら QRコードはこちら