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

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

事業のグロースを支える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(翌年のベストスピーカー賞に相当)をいただきました。誠にありがとうございます!

yuzutas0

July 27, 2018
Tweet

More Decks by yuzutas0

Other Decks in Technology

Transcript

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

    View full-size slide

  2. はじめに
    2

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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/

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  21. プロダクト・チーム
    21

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  26. データ基盤
    26

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  29. データチーム
    29

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  38. 問い合わせの傾向分析
    38

    View full-size slide

  39. 広告配信の最適化
    39

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  42. 障害発生時の影響調査
    42

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  46. 案件① KPIモニタリング
    46

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    https://www.irasutoya.com/2018/07/blog-post_403.html

    View full-size slide

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

    View full-size slide

  64. ⇒ 機械学習エンジニア・セキュリティエンジニアが集結
    64
    スタッフが巡回監視・パトロール システムによる早期検知

    https://www.irasutoya.com/2018/07/blog-post_403.html
    機械学習のスクリプトは
    早々に 完成した!
    が、実運用に乗るまで
    半年以上 掛かった……
    (ちなみに精度は当初想定を超えて圧倒的成果だった!これは良かった!)
    現実は非情である

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  68. 案件③ 集客広告配信
    68

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  85. 案件のまとめ
    85

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  118. 小さく検証しながら進める
    118
    データ分析による仮説構築(Data)
    パラメータ追加で予測精度は向上しそうか
    by MLエンジニア
    モックアップによるUI構築(Ops)
    スタッフに見てもらって運用できそうか
    by APエンジニア
    ↓ ↓
    設計・コーディング・システムテスト

    デモ環境で並行稼働させる ダークローンチ
    効果検証:システム観点に加えて 予測精度(Data) と 業務運用(Ops)

    本格移管・リリース

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  124. プロセスのまとめ
    124

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  138. 基盤① ViewとModelの分離
    138

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  151. 最終出力(30項目)を置き換え
    151

    View full-size slide

  152. 別のExcelシート(500項目)が出てきた
    152

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  155. 500項目を置き換え
    155

    View full-size slide

  156. また別のExcel(2000項目)が出てきた
    156

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  177. 基盤のまとめ
    177

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  186. チーム① 運営の安定化
    186

    View full-size slide

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

    View full-size slide

  188. セレモニー
    188

    View full-size slide

  189. アイテム
    189

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  202. アルバイト: 進捗管理
    202

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  207. データチームの悪循環
    207

    View full-size slide

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

    View full-size slide

  209. (理想は)分析担当なら出来てしかるべし
    209

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  215. チームのまとめ
    215

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  223. 文化① Measureから始める
    223

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  245. 文化のまとめ
    245

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  262. 銀の弾丸はない(再掲)
    まずはやってみる!
    日々ひたすら改善!
    262

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide