事業のグロースを支えるDataOpsの現場

Slide 1

Slide 1 text

事業のグロースを支える DataOpsの現場 2018-07-27 Developers Summit 2018 Summer presented by @yuzutas0 https://www.pexels.com/photo/abstract-art-blur-bright-373543/

Slide 2

Slide 2 text

はじめに 2

Slide 3

Slide 3 text

本日の資料はWEBに公開します #devsumi 撮影・記録の必要はありませんくつろいで聴いていただければと思います 3

Slide 4

Slide 4 text

スライド 260+ 枚 / 45min （知見をがっつり共有します）・疲れると思うので、興味のある部分をメインで聞いてください・飛ばしながら進めるので、細かいところは後で読んでください・ちょっとだけ盛ってるところもあるけど気にしないでください 4

Slide 5

Slide 5 text

どう考えても無理なのでどのトピックに興味があるか後ほど伺います 5

Slide 6

Slide 6 text

Sho Yokoyama @yuzutas0 　　　　　リクルートテクノロジーズ　　 ITエンジニアリング本部プロダクトエンジニアリング部　　　ベンチャーキャピタルから投資を受けての起業・会社経営、　　　リクルートグループ会社における複数の新規事業の立ち上げを経て、現職。　　　主に急成長プロダクトを対象に、システムアーキテクチャの再構築や　　　エンジニアチームの立ち上げ・立て直しに従事。　　　最近は「現場で使われるデータ基盤」を軸に、　　　組織全体におけるデータ活用を推進しています。 6

Slide 7

Slide 7 text

過去の資料本日の内容と重複するところが多々あります 7 http://www.atmarkit.co.jp/ait/articles/1804/23/news011.html https://speakerdeck.com/yuzutas0

Slide 8

Slide 8 text

失敗や苦労を重ねてきました 8 どれだけ作り込んでも誰も見なかったダッシュボードデータを綺麗に描画するだけでは足りないらしい納品から半年経っても本番に乗らなかったMLスクリプト機械学習エンジニアの召喚だけでは足りないらしいデータ基盤整備のために読み解いた膨大なExcelシート DWHシステムを導入するだけでは足りないらしい

Slide 9

Slide 9 text

理想に辿り着くためには、泥臭い過程が必要だった華やかなキラキラ事例とのギャップ 9 世を見渡せばキラキラした事例にあふれているいざ自分たちでやろうとすると失敗だらけデータの民主化データ基盤の構築分析チームの立ち上げ機械学習プロジェクト

Slide 10

Slide 10 text

世の流れもやってみたから “価値創出・運用” 志向に 10 https://mlxse.connpass.com/event/80434/ http://kskbyt.hatenablog.jp/entry/2018/02/17/222015

Slide 11

Slide 11 text

象徴的な言葉が “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/

Slide 12

Slide 12 text

あえて言うなら DevOps のデータ活用版 DevOps: Dev（システム開発者）と Ops（システム運用者）の協働に端を発した全体最適のパラダイムと解釈して今回は話を進めます参考「経営のアジリティを支える DevOpsと組織」（Developers Summit 2015 Summer） https://www.slideshare.net/recruitcojp/devops-51085988 DataOps: Data（データ）とOps（業務）を結びつけることによって価値創出を最大化するパラダイムと解釈して今回は話を進めます 12

Slide 13

Slide 13 text

本セッションで想定する対象・結果ではなく「登り方・道のりを知りたいんだ！」という方・ビジネスでデータ活用に携わるソフトウェアエンジニア 13

Slide 14

Slide 14 text

本日お伝えすること / しないこと知識個々のテクノロジーや開発手法の詳細 DataOps is not tied to a particular technology, architecture, tool, language or framework. by https://en.wikipedia.org/wiki/DataOps 事例案件・システム・プロセス・文化・組織をエンジニアリングしてきた現場のリアル（要するに苦労話） 14

Slide 15

Slide 15 text

DataとOpsを繋げる話です 15 http://simpleicon.com/gear-7.html データと作業（業務）を繋げる話ですテクノロジーとビジネス現場を繋げる話ですデータを活用することで誰のどんな課題を解決するのかと問い直した話です

Slide 16

Slide 16 text

とはいえ、今も試行錯誤の日々です 16 　まだまだ新参者です。　・発表者自身（@yuzutas0）がデータ活用の推進を始めて 1.5年弱　・正式な部隊を立ち上げてから 0.5年 + α 　・前を進んでいる方には、振り返りや見直しの機会を　・これからの方や始めたばかりの方には、0.5歩先の知見を　提供できればと思っています

Slide 17

Slide 17 text

本日のゴールいますぐに行動できるヒントを持ち帰っていただくこと 17

Slide 18

Slide 18 text

アジェンダ背景　①プロダクト・チーム　②データ活用事例案件　①KPIモニタリング　②業者・不正ユーザー対策　③集客広告配信プロセス　①データ抽出・集計　②機械学習プロジェクト基盤　①ViewとModelの分離　②データの信頼担保　③使われるための保守・運用チーム　①運営の安定化　②採用・育成・アウトソース　③体制拡大による痛み文化　①Measureから始める　②組織に浸透させる　③非エンジニアの壁を壊す 18

Slide 19

Slide 19 text

どう考えても無理なのでどのトピックに興味があるか後ほど伺います 19 リマインド

Slide 20

Slide 20 text

Slide 21

Slide 21 text

プロダクト・チーム 21

Slide 22

Slide 22 text

プロダクト 22 婚活恋活 http://www.recruit-mp.co.jp/service/zexy.html

Slide 23

Slide 23 text

利用の流れ 23 月額課金モデル　※恋結び女性ユーザーは本人確認料のみ STEP 1 STEP 2 STEP 3 気になったら「いいね！」お互いにいいね！でマッチングメッセージでやりとり開始

Slide 24

Slide 24 text

市場はグロース期・米国では結婚したカップルの 1/3がオンラインでの出会い・他ドメインの大規模サービスに比べて、チームやプロダクトとしてはまだ発展途上のフェーズ 24

Slide 25

Slide 25 text

ほか：スタッフ用の業務管理ツールなどのサブシステムシステム概略（カスタマー向けアプリ） 25

Slide 26

Slide 26 text

データ基盤 26

Slide 27

Slide 27 text

データ基盤担当現場ではBigQueryというソリューションを利用・他ツールではそのまま再現できない手法も出てきます・各自の環境に照らしながら聞いていただければと思います 27 Google Cloud 発表資料より引用

Slide 28

Slide 28 text

ステークホルダー社内かつ現場レイヤー（サービスとしての開発・運用業務を実際に担当している方々） 28

Slide 29

Slide 29 text

データチーム 29

Slide 30

Slide 30 text

