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

by Kazuhito Osabe

Slide 1

Slide 1 text

プロダクト中心のデータ駆動を推進していくために必要なこと  pixiv Inc. Kazuhito Osabe 2019.12.02 ピクシブがデータの民主化を目指すまでと、その後の取り組み

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

ピクシブについて(会社とpixiv本体)  3 会社としてのピクシブ「創作活動がもっと楽しくなる場所を創る」をスローガンに多数の事業を運営サービスとしてのpixiv(本体) イラスト、マンガ、小説など創作作品を公開する場社内で最大規模のWebサービスの中にある

Slide 4

Slide 4 text

ピクシブについて(周辺プロダクト)  4 ● ECサイト ● グッズ制作 ● ファンコミュニティ ● 3D事業などなど会社としてのピクシブ「創作活動がもっと楽しくなる場所を創る」をスローガンに多数の事業を運営の中にある

Slide 5

Slide 5 text

今日話すこと  ● いまデータ活用が求められる背景の考察 ● データ活用のための組織構造について（集権化と民主化、その良し悪し） ● 民主化を選ぶ場合に直面する課題とピクシブでの取り組み ● おわりに 5

Slide 6

Slide 6 text

6 いまデータ活用が求められる背景の考察     

Slide 7

Slide 7 text

● 個人としてどう考えているかの話です ● データプラットフォームに関する話題が一般化し勉強会なども増え、参加者の層も広がっている ● なぜだろうか ● データプラットフォームの構成要素のうち、近年で大きく動いた部分はおそらくこの2箇所なぜ今データプラットフォームなのか  7 生データクラウドDWH 機械学習技術データ分析可視化ここここと

Slide 8

Slide 8 text

8 クラウドDWH  もたらす変化  ● 価格的にも運用的にも低コストでデータの全数保持・全数活用が可能になる ● 「不要なデータ」の減少、ログを捨てるより保持するべきケースの増加 ● その結果として企業が管理するデータ資産の総量の増加 ● それを加工するデータパイプラインも複雑化生データと活用現場の間に挟まる低コストの抽象化＆データ蓄積層生データクラウド DWH 機械学習技術データ分析可視化

Slide 9

Slide 9 text

機械学習技術  データの価値産出の道筋が増加より広い層に活用される 9 もたらす変化  ● 分析プロセスを経由しなくても、データ単体で価値産出する道が生まれてくる ● 自動最適化、推薦など。収益の向上はもちろん、単体でユーザーに価値提供する機能になったりもする ● その恩恵が研究開発系の企業だけではなく一般Web企業まで降りてくる生データクラウド DWH 機械学習技術データ分析可視化

Slide 10

Slide 10 text

ピクシブでのビッグデータ×機械学習  10 ● レコメンドチーム ● pixiv本体を中心に、ユーザーのアクティビティを高めるようなレコメンドを目指すチーム ● pixivのブックマークデータはidが32bit intに収まらないぐらいの量があるが、これを BigQuery経由でフル活用して精度向上 ● 今も順調にpixiv内のアクティビティを底上げしつつ、知見を生かして周辺サービスへの展開に動き始めている

Slide 11

Slide 11 text

● 今までログデータが捨てられていたとして、それはそのログが生みうる価値が保持・活用コストよりも小さかったため ● クラウドDWHで保持・活用コストが下がり、機械学習技術で生み出す価値が底上げされ ● そうした前提が覆り、データは保持・活用されなければいけなくなった ● 機械学習はもちろん、分析・可視化でも、保持したぶんは使わなければもったいないデータを活用しないわけにはいかなくなる  11 生データクラウドDWH 機械学習技術データ分析可視化結果的にここも頑張らないとここが充実するので

Slide 12

Slide 12 text

12 データ活用のための組織構造について     

Slide 13

Slide 13 text

データ活用のための組織構造について  データを活用していくぞ、と方針を定めたときの組織構造の作り方は、大きく分けて2パターンあると考えています ● 少数の専門家が専業でデータを扱う中央集権的な組織構造 ● 現場のメンバーが自らデータを扱う民主的な組織構造それぞれ良し悪しがある 13

Slide 14

Slide 14 text

14 集権化  良い  ● 専門家だけがデータに触れるためデータや分析の信頼性を担保できる ● ガバナンスが効く。セキュリティも担保しやすい悪い  ● 作業依頼が介在しスピードが落ちる ● 分析チームが社内全域のドメイン理解を持たなければならない ● 分析の動機を持つ人と作業者が別人で作業内容にミスマッチが起きがちデータ分析・管理の専門チームを置く。データに直接触れる人は専門家に絞るデータ変更データ抽出レポーティングダッシュボード提供分析依頼作業依頼

Slide 15

Slide 15 text

