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
6.9k
なんとなくチームを構成することから脱却する方法 / 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.4k
ゲーム事業を持続成長させる組織をつくる / Game Organization in Akatsuki
yunon_phys
1
980
アカツキにおける チーム経営の取り組み / Executive Leadership Team in Akatsuki
yunon_phys
5
6.1k
アカツキのEngineering Managerは何をする人なのか / What is an EM in Akatsuki?
yunon_phys
7
1.8k
Engineering Managerは何をする人なのか/ What are Roles of Engineering Managers?
yunon_phys
2
9.7k
キャリア形成に必要なのは、ただ飛び込むという勇気だけだった / My Career DevLOVE X
yunon_phys
9
11k
運用中のモバイルゲーム開発チームに、 並行バージョン開発を導入してみた/RSGT2019
yunon_phys
5
8.4k
Engineering Managerの役割を再定義してみる / Redefinition of Engineering Manager Role
yunon_phys
4
2.9k
技術書典で本を出すまでのジャーニー
yunon_phys
1
240
Other Decks in Technology
See All in Technology
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
4
34k
プレイヤーとしてのチームのテスト力UP/Improving team skills for testing
goyoki
2
220
マルチテナントの実現におけるDB設計とRLS / Utilizing RSL in multi-tenancy
soudai
20
5k
実録_マルチテナント環境でのGmailガイドライン対応
ryuichi1208
7
1.5k
サイボウズのQAエンジニア育成
cybozuinsideout
PRO
3
550
進化する事業とデータ構造 ~Cloudbaseの場合~
tockn
2
220
マイクロサービスを横断したGoのコードレビュー
yuyu_hf
PRO
1
120
SecurityCamp2023基板作るコース講義資料/Security Camp 2023 Lecture Materials
tnishinaga
5
1.3k
Node-AI のリッチな WEB フロントエンドを支える技術
nenonaninu
2
960
JaSST_Tokyo経験発表_20240313.pdf
ktanizaki
0
190
【OpenAI本出版記念】npakaによるOpenAI最新技術情報と技術情報キャッチアップ術
npaka
8
1.4k
庁舎DX推進事例集
senryakuka
0
1.5k
Featured
See All Featured
A Tale of Four Properties
chriscoyier
150
22k
Keith and Marios Guide to Fast Websites
keithpitt
407
22k
How STYLIGHT went responsive
nonsquared
92
4.7k
Into the Great Unknown - MozCon
thekraken
10
810
Build The Right Thing And Hit Your Dates
maggiecrowley
23
1.9k
Designing with Data
zakiwarfel
94
4.8k
Unsuck your backbone
ammeep
660
56k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
101
6.6k
Visualization
eitanlees
135
14k
Why You Should Never Use an ORM
jnunemaker
PRO
50
8.5k
RailsConf 2023
tenderlove
0
500
The Language of Interfaces
destraynor
150
22k
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