知見の横展開婚活事業におけるデータ活用　　　婚活データチーム（通称 D4C）知見を他事業に展開横断研究会（ゆるキバン△ DataOpsプロジェクト） 30 https://recruit-holdings.co.jp/ir/library/upload/annual_2016_04.pdf 世界でも有数のボトムアップ型のデータ組織（自称）・トップダウンで体制が作られたのではなく、有志が現場の事例を積み重ねて仕組みを作っている・本日は社内横断研究会でレポートされた知見・事例の一部をお伝えします

Slide 31

Slide 31 text

Slide 32

Slide 32 text

データ活用事例 32 ※検証段階のものやスポットでの取り組みを含んでおります

Slide 33

Slide 33 text

KPIモニタリングビジネス指標（売上や Daily Active User）の推移 33 毎朝のSlack通知 Spreadsheet ダッシュボード

Slide 34

Slide 34 text

ユーザー行動の可視化主要導線（会員登録から成婚退会まで）における利用・離脱 34 行動ファンネルジャーニーマップ

Slide 35

Slide 35 text

施策の効果見立て・計測 35 ABテスト結果新機能の利用度合い

Slide 36

Slide 36 text

機械学習によるレコメンド 36 http://image.itmedia.co.jp/l/im/ait/articles/1804/23/l_news011_04.jpg

Slide 37

Slide 37 text

迷惑行為の自動検知過剰アクセスなどの異常パターンを特定 37

Slide 38

Slide 38 text

問い合わせの傾向分析 38

Slide 39

Slide 39 text

広告配信の最適化 39

Slide 40

Slide 40 text

ニュースレター分析結果をメディアに情報提供することで市場活性化に貢献 40 http://www.recruit-mp.co.jp/news/release/2017/0531_3216.html

Slide 41

Slide 41 text

システムモニタリングデバイスシェアやクラッシュ率、レスポンスタイム 41 http://yuzutas0.hatenablog.com/entry/2017/05/23/073000

Slide 42

Slide 42 text

障害発生時の影響調査 42

Slide 43

Slide 43 text

チームのキャパシティスクラムチームのベロシティやチケット消化のメトリクス 43

Slide 44

Slide 44 text

Slide 45

Slide 45 text

3つのデータ活用案件をご紹介します案件を通して Data と Ops を結びつけることの重要性をお伝えします 45

Slide 46

Slide 46 text

案件①　KPIモニタリング 46

Slide 47

Slide 47 text

最初にやったことデータ活用の第一歩は可視化である（はずだと考えた）・あらゆるデータをいい感じに見ることのできるすごいダッシュボードを作ろう・綺麗なダッシュボードを構築できたら、誰もが目にするようにオフィスのモニターに投影しよう 47

Slide 48

Slide 48 text

サービスの利益構造とKPIツリー 48 https://growthhackjournal.com/kpi-tree-for-app/

Slide 49

Slide 49 text

俺の考えた最強のダッシュボード 49

Slide 50

Slide 50 text

高まる期待 1. 毎日のKPIをすらすら言えるようになるかも 2. 異常値に気づいて迅速に動けるようになるかも 3. ビジネスコミットできる強いエンジニアチームになるかも 50

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

打ち手として妥当？ 52 期待した状態打ち手

Slide 53

Slide 53 text

何のためのデータ？ 53 https://twitter.com/msmt9/status/778865480379412481

Slide 54

Slide 54 text

まずは弟子入りから 54 そもそも成功状態をイメージできる？普段からデータを見ている人たちって、具体的に何をやっているの？毎日データを見ているディレクターやマーケッターに相談して仕事を教えてもらった

Slide 55

Slide 55 text

デイリーレポートを自動配信毎日のデータ集計・レポーティング作業を手動運用していたので既存業務を自動化する形でSlackにシンプルなグラフを配信した 55

Slide 56

Slide 56 text

圧倒的成果「めちゃくちゃ生産性あがりました！」の声ディレクターやマーケッターが Slackの日次データを見ているので二人三脚で案件を担当するエンジニアメンバーも徐々にデータを見るようになった 56

Slide 57

Slide 57 text

これだけでよかった・シンプルなグラフと数値をいつも見ているチャットに流すだけでよかった・既存オペレーションを組み合わせた「無理のない」「自然にデータを見る」体験デザイン・「いつ / どこで / 誰が / なぜ / どういう手順で / 何をするのか」（5W1H）まで解像度を上げる 57 毎朝の出社（既にやっていたこと）出社後にSlackを見る（既にやっていたこと）意思決定する（既にやっていたこと） 1. オフィスに出社する 2. PCを開く 3. Slackが自動で起動 → 1. 未読チャンネルを開く 2. 画面をスクロールする　（= 読む）ここで日次KPIレポート → （例）・新機能のリリース翌日に数字を見て　施策が当たったか、予期せぬ離脱を　招いていないかを確認する　（次の施策のインプットにする）・マーケッターが登録数の推移を見て　その日の広告予算を調整する

Slide 58

Slide 58 text

業務（Ops）に注目する 58 「派手なダッシュボードであること」よりも「業務にどう影響を与えるのか」を考えるいつどこで誰が何のためにどのデータをどのように見たいのか？（完全な0→1でもない限り）すでに何らかの形で業務やシステムは存在していて、そこから価値が生み出されているデータを活用するというのは、その価値の流れを改善（あるいは改革？）するということ

Slide 59

Slide 59 text

Slide 60

Slide 60 text

案件②　業者・不正ユーザー対策 60

Slide 61

Slide 61 text

安心・安全のための取り組み 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

Slide 62

Slide 62 text

テクノロジーでもっと改善できないか ⇒ 機械学習エンジニア・セキュリティエンジニアが集結 62 スタッフが巡回監視・パトロールシステムによる早期検知？ https://www.irasutoya.com/2018/07/blog-post_403.html

Slide 63

Slide 63 text

CREシステムの構築・導入各利用フェーズで得られるデータから特徴量を抽出過去パターンから業者・不正ユーザーの候補リストを生成する（最後はパトロールスタッフによる目視確認） 63 ※実際の内容とは異なります。あくまでもシステムをイメージするための参考としてご認識ください。

Slide 64

Slide 64 text

⇒ 機械学習エンジニア・セキュリティエンジニアが集結 64 スタッフが巡回監視・パトロールシステムによる早期検知？ https://www.irasutoya.com/2018/07/blog-post_403.html 機械学習のスクリプトは早々に完成した！が、実運用に乗るまで半年以上掛かった…… （ちなみに精度は当初想定を超えて圧倒的成果だった！これは良かった！）現実は非情である

Slide 65

Slide 65 text

