プロダクト中心のデータ駆動を推進していくために必要なこと

プロダクト開発メンバー主導の民主的なデータ活用を目指すとどの企業でも直面することになるであろういくつかの課題と、それらに対するピクシブ株式会社データ駆動推進室の取り組みをご紹介します。

Data Platform Meetup 【vol.2】の発表資料です。
https://data-platform-meetup.connpass.com/event/155073/

ピクシブ株式会社について：
https://www.pixiv.co.jp/

Transcript

1. プロダクト中心のデータ駆動を推進してい くために必要なこと
 pixiv Inc. Kazuhito Osabe 2019.12.02 ピクシブがデータの民主化を目指すまでと、その後の取り組み
2. 2 自己紹介
 • 情報系修士→ピクシブ、新卒3年目 元は有料会員部門の開発担当兼分析担当 →現データ駆動推進室のデータ基盤エンジニア • 社内のデータ基盤整備を方針決めのレベルから中 心的に進めてきました • データ基盤にpixiv本体のデータしかなかった状態か ら、全周辺プロダクトのデータが一括で乗った状態ま で持っていった 長部 和仁
 (@tohhy)
 データ駆動推進室
 エンジニア

3. ピクシブについて(会社とpixiv本体)
 3 会社としてのピクシブ 「創作活動がもっと楽しくなる場所を創る」を スローガンに多数の事業を運営 サービスとしてのpixiv(本体) イラスト、マンガ、小説など 創作作品を公開する場 社内で最大規模のWebサービス の中にある
4. ピクシブについて(周辺プロダクト)
 4 • ECサイト • グッズ制作 • ファンコミュニティ • 3D事業 などなど 会社としてのピクシブ 「創作活動がもっと楽しくなる場所を創る」を スローガンに多数の事業を運営 の中にある
5. 今日話すこと
 • いまデータ活用が求められる背景の考察 • データ活用のための組織構造について（集権化と民主化、その良し悪し） • 民主化を選ぶ場合に直面する課題とピクシブでの取り組み • おわりに 5
6. 6 いまデータ活用が求められる背景の考察
 
 

7. • 個人としてどう考えているかの話です • データプラットフォームに関する話題が一般化し 勉強会なども増え、参加者の層も広がっている • なぜだろうか • データプラットフォームの構成要素のうち、 近年で大きく動いた部分はおそらく この2箇所 なぜ今データプラットフォームなのか
 7 生データ クラウドDWH 機械学習技術 データ分析 可視化 ここ ここと
8. 8 クラウドDWH
 もたらす変化
 • 価格的にも運用的にも低コストでデータ の全数保持・全数活用が可能になる • 「不要なデータ」の減少、ログを捨てるよ り保持するべきケースの増加 • その結果として企業が管理するデータ 資産の総量の増加 • それを加工するデータパイプラインも複 雑化 生データと活用現場の間に挟まる低コス トの抽象化＆データ蓄積層 生データ クラウド DWH 機械学習 技術 データ分析 可視化
9. 機械学習技術
 データの価値産出の道筋が増加 より広い層に活用される 9 もたらす変化
 • 分析プロセスを経由しなくても、データ 単体で価値産出する道が生まれてくる • 自動最適化、推薦など。収益の向上は もちろん、単体でユーザーに価値提供 する機能になったりもする • その恩恵が研究開発系の企業だけで はなく一般Web企業まで降りてくる 生データ クラウド DWH 機械学習 技術 データ分析 可視化
10. ピクシブでのビッグデータ×機械学習
 10 • レコメンドチーム • pixiv本体を中心に、ユーザーのアクティビティ を高めるようなレコメンドを目指すチーム • pixivのブックマークデータはidが32bit intに 収まらないぐらいの量があるが、これを BigQuery経由でフル活用して精度向上 • 今も順調にpixiv内のアクティビティを 底上げしつつ、知見を生かして周辺サービス への展開に動き始めている
11. • 今までログデータが捨てられていたとして、 それはそのログが生みうる価値が 保持・活用コストよりも小さかったため • クラウドDWHで保持・活用コストが下がり、 機械学習技術で生み出す価値が底上げされ • そうした前提が覆り、データは保持・活用 されなければいけなくなった • 機械学習はもちろん、分析・可視化でも、 保持したぶんは使わなければもったいない データを活用しないわけにはいかなくなる
 11 生データ クラウドDWH 機械学習技術 データ分析 可視化 結果的に ここも 頑張らないと ここが 充実するので
12. 12 データ活用のための組織構造について
 
 

13. データ活用のための組織構造について
 データを活用していくぞ、と方針を定めたときの組織構造の 作り方は、大きく分けて2パターンあると考えています • 少数の専門家が専業でデータを扱う中央集権的な組織構造 • 現場のメンバーが自らデータを扱う民主的な組織構造 それぞれ良し悪しがある 13
