元スライド https://speakerdeck.com/yuzutas0/20180425 統計やらNight!!データマイニングMeet up #2 @ウィルゲート の発表資料です。 refs. http://yuzutas0.hatenablog.com/entry/2018/05/17/083000

1. データ集計業務を
半年で300案件捌いて
見えてきた勘所
2018-04-25
データマイニングMeet up #2
presented by @yuzutas0
https://www.pexels.com/photo/person-holding-chart-and-bar-graph-669612/
1

2. はじめに
2

3. ・Recruit Technologies Co.,Ltd.
・データチームを運営している人です
・データに関することは何でもやっています
自己紹介
3
@yuzutas0

4. 分析するときに必要な データ基盤 について連載中です
宣伝
4
http://www.atmarkit.co.jp/ait/articles/1804/23/news011.html

5. ミッション・業務
5
組織運営
例：データ活用人材を
いかに採用・育成するか
現場ごとのデータ活用支援
例：データ駆動ではない開発現場で
いかに文化・プロセスを装着するか
横断のデータソリューション
例：これまで人が意思決定・手動実施
していた業務をいかにRPA化するか
データ集計
解析・分析
データ基盤
機械学習システム

6. ※人数やプロジェクトは正確ではありません。ざっくりイメージです。外注・兼任も含みます。
チーム・体制
6
各分野のチーフ
Data Scientist, Data Visualization Specialist, Machine Learning Engineer etc…
マネジメント
マーケティング
BI構築
RPA構築
基盤
クレンジング
品質向上
基盤
SRE改善
経営
BI構築
UX
分析モデル構築
インタビュー
CRE
RPA構築
グロースハック
分析支援
Value Value Value Value Value Value Value
プロジェクト
メンバー
意思決定の支援や
業務フローの改善
テクニカル面で支援
メンターとして指導
ROI観点で
優先順位を差配

7. データ活用
7
いろいろやっています

8. データ活用（一部抜粋）
8

9. APP
ツール・システム
9
Google BigQueryというクラウドDWHで
様々なデータを一元管理しています

10. 詳細はこちら
10https://speakerdeck.com/yuzutas0/20170909

11. 本題
11

12. 本日はなすこと
データ集計業務 を
半年で300案件捌いて
見えてきた 勘所
12

13. アジェンダ
1. 集計業務のインパクト
2. データチームを苦しめる悪循環
3. そのダッシュボード、本当に必要ですか？
4. スタートアップ界隈に学ぶ 小さく試す 文化
5. 多産多死を前提としたプラクティス
13

14. もっとデータマイニングっぽい仕事もあるやろ
どうしても集計業務の話をしたい
14

15. アジェンダ
1. 集計業務のインパクト
2. データチームを苦しめる悪循環
3. そのダッシュボード、本当に必要ですか？
4. スタートアップ界隈に学ぶ 小さく試す 文化
5. 多産多死を前提としたプラクティス
15

16. データ活用 で期待されること
16
業務A 業務B 業務C
オペレーション オペレーション オペレーション
意思決定 意思決定 意思決定
顧客価値
バリューストリーム において リターンを上げる or コストを下げる

17. データ活用 は2つに大別できる
例
・RPAによるマーケティング業務やカスタマーサポート業務の一部自動化など
・また、アプリのレコメンド機能は、ユーザーの業務（情報収集→比較検討→意思決定→購買アクション）を支援するソリューションと言える
17
業務A 業務B 業務C
オペレーション オペレーション オペレーション
意思決定 意思決定 意思決定
顧客価値
BI・データ分析
アナリティクス
AP・機械学習
ソリューション
バリューストリーム において リターンを上げる or コストを下げる

18. 基盤の次は データ抽出・集計 フェーズ
18
まだ計測できないものが多い
勘による意思決定
データ基盤への一元化
根拠のある意思決定
業務フローの磨き込み
データ抽出の要望が増える
世に言うデータ活用の本格化
例）先行指標を特定するための高度な分析
例）RPAによる意思決定・作業の自動化
データ基盤の必要性
1 2 3
基盤 BI（初級編） サイエンス・機械学習

19. 抽出・集計 のインパクト①
広告媒体Aと広告媒体Bのどちらに広告を配信するか？
19
※イメージ例です

20. 抽出・集計 のインパクト②
抽出・集計対象のデータを広げるだけで
ちがう結果が見えてくる
20
データソース 集計・計測 分析結果 意思決定
前 アクセス解析ツール
CPAを計測
アクションベース
A > B 媒体Aを重視
後
アクセス解析ツール
＋ 製品データベース
ROASを計測
売上ベース
B > A 媒体Bを重視
※ECサイトで例えると
広告媒体Aはセール品ばかり購入するユーザーを集めている → 利益率が低い