アルゴリズムだけじゃなかった 65 　ステークホルダー調整　　パトロールスタッフが作業手順を学ぶためのインプットはどうするか　　カスタマー観点やビジネス観点での影響はないか　業務運用設計　　システムが自動検知したあとに、目視確認にどう繋ぐのか。　　候補リストを渡すなら、どんなリスト形式？いつ？どこで？誰に？どうやって渡す？　システム間連携　　新たに開発した機械学習スクリプト単体だけでは完結しないので、　　ユーザーが利用するサービス本体、パトロールスタッフ向けシステムとどう結合するか

Slide 66

Slide 66 text

業務（Ops）に注目する 66 テクノロジー（Data）単体ではなく、業務全体（Ops）への視点システム連携設計や業務フロー分析ステークホルダーとの認識合わせや運用装着要するに：機械学習の案件にもプロジェクトマネジメントが必要予測精度が出るか分からないなら、その不確実性を前提としたプロジェクトを計画すべきだった　　　　　　　　　　　　　　　　　　　・まずはデモ環境で試してリストの受け渡しは手動でやるとか　　　　　　　　　　　　　　　　　　　・明らかに効果が出るルールベースの機能に絞って先に運用に乗せるとか

Slide 67

Slide 67 text

Slide 68

Slide 68 text

案件③　集客広告配信 68

Slide 69

Slide 69 text

有料集客によるユーザーの獲得 69 あああ Referral（紹介） Acquisition（獲得） Activation（利用） Retention（継続） Revenue（収益）

Slide 70

Slide 70 text

媒体Aと媒体Bのどちらに広告を配信する？ 70 ※これらの広告媒体はイメージ例です

Slide 71

Slide 71 text

やっていきマーケティングを自動で良い感じにやってくれるすごいシステムを作るぞぉおおおおおおおおおお！ 71

Slide 72

Slide 72 text

72 ※これらの広告媒体はイメージ例ですぜんっっっっっっっっぜん効果が出なかった！現実は非情である

Slide 73

Slide 73 text

まだまだプロダクトは発展途上のフェーズ・少数のメンバーで集客における勝ち筋やプロセスを模索している段階・「意思決定」や「業務」を機械に置き換えようとしても「正解」となるパターンが見えていなかった・不確定な部分について仮置きして進めようとして（主に発表者 @yuzutas0 が）見事にずっこけた 73

Slide 74

Slide 74 text

まずは個々の担当を磨き込むいきなり最適化は苦戦 ↔ オペレーション＆データの可視化 ⇒ 効率化による利益創出が可能 74 Before After マーケティング担当 → 手動で実施している業務についてオペレーション整理・改善データエンジニア → 広告関連データをデータ基盤に統合したり、マーケティング業務を少しずつ自動化機械学習エンジニア → 特定の業務や広告媒体に絞って自動最適化連携して最適化システムを作ろうぜ！ NG! OK!

Slide 75

Slide 75 text

（結果的に）業務の可視化と改善テクノロジーによって広告配信の企画（Biz）・開発（Dev）・運用（Ops）サイクルを支援 75

Slide 76

Slide 76 text

（可視化の過程で）利益創出 76 マーケティング担当「このデータを出せるようにしたい。少し気掛かりなことがある。」データエンジニア「やってみた！けど、この結果って......。」一部の広告媒体の効果がそこまで高くないことが分かったマーケティング計画の大幅な方針変更を検討

Slide 77

Slide 77 text

それまでは獲得効率を目的変数にしていた 77 あああ Referral（紹介） Acquisition（獲得） Activation（利用） Retention（継続） Revenue（収益）

Slide 78

Slide 78 text

集客を収益効率で見ると結果が変わった 78 あああ Referral（紹介） Acquisition（獲得） Activation（利用） Retention（継続） Revenue（収益）

Slide 79

Slide 79 text

あああ Referral（紹介） Acquisition（獲得） Activation（利用） Retention（継続） Revenue（収益）データ元が違うから横断分析できなかった 79 マーケティング担当が使うアクセス解析ツール（プロダクトの前の世界を扱うデータ）ソフトウェアエンジニアが見るデータベース（プロダクトの中の世界を扱うデータ）

Slide 80

Slide 80 text

単一データの世界観から 80 アクセス解析ツールサーバサイド DB ユーザーの流入ログユーザーの購買記録エンジニアが参照マーケッターが参照アクションベース（CPA）を計測広告媒体A を重視 https://boxil.jp/mag/a2829/

Slide 81

Slide 81 text

統合データの世界観へ 81 アクセス解析ツールサーバサイド DB ユーザーの購買記録エンジニアが参照マーケッターが参照アクションベース（CPA）を計測広告媒体A を重視データ基盤ユーザーの流入ログ売上ベース（ROAS）を計測広告媒体B を重視 https://boxil.jp/mag/a2829/

Slide 82

Slide 82 text

売上を伸ばすモニタリングデータを見る → 行動が変わる → 結果が変わるデータを繋げて可視化するだけでビジネス改善のインサイトを得られる（こともある）自動判定とか以前に、データソースを繋げて見るだけで、価値創出につながったスペシャリストが大きな絵を描かなくても、ちょっとしたデータを出すだけで効果があったりする 82

Slide 83

Slide 83 text

データ（Data）と業務（Ops）は両輪 83 Data を機会として Ops を可視化する広告配信をいきなり全て自動化しようとしても上手くいかないデータを活用するためには 1つ1つの業務を紐解くことになる Ops を通して Data を引き出す広告効果をより正確にモニタリングするにはシステムが進化しないといけない 1つ1つの業務を改善しようとしたらデータが必要になる

Slide 84

Slide 84 text

Slide 85

Slide 85 text

案件のまとめ 85

Slide 86

Slide 86 text

3つのデータ活用案件をご紹介します案件を通して Data と Ops を結びつけることの重要性をお伝えします 86 （再掲）

Slide 87

Slide 87 text

データ活用による価値創出バリューストリームにおいてリターンを上げる or コストを下げる 87

Slide 88

Slide 88 text

データ活用による価値創出バリューストリームにおいてリターンを上げる or コストを下げる・例：RPAによるマーケティング業務やカスタマーサポート業務の一部自動化・レコメンド機能はユーザーの探索業務（一般的には情報収集 →比較検討→意思決定→アクション）を支援するソリューション 88

Slide 89

Slide 89 text

DataとOpsを繋げる 89 http://simpleicon.com/gear-7.html Data（データ）と Ops（業務）を結びつけることで価値を創造することができるデータを使うことによって誰が抱えるどんな不を解決したいのか・情報社会においては何をするにも多くの「意思決定」を必要とする・意思決定を支える / 自動化するのが「データ分析」や「機械学習」

Slide 90

Slide 90 text

事業の成長を支える・現場の1人1人が主役となり、データを活用してプロダクトや業務を磨き込む・この積み重ねによって事業が成長し、顧客に価値を届けることになる 90

Slide 91

Slide 91 text