15 民主化  良い  ● 分析の動機とドメイン理解を併せ持つ当事者が直接分析を行える ● 作業依頼の伝達コストが発生せず、分析結果も自然に活用される ● 近年のクラウドDWHの発達によってこの形を作りやすくなった「データの民主化」が注目される一因は、集権化している場合に直面する主要な課題を解決できるため横断で分析や基盤整備を行う担当者は最小限に留め、当事者が主体となり分析活動やデータ加工を行うデータ抽出データ変更

Slide 16

Slide 16 text

16 民主化  悪い  ● 各部署・各プロダクトの人員にデータリテラシーが必要になる ● 相応の分析基盤を整備し、その運用を平易にしていくことが必要 ● 分析実施者が専門家ではなくなり、分析の質が悪化したり、誤った手続きを実施してしまう懸念がある ● 分析的には必要であっても当事者が必要と感じたことしか実施されない ● データに変更を加える人が多様になりデータの破損などのリスクがある ● 権限の管理をきちんとしないと見えてはいけない人にデータが見えてしまう ● ... 良いことばかりではない。ここには書ききれないぐらい超えるべきハードルがあるデータ抽出データ変更

Slide 17

Slide 17 text

ピクシブではどうしたか  ● 民主化の路線を選んだ ● データ駆動推進室の立ち上げ ○ 社内のデータ活用を促進するための小さなチームを立ち上げ ○ 依頼を受けてこなすのではなく、仕組みを作ったり各部署に働きかけて自走をサポートユーザーに価値を最速で届けるために。ピクシブの「データ民主化」に向けた挑戦 - pixiv inside https://inside.pixiv.blog/jaggy/6421 17

Slide 18

Slide 18 text

問題山積みでも民主化したい理由  人員・能率・コスト ● 取り組んでいる企業はどこも多かれ少なかれこの点を見ているはず ● 集権化構造で高度な専門家チームを独立して持つのはそれだけで大変なコスト ● しかもそのコストセンターが前述の伝言ゲームで消耗してしまう ● トレンド技術を生かして間を抜けば業務は効率的になる ● それができる道が生まれたならチャレンジしなければ 18

Slide 19

Slide 19 text

その他、ピクシブ特有の理由  ● 社員数に対してプロダクト数が多い ● 約200名の社員で18種類のプロダクトを回しています ● それぞれ特有のドメイン知識も多く、中央に分析者を集める構成がそもそも困難だった ● いずれも個性的なプロダクトでデータの特徴もユーザー層も違う ● プロダクトに携わる人を主体にしたい 19

Slide 20

Slide 20 text

20 民主化を選ぶ場合に直面する課題と  ピクシブでの取り組み     

Slide 21

Slide 21 text

民主化を目指す上で直面する壁の一例  ● 分析スキル BigQueryを挟む場合、SQLさえ書ければなんとでもなるが、逆に言えば SQLは覚えてもらわないと始まらない。たとえビジネス職であっても。本当に可能？ ● データ理解歴史的経緯の詰まった謎のテーブルと謎のカラム。エンジニアならソースコードを読めるが、最も分析したい PMはどうすれば... ● ガバナンス誰かが誤って全社KPIに繋がるデータを壊してしまうようなことは避けたい各部署でオレオレ定義が蔓延して互いに数字が合わなくなるような状況も避けたい 21

Slide 22

Slide 22 text

目指したい到達点  ● プロダクトチームが自己完結して作業・分析できる仕組みを構築する ○ データエンジニアやアナリストがいなくても ● プロダクトチームが間違えようのない仕組みを構築する ○ 分析やデータ操作に関するリテラシーが薄くても ● プロダクトチームが感じる負荷を極力下げる ○ データを触るのはめんどくさいと認識されたら詰み 22

Slide 23

Slide 23 text

そのためのデータ駆動推進室の役割  ● プロダクトチームを主役・主体にする ● データ駆動推進チームはそのお膳立てに徹する ● その範囲でできることをできる限りやってプロダクトの業務負荷を最小化するよくある間違い：データ駆動推進チームが単なる分析・加工の代行チームと化す →それは実質集権化。われわれが直接問題解決してはいけない 23

Slide 24

Slide 24 text

実際にやったこと  ● データ基盤操作のテンプレート化 ● BIツールLookerの導入 ● 多様な互助組織の構築 ● チュートリアルリソースの整備 24

Slide 25

Slide 25 text

1. データ基盤操作のテンプレート化  ● 形式に沿って5行書けばプロダクトのDBをとりあえずBigQueryにデイリー同期できるembulkスクリプト ● 中間テーブル構築のための定形 SQLと、それを定期実行するやはり数行で済むスクリプト ● こうしたものをドキュメント化・周知 ● 基本的な操作を間違えようのない形にまとめ、部署で自己完結して実施してもらう 25