21. データを見る → 行動が変わる → 結果が変わる
データを繋げて可視化するだけで
ビジネス改善のインサイトを得られる（こともある）
抽出・集計 のインパクト③
21
※あくまでも一般的な話です
広告単価あたりの売上 集客に掛ける金額 → 改善インパクト
大
大

22. データ抽出・集計がすごいのはわかった
どんどんやっていけばいいじゃないか
22

23. アジェンダ
1. 集計業務のインパクト
2. データチームを苦しめる悪循環
3. そのダッシュボード、本当に必要ですか？
4. スタートアップ界隈に学ぶ 小さく試す 文化
5. 多産多死を前提としたプラクティス
23

24. データチームの悪循環
24
データ抽出＆集計に
工数を費やしてしまう
もっと攻めた施策を打ちにくい
付加価値を創出できない
便利屋として見られてしまう
便利屋として売り込んでしまう
さらに抽出依頼が寄せられる
抽出依頼ばかりを取りに行く

25. 悪循環を打ち破る
25
データ抽出＆集計に
工数を費やしてしまう
もっと攻めた施策を打ちにくい
付加価値を創出できない
便利屋として見られてしまう
便利屋として売り込んでしまう
さらに抽出依頼が寄せられる
抽出依頼ばかりを取りに行く
作業手順の型化・改善
起案→期待ROI提示
メッセージング
データの民主化

26. 分析担当なら出来てしかるべし
26
データ抽出＆集計に
工数を費やしてしまう
もっと攻めた施策を打ちにくい
付加価値を創出できない
便利屋として見られてしまう
便利屋として売り込んでしまう
さらに抽出依頼が寄せられる
抽出依頼ばかりを取りに行く
作業手順の型化・改善
起案→期待ROI提示
メッセージング
データの民主化
意思決定を促してこそのデータ分析
自分たちの仕事についても
分析して提案を通すべし
理解を促してこそのデータ分析
自分たちの仕事についても
納得感を得られるように伝えるべし
行動を促してこそのデータ分析
自分たちの仕事についても
関係者が行動できるように支援すべし
改善を促してこそのデータ分析
自分たちの仕事についても
課題と解決策を分析すべし

27. （例）データの民主化
27
データ抽出＆集計に
工数を費やしてしまう
もっと攻めた施策を打ちにくい
付加価値を創出できない
便利屋として見られてしまう
便利屋として売り込んでしまう
さらに抽出依頼が寄せられる
抽出依頼ばかりを取りに行く
作業手順の型化・改善
起案→期待ROI提示
メッセージング
データの民主化

28. チームごとの民主化状況
各チームがデータ活用できているかモニタリング → ブロッカーの検知・分析 → 改善アクション
28
チームA チームB チームC チームD チームE チームF チームG チームH チームI チームJ チームK
生ログ
独自利用
データT支援
業務依頼
データT支援
データ出力
自主的
データ出力
担当者依存 担当者依存 担当者依存
自主的
データ生成
他チーム依頼
基盤貢献！ 担当者依存 担当者依存
局所化の壁
自走の壁
改善の壁

29. 民主化を促す取り組み
29
Measure 効果測定 ログ要件、副作用も踏まえた影響ツリー、解釈
Learn 学習 仮説出し、ゴール設定
Culture 文化 日次指標確認、モブデータ分析
System 仕組み化 分析工程の組み込み

30. とはいえボトルネックはここ
30
データ抽出＆集計に
工数を費やしてしまう
もっと攻めた施策を打ちにくい
付加価値を創出できない
便利屋として見られてしまう
便利屋として売り込んでしまう
さらに抽出依頼が寄せられる
抽出依頼ばかりを取りに行く
作業手順の型化・改善
起案→期待ROI提示
メッセージング
データの民主化

31. あらゆるデータをいい感じに見ることのできる
すごいダッシュボードがあれば良いのでは？
データ抽出＆集計をラクにするには？
31

32. アジェンダ
1. 集計業務のインパクト
2. データチームを苦しめる悪循環
3. そのダッシュボード、本当に必要ですか？
4. スタートアップ界隈に学ぶ 小さく試す 文化
5. 多産多死を前提としたプラクティス
32

33. 過去の取り組み
俺の考えた最強の
ダッシュボード
33

34. 現実は非情である
1週間で誰も見なくなった
34

35. 間接部門のアンチパターン
35
https://twitter.com/msmt9/status/778865480379412481

36. 現場で本当に必要だったものは何？
36http://www.projectcartoon.com/

37. ・高度なプログラミングは出来ないけど
SQLならちょっと書ける
・日付の部分だけ手動で書き換えて
ひたすらSQLを叩きまくる
・事務スタッフにも声をかけて
作業を手伝ってもらった
・データさえあれば後はExcelや
Spreadsheetでどうにかできる
現場でWEBディレクターがやっていたこと
37

