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

2022-02-04 フィードフォース社内技術勉強会のプレゼン資料です。
https://developer.feedforce.jp/entry/2022/02/04/180000

Transcript

1. ボッチLookML開発者兼 データ整備人を連れてき たよ！〜２年間の悩みと知見？〜 2022-02-04 FFTT#469 @masutaka
2. 自己紹介 • 増田貴士（@masutaka） • 株式会社フィードフォース Feedmatic 所属 • 前回のFFTT#441から引き続き、個人メインPCは Manjaro (Linux) • 最近ようやく重い腰を上げて、証券口座を作ったり、仮 想通貨を購入して手触り（？）を確かめたりしている https://www.feedforce.jp/ 

3. 今日のお話の立ち位置 • 2000年4月〜2011年3月 ◦ 組み込みエンジニアとして、某社レーザープリンターのファームウェア開発や保守に携わる • 2011年4月〜2020年3月 ◦ ウェブエンジニアとして、某オンライン英会話の予約サービスや、Feedforce各種サービスの 開発や運用に携わる • 2020年4月〜 ←今日のお話 ◦ データアーキテクト（データ整備人）やBIエンジニア（LookML開発者）として、Feedmatic （フィードフォースのコンサルティング型広告代理店）へのLooker導入に携わる
4. 2020年4月からの半年間は 前々回のFFTT#414で話し た。 当時は今以上に試行錯誤中 で、未来がぼんやりしてい た。 https://developer.feedforce.jp/entry/2020/10/23/190000 

5. 思えば遠くへ来たもんだ • だいたい10年周期でキャリアチェンジしていた • フィードフォースとしても、BIにここまで投資したのは 初めてだと思う（料金は前ページ資料でふんわり言及） • ２年経って学んだこと、ああすれば良かったことを整理 し、次に繋げる
6. 最初は考えていなかったこと • 結果的にキャリアチェンジになった • 当初は３ヶ月程度でLooker導入が終わり、運用・保守 フェーズに入ると楽観視していた • 結果的にFeedmaticチーム初の専属エンジニアになった ◦ Looker以外のことはあまりやっていませんけどね
7. 目次 1. 構成図 2. ヒアリングは難しい 3. 共通化は難しい 4. 責務範囲を定めるのは難しい 5. 架け橋になる人がいないと難しい 6. LookML開発者を増やす判断は難しい 7. BIでBigQuery料金が高騰すると難しい 8. データ設計は難しい 9. 結局楽しいの？ 10. 今後の予定
8. 構成図
9. 簡略化した構成図 Funnel.io (ETL Service) BigQuery (Data Warehouse) 広告媒体 (Criteo, Facebook, Google,...) インポート エクスポート Looker 参照

