Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
開発チームにオーナーシップを委譲する手法 - DevOpsDays TOKYO 2022 #D...
Search
Kouta Ozaki
April 22, 2022
0
290
開発チームにオーナーシップを委譲する手法 - DevOpsDays TOKYO 2022 #DevOpsDaysTokyo
https://confengine.com/conferences/devopsdays-tokyo-2022/proposal/16421
Kouta Ozaki
April 22, 2022
Tweet
Share
More Decks by Kouta Ozaki
See All by Kouta Ozaki
サーバーレスを採用すべき100の理由(1つしか話さないよ)
cwozaki
3
460
Helm Chartリポジトリを2年半運用してわかったいろいろな話 - CloudNative Days Spring 2021 ONLINE #CNDO2021
cwozaki
0
530
PHP on Kubernetes - PHP Conference 2020 Re:born #phpcon
cwozaki
1
8.1k
AWS DevDay 2020 - C-8: レジェンドシステムをEC2からKubernetesに置き換える戦い #AWSDevDay
cwozaki
0
1.6k
ChatworkにおけるレジェンドシステムのKubernetes化の取り組み #containerdaysjp #meetup
cwozaki
1
2.9k
チャットワークにおける サーバーレス活用術 / Serverless at ChatWork
cwozaki
1
1.6k
Featured
See All Featured
The Pragmatic Product Professional
lauravandoore
31
6.3k
Visualization
eitanlees
144
15k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
A Philosophy of Restraint
colly
203
16k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.2k
The Language of Interfaces
destraynor
154
24k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
The Cost Of JavaScript in 2023
addyosmani
45
6.6k
Documentation Writing (for coders)
carmenintech
65
4.4k
What's new in Ruby 2.0
geeforr
342
31k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
250
21k
Transcript
© Chatwork 開発チームに オーナーシップを 委譲するという手法 プロダクト基盤開発部 尾崎 耕多 2022年04月22日 DevOpsDays Tokyo
2022
Profile ࣗݾհ Kouta Ozaki SRE DevOps Engineer Rust Engineer k_kinzal
k_kinzal
前提の話 1 DevOpsDays Tokyo 2022
4 Chatworkとは ޮతʹใڞ༗Ͱ͖Δ άϧʔϓνϟοτ ࣄͷݟ͑ΔԽ͕Ͱ͖Δ λεΫཧ ݟམͱ͕͠ͳ͘ͳΔ ϑΝΠϧཧ ͍ͭͰձ͕ٞͰ͖Δ ϏσΦ/Ի௨
5 Chatworkは利用者数No.1*のビジネスチャット 3݄ ϦϦʔε 10ສࣾ ಥഁʂ 20ສࣾ ಥഁʂ 30ສࣾ ಥഁʂ
ಋೖࣾ34ສ3000ࣾҎ্ʂ (202112݄࣌)
Chatworkと競合の機能リリース比較 6 Chatwork Aࣾ Bࣾ Cࣾ
ChatworkのPRのリリース数と開発チームの人数の相関 7 0 22.5 45 67.5 90 2014 2015 2016
2017 2018 2019 2020 2021 2022 ϦϦʔε ਓ
2010 Chatworkのチームの変遷 2011 2014 2017 2019 First Team Web1 Web2
Mobile PM PHP Scala SRE Secur Frontend 8
Project プロジェクト型の開発体制によるオーナーシップの欠如 9 PM PHP Frontend iOS Android Design
コミュニケーションパスの複雑化によるオーナーシップの欠如 10 Scala1 PHP1 PM PHP2 SRE Security Design Mobile
Customer Support Scala2 CEO Frontend
チーム間のシステム共有によるオーナーシップの欠如 11 SRE PHP Scala1 Scala2 Scala10 PHP2 PHP1 Scala1
Scala2
12 前提のまとめ • 機能開発の速度はSaaSを提供している企業として重要 • しかしChatworkの開発速度をあげきれてない • 要因として職能組織としてスケールしたというのがあるかも その結果として開発のオーナーシップを取りづらくなった
開発速度を取り戻すための次世代開発基盤 2 DevOpsDays Tokyo 2022
次世代開発基盤のゴール 14 2025年の事業計画に合わせて 生産性を維持・向上できる プロダクトと組織を構築する
次世代開発基盤 15 Account Account Message Message Task Task File File
ɹ PM ɹ Backend ɹ Frontend ɹ Mobile ɹ Design ɹ SRE 横断チーム
横断型のチームの必要性と構造 3 DevOpsDays Tokyo 2022
横断チームの必要性 17 セキュリティ 専門知識 全体最適 機能チームだけでは解決できない課題がある
横断チームの難しさ 18 Dev ユーザーに価値を届け続けること 横断チーム 目的 専門のミッションを達成すること 目的
横断チームの形 19 Dev GateKeeper Supporter PaaS Guild
横断チームの形 20 Dev GateKeeper • 専門領域に対して全オーナーシップを持つチーム • 開発チームからの依頼をベースに作業を行う • 専門知識の集約を行うため質の高いアウトプットを出しやすい
• 代わりにチームのスケーラビリティを確保できないとボトルネックに なりやすい性質がある ゲートキーパー型のチーム
21 Dev PaaS • サービスを提供して専門領域のオーナーシップを持つチーム • ゲートキーパーと違い、APIをベースにしたコミュニケーション を行うためボトルネックが発生しづらい • エンジニア的に夢と希望に満ち溢れたチームの形
横断チームの形 社内PaaS型のチーム 夢って叶わないよね
22 Supporter Dev • 開発チームを支援するチーム • このチームは機能開発には関わらず、開発チームが機能開発の 全オーナーシップを持つ • 代わりに機能開発に必要なことを支援する
• 知識 • 仕組み サポーター型のチーム 横断チームの形
23 Guild Dev • 開発チームの特定のロールの集まったバーチャルなチーム • このチームは機能開発には関わらず、開発チームが機能開発の全オー ナーシップを持つ • 横断的な課題の解決や、寄合所としてチーム間の情報共有や相談を行う
• 完全にバーチャルな組織にすると推進力に欠ける可能性がある 横断チームの形 ギルド型のチーム
次世代開発基盤チームとしての選択 24 Dev Supporter • 開発者にオーナーシップを集約するという意味ではサポーター型の チームが適している • あくまでも現時点での方向性としての選択になる •
必要があれば他の形のチームを選択する可能性はある
DevOpsとガードレール 4 DevOpsDays Tokyo 2022
DevOpsとガードレール 26 Dev System Supporter 機能開発を行うのはあくまでも開発チーム。 サポーター型のチームは直接、機能開発をおこなってシステムを触ることはしない。
DevOpsとガードレール 27 Dev Supporter System Create Create DevOps & Guardrail
Support & Feedback Monitor Guardrail
実際の取り組み 5 DevOpsDays Tokyo 2022
土台としてのAWSアカウントの整備 AWS master Audit App1 App2 App3 ҕৡ ҕৡ ࠪઃఆͷ༗ޮԽ
ࠪϩάͷऩू AWSΞΧϯτͷ ࡞ Dev1 Dev2 Dev3 ԣஅνʔϜ1 ԣஅνʔϜ2 29
AWS DevOpsとしてのIaCのCD構築 GitHub Atlantis App1 App2 App2 横断チーム Create Dev
Commit Apply 30
DevOpsとガードレールとしてのSSOとIaC化 GitHub master Dev SSO Provider App 横断チーム Commit Policy
Login with SSO Sync Apply Create 31
Kubernetes DevOpsとしてArgoCDを使ったGitOpsの構築 ԣஅνʔϜ 32 GitHub Dev System Commit Sync Create
ArgoCD
Kubernetes ガードレールとしてOPAでのマニフェスト制限 横断チーム Dev System Commit Create GitHub Conftest GitHub
Pull Policy Commit Policy Apply 33 Gatekeeper
DevOpsとしてRDBの一時ユーザー発行 34 Vault Proxy Dev Create Temporary User Get User
横断チーム Create RDB
Kubernetes DevOpsとしてのRDBのスキーマ変更 35 Self Hoster Runner Change Schema GitHub Dev
Run CI ԣஅνʔϜ Create RDB
取り組んだ結果どうなったか 36 • まずは開発者が”できる”ようになることを重視 • ガードレールはまだすべてを作りきれてない • 結果として今は開発チームがオーナーシップを発揮してる • もうちょっとフェーズが進むとガードレールがないことによ
る失敗によって開発速度の低下が起きそうなのでガードレー ル作りちまちまやってく
時間があれば雑談 37 1. この道は正しいのかどうか • 開発チームに求められるスキルセットがえぐい • チームトポロジー • DevOpsパターン
2. 理想の組織として変化し続けるために必要な方法 3. Dev vs Ops 4. DevOpsはDev主導の方がうまくいく?
まとめ 6 DevOpsDays Tokyo 2022
まとめ 39 • 問題→要因→解決方法の選択→問題解決 • 問題解決の方法自体は何もすごいことはない • 泥臭くコツコツやってるだけ • 銀の弾丸はない
• ベストプラクティスと呼ばれるものは優秀
まとめ 40 40
None