事業のグロースを支えるDataOpsの現場 #DataOps #DevSumi #デブサミ
•
4 likes•686 views
元スライド https://speakerdeck.com/yuzutas0/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をいただきました。誠にありがとうございます！
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 事業のグロースを支えるDataOpsの現場 #DataOps #DevSumi #デブサミ
Similar to 事業のグロースを支えるDataOpsの現場 #DataOps #DevSumi #デブサミ (20)
More from @yuzutas0 Yokoyama
More from @yuzutas0 Yokoyama (20)
Recently uploaded
Recently uploaded (14)
事業のグロースを支えるDataOpsの現場 #DataOps #DevSumi #デブサミ
- 1. 事業のグロースを支える DataOpsの現場 2018-07-27 Developers Summit 2018 Summer presented by @yuzutas0 https://www.pexels.com/photo/abstract-art-blur-bright-373543/
- 2. はじめに 2
- 4. スライド 260+ 枚 / 45min （知見をがっつり共有します） ・疲れると思うので、興味のある部分をメインで聞いてください ・飛ばしながら進めるので、細かいところは後で読んでください ・ちょっとだけ盛ってるところもあるけど気にしないでください 4
- 6. Sho Yokoyama @yuzutas0 リクルートテクノロジーズ ITエンジニアリング本部 プロダクトエンジニアリング部 ベンチャーキャピタルから投資を受けての起業・会社経営、 リクルートグループ会社における複数の新規事業の立ち上げを経て、現職。 主に急成長プロダクトを対象に、システムアーキテクチャの再構築や エンジニアチームの立ち上げ・立て直しに従事。 最近は「現場で使われるデータ基盤」を軸に、 組織全体におけるデータ活用を推進しています。 6
- 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
- 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を繋げる話です 15http://simpleicon.com/gear-7.html データ と 作業（業務） を繋げる話です テクノロジー と ビジネス現場 を繋げる話です データを活用することで 誰のどんな課題を解決するのか と問い直した話です
- 16. とはいえ、今も試行錯誤の日々です 16 まだまだ新参者です。 ・発表者自身（@yuzutas0）がデータ活用の推進を始めて 1.5年 弱 ・正式な部隊を立ち上げてから 0.5年 + α ・前を進んでいる方 には、振り返りや見直しの機会 を ・これからの方 や 始めたばかりの方 には、0.5歩先の知見 を 提供できればと思っています
- 21. プロダクト・チーム 21
- 23. 利用の流れ 23月額課金モデル ※恋結び女性ユーザーは本人確認料のみ STEP 1 STEP 2 STEP 3 気になったら「いいね！」 お互いにいいね！でマッチング メッセージでやりとり開始
- 26. データ基盤 26
- 29. データチーム 29
- 33. KPIモニタリング ビジネス指標（売上や Daily Active User）の推移 33 毎朝のSlack通知 Spreadsheet ダッシュボード
- 38. 問い合わせの傾向分析 38
- 39. 広告配信の最適化 39
- 40. ニュースレター 分析結果をメディアに情報提供することで市場活性化に貢献 40http://www.recruit-mp.co.jp/news/release/2017/0531_3216.html
- 42. 障害発生時の影響調査 42
- 45. 3つのデータ活用案件をご紹介します 案件を通して Data と Ops を 結びつけることの重要性をお伝えします 45
- 46. 案件① KPIモニタリング 46
- 50. 高まる期待 1. 毎日のKPIをすらすら言えるようになるかも 2. 異常値に気づいて迅速に動けるようになるかも 3. ビジネスコミットできる強いエンジニアチームになるかも 50
- 57. これだけでよかった ・シンプルなグラフと数値をいつも見ているチャットに流すだけでよかった ・既存オペレーションを組み合わせた「無理のない」「自然にデータを見る」体験 デザイン ・「いつ / どこで / 誰が / なぜ / どういう手順で / 何をするのか」（5W1H）まで解像度を上げる 57 毎朝の出社 （既にやっていたこと） 出社後にSlackを見る （既にやっていたこと） 意思決定する （既にやっていたこと） 1. オフィスに出社する 2. PCを開く 3. Slackが自動で起動 → 1. 未読チャンネルを開く 2. 画面をスクロールする （= 読む） ここで 日次KPIレポート → （例） ・新機能のリリース翌日に数字を見て 施策が当たったか、予期せぬ離脱を 招いていないかを確認する （次の施策のインプットにする） ・マーケッターが登録数の推移を見て その日の広告予算を調整する💻
- 58. 業務（Ops）に注目する 58 「派手なダッシュボードであること」よりも 「業務にどう影響を与えるのか」 を考える いつ どこで 誰が 何のために どのデータを どのように 見たいのか？ （完全な0→1でもない限り） すでに何らかの形で業務やシステムは存在 していて、そこから価値が生み出されている データを活用するというのは、その価値の流れを改善 （あるいは改革？） するということ
- 64. ⇒ 機械学習エンジニア・セキュリティエンジニアが集結 64 スタッフが巡回監視・パトロール システムによる早期検知 ？ https://www.irasutoya.com/2018/07/blog-post_403.html 機械学習のスクリプトは 早々に完成した！ が、実運用に乗るまで 半年以上掛かった…… （ちなみに精度は当初想定を超えて圧倒的成果だった！これは良かった！） 現実は非情である
- 66. 業務（Ops）に注目する 66 テクノロジー（Data）単体ではなく、業務全体（Ops）への視点 システム連携設計 や 業務フロー分析 ステークホルダーとの認識合わせ や 運用装着 要するに：機械学習の案件にもプロジェクトマネジメントが必要 予測精度が出るか分からないなら、その 不確実性を前提としたプロジェクトを計画 すべきだった ・まずはデモ環境で試してリストの受け渡しは手動でやるとか ・明らかに効果が出るルールベースの機能に絞って先に運用に乗せるとか
- 68. 案件③ 集客広告配信 68
- 73. まだまだプロダクトは発展途上のフェーズ ・少数のメンバーで集客における 勝ち筋やプロセスを模索 している段階 ・「意思決定」や「業務」 を機械に置き換えようとしても 「正解」となるパターン が見えていなかった ・不確定な部分について仮置きして進めようとして（主に発表者 @yuzutas0 が）見事にずっこけた 73
- 74. まずは個々の担当を磨き込む いきなり最適化は苦戦 ↔ オペレーション＆データの可視化 ⇒ 効率化による利益創出が可能 74 Before After マーケティング担当 → 手動で実施している業務について オペレーション整理・改善 データエンジニア → 広告関連データをデータ基盤に統合したり、 マーケティング業務を少しずつ自動化 機械学習エンジニア → 特定の業務や広告媒体に絞って自動最適化 連携して 最適化システムを 作ろうぜ！ NG! OK!
- 76. （可視化の過程で）利益創出 76 マーケティング担当「この データを出せるように したい。少し気掛かりなことがある。」 データエンジニア「やってみた！ けど、この結果って......。」 一部の広告媒体の効果 がそこまで高くないことが分かった マーケティング計画の大幅な方針変更を検討
- 77. それまでは獲得効率を目的変数にしていた 77 あああ Referral（紹介） Acquisition（獲得） Activation（利用） Retention（継続） Revenue（収益）
- 82. 売上を伸ばすモニタリング データを見る → 行動が変わる → 結果が変わる データを繋げて可視化するだけで ビジネス改善のインサイトを得られる（こともある） 自動判定とか以前に、データソースを繋げて見るだけで、価値創出につながった スペシャリストが大きな絵を描かなくても、ちょっとしたデータを出すだけで効果があったりする 82
- 83. データ（Data）と業務（Ops）は両輪 83 Data を機会として Ops を可視化する 広告配信をいきなり全て自動化しようとしても上手くいかない データを活用するためには 1つ1つの業務を紐解くことになる Ops を通して Data を引き出す 広告効果をより正確にモニタリングするにはシステムが進化しないといけない 1つ1つの業務を改善しようとしたらデータが必要になる
- 85. 案件のまとめ 85
- 86. 3つのデータ活用案件をご紹介します 案件を通して Data と Ops を 結びつけることの重要性をお伝えします 86 （再掲）
- 87. データ活用による価値創出 バリューストリーム において リターンを上げる or コストを下げる 87
- 88. データ活用による価値創出 バリューストリーム において リターンを上げる or コストを下げる ・例：RPAによるマーケティング業務やカスタマーサポート業務の一部自動化 ・レコメンド機能は ユーザーの探索業務（一般的には情報収集 →比較検討→意思決定→アクション）を支援する ソリューション 88
- 89. DataとOpsを繋げる 89http://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/ これこそが（タイトル再掲）
- 98. というか「答え」が存在しない Q. 最初に要件を全部洗い出せばOK？ A. NG！「やりたいこと」は変わる！ ● 他社ブログを見て「うちもやりたい！」 ● 新しいBIツールの提案に「これいい！」 ● 実際に画面を作ったら「なんか違う！」 98
- 100. 不確実性を前提としたプロセスが必要 「学びの最大化」に注目する 参考『リーンスタートアップ』 （例） ・リスクの大きい要素を先に検証する ・案件のバッチサイズを小さくする ・高速にイテレーションを回す リスクを抑え ながら 現場の業務（Ops）を読み解く 100 http://ec.nikkeibp.co.jp/item/books/P48970.html
- 101. 小さく試すことでリスクを抑えながら Data と Ops を読み解くことが重要です プロセスの具体例を2つご紹介します 101
- 103. プロセス① データ抽出・集計 103
- 106. データ抽出・集計の業務 106
- 108. MVP - モックアップ 108 もしこういう値だったら データを出しても どういう意思決定になるのか？ → アクションが変わらなければ どのくらいのインパクトがあるのか？ → 工数に効果が見合わなければ を最初に検証する やる意味がない ホワイトボードやSpreadsheet で ・推定される概算値を仮置きして ・出力シートをスケッチして 集計 / 抽出後のユースケースをロールプレイ
- 109. MVP - CSVファイル 凝ったグラフを描く前に、データ自体を速やかに受け渡す ・データさえあれば Excel や Spreadsheet で当面はどうにかできる ・Jupyter Notebook や BigQuery UI でCSVファイルを出力 109
- 110. MVP - Data Studio コマンド1つで即席のダッシュボード ・簡易作成したら後は好きに使ってもらう ・まだ自由度は高くないが固定指標のモニタリングなら問題なく使える 110
- 116. プロセス② 機械学習プロジェクト 116
- 118. 小さく検証しながら進める 118 データ分析による仮説構築（Data） パラメータ追加で予測精度は向上しそうか by MLエンジニア モックアップによるUI構築（Ops） スタッフに見てもらって運用できそうか by APエンジニア ↓ ↓ 設計・コーディング・システムテスト ↓ デモ環境で並行稼働させる ダークローンチ 効果検証：システム観点に加えて 予測精度（Data） と 業務運用（Ops） ↓ 本格移管・リリース
- 124. プロセスのまとめ 124
- 125. 125 （再掲） 小さく試すことでリスクを抑えながら Data と Ops を読み解くことが重要です プロセスの具体例を2つご紹介します
- 129. データ案件でもステージゲート 129
- 132. DataとOpsを繋げる 132http://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/ これこそが（タイトル再掲）
- 142. データ基盤の必要性 データソース（Data）と 利用者（Ops）をリボンのように結び付けるもの プロダクト成長や体制拡大によって リボンの両側が多様 になるとデータ基盤が必要になる 「データ基盤」を作ること自体は目的ではない 142
- 145. 基盤② データの信頼を担保する 145
- 146. システムがあるだけでは使われない ・既存の業務（Ops）は 既存のデータ（Data）を使っている ・最も信頼されていたのは Excel だった ツールとしては運用の限界を迎えていた ・これまで使っていたデータとズレると業務影響が出てしまう / 信用できない 146
- 151. 最終出力（30項目）を置き換え 151
- 153. その先は地獄だぞ ・まさに システム再構築 案件（仕様書なし）と同じ状況 ・いわば データ基盤のEOL 対応 ・小手先の工夫でどうにかできるレベルではない 153https://www.pexels.com/photo/water-outside-fire-hose-69934/
- 155. 500項目を置き換え 155
- 160. 基盤③ 使われるための保守・運用 160
- 163. ツール選定はABテストで決める 日進月歩で多様なソリューションが台頭＆進化している ・リサーチや運用サポートに工数を割けない ・1度はダメだったツールがあとで使えるようになることもある （例：Google Data Studioは月に1〜3回の頻度でアップデート） 希望者が使いたいツール（ A）を試す ・セキュリティ観点などで問題ないこと ・現行ツール（B）よりも生産性が向上すること これらを社内にフィードバックすることで 他チームやメンバーが自発的に利用する（自然と生き残る） 中途半端にガバナンスを効かせるのではなく、市場原理を利用する → 変化に対応する 163
- 167. 3層構造における2つの流れ 167
- 168. 中間層（データウェアハウス） ・1度定義して終わりではない ・分離と結合を継続的に繰り返す ことになる = データモデルは変わり続ける ・ソースコードをリファクタリングし続けるのと同じ 168
- 169. クエリ量に基づくデータマネジメント ※まだ綺麗な仕組みとしては回せておりません。異常値に対する解釈の枠組みとして使っています。 169 データレイク データウェアハウス データマート 量が 多いと 問題 ワイルドクエリ や 無駄バッチ （要チューニング） 量が 少ないと 問題 データ基盤が 利用されていない ログ追加/分析が 実施されていない プロダクトが 成長していない 継続的に中間テーブルを 分離・結合できていない ＝データモデリング観点で 技術的負債が蓄積している データ基盤が 利用されていない 施策/分析が 実施されていない 体制・チームが 拡大していない
- 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 … … … … … … … … … … … … …
- 174. SLA & OLA を改善する① 毎スプリント終了時のふりかえりで、実態（AsIs）と期待値（ToBe）を比較する 174
- 175. SLA & OLA を改善する② 改善アクション ・目標を満たせるように改善する ：基盤システムの改修案件を起票 ・目標自体を修正する ：過剰なら目標を下方修正、使用停止 BIツールはクリーニング、観点漏れは追加 175
- 177. 基盤のまとめ 177
- 179. データ活用を取り巻くテクノロジー これらのテクノロジー（Data）なくては業務（Ops）は進化しない 一方で、これらのテクノロジーを導入するだけでは解決しない問題 がある BigQueryを使うために誰よりも Excelを開くという矛盾 これらのテクノロジー（Data）を 利用者（Ops）とどう繋ぎ合わせるか 179 データ収集 IoT、オープンデータ、APIエコノミー、スマートデバイス データ蓄積 / 加工 クラウドDWH、分散処理、パイプライン データ判断 統計解析、機械学習、 MLaaS、MLOps
- 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/ これこそが（タイトル再掲）
- 186. チーム① 運営の安定化 186
- 187. データチームをいかに運営するか データ活用を取り巻く「案件」「プロセス」「システム」は不確実性が高い 可視化を促すために アジャイルプラクティス を適用した 我々が慣れ親しんでいる チーム開発の手法がそのまま当てはまる 187 https://www.shoeisha.co.jp/book/detail/9784798129716
- 188. セレモニー 188
- 189. アイテム 189
- 191. Document as Code - ドキュメントをコードのように扱う 191 データチームだけでなくプロダクトや体制全体で「このドキュメントはどこに配置すべきか」 「誰がいつどのように見るか」検討してリファクタリングを繰り返すことで、全体最適化や業務設計の観点を養う
- 194. 採用要件 スキル定義にもとづいて設計した 後述 SRE人材を優先的に採用した Data Generation Process（データ生成過程）を抑えるため あるいは Data Collection Process（データ収集過程） ・不足しているログの追加 ・DBからデータ基盤へのデータの疎通 ・データ仕様の調査 最初はプロダクト本体を開発するチームと連携して システム構成や作業手順をキャッチアップする。 徐々にデータチーム単体でデータを追加できるようにする。 ※DB影響のあるプルリクはプロダクト担当レビュー必須 といった品質担保のための約束事は設けている 194
- 197. 課題図書によるスキル定義 活躍しているメンバーへのヒアリングで ソフトスキル + ハードスキル を定義 → 育成メニューに反映 197
- 201. アルバイト: 業務手順書 201
- 202. アルバイト: 進捗管理 202
- 203. 委託先ごとの向き・不向きを模索 203
- 206. チーム③ 体制拡大による痛み 206
- 207. データチームの悪循環 207
- 210. 現場感をチームに装着する 間接部門の宿命 かつ チーム拡大の宿命 メンバー提案「とりあえずダッシュボード出しましょう」 → 「お前もか」 → 繰り返される過ち 言葉だけではパラダイムは伝わらない 現場業務（Ops）のための データ活用（Data）を言葉で伝えても ・現場業務（Ops）を担当したことがないからイメージできない ・何か特別なすごいデータ分析（ Data）への幻想をぬぐいきれない 210
- 211. チーム目標: 100案件切り ・地味な集計依頼の対応で良いので とにかく量 をこなす ・量をこなす中で、各チームとの信頼関係を築き、事情を知ることで 「現場の課題」（Ops）を咀嚼する 211 Done Done Done
- 212. 現場ヒアリング駆動 ・地味な業務の改善で良いので とにかくニーズ を聞き出す ・対面で話すことで 何か特別なすごいデータ分析 を誰も求めていないことを知る 212 ？ ？ ？
- 213. 社内短期留学 ・プロダクト開発チームに送り込む ・現場の 業務（Ops）を担当 することで強制的に DataOps の視点を身につけてもらう 213 Go Go Go
- 215. チームのまとめ 215
- 217. DataとOpsを繋げる 217http://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/ これこそが（タイトル再掲）
- 223. 文化① Measureから始める 223
- 226. こんな感じでやりました 226
- 228. 【Problem】チームにまだまだ改善余地 メンバーが自分の理解不足に驚く ● 製品仕様 - このケースだとデータの中身はどうなる？ ● フロント寄りメンバーが複雑な SQLに手間取る ● そもそもビジネスKPIを把握しているか ● きちんと分析するために本当は必要だったログ要件の漏れ 担当エンジニアのビジネス・データ理解不足は、システム設計・運用のどこかに反映されている 228
- 230. グロースハックチームの立ち上げ エンジニアが起案して仮説検証を回すチーム 必ずしもデータを見るだけではない → プロデューサーから 1つ1つ教わって真似するところから始めた 例：最初の成功体験は「朝会の後に 1日1回15分、競合のアプリを使って気づいたことを挙げる」 230
- 232. 文化② 組織に浸透させる 232
- 233. 文化が浸透するまでの流れ 1. 方向性を意識する（メッセージング） 2. 体験してみる（トライアル） 3. 仕組み化する（プロセス装着） 4. 成功経験を共有する 233
- 234. メッセージング あの手この手で「データ分析やろう」の空気を醸成 ● データ分析ハッカソンの開催 ● 朝活サークルで自由研究 （こぞってビットコインの値上がり要因を統計解析） ● JupyterHubを拡張したPython学習サイトや社内限データ向けのnbviewerを提供 234
- 235. 体験: モブ（プログラミング）データ分析 1つのモニターを囲んで全員で作業する ● 周囲が調べたりアドバイスしながら進める → ハマらない / 挫折を防ぐ、Tipsやコツを共有しあう ● 皆がやるなら自分もやるか！の後押し → 「やってみたら思った以上に良かった」の体験 235
- 237. 実績PR: アジリティの向上 エンジニア ＝ その場でデータ仕様を調べることができる データサイエンス部門が仕様ヒアリングを重ねて 1週間かけていた分析が1時間で完了（フロー効率化） 237
- 239. 文化③ 非エンジニアの壁を壊す 239
- 240. 利用手順やサンプルSQLのサポート 1. 定型業務向けSQLを渡して「ここの数字を変えるだけですよ」と案内 2. ディレクターがSQLを自主勉強して「ここについて教えて欲しい」と声を掛けてくれるように 3. 事務スタッフが当たり前のように BigQueryを叩く世界 240
- 241. エンジニア / 非エンジニアの枠を超える ディレクターがエンジニアに頼らずにレコメンドロジックを磨き込む 1. SQLを叩いてデータから仮説を立てる 2. レコメンドのパラメータを変更する（設定ファイルから反映する仕組み） 3. ABテストの結果をSQLで分析してレポートする 241
- 242. チームごとの民主化状況 各チームがデータ活用できているかモニタリング → ブロッカーの検知・分析 → 改善アクション 242
- 245. 文化のまとめ 245
- 247. DataとOpsを繋げる 247http://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/ これこそが（タイトル再掲）
- 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 遷宮プロジェクト(周辺)の皆様 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