ボッチLookML開発者兼データ整備人を連れてきたよ！

ボッチLookML開発者兼データ整備人を連れてきたよ！〜２年間の悩みと知見？〜 2022-02-04 FFTT#469 @masutaka

自己紹介 • 増田貴士（@masutaka） • 株式会社フィードフォース Feedmatic 所属 • 前回のFFTT#441から引き続き、個人メインPCは Manjaro
(Linux) • 最近ようやく重い腰を上げて、証券口座を作ったり、仮想通貨を購入して手触り（？）を確かめたりしている https://www.feedforce.jp/  

今日のお話の立ち位置 • 2000年4月〜2011年3月 ◦ 組み込みエンジニアとして、某社レーザープリンターのファームウェア開発や保守に携わる • 2011年4月〜2020年3月 ◦ ウェブエンジニアとして、某オンライン英会話の予約サービスや、Feedforce各種サービスの開発や運用に携わる
• 2020年4月〜 ←今日のお話 ◦ データアーキテクト（データ整備人）やBIエンジニア（LookML開発者）として、Feedmatic （フィードフォースのコンサルティング型広告代理店）へのLooker導入に携わる

2020年4月からの半年間は前々回のFFTT#414で話した。当時は今以上に試行錯誤中で、未来がぼんやりしていた。 https://developer.feedforce.jp/entry/2020/10/23/190000  

思えば遠くへ来たもんだ • だいたい10年周期でキャリアチェンジしていた • フィードフォースとしても、BIにここまで投資したのは初めてだと思う（料金は前ページ資料でふんわり言及） • ２年経って学んだこと、ああすれば良かったことを整理し、次に繋げる

最初は考えていなかったこと • 結果的にキャリアチェンジになった • 当初は３ヶ月程度でLooker導入が終わり、運用・保守フェーズに入ると楽観視していた • 結果的にFeedmaticチーム初の専属エンジニアになった ◦ Looker以外のことはあまりやっていませんけどね

目次 1. 構成図 2. ヒアリングは難しい 3. 共通化は難しい 4. 責務範囲を定めるのは難しい 5.
架け橋になる人がいないと難しい 6. LookML開発者を増やす判断は難しい 7. BIでBigQuery料金が高騰すると難しい 8. データ設計は難しい 9. 結局楽しいの？ 10. 今後の予定

構成図

簡略化した構成図 Funnel.io (ETL Service) BigQuery (Data Warehouse) 広告媒体 (Criteo, Facebook,
Google,...) インポートエクスポート Looker 参照 

メンテナンス簡単そうですね？ • ま、まあね...（震え • データパイプラインを組んでいるわけでなく、ETL Serviceを１つ使っているだけだし • Data WarehouseもBigQueryの１種類だけだし •
１人でメンテナンスしているので、頑張ってこの構成を保ち続けた側面はあるかもね？

ヒアリングは難しい

ヒアリングは難しい • ２年前の私 ◦ ヒアリングは他の人より得意な方だし、熱量高くやれば大丈夫でしょ (^^) • 最近の私 ◦ それなりに頑張るけど、100%うまくいかなくても仕方がない。運要素はある
◦ 過度に自分に期待しなくなった

ヒアリングは本当に難しい（現在進行系） • 広告運用コンサルタント（以下コンサル）は常に忙しい • それもあって、コンサルと共通言語をすり合わせるのが難しい（後述） • 本当に必要なものを作るようにしているが、その後の追跡は難しい ◦
取引先で本当に必要な、特異な実装があるのは事実

解決策？ • 決定的なものはない • １つ１つのヒアリングを大事にする。次確認すれば良いとは思わない • 一喜一憂しない。うまくいけば次に活かし、そうでなければ淡々と改善する •
全部を把握しようとしない。全体としてうまくいっていそうならOK

微妙に心苦しかったこと • Slackで質問をして何時間後かに「会議ですぐ返信できなくてすみません」とたびたび謝られてしまった • 「Slackだし、すぐの返信は求めてないんだけどなあ...」と微妙に心苦しい日々が続いた

自分のポリシーを共有した

共通化は難しい

共通化は難しい • 広告代理店という業務は想定以上に共通化が難しかった ◦ 例1: 広告評価に使う指標は案件ごとに違う ◦ 例2: ある取引先のConversion数値はAPIで取得出来ない。メールで送られてくる •
JumpStartでは1個だったExploreは、現在は59個 ◦ 取引先ごとのExploreが51個と大部分を占める ▪ ※ 全ての取引先で個別Exploreを作っているわけではない ◦ LookML開発において、Exploreを増やすことはアンチパターンだとは知っている... ▪ ※ extends使った最低限の共通化はしています

