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