10. メンテナンス簡単そうですね？ • ま、まあね...（震え • データパイプラインを組んでいるわけでなく、ETL Serviceを１つ使っているだけだし • Data WarehouseもBigQueryの１種類だけだし • １人でメンテナンスしているので、頑張ってこの構成を 保ち続けた側面はあるかもね？
11. 目次 1. 構成図 2. ヒアリングは難しい 3. 共通化は難しい 4. 責務範囲を定めるのは難しい 5. 架け橋になる人がいないと難しい 6. LookML開発者を増やす判断は難しい 7. BIでBigQuery料金が高騰すると難しい 8. データ設計は難しい 9. 結局楽しいの？ 10. 今後の予定
12. ヒアリングは難しい
13. ヒアリングは難しい • ２年前の私 ◦ ヒアリングは他の人より得意な方だし、熱量高くやれば大丈夫でしょ (^^) • 最近の私 ◦ それなりに頑張るけど、100%うまくいかなくても仕方がない。運要素はある ◦ 過度に自分に期待しなくなった
14. ヒアリングは本当に難しい（現在進行系） • 広告運用コンサルタント（以下コンサル）は常に忙しい • それもあって、コンサルと共通言語をすり合わせるのが 難しい（後述） • 本当に必要なものを作るようにしているが、その後の追 跡は難しい ◦ 取引先で本当に必要な、特異な実装があるのは事実
15. 解決策？ • 決定的なものはない • １つ１つのヒアリングを大事にする。次確認すれば良い とは思わない • 一喜一憂しない。うまくいけば次に活かし、そうでなけ れば淡々と改善する • 全部を把握しようとしない。全体としてうまくいってい そうならOK
16. 微妙に心苦しかったこと • Slackで質問をして何時間後かに「会議ですぐ返信できな くてすみません」とたびたび謝られてしまった • 「Slackだし、すぐの返信は求めてないんだけどなあ...」 と微妙に心苦しい日々が続いた
17. 自分のポリシーを共有した
18. 目次 1. 構成図 2. ヒアリングは難しい 3. 共通化は難しい 4. 責務範囲を定めるのは難しい 5. 架け橋になる人がいないと難しい 6. LookML開発者を増やす判断は難しい 7. BIでBigQuery料金が高騰すると難しい 8. データ設計は難しい 9. 結局楽しいの？ 10. 今後の予定
19. 共通化は難しい
20. 共通化は難しい • 広告代理店という業務は想定以上に共通化が難しかった ◦ 例1: 広告評価に使う指標は案件ごとに違う ◦ 例2: ある取引先のConversion数値はAPIで取得出来ない。メールで送られてくる • JumpStartでは1個だったExploreは、現在は59個 ◦ 取引先ごとのExploreが51個と大部分を占める ▪ ※ 全ての取引先で個別Exploreを作っているわけではない ◦ LookML開発において、Exploreを増やすことはアンチパターンだとは知っている... ▪ ※ extends使った最低限の共通化はしています
21. 「テンプレートパターン」を使わざるを得ないことが多い • テンプレートからのコピーがどんどん量産されていく ◦ 広告媒体数値とGoogle Analytics数値を紐付けるためのスプレッドシートが現在50個ほど ◦ Funnel.ioのインポート設定やエクスポート設定などは合わせて数百個はありそう • 共通箇所を変更したくなったら、量産されたコピーも全 部変更する。手作業で😱
22. 難しい事情１ • 似たような実装が複数現れてから、共通化を考えるぜ！ • というソフトウェア開発の手法を使いづらい... • LookMLで使えるのはデータテストだけで、プログラミン グ言語のテストとは関心事が異なる。まだ（？）洗練も されていないと思う • 取引先（コンサル）ごとに事情が違うため、同じものを 使ってもらうとインシデントのリスクがある
23. 難しい事情２ • Funnel.ioは良いサービスで広告にも強いが、マーケッ ター向けのサービスのようで、APIは公開されていない • 設定が大量にあっても、コード管理できたらまだマシ だったんだけどね...
24. 解決策？？ • 長年の勘（）で共通化する/しないや、タイミングを決め る • 共通化出来なくて辛くなっても、心を乱さない • 大量の手作業も頑張る！😳 • ずっと考え続ければ、いつか良いアイディアを思いつく はず🔥 ◦ 💡これは冗談ではなくて、「考えを寝かせる」という文脈で大事だと思って実践しています
25. 目次 1. 構成図 2. ヒアリングは難しい 3. 共通化は難しい 4. 責務範囲を定めるのは難しい 5. 架け橋になる人がいないと難しい 6. LookML開発者を増やす判断は難しい 7. BIでBigQuery料金が高騰すると難しい 8. データ設計は難しい 9. 結局楽しいの？ 10. 今後の予定
26. 責務範囲を定めるのは難しい
27. 責務範囲どこまで？（１） BigQuery (Data Warehouse) Funnel.io (ETL Service) 広告媒体等 (Criteo, Facebook, Google,...) インポート エクスポート Looker 参照
 コンサルの責務 LookML開発者兼データ整備人（ワイ）の責務 このあたりが 曖昧
