データ整備業でぶつかった5つの課題_データ整備人に求められる3つのスキル_SD用.pdf

by siwai

Slide 1

Slide 1 text

データ整備業でぶつかった5つの課題データ整備人に求められる3つのスキル 2019/11/27 (Wed) データアーキテクト（データ整備人）を”前向きに”考える会

Slide 2

Slide 2 text

1. 自己紹介と業務紹介 2. データ整備業でぶつかった5つの課題と解決方法 3. データ整備人に求められる3つのスキルアジェンダ 

Slide 3

Slide 3 text

自己紹介と業務紹介   

Slide 4

Slide 4 text

自己紹介①  名前と所属  ・岩井晋太郎( @hogeta_)  ・株式会社オプトデータテクノロジー部     仕事のこと  ・営業 → アフィリエイター → エンジニア → データ整備人(現職)  ・アプリDMPサービスのサーバーサイドエンジニアとして弊社でのキャリアをスタート   ・今はデータ整備人の傍ら、コード書いたり、マーケっぽいことやったり、PMやったりしてる。   ・敬虔なるBigquery信者     個人的なこと  ・出生は秋田県。都会に憧れて東京に出てきたけど永住の地は千葉になりそう   ・趣味は筋トレ(BIG3で300kgいけるようになったので中級者)  

Slide 5

Slide 5 text

自己紹介② 圧倒的操作系 

Slide 6

Slide 6 text

・株式会社オプト・Webの広告代理店・クライアントのデジタルシフト支援に力を入れるなど広告以外のマーケティング領域にも注力・以下のツールを内省していた(どちらもBQを採用している) 会社紹介  アプリのDMP AdjustやAppsflyerなどのアプリSDK のローデータを蓄積する Webの広告計測ツール (事業譲渡が決まった。。。 )

Slide 7

Slide 7 text

データ整備業の5つの課題と解決方法 

Slide 8

Slide 8 text

話すこと・話さないこと  ・データ整備業においての泥臭い運用の話・SQL周りのお話話すこと・データエンジニアリングの話・機械学習周りの話話さないこと

Slide 9

Slide 9 text

どんなデータを扱っているか  ・ADPLAN ・GA360 ・TreasureData ・POSデータ・マスターデータ・Adjust ・Appsflyer ・Firebase ・施策のデータ(SMC等) ・3rd Party DMP web App クライアント基幹データその他

Slide 10

Slide 10 text

どんな依頼がくるか  KPI設計してちょっと自分で分析したいから綺麗なデータ頂戴営業したいんだけどデータ使って何かできない？この広告施策の成果が悪い。なんで？広告活用にデータ活かしたい！シードをくれ！ダッシュボードって作れますか？今エクセルでやってる作業を簡単にできるようにしてよ webとapp横断で分析がしたい CRMに活かしたい。顧客ランクをつけてくれ媒体の管理画面で見れない指標が見れると聞いて BQ叩かせろ！

Slide 11

Slide 11 text

1. 意思決定の材料が欲しい 2. 広告活用したい 3. 自由分析したい依頼の内容を大別すると３つ 

Slide 12

Slide 12 text

どこ(誰)からデータ抽出依頼がくるか  クライアント社内からの依頼クライアントからの依頼同じ部の営業広告運用コンサルタント広告営業同じ部の営業上司基本的に同じ部の営業が一次受けをしてくれる(ことが多い)

Slide 13

Slide 13 text

求められていること・求められていないこと  ・意思決定のための示唆・意思決定をするために必要なことのすり合わせ求められていること・意思決定をすること・統計的知見による助言求められていないこと

Slide 14

Slide 14 text

どうやって依頼を解決するか 

Slide 15

Slide 15 text

結局やっていることはSQL職人 

Slide 16

Slide 16 text

1. 雑に依頼がきて辛い 2. SQLのレビューが辛い 3. 類似した依頼が何度もきて辛い 4. ノウハウが共有されなくて辛い 5. リソースが足りなくて辛いデータ整備業をしていてぶつかった5つの課題 

Slide 17

Slide 17 text

課題 1  雑に依頼がきて辛い 

Slide 18

Slide 18 text

課題1: 雑に依頼がきて辛い  とりあえずデータ出してよ、と言われた    その度に僕は唇を噛み締め、APIじゃないんだぞ、と強く思った。    しかし、なすすべなく画面に向かうのだった。。。 

Slide 19

Slide 19 text

