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

Transcript

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

   View Slide

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

   View Slide

3. 次の”はじめに”
   ● エムスリーのAIチームは、ML Engのチームではありません。
   ○ Data Eng, Software Eng, PdM, EM, ML Engが所属します。
   ○ 明確な役割分担ではなく、濃淡が違うイメージ。Data & ML Engとか。
   ● とは言っても... ML Engの仕事は？
   ○ 企画(売り込み？)
   ○ データ取得周りの整備
   ○ MLパイプラインの整備
   ○ データ取得から予測結果出力までの処理をDockerイメージ化
   ○ EngQA, CIの整備などなど。
   ○ 基本はエンジニア
   ○ (もちろん他のEngもやっています。) 3
   

   View Slide

4. 目指すチーム
   ● 強い仲間 × 価値が大きいプロダクト
   ○ 年間○十億円規模の利益貢献を目指す。
   ● 今日話すこと
   ● チームの初期と中期においての戦略
   ○ 強い仲間
   ■ ”強い”とは？集め方は？
   ○ 価値の大きいプロダクト
   ■ 最初のプロダクトは？将来目指す姿は？
   4
   

   View Slide

5. 強い仲間
   5
   

   View Slide

6. 強い仲間
   ● 集めたいポジション
   ○ ML Eng、Data Eng、Software Eng、PdM、EM
   ○ 全方向集めたい！ ⇒ 価値の高いプロダクトを作るために必要。
   ● 強いって何？
   ○ 高い専門性と広い周辺知識
   ○ エンジニアリング力
   ○ 実現力
   ○ オーナーシップ！
   6
   

   View Slide

7. 強い仲間を集める！ 1人 ⇒ 3人から5人
   ● 1人（私、ML Eng）からスタート
   ○ DataEngが必要！！
   ○ チーム立ち上げと同時(or 前)に探し始めた。
   ○ (Data Engは運良く良い人に巡り会えた)
   ● 強い人が”無名チーム”に入る理由は？ 普通はないでしょ。
   ○ ⇒ だから戦略が必要。
   7
   

   View Slide

8. 強い人に3人目、4人目として入ってほしい！
   ● (仮説)強い人が働きたい環境とは？
   ○ 強い人がいる。
   ○ 強い人の密度が高い。
   ○ スキルアップ・キャリアアップにつながる。
   ○ 価値のあるプロダクトを作れる(後半で話す)。
   ● つまり
   ○ 自分が強くなる必要がある！
   ○ 強い人を集めていることを伝える必要がある！
   8
   

   View Slide

9. 実際に行ったこと
   ● 自分が強くなる必要がある！
   ○ 仕事で結果出す！
   ○ 外部へ向けて情報発信する。
   ■ 業務で作ったプロダクト・アルゴリズム
   ■ 論文輪読会で発表。読んだ内容のメモを公開
   ■ OSS化(gokart, redshells) (すごく整備中。。。)
   ○ 真剣に候補者のスキルアップ・キャリアップについて考える！！
   ● 結果 ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ ⇒
   ○ ほんとに嬉しい！楽しい！！
   ○ （すごく優秀なので登壇依頼してあげてください！！年12回！！！）
   9
   

   View Slide

10. 強い仲間を集める！ 5人 ⇒ 15人
    ● さらに仲間を集める
    ○ 強い人の密度を更に高める。
    ○ チームとして強くなる。
    ○ 価値のあるプロダクトを作る(後半で話す)。
    ● 大人数が必要なプロダクトとは(後半で話す)？
    ○ ○ 1人ひとりが相互に依存するプロダクト開発をしている
    ○ ✗ 1人ひとりが独立的に小規模なプロダクト開発をしている
    10
    

    View Slide

11. 価値が大きいプロダクト
    11
    

    View Slide

12. 価値が大きいプロダクト
    ● 企画して開発して育てる。
    ○ 普通のことが難しい。
    ● 実行できない理由例
    ○ 課題設定ができない、なんとなくAI使いたい
    ○ データが取得できない、データ基盤が整っていない
    ○ そもそもデータがない
    ○ プロダクションに乗せられない
    ○ モデルの精度がでない
    12
    

    View Slide

