事業のグロースを支えるDataOpsの現場 #DataOps #DevSumi #デブサミ / 20180727

Developers Summit 2018 Summer 【C-1】の発表資料です。
https://event.shoeisha.jp/devsumi/20180727/session/1764/

データの民主化、データ基盤の構築、分析チームの立ち上げ、機械学習プロジェクト。世を見渡せばキラキラした事例に溢れています。
しかし、いざ自分たちでやろうとしてもなかなか上手くいきません。理想に辿り着くためには、泥臭い過程が存在します。

本セッションでは「登り方や道のりを知りたいんだ！」という方に向けて、DataOpsの観点から案件・システム・プロセス・文化・組織をエンジニアリングしてきた現場のリアルをご紹介します。
データ活用に携わる全てのエンジニアが今すぐ行動するためのヒントを持ち帰っていただければ幸いです。

以下のブログで補足・裏話を掲載しています。
- http://yuzutas0.hatenablog.com/entry/2018/08/13/083000
- https://recruit-tech.co.jp/blog/2018/08/10/developers_summit_summer2018/

追記：数あるセッションの中で、最速満席＆アンケート満足度No.1（翌年のベストスピーカー賞に相当）をいただきました。誠にありがとうございます！

Transcript

1. 事業のグロースを支える DataOpsの現場 2018-07-27 Developers Summit 2018 Summer presented by @yuzutas0 https://www.pexels.com/photo/abstract-art-blur-bright-373543/
2. はじめに 2
3. 本日の資料はWEBに公開します #devsumi 撮影・記録の必要はありません くつろいで聴いていただければと思います 3
4. スライド 260+ 枚 / 45min （知見をがっつり共有します） ・疲れると思うので、興味のある部分をメインで聞いてください ・飛ばしながら進めるので、細かいところは後で読んでください ・ちょっとだけ盛ってるところもあるけど気にしないでください 4
5. どう考えても無理なので どのトピックに興味があるか 後ほど伺います 5
6. Sho Yokoyama @yuzutas0 　　　 　　リクルートテクノロジーズ 　　 ITエンジニアリング本部 プロダクトエンジニアリング部 　　　ベンチャーキャピタルから投資を受けての起業・会社経営、 　　　リクルートグループ会社における複数の新規事業の立ち上げを経て、現職。 　　　主に急成長プロダクトを対象に、システムアーキテクチャの再構築や 　　　エンジニアチームの立ち上げ・立て直しに従事。 　　　最近は「現場で使われるデータ基盤」を軸に、 　　　組織全体におけるデータ活用を推進しています。 6
7. 過去の資料 本日の内容と重複するところが多々あります 7 http://www.atmarkit.co.jp/ait/articles/1804/23/news011.html https://speakerdeck.com/yuzutas0
8. 失敗や苦労を重ねてきました 8 どれだけ作り込んでも 誰も見なかったダッシュボード データを綺麗に描画するだけでは 足りないらしい 納品から半年経っても本番に 乗らなかったMLスクリプト 機械学習エンジニアの召喚だけでは 足りないらしい データ基盤整備のために 読み解いた膨大なExcelシート DWHシステムを導入するだけでは 足りないらしい
9. 理想に辿り着くためには、泥臭い過程が必要だった 華やかなキラキラ事例とのギャップ 9 世を見渡せばキラキラした事例にあふれている いざ自分たちでやろうとすると失敗だらけ データの民主化 データ基盤の構築 分析チームの立ち上げ 機械学習プロジェクト
10. 世の流れも やってみた から “価値創出・運用” 志向 に 10 https://mlxse.connpass.com/event/80434/ http://kskbyt.hatenablog.jp/entry/2018/02/17/222015
11. 象徴的な言葉が “DataOps” Better data management leads to better — and more available — data. More and better data leads to better analysis, which translates into better insights, business strategies, and higher profitability. DataOps strives to foster collaboration between data scientists, engineers, and technologists so that every team is working in sync to leverage data more appropriately and in less time. https://www.datascience.com/blog/what-is-dataops 11 https://medium.com/data-ops http://dataopsmanifesto.org/
12. あえて言うなら DevOps の データ活用版 DevOps: Dev（システム開発者）と Ops（システム運用者）の協働に端を発した全体最適のパラダイム と解釈して今回は話を進めます 参考「経営のアジリティを支える DevOpsと組織」（Developers Summit 2015 Summer） https://www.slideshare.net/recruitcojp/devops-51085988 DataOps: Data（データ）とOps（業務）を結びつけることによって価値創出を最大化するパラダイム と解釈して今回は話を進めます 12
13. 本セッションで想定する対象 ・結果ではなく「登り方・道のりを知りたいんだ！」という方 ・ビジネスでデータ活用に携わるソフトウェアエンジニア 13
14. 本日お伝え すること / しないこと 知識 個々のテクノロジーや開発手法の詳細 DataOps is not tied to a particular technology, architecture, tool, language or framework. by https://en.wikipedia.org/wiki/DataOps 事例 案件・システム・プロセス・文化・組織を エンジニアリングしてきた現場のリアル（要するに苦労話） 14
15. DataとOpsを繋げる話です 15 http://simpleicon.com/gear-7.html データ と 作業（業務） を繋げる話です テクノロジー と ビジネス現場 を繋げる話です データを活用することで 誰のどんな課題を解決するのか と問い直した話です
16. とはいえ、今も試行錯誤の日々です 16 　まだまだ新参者です。 　・発表者自身（@yuzutas0）がデータ活用の推進を始めて 1.5年 弱 　・正式な部隊を立ち上げてから 0.5年 + α 　・前を進んでいる方 には、振り返りや見直しの機会 を 　・これからの方 や 始めたばかりの方 には、0.5歩先の知見 を 　提供できればと思っています
17. 本日のゴール いますぐに行動できるヒントを持ち帰っていただくこと 17
18. アジェンダ 背景　①プロダクト・チーム　②データ活用事例 案件　①KPIモニタリング　②業者・不正ユーザー対策　③集客広告配信 プロセス　①データ抽出・集計　②機械学習プロジェクト 基盤　①ViewとModelの分離　②データの信頼担保　③使われるための保守・運用 チーム　①運営の安定化　②採用・育成・アウトソース　③体制拡大による痛み 文化　①Measureから始める　②組織に浸透させる　③非エンジニアの壁を壊す 18
19. どう考えても無理なので どのトピックに興味があるか 後ほど伺います 19 リマインド
20. アジェンダ 背景　①プロダクト・チーム　②データ活用事例 案件　①KPIモニタリング　②業者・不正ユーザー対策　③集客広告配信 プロセス　①データ抽出・集計　②機械学習プロジェクト 基盤　①ViewとModelの分離　②データの信頼担保　③使われるための保守・運用 チーム　①運営の安定化　②採用・育成・アウトソース　③体制拡大による痛み 文化　①Measureから始める　②組織に浸透させる　③非エンジニアの壁を壊す 20
21. プロダクト・チーム 21
22. プロダクト 22 婚活 恋活 http://www.recruit-mp.co.jp/service/zexy.html
23. 利用の流れ 23 月額課金モデル　※恋結び女性ユーザーは本人確認料のみ STEP 1 STEP 2 STEP 3 気になったら「いいね！」 お互いにいいね！でマッチング メッセージでやりとり開始
24. 市場はグロース期 ・米国では結婚したカップルの 1/3がオンラインでの出会い ・他ドメインの大規模サービスに比べて、チームやプロダクトとしてはまだ発展途上のフェーズ 24
25. ほか：スタッフ用の業務管理ツールなどのサブシステム システム概略（カスタマー向けアプリ） 25
26. データ基盤 26
27. データ基盤 担当現場ではBigQueryというソリューションを利用 ・他ツールではそのまま再現できない手法も出てきます ・各自の環境に照らしながら聞いていただければと思います 27 Google Cloud 発表資料より引用
28. ステークホルダー 社内かつ現場レイヤー（サービスとしての開発・運用業務を実際に担当している方々） 28
29. データチーム 29
30. 知見の横展開 婚活事業におけるデータ活用 　　　婚活データチーム（通称 D4C） 知見を他事業に展開 横断研究会（ゆるキバン△ DataOpsプロジェクト） 30 https://recruit-holdings.co.jp/ir/library/upload/annual_2016_04.pdf 世界でも有数のボトムアップ型のデータ組織（自称） ・トップダウンで体制が作られたのではなく、有志が現場の事例を積み重ねて仕組みを作っている ・本日は社内横断研究会でレポートされた知見・事例の一部をお伝えします
31. アジェンダ 背景　①プロダクト・チーム　②データ活用事例 案件　①KPIモニタリング　②業者・不正ユーザー対策　③集客広告配信 プロセス　①データ抽出・集計　②機械学習プロジェクト 基盤　①ViewとModelの分離　②データの信頼担保　③使われるための保守・運用 チーム　①運営の安定化　②採用・育成・アウトソース　③体制拡大による痛み 文化　①Measureから始める　②組織に浸透させる　③非エンジニアの壁を壊す 31
32. データ活用事例 32 ※検証段階のものやスポットでの取り組みを含んでおります
33. KPIモニタリング ビジネス指標（売上や Daily Active User）の推移 33 毎朝のSlack通知 Spreadsheet ダッシュボード
34. ユーザー行動の可視化 主要導線（会員登録から成婚退会まで）における利用・離脱 34 行動ファンネル ジャーニーマップ
35. 施策の効果見立て・計測 35 ABテスト結果 新機能の利用度合い
36. 機械学習によるレコメンド 36 http://image.itmedia.co.jp/l/im/ait/articles/1804/23/l_news011_04.jpg
37. 迷惑行為の自動検知 過剰アクセスなどの異常パターンを特定 37
38. 問い合わせの傾向分析 38
39. 広告配信の最適化 39
40. ニュースレター 分析結果をメディアに情報提供することで市場活性化に貢献 40 http://www.recruit-mp.co.jp/news/release/2017/0531_3216.html
41. システムモニタリング デバイスシェアやクラッシュ率、レスポンスタイム 41 http://yuzutas0.hatenablog.com/entry/2017/05/23/073000
42. 障害発生時の影響調査 42
43. チームのキャパシティ スクラムチームのベロシティ や チケット消化のメトリクス 43
44. アジェンダ 背景　①プロダクト・チーム　②データ活用事例 案件　①KPIモニタリング　②業者・不正ユーザー対策　③集客広告配信 プロセス　①データ抽出・集計　②機械学習プロジェクト 基盤　①ViewとModelの分離　②データの信頼担保　③使われるための保守・運用 チーム　①運営の安定化　②採用・育成・アウトソース　③体制拡大による痛み 文化　①Measureから始める　②組織に浸透させる　③非エンジニアの壁を壊す 44
45. 3つのデータ活用案件をご紹介します 案件を通して Data と Ops を 結びつけることの重要性をお伝えします 45
46. 案件①　KPIモニタリング 46
47. 最初にやったこと データ活用の第一歩は可視化である（はずだと考えた） ・あらゆるデータをいい感じに見ることのできる すごいダッシュボード を作ろう ・綺麗なダッシュボードを構築できたら、誰もが目にするようにオフィスのモニターに投影しよう 47
48. サービスの利益構造とKPIツリー 48 https://growthhackjournal.com/kpi-tree-for-app/
49. 俺の考えた最強のダッシュボード 49
50. 高まる期待 1. 毎日のKPIをすらすら言えるようになるかも 2. 異常値に気づいて迅速に動けるようになるかも 3. ビジネスコミットできる強いエンジニアチームになるかも 50
51. 51 1週間で誰も見なくなった 現実は非情である
52. 打ち手として妥当？ 52 期待した状態 打ち手
53. 何のためのデータ？ 53 https://twitter.com/msmt9/status/778865480379412481
54. まずは弟子入りから 54 そもそも成功状態をイメージできる？ 普段からデータを見ている人たちって、具体的に何をやっているの？ 毎日データを見ているディレクターやマーケッターに相談して 仕事を教えてもらった
55. デイリーレポートを自動配信 毎日のデータ集計・レポーティング作業を手動運用していたので 既存業務を自動化する形でSlackにシンプルなグラフを配信 した 55
56. 圧倒的成果 「めちゃくちゃ生産性あがりました！」 の声 ディレクターやマーケッターが Slackの日次データを見ているので 二人三脚で案件を担当するエンジニアメンバーも徐々にデータを見るようになった 56
57. これだけでよかった ・シンプルなグラフと数値をいつも見ているチャットに流すだけでよかった ・既存オペレーションを組み合わせた「無理のない」「自然にデータを見る」体験 デザイン ・「いつ / どこで / 誰が / なぜ / どういう手順で / 何をするのか」（5W1H）まで解像度を上げる 57 毎朝の出社 （既にやっていたこと） 出社後にSlackを見る （既にやっていたこと） 意思決定する （既にやっていたこと） 1. オフィスに出社する 2. PCを開く 3. Slackが自動で起動 → 1. 未読チャンネルを開く 2. 画面をスクロールする 　（= 読む） ここで 日次KPIレポート → （例） ・新機能のリリース翌日に数字を見て 　施策が当たったか、予期せぬ離脱を 　招いていないかを確認する 　（次の施策のインプットにする） ・マーケッターが登録数の推移を見て 　その日の広告予算を調整する
58. 業務（Ops）に注目する 58 「派手なダッシュボードであること」よりも 「業務にどう影響を与えるのか」 を考える いつ どこで 誰が 何のために どのデータを どのように 見たいのか？ （完全な0→1でもない限り） すでに何らかの形で業務やシステムは存在 していて、そこから価値が生み出されている データを活用するというのは、その価値の流れを改善 （あるいは改革？） するということ
59. アジェンダ 背景　①プロダクト・チーム　②データ活用事例 案件　①KPIモニタリング　②業者・不正ユーザー対策　③集客広告配信 プロセス　①データ抽出・集計　②機械学習プロジェクト 基盤　①ViewとModelの分離　②データの信頼担保　③使われるための保守・運用 チーム　①運営の安定化　②採用・育成・アウトソース　③体制拡大による痛み 文化　①Measureから始める　②組織に浸透させる　③非エンジニアの壁を壊す 59
60. 案件②　業者・不正ユーザー対策 60
61. 安心・安全のための取り組み 61 https://zexy-koimusubi.net/ https://www.irasutoya.com/2016/02/blog-post_376.html https://www.irasutoya.com/2017/10/sns.html https://www.irasutoya.com/2018/04/blog-post_401.html https://www.irasutoya.com/2014/03/blog-post_9780.html https://www.irasutoya.com/2018/07/blog-post_403.html
62. テクノロジーでもっと改善できないか ⇒ 機械学習エンジニア・セキュリティエンジニアが集結 62 スタッフが巡回監視・パトロール システムによる早期検知 ？ https://www.irasutoya.com/2018/07/blog-post_403.html
63. CREシステムの構築・導入 各利用フェーズで得られるデータから特徴量を抽出 過去パターンから業者・不正ユーザーの候補リストを生成する （最後はパトロールスタッフによる目視確認） 63 ※実際の内容とは異なります。あくまでもシステムをイメージするための参考としてご認識ください。
64. ⇒ 機械学習エンジニア・セキュリティエンジニアが集結 64 スタッフが巡回監視・パトロール システムによる早期検知 ？ https://www.irasutoya.com/2018/07/blog-post_403.html 機械学習のスクリプトは 早々に 完成した！ が、実運用に乗るまで 半年以上 掛かった…… （ちなみに精度は当初想定を超えて圧倒的成果だった！これは良かった！） 現実は非情である
65. アルゴリズムだけじゃなかった 65 　ステークホルダー調整 　　パトロールスタッフが作業手順を学ぶためのインプットはどうするか 　　カスタマー観点やビジネス観点での影響はないか 　業務運用設計 　　システムが自動検知したあとに、目視確認にどう繋ぐのか。 　　候補リストを渡すなら、どんなリスト形式？いつ？どこで？誰に？どうやって渡す？ 　システム間連携 　　新たに開発した機械学習スクリプト単体だけでは完結しないので、 　　ユーザーが利用するサービス本体、パトロールスタッフ向けシステムとどう結合するか
66. 業務（Ops）に注目する 66 テクノロジー（Data）単体ではなく、業務全体（Ops）への視点 システム連携設計 や 業務フロー分析 ステークホルダーとの認識合わせ や 運用装着 要するに：機械学習の案件にもプロジェクトマネジメントが必要 予測精度が出るか分からないなら、その 不確実性を前提としたプロジェクトを計画 すべきだった 　　　　　　　　　　　　　　　　　　　・まずはデモ環境で試してリストの受け渡しは手動でやるとか 　　　　　　　　　　　　　　　　　　　・明らかに効果が出るルールベースの機能に絞って先に運用に乗せるとか
67. アジェンダ 背景　①プロダクト・チーム　②データ活用事例 案件　①KPIモニタリング　②業者・不正ユーザー対策　③集客広告配信 プロセス　①データ抽出・集計　②機械学習プロジェクト 基盤　①ViewとModelの分離　②データの信頼担保　③使われるための保守・運用 チーム　①運営の安定化　②採用・育成・アウトソース　③体制拡大による痛み 文化　①Measureから始める　②組織に浸透させる　③非エンジニアの壁を壊す 67
68. 案件③　集客広告配信 68
69. 有料集客によるユーザーの獲得 69 あああ Referral（紹介） Acquisition（獲得） Activation（利用） Retention（継続） Revenue（収益）
70. 媒体Aと媒体Bのどちらに広告を配信する？ 70 ※これらの広告媒体はイメージ例です
71. やっていき マーケティングを自動で良い感じにやってくれる すごいシステムを作るぞぉおおおおおおおおおお！ 71
72. 72 ※これらの広告媒体はイメージ例です ぜんっっっっっっっっぜん 効果が出なかった！ 現実は非情である
73. まだまだプロダクトは発展途上のフェーズ ・少数のメンバーで集客における 勝ち筋やプロセスを模索 している段階 ・「意思決定」や「業務」 を機械に置き換えようとしても 「正解」となるパターン が見えていなかった ・不確定な部分について仮置きして進めようとして（主に発表者 @yuzutas0 が）見事にずっこけた 73
74. まずは個々の担当を磨き込む いきなり最適化は苦戦 ↔ オペレーション＆データの可視化 ⇒ 効率化による利益創出が可能 74 Before After マーケティング担当 → 手動で実施している業務について オペレーション整理・改善 データエンジニア → 広告関連データをデータ基盤に統合したり、 マーケティング業務を少しずつ自動化 機械学習エンジニア → 特定の業務や広告媒体に絞って自動最適化 連携して 最適化システムを 作ろうぜ！ NG! OK!
75. （結果的に）業務の可視化と改善 テクノロジーによって 広告配信の企画（Biz）・開発（Dev）・運用（Ops）サイクルを支援 75
76. （可視化の過程で）利益創出 76 マーケティング担当「この データを出せるように したい。少し気掛かりなことがある。」 データエンジニア「やってみた！ けど、この結果って......。」 一部の広告媒体の効果 がそこまで高くないことが分かった マーケティング計画の大幅な方針変更を検討
77. それまでは獲得効率を目的変数にしていた 77 あああ Referral（紹介） Acquisition（獲得） Activation（利用） Retention（継続） Revenue（収益）
78. 集客を収益効率で見ると結果が変わった 78 あああ Referral（紹介） Acquisition（獲得） Activation（利用） Retention（継続） Revenue（収益）
79. あああ Referral（紹介） Acquisition（獲得） Activation（利用） Retention（継続） Revenue（収益） データ元が違うから横断分析できなかった 79 マーケティング担当が使うアクセス解析ツール （プロダクトの前の世界を扱うデータ） ソフトウェアエンジニアが見るデータベース （プロダクトの中の世界を扱うデータ）
80. 単一データの世界観から 80 アクセス 解析ツール サーバサイド DB ユーザーの 流入ログ ユーザーの 購買記録 エンジニアが 参照 マーケッターが 参照 アクションベース （CPA）を計測 広告媒体A を重視 https://boxil.jp/mag/a2829/
81. 統合データの世界観へ 81 アクセス 解析ツール サーバサイド DB ユーザーの 購買記録 エンジニアが 参照 マーケッターが 参照 アクションベース （CPA）を計測 広告媒体A を重視 データ基盤 ユーザーの 流入ログ 売上ベース （ROAS）を計測 広告媒体B を重視 https://boxil.jp/mag/a2829/
82. 売上を伸ばすモニタリング データを見る → 行動が変わる → 結果が変わる データを繋げて可視化するだけで ビジネス改善のインサイトを得られる（こともある） 自動判定とか以前に、データソースを繋げて見るだけで、価値創出につながった スペシャリストが大きな絵を描かなくても、ちょっとしたデータを出すだけで効果があったりする 82
83. データ（Data）と業務（Ops）は両輪 83 Data を機会として Ops を可視化する 広告配信をいきなり全て自動化しようとしても上手くいかない データを活用するためには 1つ1つの業務を紐解くことになる Ops を通して Data を引き出す 広告効果をより正確にモニタリングするにはシステムが進化しないといけない 1つ1つの業務を改善しようとしたらデータが必要になる
84. アジェンダ 背景　①プロダクト・チーム　②データ活用事例 案件　①KPIモニタリング　②業者・不正ユーザー対策　③集客広告配信 プロセス　①データ抽出・集計　②機械学習プロジェクト 基盤　①ViewとModelの分離　②データの信頼担保　③使われるための保守・運用 チーム　①運営の安定化　②採用・育成・アウトソース　③体制拡大による痛み 文化　①Measureから始める　②組織に浸透させる　③非エンジニアの壁を壊す 84
85. 案件のまとめ 85
86. 3つのデータ活用案件をご紹介します 案件を通して Data と Ops を 結びつけることの重要性をお伝えします 86 （再掲）
87. データ活用による価値創出 バリューストリーム において リターンを上げる or コストを下げる 87
88. データ活用による価値創出 バリューストリーム において リターンを上げる or コストを下げる ・例：RPAによるマーケティング業務やカスタマーサポート業務の一部自動化 ・レコメンド機能は ユーザーの探索業務（一般的には情報収集 →比較検討→意思決定→アクション）を支援する ソリューション 88
89. DataとOpsを繋げる 89 http://simpleicon.com/gear-7.html Data（データ） と Ops（業務）を結びつけることで 価値を創造することができる データを使うこと によって 誰が抱えるどんな不 を解決したいのか ・情報社会においては 何をするにも多くの「意思決定」を必要とする ・意思決定 を支える / 自動化するのが「データ分析」や「機械学習」
90. 事業の成長を支える ・現場の1人1人が主役となり、データを活用 して プロダクトや業務 を磨き込む ・この積み重ねによって事業が成長し、顧客に価値を届けることになる 90
91. 事業のグロースを支える DataOpsの現場 2018-07-27 Developers Summit 2018 Summer presented by @yuzutas0 https://www.pexels.com/photo/abstract-art-blur-bright-373543/ これこそが（タイトル再掲）
92. アジェンダ 背景　①プロダクト・チーム　②データ活用事例 案件　①KPIモニタリング　②業者・不正ユーザー対策　③集客広告配信 プロセス　①データ抽出・集計　②機械学習プロジェクト 基盤　①ViewとModelの分離　②データの信頼担保　③使われるための保守・運用 チーム　①運営の安定化　②採用・育成・アウトソース　③体制拡大による痛み 文化　①Measureから始める　②組織に浸透させる　③非エンジニアの壁を壊す 92
93. 93 事業グロース データ活用案件 信頼できるシステム 効率的なプロセス 安定したチーム データ活用文化
94. データ活用案件を支えるプロセス？ 　　　　　　完璧な企画書？ 　　　　　　圧倒的な予算？ 　　　　　　1年間の開発プロジェクト？ 94
95. データ活用案件を支えるプロセス？ 　　　　　　完璧な企画書？ 　　　　　　圧倒的な予算？ 　　　　　　1年間の開発プロジェクト？ 95 ×
96. 1年後に待つもの • 思っていたのと違った • 良さそうだけど結局使わなかった 96
97. 「本当に必要だったもの」には届かない 97 http://www.projectcartoon.com/
98. というか「答え」が存在しない Q.　最初に要件を全部洗い出せばOK？ A.　NG！「やりたいこと」は変わる！ • 他社ブログを見て「うちもやりたい！」 • 新しいBIツールの提案に「これいい！」 • 実際に画面を作ったら「なんか違う！」 98
99. なぜデータ活用は難しい？ 「システムを作って終わり」ではないから 　　　　　　　　　　　・利用者に実際に使われるか？ 　　　　　　　　　　　・予測精度が一定以上となるか？ 　　　　　　　　　　　・利益の創出に貢献できるか？ しかもビジネス環境、テクノロジー進歩、プロダクト仕様、チーム・体制、業務内容でさえ日々変わっていく （特にグロースフェーズの場合） 極めて不確実性の高いプロジェクト そもそもプロダクト開発というのは本質的に不確実性との戦い。システム部門がビジネスから遠ざかっていると見えにくいだけ。 99 https://unsplash.com/photos/vBpd607jLXs
100. 不確実性を前提としたプロセスが必要 「学びの最大化」に注目する 参考『リーンスタートアップ』 　　　　　（例） 　　　　　　　・リスクの大きい要素を先に検証する 　　　　　　　・案件のバッチサイズを小さくする 　　　　　　　・高速にイテレーションを回す リスクを抑え ながら 現場の業務（Ops）を読み解く 100 http://ec.nikkeibp.co.jp/item/books/P48970.html
101. 小さく試すことでリスクを抑えながら Data と Ops を読み解くことが重要です プロセスの具体例を2つご紹介します 101
102. アジェンダ 背景　①プロダクト・チーム　②データ活用事例 案件　①KPIモニタリング　②業者・不正ユーザー対策　③集客広告配信 プロセス　①データ抽出・集計　②機械学習プロジェクト 基盤　①ViewとModelの分離　②データの信頼担保　③使われるための保守・運用 チーム　①運営の安定化　②採用・育成・アウトソース　③体制拡大による痛み 文化　①Measureから始める　②組織に浸透させる　③非エンジニアの壁を壊す 102
103. プロセス①　データ抽出・集計 103
104. 抽出・集計だけでも利益に寄与しうる 先ほど紹介した集客モニタリング案件 104
105. 約300案件を捌きまくった 105 ↓は四半期への言及なのでトータルはもっと多いです（念のため）
106. データ抽出・集計の業務 106
107. MVPで小さく作る ・要求者は「自分が本当に必要とするデータ」を知らないまま依頼する（業務フローが不明確） ・多くはすぐに使わなくなる＆見なくなる（余分な機能のムダ） ・一部は実運用が進む → 最適IFを提供：正しい要求にもとづいて作り直す 　活用側の独自システムやシートが複雑化して保守困難になるので、整理してデータパイプラインに組み込む 107 http://ec.nikkeibp.co.jp/item/books/P48970.html
108. MVP - モックアップ 108 　もしこういう値だったら データを出しても 　　どういう意思決定になるのか？ → 　アクションが変わらなければ 　　どのくらいのインパクトがあるのか？ → 　工数に効果が見合わなければ 　を最初に検証する やる意味がない ホワイトボードやSpreadsheet で 　　　・推定される概算値を仮置きして 　　　・出力シートをスケッチして 集計 / 抽出後のユースケースをロールプレイ
109. MVP - CSVファイル 凝ったグラフを描く前に、データ自体を速やかに受け渡す ・データさえあれば Excel や Spreadsheet で当面はどうにかできる ・Jupyter Notebook や BigQuery UI でCSVファイルを出力 109
110. MVP - Data Studio コマンド1つで即席のダッシュボード ・簡易作成したら後は好きに使ってもらう ・まだ自由度は高くないが固定指標のモニタリングなら問題なく使える 110
111. MVP - 継続的に使い始めたら自動配信 毎朝のSlackでCSVファイルやダッシュボードURLを配信 ・用意したテンプレートに沿ってプログラミングする ・masterブランチにマージすれば翌日から自動で配信される 111
112. 不要になったらクリーニング 大抵は見なくなるので毎週のふりかえりでクリーニングする（後述） そのタイミングで「本当に必要だったデータは何か」を振り返って次に活かす 112
113. 生き残った案件だけを磨き込む 113 検知タイミング 業務の実態とデータ集計処理が 合わなくなってくるので ・追加や改修の依頼が寄せられる ・魔改造で保守不可になり声が掛かる 対応方針 ①ホワイトボード設計からやり直す！ ・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
114. 案件ライフサイクル スタートアップと同じように 小さくテストしながら、段階的に要求・設計を磨き込む （ひたすら螺旋のように繰り返す） 114
115. アジェンダ 背景　①プロダクト・チーム　②データ活用事例 案件　①KPIモニタリング　②業者・不正ユーザー対策　③集客広告配信 プロセス　①データ抽出・集計　②機械学習プロジェクト 基盤　①ViewとModelの分離　②データの信頼担保　③使われるための保守・運用 チーム　①運営の安定化　②採用・育成・アウトソース　③体制拡大による痛み 文化　①Measureから始める　②組織に浸透させる　③非エンジニアの壁を壊す 115
116. プロセス②　機械学習プロジェクト 116
117. 作って終わりではない！システムを磨き込む！ 業者・不正ユーザー対策の機能追加 117
118. 小さく検証しながら進める 118 データ分析による仮説構築（Data） パラメータ追加で予測精度は向上しそうか by MLエンジニア モックアップによるUI構築（Ops） スタッフに見てもらって運用できそうか by APエンジニア ↓ ↓ 設計・コーディング・システムテスト ↓ デモ環境で並行稼働させる ダークローンチ 効果検証：システム観点に加えて 予測精度（Data） と 業務運用（Ops） ↓ 本格移管・リリース
119. データ分析による仮説構築 Data（データ）を検証する どのパラメータを追加すると予測精度は向上しそうか MLエンジニアが主体となって実施 119
120. モックアップによるUX構築 Ops（業務）を検証する スタッフに画面を見てもらって運用できそうか APエンジニアが主体となって実施 120
121. ダークローンチによる検証 デモ環境でシステムを並行稼働させることで パトロールスタッフが利用可能な状態にする 本番相当のData（データ）やOps（業務）で シミュレーションを実施 システム観点でのステージング試験に加えて 予測精度（Data） と 業務運用（Ops）において 本番リリース可能かどうかを検証する 121
122. 余談：インタビューによる仮説構築 データを見るよりもユーザーに話を聞いたほうが早いこともある リサーチ担当と連携してユーザーインタビューを実施 122
123. アジェンダ 背景　①プロダクト・チーム　②データ活用事例 案件　①KPIモニタリング　②業者・不正ユーザー対策　③集客広告配信 プロセス　①データ抽出・集計　②機械学習プロジェクト 基盤　①ViewとModelの分離　②データの信頼担保　③使われるための保守・運用 チーム　①運営の安定化　②採用・育成・アウトソース　③体制拡大による痛み 文化　①Measureから始める　②組織に浸透させる　③非エンジニアの壁を壊す 123
124. プロセスのまとめ 124
125. 125 （再掲） 小さく試すことでリスクを抑えながら Data と Ops を読み解くことが重要です プロセスの具体例を2つご紹介します
126. MVP：検証に足る最小限の製品 126 “自分達のアパートの写真だけを載せた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
127. データ案件でもMVP ホワイトボードスケッチ、 CSVファイル、DataStudio、Slack自動配信 etc... 127
128. ステージゲート方式 “仮説段階や事業化1年目と ステージを区切り、 どのステージにいれば 擬似的な時価総額はいくらで、 投下する資金額は いくらが適切なのかを 簡単に判断できるように しています。” http://hrnabi.com/2017/09/12/15065/ 128
129. データ案件でもステージゲート 129
130. 革新会計・リーンキャンバス “売上や利益といった一般的な管理会計で測るのではなく、別の基準（革新会計）で進捗を測って プロジェクトにアカウンタビリティを持たせる仕組みのことです。” 130 https://medium.com/@tumada/lean-startup-retrospective-2018-ab291889a797
131. データ案件でも革新会計 131 https://www.oreilly.co.jp/books/9784873115917/ http://www.shoeisha.co.jp/book/detail/9784798128511
132. DataとOpsを繋げる 132 http://simpleicon.com/gear-7.html そのデータを使うこと によって 解決したい課題 を解決できるか ・なるべく小さなバッチサイズに分解する ・高速にイテレーションを回す ・案件のフェーズを登っていく Data（データ） と Ops（業務）が結びつくか、テストしながら進めていく
133. 事業の成長を支える（再掲） ・現場の1人1人が主役となり、データを活用 して プロダクトや業務 を磨き込む ・この積み重ねによって事業が成長し、顧客に価値を届けることになる 133
134. 事業のグロースを支える DataOpsの現場 2018-07-27 Developers Summit 2018 Summer presented by @yuzutas0 https://www.pexels.com/photo/abstract-art-blur-bright-373543/ これこそが（タイトル再掲）
135. アジェンダ 背景　①プロダクト・チーム　②データ活用事例 案件　①KPIモニタリング　②業者・不正ユーザー対策　③集客広告配信 プロセス　①データ抽出・集計　②機械学習プロジェクト 基盤　①ViewとModelの分離　②データの信頼担保　③使われるための保守・運用 チーム　①運営の安定化　②採用・育成・アウトソース　③体制拡大による痛み 文化　①Measureから始める　②組織に浸透させる　③非エンジニアの壁を壊す 135
136. 136 事業グロース データ活用案件 信頼できるシステム 効率的なプロセス 安定したチーム データ活用文化
137. 安易な “小さく試す” では解決できないのが システムの難しいところです 「使われるデータ基盤」のための 紆余曲折をご紹介します 137
138. 基盤①　ViewとModelの分離 138
139. 各々がデータを利用 各案件を担うデータサイエンティストや MLエンジニアが 「とりあえず」「小さく試す」ために独自にデータを取得・加工 139
140. 部署ごとに「売上」がズレる問題 「売上」と一言で言っても、考え方や用途によって定義は変わる さまざまな計算方法が考えられる ・消費税を含むのか ・割引分はどこで差し引くのか ・年間契約プランは月次で按分するのか ・按分する場合は途中解約をどこに計上するのか ・返金は後で一括で差し引くのか、購入時にさかのぼって差し引くのか ・モバイルアプリの課金はAppleやGoogleへの決済手数料を含むのか ・用途は財務会計か管理会計か あるチームは自分たちの施策によって KPIが大幅に上がったと主張しても 別のチームからは何の参考にもならない数字に見える どのデータが正しいのか誰も分からない ので、横断での意思決定や調整が困難になる 140
141. コンウェイの法則 「とりあえず」「小さく試す」を繰り返した結果、システム全体が過剰に複雑化 141
142. データ基盤の必要性 データソース（Data）と 利用者（Ops）をリボンのように結び付けるもの プロダクト成長や体制拡大によって リボンの両側が多様 になるとデータ基盤が必要になる 「データ基盤」を作ること自体は目的ではない 142
143. 責務に応じたシステムの分離・結合 ・SREチーム* が全体設計から見直してデータ基盤を整備 ・Model（収集・蓄積・加工）と View（参照・利用） 143 *この論点の取りまとめはSREが望ましい。ビジネス経営に近い立場のロールが判断しても 情報システム設計の専門家でないと、データモデリングやシステムは設計破綻しがち。
144. アジェンダ 背景　①プロダクト・チーム　②データ活用事例 案件　①KPIモニタリング　②業者・不正ユーザー対策　③集客広告配信 プロセス　①データ抽出・集計　②機械学習プロジェクト 基盤　①ViewとModelの分離　②データの信頼担保　③使われるための保守・運用 チーム　①運営の安定化　②採用・育成・アウトソース　③体制拡大による痛み 文化　①Measureから始める　②組織に浸透させる　③非エンジニアの壁を壊す 144
145. 基盤②　データの信頼を担保する 145
146. システムがあるだけでは使われない ・既存の業務（Ops）は 既存のデータ（Data）を使っている ・最も信頼されていたのは Excel だった　ツールとしては運用の限界を迎えていた ・これまで使っていたデータとズレると業務影響が出てしまう / 信用できない 146
147. ExcelからBigQueryにデータを移行する Excelの多重参照や謎ロジックを読み解きながら SQLに反映していく 147
148. 重厚長大なExcelを解読する マインドマップによる整理 スライドに入るように（入りきってないけど）縮めたら画像が潰れてしもうた…… 148
149. 既存の計算ミスやデータ不整合を発見 とにかく数字が合わない 149
150. 特にデータクレンジング ひらすら地味な作業が続く 150
151. 最終出力（30項目）を置き換え 151
152. 別のExcelシート（500項目）が出てきた 152
153. その先は地獄だぞ ・まさに システム再構築 案件（仕様書なし）と同じ状況 ・いわば データ基盤のEOL 対応 ・小手先の工夫でどうにかできるレベルではない 153 https://www.pexels.com/photo/water-outside-fire-hose-69934/
154. アルバイトを募集した 体制をスケールして 1人当たりの負担を減らさないと（自分が）辛すぎる 154
155. 500項目を置き換え 155
156. また別のExcel（2000項目）が出てきた 156
157. オフショアを検証中 オフショア部隊によるデータ基盤EOL対応の仕組み化（試行錯誤中） ・データ活用を促進して、現場業務に注目すると、この手の話は出てくる（はず） 　　役職者の知らないうちに担当者のローカル環境に実務の根幹を支えるデータが溜まっていたりする ・デジタルトランスフォーメーションの痛み 157
158. 愚直に向き合うことで データの信頼性を高める 158
159. アジェンダ 背景　①プロダクト・チーム　②データ活用事例 案件　①KPIモニタリング　②業者・不正ユーザー対策　③集客広告配信 プロセス　①データ抽出・集計　②機械学習プロジェクト 基盤　①ViewとModelの分離　②データの信頼担保　③使われるための保守・運用 チーム　①運営の安定化　②採用・育成・アウトソース　③体制拡大による痛み 文化　①Measureから始める　②組織に浸透させる　③非エンジニアの壁を壊す 159
160. 基盤③　使われるための保守・運用 160
161. 信頼性と利便性のバランスをいかにとるか？ 161 共通化による信頼性 個別化による利便性
162. 部署ごとに最適なViewは異なる Ops（担当業務やスキルセット） が異なるので Data（見たいデータや使いたいツール） も異なる 162
163. ツール選定はABテストで決める 日進月歩で多様なソリューションが台頭＆進化している ・リサーチや運用サポートに工数を割けない ・1度はダメだったツールがあとで使えるようになることもある 　（例：Google Data Studioは月に1〜3回の頻度でアップデート） 希望者が使いたいツール（ A）を試す ・セキュリティ観点などで問題ないこと ・現行ツール（B）よりも生産性が向上すること これらを社内にフィードバックすることで 他チームやメンバーが自発的に利用する（自然と生き残る） 中途半端にガバナンスを効かせるのではなく、市場原理を利用する → 変化に対応する 163
164. スタートアップと同じように 小さくテストしながら、段階的に要求・設計を磨き込む （ひたすら螺旋のように繰り返す） View: ユースケースも変わる （例）データの抽出・集計 164
165. Model: 元データの仕様も変わる 165 システムが日々変わる ・新機能の追加 ・不具合の修正 データ仕様も日々変わる データ活用 データを 生成 集計方法に 影響 ※非エンジニアにとっては同じ挙動のように見えても 処理のタイミングやレコード反映の順序が微妙に変わっていたり
166. ModelとViewの境界線 3層構造でのデータ管理 参考『10年戦えるデータ分析入門 - SQLを武器にデータ活用時代を生き抜く』 166
167. 3層構造における2つの流れ 167
168. 中間層（データウェアハウス） ・1度定義して終わりではない ・分離と結合を継続的に繰り返す ことになる = データモデルは変わり続ける ・ソースコードをリファクタリングし続けるのと同じ 168
169. クエリ量に基づくデータマネジメント ※まだ綺麗な仕組みとしては回せておりません。異常値に対する解釈の枠組みとして使っています。 169 データレイク データウェアハウス データマート 量が 多いと 問題 ワイルドクエリ や 無駄バッチ （要チューニング） 量が 少ないと 問題 データ基盤が 利用されていない ログ追加/分析が 実施されていない プロダクトが 成長していない 継続的に中間テーブルを 分離・結合できていない ＝データモデリング観点で 技術的負債が蓄積している データ基盤が 利用されていない 施策/分析が 実施されていない 体制・チームが 拡大していない
170. 利用者の寄る辺: データ辞書 最適なツールにはまだ巡り会えていませんが …… 170 ・既にあるならそれを渡す ・まだなければ一緒に作る ・変化に追従できていなければ更新する
171. 管理者の寄る辺: サービスレベル サービスレベルにもとづいて全ての意思決定がなされる 171 https://www.oreilly.co.jp/books/9784873117911/ https://www.oreilly.co.jp/books/9784873114934/ http://gihyo.jp/book/2007/978-4-7741-3125-2 日本語で一番分かりやすい記事（自称） http://yuzutas0.hatenablog.com/entry/2017/05/23/073000
172. サービスレベル データの用途・利用者ごとに期待されているサービスレベルを可視化 ・信頼性は「実際にシステムを使う人・目的・時間」を前提にする ・なのでサービスレベルはユースケース駆動で設計することになる ・誰も使わない機能や時間帯でシステム稼働率が100%であっても仕方ない ※曖昧なものは曖昧であるということが可視化された。これが大事。 決めることが目的ではなく、 共通認識の醸成と クオリティコントロールの 寄る辺を作ることが目的。 172 例 用途 約束相手 連絡先・周知先 利用データ 約束事項（SLA） 違反時の影響範囲 1 日次レポート ディレクター Slack #monitoring BigQueryの 売上テーブル 毎営業日の午前x時までに 欠損なく前日の売上が レポートされること 売上状況に応じた 施策が打てなくなる （機会損失） 2 … … … … … … 3 … … … … … … … … … … … … …
173. オペレーションレベル サービスレベルに対する脅威（＝インシデント）発生時のオペレーション 173 対応スピード 補償・代替手段 ワークアラウンド（回避策） レポーティング＆記録
174. SLA & OLA を改善する① 毎スプリント終了時のふりかえりで、実態（AsIs）と期待値（ToBe）を比較する 174
175. SLA & OLA を改善する② 改善アクション ・目標を満たせるように改善する ：基盤システムの改修案件を起票 ・目標自体を修正する ：過剰なら目標を下方修正、使用停止 BIツールはクリーニング、観点漏れは追加 175
176. アジェンダ 背景　①プロダクト・チーム　②データ活用事例 案件　①KPIモニタリング　②業者・不正ユーザー対策　③集客広告配信 プロセス　①データ抽出・集計　②機械学習プロジェクト 基盤　①ViewとModelの分離　②データの信頼担保　③使われるための保守・運用 チーム　①運営の安定化　②採用・育成・アウトソース　③体制拡大による痛み 文化　①Measureから始める　②組織に浸透させる　③非エンジニアの壁を壊す 176
177. 基盤のまとめ 177
178. 安易な “小さく試す” では解決できないのが システムの難しいところです 「使われるデータ基盤」のための 紆余曲折をご紹介します 178 （再掲）
179. データ活用を取り巻くテクノロジー これらのテクノロジー（Data）なくては業務（Ops）は進化しない 一方で、これらのテクノロジーを導入するだけでは解決しない問題 がある BigQueryを使うために誰よりも Excelを開くという矛盾 これらのテクノロジー（Data）を 利用者（Ops）とどう繋ぎ合わせるか 179 データ収集 IoT、オープンデータ、APIエコノミー、スマートデバイス データ蓄積 / 加工 クラウドDWH、分散処理、パイプライン データ判断 統計解析、機械学習、 MLaaS、MLOps
180. DataとOpsを繋げる 180 http://simpleicon.com/gear-7.html Data（データ） と Ops（利用者）を結ぶデータ基盤 ・データを正しく使えるように信頼性を保つ ・利用者が小さく試せるように利便性を保つ あらゆる開発・運用手法を総動員して「使われるシステム」を提供する
181. 事業の成長を支える（再掲） ・現場の1人1人が主役となり、データを活用 して プロダクトや業務 を磨き込む ・この積み重ねによって事業が成長し、顧客に価値を届けることになる 181
182. 事業のグロースを支える DataOpsの現場 2018-07-27 Developers Summit 2018 Summer presented by @yuzutas0 https://www.pexels.com/photo/abstract-art-blur-bright-373543/ これこそが（タイトル再掲）
183. アジェンダ 背景　①プロダクト・チーム　②データ活用事例 案件　①KPIモニタリング　②業者・不正ユーザー対策　③集客広告配信 プロセス　①データ抽出・集計　②機械学習プロジェクト 基盤　①ViewとModelの分離　②データの信頼担保　③使われるための保守・運用 チーム　①運営の安定化　②採用・育成・アウトソース　③体制拡大による痛み 文化　①Measureから始める　②組織に浸透させる　③非エンジニアの壁を壊す 183
184. 184 事業グロース データ活用案件 信頼できるシステム 効率的なプロセス 安定したチーム データ活用文化
185. サイエンティストやMLエンジニアが1人いるだけで 全てが上手くいくわけではありません チーム運営自体について科学し、 エンジニアリングしてきた内容をお伝えします 185
186. チーム①　運営の安定化 186
187. データチームをいかに運営するか データ活用を取り巻く「案件」「プロセス」「システム」は不確実性が高い 可視化を促すために アジャイルプラクティス を適用した 我々が慣れ親しんでいる チーム開発の手法がそのまま当てはまる 187 https://www.shoeisha.co.jp/book/detail/9784798129716
188. セレモニー 188
189. アイテム 189
190. ドキュメント（業務手順） ・チーム立ち上げに合わせて、作業手順のドキュメントから見直す ・手順が明文化されていなければ文書化する 　※文書化できる人材を優先して引き入れる 190 　トヨタ自工に転出してから、 　私がまず標準作業表をつくれ と 　呼びかけたことはいうまでもない。 　生産現場の基本ともいうべき標準作業表づくりから、 　トヨタ生産方式づくりへの三五年にわたる道程を 　歩ませるもとをなしているように思う。 http://www.diamond.co.jp/book/9784478460016.html
191. Document as Code - ドキュメントをコードのように扱う 191 データチームだけでなくプロダクトや体制全体で「このドキュメントはどこに配置すべきか」 「誰がいつどのように見るか」検討してリファクタリングを繰り返すことで、全体最適化や業務設計の観点を養う
192. アジェンダ 背景　①プロダクト・チーム　②データ活用事例 案件　①KPIモニタリング　②業者・不正ユーザー対策　③集客広告配信 プロセス　①データ抽出・集計　②機械学習プロジェクト 基盤　①ViewとModelの分離　②データの信頼担保　③使われるための保守・運用 チーム　①運営の安定化　②採用・育成・アウトソース　③体制拡大による痛み 文化　①Measureから始める　②組織に浸透させる　③非エンジニアの壁を壊す 192
193. チーム②　採用・育成・アウトソース 193
194. 採用要件 スキル定義にもとづいて設計した 　後述 SRE人材を優先的に採用した Data Generation Process（データ生成過程）を抑えるため あるいは Data Collection Process（データ収集過程） 　・不足しているログの追加 　・DBからデータ基盤へのデータの疎通 　・データ仕様の調査 最初はプロダクト本体を開発するチームと連携して システム構成や作業手順をキャッチアップする。 徐々にデータチーム単体でデータを追加できるようにする。 ※DB影響のあるプルリクはプロダクト担当レビュー必須 といった品質担保のための約束事は設けている 194
195. 立ち上げメニュー プロダクトのドッグフーディング 1. データ構成（ER）をリバースエンジニアリング 　　　自分で1から考えることで、プロダクトやデータの仕様に素早くキャッチアップする（仮説思考） 2. 改善提案をSlackの起案チャンネルに投稿する 　　　プロダクト改善の姿勢を身につけて、現場視点のデータ活用案件を担えるようにする 195 例：高速データ把握メソッド
196. OJTの運用設計 ビジネス基礎スキルがボトルネックになちがち → OJTを整備 　・ステークホルダーから要求を聞き出すためのコミュニケーション 　・未知の領域について業務知識を短期間でキャッチアップできる学び方 196
197. 課題図書によるスキル定義 活躍しているメンバーへのヒアリングで ソフトスキル + ハードスキル を定義 → 育成メニューに反映 197
198. 新人研修: データ分析ハッカソン 実践型の学習パッケージを開発・展開 https://recruit-tech.co.jp/blog/2018/07/23/rtech_bootcamp_2018/ 198
199. インターン ・案件を通して学生に学習機会を提供 ・小さくスコープを区切った案件のうち 　本人のWillと合致したものをお願いする ・重要度は高いが、緊急度は低い案件 　　・技術検証やデータ分析による仮説出し 　　・攻めあぐねている課題の突破口になってもらう 199 https://blog.monora.me/2018/03/did-an-internship-at-recruit-technologies/
200. アルバイト: 募集要項やオンボーディング 案件を担ってもらうために ・どういうスキルの人が ・どうキャッチアップして ・どのシステムのどのデータで ・どのような手順で作業して ・どうコミュニケーションするか これらを設計するところから 200
201. アルバイト: 業務手順書 201
202. アルバイト: 進捗管理 202
203. 委託先ごとの向き・不向きを模索 203
204. 案件フェーズに適した契約形態を模索 ※発表者の置かれたコンテキストに強く依存しているので参考程度でお願いします ※分業を推し進めると、ノウハウ共有や横断連携、業務分解や手順書作成がボトルネックになりがち 204
205. アジェンダ 背景　①プロダクト・チーム　②データ活用事例 案件　①KPIモニタリング　②業者・不正ユーザー対策　③集客広告配信 プロセス　①データ抽出・集計　②機械学習プロジェクト 基盤　①ViewとModelの分離　②データの信頼担保　③使われるための保守・運用 チーム　①運営の安定化　②採用・育成・アウトソース　③体制拡大による痛み 文化　①Measureから始める　②組織に浸透させる　③非エンジニアの壁を壊す 205
206. チーム③　体制拡大による痛み 206
207. データチームの悪循環 207
208. 悪循環を打ち破る 他パートの内容と 重複するので詳細は省略 208
209. （理想は）分析担当なら出来てしかるべし 209
210. 現場感をチームに装着する 間接部門の宿命 かつ チーム拡大の宿命 　メンバー提案「とりあえずダッシュボード出しましょう」 → 「お前もか」 → 繰り返される過ち 言葉だけではパラダイムは伝わらない 　現場業務（Ops）のための データ活用（Data）を言葉で伝えても 　　・現場業務（Ops）を担当したことがないからイメージできない 　　・何か特別なすごいデータ分析（ Data）への幻想をぬぐいきれない 210
211. チーム目標: 100案件切り ・地味な集計依頼の対応で良いので とにかく量 をこなす ・量をこなす中で、各チームとの信頼関係を築き、事情を知ることで 「現場の課題」（Ops）を咀嚼する 211 Done Done Done
212. 現場ヒアリング駆動 ・地味な業務の改善で良いので とにかくニーズ を聞き出す ・対面で話すことで 何か特別なすごいデータ分析 を誰も求めていないことを知る 212 ？ ？ ？
213. 社内短期留学 ・プロダクト開発チームに送り込む ・現場の 業務（Ops）を担当 することで強制的に DataOps の視点を身につけてもらう 213 Go Go Go
214. アジェンダ 背景　①プロダクト・チーム　②データ活用事例 案件　①KPIモニタリング　②業者・不正ユーザー対策　③集客広告配信 プロセス　①データ抽出・集計　②機械学習プロジェクト 基盤　①ViewとModelの分離　②データの信頼担保　③使われるための保守・運用 チーム　①運営の安定化　②採用・育成・アウトソース　③体制拡大による痛み 文化　①Measureから始める　②組織に浸透させる　③非エンジニアの壁を壊す 214
215. チームのまとめ 215
216. サイエンティストやMLエンジニアが1人いるだけで 全てが上手くいくわけではありません チーム運営自体について科学し、 エンジニアリングしてきた内容をお伝えします 216 （再掲）
217. DataとOpsを繋げる 217 http://simpleicon.com/gear-7.html Data（データ） と Ops（現場）の間に立つデータチーム ・チーム開発＆運用のスキーム ・採用、育成、アウトソース ・体制の拡大による痛み 安定した支援部隊として Data（データ） と Ops（現場）にコミットする
218. 事業の成長を支える（再掲） ・現場の1人1人が主役となり、データを活用 して プロダクトや業務 を磨き込む ・この積み重ねによって事業が成長し、顧客に価値を届けることになる 218
219. 事業のグロースを支える DataOpsの現場 2018-07-27 Developers Summit 2018 Summer presented by @yuzutas0 https://www.pexels.com/photo/abstract-art-blur-bright-373543/ これこそが（タイトル再掲）
220. アジェンダ 背景　①プロダクト・チーム　②データ活用事例 案件　①KPIモニタリング　②業者・不正ユーザー対策　③集客広告配信 プロセス　①データ抽出・集計　②機械学習プロジェクト 基盤　①ViewとModelの分離　②データの信頼担保　③使われるための保守・運用 チーム　①運営の安定化　②採用・育成・アウトソース　③体制拡大による痛み 文化　①Measureから始める　②組織に浸透させる　③非エンジニアの壁を壊す 220
221. 221 事業グロース データ活用案件 信頼できるシステム 効率的なプロセス 安定したチーム データ活用文化
222. データチームだけではスケールしません 現場の担当者1人1人が活躍できるよう 「データの民主化」の取り組みをお伝えします 222
223. 文化①　Measureから始める 223
224. エンジニアはMeasureから始めてみる 224
225. 実施した施策の結果を分析 225 http://01.gatag.net/0010543-free-illustraition/
226. こんな感じでやりました 226
227. 【Keep】ビジネス視点で開発を見る 自分の成果を自分で言えるようになった （例：1ヶ月掛けた案件で売上xx円/年） 227
228. 【Problem】チームにまだまだ改善余地 　　　　　　メンバーが自分の理解不足に驚く 　　　　　　　　　• 製品仕様 - このケースだとデータの中身はどうなる？ 　　　　　　　　　• フロント寄りメンバーが複雑な SQLに手間取る 　　　　　　　　　• そもそもビジネスKPIを把握しているか 　　　　　　　　　• きちんと分析するために本当は必要だったログ要件の漏れ 担当エンジニアのビジネス・データ理解不足は、システム設計・運用のどこかに反映されている 228
229. 【Try】エンジニアによる起案 言われたものを作るだけ（Build重視）思考からの脱却 229
230. グロースハックチームの立ち上げ エンジニアが起案して仮説検証を回すチーム 必ずしもデータを見るだけではない → プロデューサーから 1つ1つ教わって真似するところから始めた 例：最初の成功体験は「朝会の後に 1日1回15分、競合のアプリを使って気づいたことを挙げる」 230
231. アジェンダ 背景　①プロダクト・チーム　②データ活用事例 案件　①KPIモニタリング　②業者・不正ユーザー対策　③集客広告配信 プロセス　①データ抽出・集計　②機械学習プロジェクト 基盤　①ViewとModelの分離　②データの信頼担保　③使われるための保守・運用 チーム　①運営の安定化　②採用・育成・アウトソース　③体制拡大による痛み 文化　①Measureから始める　②組織に浸透させる　③非エンジニアの壁を壊す 231
232. 文化②　組織に浸透させる 232
233. 文化が浸透するまでの流れ 1. 方向性を意識する（メッセージング） 2. 体験してみる（トライアル） 3. 仕組み化する（プロセス装着） 4. 成功経験を共有する 233
234. メッセージング あの手この手で「データ分析やろう」の空気を醸成 • データ分析ハッカソンの開催 • 朝活サークルで自由研究 （こぞってビットコインの値上がり要因を統計解析） • JupyterHubを拡張したPython学習サイトや社内限データ向けのnbviewerを提供 234
235. 体験: モブ（プログラミング）データ分析 1つのモニターを囲んで全員で作業する 　　　　　• 周囲が調べたりアドバイスしながら進める 　　　　　　 → ハマらない / 挫折を防ぐ、Tipsやコツを共有しあう 　　　　　 • 皆がやるなら自分もやるか！の後押し 　　　　　　 → 「やってみたら思った以上に良かった」の体験 235
236. プロセス装着: 開発工程に組み込む データ仕様に詳しい（少なくとも調査するスキルはもっている）エンジニアが 担当領域を広げることで前後工程のリードタイムを短縮 236
237. 実績PR: アジリティの向上 エンジニア ＝ その場でデータ仕様を調べることができる データサイエンス部門が仕様ヒアリングを重ねて 1週間かけていた分析が1時間で完了（フロー効率化） 237
238. アジェンダ 背景　①プロダクト・チーム　②データ活用事例 案件　①KPIモニタリング　②業者・不正ユーザー対策　③集客広告配信 プロセス　①データ抽出・集計　②機械学習プロジェクト 基盤　①ViewとModelの分離　②データの信頼担保　③使われるための保守・運用 チーム　①運営の安定化　②採用・育成・アウトソース　③体制拡大による痛み 文化　①Measureから始める　②組織に浸透させる　③非エンジニアの壁を壊す 238
239. 文化③　非エンジニアの壁を壊す 239
240. 利用手順やサンプルSQLのサポート 1. 定型業務向けSQLを渡して「ここの数字を変えるだけですよ」と案内 2. ディレクターがSQLを自主勉強して「ここについて教えて欲しい」と声を掛けてくれるように 3. 事務スタッフが当たり前のように BigQueryを叩く世界 240
241. エンジニア / 非エンジニアの枠を超える ディレクターがエンジニアに頼らずにレコメンドロジックを磨き込む 1. SQLを叩いてデータから仮説を立てる 2. レコメンドのパラメータを変更する（設定ファイルから反映する仕組み） 3. ABテストの結果をSQLで分析してレポートする 241
242. チームごとの民主化状況 各チームがデータ活用できているかモニタリング → ブロッカーの検知・分析 → 改善アクション 242
243. この文化を広げるために まずはやってみる！ 日々ひたすら改善！ 243
244. アジェンダ 背景　①プロダクト・チーム　②データ活用事例 案件　①KPIモニタリング　②業者・不正ユーザー対策　③集客広告配信 プロセス　①データ抽出・集計　②機械学習プロジェクト 基盤　①ViewとModelの分離　②データの信頼担保　③使われるための保守・運用 チーム　①運営の安定化　②採用・育成・アウトソース　③体制拡大による痛み 文化　①Measureから始める　②組織に浸透させる　③非エンジニアの壁を壊す 244
245. 文化のまとめ 245
246. データチームだけではスケールしません 現場の担当者1人1人が活躍できるよう 「データの民主化」の取り組みをお伝えします 246 （再掲）
247. DataとOpsを繋げる 247 http://simpleicon.com/gear-7.html データ と 作業（業務） を繋げる テクノロジー と ビジネス現場 を繋げる データを活用することで 自身が抱える業務課題 を解決する
248. 事業の成長を支える（再掲） ・現場の1人1人が主役となり、データを活用 して プロダクトや業務 を磨き込む ・この積み重ねによって事業が成長し、顧客に価値を届けることになる 248
249. 事業のグロースを支える DataOpsの現場 2018-07-27 Developers Summit 2018 Summer presented by @yuzutas0 https://www.pexels.com/photo/abstract-art-blur-bright-373543/ これこそが（タイトル再掲）
250. アジェンダ 背景　①プロダクト・チーム　②データ活用事例 案件　①KPIモニタリング　②業者・不正ユーザー対策　③集客広告配信 プロセス　①データ抽出・集計　②機械学習プロジェクト 基盤　①ViewとModelの分離　②データの信頼担保　③使われるための保守・運用 チーム　①運営の安定化　②採用・育成・アウトソース　③体制拡大による痛み 文化　①Measureから始める　②組織に浸透させる　③非エンジニアの壁を壊す 250
251. 251 事業グロース データ活用案件 信頼できるシステム 効率的なプロセス 安定したチーム データ活用文化
252. 色々な人たちが試行錯誤してきたのと同じ （細部や対象や文脈は違うが） 要求整理、要件定義、業務分析、デジタルトランスフォー メーション、xOps、ジョブ理論、バリューストリーム、価値 フロー、サプライチェーン、トヨタウェイ、リーン、制約理 論、アジャイル、ITIL、SRE、DevOps、顧客開発、デザ イン思考、HCD、CRM、マーケティングオートメーショ ン、機械学習工学 252
253. 銀の弾丸はない まずはやってみる！ 日々ひたすら改善！ 253
254. アンチパターンや泥臭い話も伝えてきましたが ぜひ行動を躊躇わないでほしいです 1人1人が行動した先に 個人としても、事業としても、社会としても グロースがあるのだと思います 254
255. DataOps は1人にしてならず ① Special Thanks for 22 代表として発表しましたが、実際には彼らの功績です Naoya Osugi　Shinryo Uchida Shin Kanouchi　GeeWook Kim　Koh Fujiwara　Kouga Kobayashi Takuya Beppu　Shinsaku Kono Mitsuhiro Nakamura　Kazuki Oodo　Sosuke Kakehi　Yuka Tamura　Kenichi Suda Shunketsu Oh　Hikaru Izumisawa　Miki Kakihana　Hideshi Ogushi Sho Ito　Shinya Nishinaka　Naoki Ainoya　Kyosuke Tanaka　Ryusuke Kawasaki 255
256. DataOps は1人にしてならず ② Special Thanks for 18 遷宮プロジェクト(周辺)の皆様 Akira Yoshino　Shunsuke Hamaoka　Atsushi Oda Kento Obata　Shunji Makino　Motofumi Shishikura　Ryohei Iwata ブートキャンプの皆様 Aoi Fukuoka　Kosuke Hiramatsu　Masataka Ikeda Ryoya Komatsu　Takuma Nishino　Ryosuke Mita　Takuya Morimatsu Tomonari Takahashi　Kento Tsuji　ZIJUN WEI　Yuji Amano 256
257. DataOps は1人にしてならず ③ Special Thanks for 24 プロダクトな皆様 Shun Ono　Tatsuya Ishibe　Shota Kohara　Kenta Hara　Kento Sasamoto Takahiro Kato　Hiroki Sakamoto　Hidetada Suzuki　Shunya Matsubara　Yojiro Motoba Ryo Inoue　Kohei Aota　Akira Higuchi ビジネスな皆様 Satoru Washio　Shunya Tabata　Toshiya Matsui　Heesung Lee　Kanata Yuasa　Tomoya Nakajima Megumi Matsukura　Seiichi Shishido　Hirokazu Tajima　Tomokazu Mizoguchi　Naruya Ohta 257
258. DataOps は1人にしてならず ④ Special Thanks for 16 社内でお世話になった皆様（どっちかというとデザイン系） Mizuki Takenobu　Yusaku Tokunaga　Shohei Aizu　Tomoko Kanatani 社内でお世話になった皆様（どっちかというとエンジニアリング系） Ryoma Fujiwara　Akito Ito　Katsuya Miyachi　Nao Yonashiro Shotaro Magara　Akira Yamaguchi　Yu Kabutoya　Yuki Tsukuda　Katsuhiko Higuchi どっちかというと社外連携面でお世話になった皆様 Yuki Tanaka　Yoshiyasu Saeki　Hironori Arakawa　 258
259. DataOps は1人にしてならず ⑤ Special Thanks for 14 組織面でサポートいただいた皆様 Norihisa Miyakawa　Satoshi Uejima　Kenichi Takahashi　Kazuhito Gomi Keisuke Sone　Ayaka Nagayasu　Takeshi Sato 登壇にあたってサポートいただいた皆様 Kae Washimi　Saki Kato　Kazutaka Sakurai　Yotaro Takahashi Muneaki Nishimura　Toshiharu Sugiyama　Yuji Ino 259
260. DataOps は1人にしてならず ⑥ Special Thanks for 2 + α Inspired by Kazushige Shida　Itsuki Kuroda　 その他 書ききれなかった方々含めて全ての関係者の方々 ※資料・内容に誤りや不適切な表現があれば発表者のミスです。 お気付きの方はお手数をお掛けしますが @yuzutas0 にご連絡いただけると幸いです。 260
261. アンチパターンや泥臭い話も伝えてきましたが ぜひ行動を躊躇わないでほしいです 1人1人が行動した先に 個人としても、事業としても、社会としても グロースがあるのだと思います 261 （再掲）
262. 銀の弾丸はない（再掲） まずはやってみる！ 日々ひたすら改善！ 262
263. 本日のゴール（再掲） いますぐに行動できるヒントを持ち帰っていただくこと 263
264. 1: 現場の業務（Ops）に目を向ける Ops を改善するから、価値が生まれる 「誰のどんな課題を解決したいのか？」 すでに動いている人は ぜひこの観点で見返して改善のきっかけにしてほしいです まだ動いていない人は これから動くために担当している業務について考えてほしいです 264
265. 2: テクノロジーや手法（Data）を楽しむ Data を活用するから、可能性が広がる 「この技術でどんなことができるだろう？」 私自身もCourseraでML講座の受講から始めました こうした1人1人、1つ1つの小さな努力の積み重ねです だからこそ、ぜひ興味のあることに挑戦してみてほしいです せっかくなら一緒に楽しんでいきたいです 265
266. こういったテーマについて 午後のセッションで有識者の方々が 色々な話をしてくださる とのことなので デブサミを楽しんでいきましょう 266
267. ご清聴ありがとうございました https://www.pexels.com/photo/abstract-art-blur-bright-373543/
268. 結論 AI じゃなくて 愛 （現場への） 268 ダダ滑りだったのでAppendixに追放