開発チームにオーナーシップを委譲する手法 - DevOpsDays TOKYO 2022 #DevOpsDaysTokyo

https://confengine.com/conferences/devopsdays-tokyo-2022/proposal/16421

Transcript

1. © Chatwork
   開発チームに
   
   
   オーナーシップを
   
   
   委譲するという手法
   プロダクト基盤開発部　尾崎 耕多
   2022年04月22日
   DevOpsDays Tokyo 2022
   

   View Slide

2. Profile
   ࣗݾ঺հ
   Kouta Ozaki
   SRE
   
   
   DevOps Engineer
   
   
   Rust Engineer
   k_kinzal k_kinzal
   

   View Slide

3. 前提の話
   1
   DevOpsDays
   Tokyo 2022
   

   View Slide

4. 4
   Chatworkとは
   ޮ཰తʹ৘ใڞ༗Ͱ͖Δ
   άϧʔϓνϟοτ
   ࢓ࣄͷݟ͑ΔԽ͕Ͱ͖Δ
   λεΫ؅ཧ
   ݟམͱ͕͠ͳ͘ͳΔ
   ϑΝΠϧ؅ཧ
   ͍ͭͰ΋ձ͕ٞͰ͖Δ
   ϏσΦ/Ի੠௨࿩
   

   View Slide

5. 5
   Chatworkは利用者数No.1*のビジネスチャット
   3݄
   ϦϦʔε
   10ສࣾ

   ಥഁʂ
   20ສࣾ

   ಥഁʂ
   30ສࣾ

   ಥഁʂ
   ಋೖࣾ਺34ສ3000ࣾҎ্ʂ
   (2021೥12݄຤೔࣌఺)
   

   View Slide

6. Chatworkと競合の機能リリース比較
   6
   Chatwork Aࣾ Bࣾ Cࣾ
   

   View Slide

7. ChatworkのPRのリリース数と開発チームの人数の相関
   7
   0
   22.5
   45
   67.5
   90
   2014 2015 2016 2017 2018 2019 2020 2021 2022
   ϦϦʔε਺ ਓ਺
   

   View Slide

8. 2010
   Chatworkのチームの変遷
   2011
   2014
   2017
   2019
   First Team Web1
   Web2 Mobile
   PM
   PHP
   Scala
   SRE
   Secur
   Frontend
   8
   

   View Slide

9. Project
   プロジェクト型の開発体制によるオーナーシップの欠如
   9
   PM
   PHP
   Frontend
   iOS
   Android
   Design
   

   View Slide

10. コミュニケーションパスの複雑化によるオーナーシップの欠如
    10
    Scala1
    PHP1
    PM
    PHP2
    SRE Security
    Design
    Mobile
    Customer
    
    Support
    Scala2
    CEO
    Frontend
    

    View Slide

11. チーム間のシステム共有によるオーナーシップの欠如
    11
    SRE
    PHP Scala1 Scala2 Scala10
    PHP2
    PHP1 Scala1 Scala2
    

    View Slide

12. 12
    前提のまとめ
    • 機能開発の速度はSaaSを提供している企業として重要
    
    
    • しかしChatworkの開発速度をあげきれてない
    
    
    • 要因として職能組織としてスケールしたというのがあるかも
    その結果として開発のオーナーシップを取りづらくなった
    

    View Slide

13. 開発速度を取り戻すための次世代開発基盤
    2
    DevOpsDays
    Tokyo 2022
    

    View Slide

14. 次世代開発基盤のゴール
    14
    2025年の事業計画に合わせて
    
    
    生産性を維持・向上できる
    
    
    プロダクトと組織を構築する
    

    View Slide

15. 次世代開発基盤
    15
    Account
    Account
    Message
    Message
    Task
    Task
    File
    File
    ɹ PM
    
    ɹ Backend
    
    ɹ Frontend
    
    ɹ Mobile
    
    ɹ Design
    
    ɹ SRE
    横断チーム
    

    View Slide

16. 横断型のチームの必要性と構造
    3
    DevOpsDays
    Tokyo 2022
    

    View Slide

17. 横断チームの必要性
    17
    セキュリティ 専門知識
    全体最適
    機能チームだけでは解決できない課題がある
    

    View Slide

18. 横断チームの難しさ
    18
    Dev
    　　　　ユーザーに価値を届け続けること
    横断チーム
    目的
    　　　　専門のミッションを達成すること
    目的
    

    View Slide

19. 横断チームの形
    19
    Dev
    GateKeeper
    Supporter
    PaaS
    Guild
    

    View Slide

20. 横断チームの形
    20
    Dev
    GateKeeper
    • 専門領域に対して全オーナーシップを持つチーム
    
    
    • 開発チームからの依頼をベースに作業を行う
    
    
    • 専門知識の集約を行うため質の高いアウトプットを出しやすい
    
    
    • 代わりにチームのスケーラビリティを確保できないとボトルネックに
    なりやすい性質がある
    ゲートキーパー型のチーム
    

    View Slide

21. 21
    Dev PaaS
    • サービスを提供して専門領域のオーナーシップを持つチーム
    
    
    • ゲートキーパーと違い、APIをベースにしたコミュニケーション
    を行うためボトルネックが発生しづらい
    
    
    • エンジニア的に夢と希望に満ち溢れたチームの形
    横断チームの形
    社内PaaS型のチーム
    夢って叶わないよね
    

    View Slide

