なんとなくチームを構成することから脱却する方法 / Clean Teams

by Yoshihiro Yunomae

Slide 1

Slide 1 text

なんとなくチームを構成することから脱却する⽅法アカツキ湯前慶⼤

Slide 2

Slide 2 text

2 湯前慶⼤(ゆのまえよしひろ) @yunon_phys ・2010~2014(電気メーカー) R & D of Linux カーネル・2014~(アカツキ) VP of Engineering プロジェクトマネージャー, スクラムマスター

Slide 3

Slide 3 text

3 良いチーム、作れていますか？

Slide 4

Slide 4 text

4 良いチーム構成、作れていますか？

Slide 5

Slide 5 text

5 チーム構成はトレードオフの関係

Slide 6

Slide 6 text

6 事例: アカツキのゲーム開発プロジェクト拠点A 拠点B 各拠点で閉じて開発するのが良いのか？混ぜて開発するのが良いのか？

Slide 7

Slide 7 text

7 ⽅向性の認識が合いやすいコミュニケーションコスト増⼤チーム間の整合性チームを分断すべきか、統合すべきかチーム内の認識すり合わせ

Slide 8

Slide 8 text

8 ⽅向性の認識が合いやすいコミュニケーションコスト増⼤チーム間の整合性チームを分断すべきか、統合すべきかチーム内の認識すり合わせ別の手段で担保

Slide 9

Slide 9 text

9 PO Area PO Area PO ü ユーザーストーリーをPO同⼠ですり合わせ、受け⼊れ基準の明確化 ü Howは各拠点に任せる

Slide 10

Slide 10 text

10 PO Area PO Area PO ü ユーザーストーリーをPO同⼠ですり合わせ、受け⼊れ条件の明確化 ü Howは各拠点に任せるしかし、これだけでは終わらなかった

Slide 11

Slide 11 text

11 ソーシャルゲームの特徴 üリリースしてからが本番

Slide 12

Slide 12 text

12 ソーシャルゲームの特徴 üリリースしてからが本番 ü運⽤はノウハウの塊

Slide 13

Slide 13 text

13 ソーシャルゲームの特徴 üリリースしてからが本番 ü運⽤はノウハウの塊 üバイナリアップデート⾟い

Slide 14

Slide 14 text

14 ソーシャルゲームの特徴 üリリースしてからが本番 ü運⽤はノウハウの塊 üバイナリアップデート⾟い üイケてない⾮機能が真綿で⾸を絞めてくる

Slide 15

Slide 15 text

15 考えなければいけないこと運⽤どちらがやる？開発項⽬どうわける？同じソースを触って問題がおきたらどうしよう⾮機能開発どちらがやる？採⽤難易度？？

Slide 16

Slide 16 text

16 コンテンツ更新必要コンテンツ更新不要ソースコード更新不要機能追加・改修非機能追加・改修バイナリ改修不要バイナリ改修必要バイナリ改修不要ひとまず観点整理(図解思考法)

Slide 17

Slide 17 text

17 運⽤の経験あり⼀から施策を考えた運⽤の経験なしこちらが運用を担当する

Slide 18

Slide 18 text

18 コンテンツ更新必要コンテンツ更新不要ソースコード更新不要機能追加・改修非機能追加・改修バイナリ改修不要バイナリ改修必要バイナリ改修不要運⽤⾮運⽤

Slide 19

Slide 19 text

19 コンテンツ更新必要コンテンツ更新不要ソースコード更新不要機能追加・改修非機能追加・改修バイナリ改修不要バイナリ改修必要バイナリ改修不要運⽤⾮運⽤実は運用経験に深く関わりがある

Slide 20

Slide 20 text

20 コンテンツ更新必要コンテンツ更新不要ソースコード更新不要機能追加・改修非機能追加・改修バイナリ改修不要バイナリ改修必要バイナリ改修不要運⽤⾮運⽤コンテンツ更新不要運⽤ (⾮機能開発) 運用チームにスイッチ