38. ExcelやSpreadsheetを
活用するのが良さそう
抽象化すると
小さく試すことが大事
データ抽出＆集計をラクにするには？
38

39. アジェンダ
1. 集計業務のインパクト
2. データチームを苦しめる悪循環
3. そのダッシュボード、本当に必要ですか？
4. スタートアップ界隈に学ぶ 小さく試す 文化
5. 多産多死を前提としたプラクティス
39

40. 小さく試す をスタートアップに学ぶ①
金も時間も足りない。どうする？
40

41. MVP：実用最小限の製品
41
自分達のアパートの写真だけを載せたLP
プロダクトを開発せずに…(中略)…
30秒のサービス紹介動画を作り
https://medium.com/@masayukiminato/%E3%81%84%E3%81%8B%E3%81%ABminimum-viable-product%E4%BD%9C%E3%82%8B%E3%81%8B-
twitter%E3%82%84airbnb%E3%82%82%E3%81%AF%E3%81%98%E3%81%BE%E3%82%8A%E3%81%AF%E3%82%B7%E3%83%B3%E3%83%97%E3%83%AB
%E3%81%AA%E3%83%97%E3%83%AD%E3%83%80%E3%82%AF%E3%83%88-dcfc8d854823

42. データ案件もMVPだ
42

43. 43
小さく試す をスタートアップに学ぶ②
とはいえアクセルを踏みたい。どうする？

44. ステージゲート
仮説段階や事業化1年目とステージを区切り、どのステージにいれば擬似的な時価総額はいくらで、
投下する資金額はいくらが適切なのかを簡単に判断できるようにしています。
44
http://hrnabi.com/2017/09/12/15065/

45. データ案件もステージゲートだ
投資
※あくまで例です
フェーズ
45
・工数
・時間
・予算
Check
Go / Stop
Budget
Budget
Budget
【Seed】過去データ
モデル構築＆交差検定
【Series A】並行稼働
実データによる試験
【Series B】商用環境
現場に装着して利益創出
Check
Go / Stop
Check
Go / Stop
Check
Go / Stop

46. 46
小さく試す をスタートアップに学ぶ③
進めるか止めるか判断したい。どうする？

47. 革新会計・リーンキャンバス
売上や利益といった一般的な管理会計で測るのではなく、別の基準（革新会計）で進 を測って
プロジェクトにアカウンタビリティを持たせる仕組みのことです。
47
https://medium.com/@tumada/lean-startup-retrospective-2018-ab291889a797

48. データ案件も革新会計だ
※データ施策向けのフォーマットは模索中
48
STEP2. 効果性
P/S Fit
その課題を解決できるか
STEP3. 効果量
P/M Fit
工数やコストに見合うか
STEP1. 必要性
C/P Fit
本当に解決すべき課題か
https://www.oreilly.co.jp/books/9784873115917/
http://www.shoeisha.co.jp/book/detail/9784798128511

49. アジェンダ
1. 集計業務のインパクト
2. データチームを苦しめる悪循環
3. そのダッシュボード、本当に必要ですか？
4. スタートアップ界隈に学ぶ 小さく試す 文化
5. 多産多死を前提としたプラクティス
49

50. データ抽出・集計の業務
50
データモデル定義
インターフェース設計
目的・背景・制約事項

51. MVPで小さく作る
・要求者は「自分が本当に必要とするデータ」を知らないまま依頼する（業務フローが不明確）
・多くはすぐに使わなくなる＆見なくなる（余分な機能のムダ）
・一部は実運用が進む → 最適IFを提供：正しい要求にもとづいて作り直す
活用側の独自システムやシートが複雑化して保守困難になるので、整理してデータパイプラインに組み込む
51
Minimum
Viable
Product
1. LP型
完成イメージ
2. モックアップ型
簡易フォーマット
3. コンシェルジュ型
手動運用
4. ソリューションα
一部作業の自動化
データモデル
定義
数式モデル 近似数値を仮置き
例）CSVファイルが便利すぎる
・BQ UIからCSVを出力＆受け渡し
・利用者にExcelかSpreadsheetで
手動集計してもらう
例）
・何度も使うなら日次Slackで
CSVを自動配信
・ダッシュボードを欲しがる人
向けにはDatastudioを作って
手渡す
インターフェース
設計
ホワイトボードスケッチ Spreadsheetシート
10minで検証 30minで検証 120minで検証データ抽出案件
http://ec.nikkeibp.co.jp/item/books/P48970.html

52. モックアップ
ホワイトボードやSpreadsheetで
推定される概算値を仮置きして
出力シートをスケッチして
集計・抽出後のユースケースをロールプレイ
52
もしこういう値だったら データを出しても
どういう意思決定になるのか？
→ アクションが変わらなければ
どのくらいのインパクトがあるのか？
→ 工数に効果が見合わなければ
を最初に検証する やる意味がない

