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

Transcript

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

2. 2 湯前 慶⼤(ゆのまえ よしひろ) @yunon_phys ・2010~2014(電気メーカー) R & D of

   Linux カーネル ・2014~(アカツキ) VP of Engineering プロジェクトマネージャー, スクラムマスター

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

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

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

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

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

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

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

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

    しかし、これだけでは終わらなかった

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

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

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

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

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

    採⽤難易度？？

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

    バイナリ改修必要 バイナリ 改修不要 ひとまず観点整理(図解思考法)

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

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

    バイナリ改修必要 バイナリ 改修不要 運⽤ ⾮運⽤

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

    バイナリ改修必要 バイナリ 改修不要 運⽤ ⾮運⽤ 実は運用経験に深く 関わりがある

20. 20 コンテンツ更新必要 コンテ ンツ更 新不 要 ソース コード 更新不要 機能追加・改修

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

21. 21 コンテンツ更新必要 コンテ ンツ更 新不 要 ソース コード 更新不要 機能追加・改修

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

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

    PO Area PO

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

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

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

26. 26 他社事例

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

    エンジニア

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

    チーム横断の解決が難しくはなった Eng Eng Eng Eng Eng

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

30. 30 エウレカ社の例(改善前) PJT A PJT B PJT C iOS Android

    Web iOS Android Web iOS Android Web ü featureチーム ü プラットフォーム(PF: iOS/Android/Web)間の整合性を気にする あまり、PFごとの品質が上がらず

31. 31 エウレカ社の例(改善後) PJT A PJT B PJT C iOS Android

    Web CTO VPoP ü Componentチーム ü 各職能がPFごとのクオリティを⾼める ü 各職能のマネージャーはいろいろなPJTをふらふらする ü VPoPが最終アウトプットの整合性を担保する

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

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

    A プロダクト B プロダクト C プロダクト D 鈴木さん 佐藤さん 田中さん

34. 34 某映像系会社の例(改善後) ü 全体のプロダクトバックログを作成 ü 全体を⾒ているPOが負荷度合いを加味して、うまいこと振り分け ü 様々なタスクが降ってくるので、スキルが平準化 ü POの負荷が⾼い状態に

    1. A向けの機能 2. B向けの改修 3. D向けの修正 4. A向けの改修 5. C向けの改修 PO Area PO1 Area PO2 PBL

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

36. 36