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

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

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

3a4e9f8c3cb529de8b1ac11fadb45d3d?s=128

Yoshihiro Yunomae

October 31, 2019
Tweet

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