53. CSVファイル
無難なインターフェース
・簡易出力 → Excel や Spreadsheet で開いてもらう
・BigQuery UIから手動で受け渡す
・用意したクエリを依頼者自身に叩いてDLしてもらう
53

54. Data Studio
即席のダッシュボード
・簡易作成 → 好きに使ってもらう
・まだ自由度は高くないが簡易モニタリングなら問題なく使える
54

55. 毎朝のSlackでCSVファイルやダッシュボードURLを配信
・用意してあるテンプレートに沿ってプログラミングする
・masterマージすれば翌日から自動で配信される
継続的に使い始めたら自動配信
55

56. 不要になったらクリーニング
大抵は見なくなるので毎週のふりかえりでクリーニングする
そのタイミングで「本当に必要だったデータは何か」を振り返って次に活かす
https://speakerdeck.com/yuzutas0/20180402
56

57. 生き残った案件だけを磨き込む
57
検知タイミング
業務の実態とデータ集計処理が
合わなくなってくるので
・追加や改修の依頼が寄せられる
・魔改造で保守不可になり声が掛かる
対応方針
①ホワイトボード設計からやり直す！
・Model：新しいロジックを検討する
・View：新しいユースケースを整理する
②本格的なデータ施策として案件化する！
・どうしてもMVPでは不都合がある場合
・データ集計後の業務本体を改善する場合
（例：RPA導入）
https://www.irasutoya.com/2013/03/blog-post_490.html https://www.irasutoya.com/2016/09/kj_19.html https://www.irasutoya.com/2017/11/blog-post_19.html

58. スタートアップと同じように
小さくテストしながら、段階的に要求・設計を磨き込んで行く
案件ライフサイクル
58
v1 ホワイトボード
v2 ホワイトボード → Spreadsheetに数値仮置き → 手動CSV受け渡し
v3 ホワイトボード → Spreadsheetに数値仮置き → 手動CSV受け渡し → 自動配信・ダッシュボード
v4 ホワイトボード
v5 ホワイトボード → Spreadsheetに数値仮置き → 手動CSV受け渡し → 自動配信・ダッシュボード

59. 備考
集計処理におけるボトルネック
59

60. データクレンジング
60

61. データクレンジング（暫定対応）
回避策・解決策
後工程・分析後のアクションを踏まえれば回避可能
1. 信頼関係の構築
「仮に現時点で多少モニタリングがズレても後で直してくれるだろう」という関係者からの信頼
※日々の頻繁な改修アナウンスやコミュニケーションが前提
2. ROIの提示
「多少数値がずれているけど今回の目的なら許容範囲だ」
「これを調査するのに1日使うくらいならxxの方が優先だ」の会話
61

62. データクレンジング（恒久対応）
原因・予防策
数値ズレは設計力不足に基づくことが多い（ノイズデータもたまにあるが）
1. 仕様理解
・ドメイン知識：数値ズレを元に詳しい人と話すと解決する → その人の脳内に推定値を出すロジックがある
・データ仕様：ノイズデータのパターンやプロダクトの状況は経験的に学習できる → 慣れによって早くなる
2. 論理的思考
・数理モデル：ロジックの改修前後で数値が一致しないことは数学的に証明できるのに、
気付かずに右往左往したケースがある
62

63. 最後に
63

64. まとめ
これで300案件は達成できました
皆様もできる気がしませんか？
64
最初は 生き残った案件は
・SQLを書いてCSVで渡しまくるだけ
・その作業プロセスは型化→継続改善する
・自分たちも詳しくなっているので
どうにかなる（はず）
・クレンジングもどうにかなる（はず）

65. （機会があればぜひ皆様と一緒に）やりたいこと
※個人の見解です
データ抽出用の独自ツール や データ活用人材の育成メニュー など
ノウハウ一式をパッケージ化して公開したい
抽象論ではなくデータ活用現場で実際に使える粒度のものを……
あちこちで使ってもらう → 国内産業全体におけるデータ活用を促進 → 日本経済を盛り上げたい
50年後に振り返って「あの取り組みがあったから今の日本がある」と思えることをやりたい
65

66. 【宣伝】チームメイト募集中
・データ分析による意思決定でプロダクト開発を支える アナリスト・サイエンティスト
・データ案件推進やデータ駆動文化の醸成を担う ディレクター・業務デザイナー
・データ活用によるソリューション提供で利益創出を目指す APエンジニア・MLエンジニア
・データ基盤の開発・運用におけるベストプラクティスを追求する SREエンジニア
我こそはという方がいらっしゃいましたら、ぜひお気軽に@yuzutas0までお声掛けください。
66

67. ご清聴ありがとうございました
67
https://www.pexels.com/photo/person-holding-chart-and-bar-graph-669612/