13. 最初のプロジェクトの選び方
    ● 既存サービスでRule-basedなものをMLに置き換える。
    ● 他社でうまくいっているMLの分野を選ぶ。
    ● 成功確率が高く工数も少ない。
    Data
    Rule based
    algorithm
    DB Service
    ML
    algorithm
    13
    

    View Slide

14. 2つ目以降のプロジェクトの選び方
    ● 成功確率を上げる
    ○ 技術的に近いもの
    ○ 2’ではなく2
    ○ 小さく始める
    ● ROIを上げる
    ○ 同じ仕組みを使えるもの
    ○ 互いに相乗効果があるもの
    1 2
    3 4
    5
    2’
    14
    

    View Slide

15. 小さく始める
    ● (仮)カルテと問診(質問が自動化されている)から自動診断したい
    ○ リスクが多く成功確率が低い。工数がかかる。
    ● 小さく始める
    ○ (例)QAサイトの改善から始める。技術を貯める。
    ■ 新規のQuestionに対して
    ● 過去のAnswerを関連付ける
    ● 他のQuestionと差分を把握する(条件等)
    ● 良いQuestionをするための補助を行なう
    ● ・・・・
    ⇒ 問診の自動化につながる
    15
    

    View Slide

16. 相乗効果を生み出す
    ● 他のプロジェクトを改善するようなリッチなデータが取得できる
    ○ implicit dataを使った推薦システムを強化するようなexplicit dataが取得でき
    る。
    ● 他のプロジェクトの特徴量として活用できる(埋め込み表現など)
    ○ ユーザーやコンテンツの特徴量化の高度化を行なう。推薦システムや関連コ
    ンテンツ探索などに応用可能。
    ● 他のプロジェクトでも技術（コード）がそのまま使える。
    ○ モジュール化。次のプロジェクトの工数が大幅に削減できる。
    16
    

    View Slide

17. feedback(強)
    ・検索キーワード
    ・アンケート
    feedback(中)
    ・関連記事一覧
    feedback(弱)
    ・アクセスログ
    Gauss
    (item, tag, score)
    Maxwell
    (user, tag, score)
    Archimedes
    (推薦システム)
    各サービス分析
    サービスの
    パーソナライズ
    プロジェクト
    Isaacs
    ・EntityLinking
    ・一覧ページ
    Knuth
    ・検索エンジン
    ・パーソナライズ
    ● 全体を一つのプロダクトだと考え成長させる。
    Feynman
    ・クローラー
    ・コンテンツ作成支援
    17
    

    View Slide

18. コラム
    18
    

    View Slide

19. コラム1: チームビルディングに必要な要素
    ● 協力してくれる人事
    ○ 採用力のある人事担当者が必要
    ○ AIチームの2人目のData Engは人事が見つけて来てくれた。
    ○ (今日もイベントに来てくれています)
    ● 収益を上げる
    ○ 人数を増やすことに対する説明責任
    ○ 収益を上げられると説明がしやすい
    19
    

    View Slide

20. コラム2: ストレッチ目標
    ● ストレッチ目標が好きです。
    ● 成功確率が50%くらいに設定
    ● 達成することにコミットは必要
    ● 思考をストレッチしてほしい。
    ● 今までやり方ではなく新しいチャレン
    ジをしてほしい
    ● もちろん私も支援する
    ● (私にとってもストレッチ)
    ● 評価は達成率ではなく長期的観点
    で行なう
    20
    

    View Slide

21. コラム3: 1on1で「不満は？」は聞かない
    ● 前提: 成長や目標達成のサポートをするために1on1をしている。
    ○ 成長のサポートで効果の高いものに取り組みたい。
    ■ 例: Aの方が大事
    ● A: +10 ⇒ +20
    ● B: -10 ⇒ 0
    ○ 「不満は？」と定型文で聞くと「不満」を探すようになりそう
    ■ 例: 効果が低すぎるものが出てきそう
    ● C: -0.1 ⇒ 0
    ● メンバーが「リーダーになりたい！」と思えるリーダーになりたい！
    ○ チームやメンバーの成長をドライブすることに専念したい。
    ○ 雑用係にはならない。(もちろんメンバーも雑用係でない)
    21
    

    View Slide

22. コラム4: 良いプロダクトを考えるために
    ● PdMの勉強中
    22
    

    View Slide

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

    View Slide

24. 質問受付
    24
    

    View Slide

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

    View Slide