28. 責務範囲どこまで？（１） • どんなデータをLookerで分析したいか判断するのはコン サルの責務（のはず） • 一方でコンサルは、普段そこまでFunnel.ioを使うわけで なく、私への説明が広告媒体管理画面の話になりがち • 「Funnel.ioだとどこの話なんだろう？」で止まることは あり、私がどこまで踏み込むべきかの判断が難しい ◦ さすがに私は広告運用は出来ないので...
29. 責務範囲どこまで？（１） • Funnel.ioを私とコンサル間の翻訳機として使うことを考 えたが、うまくいかなかった
30. Funnel.ioが対応する媒体 責務範囲どこまで？（２） Funnel.io (ETL Service) 人力 Funnel.ioの責務 インポート Funnel.ioが対応しない媒体
31. 責務範囲どこまで？（２） • Funnel.ioは海外のサービスはほぼ対応しているが、国内 はYahoo! JAPANくらいしか対応していない • それらFunnel.ioが対応していない媒体は全て、APIを提供 しておらず、現在は社内の人力で対応している • 安直に自動化（スクレイピング）を始めると、日々のエ ラー対応やデータの不一致に向かい合うことになる ◦ 人力だと多少のエラーには対応出来てしまう。自動化とはそれも加味する必要がある
32. 責務範囲どこまで？（２） • LookML開発をやりながら、データの不一致にまで向き合 う余力はないなー😅 • 自動化を始めたら、それを止めるのは困難になる • スクレイピングって、１つのプロダクトに出来るくら い、困難で価値ある技術だと思うのよねん • 言い訳ばかりに見えますね...
33. データ不一致をゼロにすることの難しさ（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.
34. （機械翻訳） データの不一致を発見するのは非常に難しく、必ずしも当社側のエラーが原因ではありませ ん。 エンドポイントによっては、我々がプラットフォームから取得するデータを単純に制限した り、スクランブルをかけたりして、不一致を引き起こすことがありますが、残念ながら我々 は何もできません。 また、ユーザーのエラーにより、データが正しい方法で処理または集計されていない場合に もミスマッチが発生します。 このような場合は、ユーザーに問題を理解してもらい、今後同様の問題が発生しないように するための対策を伝えるようにしています。 私たちは、プラットフォーム上でのミスマッチを減らすために常に努力しています。
35. 解決策？？？ • 結論を先延ばし中...
36. 目次 1. 構成図 2. ヒアリングは難しい 3. 共通化は難しい 4. 責務範囲を定めるのは難しい 5. 架け橋になる人がいないと難しい 6. LookML開発者を増やす判断は難しい 7. BIでBigQuery料金が高騰すると難しい 8. データ設計は難しい 9. 結局楽しいの？ 10. 今後の予定
37. 架け橋になる人がいないと難しい
38. 架け橋になる人がいないと難しい • 前述の責務範囲と関連して、少なくとも広告代理店の文 脈では、チーム内にLookML開発者との架け橋になる人が いないと難しいことを実感した • 去年の７月まではいたのですがね😭󰑜 • 分からないなりにやったりもしたが、効率が良くなかっ た。自分の責務も分からなくなってきた
39. 解決策？？？？ • 以上のことが分かっても、すぐ架け橋さんが来てくれる わけではない
40. 目次 1. 構成図 2. ヒアリングは難しい 3. 共通化は難しい 4. 責務範囲を定めるのは難しい 5. 架け橋になる人がいないと難しい 6. LookML開発者を増やす判断は難しい 7. BIでBigQuery料金が高騰すると難しい 8. データ設計は難しい 9. 結局楽しいの？ 10. 今後の予定
41. LookML開発者を増やす判断は難しい
42. LookML開発者を増やす判断は難しい • なんとか自分がボトルネックにはならずに、１人でやっ てこれたと思う（未確認） • しかし、他人のレビューを通らないコードがデプロイさ れるのは健全ではない • 一方でFeedmatic２人目のLookML開発者はオーバース ペックではないかという疑念もあった
43. 解決策？？？？？ • 人を増やすべきか、増やしてよいのか、増やすと良くな るのか？など、判断できていない。そもそもどこにいる のか？ • プレイヤーに徹して、欲しい欲しい欲しい！って言いま くったほうが良かったのかなあ...？
44. [突然のコラム] 自分がボトルネックにならないための三箇条 1. 出来るだけ早く回答する。可能ならメンションが来たら すぐに。少なくとも絵文字リアクションはつける 2. 出来るだけ早く実装する。可能なら当日に実装する。遅 くなる時は、もちろん事前にお知らせする 3. 誰かに依頼や質問をした時、絶対にボールを離さない a. 例: 自分から誰かへの依頼をSlackのリマインダーで管理する
45. 目次 1. 構成図 2. ヒアリングは難しい 3. 共通化は難しい 4. 責務範囲を定めるのは難しい 5. 架け橋になる人がいないと難しい 6. LookML開発者を増やす判断は難しい 7. BIでBigQuery料金が高騰すると難しい 8. データ設計は難しい 9. 結局楽しいの？ 10. 今後の予定
46. BIでBigQuery料金が高騰すると難しい
47. BIでBigQuery料金が高騰すると難しい • ちょど１年前、11万円/月ほど溶かしてしまった（当時は 通常2万円/月） • クエリが全体的に増えたようにしか見えず、特定に時間 がかかった... • 料金は毎日上がっていくのに、業務が止まるのでLooker を止めるわけにもいかず、日々胃をｷｭﾙｷｭﾙさせることし かできなかった。１人でｷｭﾙｷｭﾙはなかなか堪えました...
48. 解決方法 • GCPの100%以上の月単位予算アラートを設定した（そん なん出来たんや...） • さらにGoogle Cloud Billing Blockを利用して、１日単位 のアラートも設定した • 後日、この「１日単位のアラート」に救われた😂 • 今はDatasetを特定する方法も分かったので、もう楽勝！ • 今度ブログ記事書こうかな？ https://github.com/llooker/gcp_billing_block 

