Self-Serviceとサイロ化と組織構造

Agile Tech EXPO mini #4 チームの相乗効果を生むVPoEの企て https://agiletechexpo.connpass.com/event/206455/ でお話した資料です。

Envoyの作者Matt Klein氏が自身のブログにて「DevOps is the practice of developers being responsible for operating their services in production, 24/7.」と記したことは有名です。この考えに共感した私たちが、これまで実際にどういった考えで、この思想の体現にむけて取り組んできたかについて、技術と組織の観点からお話します。

技術が先行しすぎると専門性でチーム同士がサイロ化してしまい、組織の構造だけが先行してもチームで個別最適化しすぎてしまいます。単に自動化すればよかったのか？単にチームを小さくすればよかったのか？否、技術と組織の思想が噛み合うことで、ようやくたった一歩だけ前進できるのです。

これは私たちの発展途上の物語であり、懇親会でみなさんの物語についてもお伺いすることを楽しみにしています。

---
Organizational Choice: Product vs. Function
https://hbr.org/1968/11/organizational-choice-product-vs-function

Team Topologies
https://teamtopologies.com/

Self-Service Operations
https://www.rundeck.com/self-service

What's the Difference Between DevOps and SRE? (class SRE implements DevOps)
https://www.youtube.com/watch?v=uTEL8Ff1Zvk

『LeanとDevOpsの科学[Accelerate]』
https://www.amazon.co.jp/dp/4295004901

『This is Lean』
https://www.amazon.co.jp/dp/479816951X/

『サイロエフェクト』
https://www.amazon.co.jp/dp/4163903895

Transcript