事業のグロースを支える DataOpsの現場 2018-07-27 Developers Summit 2018 Summer presented by @yuzutas0 https://www.pexels.com/photo/abstract-art-blur-bright-373543/ これこそが（タイトル再掲）

Slide 92

Slide 92 text

Slide 93

Slide 93 text

93 事業グロースデータ活用案件信頼できるシステム効率的なプロセス安定したチームデータ活用文化

Slide 94

Slide 94 text

データ活用案件を支えるプロセス？　　　　　　完璧な企画書？　　　　　　圧倒的な予算？　　　　　　1年間の開発プロジェクト？ 94

Slide 95

Slide 95 text

データ活用案件を支えるプロセス？　　　　　　完璧な企画書？　　　　　　圧倒的な予算？　　　　　　1年間の開発プロジェクト？ 95 ×

Slide 96

Slide 96 text

1年後に待つもの ● 思っていたのと違った ● 良さそうだけど結局使わなかった 96

Slide 97

Slide 97 text

「本当に必要だったもの」には届かない 97 http://www.projectcartoon.com/

Slide 98

Slide 98 text

というか「答え」が存在しない Q.　最初に要件を全部洗い出せばOK？ A.　NG！「やりたいこと」は変わる！ ● 他社ブログを見て「うちもやりたい！」 ● 新しいBIツールの提案に「これいい！」 ● 実際に画面を作ったら「なんか違う！」 98

Slide 99

Slide 99 text

なぜデータ活用は難しい？「システムを作って終わり」ではないから　　　　　　　　　　　・利用者に実際に使われるか？　　　　　　　　　　　・予測精度が一定以上となるか？　　　　　　　　　　　・利益の創出に貢献できるか？しかもビジネス環境、テクノロジー進歩、プロダクト仕様、チーム・体制、業務内容でさえ日々変わっていく（特にグロースフェーズの場合）極めて不確実性の高いプロジェクトそもそもプロダクト開発というのは本質的に不確実性との戦い。システム部門がビジネスから遠ざかっていると見えにくいだけ。 99 https://unsplash.com/photos/vBpd607jLXs

Slide 100

Slide 100 text

不確実性を前提としたプロセスが必要「学びの最大化」に注目する参考『リーンスタートアップ』　　　　　（例）　　　　　　　・リスクの大きい要素を先に検証する　　　　　　　・案件のバッチサイズを小さくする　　　　　　　・高速にイテレーションを回すリスクを抑えながら現場の業務（Ops）を読み解く 100 http://ec.nikkeibp.co.jp/item/books/P48970.html

Slide 101

Slide 101 text

小さく試すことでリスクを抑えながら Data と Ops を読み解くことが重要ですプロセスの具体例を2つご紹介します 101

Slide 102

Slide 102 text

Slide 103

Slide 103 text

プロセス①　データ抽出・集計 103

Slide 104

Slide 104 text

抽出・集計だけでも利益に寄与しうる先ほど紹介した集客モニタリング案件 104

Slide 105

Slide 105 text

約300案件を捌きまくった 105 ↓は四半期への言及なのでトータルはもっと多いです（念のため）

Slide 106

Slide 106 text

データ抽出・集計の業務 106

Slide 107

Slide 107 text

MVPで小さく作る・要求者は「自分が本当に必要とするデータ」を知らないまま依頼する（業務フローが不明確）・多くはすぐに使わなくなる＆見なくなる（余分な機能のムダ）・一部は実運用が進む → 最適IFを提供：正しい要求にもとづいて作り直す　活用側の独自システムやシートが複雑化して保守困難になるので、整理してデータパイプラインに組み込む 107 http://ec.nikkeibp.co.jp/item/books/P48970.html

Slide 108

Slide 108 text

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

Slide 109

Slide 109 text

MVP - CSVファイル凝ったグラフを描く前に、データ自体を速やかに受け渡す・データさえあれば Excel や Spreadsheet で当面はどうにかできる・Jupyter Notebook や BigQuery UI でCSVファイルを出力 109

Slide 110

Slide 110 text

MVP - Data Studio コマンド1つで即席のダッシュボード・簡易作成したら後は好きに使ってもらう・まだ自由度は高くないが固定指標のモニタリングなら問題なく使える 110

Slide 111

Slide 111 text

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

Slide 112

Slide 112 text

不要になったらクリーニング大抵は見なくなるので毎週のふりかえりでクリーニングする（後述）そのタイミングで「本当に必要だったデータは何か」を振り返って次に活かす 112

Slide 113

Slide 113 text

生き残った案件だけを磨き込む 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

Slide 114

Slide 114 text

案件ライフサイクルスタートアップと同じように小さくテストしながら、段階的に要求・設計を磨き込む（ひたすら螺旋のように繰り返す） 114

Slide 115

Slide 115 text

Slide 116

Slide 116 text

プロセス②　機械学習プロジェクト 116

Slide 117

Slide 117 text

作って終わりではない！システムを磨き込む！業者・不正ユーザー対策の機能追加 117

Slide 118

Slide 118 text

小さく検証しながら進める 118 データ分析による仮説構築（Data）パラメータ追加で予測精度は向上しそうか by MLエンジニアモックアップによるUI構築（Ops）スタッフに見てもらって運用できそうか by APエンジニア ↓ ↓ 設計・コーディング・システムテスト ↓ デモ環境で並行稼働させるダークローンチ効果検証：システム観点に加えて予測精度（Data）と業務運用（Ops） ↓ 本格移管・リリース

Slide 119

Slide 119 text

データ分析による仮説構築 Data（データ）を検証するどのパラメータを追加すると予測精度は向上しそうか MLエンジニアが主体となって実施 119

Slide 120

Slide 120 text

モックアップによるUX構築 Ops（業務）を検証するスタッフに画面を見てもらって運用できそうか APエンジニアが主体となって実施 120

Slide 121

Slide 121 text

ダークローンチによる検証デモ環境でシステムを並行稼働させることでパトロールスタッフが利用可能な状態にする本番相当のData（データ）やOps（業務）でシミュレーションを実施システム観点でのステージング試験に加えて予測精度（Data）と業務運用（Ops）において本番リリース可能かどうかを検証する 121

Slide 122

Slide 122 text

余談：インタビューによる仮説構築データを見るよりもユーザーに話を聞いたほうが早いこともあるリサーチ担当と連携してユーザーインタビューを実施 122

Slide 123

Slide 123 text

Slide 124

Slide 124 text

プロセスのまとめ 124

Slide 125

Slide 125 text

125 （再掲）小さく試すことでリスクを抑えながら Data と Ops を読み解くことが重要ですプロセスの具体例を2つご紹介します

Slide 126

Slide 126 text

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

Slide 127

Slide 127 text

データ案件でもMVP ホワイトボードスケッチ、 CSVファイル、DataStudio、Slack自動配信 etc... 127

Slide 128

Slide 128 text

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

Slide 129