49. 目次 1. 構成図 2. ヒアリングは難しい 3. 共通化は難しい 4. 責務範囲を定めるのは難しい 5. 架け橋になる人がいないと難しい 6. LookML開発者を増やす判断は難しい 7. BIでBigQuery料金が高騰すると難しい 8. データ設計は難しい 9. 結局楽しいの？ 10. 今後の予定
50. データ設計は難しい
51. データ設計は難しい • Looker SEの方の教えを守り、全取引先のデータを出来る だけ１つのBigQuery Datasetにまとめていた • 平和な日々が続いたが、ある日Google Analytics (GA)の インポートパラメータを１つ増やしたら、知らぬ間に Datasetサイズが10倍に... • それが前述のBigQuery料金高騰に繋がったというオチ😭
52. 解決方法 • GAに関して、全取引先のDatasetを別々にしてスキャン サイズを抑えた ◦ ※ もちろんTime Partitioningは設定済みだった • GAはDatasetの数が1つから50以上に増えた • もちろん手作業でFunnel.ioのエクスポート設定x50以上 を作りましたとも😭 • Datasetを別々にしないで出来る方法はあるのかなあ...？
53. 目次 1. 構成図 2. ヒアリングは難しい 3. 共通化は難しい 4. 責務範囲を定めるのは難しい 5. 架け橋になる人がいないと難しい 6. LookML開発者を増やす判断は難しい 7. BIでBigQuery料金が高騰すると難しい 8. データ設計は難しい 9. 結局楽しいの？ 10. 今後の予定
54. 結局楽しいの？
55. 結局楽しいの？ • めっちゃ楽しい (^^)v • コツコツと箱庭をつくるのが好きな性格だったらしい ◦ レビューを通さずにマージ出来るのでとても楽 • 大量の手作業もやってしまう。疲れるけどね。プログラ マー向いてないのかもｗ
56. 目次 1. 構成図 2. ヒアリングは難しい 3. 共通化は難しい 4. 責務範囲を定めるのは難しい 5. 架け橋になる人がいないと難しい 6. LookML開発者を増やす判断は難しい 7. BIでBigQuery料金が高騰すると難しい 8. データ設計は難しい 9. 結局楽しいの？ 10. 今後の予定
57. 今後の予定
58. 今後の予定 • Feedmaticは一段落着いたので、他プロダクトやグルー プ会社にLookerがマッチするかの検証を進める • ２人目のLookML開発者のための情報収集をする • Feedmaticもまだまだやることがありそうなので、そち らも（一段落とは...） • 別途「データ整備」という文脈での精査は必要そう
59. ご清聴ありがとうg..
60. 最近「ロジスティクス」を考えています
61. ロジスティクス
62. ロジスティクスとは • ロジスティクス＝兵站（へいたん）のこと • 日本人は「情報」と「兵站」が苦手らしい • 必要物資の補給、後方連絡線の確保 • 旧日本軍は陸軍と海軍がいがみあっていた上、兵站を軽 視していたそう • 例えば飛行機は別々に作られ、技術交流はなく、部品も 共用できなかったそう
63. あまり笑ってもいられない • フィードフォースにも一部当てはまるかもしれない • 各プロダクトはいがみあっていることはないが、それぞれデータ整備（兵站 を確保）している。片手間ではあり、統一された手法があるわけではない • FeedmaticはLookerでデータ整備しつつある • それ以外のプロダクトは、開発サイドはRedashでデータ整備することが多 い。ビジネスサイドは分からない。他のグループ会社も分からない
65. 未完
66. ご清聴ありがとうございました。
67. 参考資料 • しんゆう（2021）『データ整備とどう付き合うか』 • 瀬沼裕樹（2021）『データ・ドリブンな事業開発を根付かせるためには？』 • 谷光太郎（2016）『ロジスティクスから見た「失敗の本質」』パンダ・パブ リッシング