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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

前提の話 1 DevOpsDays Tokyo 2022

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

5 Chatworkは利用者数No.1*のビジネスチャット 3݄ ϦϦʔε 10ສࣾ  ಥഁʂ 20ສࣾ  ಥഁʂ 30ສࣾ  ಥഁʂ ಋೖࣾ਺34ສ3000ࣾҎ্ʂ (2021೥12݄຤೔࣌఺)

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

実際の取り組み 5 DevOpsDays Tokyo 2022

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

まとめ 6 DevOpsDays Tokyo 2022

Slide 39

Slide 39 text

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