$30 off During Our Annual Pro Sale. View Details »

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

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

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

Yoshihiro Yunomae

October 31, 2019
Tweet

More Decks by Yoshihiro Yunomae

Other Decks in Technology

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

    View Slide