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
なんとなくチームを構成することから脱却する方法 / Clean Teams
Search
Yoshihiro Yunomae
October 31, 2019
Technology
8
7.5k
なんとなくチームを構成することから脱却する方法 / Clean Teams
2019.10.31に開催されたEngineering Organization Festival(EOF) 2019で発表に使った資料です
Yoshihiro Yunomae
October 31, 2019
Tweet
Share
More Decks by Yoshihiro Yunomae
See All by Yoshihiro Yunomae
モバイルゲームの運用の安定化のためにプロセスマネジメントをチームで取り組んでみた / Process Management Team in Akatsuki
yunon_phys
1
3.8k
ゲーム事業を持続成長させる組織をつくる / Game Organization in Akatsuki
yunon_phys
1
1.1k
アカツキにおける チーム経営の取り組み / Executive Leadership Team in Akatsuki
yunon_phys
5
7.1k
アカツキのEngineering Managerは何をする人なのか / What is an EM in Akatsuki?
yunon_phys
7
2.1k
Engineering Managerは何をする人なのか/ What are Roles of Engineering Managers?
yunon_phys
2
13k
キャリア形成に必要なのは、ただ飛び込むという勇気だけだった / My Career DevLOVE X
yunon_phys
9
12k
運用中のモバイルゲーム開発チームに、 並行バージョン開発を導入してみた/RSGT2019
yunon_phys
5
9.4k
Engineering Managerの役割を再定義してみる / Redefinition of Engineering Manager Role
yunon_phys
4
3.1k
技術書典で本を出すまでのジャーニー
yunon_phys
1
320
Other Decks in Technology
See All in Technology
Delegating the chores of authenticating users to Keycloak
ahus1
0
190
Introduction to Sansan for Engineers / エンジニア向け会社紹介
sansan33
PRO
5
39k
20250708オープンエンドな探索と知識発見
sakana_ai
PRO
5
1.1k
Figma Dev Mode MCP Serverを用いたUI開発
zoothezoo
1
270
マルチプロダクト環境におけるSREの役割 / SRE NEXT 2025 lunch session
sugamasao
1
800
ロールが細分化された組織でSREは何をするか?
tgidgd
1
450
PHPからはじめるコンピュータアーキテクチャ / From Scripts to Silicon: A Journey Through the Layers of Computing
tomzoh
2
330
三視点LLMによる複数観点レビュー
mhlyc
0
240
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
18k
Semantic Machine Intelligence for Vision, Language, and Actions
keio_smilab
PRO
2
330
ソフトウェアQAがハードウェアの人になったの
mineo_matsuya
3
230
SRE with AI:実践から学ぶ、運用課題解決と未来への展望
yoshiiryo1
1
480
Featured
See All Featured
What's in a price? How to price your products and services
michaelherold
246
12k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Typedesign – Prime Four
hannesfritz
42
2.7k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
KATA
mclloyd
30
14k
Building a Modern Day E-commerce SEO Strategy
aleyda
42
7.4k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
840
Mobile First: as difficult as doing things right
swwweet
223
9.7k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
47
9.6k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.5k
Transcript
なんとなくチームを構成することから 脱却する⽅法 アカツキ 湯前 慶⼤
2 湯前 慶⼤(ゆのまえ よしひろ) @yunon_phys ・2010~2014(電気メーカー) R & D of
Linux カーネル ・2014~(アカツキ) VP of Engineering プロジェクトマネージャー, スクラムマスター
3 良いチーム、 作れていますか?
4 良いチーム構成、 作れていますか?
5 チーム構成はトレードオフの関係
6 事例: アカツキのゲーム開発プロジェクト 拠点A 拠点B 各拠点で閉じて開発するのが良いのか? 混ぜて開発するのが良いのか?
7 ⽅向性の認識が合いやすい コミュニケーション コスト増⼤ チーム間の整合性 チームを分断すべきか、統合すべきか チーム内の認識すり合わせ
8 ⽅向性の認識が合いやすい コミュニケーション コスト増⼤ チーム間の整合性 チームを分断すべきか、統合すべきか チーム内の認識すり合わせ 別の手段 で担保
9 PO Area PO Area PO ü ユーザーストーリーをPO同⼠ですり合わせ、受け⼊れ基準の明確化 ü Howは各拠点に任せる
10 PO Area PO Area PO ü ユーザーストーリーをPO同⼠ですり合わせ、受け⼊れ条件の明確化 ü Howは各拠点に任せる
しかし、これだけでは終わらなかった
11 ソーシャルゲームの特徴 üリリースしてからが本番
12 ソーシャルゲームの特徴 üリリースしてからが本番 ü運⽤はノウハウの塊
13 ソーシャルゲームの特徴 üリリースしてからが本番 ü運⽤はノウハウの塊 üバイナリアップデート⾟い
14 ソーシャルゲームの特徴 üリリースしてからが本番 ü運⽤はノウハウの塊 üバイナリアップデート⾟い üイケてない⾮機能が真綿で ⾸を絞めてくる
15 考えなければいけないこと 運⽤どちらがやる? 開発項⽬どう わける? 同じソースを触っ て問題がおきたら どうしよう ⾮機能開発どちら がやる?
採⽤難易度??
16 コンテンツ更新必要 コンテンツ更新不要 ソース コード 更新不要 機能追加・改修 非機能追加・ 改修 バイナリ改修不要
バイナリ改修必要 バイナリ 改修不要 ひとまず観点整理(図解思考法)
17 運⽤の経験あり ⼀から施策を考えた 運⽤の経験なし こちらが運用を担当する
18 コンテンツ更新必要 コンテンツ更新不要 ソース コード 更新不要 機能追加・改修 非機能追加・ 改修 バイナリ改修不要
バイナリ改修必要 バイナリ 改修不要 運⽤ ⾮運⽤
19 コンテンツ更新必要 コンテンツ更新不要 ソース コード 更新不要 機能追加・改修 非機能追加・ 改修 バイナリ改修不要
バイナリ改修必要 バイナリ 改修不要 運⽤ ⾮運⽤ 実は運用経験に深く 関わりがある
20 コンテンツ更新必要 コンテ ンツ更 新不 要 ソース コード 更新不要 機能追加・改修
非機能追加・ 改修 バイナリ改修不要 バイナリ改修必要 バイナリ 改修不要 運⽤ ⾮運⽤ コンテンツ更新 不要 運⽤ (⾮機能開発) 運用チームにスイッチ
21 コンテンツ更新必要 コンテ ンツ更 新不 要 ソース コード 更新不要 機能追加・改修
非機能追加・ 改修 バイナリ改修不要 バイナリ改修必要 バイナリ 改修不要 運⽤ ⾮運⽤ コンテンツ更新 不要 運⽤ (⾮機能開発) 分断箇所は コミュニケーションに 課題あり
22 発⽣しうる問題 üPOが全てを 把握するのが ⼤変 üどちらが担 当なのかわか りづらい PO Area
PO Area PO
23 機能パートで分類 ログインボーナス プレゼント受け取り ガチャ 育成 クエスト 運⽤施策に 強く依存
24 その他コミュニケーションでカバー ü双⽅のPRレビュー ü週1回のお困りごとの共有 ü週1回の出来たものチェック üリアルのつながり ※ 絶賛改善中!
25 ここまでのまとめ ü良いチーム構成のために 課題を明らかにする ü課題がごちゃごちゃしてき たら、図で⽰して何が分断 されたのかを理解するとわ かりやすい
26 他社事例
27 Quipper社の例(改善前) toC toB ü エンジニア5~10⼈規模の頃は各々が全てのドメインを⾒ていたが、 各事業領域が⼤きく、ステークホルダーが増えるにつれて難しく なった ü ステークホルダーは誰に会話すれば良いかわからない
エンジニア
28 Quipper社の例(改善後) toC toB ü ドメインごとにチームを分割 ü ドメイン知識が深くなり、ステークホルダーとエンジニアの 信頼関係を構築しやすくなった ü
チーム横断の解決が難しくはなった Eng Eng Eng Eng Eng
29 toC toB 整合性 エンジニア ドメイン知識が 深くなる Quipper社の例(図解思考法)
30 エウレカ社の例(改善前) PJT A PJT B PJT C iOS Android
Web iOS Android Web iOS Android Web ü featureチーム ü プラットフォーム(PF: iOS/Android/Web)間の整合性を気にする あまり、PFごとの品質が上がらず
31 エウレカ社の例(改善後) PJT A PJT B PJT C iOS Android
Web CTO VPoP ü Componentチーム ü 各職能がPFごとのクオリティを⾼める ü 各職能のマネージャーはいろいろなPJTをふらふらする ü VPoPが最終アウトプットの整合性を担保する
32 iOS Android Web 整合性 整合性 プロダクトの整合性 VPoPや各職能のマネージャーが担保 エウレカ社の例(図解思考法)
33 某映像系会社の例(改善前) ü プロダクトに⼈をアサイン ü 個⼈のスキルでベストエフォート ü 兼任業務があるため同時着⼿が出来ず、全体的に優先順位が 最適化されていない プロダクト
A プロダクト B プロダクト C プロダクト D 鈴木さん 佐藤さん 田中さん
34 某映像系会社の例(改善後) ü 全体のプロダクトバックログを作成 ü 全体を⾒ているPOが負荷度合いを加味して、うまいこと振り分け ü 様々なタスクが降ってくるので、スキルが平準化 ü POの負荷が⾼い状態に
1. A向けの機能 2. B向けの改修 3. D向けの修正 4. A向けの改修 5. C向けの改修 PO Area PO1 Area PO2 PBL
35 良いチーム構成のためのポイント ü課題や達成したいことを 明らかにする ü⼀般論は参考にしかならない ü考えうるベストを採⽤する ü観察を怠らない ü変化を受け⼊れる
36