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

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