22. 22
    Supporter
    Dev
    • 開発チームを支援するチーム
    
    
    • このチームは機能開発には関わらず、開発チームが機能開発の
    全オーナーシップを持つ
    
    
    • 代わりに機能開発に必要なことを支援する
    
    
    • 知識
    
    
    • 仕組み
    サポーター型のチーム
    横断チームの形
    

    View Slide

23. 23
    Guild
    Dev
    • 開発チームの特定のロールの集まったバーチャルなチーム
    
    
    • このチームは機能開発には関わらず、開発チームが機能開発の全オー
    ナーシップを持つ
    
    
    • 横断的な課題の解決や、寄合所としてチーム間の情報共有や相談を行う
    
    
    • 完全にバーチャルな組織にすると推進力に欠ける可能性がある
    横断チームの形
    ギルド型のチーム
    

    View Slide

24. 次世代開発基盤チームとしての選択
    24
    Dev Supporter
    • 開発者にオーナーシップを集約するという意味ではサポーター型の
    チームが適している
    
    
    • あくまでも現時点での方向性としての選択になる
    
    
    • 必要があれば他の形のチームを選択する可能性はある
    

    View Slide

25. DevOpsとガードレール
    4
    DevOpsDays
    Tokyo 2022
    

    View Slide

26. DevOpsとガードレール
    26
    Dev
    System
    Supporter
    機能開発を行うのはあくまでも開発チーム。
    
    
    サポーター型のチームは直接、機能開発をおこなってシステムを触ることはしない。
    

    View Slide

27. DevOpsとガードレール
    27
    Dev
    Supporter
    System
    Create Create
    DevOps & Guardrail
    Support & Feedback Monitor
    Guardrail
    

    View Slide

28. 実際の取り組み
    5
    DevOpsDays
    Tokyo 2022
    

    View Slide

29. 土台としてのAWSアカウントの整備
    AWS
    master
    Audit
    App1
    App2
    App3
    ҕৡ
    ҕৡ
    ؂ࠪઃఆͷ༗ޮԽ
    ؂ࠪϩάͷऩू
    AWSΞΧ΢ϯτͷ
    ࡞੒
    Dev1
    Dev2
    Dev3
    ԣஅνʔϜ1
    ԣஅνʔϜ2
    29
    

    View Slide

30. AWS
    DevOpsとしてのIaCのCD構築
    GitHub
    Atlantis
    App1
    App2
    App2
    横断チーム
    Create
    Dev
    Commit
    Apply
    30
    

    View Slide

31. DevOpsとガードレールとしてのSSOとIaC化
    GitHub
    master
    Dev
    SSO Provider
    App
    横断チーム
    Commit Policy
    Login with SSO
    Sync
    Apply
    Create
    31
    

    View Slide

32. Kubernetes
    DevOpsとしてArgoCDを使ったGitOpsの構築
    ԣஅνʔϜ
    32
    GitHub
    Dev
    System
    Commit
    Sync
    Create
    ArgoCD
    

    View Slide

33. Kubernetes
    ガードレールとしてOPAでのマニフェスト制限
    横断チーム
    Dev
    System
    Commit
    Create
    GitHub
    Conftest
    GitHub
    Pull Policy
    Commit Policy
    Apply
    33
    Gatekeeper
    

    View Slide

34. DevOpsとしてRDBの一時ユーザー発行
    34
    Vault
    Proxy
    Dev
    Create Temporary User
    Get User
    横断チーム
    Create
    RDB
    

    View Slide

35. Kubernetes
    DevOpsとしてのRDBのスキーマ変更
    35
    Self Hoster
    
    Runner
    Change Schema
    GitHub
    Dev
    Run CI
    ԣஅνʔϜ
    Create
    RDB
    

    View Slide

36. 取り組んだ結果どうなったか
    36
    • まずは開発者が”できる”ようになることを重視
    
    
    • ガードレールはまだすべてを作りきれてない
    
    
    • 結果として今は開発チームがオーナーシップを発揮してる
    
    
    • もうちょっとフェーズが進むとガードレールがないことによ
    る失敗によって開発速度の低下が起きそうなのでガードレー
    ル作りちまちまやってく
    

    View Slide

37. 時間があれば雑談
    37
    1. この道は正しいのかどうか
    
    
    • 開発チームに求められるスキルセットがえぐい
    
    
    • チームトポロジー
    
    
    • DevOpsパターン
    
    
    2. 理想の組織として変化し続けるために必要な方法
    
    
    3. Dev vs Ops
    
    
    4. DevOpsはDev主導の方がうまくいく？
    

    View Slide

38. まとめ
    6
    DevOpsDays
    Tokyo 2022
    

    View Slide

39. まとめ
    39
    • 問題→要因→解決方法の選択→問題解決
    
    
    • 問題解決の方法自体は何もすごいことはない
    
    
    • 泥臭くコツコツやってるだけ
    
    
    • 銀の弾丸はない
    
    
    • ベストプラクティスと呼ばれるものは優秀
    

    View Slide

40. まとめ
    40
    40
    

    View Slide

41. View Slide