Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

2018/07/27 Developers Summit 2018 Summerでの、横山の講演資料になります。
https://speakerdeck.com/yuzutas0/20180727

Recruit Technologies

July 27, 2018
Tweet

More Decks by Recruit Technologies

Other Decks in Technology

Transcript

  1. Sho Yokoyama @yuzutas0       リクルートテクノロジーズ    ITエンジニアリング本部 プロダクトエンジニアリング部    ベンチャーキャピタルから投資を受けての起業・会社経営、    リクルートグループ会社における複数の新規事業の立ち上げを経て、現職。

       主に急成長プロダクトを対象に、システムアーキテクチャの再構築や    エンジニアチームの立ち上げ・立て直しに従事。    最近は「現場で使われるデータ基盤」を軸に、    組織全体におけるデータ活用を推進しています。 6
  2. 象徴的な言葉が “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/
  3. あえて言うなら DevOps の データ活用版 DevOps: Dev(システム開発者)と Ops(システム運用者)の協働に端を発した全体最適のパラダイム と解釈して今回は話を進めます 参考「経営のアジリティを支える DevOpsと組織」(Developers

    Summit 2015 Summer) https://www.slideshare.net/recruitcojp/devops-51085988 DataOps: Data(データ)とOps(業務)を結びつけることによって価値創出を最大化するパラダイム と解釈して今回は話を進めます 12
  4. 本日お伝え すること / しないこと 知識 個々のテクノロジーや開発手法の詳細 DataOps is not tied

    to a particular technology, architecture, tool, language or framework. by https://en.wikipedia.org/wiki/DataOps 事例 案件・システム・プロセス・文化・組織を エンジニアリングしてきた現場のリアル(要するに苦労話) 14
  5. DataとOpsを繋げる話です 15 http://simpleicon.com/gear-7.html データ と 作業(業務) を繋げる話です テクノロジー と ビジネス現場

    を繋げる話です データを活用することで 誰のどんな課題を解決するのか と問い直した話です
  6. とはいえ、今も試行錯誤の日々です 16  まだまだ新参者です。  ・発表者自身(@yuzutas0)がデータ活用の推進を始めて 1.5年 弱  ・正式な部隊を立ち上げてから 0.5年 + α

     ・前を進んでいる方 には、振り返りや見直しの機会 を  ・これからの方 や 始めたばかりの方 には、0.5歩先の知見 を  提供できればと思っています
  7. 知見の横展開 婚活事業におけるデータ活用    婚活データチーム(通称 D4C) 知見を他事業に展開 横断研究会(ゆるキバン△ DataOpsプロジェクト) 30 https://recruit-holdings.co.jp/ir/library/upload/annual_2016_04.pdf 世界でも有数のボトムアップ型のデータ組織(自称)

    ・トップダウンで体制が作られたのではなく、有志が現場の事例を積み重ねて仕組みを作っている ・本日は社内横断研究会でレポートされた知見・事例の一部をお伝えします
  8. これだけでよかった ・シンプルなグラフと数値をいつも見ているチャットに流すだけでよかった ・既存オペレーションを組み合わせた「無理のない」「自然にデータを見る」体験 デザイン ・「いつ / どこで / 誰が /

    なぜ / どういう手順で / 何をするのか」(5W1H)まで解像度を上げる 57 毎朝の出社 (既にやっていたこと) 出社後にSlackを見る (既にやっていたこと) 意思決定する (既にやっていたこと) 1. オフィスに出社する 2. PCを開く 3. Slackが自動で起動 → 1. 未読チャンネルを開く 2. 画面をスクロールする  (= 読む) ここで 日次KPIレポート → (例) ・新機能のリリース翌日に数字を見て  施策が当たったか、予期せぬ離脱を  招いていないかを確認する  (次の施策のインプットにする) ・マーケッターが登録数の推移を見て  その日の広告予算を調整する
  9. 業務(Ops)に注目する 58 「派手なダッシュボードであること」よりも 「業務にどう影響を与えるのか」 を考える いつ どこで 誰が 何のために どのデータを

    どのように 見たいのか? (完全な0→1でもない限り) すでに何らかの形で業務やシステムは存在 していて、そこから価値が生み出されている データを活用するというのは、その価値の流れを改善 (あるいは改革?) するということ
  10. ⇒ 機械学習エンジニア・セキュリティエンジニアが集結 64 スタッフが巡回監視・パトロール システムによる早期検知 ? https://www.irasutoya.com/2018/07/blog-post_403.html 機械学習のスクリプトは 早々に 完成した!

    が、実運用に乗るまで 半年以上 掛かった…… (ちなみに精度は当初想定を超えて圧倒的成果だった!これは良かった!) 現実は非情である
  11. 業務(Ops)に注目する 66 テクノロジー(Data)単体ではなく、業務全体(Ops)への視点 システム連携設計 や 業務フロー分析 ステークホルダーとの認識合わせ や 運用装着 要するに:機械学習の案件にもプロジェクトマネジメントが必要

    予測精度が出るか分からないなら、その 不確実性を前提としたプロジェクトを計画 すべきだった                    ・まずはデモ環境で試してリストの受け渡しは手動でやるとか                    ・明らかに効果が出るルールベースの機能に絞って先に運用に乗せるとか
  12. まずは個々の担当を磨き込む いきなり最適化は苦戦 ↔ オペレーション&データの可視化 ⇒ 効率化による利益創出が可能 74 Before After マーケティング担当

    → 手動で実施している業務について オペレーション整理・改善 データエンジニア → 広告関連データをデータ基盤に統合したり、 マーケティング業務を少しずつ自動化 機械学習エンジニア → 特定の業務や広告媒体に絞って自動最適化 連携して 最適化システムを 作ろうぜ! NG! OK!
  13. 単一データの世界観から 80 アクセス 解析ツール サーバサイド DB ユーザーの 流入ログ ユーザーの 購買記録

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

    マーケッターが 参照 アクションベース (CPA)を計測 広告媒体A を重視 データ基盤 ユーザーの 流入ログ 売上ベース (ROAS)を計測 広告媒体B を重視 https://boxil.jp/mag/a2829/
  15. データ(Data)と業務(Ops)は両輪 83 Data を機会として Ops を可視化する 広告配信をいきなり全て自動化しようとしても上手くいかない データを活用するためには 1つ1つの業務を紐解くことになる Ops

    を通して Data を引き出す 広告効果をより正確にモニタリングするにはシステムが進化しないといけない 1つ1つの業務を改善しようとしたらデータが必要になる
  16. DataとOpsを繋げる 89 http://simpleicon.com/gear-7.html Data(データ) と Ops(業務)を結びつけることで 価値を創造することができる データを使うこと によって 誰が抱えるどんな不

    を解決したいのか ・情報社会においては 何をするにも多くの「意思決定」を必要とする ・意思決定 を支える / 自動化するのが「データ分析」や「機械学習」
  17. 事業のグロースを支える DataOpsの現場 2018-07-27 Developers Summit 2018 Summer presented by @yuzutas0

    https://www.pexels.com/photo/abstract-art-blur-bright-373543/ これこそが(タイトル再掲)
  18. MVP - モックアップ 108  もしこういう値だったら データを出しても   どういう意思決定になるのか? →  アクションが変わらなければ   どのくらいのインパクトがあるのか?

    →  工数に効果が見合わなければ  を最初に検証する やる意味がない ホワイトボードやSpreadsheet で    ・推定される概算値を仮置きして    ・出力シートをスケッチして 集計 / 抽出後のユースケースをロールプレイ
  19. 生き残った案件だけを磨き込む 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
  20. 小さく検証しながら進める 118 データ分析による仮説構築(Data) パラメータ追加で予測精度は向上しそうか by MLエンジニア モックアップによるUI構築(Ops) スタッフに見てもらって運用できそうか by APエンジニア

    ↓ ↓ 設計・コーディング・システムテスト ↓ デモ環境で並行稼働させる ダークローンチ 効果検証:システム観点に加えて 予測精度(Data) と 業務運用(Ops) ↓ 本格移管・リリース
  21. 事業のグロースを支える DataOpsの現場 2018-07-27 Developers Summit 2018 Summer presented by @yuzutas0

    https://www.pexels.com/photo/abstract-art-blur-bright-373543/ これこそが(タイトル再掲)
  22. ツール選定はABテストで決める 日進月歩で多様なソリューションが台頭&進化している ・リサーチや運用サポートに工数を割けない ・1度はダメだったツールがあとで使えるようになることもある  (例:Google Data Studioは月に1〜3回の頻度でアップデート) 希望者が使いたいツール( A)を試す ・セキュリティ観点などで問題ないこと

    ・現行ツール(B)よりも生産性が向上すること これらを社内にフィードバックすることで 他チームやメンバーが自発的に利用する(自然と生き残る) 中途半端にガバナンスを効かせるのではなく、市場原理を利用する → 変化に対応する 163
  23. Model: 元データの仕様も変わる 165 システムが日々変わる ・新機能の追加 ・不具合の修正 データ仕様も日々変わる データ活用 データを 生成

    集計方法に 影響 ※非エンジニアにとっては同じ挙動のように見えても 処理のタイミングやレコード反映の順序が微妙に変わっていたり
  24. クエリ量に基づくデータマネジメント ※まだ綺麗な仕組みとしては回せておりません。異常値に対する解釈の枠組みとして使っています。 169 データレイク データウェアハウス データマート 量が 多いと 問題 ワイルドクエリ

    や 無駄バッチ (要チューニング) 量が 少ないと 問題 データ基盤が 利用されていない ログ追加/分析が 実施されていない プロダクトが 成長していない 継続的に中間テーブルを 分離・結合できていない =データモデリング観点で 技術的負債が蓄積している データ基盤が 利用されていない 施策/分析が 実施されていない 体制・チームが 拡大していない
  25. サービスレベル データの用途・利用者ごとに期待されているサービスレベルを可視化 ・信頼性は「実際にシステムを使う人・目的・時間」を前提にする ・なのでサービスレベルはユースケース駆動で設計することになる ・誰も使わない機能や時間帯でシステム稼働率が100%であっても仕方ない ※曖昧なものは曖昧であるということが可視化された。これが大事。 決めることが目的ではなく、 共通認識の醸成と クオリティコントロールの 寄る辺を作ることが目的。

    172 例 用途 約束相手 連絡先・周知先 利用データ 約束事項(SLA) 違反時の影響範囲 1 日次レポート ディレクター Slack #monitoring BigQueryの 売上テーブル 毎営業日の午前x時までに 欠損なく前日の売上が レポートされること 売上状況に応じた 施策が打てなくなる (機会損失) 2 … … … … … … 3 … … … … … … … … … … … … …
  26. 事業のグロースを支える DataOpsの現場 2018-07-27 Developers Summit 2018 Summer presented by @yuzutas0

    https://www.pexels.com/photo/abstract-art-blur-bright-373543/ これこそが(タイトル再掲)
  27. 採用要件 スキル定義にもとづいて設計した  後述 SRE人材を優先的に採用した Data Generation Process(データ生成過程)を抑えるため あるいは Data Collection

    Process(データ収集過程)  ・不足しているログの追加  ・DBからデータ基盤へのデータの疎通  ・データ仕様の調査 最初はプロダクト本体を開発するチームと連携して システム構成や作業手順をキャッチアップする。 徐々にデータチーム単体でデータを追加できるようにする。 ※DB影響のあるプルリクはプロダクト担当レビュー必須 といった品質担保のための約束事は設けている 194
  28. 現場感をチームに装着する 間接部門の宿命 かつ チーム拡大の宿命  メンバー提案「とりあえずダッシュボード出しましょう」 → 「お前もか」 → 繰り返される過ち 言葉だけではパラダイムは伝わらない

     現場業務(Ops)のための データ活用(Data)を言葉で伝えても   ・現場業務(Ops)を担当したことがないからイメージできない   ・何か特別なすごいデータ分析( Data)への幻想をぬぐいきれない 210
  29. 事業のグロースを支える DataOpsの現場 2018-07-27 Developers Summit 2018 Summer presented by @yuzutas0

    https://www.pexels.com/photo/abstract-art-blur-bright-373543/ これこそが(タイトル再掲)
  30. 【Problem】チームにまだまだ改善余地       メンバーが自分の理解不足に驚く          • 製品仕様 - このケースだとデータの中身はどうなる?          • フロント寄りメンバーが複雑な SQLに手間取る          •

    そもそもビジネスKPIを把握しているか          • きちんと分析するために本当は必要だったログ要件の漏れ 担当エンジニアのビジネス・データ理解不足は、システム設計・運用のどこかに反映されている 228
  31. 事業のグロースを支える DataOpsの現場 2018-07-27 Developers Summit 2018 Summer presented by @yuzutas0

    https://www.pexels.com/photo/abstract-art-blur-bright-373543/ これこそが(タイトル再掲)
  32. 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
  33. 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
  34. 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
  35. 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
  36. 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
  37. DataOps は1人にしてならず ⑥ Special Thanks for 2 + α Inspired

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