Slide 129 text

データ案件でもステージゲート 129

Slide 130

Slide 130 text

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

Slide 131

Slide 131 text

データ案件でも革新会計 131 https://www.oreilly.co.jp/books/9784873115917/ http://www.shoeisha.co.jp/book/detail/9784798128511

Slide 132

Slide 132 text

DataとOpsを繋げる 132 http://simpleicon.com/gear-7.html そのデータを使うことによって解決したい課題を解決できるか・なるべく小さなバッチサイズに分解する・高速にイテレーションを回す・案件のフェーズを登っていく Data（データ）と Ops（業務）が結びつくか、テストしながら進めていく

Slide 133

Slide 133 text

事業の成長を支える（再掲）・現場の1人1人が主役となり、データを活用してプロダクトや業務を磨き込む・この積み重ねによって事業が成長し、顧客に価値を届けることになる 133

Slide 134

Slide 134 text

Slide 135

Slide 135 text

Slide 136

Slide 136 text

136 事業グロースデータ活用案件信頼できるシステム効率的なプロセス安定したチームデータ活用文化

Slide 137

Slide 137 text

安易な “小さく試す” では解決できないのがシステムの難しいところです「使われるデータ基盤」のための紆余曲折をご紹介します 137

Slide 138

Slide 138 text

基盤①　ViewとModelの分離 138

Slide 139

Slide 139 text

各々がデータを利用各案件を担うデータサイエンティストや MLエンジニアが「とりあえず」「小さく試す」ために独自にデータを取得・加工 139

Slide 140

Slide 140 text

部署ごとに「売上」がズレる問題「売上」と一言で言っても、考え方や用途によって定義は変わるさまざまな計算方法が考えられる・消費税を含むのか・割引分はどこで差し引くのか・年間契約プランは月次で按分するのか・按分する場合は途中解約をどこに計上するのか・返金は後で一括で差し引くのか、購入時にさかのぼって差し引くのか・モバイルアプリの課金はAppleやGoogleへの決済手数料を含むのか・用途は財務会計か管理会計かあるチームは自分たちの施策によって KPIが大幅に上がったと主張しても別のチームからは何の参考にもならない数字に見えるどのデータが正しいのか誰も分からないので、横断での意思決定や調整が困難になる 140

Slide 141

Slide 141 text

コンウェイの法則「とりあえず」「小さく試す」を繰り返した結果、システム全体が過剰に複雑化 141

Slide 142

Slide 142 text

データ基盤の必要性データソース（Data）と利用者（Ops）をリボンのように結び付けるものプロダクト成長や体制拡大によってリボンの両側が多様になるとデータ基盤が必要になる「データ基盤」を作ること自体は目的ではない 142

Slide 143

Slide 143 text

責務に応じたシステムの分離・結合・SREチーム* が全体設計から見直してデータ基盤を整備・Model（収集・蓄積・加工）と View（参照・利用） 143 *この論点の取りまとめはSREが望ましい。ビジネス経営に近い立場のロールが判断しても情報システム設計の専門家でないと、データモデリングやシステムは設計破綻しがち。

Slide 144

Slide 144 text

Slide 145

Slide 145 text

基盤②　データの信頼を担保する 145

Slide 146

Slide 146 text

システムがあるだけでは使われない・既存の業務（Ops）は既存のデータ（Data）を使っている・最も信頼されていたのは Excel だった　ツールとしては運用の限界を迎えていた・これまで使っていたデータとズレると業務影響が出てしまう / 信用できない 146

Slide 147

Slide 147 text

ExcelからBigQueryにデータを移行する Excelの多重参照や謎ロジックを読み解きながら SQLに反映していく 147

Slide 148

Slide 148 text

重厚長大なExcelを解読するマインドマップによる整理スライドに入るように（入りきってないけど）縮めたら画像が潰れてしもうた…… 148

Slide 149

Slide 149 text

既存の計算ミスやデータ不整合を発見とにかく数字が合わない 149

Slide 150

Slide 150 text

特にデータクレンジングひらすら地味な作業が続く 150

Slide 151

Slide 151 text

最終出力（30項目）を置き換え 151

Slide 152

Slide 152 text

別のExcelシート（500項目）が出てきた 152

Slide 153

Slide 153 text

その先は地獄だぞ・まさにシステム再構築案件（仕様書なし）と同じ状況・いわばデータ基盤のEOL 対応・小手先の工夫でどうにかできるレベルではない 153 https://www.pexels.com/photo/water-outside-fire-hose-69934/

Slide 154

Slide 154 text

アルバイトを募集した体制をスケールして 1人当たりの負担を減らさないと（自分が）辛すぎる 154

Slide 155

Slide 155 text

500項目を置き換え 155

Slide 156

Slide 156 text

また別のExcel（2000項目）が出てきた 156

Slide 157

Slide 157 text

オフショアを検証中オフショア部隊によるデータ基盤EOL対応の仕組み化（試行錯誤中）・データ活用を促進して、現場業務に注目すると、この手の話は出てくる（はず）　　役職者の知らないうちに担当者のローカル環境に実務の根幹を支えるデータが溜まっていたりする・デジタルトランスフォーメーションの痛み 157

Slide 158

Slide 158 text

愚直に向き合うことでデータの信頼性を高める 158

Slide 159

Slide 159 text

Slide 160

Slide 160 text

基盤③　使われるための保守・運用 160

Slide 161

Slide 161 text

信頼性と利便性のバランスをいかにとるか？ 161 共通化による信頼性個別化による利便性

Slide 162

Slide 162 text

部署ごとに最適なViewは異なる Ops（担当業務やスキルセット）が異なるので Data（見たいデータや使いたいツール）も異なる 162

Slide 163

Slide 163 text

ツール選定はABテストで決める日進月歩で多様なソリューションが台頭＆進化している・リサーチや運用サポートに工数を割けない・1度はダメだったツールがあとで使えるようになることもある　（例：Google Data Studioは月に1〜3回の頻度でアップデート）希望者が使いたいツール（ A）を試す・セキュリティ観点などで問題ないこと・現行ツール（B）よりも生産性が向上することこれらを社内にフィードバックすることで他チームやメンバーが自発的に利用する（自然と生き残る）中途半端にガバナンスを効かせるのではなく、市場原理を利用する → 変化に対応する 163

Slide 164

Slide 164 text

スタートアップと同じように小さくテストしながら、段階的に要求・設計を磨き込む（ひたすら螺旋のように繰り返す） View: ユースケースも変わる（例）データの抽出・集計 164

Slide 165

Slide 165 text

Model: 元データの仕様も変わる 165 システムが日々変わる・新機能の追加・不具合の修正データ仕様も日々変わるデータ活用データを生成集計方法に影響 ※非エンジニアにとっては同じ挙動のように見えても処理のタイミングやレコード反映の順序が微妙に変わっていたり