自然と目的が添えられた上で依頼がくるようになった。同時に自分自身のドメイン知見も向上した。そもそもデータを出さずに課題解決することもたまにあった。依頼者に対して何をしたくてデータが欲しいかをしつこく聞いた。納得感がない場合は断ることも。課題1: 雑に依頼がきて辛い  やったこと① データがあると何が嬉しいんですかと聞くようにした結果: 成功

Slide 20

Slide 20 text

・目的、期限、希望のアウトプットなど必要な情報の漏れがないように　依頼時のフォーマットを作った。・アウトプットのイメージで合意が取れるまで作業に着手しないようにした。手戻りが圧倒的に少なくなった。アウトプットのイメージを握っておくことで齟齬が生じなくなった。課題1: 雑に依頼がきて辛い  やったこと② 依頼のフォーマットを作った結果: 成功

Slide 21

Slide 21 text

課題 2  SQLのレビューが辛い  

Slide 22

Slide 22 text

SQLのレビューが辛い３つの理由 1. SQLが読みづらい (書き手よってインデントが違ったりとか) 2. SQLがスパゲッティ 3. データの仕様が分からない課題2: SQLのレビューが辛い  

Slide 23

Slide 23 text

課題2: SQLのレビューが辛い   SQLの書き方を統一してレビュワーが読みやすくするのが狙い。インデントやView、カラムの命名規則など細かく作成した。やったこと① SQLスタイルガイドを書いた・浸透させるのが難しいのと、スタイルガイドからのちょっとのずれを指摘するのは本質的ではない。フォーマッターがないと浸透は難しそう。・とはいえ、いくつかのルールは徹底されている(後述) 結果: 失敗

Slide 24

Slide 24 text

・全てをcolab化するのは逆にコストが増えるが、重要度が高いものや複雑なものは colabを使うとレビューがしやすく、知見も共有しやすい。・SQLをかけないビジネスメンバーへの説明も容易になる・結果をDataflameとしてpythonで扱えるので統計情報を見たり、可視化したりして異常値に気づけるきっかけになる課題2: SQLのレビューが辛い   Google Colaboratoryで途中の処理を可視化しながら処理の流れを把握できるようにすることが目的。 SQLがスパゲッティでも順次処理を追っていけば理解しやすい。やったこと② Google ColaboratoryでのSQLレビュー結果: 成功

Slide 25

Slide 25 text

課題 3  類似した依頼が何度もきて辛い 

Slide 26

Slide 26 text

課題3: 類似した依頼が何度もきて辛い  例えば、期間を変えるだけ、など過去に出したものの焼き直しみたいな依頼は頻繁にある。そういったものは可能な限り手間をかけずに出したい、なんなら一次受けした営業さんに捌いてもらいたい...

Slide 27

Slide 27 text

スタイルガイドで唯一徹底されている「変数定義を一番上にする」のおかげで githubに再利用がしやすい形で過去の事例が溜まっている。類似分析をする際に1からクエリを書かなくていいように汎用的に作成し、githubに保存。汎用的な形とは変数をSQL文の一番上に書くこと ※保存先はBQでも良かったが検索しづらいのと githubでのレビューの都合上不採用課題3: 類似した依頼が何度もきて辛い  やったこと: 再利用がしやすい形でSQLを作成し、githubに保存結果: 成功

Slide 28

Slide 28 text

再利用しにくいSQL  SELECT count(distinct id) FROM table WHERE date = “2019-11-11” # 任意の日付を入力してください AND event = “install” # 任意のイベントを入力してください例:任意の日のインストール UUを出すSQL コメントで変更箇所を示す変更部分にコメントを書く。コメント部分を探すのが大変

Slide 29

Slide 29 text

再利用しやすいSQL  create temp function targetDate() as ("2019-11-11"); create temp function targetEvent() as ("install"); SELECT count(distinct id) FROM table WHERE date = targetDate() AND event = targetEvent() 変数(固定値を返す関数)を一番上に定義する例:任意の日のインストール UUを出すSQL 変数がSQLの一番上に集約されているので変更箇所が明白

Slide 30

Slide 30 text

再利用しやすいSQL  with const as ( select "2019-11-11" as targetDate, "install" as targetEvent ) SELECT count(distinct id) FROM table,const WHERE date = targetDate AND event = targetEvent 1行しかないCTE式を定義例:任意の日のインストール UUを出すSQL もしfunctionが使えなければ1行しかないテーブルをcross joinする方法も

Slide 31

Slide 31 text

課題 4  ノウハウが共有されなくて辛い 

Slide 32

Slide 32 text

