Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

データプロダクト開発を成功に導くには

1,030 views

Published on

2019年2月5日開催『ソフトウエアジャパン2019 〜ビッグデータ、IoT、AI でプロフェッショナルを生き残れ〜』
https://www.ipsj.or.jp/event/sj/sj2019/

Published in: Engineering
  • Be the first to comment

データプロダクト開発を成功に導くには

  1. 1. データプロダクト開発を成功に導くには 堀澤健太  NB 本部 テクノロジープラットフォームユニット データエンジニアリング2グループ グループマネージャー 1
  2. 2. アジェンダ 1. 自己紹介 2. リクルートライフスタイルの紹介 3. データプロダクトとは 4. 不確実性に強い組織 5. データプロダクト開発を支える基盤 6. まとめ 01
  3. 3. 自己紹介
  4. 4. 堀澤健太 株式会社リクルートライフスタイル グループマネージャー 兼 エンジニア 戦略立案、組織設計、メンバー育成・評価、採用 データプロダクト開発 チーム外への技術コンサル、R&D @horiken4 自己紹介02
  5. 5. 自己紹介 Google Cloud Next in Tokyo ‘18 リクルートライフスタイルにおける 深層学習の活用とGCPでの実現方法 https://www.youtube.com/watch?v=X_yavAFAE4I Cloud On Air リクルートライフスタイルにおけるデジタルトランスフォーメー ションとクラウド活用 https://cloudplatform-jp.googleblog.com/2018/07/Cloud-OnAir-gcp-rec ruit-lifestyle-20180712.html 03
  6. 6. リクルートライフスタイルの紹介
  7. 7. リクルートのビジネスモデル04 クライアントとユーザーを結びつける 対価としてクライアントからフィーを受領 ユーザー クライアント
  8. 8. リクルートライフスタイルのサービス05
  9. 9. データプロダクトとは
  10. 10. データプロダクトとは サービスから収集されたデータを活用して価値を創出するプロダクト 06 既存サービスのグロース データの活用を前提とした新規サービス
  11. 11. データプロダクトにより実現したいこと07 チャットボットでお店を検索できるようにしたい サイト内検索順を調整して売上げを増やしたい ユーザーにおすすめのお店を推薦したい
  12. 12. データプロダクトのライフサイクル08 案件発生 企画プレ 分析 バッチ開発 前処理 モデリング API開発 LP開発 QAテスト ABテスト 評価 本番反映 運用
  13. 13. データプロダクトの不確実性を高める要因 選択肢が多い 09 関係者が多い ドメインが広い
  14. 14. 不確実性への対処 良いソリューションに近づくためには 試行錯誤を広く、素早く、小さくできる環境が必要 10
  15. 15. 不確実性への対処 良いソリューションに近づくためには 試行錯誤を広く、素早く、小さくできる環境が必要 リーンアプローチ 合意形成コストの最小化 クラウドの活用 早すぎる最適化を避ける 11
  16. 16. 不確実性に強い組織
  17. 17. 不確実性に強い組織12 状況が変化してもソリューション探索の早さに影響が無い 方針の変更が容易 合意形成が容易
  18. 18. 不確実性に強い組織13 三位一体 ビジネス、エンジニア、データサイエンティストでワンチーム 組織を横断しないのでコミュニケーションコストが小さい 意思決定しやすい
  19. 19. 不確実性に強い組織14 専門領域を強みとして他の領域も理解する お互いある程度他の職務に関する知識、スキルがある 変化があったとしても、意思の疎通がしやすく、意思決定が早い エンジニアリング データサイエンス ビジネス
  20. 20. 不確実性に強い組織15 自律的に動く 意思決定はチーム内、担当者同士で 変化が大きい環境ではトップダウン的な指示はボトルネックになる マネージャーは1対1の小MTGでキャッチアップ
  21. 21. 不確実性に強い組織16 サービス担当者から信頼されているビジネス側メンバーを配置 サービス側との合意形成が容易 テンポよく施策を推進できる 採用を妥協しない 独自のコーディング試験、モデリング試験を実施 ベースのスキルに加えて利益貢献に対する意欲が重要
  22. 22. CETチーム Capture EveryThing あらゆるデータを収集することを目的に発足 現在はデータの利活用側へシフト データプロダクト開発により価値を創出することがミッション 17
  23. 23. CETチーム18 CETチーム
  24. 24. CETチーム ビジネス 分析によるインサイトの発見 データプロダクトによるサービスグロースの起案 データサイエンティスト 分析によるインサイトの発見 施策起案、モデリング エンジニア 基盤システムの開発、運用 施策に特化したデータプロダクト開発、運用 データ・MLエンジニア、フロントエンド・バックエンド・アプリエンジニア 19
  25. 25. チーム体制20 エンジニア データサイエンティスト ビジネス 案件の発生 サービス側担当者 少チームを結成して データプロダクト開発を推進CET チーム
  26. 26. データプロダクト開発を支える基盤
  27. 27. 基盤システムに求められること データプロダクト開発における試行錯誤を 効率的に行うことを可能にする 21 システムは疎結合に 高いサービスレベルを求めすぎない 迅速なデプロイ環境 コミュニケーションを少なく
  28. 28. 適切なレイヤー分け ETL (extract, transform, load) マートはビジネスの意思決定にも利用される 高いサービスレベルが求められる 変化はそこまで多くなく 硬い 22 データプロダクト開発 試行錯誤が多く、素早い検証が求められる サービスレベルはそこまで高い必要は無い 変化が多く柔らかい サービスレベルや変化の頻度が違うシステムが 同じチームの責務にならないほうが良い
  29. 29. 適切なレイヤー分け23   CET基盤 案件1 案件2 案件N ストリーミングデータ収集 BLT 日時バッチによるマート作成 利活用のレイヤーは 柔軟に変化できる ・・・ BLTについて https://www.slideshare.net/RecruitLifestyle/ss-119541717
  30. 30. 汎用API 機械学習の予測結果をサービング KVSをリクエストパスに含まれるキーで取得し返す 非エンジニアでも簡単にAPIを作成 TSVアップロードで即APIとして利用可能に 24 案件発生 企画プレ 分析 バッチ開発 前処理 モデリング API開発 LP開発 QAテスト ABテスト 評価 本番反映 運用
  31. 31. 汎用API25 User GET request TSV Data scientist ML Batch Web server GCP Bigtable     AWS S3
  32. 32. MLバッチ処理基盤26 テンプレを使いながらデータサイエンティストがバッチを作成 エンジニアは必要ない 最低限品質を担保できる デプロイの自動化 Github FlowとCI/CDツールによりデプロイを手軽に 試行錯誤がしやすい 案件発生 企画プレ 分析 バッチ開発 前処理 モデリング API開発 LP開発 QAテスト ABテスト 評価 本番反映 運用
  33. 33. MLバッチ処理基盤27 DAG デプロイ 起動 データ 予測結果 Script Web hook Docker image Data scientist Engeenier Batch Instance API Data Loader GCP BigQuerycommit/merge/tag Airflow
  34. 34. cetflow28 MLバッチ基盤でエンジニア工数を削減できたが… データサイエンティストがバッチを作ること自体が辛い オンライン予測ができない 機会損失になっているかも
  35. 35. cetflow29 cetflow JupyterHubによるリソースが十分な分析・モデリング環境 Jupyter Notebookをそのままバッチとして運用 scikit-learn モデルのサービング コードレビューの自動化で最低限の品質は担保 案件発生 企画プレ 分析 バッチ開発 前処理 モデリング API開発 LP開発 QAテスト ABテスト 評価 本番反映 運用
  36. 36. cetflow01 https://engineer.recruit-lifestyle.co.jp/techblog/2018-10-04-ml-platform/
  37. 37. LPO基盤 FEの変更が伴う場合リードタイムが比較的長い チーム外担当者とのリリース時期調整など QAリソースの確保 サービスのHTMLを部分的にサービングする チーム内で自由にFEを変更 関係者との合意形成を簡易に 30 案件発生 企画プレ 分析 バッチ開発 前処理 モデリング API開発 LP開発 QAテスト ABテスト 評価 本番反映 運用
  38. 38. LPO基盤31 AWS Route 53 AWS S3 GCP LB GET Request ABテスト 対象ページ Reverse Proxy 通常 ページ 異常発生時は サービスへリダイレクト ABテスト対象ページを配信 User Health check
  39. 39. まとめ
  40. 40. まとめ リーンアプローチ 不確実性が高いのでまずは小さくやってみる 試行錯誤を素早く 試行錯誤を高速に行える環境づくり 組織観点、技術観点 チームで完結した推進 クラウドの利用 マネージド環境によるインフラ運用からの解放 本来のデータプロダクト開発にフォーカス 32
  41. 41. 謝辞 Photo by Annie Spratt on Unsplash Photo by Guillaume Jaillet on Unsplash Icons made by Roundicons from flaticon Icons made by Icon Pond from flaticon 33

×