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
johshisha
September 12, 2018
0
530
サービスに寄り添った研究開発部にするための取り組み
Data Driven Developer Meetup #1
https://d3m.connpass.com/event/98934/
johshisha
September 12, 2018
Tweet
Share
More Decks by johshisha
See All by johshisha
Cookpad Summer Internship 2022 15-day Tech Course ~サーバーサイド編~
johshisha
0
4k
Rustで作る機械学習を用いた画像クロッピングシステム
johshisha
2
2.6k
レシピの画像検索
johshisha
1
1k
機械学習を用いた見栄えのいい料理画像抽出をサービスに活かすための取り組み
johshisha
0
4.3k
Featured
See All Featured
Adopting Sorbet at Scale
ufuk
73
9.1k
Designing the Hi-DPI Web
ddemaree
280
34k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
42
9.2k
Side Projects
sachag
452
42k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
1.8k
How to Think Like a Performance Engineer
csswizardry
20
1.1k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
Product Roadmaps are Hard
iamctodd
PRO
49
11k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
26
2.1k
Measuring & Analyzing Core Web Vitals
bluesmoon
3
78
VelocityConf: Rendering Performance Case Studies
addyosmani
325
24k
Transcript
サービスに寄り添った 研究開発部にするための取り組み
2 自己紹介 • 三條智史 (さんじょう さとし) • クックパッド株式会社 2018年新卒 •
機械学習エンジニア johshisha
3 本日の内容 ※研究開発部は機械学習以外も行っていますが,今回は機械学習グ ループにおいての話をします 研究開発部とサービス開発の部署の連携方法の話 価値のある成果を出すための工夫や注意点の紹介
4 クックパッドの研究開発部(R&D) サービスに活きる研究 > 最先端の研究 ※ まったくしていない わけではないです 料理きろく おまかせ整理
ユーザのご意見分類
5 クックパッドR&Dの立ち位置 cookpadを開発する部署 広告基盤を開発する部署 ユーザをサポートする部署 ・・・ 研究開発部 仕事の依頼 R&Dは独立した部署で,全部署の機械学習関連のタスクを請け負う 例:
6 cookpadを開発する部署 広告基盤を開発する部署 ユーザをサポートする部署 ・・・ 研究開発部 仕事の依頼 クックパッドR&Dの立ち位置 R&Dは独立した部署で,全部署の機械学習関連のタスクを請け負う 例:
実際はそんなにたくさん 依頼がくるわけではない
7 研究開発部の仕事が生まれてサービスに組み込まれるまでの流れ アイデア出し・タスク設計 機械学習モデルの作成 サービスへの導入 R&Dだけではできない R&Dだけではできない 他部署との連携が不可欠
8 研究開発部の仕事が生まれてサービスに組み込まれるまでの流れ アイデア出し・タスク設計 機械学習モデルの作成 サービスへの導入 R&Dだけではできない R&Dだけではできない 他部署との連携が不可欠 → 連携する際に様々な課題がある
9 研究開発部の仕事が生まれてサービスに組み込まれるまでの流れ アイデア出し・タスク設計 機械学習モデルの作成 サービスへの導入 アイデア出し・タスク設計の段階で生じる問題
10 R&D起点のアイデアはサービスに組み込まれにくい • 他部署の状況をちゃんと理解できているわけではない ◦ 何を課題にしているのか ◦ 普段どういう風に仕事をしているのか ◦ ちゃんと把握するにはコストがかかる
• 他に優先度の高いタスクがある ◦ 実は本質的な課題を解決できなくて,そんなに役に立たなかったりする (ちょっと体験が良くなる程度) ◦ サービス導入の優先度が下がる できるだけサービス側からのアイデアがほしい
11 何ができて,何ができないのかわからないので, サービス側からのアイデアが出づらい 機械学習ってやつは 意外とできないこと多いらしい 結局何ができて何ができない のかわからない
12 R&Dでやってること 課題: 何ができて,何ができないのかわからないので, サービス側からのアイデアが出づらい 部署の定例MTGでできることの紹介 R&Dでできることを理解してもらう サービスでの課題を聞いてアイデアを募 る 既存の成果をサービスに利用してもらう
社内ブログで定期的に紹介 雑な相談用チャンネルの設置 毎週誰かがやっていることを紹介する R&D主体のアイデアはこういうところで 宣伝したりして,サービス利用のアイデア を募る 出てきたアイデアを逃さないように, 気軽に相談できる環境を準備している
13 となるときに注意すること サービス側から要望がもらえた! 早速取り掛かろう!
要望はあくまで解決法の一例 • いろんな背景を踏まえた上で出てきているアイデア ◦ なんでその要望がでてきたのか ◦ どういう課題を解決したいのか • より適した別の解決法があるかもしれない •
背景をちゃんと理解する必要がある 14 あれがこうだから あっちがこうなる そうすると こっちはこうだから 最終的に☓☓になるな ☓☓ができると嬉しいです!
15 個人的に注意して聞いていること • 要望がでてきた背景 ◦ 課題はなにか ◦ どういう風にうれしいのか • どれくらいうれしいのか
◦ コストに見合うメリットがあるか • どんなものができればうれしいのか ◦ 入出力 ◦ 性能 ◦ タスク特有の制約 • 使う人はどう思うのか ◦ アイデアを出した人とそれを利用する人が違う場合もある ◦ そのときは実際に使っている人がどう思うのかを聞きに行く
16 • 要望がでてきた背景 ◦ 課題: スパイクがうまく予測できていない ◦ 嬉しいこと: 広告の在庫管理をちゃんとできる •
どれくらいうれしいのか ◦ メリット: 今まで余っていたimpを売れる → 売上UP • どんなものができればうれしいのか ◦ 入出力: I (直近のimpression) → O (未来のimpression) ◦ 性能: 既存手法より高いもの・スパイクに頑強なもの ◦ 制約: 在庫足りないことは避けたい • 使う人はどう思うのか 人手で対応できているし,そんなに在庫管理で困っていない. それよりもキーワードごとのimpがわかったらうれしい. 例: 広告のimpression予測性能をよくしてほしい
17 • 要望がでてきた背景 ◦ 課題: スパイクがうまく予測できていない キーワードごとのimpressionの予測性能ができていない ◦ 嬉しいこと: 別商品の広告の在庫予測をできるようになる
• どれくらいうれしいのか ◦ メリット: 今まで余っていたimpを売れる → 売上UP • どんなものができればうれしいのか ◦ 入出力: I (直近のimpressionとキーワード ) → O (未来のimpression) ◦ 性能: 既存手法より高いもの・スパイクに頑強なもの ◦ 制約: 在庫足りないことは避けたい 例: 広告のimpression予測性能をよくしてほしい
18 研究開発部の仕事が生まれてサービスに組み込まれるまでの流れ アイデア出し・タスク設計 機械学習モデルの作成 サービスへの導入 サービスへ導入する段階で生じる問題
19 サービスへ組み込むタスクの優先度が低くなりがち R&Dでコードを触って導入するのは現状ではできない (技術力・リソース的問題) つまり サービスへ導入するにはサービス開発者のサポートが必要 しかし 機械学習関連のタスクは優先度が低くなってしまうことが多い • 他に部署としてやるべきタスクがたくさんある
• ビジネス的に劇的な効果が得られないタスクは特に
20 R&Dの取り組み サービス側でちゃんと導入まで責任を持ってくれる人を明確にする • アイデア出しの段階から一緒に議論してくれてる人にお願いすることが多い できる限りサービス側が利用しやすいように整備しておく • バッチ等でデータベースに結果を保存しておく • デモアプリケーションを用意しておく
• 社内ツールから参照できるようにしておく
21 まとめ サービスに寄り添ったR&Dにしようとしている • サービス側の要望をうまく得る事が重要 うまく成果を出すために • 得た要望を鵜呑みにしない • 背景・課題を理解した上で適した解決法を提案する
サービス導入への障壁はできるだけ取り払う • サービス開発者が簡単に利用できるように整備しておく