「テンプレートパターン」を使わざるを得ないことが多い • テンプレートからのコピーがどんどん量産されていく ◦ 広告媒体数値とGoogle Analytics数値を紐付けるためのスプレッドシートが現在50個ほど ◦ Funnel.ioのインポート設定やエクスポート設定などは合わせて数百個はありそう • 共通箇所を変更したくなったら、量産されたコピーも全
部変更する。手作業で😱

難しい事情１ • 似たような実装が複数現れてから、共通化を考えるぜ！ • というソフトウェア開発の手法を使いづらい... • LookMLで使えるのはデータテストだけで、プログラミング言語のテストとは関心事が異なる。まだ（？）洗練もされていないと思う •
取引先（コンサル）ごとに事情が違うため、同じものを使ってもらうとインシデントのリスクがある

難しい事情２ • Funnel.ioは良いサービスで広告にも強いが、マーケッター向けのサービスのようで、APIは公開されていない • 設定が大量にあっても、コード管理できたらまだマシだったんだけどね...

解決策？？ • 長年の勘（）で共通化する/しないや、タイミングを決める • 共通化出来なくて辛くなっても、心を乱さない • 大量の手作業も頑張る！😳 • ずっと考え続ければ、いつか良いアイディアを思いつく
はず🔥 ◦ 💡これは冗談ではなくて、「考えを寝かせる」という文脈で大事だと思って実践しています

責務範囲を定めるのは難しい

責務範囲どこまで？（１） BigQuery (Data Warehouse) Funnel.io (ETL Service) 広告媒体等 (Criteo, Facebook,
Google,...) インポートエクスポート Looker 参照  コンサルの責務 LookML開発者兼データ整備人（ワイ）の責務このあたりが曖昧

責務範囲どこまで？（１） • どんなデータをLookerで分析したいか判断するのはコンサルの責務（のはず） • 一方でコンサルは、普段そこまでFunnel.ioを使うわけでなく、私への説明が広告媒体管理画面の話になりがち • 「Funnel.ioだとどこの話なんだろう？」で止まることはあり、私がどこまで踏み込むべきかの判断が難しい
◦ さすがに私は広告運用は出来ないので...

責務範囲どこまで？（１） • Funnel.ioを私とコンサル間の翻訳機として使うことを考えたが、うまくいかなかった

Funnel.ioが対応する媒体責務範囲どこまで？（２） Funnel.io (ETL Service) 人力 Funnel.ioの責務インポート Funnel.ioが対応しない媒体

責務範囲どこまで？（２） • Funnel.ioは海外のサービスはほぼ対応しているが、国内はYahoo! JAPANくらいしか対応していない • それらFunnel.ioが対応していない媒体は全て、APIを提供しておらず、現在は社内の人力で対応している • 安直に自動化（スクレイピング）を始めると、日々のエ
ラー対応やデータの不一致に向かい合うことになる ◦ 人力だと多少のエラーには対応出来てしまう。自動化とはそれも加味する必要がある

責務範囲どこまで？（２） • LookML開発をやりながら、データの不一致にまで向き合う余力はないなー😅 • 自動化を始めたら、それを止めるのは困難になる • スクレイピングって、１つのプロダクトに出来るくらい、困難で価値ある技術だと思うのよねん •
言い訳ばかりに見えますね...

データ不一致をゼロにすることの難しさ（Funnel.io開発者より） Data mismatches are very tricky to notice and is
not always due to an error on our side. Some endpoints simply restrict or scramble the data we retrieve from their platforms, which can cause a mismatch that we cannot do anything about unfortunately. A mismatch could also occur because of a user-error, where the data is not handled or aggregated in a correct way. In those cases, we try to make sure that the user understands the issue and often inform them on what to do in order to avoid similar issues in the future. We are constantly striving to reduce the amounts of mismatches on our platform.

（機械翻訳）データの不一致を発見するのは非常に難しく、必ずしも当社側のエラーが原因ではありません。エンドポイントによっては、我々がプラットフォームから取得するデータを単純に制限したり、スクランブルをかけたりして、不一致を引き起こすことがありますが、残念ながら我々は何もできません。また、ユーザーのエラーにより、データが正しい方法で処理または集計されていない場合にもミスマッチが発生します。このような場合は、ユーザーに問題を理解してもらい、今後同様の問題が発生しないようにするための対策を伝えるようにしています。
私たちは、プラットフォーム上でのミスマッチを減らすために常に努力しています。

解決策？？？ • 結論を先延ばし中...

架け橋になる人がいないと難しい

架け橋になる人がいないと難しい • 前述の責務範囲と関連して、少なくとも広告代理店の文脈では、チーム内にLookML開発者との架け橋になる人がいないと難しいことを実感した • 去年の７月まではいたのですがね😭󰑜 • 分からないなりにやったりもしたが、効率が良くなかった。自分の責務も分からなくなってきた

解決策？？？？ • 以上のことが分かっても、すぐ架け橋さんが来てくれるわけではない

LookML開発者を増やす判断は難しい

