Slide 1
Slide 1 text
データをモデリングしていたら、
組織をモデリングし始めた話
近森淳平 @pei0804
CARTA HOLDINGS （旧VOYAGE GROUP） Zucks アドプロダクト事業本部
ソフトウェアエンジニア x データ in Real world
Slide 2
Slide 2 text
今日はデータと向き合ってる
1人のエンジニアの事例を紹介します。
Slide 3
Slide 3 text
アジェンダ
● 自己紹介
● これまで
○ データの仕事のはじまり
○ 1年運用してどうだったか
● これから
○ イネイブリングチーム
○ 機械学習チームのサイロ化の解決
Slide 4
Slide 4 text
アジェンダ
● 自己紹介
● これまで
○ データの仕事のはじまり
○ 1年運用してどうだったか
● これから
○ イネイブリングチーム
○ 機械学習チームのサイロ化の解決
Slide 5
Slide 5 text
自己紹介
ぺい
@pei0804
近森淳平(チカモリ ジュンペイ)
CARTA HOLDINGS （旧VOYAGE GROUP）
Zucks アドプロダクト事業本部 エンジニア
Slide 6
Slide 6 text
techblog.cartaholdings.co.jp, The Zen of Zucks, 2022/06/10, https://techblog.cartaholdings.co.jp/entry/the-zen-of-zucks
Slide 7
Slide 7 text
アジェンダ
● 自己紹介
● これまで
○ データの仕事のはじまり
○ 1年運用してどうだったか
● これから
○ イネイブリングチーム
○ 機械学習チームのサイロ化の解決
Slide 8
Slide 8 text
最初はデータの仕事をやってなかった。
気づいたら、やっていた。
Slide 9
Slide 9 text
大まかな過去のお仕事（時系列）
1. レコメンドエンジンの開発
2. AWSセキュリティ基盤構築
3. バッチ基盤構築
4. ネットワーク構築と可用性向上
5. IaCのポリシー策定
Slide 10
Slide 10 text
現在やってること
Zucksが開発している
DSP（Demand Side Platform）の
広告レポート基盤の構築・運用。
ここから、データの仕事が始まった。
この仕事から、データエンジニアっぽい
仕事が始まった。
Slide 11
Slide 11 text
解決したかったのは、
レポーティング機能の扱いづらさ。
Slide 12
Slide 12 text
2つの大きな課題
● モデリングが不適切
● アーキテクチャの不適切
どちらも分析システムに適した構造になっていなかった。
Slide 13
Slide 13 text
モデリングが不適切
Slide 14
Slide 14 text
モデリングが不適切なことによる難しさ
● ビジネスプロセスがモデリングされてないため、
同じ事実を色んな箇所で、都度クエリで表現してある。
● アドホックな対応が積み上がり、
レポートのちょっとした変更が出来ない。
● 数字がズレた。なぜかは分からない。
● amountというカラムがTypeによって文脈が変わる。
Slide 15
Slide 15 text
辛いモデリングのSQL例
SELECT id, amount FROM score WHERE score_type = 1
● id, amount？ってなに
● score_type = 1ってなに？
● scoreってなに？
● WHEREなしだと、何が返ってくるの？
認知負荷が高いテーブルが積み重なって、どんどん辛くなる。
Slide 16
Slide 16 text
解決策
スタースキーマ（ディメンションモデリング）の適用。
アドテクのデータは、非常に大量のレコードが発生する。
ログの種類によっては、1日に7億+-程度発生する。
また、多種多様なファクトとディメンションが発生するため、
場当たり的に対応していると、簡単に崩壊する。
そこで、秩序を維持しつつ、ストレージを効率的に扱える
ディメンションモデリングが非常にマッチしていた。
Slide 17
Slide 17 text
スタースキーマ適用後の世界
SELECT id, amount FROM score WHERE score_type = 1
↓
SELECT click_id, click_amount FROM clicks
シンプルで分かりやすくなったね👍
Slide 18
Slide 18 text
アーキテクチャの不適切
Slide 19
Slide 19 text
アーキテクチャが不適切なことによる難しさ
● 即時性、確実性関係なく全てスピードレイヤーで構築されていた。
全てがストリーム処理である妥当性は低く。
再集計の時の複雑性が上がっていた。
● データの集計の仕組みが、cronによるバッチ処理で実現されているた
め、バッチの処理のコントロールが職人芸。
Slide 20
Slide 20 text
解決策
ラムダアーキテクチャの採用
スピードレイヤーとバッチレイヤーをユースケースに合わせて分ける。
それぞれ求められる要件に合わせた設計を、行えるようにした。
ワークフローエンジンの採用
データの流れ通りにワークフローを組めるようにした。
これにより、再集計やデータの流れの把握が簡単になった。
Slide 21
Slide 21 text
アーキテクチャ
Slide 22
Slide 22 text
1年程度運用してどうだったか
Slide 23
Slide 23 text
1年運用してみて
● モデリングは破綻しなかった
● 集計レイヤーをdbtでやりたくなった
● DataOpsが必要になった
● データに関する知識が社内で広まってきた
● 社内のデータ課題に気づくようになった
Slide 24
Slide 24 text
モデリングは破綻しなかった
Slide 25
Slide 25 text
モデリングが破綻しなかった
● 新しい軸（ディメンション）を増やせる。
● 新しい指標（ファクト）を増やせる。
● 色んなデータを横断して見れる。
● 数字がズレない。
途中の集計方法や、見せ方の微調整はありつつも、
コアコンセプトはズレずにやってこれた。
Slide 26
Slide 26 text
令和のスタースキーマ
スタースキーマが考えられた頃と現代だと、
若干良いプラクティスが変わっている。
例えば、Slow Changing Dimensionは、
現代だとDimension snapshotで十分であるとか。
Unified Star SchemaのようなBIツールを意識したモデリングなど。
現代向けに知識をアップデートする必要がある。
Slide 27
Slide 27 text
dbtを使いたくなった
Slide 28
Slide 28 text
dbtとは
Rawデータの変換ELTに使う。
SELECTを書くだけで、様々な面倒を見てくれるので、
一番重要であるデータモデリングに注力できるので、とても良い。
www.getdbt.com,What, exactly, is dbt?,2022/06/10,https://www.getdbt.com/blog/what-exactly-is-dbt/
Slide 29
Slide 29 text
dbtを使いたくなった
集計レイヤーのELT処理を構築する際に、
ワークフローエンジンとSQLを実行するスクリプトを、
それぞれ意識しながら実装する負荷が高かった。
そこで、ELT部分をいい感じに出来そうなdbtを触り始めた。
触ってみたところ、置き換えれるのはもちろん、やりたいことを
素直に実装できるdbtはとてもマッチしていたため、
集計レイヤーの置き換えに向けて準備中。
dbt気になってる人向けに一言。
読んで理解するより、とりあえず、触ればいいと思います。
Slide 30
Slide 30 text
DataOpsが必要になった
Slide 31
Slide 31 text
DataOpsが必要になった。
レポート機能で、どこまで集計されているか？が知りたくなったので、
メタデータを提供することになった。
レポート画面的にも必要なデータだったけど、
集計レイヤーが正しく動いてそうか？の監視にも活用できた。
今後、データ活用が進めば、メタデータのニーズが高まるはずなので、
適宜検討し拡充していく。
Slide 32
Slide 32 text
データに関する知識が社内で広まってきた
Slide 33
Slide 33 text
データに関する知識が社内で広まってきた
● ファクト
● ディメンション
● バックフィリング
● ファントラップ
● スタースキーマ
● etc…
データ系の用語が、当たり前のように使われるようになった。
共通言語があることで、本当に会話が楽になった。
Slide 34
Slide 34 text
社内のデータ課題に気づくようになった
Slide 35
Slide 35 text
社内のデータ課題に気づくようになった
これまで目につかなかった課題が、目につくようになった。
しかし、物理的に１人で全てを解決出来る訳もないので、
データ相談窓口的なものを、設けることができないか模索中。
Slide 36
Slide 36 text
アジェンダ
● 自己紹介
● これまで
○ データの仕事のはじまり
○ 1年運用してどうだったか
● これから
○ イネイブリングチーム
○ 機械学習チームのサイロ化の解決
Slide 37
Slide 37 text
これから
● イネイブリングチームを試す。
● 機械学習向けのデータプラットフォームを構築する。
Slide 38
Slide 38 text
イネイブリングチームを試す
Slide 39
Slide 39 text
No content
Slide 40
Slide 40 text
チームトポロジーとは
高速なデリバリーを実現することを目的とした、
4つの基本的なチームタイプと3つのインタラクションパターンに基づく、
組織設計とチームインタラクションのための実践的な適応モデルを紹介する。
これは、ソフトウェアの組織設計における大きな前進であり、
チームの相互作用と相互関係を明確に定義した方法を提示することで、
チーム間の問題を組織の自己運営のための貴重なシグナルに変え、
結果として得られるソフトウェアアーキテクチャを
より明確で持続可能なものにする。
amazon.co.jp商品ページ,チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計
,2022/06/10
Slide 41
Slide 41 text
イネイブリングチームとは
特定のテクニカル（プロダクト）ドメインのスペシャリストから構成され、能力ギャップ
を埋めるのを助ける。
マシュー・スケルトン (著), マニュエル・パイス (著), 原田 騎郎 (翻訳), 他 日本能率協会マネジメントセンター
チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 , 105P, 2022
今日は、チームトポロジーについては、詳しく話しません。
Slide 42
Slide 42 text
感じている課題感
データへのアプローチは、多岐に渡っていて、
普段アプリケーションの開発をしているエンジニアにとって、
データの仕事は、認知負荷が非常に高い。
また、知っていれば苦労せずに済んだ・・・という例も少なくない。
最もよくあるのが分析向けモデリングが用いられていない。
こういうのは、方法論さえ知っていれば苦しまずに済んだ問題。
Slide 43
Slide 43 text
なぜイネイブリングチームなのか
継続的な依存関係を作るのではなく、
チームの自走をサポートすることに魅力を感じた。
データ活用には、それぞれの抱えてる課題に対して、
深い理解が必要であり、データを扱えることが、データ活用に繋がるわけではない。
あくまで、そのチームが主導で動けることが重要だと考えている。
しかし、HOWの部分は、ある程度決まったやり方があるので、
そこの調査で苦労するのではなく、もっとやりたいことを考えてほしい。
そこでイネイブリングチームがちょうど良いのでは？と考えた。
また、聞けばいい人たちを構造化することで、迷える人達の視界に入るようにする。
Slide 44
Slide 44 text
魚を与えるのではなく、
魚の釣り方を教える。
Slide 45
Slide 45 text
機械学習向けの
データプラットフォームを構築する。
Slide 46
Slide 46 text
機械学習チームとアプリケーションチームの
サイロ化問題。
機械学習チーム
データサイエンスエンジニアと呼ばれるエンジニアが属している。
アプリケーションチーム
ソフトウェアエンジニアと呼ばれるエンジニアが属している。
お互いにやっている技術領域が違いすぎるため、
コミュニケーションが希薄なまま、今日までやってきてしまった。
それによって、サイロ化が起きている。
「そこは、話せばすぐだったのに・・・」は少なくない。
Slide 47
Slide 47 text
サイロ化とは
業務プロセスや業務アプリケーション、各種システムが孤立し、
情報が連携されていない様子を指します。サイロ化する理由としては、
企業内の各部門が個別最適でシステムを構築し、
他部門のシステムとの連携が考慮されずに
開発されてしまうことなどが挙げられます。
www.ntt.com,サイロとは？意味・定義,
https://www.ntt.com/bizon/glossary/j-s/silo.html, 2022/06/10
Slide 48
Slide 48 text
「コミュニケーションしましょう」
1ヶ月後の継続率0%
Slide 49
Slide 49 text
現状の組織構造が、
自然なコミュニケーションが
生まれる構造ではない。
Slide 50
Slide 50 text
組織のコミュニケーションは、組織図で決まる
組織図を額面どおりに受け取ってしまうと、
人間をソフトウェアのように設計し、コミュニケーションをきっちりと決められた
枠の中に収めようとする。だが、人間は組織図の線で
つながっている人たちだけとコミュニケーションするわけではない。
仕事を終わらせるのに必要な相手であれば、誰とでも連絡を取る。
マシュー・スケルトン (著), マニュエル・パイス (著), 原田 騎郎 (翻訳), 他 日本能率協会マネジメントセンター
チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計, 4P, 2022
Slide 51
Slide 51 text
コミュニケーションした方がいいなら、
そういう構造にしよう。
Slide 52
Slide 52 text
しかし、不必要なチーム統合は、
オーバーヘッドを生む。
Slide 53
Slide 53 text
自然な形で協調するには、
どうすればいい？
Slide 54
Slide 54 text
それぞれの得意分野で協調する。
Slide 55
Slide 55 text
それぞれの得意分野で協調する
● 機械学習チームのエンジニア（データサイエンスエンジニア）
○ ビジネスと垂直統合された問題へ取り組むことが得意。
例えば、あるプロセスの最適化や進め方の再構築をする。
● アプリケーションチームのエンジニア（ソフトウェアエンジニア）
○ 抽象化、一般化を用いて、業務効率化が得意。
つまり、水平方向の仕事でインパクトを発揮する。
必ずしも、全員に当てはまるわけではないけど、
こういう性質を持った人が居るという話。
Slide 56
Slide 56 text
水平・垂直でコラボする。
Slide 57
Slide 57 text
データサイエンスエンジニアの
成果を出すサイクルを高速にする。
Slide 58
Slide 58 text
成果が出るまでのサイクルを高速にする
● ソフトウェアエンジニア
○ データサイエンスエンジニアが使う道具を作る。
● データサイエンスエンジニア
○ これまで通りに働く
with ソフトウェアエンジニアが作った道具。
ソフトウェアエンジニアが、データプラットフォームを作る。
データサイエンスエンジニアは、そのプラットフォームで、
コア部分に集中して、高速で課題解決する。
Slide 59
Slide 59 text
コラボレーションさせる狙い
データを用意してから先の業務は、おまかせ！だったので、
コミュニケーションが発生しにくい構造だった。
データプラットフォームというコミュニケーションパスを作ることで、
構造的にコミュニケーション可能にすることで、
これまであった「聞いてくれたらすぐ終わったのに」を未然に防ぐ。
Slide 60
Slide 60 text
具体的な戦略は、これから・・・！
Slide 61
Slide 61 text
気がついたら、
組織をモデリングし始めていた。
Slide 62
Slide 62 text
まとめ
Slide 63
Slide 63 text
朗報です。
実はエンジニア採用してます。
Slide 64
Slide 64 text
https://engineering.cartaholdings.co.jp/