Slide 166

Slide 166 text

ModelとViewの境界線 3層構造でのデータ管理参考『10年戦えるデータ分析入門 - SQLを武器にデータ活用時代を生き抜く』 166

Slide 167

Slide 167 text

3層構造における2つの流れ 167

Slide 168

Slide 168 text

中間層（データウェアハウス）・1度定義して終わりではない・分離と結合を継続的に繰り返すことになる = データモデルは変わり続ける・ソースコードをリファクタリングし続けるのと同じ 168

Slide 169

Slide 169 text

クエリ量に基づくデータマネジメント ※まだ綺麗な仕組みとしては回せておりません。異常値に対する解釈の枠組みとして使っています。 169 データレイクデータウェアハウスデータマート量が多いと問題ワイルドクエリや無駄バッチ（要チューニング）量が少ないと問題データ基盤が利用されていないログ追加/分析が実施されていないプロダクトが成長していない継続的に中間テーブルを分離・結合できていない＝データモデリング観点で技術的負債が蓄積しているデータ基盤が利用されていない施策/分析が実施されていない体制・チームが拡大していない

Slide 170

Slide 170 text

利用者の寄る辺: データ辞書最適なツールにはまだ巡り会えていませんが …… 170 ・既にあるならそれを渡す・まだなければ一緒に作る・変化に追従できていなければ更新する

Slide 171

Slide 171 text

管理者の寄る辺: サービスレベルサービスレベルにもとづいて全ての意思決定がなされる 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

Slide 172

Slide 172 text

サービスレベルデータの用途・利用者ごとに期待されているサービスレベルを可視化・信頼性は「実際にシステムを使う人・目的・時間」を前提にする・なのでサービスレベルはユースケース駆動で設計することになる・誰も使わない機能や時間帯でシステム稼働率が100%であっても仕方ない ※曖昧なものは曖昧であるということが可視化された。これが大事。決めることが目的ではなく、共通認識の醸成とクオリティコントロールの寄る辺を作ることが目的。 172 例用途約束相手連絡先・周知先利用データ約束事項（SLA）違反時の影響範囲 1 日次レポートディレクター Slack #monitoring BigQueryの売上テーブル毎営業日の午前x時までに欠損なく前日の売上がレポートされること売上状況に応じた施策が打てなくなる（機会損失） 2 … … … … … … 3 … … … … … … … … … … … … …

Slide 173

Slide 173 text

オペレーションレベルサービスレベルに対する脅威（＝インシデント）発生時のオペレーション 173 対応スピード補償・代替手段ワークアラウンド（回避策）レポーティング＆記録

Slide 174

Slide 174 text

SLA & OLA を改善する① 毎スプリント終了時のふりかえりで、実態（AsIs）と期待値（ToBe）を比較する 174

Slide 175

Slide 175 text

SLA & OLA を改善する② 改善アクション・目標を満たせるように改善する：基盤システムの改修案件を起票・目標自体を修正する：過剰なら目標を下方修正、使用停止 BIツールはクリーニング、観点漏れは追加 175

Slide 176

Slide 176 text

Slide 177

Slide 177 text

基盤のまとめ 177

Slide 178

Slide 178 text

安易な “小さく試す” では解決できないのがシステムの難しいところです「使われるデータ基盤」のための紆余曲折をご紹介します 178 （再掲）

Slide 179

Slide 179 text

データ活用を取り巻くテクノロジーこれらのテクノロジー（Data）なくては業務（Ops）は進化しない一方で、これらのテクノロジーを導入するだけでは解決しない問題がある BigQueryを使うために誰よりも Excelを開くという矛盾これらのテクノロジー（Data）を利用者（Ops）とどう繋ぎ合わせるか 179 データ収集 IoT、オープンデータ、APIエコノミー、スマートデバイスデータ蓄積 / 加工クラウドDWH、分散処理、パイプラインデータ判断統計解析、機械学習、 MLaaS、MLOps

Slide 180

Slide 180 text

DataとOpsを繋げる 180 http://simpleicon.com/gear-7.html Data（データ）と Ops（利用者）を結ぶデータ基盤・データを正しく使えるように信頼性を保つ・利用者が小さく試せるように利便性を保つあらゆる開発・運用手法を総動員して「使われるシステム」を提供する

Slide 181

Slide 181 text

事業の成長を支える（再掲）・現場の1人1人が主役となり、データを活用してプロダクトや業務を磨き込む・この積み重ねによって事業が成長し、顧客に価値を届けることになる 181

Slide 182

Slide 182 text

Slide 183

Slide 183 text

Slide 184

Slide 184 text

184 事業グロースデータ活用案件信頼できるシステム効率的なプロセス安定したチームデータ活用文化

Slide 185

Slide 185 text

サイエンティストやMLエンジニアが1人いるだけで全てが上手くいくわけではありませんチーム運営自体について科学し、エンジニアリングしてきた内容をお伝えします 185

Slide 186

Slide 186 text

チーム①　運営の安定化 186

Slide 187

Slide 187 text

データチームをいかに運営するかデータ活用を取り巻く「案件」「プロセス」「システム」は不確実性が高い可視化を促すためにアジャイルプラクティスを適用した我々が慣れ親しんでいるチーム開発の手法がそのまま当てはまる 187 https://www.shoeisha.co.jp/book/detail/9784798129716

Slide 188

Slide 188 text

セレモニー 188

Slide 189

Slide 189 text

アイテム 189

Slide 190

Slide 190 text

ドキュメント（業務手順）・チーム立ち上げに合わせて、作業手順のドキュメントから見直す・手順が明文化されていなければ文書化する　※文書化できる人材を優先して引き入れる 190 　トヨタ自工に転出してから、　私がまず標準作業表をつくれと　呼びかけたことはいうまでもない。　生産現場の基本ともいうべき標準作業表づくりから、　トヨタ生産方式づくりへの三五年にわたる道程を　歩ませるもとをなしているように思う。 http://www.diamond.co.jp/book/9784478460016.html

Slide 191

Slide 191 text

Document as Code - ドキュメントをコードのように扱う 191 データチームだけでなくプロダクトや体制全体で「このドキュメントはどこに配置すべきか」「誰がいつどのように見るか」検討してリファクタリングを繰り返すことで、全体最適化や業務設計の観点を養う

Slide 192

Slide 192 text

Slide 193

Slide 193 text

チーム②　採用・育成・アウトソース 193

Slide 194

Slide 194 text

採用要件スキル定義にもとづいて設計した　後述 SRE人材を優先的に採用した Data Generation Process（データ生成過程）を抑えるためあるいは Data Collection Process（データ収集過程）　・不足しているログの追加　・DBからデータ基盤へのデータの疎通　・データ仕様の調査最初はプロダクト本体を開発するチームと連携してシステム構成や作業手順をキャッチアップする。徐々にデータチーム単体でデータを追加できるようにする。 ※DB影響のあるプルリクはプロダクト担当レビュー必須といった品質担保のための約束事は設けている 194

