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.2k
なんとなくチームを構成することから脱却する方法 / 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.6k
ゲーム事業を持続成長させる組織をつくる / Game Organization in Akatsuki
yunon_phys
1
1k
アカツキにおける チーム経営の取り組み / Executive Leadership Team in Akatsuki
yunon_phys
5
6.4k
アカツキのEngineering Managerは何をする人なのか / What is an EM in Akatsuki?
yunon_phys
7
2k
Engineering Managerは何をする人なのか/ What are Roles of Engineering Managers?
yunon_phys
2
11k
キャリア形成に必要なのは、ただ飛び込むという勇気だけだった / My Career DevLOVE X
yunon_phys
9
11k
運用中のモバイルゲーム開発チームに、 並行バージョン開発を導入してみた/RSGT2019
yunon_phys
5
8.9k
Engineering Managerの役割を再定義してみる / Redefinition of Engineering Manager Role
yunon_phys
4
2.9k
技術書典で本を出すまでのジャーニー
yunon_phys
1
270
Other Decks in Technology
See All in Technology
ロボットアームを遠隔制御の話 & LLMをつかったIoTの話もしたい
soracom
PRO
1
380
エンジニア視点で見る、 組織で運用されるデザインシステムにするには
shunya078
1
300
Jetpack Compose Modifier 徹底解説 / Jetpack Compose Modifier
wiroha
0
180
リアルお遍路+SORACOM IoT
ozk009
1
130
React Aria で実現する次世代のアクセシビリティ
ryo_manba
4
1.2k
Mocking in Rust Applications
taiki45
1
410
OSTという文化を組織に根付かせてみた
sansantech
PRO
2
290
なにもしてないのにNew Relicのデータ転送量が増えていたときに確認したこと
tk3fftk
2
220
忙しい人のためのLangGraph概要まとめ
__ymgc__
1
170
20240911_New_Relicダッシュボード活用例
speakerdeckfk
0
100
『GRANBLUE FANTASY Relink』ソフトウェアラスタライザによる実践的なオクルージョンカリング
cygames
0
140
DuckDB雑紹介(1.1対応版)@DuckDB座談会
ktz
6
1.4k
Featured
See All Featured
Atom: Resistance is Futile
akmur
261
25k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
24
610
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
8.9k
For a Future-Friendly Web
brad_frost
174
9.3k
Building a Scalable Design System with Sketch
lauravandoore
458
32k
Building Better People: How to give real-time feedback that sticks.
wjessup
359
19k
Faster Mobile Websites
deanohume
304
30k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
32k
Music & Morning Musume
bryan
46
6k
Large-scale JavaScript Application Architecture
addyosmani
508
110k
A better future with KSS
kneath
235
17k
Designing for Performance
lara
604
68k
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