元アナリストがdbtでプロダクトのデータパイプライン構築できるようになった話
この記事は、10Xアドベントカレンダー3日目の記事です！
昨日は@sota1235さんによる、”10XにおけるEngineering Manager”についての記事でした！
個人的にsotaさんとは仕事の絡みは少ないのですが、音楽の趣味が似てるのでオフサイトの度に一方的にウザ絡みしてます話していてとても楽しいです！
また、sotaさんのリーダーとしての考え方は、以下の別記事も素晴らしかったです！
僕は初日の座席指定券を予約してあったので、この後日比谷の映画館まで観に行ってきます！
ちなみに最近のお気に入りスーパーは、長野県のツルヤです。
道民なので、そもそも長野県は空気が肌に馴染む？感じがして好きなのです。
ご当地信州りんごのジュースはもちろん美味しいですが、いつもコーヒー豆を買って帰ります。
同じく長野県・軽井沢の丸山珈琲が、ツルヤだけに卸しているオリジナルのコーヒー豆で、鮮度の高さから焙煎後のガスで袋が膨れていたり、パッケージ自体も機能性が考えられていたり、スーパーで買えるとは思えない専門店の味わいです。
さて、前置きが長くなりました。
最初は簡単な分析やダッシュボード作成からはじまって、dbtの導入、現在はプロダクトで使われるマスタデータの生成など、個人の担当業務だけでもこの2年間は激動だったなー、と思います。
そんな歴史も合わせて、今日は10Xにおいて僕がdbtに触れることになった経緯だったり、並行してどんな仕事をしてきたか、改めてここまでの足跡を振り返ってみようと思います。
さあいこーか🏀
dbtが導入される前の状況
僕は10Xで業務を開始するまで、恥ずかしながらdbtの名前を聴いたことはありませんでした。
それまでのZOZOやヤフーの経験として、中間テーブルの作成やデータパイプラインの構築も、基本的にはエンジニアとタッグを組んで実施することが多く、何ができるのか・どんな嬉しいことがあるのかなど、いまいちピンときていませんでした。
10Xで副業を始めた当時の状況としては、様々な集計や可視化がredashを中心に行われており、分析者が書いたクエリの保存場所も兼ねられている状態でした。
クエリの内容も、生データを参照するベタ書きとなっており、いわゆるおまじないを使い回したレポートやダッシュボードがどんどん生まれていました。
SQL文の共通部分が多いだけでなく、毎回同じ前処理をしているので、処理データ量的にももったいない状態でした。
（僕自身もそのようなクエリを量産していました・・・）
思いを馳せると、まだ立ち上がったばかりの事業において、初動を見たりクイックに検証を回していく必要があることから、このような構造になっていたのだと思います。
また、Stailerはネットスーパーを立ち上げて運用するプラットフォームであることから、一部のダッシュボードを小売側にも提供しています。
そのため、ある小売側の担当者様は、別の企業のデータを閲覧できないようにするなど、権限周りでもいくつかの条件を満たす必要がありました。
したがって要件としては、フロントとなるダッシュボードでセキュリティを担保することはもちろん、裏側の参照先となるデータマートについても切り分けることで、安全側に倒す必要がありました。
当時運用しているパートナー小売企業は、まだ片手で数えるほどであったことから、一部テーブルについてはDigdagを用いて、企業別に中間テーブルを生成している状態でした。
このように、データ周りの課題は当然認識されており、将来的に数十というパートナー小売企業のデータを横断的かつ安全に扱うために、ダッシュボード・データマートなどの仕組みを新しく考える必要がありました。
僕は当時の役割的に、データアナリストバックグラウンドだったこともあって、分析レポートやダッシュボード作成を中心に作業するのかな？と呑気に考えていました。
しかし蓋を開けてみれば、これらの仕事をこなしていくのは勿論、社内のデータマート整備にも一定コミットする必要があることがわかってきました。
例えば作業において、ダッシュボードにあるSQL文を修正する際に、各クエリのおまじない部分も全てを変更しなくてはならないことは、とても面倒です。
そのため、生データからある程度共通の前処理を施した上で、集計向けに使いやすく加工された、中間テーブルが欲しい！と真っ先に思い当たりました。
これは最近アナリスト専業の@ktrruさんとも話していたことですが、たとえデータ関連の職種であってもドメイン知識は大切であることから、ネットスーパーの分析をしたことがない状態でデータマートを1から作るのも難しそうで、「分析をしながらダッシュボードも作り、裏側でデータマートも整えていく」という役割は、一見広範のように見えて近道なのかもしれません。
dbtの導入初期
おめーのヘマはもともと計算に入れてる…つっただろ ど素人
2020年のクリスマスイブ、恐らく10Xではじめて”dbt”というワードが投稿されました。
・生データをdbtで処理してデータマートを生成すること
・前処理を施すことで各パートナー小売企業への横展開に向けた工数を下げること
などについて言及いただいています。
はじめは「dbtなにそれ？」状態だったのですが、@takimoさん自身がディープダイブの上で社内でも丁寧なレクチャー会を開いてくれたり、ドキュメントを整備してくれたおかげで、徐々にキャッチアップすることが出来ていきました。
ポジションはどこでもやれます！！
なぜオレはあんなムダな時間を…
redashにベタ書きされていたとあるクエリについて、dbtを使って中間テーブルを参照するようになった結果、なんと処理時間とデータ量が1/5に！🎊
僕も例に漏れず、ダッシュボードの裏側にあるデータマート構築の一環として、dbtを触り始めていました。
一例ですが、ダッシュボードのクエリに直接処理を書いてしまっている状態は、将来的なメンテナンスコストが高くなりそうだったため、dbt側で最終的なレポートまでのデータマートを生成し、フロントでは するだけの方針で実装していました。
ゆっくりでもいい！！自分の力でやり遂げろ！！
@takimoさんに泣きつきながら、悪戦苦闘している当時の僕の様子。
（素人の僕が作ったデータマートなど、見る影もなくなった模様・・・）
ただ、この頃から現在のマスタデータ生成につながるような、プロダクト用途でもdbt使えるかも？という話は出始めていていました。
dbtを使ってBigQueryに生成したテーブルについて、dart側でインポートしてもらうことができれば、プロダクトにデータを利活用することもできるのではないか？と。
オレ…なんか上手くなってきた…
2021年3月、社内の分析とプロダクトそれぞれの用途で、どうしたらdbtを活用できそうか？を副業の3人で話している筆跡。
マスタデータ生成への適用
10Xにおけるdbt活用がさらに進んだのは、 2021年5月頃のこと。
その頃の状況としては、とあるパートナー小売企業に向けた開発が進んでおり、ネットスーパーの売り場を生成するための商品マスタデータの生成が課題となっていました。
商品名・売価・在庫数のようなデータについて、小売側の基幹システムなどから受領する元データはあるものの、これをネットスーパー用に加工する工数が膨大となっており、さらにそれを最も貴重なロールと言っても過言ではない、エンジニアの皆さんが担っている状態でした。
そうすることで、分析経験者のようにSQLが使える人材であれば、ネットスーパーのマスタデータ生成ロジックを実装することができたり、BizDevのようにプログラミングが専門でない方であっても、例えば「どういう場合にセール価格を反映させるのか？」のような条件分岐がキャッチアップしやすくなりました。
また、その後のローンチに向けてロジックを詰めなければならないパートナー小売企業が続々と控えていたこともあり、「何を決める必要があって、どのデータをどんな粒度で受領することができれば良いのか？」のようなチェックリストを作成することで、スムーズに開発着手ができました。
プレイヤーとしての奴はクールとは程遠いぜ
驚くべきは、この動きをご自身の入社選考であるトライアルでこなしてしまっているところ。
僕自身としても、当時のチーム内での業務の組み換えもあって、このようなマスタデータ生成のパイプライン構築にチャレンジし始めていました。
冒頭言及したように、過去にはあくまで”CRM施策のためにMLOpsエンジニアと協業する”のような形でしたが、SQLを納品しながらデータパイプライン構築に関わることもあったり、dbtを使った作業もSQLとgitとGUIでほぼ完結することから、仕事内容にあまりギャップは感じませんでした。
何よりも、同時期に複数のパートナー小売企業向けの開発をしなければいけないことから、とにかく作業をこなしつつ、色々とやりながら体で覚えていきました。
このチームは…最高だ…
ちょうど去年の同日付・12月3日、その後のローンチラッシュに向けてMTGする、BizDevの@_yuki_yさんと@nkatsuyaさん、Growthの@ktrruさんと僕。
BizDevのお二人はデータへの解像度が非常に高く、他職種ながらAs One Teamで仕事することが出来てます。
ちなみに12月で寒かったのか、偶然全員がお揃いで黒フリースを着用しています。
大した経歴も無い人間なので、ブランチを切ってコミットする、PRを出してレビューをもらう、QAをした上でマージする・・・など、いわゆる開発っぽい仕事のやり方については、キャッチアップしながら進めてました。
また、dbtからgitを使った開発まで、なにせ本当にわからない事だらけだったので、自分自身の学習や他の業務委託メンバーの受け入れがてら、ドキュメントや導線を作りまくりました。
ドリブルこそチビの生きる道なんだよ！！
自らの備忘も兼ねて作成した、ドキュメントたちの一部抜粋。
前パートでのデータマート作成と、プロダクトで使われるマスタデータ生成において、個人的に感じる一番の違いとしては、品質に対する責任感だと思います。
例えば、社内の可視化用途で用いられるデータマートであれば、細かい数字の揺らぎやログの欠損は怖いものの、その修正が1分1秒を争うような事態はあまり発生しにくいです。
一方で、マスタデータはパートナー小売企業が商いをする・エンドユーザーが買い物をするプロダクトに直接的に結びついていることから、万が一障害が起きるとその影響が瞬時に広がってしまい、はじめはビクビクしていました。
いま振り返ってみると、プロダクトの仕組み的にいくつものフェールセーフが設けられていることから、無駄な心配だったことも多かったですが。
とはいえ、責任感はやりがいの裏返しでもあるので、自分自身が構築したロジックや生成したデータが、プロダクトにインポートされてアプリの売り場に表示される瞬間は、興奮のあまり毎回「うおおおおお」のスタンプを押さざるを得ません。
この音が…オレを甦らせる。何度でもよ
社内においても連携する職種が幅広く、色々な人と話せたり、小売側の担当者様とも直接関わったり、スーパーの現場にも行く機会もどんどん増えました。
このような心境の変化だったり、仕事がどんどん楽しくなっていく様子などは、以下の記事でも書きました。
今後の展望など
そんなこんなで、色々なパートナー小売企業のネットスーパー立ち上げに向けて、マスタデータ生成のパイプライン構築を始めたわけですが、段々と次なる壁も見えてきました。
例えば、ロジックやパイプラインの仕組みが属人的になってしまっていたり、SQLを書く作業のような労働集約のプロセスの重たさだったり。
これらを解決するために、10Xにおけるマスタデータの取り扱いを中心とした、プロダクトに使われるデータと生成プロセスに対して責任を持つ、データプロダクト部がグロース本部配下にて爆誕し、恐れ多くも僕が部長を仰せつかりました。
会社にマトリクス組織が導入された背景もあり、チームとして独立したことも受けて、目の前のローンチや運用だけでなく、今後起こり得る未来を想像しながら、より集中して先手を打つ動きが取れるようになったと思っています。
その一手として、ローンチを何周かこなした上で一層抽象化された新アーキテクチャの実装だったり、開発プロセスや組織体制の再構築など、様々な取り組みを並行して進めています。
結びに
まだ何かを成し遂げたわけじゃない。 なぜこんなことを思い出している バカめ
本記事では、僕自身が10Xで遭遇してきた事象を交えながら、dbtを使ってプロダクトのデータパイプライン構築するようになるまでをご紹介しました。
僕たちグロース本部・データプロダクト部では、現在2つの職種をオープンにしています。
詳しくは下記JDをご覧いただいた上で、少しでもご興味がある方は、お気軽にお声がけください！
データプロダクトエンジニア / 株式会社10X
株式会社10Xはデータプロダクトエンジニアを採用しています。
https://open.talentio.com/r/1/c/10x/pages/68636
また来週12月7日(水)には、前記事の”データ人材が初めてネットスーパーの現場に行ってみた話”のきっかけとなった、マブダチOperations Manager@tsukui7さんと仲良しBizDev@nkatsuyaさんと一緒に、オンラインイベントを開催します。
本記事で言及したような業務内容に限らず、幅広い職種の方に興味を持っていただけるようなコンテンツを考えてますので、ぜひ遊びにきてください！
ネットスーパーの立ち上げや事業成長のために、多種多様なデータが使われていることや、あらゆる専門性が必要であることが御理解いただけるはずです！
要チェックや！！🏀