Slide 195

Slide 195 text

立ち上げメニュープロダクトのドッグフーディング 1. データ構成（ER）をリバースエンジニアリング　　　自分で1から考えることで、プロダクトやデータの仕様に素早くキャッチアップする（仮説思考） 2. 改善提案をSlackの起案チャンネルに投稿する　　　プロダクト改善の姿勢を身につけて、現場視点のデータ活用案件を担えるようにする 195 例：高速データ把握メソッド

Slide 196

Slide 196 text

OJTの運用設計ビジネス基礎スキルがボトルネックになちがち → OJTを整備　・ステークホルダーから要求を聞き出すためのコミュニケーション　・未知の領域について業務知識を短期間でキャッチアップできる学び方 196

Slide 197

Slide 197 text

課題図書によるスキル定義活躍しているメンバーへのヒアリングでソフトスキル + ハードスキルを定義 → 育成メニューに反映 197

Slide 198

Slide 198 text

新人研修: データ分析ハッカソン実践型の学習パッケージを開発・展開 https://recruit-tech.co.jp/blog/2018/07/23/rtech_bootcamp_2018/ 198

Slide 199

Slide 199 text

インターン・案件を通して学生に学習機会を提供・小さくスコープを区切った案件のうち　本人のWillと合致したものをお願いする・重要度は高いが、緊急度は低い案件　　・技術検証やデータ分析による仮説出し　　・攻めあぐねている課題の突破口になってもらう 199 https://blog.monora.me/2018/03/did-an-internship-at-recruit-technologies/

Slide 200

Slide 200 text

アルバイト: 募集要項やオンボーディング案件を担ってもらうために・どういうスキルの人が・どうキャッチアップして・どのシステムのどのデータで・どのような手順で作業して・どうコミュニケーションするかこれらを設計するところから 200

Slide 201

Slide 201 text

アルバイト: 業務手順書 201

Slide 202

Slide 202 text

アルバイト: 進捗管理 202

Slide 203

Slide 203 text

委託先ごとの向き・不向きを模索 203

Slide 204

Slide 204 text

案件フェーズに適した契約形態を模索 ※発表者の置かれたコンテキストに強く依存しているので参考程度でお願いします ※分業を推し進めると、ノウハウ共有や横断連携、業務分解や手順書作成がボトルネックになりがち 204

Slide 205

Slide 205 text

Slide 206

Slide 206 text

チーム③　体制拡大による痛み 206

Slide 207

Slide 207 text

データチームの悪循環 207

Slide 208

Slide 208 text

悪循環を打ち破る他パートの内容と重複するので詳細は省略 208

Slide 209

Slide 209 text

（理想は）分析担当なら出来てしかるべし 209

Slide 210

Slide 210 text

現場感をチームに装着する間接部門の宿命かつチーム拡大の宿命　メンバー提案「とりあえずダッシュボード出しましょう」 → 「お前もか」 → 繰り返される過ち言葉だけではパラダイムは伝わらない　現場業務（Ops）のためのデータ活用（Data）を言葉で伝えても　　・現場業務（Ops）を担当したことがないからイメージできない　　・何か特別なすごいデータ分析（ Data）への幻想をぬぐいきれない 210

Slide 211

Slide 211 text

チーム目標: 100案件切り・地味な集計依頼の対応で良いのでとにかく量をこなす・量をこなす中で、各チームとの信頼関係を築き、事情を知ることで「現場の課題」（Ops）を咀嚼する 211 Done Done Done

Slide 212

Slide 212 text

現場ヒアリング駆動・地味な業務の改善で良いのでとにかくニーズを聞き出す・対面で話すことで何か特別なすごいデータ分析を誰も求めていないことを知る 212 ？？？

Slide 213

Slide 213 text

社内短期留学・プロダクト開発チームに送り込む・現場の業務（Ops）を担当することで強制的に DataOps の視点を身につけてもらう 213 Go Go Go

Slide 214

Slide 214 text

Slide 215

Slide 215 text

チームのまとめ 215

Slide 216

Slide 216 text

サイエンティストやMLエンジニアが1人いるだけで全てが上手くいくわけではありませんチーム運営自体について科学し、エンジニアリングしてきた内容をお伝えします 216 （再掲）

Slide 217

Slide 217 text

DataとOpsを繋げる 217 http://simpleicon.com/gear-7.html Data（データ）と Ops（現場）の間に立つデータチーム・チーム開発＆運用のスキーム・採用、育成、アウトソース・体制の拡大による痛み安定した支援部隊として Data（データ）と Ops（現場）にコミットする

Slide 218

Slide 218 text

事業の成長を支える（再掲）・現場の1人1人が主役となり、データを活用してプロダクトや業務を磨き込む・この積み重ねによって事業が成長し、顧客に価値を届けることになる 218

Slide 219

Slide 219 text

Slide 220

Slide 220 text

Slide 221

Slide 221 text

221 事業グロースデータ活用案件信頼できるシステム効率的なプロセス安定したチームデータ活用文化

Slide 222

Slide 222 text

データチームだけではスケールしません現場の担当者1人1人が活躍できるよう「データの民主化」の取り組みをお伝えします 222

Slide 223

Slide 223 text

文化①　Measureから始める 223

Slide 224

Slide 224 text

エンジニアはMeasureから始めてみる 224

Slide 225

Slide 225 text

実施した施策の結果を分析 225 http://01.gatag.net/0010543-free-illustraition/

Slide 226

Slide 226 text

こんな感じでやりました 226

Slide 227

Slide 227 text

【Keep】ビジネス視点で開発を見る自分の成果を自分で言えるようになった（例：1ヶ月掛けた案件で売上xx円/年） 227

Slide 228

Slide 228 text

【Problem】チームにまだまだ改善余地　　　　　　メンバーが自分の理解不足に驚く　　　　　　　　　● 製品仕様 - このケースだとデータの中身はどうなる？　　　　　　　　　● フロント寄りメンバーが複雑な SQLに手間取る　　　　　　　　　● そもそもビジネスKPIを把握しているか　　　　　　　　　● きちんと分析するために本当は必要だったログ要件の漏れ担当エンジニアのビジネス・データ理解不足は、システム設計・運用のどこかに反映されている 228

Slide 229

Slide 229 text

【Try】エンジニアによる起案言われたものを作るだけ（Build重視）思考からの脱却 229

Slide 230

Slide 230 text

グロースハックチームの立ち上げエンジニアが起案して仮説検証を回すチーム必ずしもデータを見るだけではない → プロデューサーから 1つ1つ教わって真似するところから始めた例：最初の成功体験は「朝会の後に 1日1回15分、競合のアプリを使って気づいたことを挙げる」 230