Slide 26

Slide 26 text

2.BIツールLookerの導入  ● LookerというBIツールを導入した ● githubリポジトリとして管理され共有される分析用モデルでガバナンスを確保 ○ Lookerの特色といえる部分 ○ プルリクベースで書き換えていくので人の目が入りオレオレ定義が蔓延しにくい ○ リポジトリ内を検索して変な記述を見つけたら突っ込むことも可能 26

Slide 27

Slide 27 text

2.BIツールLookerの導入  ● 分析スキルがなくても能動的にデータを掘り下げられる状態を担保 ○ SQLを覚えてもらうのも難しいが、用意されたダッシュボードを見るレベルの掘り下げで終わるのもまずい ○ UI経由でドリルダウンできるタイプの BIツールがどうしても必要 ○ エンジニアに飛びがちな「クエリ書いてください！」系の割り込みを減らす意味も 27

Slide 28

Slide 28 text

3. 多様な互助組織の構築  ● 様々な軸で複数の互助組織を構築 ● Slackのanalystチャンネル ● 200人に満たない会社で134人が参加する一大勢力 ● これってどうすればいいんでしたっけ、という話を投げると有識者がよってたかって解決してくれる 28

Slide 29

Slide 29 text

3. 多様な互助組織の構築  ● データエンジニアリング互助会 ● 各プロダクトにデータ担当的なエンジニアを立ててもらい、そうした人が集まって情報共有する場として互助会を定期開催 ● データ基盤にこんな要素が増えますとか、これは非推奨になってこうなりますとか ● BigQuery・Lookerにベータ版でこんな機能が出たらしいですよとか ● 共有部分の方針の議論とか 29

Slide 30

Slide 30 text

3. 多様な互助組織の構築  ● 分析ワクワクタイム ● 毎週決まった曜日の決まった時間、オープンスペースにデータ駆動推進室メンバーが溜まって待機 ● エンジニアもビジネス職も来る、データ基盤の話から KPI設計の話までする ● 困ったときの駆け込み寺が成立して心理的ハードルが下がった（はず） ● データ民主化を加速させる「分析ワクワクタイム」 - pixiv inside https://inside.pixiv.blog/minamitary/7407 30

Slide 31

Slide 31 text

4.チュートリアルリソースの整備  ● 少人数の横断メンバーで済ませるなら非同期コミュニケーションが不可欠 ● 都度個別に口頭で教えてはいられない ● 読んでその通りに手を動かしていくとツールの基本的な使い方を理解できるようなチュートリアルを組んだり、問題集を作ったり 31

Slide 32

Slide 32 text

取り組みの結果  ● ほぼ全プロダクトでBigQueryやLookerを経由して自走してデータ抽出・加工が行われるようになった ● データ基盤への繋ぎこみもプロダクト側のエンジニアが自ら実施してくれるようになった ● BigQuery上のデータ資産を活用し、プロダクトの機能を向上する取り組みが随所で進み始めた ○ ランキング計算処理の改善、レコメンド精度の向上など 32

Slide 33

Slide 33 text

取り組みの結果  ● 機械学習エンジニアに分析依頼やデータ系の作業依頼が飛ばなくなった ● 昔は機械学習系エンジニア→データに強い→分析してもらえる・データを繋ぎ込んでもらえるの認識でアドホック依頼がばしばし飛んでいた ● これらの取り組みや、自前で分析できる人の全社的増加によりほぼ殲滅できた ● アドホック依頼から解放された機械学習エンジニアが振るった腕が前述のレコメンドの進歩に寄与 33

Slide 34

Slide 34 text

34 おわりに     

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

道半ばな部分  ● 例えば： ○ 中間テーブルの管理 ■ まだ数が多くないので回っているがここから爆発的に増えることが予想され、その対策も不完全 ○ 依存関係の網羅的な把握と異常検知 ■ データ基盤の不具合がプロダクトの機能に影響しうる状況が生まれる ○ 非プロダクト系チームへの普及 ■ 人事、経理、総務など。データの性質と置き場が違い難航 36

Slide 37

Slide 37 text

道半ばなので  ● 一緒にデータの仕事をしていくメンバーを募集中です！ ● データエンジニア https://www.wantedly.com/projects/282666 ● データアナリスト https://www.wantedly.com/projects/198783 ● レコメンド（機械学習）エンジニア https://www.wantedly.com/projects/209847 37

Slide 38

Slide 38 text

会社が違えば環境もそれぞれ  ● 会社ごとのプロダクト構成、組織の構造や規模、いろんな要素があってデータプラットフォームの適切な形が決まっていくはず ● そこに向けて取り組んでいく道筋もさまざま ● 皆さんの会社での取り組みもぜひ聞かせていただきたいです！ 38