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.2k
アカツキの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.5k
Engineering Managerの役割を再定義してみる / Redefinition of Engineering Manager Role
yunon_phys
4
3.1k
技術書典で本を出すまでのジャーニー
yunon_phys
1
320
Other Decks in Technology
See All in Technology
Green Tea Garbage Collector の今
zchee
PRO
2
360
あなたのWebサービスはAIに自動テストしてもらえる?アクセシビリティツリーで読み解く、AIの『視点』
yusukeiwaki
1
3.4k
今日から始めるpprof / Pprof workshop for beginners
ymotongpoo
6
780
Goのビルドシステムの変遷 / The history of Go's build system
ymotongpoo
12
3.5k
組織観点からIAM Identity CenterとIAMの設計を考える
nrinetcom
PRO
1
130
FastAPIの魔法をgRPC/Connect RPCへ
monotaro
PRO
0
490
生成AIを活用したZennの取り組み事例
ryosukeigarashi
0
170
ユニットテストに対する考え方の変遷 / Everyone should watch his live coding
mdstoy
0
110
AIを導⼊しても、 開発⽣産性は"爆増"していない なぜ?
kinosuke01
4
3.6k
サプライチェーン攻撃に学ぶModuleの仕組みと セキュリティ対策
kuro_kurorrr
3
790
全てGoで作るP2P対戦ゲーム入門
ponyo877
3
1.2k
C# 14 / .NET 10 の新機能 (RC 1 時点)
nenonaninu
1
1.3k
Featured
See All Featured
The Power of CSS Pseudo Elements
geoffreycrofte
78
6k
How GitHub (no longer) Works
holman
315
140k
The World Runs on Bad Software
bkeepers
PRO
71
11k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
What's in a price? How to price your products and services
michaelherold
246
12k
Become a Pro
speakerdeck
PRO
29
5.5k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.1k
Balancing Empowerment & Direction
lara
4
660
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1.2k
Mobile First: as difficult as doing things right
swwweet
224
9.9k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
9
840
Embracing the Ebb and Flow
colly
88
4.8k
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