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

Transcript

1. 1.

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

2. 2.

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

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

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

4. 4.

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

5. 5.

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

6. 6.

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

7. 7.

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

8. 8.

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

9. 9.

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

10. 10.

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

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

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

12. 12.

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

13. 13.

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

14. 14.

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

15. 15.

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

    採⽤難易度？？
16. 16.

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

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

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

18. 18.

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

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

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

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

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

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

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

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

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

    PO Area PO
23. 23.

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

24. 24.

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

25. 25.

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

26. 26.

    26 他社事例

27. 27.

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

    エンジニア
28. 28.

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

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

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

30. 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.

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

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

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

33. 33.

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

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

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

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

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

36. 36.

    36