LookML開発者を増やす判断は難しい • なんとか自分がボトルネックにはならずに、１人でやってこれたと思う（未確認） • しかし、他人のレビューを通らないコードがデプロイされるのは健全ではない • 一方でFeedmatic２人目のLookML開発者はオーバースペックではないかという疑念もあった

解決策？？？？？ • 人を増やすべきか、増やしてよいのか、増やすと良くなるのか？など、判断できていない。そもそもどこにいるのか？ • プレイヤーに徹して、欲しい欲しい欲しい！って言いまくったほうが良かったのかなあ...？

[突然のコラム] 自分がボトルネックにならないための三箇条 1. 出来るだけ早く回答する。可能ならメンションが来たらすぐに。少なくとも絵文字リアクションはつける 2. 出来るだけ早く実装する。可能なら当日に実装する。遅くなる時は、もちろん事前にお知らせする 3. 誰かに依頼や質問をした時、絶対にボールを離さない
a. 例: 自分から誰かへの依頼をSlackのリマインダーで管理する

BIでBigQuery料金が高騰すると難しい

BIでBigQuery料金が高騰すると難しい • ちょど１年前、11万円/月ほど溶かしてしまった（当時は通常2万円/月） • クエリが全体的に増えたようにしか見えず、特定に時間がかかった... • 料金は毎日上がっていくのに、業務が止まるのでLooker を止めるわけにもいかず、日々胃をｷｭﾙｷｭﾙさせることし
かできなかった。１人でｷｭﾙｷｭﾙはなかなか堪えました...

解決方法 • GCPの100%以上の月単位予算アラートを設定した（そんなん出来たんや...） • さらにGoogle Cloud Billing Blockを利用して、１日単位のアラートも設定した
• 後日、この「１日単位のアラート」に救われた😂 • 今はDatasetを特定する方法も分かったので、もう楽勝！ • 今度ブログ記事書こうかな？ https://github.com/llooker/gcp_billing_block  

データ設計は難しい

データ設計は難しい • Looker SEの方の教えを守り、全取引先のデータを出来るだけ１つのBigQuery Datasetにまとめていた • 平和な日々が続いたが、ある日Google Analytics (GA)の
インポートパラメータを１つ増やしたら、知らぬ間に Datasetサイズが10倍に... • それが前述のBigQuery料金高騰に繋がったというオチ😭

解決方法 • GAに関して、全取引先のDatasetを別々にしてスキャンサイズを抑えた ◦ ※ もちろんTime Partitioningは設定済みだった • GAはDatasetの数が1つから50以上に増えた
• もちろん手作業でFunnel.ioのエクスポート設定x50以上を作りましたとも😭 • Datasetを別々にしないで出来る方法はあるのかなあ...？

結局楽しいの？

結局楽しいの？ • めっちゃ楽しい (^^)v • コツコツと箱庭をつくるのが好きな性格だったらしい ◦ レビューを通さずにマージ出来るのでとても楽 • 大量の手作業もやってしまう。疲れるけどね。プログラ
マー向いてないのかもｗ

今後の予定

今後の予定 • Feedmaticは一段落着いたので、他プロダクトやグループ会社にLookerがマッチするかの検証を進める • ２人目のLookML開発者のための情報収集をする • Feedmaticもまだまだやることがありそうなので、そちらも（一段落とは...） •
別途「データ整備」という文脈での精査は必要そう

ご清聴ありがとうg..

最近「ロジスティクス」を考えています

ロジスティクス

ロジスティクスとは • ロジスティクス＝兵站（へいたん）のこと • 日本人は「情報」と「兵站」が苦手らしい • 必要物資の補給、後方連絡線の確保 • 旧日本軍は陸軍と海軍がいがみあっていた上、兵站を軽視していたそう
• 例えば飛行機は別々に作られ、技術交流はなく、部品も共用できなかったそう

あまり笑ってもいられない • フィードフォースにも一部当てはまるかもしれない • 各プロダクトはいがみあっていることはないが、それぞれデータ整備（兵站を確保）している。片手間ではあり、統一された手法があるわけではない • FeedmaticはLookerでデータ整備しつつある • それ以外のプロダクトは、開発サイドはRedashでデータ整備することが多
い。ビジネスサイドは分からない。他のグループ会社も分からない

未完

ご清聴ありがとうございました。

参考資料 • しんゆう（2021）『データ整備とどう付き合うか』 • 瀬沼裕樹（2021）『データ・ドリブンな事業開発を根付かせるためには？』 • 谷光太郎（2016）『ロジスティクスから見た「失敗の本質」』パンダ・パブリッシング

ボッチLookML開発者兼データ整備人を連れてきたよ！

ボッチLookML開発者兼データ整備人を連れてきたよ！

More Decks by Takashi Masuda

Other Decks in Technology

Featured

Transcript