14. 14 集権化
 良い
 • 専門家だけがデータに触れるためデー タや分析の信頼性を担保できる • ガバナンスが効く。セキュリティも担保し やすい 悪い
 • 作業依頼が介在しスピードが落ちる • 分析チームが社内全域のドメイン理解 を持たなければならない • 分析の動機を持つ人と作業者が別人で 作業内容にミスマッチが起きがち データ分析・管理の専門チームを置く。 データに直接触れる人は専門家に絞る データ変更 データ抽出 レポーティング ダッシュボード提供 分析依頼 作業依頼
15. 15 民主化
 良い
 • 分析の動機とドメイン理解を併せ持つ 当事者が直接分析を行える • 作業依頼の伝達コストが発生せず、分 析結果も自然に活用される • 近年のクラウドDWHの発達によってこ の形を作りやすくなった 「データの民主化」が注目される一因は、集 権化している場合に直面する主要な課題を 解決できるため 横断で分析や基盤整備を行う担当者は 最小限に留め、当事者が主体となり分析 活動やデータ加工を行う データ抽出 データ変更
16. 16 民主化
 悪い
 • 各部署・各プロダクトの人員にデータリテラシーが必 要になる • 相応の分析基盤を整備し、その運用を平易にしてい くことが必要 • 分析実施者が専門家ではなくなり、分析の質が悪化 したり、誤った手続きを実施してしまう懸念がある • 分析的には必要であっても当事者が必要と感じたこ としか実施されない • データに変更を加える人が多様になりデータの破損 などのリスクがある • 権限の管理をきちんとしないと見えてはいけない人 にデータが見えてしまう • ... 良いことばかりではない。ここには書きき れないぐらい超えるべきハードルがある データ抽出 データ変更
17. ピクシブではどうしたか
 • 民主化の路線を選んだ • データ駆動推進室の立ち上げ ◦ 社内のデータ活用を促進するための小さな チームを立ち上げ ◦ 依頼を受けてこなすのではなく、仕組みを 作ったり各部署に働きかけて自走をサポート ユーザーに価値を最速で届けるために。 ピクシブの「データ民主化」に向けた挑戦 - pixiv inside https://inside.pixiv.blog/jaggy/6421 17
18. 問題山積みでも民主化したい理由
 人員・能率・コスト • 取り組んでいる企業はどこも多かれ少なかれこの点を見ているはず • 集権化構造で高度な専門家チームを独立して持つのはそれだけで大変なコスト • しかもそのコストセンターが前述の伝言ゲームで消耗してしまう • トレンド技術を生かして間を抜けば業務は効率的になる • それができる道が生まれたならチャレンジしなければ 18
19. その他、ピクシブ特有の理由
 • 社員数に対してプロダクト数が多い • 約200名の社員で18種類のプロダクト を回しています • それぞれ特有のドメイン知識も多く、 中央に分析者を集める構成がそもそも 困難だった • いずれも個性的なプロダクトでデータ の特徴もユーザー層も違う • プロダクトに携わる人を主体にしたい 19
20. 20 民主化を選ぶ場合に直面する課題と
 ピクシブでの取り組み
 
 

21. 民主化を目指す上で直面する壁の一例
 • 分析スキル BigQueryを挟む場合、SQLさえ書ければなんとでもなるが、逆に言えば SQLは覚えてもら わないと始まらない。たとえビジネス職であっても。本当に可能？ • データ理解 歴史的経緯の詰まった謎のテーブルと謎のカラム。 エンジニアならソースコードを読めるが、最も分析したい PMはどうすれば... • ガバナンス 誰かが誤って全社KPIに繋がるデータを壊してしまうようなことは避けたい 各部署でオレオレ定義が蔓延して互いに数字が合わなくなるような状況も避けたい 21
22. 目指したい到達点
 • プロダクトチームが自己完結して作業・分析できる仕組みを構築する ◦ データエンジニアやアナリストがいなくても • プロダクトチームが間違えようのない仕組みを構築する ◦ 分析やデータ操作に関するリテラシーが薄くても • プロダクトチームが感じる負荷を極力下げる ◦ データを触るのはめんどくさいと認識されたら詰み 22
23. そのためのデータ駆動推進室の役割
 • プロダクトチームを主役・主体にする • データ駆動推進チームはそのお膳立てに徹する • その範囲でできることをできる限りやってプロダクトの業務負荷を最小化する よくある間違い： データ駆動推進チームが単なる分析・加工の代行チームと化す →それは実質集権化。われわれが直接問題解決してはいけない 23
24. 実際にやったこと
 • データ基盤操作のテンプレート化 • BIツールLookerの導入 • 多様な互助組織の構築 • チュートリアルリソースの整備 24
25. 1. データ基盤操作のテンプレート化
 • 形式に沿って5行書けばプロダクトのDBをとりあえ ずBigQueryにデイリー同期できるembulkスクリプ ト • 中間テーブル構築のための定形 SQLと、それを定 期実行するやはり数行で済むスクリプト • こうしたものをドキュメント化・周知 • 基本的な操作を間違えようのない形にまとめ、部署 で自己完結して実施してもらう 25
