エムスリーの機械学習チームビルディングの考え方

De48ef31de22781848d8f9988bd20a5e?s=47 nishiba
March 28, 2019

 エムスリーの機械学習チームビルディングの考え方

De48ef31de22781848d8f9988bd20a5e?s=128

nishiba

March 28, 2019
Tweet

Transcript

  1. エムスリーの機械学習チームビルディングの考え方 チームリーダー 西場正浩 @m_nishiba 2019年3月28日 Version 0.4

  2. はじめに • この資料は2019年3月28日時点で私個人が考えたことです。 • チームビルディング真っ只中なので明日、言っていることは変わるかも。 • 最新情報は@m_nishibaをチェック!! 2

  3. 次の”はじめに” • エムスリーのAIチームは、ML Engのチームではありません。 ◦ Data Eng, Software Eng, PdM,

    EM, ML Engが所属します。 ◦ 明確な役割分担ではなく、濃淡が違うイメージ。Data & ML Engとか。 • とは言っても... ML Engの仕事は? ◦ 企画(売り込み?) ◦ データ取得周りの整備 ◦ MLパイプラインの整備 ◦ データ取得から予測結果出力までの処理をDockerイメージ化 ◦ EngQA, CIの整備などなど。 ◦ 基本はエンジニア ◦ (もちろん他のEngもやっています。) 3
  4. 目指すチーム • 強い仲間 × 価値が大きいプロダクト ◦ 年間◦十億円規模の利益貢献を目指す。 • 今日話すこと •

    チームの初期と中期においての戦略 ◦ 強い仲間 ▪ ”強い”とは?集め方は? ◦ 価値の大きいプロダクト ▪ 最初のプロダクトは?将来目指す姿は? 4
  5. 強い仲間 5

  6. 強い仲間 • 集めたいポジション ◦ ML Eng、Data Eng、Software Eng、PdM、EM ◦ 全方向集めたい!

    ⇒ 価値の高いプロダクトを作るために必要。 • 強いって何? ◦ 高い専門性と広い周辺知識 ◦ エンジニアリング力 ◦ 実現力 ◦ オーナーシップ! 6
  7. 強い仲間を集める! 1人 ⇒ 3人から5人 • 1人(私、ML Eng)からスタート ◦ DataEngが必要!! ◦

    チーム立ち上げと同時(or 前)に探し始めた。 ◦ (Data Engは運良く良い人に巡り会えた) • 強い人が”無名チーム”に入る理由は? 普通はないでしょ。 ◦ ⇒ だから戦略が必要。 7
  8. 強い人に3人目、4人目として入ってほしい! • (仮説)強い人が働きたい環境とは? ◦ 強い人がいる。 ◦ 強い人の密度が高い。 ◦ スキルアップ・キャリアアップにつながる。 ◦

    価値のあるプロダクトを作れる(後半で話す)。 • つまり ◦ 自分が強くなる必要がある! ◦ 強い人を集めていることを伝える必要がある! 8
  9. 実際に行ったこと • 自分が強くなる必要がある! ◦ 仕事で結果出す! ◦ 外部へ向けて情報発信する。 ▪ 業務で作ったプロダクト・アルゴリズム ▪

    論文輪読会で発表。読んだ内容のメモを公開 ▪ OSS化(gokart, redshells) (すごく整備中。。。) ◦ 真剣に候補者のスキルアップ・キャリアップについて考える!! • 結果 ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ ◦ ほんとに嬉しい!楽しい!! ◦ (すごく優秀なので登壇依頼してあげてください!!年12回!!!) 9
  10. 強い仲間を集める! 5人 ⇒ 15人 • さらに仲間を集める ◦ 強い人の密度を更に高める。 ◦ チームとして強くなる。

    ◦ 価値のあるプロダクトを作る(後半で話す)。 • 大人数が必要なプロダクトとは(後半で話す)? ◦ ◦ 1人ひとりが相互に依存するプロダクト開発をしている ◦ ✗ 1人ひとりが独立的に小規模なプロダクト開発をしている 10
  11. 価値が大きいプロダクト 11

  12. 価値が大きいプロダクト • 企画して開発して育てる。 ◦ 普通のことが難しい。 • 実行できない理由例 ◦ 課題設定ができない、なんとなくAI使いたい ◦

    データが取得できない、データ基盤が整っていない ◦ そもそもデータがない ◦ プロダクションに乗せられない ◦ モデルの精度がでない 12
  13. 最初のプロジェクトの選び方 • 既存サービスでRule-basedなものをMLに置き換える。 • 他社でうまくいっているMLの分野を選ぶ。 • 成功確率が高く工数も少ない。 Data Rule based

    algorithm DB Service ML algorithm 13
  14. 2つ目以降のプロジェクトの選び方 • 成功確率を上げる ◦ 技術的に近いもの ◦ 2’ではなく2 ◦ 小さく始める •

    ROIを上げる ◦ 同じ仕組みを使えるもの ◦ 互いに相乗効果があるもの 1 2 3 4 5 2’ 14
  15. 小さく始める • (仮)カルテと問診(質問が自動化されている)から自動診断したい ◦ リスクが多く成功確率が低い。工数がかかる。 • 小さく始める ◦ (例)QAサイトの改善から始める。技術を貯める。 ▪

    新規のQuestionに対して • 過去のAnswerを関連付ける • 他のQuestionと差分を把握する(条件等) • 良いQuestionをするための補助を行なう • ・・・・ ⇒ 問診の自動化につながる 15
  16. 相乗効果を生み出す • 他のプロジェクトを改善するようなリッチなデータが取得できる ◦ implicit dataを使った推薦システムを強化するようなexplicit dataが取得でき る。 • 他のプロジェクトの特徴量として活用できる(埋め込み表現など)

    ◦ ユーザーやコンテンツの特徴量化の高度化を行なう。推薦システムや関連コ ンテンツ探索などに応用可能。 • 他のプロジェクトでも技術(コード)がそのまま使える。 ◦ モジュール化。次のプロジェクトの工数が大幅に削減できる。 16
  17. feedback(強) ・検索キーワード ・アンケート feedback(中) ・関連記事一覧 feedback(弱) ・アクセスログ Gauss (item, tag,

    score) Maxwell (user, tag, score) Archimedes (推薦システム) 各サービス分析 サービスの パーソナライズ プロジェクト Isaacs ・EntityLinking ・一覧ページ Knuth ・検索エンジン ・パーソナライズ • 全体を一つのプロダクトだと考え成長させる。 Feynman ・クローラー ・コンテンツ作成支援 17
  18. コラム 18

  19. コラム1: チームビルディングに必要な要素 • 協力してくれる人事 ◦ 採用力のある人事担当者が必要 ◦ AIチームの2人目のData Engは人事が見つけて来てくれた。 ◦

    (今日もイベントに来てくれています) • 収益を上げる ◦ 人数を増やすことに対する説明責任 ◦ 収益を上げられると説明がしやすい 19
  20. コラム2: ストレッチ目標 • ストレッチ目標が好きです。 • 成功確率が50%くらいに設定 • 達成することにコミットは必要 • 思考をストレッチしてほしい。

    • 今までやり方ではなく新しいチャレン ジをしてほしい • もちろん私も支援する • (私にとってもストレッチ) • 評価は達成率ではなく長期的観点 で行なう 20
  21. コラム3: 1on1で「不満は?」は聞かない • 前提: 成長や目標達成のサポートをするために1on1をしている。 ◦ 成長のサポートで効果の高いものに取り組みたい。 ▪ 例: Aの方が大事

    • A: +10 ⇒ +20 • B: -10 ⇒ 0 ◦ 「不満は?」と定型文で聞くと「不満」を探すようになりそう ▪ 例: 効果が低すぎるものが出てきそう • C: -0.1 ⇒ 0 • メンバーが「リーダーになりたい!」と思えるリーダーになりたい! ◦ チームやメンバーの成長をドライブすることに専念したい。 ◦ 雑用係にはならない。(もちろんメンバーも雑用係でない) 21
  22. コラム4: 良いプロダクトを考えるために • PdMの勉強中 22

  23. コラム4: オンボーディング Under Construction... 23

  24. 質問受付 24

  25. Twitterでもらった質問に答えます。 m_nishibaにメンションください〜 25