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
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
ota42y
September 02, 2024
Technology
380
1
Share
バックログを導入し やっぱやめた話
渋谷アジャイル#2 ゼロからのアジャイル試行錯誤
の発表資料です
https://shibuyagile.connpass.com/event/327530/
ota42y
September 02, 2024
More Decks by ota42y
See All by ota42y
PFNにある2つのKubernetes
ota42y
10
5.8k
ゼロから作るDeep Learning 2 3章 word2vec 3.1〜3.2
ota42y
1
590
Q&A for How to use OpenAPI3 for API developer
ota42y
0
2.9k
How to use OpenAPI3 for API developer (RubyKaigi 2019)
ota42y
5
22k
How should we face with microservices (我々はマイクロサービスとどう向き合うべきか)
ota42y
20
4.9k
DeepLearningの本番環境にSageMakerを利用してる話
ota42y
1
6.8k
検索結果の良さを計測して定量的に改善していく
ota42y
3
2.7k
Flutterを広めるために技術同人誌を作った話
ota42y
1
1.8k
何も考えずにCIや継続的デリバリーしたら辛くなった話.pdf
ota42y
0
3.3k
Other Decks in Technology
See All in Technology
「QA=テスト」「シフトレフト=スクラムイベントの参加者の一員」の呪縛を解く。アジャイルな開発を止めないために、10Xで挑んだ「右側のしわ寄せ」解消記 #scrumniigata
nihonbuson
PRO
5
1.4k
Redmine次期バージョン7.0の注目新機能解説 — UI/UX強化と連携強化を中心に
vividtone
1
110
「背中を見て育て」からの卒業 〜専門技術としてのテスト設計を軸に、品質保証のバトンを繋ぐ〜 #genda_tech_talk
nihonbuson
PRO
3
1.4k
Gaussian Splattingの実用化 - 映像制作への展開
gpuunite_official
0
180
ServiceによるKubernetes通信制御ーClusterIPを例に
miku01
1
170
バイブコーディング、仕様駆動、その先へ - 「不確実性に対する検査‧適応のサイクル」を設計する
littlehands
1
170
AIエージェントの支払い基盤 AgentCore Payments概要
kmiya84377
2
180
"うちにはまだ早い"は本当? ─ 小さく始めるPlatform Engineering入門
harukasakihara
6
570
エンタープライズの厳格な制約を開発者に意識させない:クラウドネイティブ開発基盤設計/cloudnative-kaigi-golden-path
mhrtech
0
420
続 運用改善、不都合な真実 〜 物理制約のない運用改善はほとんど無価値 / 20260518-ssmjp-kaizen-no-value-without-physical-constraints
opelab
2
190
100マイクロサービスのTerraform/Kubernetes管理地獄から抜け出すためのAI活用術
markie1009
0
150
Gaussian Splattingの表現力を拡張する — 高周波再構成とインタラクションへのアプローチ —
gpuunite_official
0
170
Featured
See All Featured
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
54k
The innovator’s Mindset - Leading Through an Era of Exponential Change - McGill University 2025
jdejongh
PRO
1
170
Writing Fast Ruby
sferik
630
63k
SEO Brein meetup: CTRL+C is not how to scale international SEO
lindahogenes
1
2.6k
Highjacked: Video Game Concept Design
rkendrick25
PRO
1
350
Typedesign – Prime Four
hannesfritz
42
3k
Building a A Zero-Code AI SEO Workflow
portentint
PRO
0
500
Documentation Writing (for coders)
carmenintech
77
5.3k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
25
1.9k
Side Projects
sachag
455
43k
Believing is Seeing
oripsolob
1
120
Navigating Team Friction
lara
192
16k
Transcript
バックログを導入し やっぱやめた話 渋谷アジャイル#2 ota42y
自己紹介 • おおた @ota42y (X/Github) • Engineer Manager in PFN
◦ ML以外だいたい全部やるエンジニアもやっています ◦ 最近作っていたサービスがでました、今ならトライアル期間で無料です! ▪ https://plamo.preferredai.jp/ ▪ 登録してね!
今日の話のまとめ • LLMを応用するチームのEMをやっている • 1チームで複数プロジェクトをやっていて全体像が見えづらかった • バックログを入れてチーム全体の動きややることを整理した ◦ 全プロジェクトを一つの軸で並べて整理できる ◦
相互に何をやっているかを明確にできる ◦ メンバーが複数のプロジェクトに入る・サポートに回るなど、横の協力がしやすい • ある程度動いていたが、徐々にワークしなくなっていった ◦ プロジェクトが独立して動いていき、 POの元チームとして動き始めた ◦ プロダクトバックログでやりたかったことが不可能になってきた • 結果としてチームのプロダクトバックログを廃止した ◦ 各プロジェクトチームでやることが管理されていく ◦ マトリクス組織のようにプロジェクトとは別軸のチームに変化
LLMの応用に特化したチーム • PFNでは純国産の生成AI基盤モデルを作っています • LLMを研究・訓練するチームと協力して LLMの応用を考えるチームのEMをしています LLM研究チーム LLM応用チーム 社内の別チーム LLM
プロダクト 作成したLLMやノウハウ LLMプロダクトの 開発・運用 LLMツールの 提供
結構新しいチーム • もともと別々のことをやっていたが本格化に伴い統合 ◦ Applicationを作っているチーム ◦ R&Dをやっているチーム • 統合したことで別々のことを一つのチームでやっており全体像が分かりづらく 上位のEM
Devチーム R&Dチーム 上位のEM 応用チーム
複数プロジェクトの同時進行 • およそ3つのプロジェクトを1チームで行うことに ◦ ベースとなるLLM周りは共通の部分が多い ◦ 技術Seedを育てるフェーズのため、基本的にプロジェクトはチーム内で完結 ◦ ただし、専任や兼任もあり、人のアサインもまちまち •
このプロジェクトのXをやっているが、他プロジェクトのYのほうが重要では?という ことが分かりづらくなった LLM応用チーム 社内の別チーム LLM プロダクト LLM プロダクト
バックログを導入して全体を一箇所で管理 • プロダクトバックログを整備し、すべてのプロジェクトを一元管理 • スプリントごとにGitHub Projectで管理 No 内容 Point 詳細
3 ユーザはAとBを比較できる 5 devに関連 8 Cにより効果を改善する 13 R&Dに関連 5 Dを確認できる 8 R&Dに関連 プロダクトバックログ スプリントバックログ
バックログを導入して全体を一箇所で管理 • どのプロジェクトで何をやっているか、それは他のプロジェクトのものにくらべて優先 度はどれくらいか?を管理できるように • なぜそれをやるのか?何をやったら完成か?が明確になった No 内容 Point 詳細
3 ユーザはAとBを比較できる 5 devに関連 8 Cにより効果を改善する 13 R&Dに関連 5 Dを確認できる 8 R&Dに関連 プロダクトバックログ スプリントバックログ
徐々にワークしなくなっていく • プロダクトの成長・ツールの本格運用が始まると規模が拡大 ◦ BizDevとの連携が強くなり、 POが配置されるなど ◦ 他チームからの応援 LLM応用チーム 社内の別チーム
LLM プロダクト LLM プロダクト BizDev PO BizDev PO Engineer Engineer
応用チームのバックログの重要度が下がる • POの元で話が動き始める ◦ 応用チームで考える から POを元にしたプロダクトチームが考える という形に ◦ 何を優先するか、誰に何をやってもらうかもそちらで考えるように 社内の別チーム LLM
プロダクト LLM プロダクト BizDev PO BizDev PO Engineer Engineer LLM応用チーム LLM プロダクト LLM プロダクト BizDev PO BizDev PO Engineer
応用チームのバックログは廃止に • 一つのバックログですべてを管理するのをやめた ◦ プロダクトチームでやることを管理してもらう ◦ 応用チームは横方向の協力関係や人のアサインレベルでの管理に特化 ◦ 最終的にマトリクス組織のような構造になっている 社内の別チーム
LLM プロダクト LLM プロダクト BizDev PO BizDev PO Engineer Engineer LLM応用チーム LLM プロダクト LLM プロダクト BizDev PO BizDev PO Engineer
課題は残されている • プロダクトではないものをどう管理するか ◦ ツールやノウハウ提供といった活動 ◦ LLM周りの全チーム共通で使う仕組みのメンテナンス • 人の負荷軽減 ◦
困っているチームメンバーを助けやすい仕組み ◦ 複数PrJにわたった人のタスクの優先順位 • 良い方法を模索中、、、マトリクス組織の運営とかに知見がありそう? 社内の別チーム Engineer LLM応用チーム LLM プロダクト LLM プロダクト BizDev PO BizDev PO Engineer LLM プロダクト LLM プロダクト BizDev PO BizDev PO Engineer