Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
エムスリーの機械学習チームビルディングの考え方
Search
nishiba
March 28, 2019
Technology
12
6.9k
エムスリーの機械学習チームビルディングの考え方
nishiba
March 28, 2019
Tweet
Share
More Decks by nishiba
See All by nishiba
gokartを作った話
nishiba
2
7.6k
m3 ai team
nishiba
36
45k
Graph Convolutional Networksを使った 推薦システム
nishiba
6
8.1k
機械学習関連の開発を 効率化した話
nishiba
7
5.2k
Graphの推薦システムへの応用
nishiba
6
8.4k
AI・機械学習チームにおけるデータパイプライン構築
nishiba
8
26k
エムスリーにおける 機械学習活用事例と開発の効率化
nishiba
3
6.5k
医療用語に注目した文書の類似度計算
nishiba
6
4.7k
WSDM 2018 論文読み会 Hyperbolic Representation Learning for Fast and Efficient Neural Qestion Answering
nishiba
0
1.6k
Other Decks in Technology
See All in Technology
Shift-from-React-to-Vue
calm1205
3
1.3k
独自ツール開発でスタジオ撮影をDX!「VLS(Virtual LED Studio)」 / dx-studio-vls
cyberagentdevelopers
PRO
1
180
端末が簡単にリモートから操作されるデモを通じて ソフトウェアサプライチェーン攻撃対策の重要性を理解しよう
kitaji0306
0
170
よくわからんサービスについての問い合わせが来たときの強い味方 Amazon Q について
kazzpapa3
0
220
Amazon_CloudWatch_ログ異常検出_導入ガイド
tsujiba
4
1.6k
ネット広告に未来はあるか?「3rd Party Cookie廃止とPrivacy Sandboxの効果検証の裏側」 / third-party-cookie-privacy
cyberagentdevelopers
PRO
1
130
Nix入門パラダイム編
asa1984
2
200
Jr. Championsになって、強く連携しながらAWSをもっと使いたい!~AWSに対する期待と行動~
amixedcolor
0
190
Amazon FSx for NetApp ONTAPを利用するにあたっての要件整理と設計のポイント
non97
1
160
なんで、私がAWS Heroに!? 〜社外の広い世界に一歩踏み出そう〜
minorun365
PRO
6
1.1k
バクラクにおける可観測性向上の取り組み
yuu26
3
410
Product Engineer Night #6プロダクトエンジニアを育む仕組み・施策
hacomono
PRO
1
470
Featured
See All Featured
Being A Developer After 40
akosma
86
590k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
It's Worth the Effort
3n
183
27k
[RailsConf 2023] Rails as a piece of cake
palkan
51
4.9k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
3
370
What's new in Ruby 2.0
geeforr
342
31k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
26
2.1k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
43
6.6k
A Philosophy of Restraint
colly
203
16k
Writing Fast Ruby
sferik
626
61k
Testing 201, or: Great Expectations
jmmastey
38
7k
Transcript
エムスリーの機械学習チームビルディングの考え方 チームリーダー 西場正浩 @m_nishiba 2019年3月28日 Version 0.4
はじめに • この資料は2019年3月28日時点で私個人が考えたことです。 • チームビルディング真っ只中なので明日、言っていることは変わるかも。 • 最新情報は@m_nishibaをチェック!! 2
次の”はじめに” • エムスリーのAIチームは、ML Engのチームではありません。 ◦ Data Eng, Software Eng, PdM,
EM, ML Engが所属します。 ◦ 明確な役割分担ではなく、濃淡が違うイメージ。Data & ML Engとか。 • とは言っても... ML Engの仕事は? ◦ 企画(売り込み?) ◦ データ取得周りの整備 ◦ MLパイプラインの整備 ◦ データ取得から予測結果出力までの処理をDockerイメージ化 ◦ EngQA, CIの整備などなど。 ◦ 基本はエンジニア ◦ (もちろん他のEngもやっています。) 3
目指すチーム • 強い仲間 × 価値が大きいプロダクト ◦ 年間◦十億円規模の利益貢献を目指す。 • 今日話すこと •
チームの初期と中期においての戦略 ◦ 強い仲間 ▪ ”強い”とは?集め方は? ◦ 価値の大きいプロダクト ▪ 最初のプロダクトは?将来目指す姿は? 4
強い仲間 5
強い仲間 • 集めたいポジション ◦ ML Eng、Data Eng、Software Eng、PdM、EM ◦ 全方向集めたい!
⇒ 価値の高いプロダクトを作るために必要。 • 強いって何? ◦ 高い専門性と広い周辺知識 ◦ エンジニアリング力 ◦ 実現力 ◦ オーナーシップ! 6
強い仲間を集める! 1人 ⇒ 3人から5人 • 1人(私、ML Eng)からスタート ◦ DataEngが必要!! ◦
チーム立ち上げと同時(or 前)に探し始めた。 ◦ (Data Engは運良く良い人に巡り会えた) • 強い人が”無名チーム”に入る理由は? 普通はないでしょ。 ◦ ⇒ だから戦略が必要。 7
強い人に3人目、4人目として入ってほしい! • (仮説)強い人が働きたい環境とは? ◦ 強い人がいる。 ◦ 強い人の密度が高い。 ◦ スキルアップ・キャリアアップにつながる。 ◦
価値のあるプロダクトを作れる(後半で話す)。 • つまり ◦ 自分が強くなる必要がある! ◦ 強い人を集めていることを伝える必要がある! 8
実際に行ったこと • 自分が強くなる必要がある! ◦ 仕事で結果出す! ◦ 外部へ向けて情報発信する。 ▪ 業務で作ったプロダクト・アルゴリズム ▪
論文輪読会で発表。読んだ内容のメモを公開 ▪ OSS化(gokart, redshells) (すごく整備中。。。) ◦ 真剣に候補者のスキルアップ・キャリアップについて考える!! • 結果 ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ ◦ ほんとに嬉しい!楽しい!! ◦ (すごく優秀なので登壇依頼してあげてください!!年12回!!!) 9
強い仲間を集める! 5人 ⇒ 15人 • さらに仲間を集める ◦ 強い人の密度を更に高める。 ◦ チームとして強くなる。
◦ 価値のあるプロダクトを作る(後半で話す)。 • 大人数が必要なプロダクトとは(後半で話す)? ◦ ◦ 1人ひとりが相互に依存するプロダクト開発をしている ◦ ✗ 1人ひとりが独立的に小規模なプロダクト開発をしている 10
価値が大きいプロダクト 11
価値が大きいプロダクト • 企画して開発して育てる。 ◦ 普通のことが難しい。 • 実行できない理由例 ◦ 課題設定ができない、なんとなくAI使いたい ◦
データが取得できない、データ基盤が整っていない ◦ そもそもデータがない ◦ プロダクションに乗せられない ◦ モデルの精度がでない 12
最初のプロジェクトの選び方 • 既存サービスでRule-basedなものをMLに置き換える。 • 他社でうまくいっているMLの分野を選ぶ。 • 成功確率が高く工数も少ない。 Data Rule based
algorithm DB Service ML algorithm 13
2つ目以降のプロジェクトの選び方 • 成功確率を上げる ◦ 技術的に近いもの ◦ 2’ではなく2 ◦ 小さく始める •
ROIを上げる ◦ 同じ仕組みを使えるもの ◦ 互いに相乗効果があるもの 1 2 3 4 5 2’ 14
小さく始める • (仮)カルテと問診(質問が自動化されている)から自動診断したい ◦ リスクが多く成功確率が低い。工数がかかる。 • 小さく始める ◦ (例)QAサイトの改善から始める。技術を貯める。 ▪
新規のQuestionに対して • 過去のAnswerを関連付ける • 他のQuestionと差分を把握する(条件等) • 良いQuestionをするための補助を行なう • ・・・・ ⇒ 問診の自動化につながる 15
相乗効果を生み出す • 他のプロジェクトを改善するようなリッチなデータが取得できる ◦ implicit dataを使った推薦システムを強化するようなexplicit dataが取得でき る。 • 他のプロジェクトの特徴量として活用できる(埋め込み表現など)
◦ ユーザーやコンテンツの特徴量化の高度化を行なう。推薦システムや関連コ ンテンツ探索などに応用可能。 • 他のプロジェクトでも技術(コード)がそのまま使える。 ◦ モジュール化。次のプロジェクトの工数が大幅に削減できる。 16
feedback(強) ・検索キーワード ・アンケート feedback(中) ・関連記事一覧 feedback(弱) ・アクセスログ Gauss (item, tag,
score) Maxwell (user, tag, score) Archimedes (推薦システム) 各サービス分析 サービスの パーソナライズ プロジェクト Isaacs ・EntityLinking ・一覧ページ Knuth ・検索エンジン ・パーソナライズ • 全体を一つのプロダクトだと考え成長させる。 Feynman ・クローラー ・コンテンツ作成支援 17
コラム 18
コラム1: チームビルディングに必要な要素 • 協力してくれる人事 ◦ 採用力のある人事担当者が必要 ◦ AIチームの2人目のData Engは人事が見つけて来てくれた。 ◦
(今日もイベントに来てくれています) • 収益を上げる ◦ 人数を増やすことに対する説明責任 ◦ 収益を上げられると説明がしやすい 19
コラム2: ストレッチ目標 • ストレッチ目標が好きです。 • 成功確率が50%くらいに設定 • 達成することにコミットは必要 • 思考をストレッチしてほしい。
• 今までやり方ではなく新しいチャレン ジをしてほしい • もちろん私も支援する • (私にとってもストレッチ) • 評価は達成率ではなく長期的観点 で行なう 20
コラム3: 1on1で「不満は?」は聞かない • 前提: 成長や目標達成のサポートをするために1on1をしている。 ◦ 成長のサポートで効果の高いものに取り組みたい。 ▪ 例: Aの方が大事
• A: +10 ⇒ +20 • B: -10 ⇒ 0 ◦ 「不満は?」と定型文で聞くと「不満」を探すようになりそう ▪ 例: 効果が低すぎるものが出てきそう • C: -0.1 ⇒ 0 • メンバーが「リーダーになりたい!」と思えるリーダーになりたい! ◦ チームやメンバーの成長をドライブすることに専念したい。 ◦ 雑用係にはならない。(もちろんメンバーも雑用係でない) 21
コラム4: 良いプロダクトを考えるために • PdMの勉強中 22
コラム4: オンボーディング Under Construction... 23
質問受付 24
Twitterでもらった質問に答えます。 m_nishibaにメンションください〜 25