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

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

Transcript

1. © Chatwork 開発チームに オーナーシップを 委譲するという手法 プロダクト基盤開発部　尾崎 耕多 2022年04月22日 DevOpsDays Tokyo 2022
2. Profile ࣗݾ঺հ Kouta Ozaki SRE DevOps Engineer Rust Engineer k_kinzal k_kinzal
3. 前提の話 1 DevOpsDays Tokyo 2022
4. 4 Chatworkとは ޮ཰తʹ৘ใڞ༗Ͱ͖Δ άϧʔϓνϟοτ ࢓ࣄͷݟ͑ΔԽ͕Ͱ͖Δ λεΫ؅ཧ ݟམͱ͕͠ͳ͘ͳΔ ϑΝΠϧ؅ཧ ͍ͭͰ΋ձ͕ٞͰ͖Δ ϏσΦ/Ի੠௨࿩
5. 5 Chatworkは利用者数No.1*のビジネスチャット 3݄ ϦϦʔε 10ສࣾ
 ಥഁʂ 20ສࣾ
 ಥഁʂ 30ສࣾ
 ಥഁʂ ಋೖࣾ਺34ສ3000ࣾҎ্ʂ (2021೥12݄຤೔࣌఺)
6. Chatworkと競合の機能リリース比較 6 Chatwork Aࣾ Bࣾ Cࣾ
7. ChatworkのPRのリリース数と開発チームの人数の相関 7 0 22.5 45 67.5 90 2014 2015 2016 2017 2018 2019 2020 2021 2022 ϦϦʔε਺ ਓ਺
8. 2010 Chatworkのチームの変遷 2011 2014 2017 2019 First Team Web1 Web2 Mobile PM PHP Scala SRE Secur Frontend 8
9. Project プロジェクト型の開発体制によるオーナーシップの欠如 9 PM PHP Frontend iOS Android Design
10. コミュニケーションパスの複雑化によるオーナーシップの欠如 10 Scala1 PHP1 PM PHP2 SRE Security Design Mobile Customer Support Scala2 CEO Frontend
11. チーム間のシステム共有によるオーナーシップの欠如 11 SRE PHP Scala1 Scala2 Scala10 PHP2 PHP1 Scala1 Scala2
12. 12 前提のまとめ • 機能開発の速度はSaaSを提供している企業として重要 • しかしChatworkの開発速度をあげきれてない • 要因として職能組織としてスケールしたというのがあるかも その結果として開発のオーナーシップを取りづらくなった
13. 開発速度を取り戻すための次世代開発基盤 2 DevOpsDays Tokyo 2022
14. 次世代開発基盤のゴール 14 2025年の事業計画に合わせて 生産性を維持・向上できる プロダクトと組織を構築する
15. 次世代開発基盤 15 Account Account Message Message Task Task File File ɹ PM ɹ Backend ɹ Frontend ɹ Mobile ɹ Design ɹ SRE 横断チーム
16. 横断型のチームの必要性と構造 3 DevOpsDays Tokyo 2022
17. 横断チームの必要性 17 セキュリティ 専門知識 全体最適 機能チームだけでは解決できない課題がある
18. 横断チームの難しさ 18 Dev 　　　　ユーザーに価値を届け続けること 横断チーム 目的 　　　　専門のミッションを達成すること 目的
19. 横断チームの形 19 Dev GateKeeper Supporter PaaS Guild
20. 横断チームの形 20 Dev GateKeeper • 専門領域に対して全オーナーシップを持つチーム • 開発チームからの依頼をベースに作業を行う • 専門知識の集約を行うため質の高いアウトプットを出しやすい • 代わりにチームのスケーラビリティを確保できないとボトルネックに なりやすい性質がある ゲートキーパー型のチーム
21. 21 Dev PaaS • サービスを提供して専門領域のオーナーシップを持つチーム • ゲートキーパーと違い、APIをベースにしたコミュニケーション を行うためボトルネックが発生しづらい • エンジニア的に夢と希望に満ち溢れたチームの形 横断チームの形 社内PaaS型のチーム 夢って叶わないよね
22. 22 Supporter Dev • 開発チームを支援するチーム • このチームは機能開発には関わらず、開発チームが機能開発の 全オーナーシップを持つ • 代わりに機能開発に必要なことを支援する • 知識 • 仕組み サポーター型のチーム 横断チームの形
23. 23 Guild Dev • 開発チームの特定のロールの集まったバーチャルなチーム • このチームは機能開発には関わらず、開発チームが機能開発の全オー ナーシップを持つ • 横断的な課題の解決や、寄合所としてチーム間の情報共有や相談を行う • 完全にバーチャルな組織にすると推進力に欠ける可能性がある 横断チームの形 ギルド型のチーム
24. 次世代開発基盤チームとしての選択 24 Dev Supporter • 開発者にオーナーシップを集約するという意味ではサポーター型の チームが適している • あくまでも現時点での方向性としての選択になる • 必要があれば他の形のチームを選択する可能性はある
25. DevOpsとガードレール 4 DevOpsDays Tokyo 2022
26. DevOpsとガードレール 26 Dev System Supporter 機能開発を行うのはあくまでも開発チーム。 サポーター型のチームは直接、機能開発をおこなってシステムを触ることはしない。
27. DevOpsとガードレール 27 Dev Supporter System Create Create DevOps & Guardrail Support & Feedback Monitor Guardrail
28. 実際の取り組み 5 DevOpsDays Tokyo 2022
29. 土台としてのAWSアカウントの整備 AWS master Audit App1 App2 App3 ҕৡ ҕৡ ؂ࠪઃఆͷ༗ޮԽ ؂ࠪϩάͷऩू AWSΞΧ΢ϯτͷ ࡞੒ Dev1 Dev2 Dev3 ԣஅνʔϜ1 ԣஅνʔϜ2 29
30. AWS DevOpsとしてのIaCのCD構築 GitHub Atlantis App1 App2 App2 横断チーム Create Dev Commit Apply 30
31. DevOpsとガードレールとしてのSSOとIaC化 GitHub master Dev SSO Provider App 横断チーム Commit Policy Login with SSO Sync Apply Create 31
32. Kubernetes DevOpsとしてArgoCDを使ったGitOpsの構築 ԣஅνʔϜ 32 GitHub Dev System Commit Sync Create ArgoCD
33. Kubernetes ガードレールとしてOPAでのマニフェスト制限 横断チーム Dev System Commit Create GitHub Conftest GitHub Pull Policy Commit Policy Apply 33 Gatekeeper
34. DevOpsとしてRDBの一時ユーザー発行 34 Vault Proxy Dev Create Temporary User Get User 横断チーム Create RDB
35. Kubernetes DevOpsとしてのRDBのスキーマ変更 35 Self Hoster Runner Change Schema GitHub Dev Run CI ԣஅνʔϜ Create RDB
36. 取り組んだ結果どうなったか 36 • まずは開発者が”できる”ようになることを重視 • ガードレールはまだすべてを作りきれてない • 結果として今は開発チームがオーナーシップを発揮してる • もうちょっとフェーズが進むとガードレールがないことによ る失敗によって開発速度の低下が起きそうなのでガードレー ル作りちまちまやってく
37. 時間があれば雑談 37 1. この道は正しいのかどうか • 開発チームに求められるスキルセットがえぐい • チームトポロジー • DevOpsパターン 2. 理想の組織として変化し続けるために必要な方法 3. Dev vs Ops 4. DevOpsはDev主導の方がうまくいく？
38. まとめ 6 DevOpsDays Tokyo 2022
39. まとめ 39 • 問題→要因→解決方法の選択→問題解決 • 問題解決の方法自体は何もすごいことはない • 泥臭くコツコツやってるだけ • 銀の弾丸はない • ベストプラクティスと呼ばれるものは優秀
40. まとめ 40 40