1. #agiletechexpo Self-Serviceと サイロ化と組織構造 Katsuhisa Kitano / @katsuhisa__
2. #agiletechexpo 2 北野 勝久 / @katsuhisa__ 株式会社スタディスト 執行役員 / VPoE - Teachme Biz というSaaSをつくっている 『Pythonでかなえる Excel作業効率化』著者 Organizer of SRE Lounge / SRE NEXT
3. #agiletechexpo • 私が入社してからの、開発組織構造の変遷とその背景 • 私が体制変更に関与した場合、 その過程でなにを考えていたか・参考にしたか 話すこと
4. #agiletechexpo 目的 • 組織構造に正解はないことを皆さんと共有する • 技術と組織構造の思想が噛み合うことの重要性を 実体験をもとにお伝えする • ≠ 「こうやればいいよ」を伝える • ≠ 「◦◦はアンチパターンだよ」を伝える
5. #agiletechexpo 注意点 • Agile開発に直接的に関係する “何か” は出てこない • Agile開発を実践するチームを取り巻く “何か” を扱う
6. #agiletechexpo 変化の歴史 むかし 一人がなんでもやる 2018/9 マネージャーを設置しはじめた 2020/9 職能横断のより正確な実装を目指して 2021/3 チームのリーダーを明示する
7. #agiletechexpo 変化の歴史 むかし 一人がなんでもやる 2018/9 マネージャーを設置しはじめた 2020/9 職能横断のより正確な実装を目指して 2021/3 チームのリーダーを明示する ↑このあたりが今日の本題 （私が体制変更に関与しはじめたのは、このあたりからってだけ）
8. #agiletechexpo 一人がなんでもやる
9. #agiletechexpo 部の直下に全員が所属 ※人数は適当 ※当時は開発部という名前ではなかった 開発部
10. #agiletechexpo この頃の様子 • 新規機能開発をする ◦ サーバーサイドの実装 ◦ フロントエンドの実装 ◦ QA • 新規機能開発のリリースに関する様々な調整 ◦ 社内説明会 ◦ 顧客向けマニュアル整備 • お客様問い合わせに関する調査の実施 • OnCall対応
11. #agiletechexpo 課題に感じていたこと • 属人化が多かった • やることはたくさんあったが、先の見えないゴール感 • 一人がなんでもやるとはいえ、運用権限は絞られており、 依頼作業ベースで運用業務が行われる • 明示的にチームは分かれていないが、 実態としては開発チームと運用チームが存在しておりサイロ化
12. #agiletechexpo DevOpsとサイロ化
13. #agiletechexpo https://www.youtube.com/watch?v=uTEL8Ff1Zvk
14. #agiletechexpo https://www.youtube.com/watch?v=uTEL8Ff1Zvk
15. #agiletechexpo https://www.youtube.com/watch?v=uTEL8Ff1Zvk
16. #agiletechexpo DevOpsとサイロ化 • DevチームとOpsチームが分かれていることが 悪いわけではない • 各チームの目的が異なることで、 お互いの共通ゴールが持てないことが問題
17. #agiletechexpo • まずは標準化と手順書化をおこなった後に Infrastructure as Code の実践 →Opsしか知らない情報を減らす • SRE のプラクティスをいくつか実践 →信頼性をともに高める関係を目指す • 信頼性を高めるために、技術で課題解決 →Performanceに意識をむけ、 　技術でいっしょに課題解決するプロジェクトを運用 やったこと
18. #agiletechexpo 詳細は割愛（資料はすべて https://speakerdeck.com/katsuhisa91 に）
19. #agiletechexpo マネージャーを設置しはじめた
20. #agiletechexpo マネージャーが設置されはじめた ※人数もハコの数も適当 開発部
21. #agiletechexpo マネージャーが設置されはじめた ※人数もハコの数も適当 開発部 北野はSREチームの マネージャーに
22. #agiletechexpo この頃の様子 • 職能横断チームを組んで仕事をするのが標準に ◦ PdM + Engineer + 必要に応じて SRE がアーキテクチャサポート • Infra 環境構築は、SRE が実施 • SREに人が増えはじめた
23. #agiletechexpo 当時、目指していたこと • 開発者が “Self-Service” でやりたいことを 定義・実行できるようにし、SRE はその基盤を整える • アーキテクチャの決定は意思決定の記録を残し、 あとから追従できるように （当時は ADR という言葉も知らなかったが…） Architecture Decision Records at Spotify https://www.infoq.com/news/2020/04/architecture-decision-records/
24. #agiletechexpo Self-Service
25. #agiletechexpo https://www.rundeck.com/self-service
26. #agiletechexpo https://www.rundeck.com/self-service
27. #agiletechexpo https://www.rundeck.com/self-service
28. #agiletechexpo https://www.rundeck.com/self-service
29. #agiletechexpo やったこと • 開発者が Self-Service で Infra をさわれるよう、 Governance を構築する ◦ AWS Organizations + Terraform ＆ GitHub - CODEOWNERS • これまでのリリースプロセスを自動化
30. #agiletechexpo 詳細は割愛
31. #agiletechexpo 職能横断のより正確な実装を目指して
32. #agiletechexpo 専門性の高い役割を担う人が増えた この頃、カスタマーサポートも開発部に　 ※人数もハコの数も適当 開発部
33. #agiletechexpo 専門性の高い役割を担う人が増えた この頃、カスタマーサポートも開発部に　 ※人数もハコの数も適当 開発部 SRE QA PdM PdD Web / Mobile
34. #agiletechexpo この頃の様子 • 相変わらず、職能横断チームを組んで仕事をする • 開発者が望めば Terraform の コードを書いて Pull Request を送ることができる状態に ◦ とはいえ、すぐに定着しなかった • 次第に一部のチームが大所帯へ ◦ エンジニア人数増加にともない、リリース回数が増え、 社内で「リリース待ち」という発言もチラホラ • マイクロサービスアーキテクチャの採用がはじまった
35. #agiletechexpo • 技術支援とよばれる Enabling team を明示的に設置 • 大きくなったチームを小さくする • いくつかの技術的な問題を解決するため、 Kubernetes への移行をはじめた 当時、目指していたこと
36. #agiletechexpo Enabling team
37. #agiletechexpo https://teamtopologies.com/resources
38. #agiletechexpo “通過地点” として目指したもの Stream-aligned team Stream-aligned team Stream-aligned team Platform team Enabling team
39. #agiletechexpo “通過地点” として目指したもの Stream-aligned team Stream-aligned team Stream-aligned team Platform team Enabling team SREが 基盤開発の 役割を強める 技術支援 や SREが支援 Engineer, QA，PdM, PdD
40. #agiletechexpo Kubernetes
41. #agiletechexpo • そもそもコンテナで運用したかった ◦ VMのB/G Deployは時間がかかる ◦ VMだとOSライブラリのバージョン統一が （めっちゃがんばらない限り）むずかしい • 最終的に、マイクロサービスと本体を1つの基盤にのせたかった ◦ それぞれの環境構築を行うと、柔軟な検証環境構築のコストが高かった • 複数サービスを今後ものせる前提での管理の容易さを重視 ◦ 今日はここでいう管理の容易さは詳細割愛 …今度、社の開発ブログを誰かが書きます（予定） なんで Kubernetes 移行？（ちなみにEKS / Fargate）
42. #agiletechexpo なによりも思想に共感 Kubernetes is a platform for building platforms. Here's what that means. https://tanzu.vmware.com/content/blog/kubernetes -is-a-platform-for-building-platforms
43. #agiletechexpo チームのリーダーを明示する
44. #agiletechexpo チームの中に、明示的にリーダー（≠マネージャー）を置いた ※人数もハコの数も適当 開発部
45. #agiletechexpo チームの中に、明示的にリーダー（≠マネージャー）を置いた ※人数もハコの数も適当 開発部 わたし リーダーの 皆さん リーダーの 皆さん リーダーの 皆さん リーダーの 皆さん
46. #agiletechexpo 最近の様子 • 相変わらず、職能横断チームを組んで仕事をする • Stream-aligned team の増加・成長に伴い、 技術支援や SRE が大忙し • 開発者による Infra 環境構築の Pull Request 作成が ほぼ当たり前に • マイクロサービスもさらに新しいものが増え始めた
47. #agiletechexpo • 大所帯のチームをばらして小さなチームにしたは良いが、 それだけだと全体最適になっていないのでは？ ◦ チーム内部の一次情報なしに評価ってできない ▪ じゃあ、チームの中にいる誰かをマネージャーに？ ▪ でも評価のためだけにマネージャーへの道を進んでもらうのは それでいいんだっけ？ ◦ そういえば技術情報の横連携をする際にも、 チームからだれか一人いてくれると… e.g. ライブラリのバージョンアップとそれに関する影響範囲の確認 ◦ あ、そういえばそういえばチームの採用のときも… 当時、考えていたこと（リーダーなんで明示？）
48. #agiletechexpo リーダーを設置してみてどうか • 良い予感はしている ◦ 一年後くらいに、どこかで話せれば良いなー • 役割をドキュメントにして伝えるプロセスを踏んだが、 なにか不満があったら Pull Request が飛んでくるだろう とも思っている ◦ スタディストには handbook リポジトリがあり、 マネージャーやリーダーの役割のドキュメント等は そこで管理されている
49. #agiletechexpo 今なにが起こっているか・考えているか 1 • 複数チームが所属するチームのマネージャー（私）の役割は コーチにシフトしつつある • 私がチームの邪魔をしないことが一番大事だというのを 最近はあらためて自分に言い聞かせている
50. #agiletechexpo 今なにが起こっているか・考えているか 2 • Enabling team だけでなく Complicated Subsystem team の役割が欲しい ◦ いまは部分的に Enabling team がこの役割を担っているが、 責務が多すぎる • Stream-aligned team をより Full Cycle に近づけたい ◦ Infra 構築だけでなく、サービス運用に関わる責務もより委譲したい e.g. モニタリング設計・実装、OnCall、負荷試験設計・実施
51. #agiletechexpo 言いたかったこと
52. #agiletechexpo 顧客と向き合う小さなチームを大事に
53. #agiletechexpo そのためには リソース効率ではなく、 顧客重視
54. #agiletechexpo でも職能横断チームだけあれば 良いわけじゃない
55. #agiletechexpo （職能横断チームとその他チームの） コミュニケーションパターンは 技術と組織一体で考える
56. #agiletechexpo 組織構造といいつつ、 結局はそこにいる “人たち” でしかない
57. #agiletechexpo ごきげんに成果を出すことを 目指し続けます
58. #agiletechexpo 参考文献 • Organizational Choice: Product vs. Function https://hbr.org/1968/11/organizational-choice-product-vs-function • Team Topologies https://teamtopologies.com/ • Self-Service Operations https://www.rundeck.com/self-service • What's the Difference Between DevOps and SRE? (class SRE implements DevOps) https://www.youtube.com/watch?v=uTEL8Ff1Zvk • 『LeanとDevOpsの科学[Accelerate]』 https://www.amazon.co.jp/dp/4295004901 • 『This is Lean』 https://www.amazon.co.jp/dp/479816951X/ • 『サイロエフェクト』 https://www.amazon.co.jp/dp/4163903895