2020-09-16 Data Engineering Study #3「分析基盤をうまく組織に浸透させる方法」 #DataEngineeringStudy
2020/09/16 に開催された Data Engineering Study #3 「分析基盤をうまく組織に浸透させる方法」のイベントレポートです。
●イベント概要
プログラム第3回「分析基盤をうまく組織に浸透させる方法」
データ分析基盤というものは、作ったら終わりではありません。基盤を作り上げた後は、頑張って貯めたログをビジネスに活用したり、基盤を利用する社内ユーザーを育成する「啓蒙」フェーズが始まります。むしろ作ってからが始まりなのです。
このセッションでは、分析基盤を上手く組織に浸透させる方法について、基調講演ではData Pipeline Casual Talkの主催者である伊藤様に道先案内人を務めて頂きます。
事例講演では、0→10の立ち上げフェーズの事例としてエウレカ鉄本氏、10→100の拡大フェーズの事例としてDeNA長谷川氏を迎え、各社の具体的な事例から学びます。
■データ分析基盤の浸透に必要なこと
伊藤 徹郎 さん [Data Pipeline Casual Talk主催者]
●自己紹介
・著書
データサイエンティスト養成読本ビジネス活用編
・運営
Data Pipeline Casual Talk
Machine Learning Casual Talks
Data Analyst Meetup Tokyo
●過去のイベントで学んだこと
・#1 DWHやBIツール
・#2 データ収集基盤や整備
・最初に描いた基盤は、おそらく使われない
●データ分析基盤の関係者が必ず通る道
・苦労して基盤を作ったのに利用されない
・ほしいと言われたダッシュボードも、最初しか使われない
・様々な指標を分析できるようにしたが、何を見ていいかわからない
・パイプラインを整理したら、いろいろな部署から苦情が来る
●使われない原因
・現場のニーズに合ってない
・ビジネスバリュープロセスにデータ活用が組み込まれていない
・要望はスポットのニーズだった
・ユーザーが利用したい時に最新のデータが連携されていない
・どこに何の情報があるのかわからない
データ分析基盤を組織に浸透させる銀の弾丸はない
●組織にデータ分析基盤が浸透した状態をどう定義するか？
・理想の状態の一つは天気予報
外出時に意思決定
配信時間が決まっている
・組織内の人がどう活用するかを定義
●価値提供サイクル
・天気予報を見る
転記状況の確認
時間別降水確率を確認
傘を持つ開始決定
行動
ふりかえり
傘をさしたか、ささなかったか
どんなときには傘を持っていくか
折りたたみ傘にするか
→ 組織内のどの程度の人たちが活用できている状態を目指すのか
・ダッシュボードを見る
KPIの確認
特定セグメントを確認
施策立案
実行
効果検証
→ 業務上のサイクルに組み込まれていれば利用される
●浸透するためには
・戦略
・データマネジメント
●戦略の構成要素
・診断
状況を診断し、取り組むべき課題を見極める
・基本方針
見つかった課題に対する総合的な方針
・行動
方針を実行する一貫した行動
●診断
・組織のデータ利用者数の把握
・クエリと用途の把握
・利用の多いテーブルの傾向
ロングテールをどうするかは考慮が必要
・部署別の利用状況の可視化
・利用状況のKPI
何を持って浸透したとするか
・組織サーベイ
●基本方針
・データ利用で価値を最大化させているユースケースを特定
・成功事例を転用していく
・部署/役割により価値は様々
いろいろなユースケースに適応できるように設計
・優先順位づけ
顧客に近い、価値を出しやすいところから
●行動
・Modelで処理を共通化
・Viewで個別のユースケースに適応
・Viewによるツールは利用者に合ったものに順次対応
・品質の担保も
●DAMAデータマネジメントフレームワーク
・右のライフサイクル管理
つくってきたから理解しやすいかもしれない
・左をつくっていかなければならない
データマネジメント
ガバナンス
アクティビティ
→ 狭義の非機能要件
●浸透していくと
・利用者が浸透してくると多種多様なニーズ対応が必要
SoR→SoE
正しいものを正しくつくる
・DevだけでなくOpsの観点が重要
DataOps
・利用実態に見合った開発組織体制になっているか
予算、人員、権限、スパン・オブ・コントロール
・詳細は
DMBOK
データマネジメントが30分で分かる本
●浸透するには？
・データ活用を企業戦略に組み込む
・業務フローに組み込まれている
・データ基盤がマネジメントできている
↓
・ボトムアップだけでは限界がある
トップの協力が不可欠
●創発戦略
・マネジャーの実像
トップダウンとボトムアップがぶつかり合う場所が重要
●事例：ワークマン
・ワークマンはなぜ2倍売れたのか
新しいCIOが着任
徹底的に標準化
全自動発注システム
裏では高度な予測が動いている
データ経営という戦略
昇進要件にデータ分析を必須化
出店計画もA/Bテスト
●QA
・分析基盤整備に費用がかかることをビジネス部署に理解してもらうには？
ビジネス部署と信頼関係を築くことが先
いきなり金額の根拠を話しても伝わらない
一緒にビジネスを成長させる仲間だと認識してもらう
マーケにデータを活用していきたい場合
マーケの目標が先にあって
目標に向けて仮説を検証するためにデータを活用していく
顕在化するかはわからないが、必ず組織に課題は存在する
課題を見つけに行く
・データアナリストに望む基盤に関する最低限の技術知識はなんですか？
BI、MLの知識を持っているはず
データパイプラインを理解してもらうと動きやすさはある
ビジネスがわかっていて、巻き込めると良い
会話ができて一緒に仕事ができることが前提
通信やセキュリティも知っていたら良いけど
最低限はアナリストの業務ができること
勉強する時間があるなら、その時間で
顔を突き合わせて離した方が早いかもしれない
わからないことがあったら質問するのが早そう
■スポンサーセッション forkwell
■Data Platform 運用推進事例とこれから
鉄本 環 さん [Eureka]
●Eurekaの BI Team と Data Platform
・BI Team
AI Teamの隣
CTOの下
Engineering要素が強め
Biz/Prod両軸でデータ活用に関わる
・BI TeamのMission
Dicision Making Reliability
高度な意思決定
分析を効率化
指標の作成や予測・評価に集中
意思決定を効率化
過去の意思決定を蓄積
知見を集約、再現性をもたせる
・Data Platformの立ち位置
アナリストとステークホルダーの間
意思決定のエコシステムを目指している
・アーキテクチャ設計
Google Cloud ComposerでDWH/DMを構築
●Data Platform運用のこれまで
・3ヶ月くらいで構築して解散
・アナリストが有志でコミュニティ化
・施策：品質と効率
1名以上からのreviewを必須化
SQL, workflow自動テスト
・施策：知ってもらう
毎日昼会
→共有会
→ふりかえり会
・施策：データ活用の進め方
定例のレポートから展開
接触頻度が上がる
BIツールの理解、興味関心を高める
現場には細かい粒度
CXO/VPにはサービス全体の大きな粒度
→ 自発的にTebleauレクチャー会を催す利用者も出てきた
・課題
DWH/DMが拡充され、利用者が増え続ける未来を描いていた
浸透が停滞しはじめる
・融資による改善運用の限界
リソースを投資し続ける価値が組織的に実感されていない
●Data Platform運用のこれから
・Team内外で浸透の対象を切り分け
Team内
Analyst/Data Engineerの業務として再定義
Analystの業務プロセスでDWH/DMの拡充をこみこみ
Data Engineerはworkflow改善に集中
Team外
既存の成果物の価値を最大化
・Team内外で共通認識をつくっておかないと板挟みに
活動をふりかえり
会社のvisionを達成する上でのBI Teamのあり方
そのためのData Platformのあり方
・Analystの業務プロセスを変更
利用傾向の分析とDWH/DM構築を並走していた
レポートをつくるためにDWH/DMをつくることを直列に組み込んだ
・組織、アナリストそれぞれにロードマップ
組織：利用価値の最大化
Tableau認知拡大
既存指標のTableau化
運用ルール
利用者教育
アナリスト：開発の効率化
リファクタ
依存関係解消
テンプレ化
開発者拡充
・組織への広め方
基盤自体は短期集中で作りきってしまう
成果物は接触頻度の高いものから展開
・今後
意思決定 → AI Team にも活用してもらう
●QA
・データ分析を行っていなかった組織にデータ基盤を広めるには？
分析していないところで基盤を作ると失敗する
データ分析からはじめる
データの整理から入る
データ活用が成果につながるところを見つける
・どうしたら分析基盤を支えるエンジニアを増やすことができるか？
有志メンバーはみんなanalyst
つらいから直したい、楽にしたい
だんだん深いところに入っていった
支えるならまずは使う側に関わってもらうのが良い
エンジニアリングできるアナリストだった
コアな部分はSREを巻き込んだ
SREを巻き込むポイントならデリバリーの相談から
データドリブンな文化が会社にある
エンジニアがデータに触れる機会があった
エンジニア上がりのアナリストも結構いた
・現場を動かすコツ/ポイントは？
大切なのは同じ課題感を持つこと
その現場に入っていく
プロセスを一緒に書き出す
課題が見えるので、自動化や基盤づくりの話へ
マーケの例
広告運用
大きな粒度のデータで運用していた
細かく見れれば、細かい投資が考えられる
レポートを把握しにいった
細かいデータを見た方が、施策を考えやすい、とか
週次が日次で見れれば、もっと細やかに対応できるのでは、とか
■スポンサーセッション primeNumber
■分析基盤と組織のあり方 DeNAの事例
長谷川 了示 さん [DeNA]
●DeNAの組織形態
・多角化経営の組織形態
事業部制
メリット
事業内で目標・前提情報を共有しやすい
素早い意思決定
デメリット
事業部感で経営資源の取り合い、重複
知識共有しにくい
機能別
メリット
専門性を高めやすい
経営資源を融通しやすい
デメリット
事業の目標前提が共有しづらい
マトリクス
メリット
いいとこ取り
デメリット
指揮系統が分かれるので管理しづらい
・DeNAでの組織形態
事業部制+機能別のハイブリッド
ゲーム・エンタメから始まったが、データ分析が全社共通になった
●DeNAの分析基盤と基盤組織の歴史
・分析基盤ができる前
データに基づきサービスを改善
RDBやExcel
立ち上げのきっかけ
ゲーム事業が急成長
データ分析の価値も高まった
アナリストとエンジニア一体の組織を立ち上げ
オンプレ分析基盤発展期
全社共通の部門に再編
機能別にチームを分けて特化
hadoopの高速化
BI/ETLツールの内製でより楽に
アナリストは事業部に残った
全社で利用される基盤へ
BIツールのMAUは社員の40%+
・現在進行中の改革
分析基盤の刷新
基盤組織の刷新
・分析基盤の刷新
構築してきた分析基盤が事業の妖精を満たせなくなってきた
新しい技術を素早く取り入れたい
事業ごとに環境を柔軟にカスタマイズしたい
パブリッククラウドで分析基盤を全面刷新
・基盤組織の刷新
事業との距離感を感じるようになった
事業側と依頼→対応の関係になりがち
基盤の立ち上げ/発展期は、技術獲得・深耕で機能別
運用フェーズに入って、フィットしなくなってきた
事業部側にデータエンジニア組織ができるケースが出てきた
事業、事業のデータエンジニア、分析基盤でコミュニケーション
似たようなものをつくってしまうことも
形としては機能別組織
チームを目的別に再編
注力事業のデータ活用支援
民主化推進・ガバナンス強化
ツール・基盤開発
・クラウドを活用して工数配分を再構成
運用工数を減らし、事業やデータ活用の工数を増やす
事業部、機能別どちらが良いということではない
常に最適な組織形態を模索し続けていく
●QA
・ゲーム事業部以外でも同じような感じ？
ゲームが7割以上
他の事業と規模が違うので温度感の差はある
・組織変更をする決定的なきっかけは？
ひとつの出来事ではなかった
メンバーとの1on1、日々の会話からつらみを感じることが多かった
クラウド移行というきっかけはあった
組織hの課題は溜まっていたので、組織はそのままで良いの？になった
・クラウド移管の観点は？
分析だとデータベースが重要
BigQuery良いよねが前にあった
BigQueryを中心に考えて今の形に
・スケール的にユーザー側の組織体制の変更も大変そう
どう対応していく？
GSuiteにロック飲されている
GoogleGroupで権限管理されている
ユーザー側で権限管理している
LDAPとの連携もできているので、助けられている
新しいしくみを入れるときも、この権限管理に繋げられるかを考える
LookerでもバッチでGoogleGroupと同期したりしている
■感想
私はアプリケーション開発者を支援するプラットフォームに関わることが多いのですが「利用者を顧客として、プラットフォームをプロダクトとして捉える」「企画/マーケ/セールス/カスタマーサクセス/サポート/運用/開発を仮説検証で回していく」ということは、データ分析基盤でも同じだなと改めて感じました。
登壇者の皆さん、運営の皆さん、ありがとうございました！
いつも応援していただいている皆さん支えられています。