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.7k
m3 ai team
nishiba
36
45k
Graph Convolutional Networksを使った 推薦システム
nishiba
6
8.1k
機械学習関連の開発を 効率化した話
nishiba
7
5.2k
Graphの推薦システムへの応用
nishiba
6
8.5k
AI・機械学習チームにおけるデータパイプライン構築
nishiba
8
26k
エムスリーにおける 機械学習活用事例と開発の効率化
nishiba
3
6.6k
医療用語に注目した文書の類似度計算
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
【若手エンジニア応援LT会】ソフトウェアを学んできた私がインフラエンジニアを目指した理由
kazushi_ohata
0
150
The Rise of LLMOps
asei
7
1.6k
Platform Engineering for Software Developers and Architects
syntasso
1
520
社内で最大の技術的負債のリファクタリングに取り組んだお話し
kidooonn
1
550
Evangelismo técnico: ¿qué, cómo y por qué?
trishagee
0
360
マルチプロダクトな開発組織で 「開発生産性」に向き合うために試みたこと / Improving Multi-Product Dev Productivity
sugamasao
1
310
20241120_JAWS_東京_ランチタイムLT#17_AWS認定全冠の先へ
tsumita
2
280
Making your applications cross-environment - OSCG 2024 NA
salaboy
0
190
Terraform Stacks入門 #HashiTalks
msato
0
360
SSMRunbook作成の勘所_20241120
koichiotomo
2
150
エンジニア人生の拡張性を高める 「探索型キャリア設計」の提案
tenshoku_draft
1
130
Flutterによる 効率的なAndroid・iOS・Webアプリケーション開発の事例
recruitengineers
PRO
0
110
Featured
See All Featured
Rebuilding a faster, lazier Slack
samanthasiow
79
8.7k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
1.9k
Statistics for Hackers
jakevdp
796
220k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
6
410
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
What's in a price? How to price your products and services
michaelherold
243
12k
How to Think Like a Performance Engineer
csswizardry
20
1.1k
Bash Introduction
62gerente
608
210k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
16
2.1k
It's Worth the Effort
3n
183
27k
The Pragmatic Product Professional
lauravandoore
31
6.3k
Building Your Own Lightsaber
phodgson
103
6.1k
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