Slide 21

Slide 21 text

21 コンテンツ更新必要コンテンツ更新不要ソースコード更新不要機能追加・改修非機能追加・改修バイナリ改修不要バイナリ改修必要バイナリ改修不要運⽤⾮運⽤コンテンツ更新不要運⽤ (⾮機能開発) 分断箇所はコミュニケーションに課題あり

Slide 22

Slide 22 text

22 発⽣しうる問題 üPOが全てを把握するのが⼤変 üどちらが担当なのかわかりづらい PO Area PO Area PO

Slide 23

Slide 23 text

23 機能パートで分類ログインボーナスプレゼント受け取りガチャ育成クエスト運⽤施策に強く依存

Slide 24

Slide 24 text

24 その他コミュニケーションでカバー ü双⽅のPRレビュー ü週1回のお困りごとの共有 ü週1回の出来たものチェック üリアルのつながり ※ 絶賛改善中！

Slide 25

Slide 25 text

25 ここまでのまとめ ü良いチーム構成のために課題を明らかにする ü課題がごちゃごちゃしてきたら、図で⽰して何が分断されたのかを理解するとわかりやすい

Slide 26

Slide 26 text

26 他社事例

Slide 27

Slide 27 text

27 Quipper社の例(改善前) toC toB ü エンジニア5~10⼈規模の頃は各々が全てのドメインを⾒ていたが、各事業領域が⼤きく、ステークホルダーが増えるにつれて難しくなった ü ステークホルダーは誰に会話すれば良いかわからないエンジニア

Slide 28

Slide 28 text

28 Quipper社の例(改善後) toC toB ü ドメインごとにチームを分割 ü ドメイン知識が深くなり、ステークホルダーとエンジニアの信頼関係を構築しやすくなった ü チーム横断の解決が難しくはなった Eng Eng Eng Eng Eng

Slide 29

Slide 29 text

29 toC toB 整合性エンジニアドメイン知識が深くなる Quipper社の例(図解思考法)

Slide 30

Slide 30 text

30 エウレカ社の例(改善前) PJT A PJT B PJT C iOS Android Web iOS Android Web iOS Android Web ü featureチーム ü プラットフォーム(PF: iOS/Android/Web)間の整合性を気にするあまり、PFごとの品質が上がらず

Slide 31

Slide 31 text

31 エウレカ社の例(改善後) PJT A PJT B PJT C iOS Android Web CTO VPoP ü Componentチーム ü 各職能がPFごとのクオリティを⾼める ü 各職能のマネージャーはいろいろなPJTをふらふらする ü VPoPが最終アウトプットの整合性を担保する

Slide 32

Slide 32 text

32 iOS Android Web 整合性整合性プロダクトの整合性 VPoPや各職能のマネージャーが担保エウレカ社の例(図解思考法)

Slide 33

Slide 33 text

33 某映像系会社の例(改善前) ü プロダクトに⼈をアサイン ü 個⼈のスキルでベストエフォート ü 兼任業務があるため同時着⼿が出来ず、全体的に優先順位が最適化されていないプロダクト A プロダクト B プロダクト C プロダクト D 鈴木さん佐藤さん田中さん

Slide 34

Slide 34 text

34 某映像系会社の例(改善後) ü 全体のプロダクトバックログを作成 ü 全体を⾒ているPOが負荷度合いを加味して、うまいこと振り分け ü 様々なタスクが降ってくるので、スキルが平準化 ü POの負荷が⾼い状態に 1. A向けの機能 2. B向けの改修 3. D向けの修正 4. A向けの改修 5. C向けの改修 PO Area PO1 Area PO2 PBL

Slide 35

Slide 35 text

35 良いチーム構成のためのポイント ü課題や達成したいことを明らかにする ü⼀般論は参考にしかならない ü考えうるベストを採⽤する ü観察を怠らない ü変化を受け⼊れる