Slide 231

Slide 231 text

Slide 232

Slide 232 text

文化②　組織に浸透させる 232

Slide 233

Slide 233 text

文化が浸透するまでの流れ 1. 方向性を意識する（メッセージング） 2. 体験してみる（トライアル） 3. 仕組み化する（プロセス装着） 4. 成功経験を共有する 233

Slide 234

Slide 234 text

メッセージングあの手この手で「データ分析やろう」の空気を醸成 ● データ分析ハッカソンの開催 ● 朝活サークルで自由研究（こぞってビットコインの値上がり要因を統計解析） ● JupyterHubを拡張したPython学習サイトや社内限データ向けのnbviewerを提供 234

Slide 235

Slide 235 text

体験: モブ（プログラミング）データ分析 1つのモニターを囲んで全員で作業する　　　　　● 周囲が調べたりアドバイスしながら進める　　　　　　 → ハマらない / 挫折を防ぐ、Tipsやコツを共有しあう　　　　　 ● 皆がやるなら自分もやるか！の後押し　　　　　　 → 「やってみたら思った以上に良かった」の体験 235

Slide 236

Slide 236 text

プロセス装着: 開発工程に組み込むデータ仕様に詳しい（少なくとも調査するスキルはもっている）エンジニアが担当領域を広げることで前後工程のリードタイムを短縮 236

Slide 237

Slide 237 text

実績PR: アジリティの向上エンジニア＝その場でデータ仕様を調べることができるデータサイエンス部門が仕様ヒアリングを重ねて 1週間かけていた分析が1時間で完了（フロー効率化） 237

Slide 238

Slide 238 text

Slide 239

Slide 239 text

文化③　非エンジニアの壁を壊す 239

Slide 240

Slide 240 text

利用手順やサンプルSQLのサポート 1. 定型業務向けSQLを渡して「ここの数字を変えるだけですよ」と案内 2. ディレクターがSQLを自主勉強して「ここについて教えて欲しい」と声を掛けてくれるように 3. 事務スタッフが当たり前のように BigQueryを叩く世界 240

Slide 241

Slide 241 text

エンジニア / 非エンジニアの枠を超えるディレクターがエンジニアに頼らずにレコメンドロジックを磨き込む 1. SQLを叩いてデータから仮説を立てる 2. レコメンドのパラメータを変更する（設定ファイルから反映する仕組み） 3. ABテストの結果をSQLで分析してレポートする 241

Slide 242

Slide 242 text

チームごとの民主化状況各チームがデータ活用できているかモニタリング → ブロッカーの検知・分析 → 改善アクション 242

Slide 243

Slide 243 text

この文化を広げるためにまずはやってみる！日々ひたすら改善！ 243

Slide 244

Slide 244 text

Slide 245

Slide 245 text

文化のまとめ 245

Slide 246

Slide 246 text

データチームだけではスケールしません現場の担当者1人1人が活躍できるよう「データの民主化」の取り組みをお伝えします 246 （再掲）

Slide 247

Slide 247 text

DataとOpsを繋げる 247 http://simpleicon.com/gear-7.html データと作業（業務）を繋げるテクノロジーとビジネス現場を繋げるデータを活用することで自身が抱える業務課題を解決する

Slide 248

Slide 248 text

事業の成長を支える（再掲）・現場の1人1人が主役となり、データを活用してプロダクトや業務を磨き込む・この積み重ねによって事業が成長し、顧客に価値を届けることになる 248

Slide 249

Slide 249 text

Slide 250

Slide 250 text

Slide 251

Slide 251 text

251 事業グロースデータ活用案件信頼できるシステム効率的なプロセス安定したチームデータ活用文化

Slide 252

Slide 252 text

色々な人たちが試行錯誤してきたのと同じ（細部や対象や文脈は違うが）要求整理、要件定義、業務分析、デジタルトランスフォーメーション、xOps、ジョブ理論、バリューストリーム、価値フロー、サプライチェーン、トヨタウェイ、リーン、制約理論、アジャイル、ITIL、SRE、DevOps、顧客開発、デザイン思考、HCD、CRM、マーケティングオートメーション、機械学習工学 252

Slide 253

Slide 253 text

銀の弾丸はないまずはやってみる！日々ひたすら改善！ 253

Slide 254

Slide 254 text

アンチパターンや泥臭い話も伝えてきましたがぜひ行動を躊躇わないでほしいです 1人1人が行動した先に個人としても、事業としても、社会としてもグロースがあるのだと思います 254

Slide 255

Slide 255 text

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

Slide 256

Slide 256 text

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

Slide 257

Slide 257 text

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

Slide 258

Slide 258 text

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

Slide 259

Slide 259 text

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

Slide 260

Slide 260 text

DataOps は1人にしてならず ⑥ Special Thanks for 2 + α Inspired by Kazushige Shida　Itsuki Kuroda　その他書ききれなかった方々含めて全ての関係者の方々 ※資料・内容に誤りや不適切な表現があれば発表者のミスです。お気付きの方はお手数をお掛けしますが @yuzutas0 にご連絡いただけると幸いです。 260

Slide 261

Slide 261 text

アンチパターンや泥臭い話も伝えてきましたがぜひ行動を躊躇わないでほしいです 1人1人が行動した先に個人としても、事業としても、社会としてもグロースがあるのだと思います 261 （再掲）

Slide 262

Slide 262 text

銀の弾丸はない（再掲）まずはやってみる！日々ひたすら改善！ 262

Slide 263

Slide 263 text

本日のゴール（再掲）いますぐに行動できるヒントを持ち帰っていただくこと 263

Slide 264

Slide 264 text

1: 現場の業務（Ops）に目を向ける Ops を改善するから、価値が生まれる「誰のどんな課題を解決したいのか？」すでに動いている人はぜひこの観点で見返して改善のきっかけにしてほしいですまだ動いていない人はこれから動くために担当している業務について考えてほしいです 264

Slide 265

Slide 265 text

2: テクノロジーや手法（Data）を楽しむ Data を活用するから、可能性が広がる「この技術でどんなことができるだろう？」私自身もCourseraでML講座の受講から始めましたこうした1人1人、1つ1つの小さな努力の積み重ねですだからこそ、ぜひ興味のあることに挑戦してみてほしいですせっかくなら一緒に楽しんでいきたいです 265

Slide 266

Slide 266 text

こういったテーマについて午後のセッションで有識者の方々が色々な話をしてくださるとのことなのでデブサミを楽しんでいきましょう 266

Slide 267

Slide 267 text

ご清聴ありがとうございました https://www.pexels.com/photo/abstract-art-blur-bright-373543/

Slide 268

Slide 268 text

結論 AI じゃなくて愛（現場への） 268 ダダ滑りだったのでAppendixに追放