課題4: ノウハウが共有されなくて辛い  マニアックなSQLの小技とかデータの仕様で気づいたこととかが共有されておらず、知識がかなり属人化していた。知識が属人化すると、結果的に作業が属人化するので疲弊する。 (体験談) リファレンスがないので初めてデータを触る人の教育コストも高くなる。

Slide 33

Slide 33 text

GithubにSQLを書いていて気づいたノウハウやデータ構造についてのTipsを貯めていった。 (これは完全に某M社さんのパクリ) ちょっとずつ溜まっていっているが、まだリファレンスとしては不十分課題4: ノウハウが共有されなくて辛い  やったこと① GithubにクエリのTipsを保存結果: 成功?

Slide 34

Slide 34 text

定義した関数を保存するというBigqueryの機能がある。ここによく使う関数を保存する課題4: ノウハウが共有されなくて辛い  やったこと② 永続UDFの採用結果: 成功? ここ最近できた機能なのでまだそれほど関数は作成されていない。サービスごとにプロジェクトが違うのどこのプロジェクトにまとめるかは決めかねている。

Slide 35

Slide 35 text

課題 5   リソースが足りなくて辛い 

Slide 36

Slide 36 text

結局これが一番大きな問題で、まだ解決できていない。いくら作業を効率化したとしても、作業自体はなくならないので結果的には非常にスケールしにくい状態。組織として専任がいるわけではないので、キューが詰まりやすい。課題5: リソースが足りなくて辛い 

Slide 37

Slide 37 text

興味ある人を対象にSQLの社内勉強会を開催。課題5: リソースが足りなくて辛い  やったこと SQL布教活動・結局SQLを定常的に書かないとできるようにならない・SQLが書けるのと、扱うデータを理解するは別の問題結果: 失敗

Slide 38

Slide 38 text

課題5: リソースが足りなくて辛い  結局やりたいことはデータの民主化なんだけど  障壁を極限まで取り除いた状態での  民主化が必要なんじゃないかと思った。 

Slide 39

Slide 39 text

やりたい分析のほとんどは  行動分析とユーザー分析  課題5: リソースが足りなくて辛い 

Slide 40

Slide 40 text

課題5: リソースが足りなくて辛い  扱うデータソースによってカラム名や仕様、値が異なる。データの仕様の理解という部分は SQL習得と同等以上にコストがかかる。 webだろうがappだろうが、posデータだろうが全ての行動ログを同じ形式に変換することでそこのコストを大幅に下げ、データを触る敷居もグッと下げたいスキーマはもちろん、値の表記揺れの統一なども全てこのインターフェースで吸収する構想。 When,Who,Where,Whatさえ分かれば行動分析はできるという思想。やろうとしていること① 全ての行動ログを同じ形式に変換する抽象化インターフェースの作成

Slide 41

Slide 41 text

①で作ろうとしているものは自由分析をしたい人向けのインターフェースだが、これは完全にユーザー分析に特化したマート。 ID単位でLTVやRFM、接触メディアなど必要なユーザーステータスがデイリーで更新され、過去との比較も容易にできる課題5: リソースが足りなくて辛い  やろうとしていること② ユーザー分析が容易にできるマートの作成 id 総課金額 CV回数直近来訪日 xx 5000 20 2019/11/27 usermart_20191112 イメージ 

Slide 42

Slide 42 text

データ整備人に求められる３つのスキル 

Slide 43

Slide 43 text

雑に投げられたデータ抽出の依頼から、「これを出すことでどんなメリットがあるのか」「結果を用いてこの人は何をしようとしているのか」等を考える能力。そして必要に応じて議論を交わして落とし所を見つける能力これがないと、データを出すAPIと化してしまう。やらなくていいことをしないためデータを出すことが本質的な課題解決にならないことを認識させるため ① 課題抽出力  なぜ必要か

Slide 44

Slide 44 text

出したいものが出せるか、工数はどのくらいかかるかを判断するため。ただ書けるだけじゃなく、自分が扱うDBの関数は全て理解していることが望ましい。依頼の内容を聞いた段階で頭の中である程度SQLが組み上がるレベル ②高いSQL力  なぜ必要か

Slide 45

Slide 45 text

扱うデータの仕様、どのように取得され、どこで加工されているか等を可能な限り把握すること。扱うデータに責任を持つということ。データの不整合があった場合のあたりのつけどころが広がる。 SQL以前に必要なデータがあるかという観点での実現可否を判断するため。 ③データ理解力  なぜ必要か

Slide 46

Slide 46 text

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