このエントリーは、2022年6月に開催された「Engineers in CARTA vol.3 #データエンジニアリング」の中で、株式会社Zucks アドプロダクト事業本部の 近森 淳平 ( @pei0804 )がセッションした
「データをモデリングしていたら、組織をモデリングし始めた話」の書き起こし記事となります。
資料はこちら
データをモデリングしていたら、組織をモデリングし始めた話
近森 淳平：『データをモデリングしていたら、組織をモデリングし始めた話』という題でお話ししていきたいと思います。今日は、データと向き合っている1人のエンジニアとしての事例を紹介します。
ちなみに私の所属している Zucks について、大事にしていることや考え方は「The Zen of Zucks」というものにまとめています。面白いのでぜひ読んでみてください。
最初はデータの仕事をやっていなかった。気づいたら、やっていた
まず、これまでデータとどのように向き合ってきたかという話をします。最初はデータの仕事はやっていませんでした。データに関連する仕事をやり始めた時も、実は途中まではデータの仕事だと思っておらず、気づいたらやっていたという感じです。
入社して最初はレコメンドエンジンを開発していました。その後開発を続けながら、AWS セキュリティ周りの基盤構築したり、細かなリファクタリングをしたり、バッチ基盤構築をやったり、ネットワーク構成回りを見直してひたすら terraform import をしまくったり、可用性向上をさせたり。それから IaC のポリシーがちゃんと考えられていないところがあったので作成したりしていました。
現在は、CARTA HOLDINGS の Zucks で DSP の広告レポート基盤の構築運用をやっています。ここからデータの仕事が始まりました。
その中で解決したかったのは、レポーティング機能の扱いづらさでした。
しかし、ここには2つの大きな課題がありました。モデリングの不適切さ、アーキテクチャの不適切さです。簡単に言うと、どちらも分析を想定した構造になっていなくて大変でした。
モデリングの不適切さはスタースキーマで解消
「モデリングが不適切」としてよくあるのが、ビジネスプロセスがモデリングされていないというものです。
例えば小売店だったら商品を購入したとか、入荷したとか、そういう1つ1つのビジネスプロセスです。 Zucks だとクリック、インプレッション、コンバージョンと呼ばれるようなものです。これが上手くモデリングされておらず、都度クエリするたびに頑張っている状態でした。加えてこういうことがしたいというアドホックな対応が積み上がって、このまま適当な対応をしていくとレポート業務で身動きが取れなくなっていきそうでした。
他にも、数字がずれたり、画面によって数字が違うけど、理由はわからん、となってしまったり。amountというカラムがあるけれど、Typeというカラムによって文脈が変わるらしい、みたいなことがありました。
例えば辛い SQL の話で言うと、
SELECT id, amount FROM score
となっていて、WHERE score_type = 1にするという感じなのですが、
id,amount？ってなに？socre_type = 1ってなに？- そもそも
scoreってなに？ WHEREなしだと、そもそも何が返ってくるの？
というものがありました。こういうのは認知負荷が高いんですよね。積み重なっていくと、どんどんつらくなってしまう。
どうやって対応したかというと、伝統的な手法として「ディメンションモデリング」というものがあるんですが、その中のスタースキーマを適用しました。
アドテクのデータは非常に大量です。ログの種類によっては、1日に7億+-くらいは発生します。多種多様なファクトとディメンションが発生するため、場当たり的に対応していると簡単に秩序が崩壊します。
スタースキーマを使うことによって秩序を維持しつつ、ストレージを効率的に扱えるようになりました。アドテクに対するモデリングでは、スタースキーマはマッチしていたと思います。
スタースキーマ適用後の世界は、簡単言うと
SELECT id, amount FROM score WHERE score_type = 1
↓
SELECT click_id,click_amount FROM clicks
となり、シンプルでわかりやすくなりました。
アーキテクチャの不適切はラムダアーキテクチャで解消
「アーキテクチャが不適切」というのもありました。
データによって求められている要件が色々ありますが、大きく分けると、即時性が大事なパターンと、確実性が大事というパターンがあります。しかし、関係なく全てスピードレイヤーで構築されていました。全てストリーム処理でやっていたのですが、調べてみると深い理由はなく、なんとなく最初に作ったものの横に生やしたような状態でした。結果、再集計の時の複雑性だけ上がっていて、何が嬉しいのかわからなくなっていました。
またデータの集計の仕組みで、例えば cron が14時になったらこれが走って、14時20分になったらこれが走って、14時40分になるとこれが走るみたいなものがありました。じゃあ、処理が重くて15時回ってしまった場合はどうするの？と。再処理するにはどうすればいいかというと、職人のように1個1個バッチの処理を頑張ってバックフィリングするしかありませんでした。
これに対しての解決策として、伝統的な方法の「ラムダアーキテクチャ」を採用しました。これはスピードレイヤー、バッチレイヤーのそれぞれやりたいことに対して合わせて使えます。
また「ワークフローエンジン」を使うことで、再集計やデータの流れの把握が簡単になりました。
出来上がったアーキテクチャは以下です。
運用してみて
これを1年程度運用してみたところ、以下のようになりました。
- モデリングは破綻しなかった
- 集計レイヤーを dbt でやりたくなった
- DataOps が必要になった
- データに関する知識が社内で広まってきた
- 社内のデータ課題に気づくようになった
モデリングは破綻しなかった
「モデリングが破綻しなかった」とはどういうことかというと、
- 新しい軸（ディメンション）を増やせる
- 新しい指標（ファクト）を増やせる
- 色んなデータを横断して見れる
- 数字がズレない
ということです。途中の集計方法や見せ方の微調整はありつつも、壊れることはなかったので良かったです。
やっていくうちにわかったのは、スタースキーマが出た当時と現在では若干文脈が違うということです。
出た当時、ストレージは非常に高価なものでした。しかし、現在は無限に近いストレージを安価で扱えるようになりました。
その結果、スタースキーマのメリットの一つであったストレージ最適化は、当時ほどのメリットを持たなくなり、故にそのメリットを意識した設計手法も、今となってはリッチすぎる実装になりえるのです。そうなると、スタースキーマの良いプラクティスが若干変わってきます。
例えば、 Slow Changing Dimension は、現代だと Dimension snapshot で十分であるとか。
また、 Unified Star Schema のようなBIツールを意識したモデリングも、当時は複合的な使い方は難しかったと思いますが今は全然できます。現代でも有効かどうかはちゃんとキャッチアップしていく必要があります。
集計レイヤーを dbt でやりたくなった
そもそも dbt とは何かを説明すると、Rawデータの変換ELTに使います。Rawデータがちゃんと揃っていることが前提なんですが、 SELECT を書くだけで普段やっている様々な面倒をやってくれます。
一番重要であるモデリングに注力できるのがすごく嬉しいところです。
今は集計レイヤーのELT処理をするとき SQL ベースでやっていますが、ワークフローエンジンを作る際に、実行する SQL を意識しながら実装していくことがとても大変なんです。
そこで、ELT部分を良い感じにできそうだということでdbtを触り始めたら、実はやりたかったことが全て詰まっていそうでした。現在はだいたい置き換えることができたので、あとは運用をどうやって回すのかを検討しています。
dbt 気になっている方は一定数いるのではないかと思いますが、読んで理解するよりとりあえず触ってみた方がよくわかるので、触ってみると良いと思います。
DataOps が必要になった
レポート機能を提供しているのですが、どこまで集計されているのか？が気になるわけです。
その時に、データは確かに揃っているものの、バッチがどこまで集計したかという情報は別なので、やはりそれ用のデータが欲しいとなり、メタデータを提供することになりました。そうすることで集計レイヤーが正しく動いてるかの監視にも活用することができて便利でした。
今後メタデータのニーズは高まるはずなので、適宜検討して拡充しています。
データに関する知識が社内で広まってきた
ここ1年、データに関する知識が社内に広まっている実感が広まっている実感があまります。
「ファクト」「ディメンション」「バックフィリング」「ファントラップ」「スタースキーマ」などのデータの用語が、当たり前のように社内で出てくるようになりました。
社内の Slack でも飛び交い、共通言語ができたことで、とても会話が楽になりました。
社内のデータ課題に気づくようになった
こういった仕事をしているとデータに関する相談に乗ることも増えたのですが、物理的に全て解決できるわけではないので、社内に相談窓口を設けた方が良いんじゃないかというのを模索中です。
これからやっていきたいこと
これまで2年間何をやってきたかを話しました。次に、これからやっていきたいことについても話したいと思います。
やりたいこととしては、「イネイブリングチームを試す」ことと「機械学習向けのデータプラットフォームを構築する」ことをやりたいと考えています。
イネイブリングチームを試す
イネイブリングチームとは、「チームトポロジー」という本にも出てくるものですが、簡単に言うと組織構造のままアーキテクチャが作られる「コンウェイの法則」*1というのがあるのですが、それをうまく利用することでチームのパフォーマンスを上げたり、アプリケーション開発に活かしていこうということが書いてあります。
イネイブリングチームの仕事は、特定のドメイン、自分の場合はデータのところの知識を、アプリケーション開発しているチームで必要なギャップを埋めてあげることです。
チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計
著者／訳者：マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎
出版社：日本能率協会マネジメントセンター
私の感じている課題感は、データのアプローチは ユースケースによっても、組織の構造によっても、やりたいことが全然変わってくる ので、判断が難しいということです。
普段勉強している人からすると「やるだけ」なのですが、アプリケーション開発している人からすると、データの仕事は非常に認知負荷が高いです。業務システムを作る流れでやってしまうと上手くいかず、事前に知っていれば苦労せずに済んだという例が結構あります。
最もよくあるのが「分析向けモデリング」が用いられていないことです。一度、テーブルが可哀そうなことになってしまうと直すのが大変なんです。モデリングさえどうにかなっていればいいので、ここの方法論さえ知っていれば良かったということが結構あります。
なぜその課題に対してイネイブリングチームが良いと思っているかというと、継続的な依存関係を作るのではなく、チームの自走をサポートすることに魅力を感じたからです。
データ活用にはそれぞれの抱えている課題に対して深い理解をする必要があり、データを扱えること自体はデータ活用に繋がるわけではありません。あくまでそのチームがデータをコントロールできるようにして、そのデータを使って課題解決できることが重要なので、ここまでを助けるのがイネイブリングチームであり、まさに私のやりたいことです。
How の部分についてはある程度決まったやり方があり、そこの調査で疲弊してしまうのは本当にもったいないので、助けられたらなと思います。
イネイブリングチームにまでしなくてもいいんじゃない？ という意見もあるかもしれません。しかし、聞けばいい人たちを構造化することで、誰に聞けばいいかわかるようになるので、私はこうした方がいいと考えています。
つまり魚を与えるのではなく、魚の釣り方を教えるということが大事なのだと思います。
機械学習向けのデータプラットフォームを構築する
やりたいことのもう1つは「機械学習向けのデータプラットフォームを構築する」ことですが、弊社には機械学習チームとアプリケーションチームがそれぞれあります。（厳密にはそう呼ばれていませんが、一般的に分けるとこのようになります）
ただお互いにやっている技術領域が違いすぎることから、コミュニケーションが薄くなりがちで、サイロ化*2が起きてしまっていました。
「そこは相談してくれればすぐできたのに」と思うことが多々あります。そこで双方がコミュニケーションしましょうとなるわけですが、1か月後には全く継続されていない状態になりがちです。現状の組織構造が、自然なコミュニケーションが生まれる構造ではないわけです。
これはチームトポロジーの本にも書いてあるのですが、組織のコミュニケーションは組織図で決まるということです。組織の枠を超えて聞きに行くことができる人もいるが、そうではない人もいるので再現性がないんですよね。
コミュニケーションを取ることはムーブであって仕組みではない。じゃあコミュニケーションした方がいいなら、そういう構造にしようと考えるけれど、不必要なチーム統合はオーバーヘッドを生んでしまうので、ちゃんと考える必要があります。
自然な形で協調するには「それぞれの得意分野で協調する」必要があります。
弊社の場合、簡単言うと機械学習チームのエンジニアはビジネスと垂直統合された問題へ取り組むことが得意です。例えば、あるプロセスの最適化や進め方の再構築などです。
一方、アプリケーションエンジニアは、抽象化や一般化を用いて業務効率を上げるのが得意です。つまり、水平方向の仕事でインパクトを発揮します。必ずしも全員に当てはまるわけではないですが、こういう性質を持った人が多いと思います。
これをうまく使うと、水平・垂直でコラボできるんじゃないかと思いました。
データサイエンスエンジニアの成果を出すサイクルを高速にするをやりたく、ソフトウェアエンジニアがデータチームに入る形になった時に、データサイエンスエンジニアが普段使う道具を作る。データサイエンスエンジニアにとってはこれまで通り働くが、使う道具がすごく便利になります。
ソフトウェアエンジニアは自分の得意領域なのでオーナーシップを持って仕事しているし、データサイエンスエンジニアも同じです。お互いがコア部分に集中して、高速で課題解決をすることができます。
コラボレーションさせる狙いとしては、サイロ化を防ぎたいからで、今まではデータを用意した先はお任せという状態だったので、コミュニケーションが発生しにくい構造でした。
狙ってそうなっているならそれで良いのですが、「コミュニケーションしましょう」という意見が出てくるということは、話した方がいいということです。データプラットフォームというコミュニケーションパスを作ることで、構造的にコミュニケーションを可能にするということをやった方が良いんじゃないかと。こうすることで、「聞いてくれたらすぐ終わったのに…」というのが無くなります。
具体的な戦略はこれからなのですが、基本的には垂直・水平でコラボしましょうということで進める予定です。
ということで、最初はデータモデリングをしていたのですが、気づいたら組織をモデリングしていたという話でした。
ちなみに朗報ですが、弊社はエンジニア採用をしているので、このような面白い組織を創っていくことに興味がある方は、ぜひお話ししましょう。
以上となります！
最初はデータの仕事をやっていなかった近森が、色々な整備していった結果、組織の構造にまで着手していった話でした。
