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

2019.10.31に開催されたEngineering Organization Festival(EOF) 2019で発表に使った資料です

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

26. 26
    他社事例
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

36. View Slide