26. 2.BIツールLookerの導入
 • LookerというBIツールを導入した • githubリポジトリとして管理され共有される 分析用モデルでガバナンスを確保 ◦ Lookerの特色といえる部分 ◦ プルリクベースで書き換えていくので人の目が 入りオレオレ定義が蔓延しにくい ◦ リポジトリ内を検索して変な記述を見つけたら 突っ込むことも可能 26
27. 2.BIツールLookerの導入
 • 分析スキルがなくても能動的にデータを掘り下げられ る状態を担保 ◦ SQLを覚えてもらうのも難しいが、用意されたダッ シュボードを見るレベルの掘り下げで終わるのも まずい ◦ UI経由でドリルダウンできるタイプの BIツールが どうしても必要 ◦ エンジニアに飛びがちな「クエリ書いてくださ い！」系の割り込みを減らす意味も 27
28. 3. 多様な互助組織の構築
 • 様々な軸で複数の互助組織を構築 • Slackのanalystチャンネル • 200人に満たない会社で134人が参加す る一大勢力 • これってどうすればいいんでしたっけ、と いう話を投げると有識者がよってたかっ て解決してくれる 28
29. 3. 多様な互助組織の構築
 • データエンジニアリング互助会 • 各プロダクトにデータ担当的なエンジニアを立ててもら い、そうした人が集まって情報共有する場として互助会 を定期開催 • データ基盤にこんな要素が増えますとか、これは非推奨 になってこうなりますとか • BigQuery・Lookerにベータ版でこんな機能が出たらしい ですよとか • 共有部分の方針の議論とか 29
30. 3. 多様な互助組織の構築
 • 分析ワクワクタイム • 毎週決まった曜日の決まった時間、オープンスペースに データ駆動推進室メンバーが溜まって待機 • エンジニアもビジネス職も来る、データ基盤の話から KPI設計の話までする • 困ったときの駆け込み寺が成立して心理的ハードルが 下がった（はず） • データ民主化を加速させる「分析ワクワクタイム」 - pixiv inside https://inside.pixiv.blog/minamitary/7407 30
31. 4.チュートリアルリソースの整備
 • 少人数の横断メンバーで済ませるなら非同 期コミュニケーションが不可欠 • 都度個別に口頭で教えてはいられない • 読んでその通りに手を動かしていくとツール の基本的な使い方を理解できるような チュートリアルを組んだり、問題集を作った り 31
32. 取り組みの結果
 • ほぼ全プロダクトでBigQueryやLookerを経由して自走してデータ抽出・加工が行われるよ うになった • データ基盤への繋ぎこみもプロダクト側のエンジニアが自ら実施してくれるようになった • BigQuery上のデータ資産を活用し、プロダクト の機能を向上する取り組みが随所で進み始めた ◦ ランキング計算処理の改善、 レコメンド精度の向上など 32
33. 取り組みの結果
 • 機械学習エンジニアに分析依頼やデータ系の作業依頼が飛ばなくなった • 昔は機械学習系エンジニア→データに強い→分析してもらえる・データを繋ぎ込んでもら えるの認識でアドホック依頼がばしばし飛んでいた • これらの取り組みや、自前で分析できる 人の全社的増加によりほぼ殲滅できた • アドホック依頼から解放された機械学習 エンジニアが振るった腕が前述のレコメ ンドの進歩に寄与 33
34. 34 おわりに
 
 

35. これまでわれわれがやってきたこと
 • 平易なデータ基盤の層を作って全社的にデータを手に取れる状態にした 
 • 各自が主体的にデータを触る組織構造に向けて地盤固めを進めてきた 
 
 • 今できてると言えるのはここまで 
 • まだまだ課題点はたくさん残っている 
 35

36. 道半ばな部分
 • 例えば： ◦ 中間テーブルの管理 ▪ まだ数が多くないので回っているがここから爆発的に増えることが予想され、そ の対策も不完全 ◦ 依存関係の網羅的な把握と異常検知 ▪ データ基盤の不具合がプロダクトの機能に影響しうる状況が生まれる ◦ 非プロダクト系チームへの普及 ▪ 人事、経理、総務など。データの性質と置き場が違い難航 36
37. 道半ばなので
 • 一緒にデータの仕事をしていくメンバーを 募集中です！ • データエンジニア https://www.wantedly.com/projects/282666 • データアナリスト https://www.wantedly.com/projects/198783 • レコメンド（機械学習）エンジニア https://www.wantedly.com/projects/209847 37
38. 会社が違えば環境もそれぞれ
 • 会社ごとのプロダクト構成、組織の構造や規模、いろんな要素があってデータプラット フォームの適切な形が決まっていくはず • そこに向けて取り組んでいく道筋もさまざま • 皆さんの会社での取り組みもぜひ聞かせていただきたいです！ 38