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

Slide 1

Slide 1 text

#agiletechexpo Self-Serviceとサイロ化と組織構造 Katsuhisa Kitano / @katsuhisa__

Slide 2

Slide 2 text

#agiletechexpo 2 北野勝久 / @katsuhisa__ 株式会社スタディスト執行役員 / VPoE - Teachme Biz というSaaSをつくっている『Pythonでかなえる Excel作業効率化』著者 Organizer of SRE Lounge / SRE NEXT

Slide 3

Slide 3 text

#agiletechexpo ● 私が入社してからの、開発組織構造の変遷とその背景 ● 私が体制変更に関与した場合、その過程でなにを考えていたか・参考にしたか話すこと

Slide 4

Slide 4 text

#agiletechexpo 目的 ● 組織構造に正解はないことを皆さんと共有する ● 技術と組織構造の思想が噛み合うことの重要性を実体験をもとにお伝えする ● ≠ 「こうやればいいよ」を伝える ● ≠ 「○○はアンチパターンだよ」を伝える

Slide 5

Slide 5 text

#agiletechexpo 注意点 ● Agile開発に直接的に関係する “何か” は出てこない ● Agile開発を実践するチームを取り巻く “何か” を扱う

Slide 6

Slide 6 text

#agiletechexpo 変化の歴史むかし一人がなんでもやる 2018/9 マネージャーを設置しはじめた 2020/9 職能横断のより正確な実装を目指して 2021/3 チームのリーダーを明示する

Slide 7

Slide 7 text

#agiletechexpo 変化の歴史むかし一人がなんでもやる 2018/9 マネージャーを設置しはじめた 2020/9 職能横断のより正確な実装を目指して 2021/3 チームのリーダーを明示する ↑このあたりが今日の本題（私が体制変更に関与しはじめたのは、このあたりからってだけ）

Slide 8

Slide 8 text

#agiletechexpo 一人がなんでもやる

Slide 9

Slide 9 text

#agiletechexpo 部の直下に全員が所属 ※人数は適当 ※当時は開発部という名前ではなかった開発部

Slide 10

Slide 10 text

#agiletechexpo この頃の様子 ● 新規機能開発をする ○ サーバーサイドの実装 ○ フロントエンドの実装 ○ QA ● 新規機能開発のリリースに関する様々な調整 ○ 社内説明会 ○ 顧客向けマニュアル整備 ● お客様問い合わせに関する調査の実施 ● OnCall対応

Slide 11

Slide 11 text

#agiletechexpo 課題に感じていたこと ● 属人化が多かった ● やることはたくさんあったが、先の見えないゴール感 ● 一人がなんでもやるとはいえ、運用権限は絞られており、依頼作業ベースで運用業務が行われる ● 明示的にチームは分かれていないが、実態としては開発チームと運用チームが存在しておりサイロ化

Slide 12

Slide 12 text

#agiletechexpo DevOpsとサイロ化

Slide 13

Slide 13 text

#agiletechexpo https://www.youtube.com/watch?v=uTEL8Ff1Zvk

Slide 14

Slide 14 text

#agiletechexpo https://www.youtube.com/watch?v=uTEL8Ff1Zvk

Slide 15

Slide 15 text

#agiletechexpo https://www.youtube.com/watch?v=uTEL8Ff1Zvk

Slide 16

Slide 16 text

#agiletechexpo DevOpsとサイロ化 ● DevチームとOpsチームが分かれていることが悪いわけではない ● 各チームの目的が異なることで、お互いの共通ゴールが持てないことが問題

Slide 17

Slide 17 text

#agiletechexpo ● まずは標準化と手順書化をおこなった後に Infrastructure as Code の実践 →Opsしか知らない情報を減らす ● SRE のプラクティスをいくつか実践 →信頼性をともに高める関係を目指す ● 信頼性を高めるために、技術で課題解決 →Performanceに意識をむけ、　技術でいっしょに課題解決するプロジェクトを運用やったこと

Slide 18

Slide 18 text

#agiletechexpo 詳細は割愛（資料はすべて https://speakerdeck.com/katsuhisa91 に）

Slide 19

Slide 19 text

#agiletechexpo マネージャーを設置しはじめた

Slide 20

Slide 20 text

#agiletechexpo マネージャーが設置されはじめた ※人数もハコの数も適当開発部

Slide 21

Slide 21 text

#agiletechexpo マネージャーが設置されはじめた ※人数もハコの数も適当開発部北野はSREチームのマネージャーに

Slide 22

Slide 22 text

#agiletechexpo この頃の様子 ● 職能横断チームを組んで仕事をするのが標準に ○ PdM + Engineer + 必要に応じて SRE がアーキテクチャサポート ● Infra 環境構築は、SRE が実施 ● SREに人が増えはじめた

Slide 23

Slide 23 text

#agiletechexpo 当時、目指していたこと ● 開発者が “Self-Service” でやりたいことを定義・実行できるようにし、SRE はその基盤を整える ● アーキテクチャの決定は意思決定の記録を残し、あとから追従できるように（当時は ADR という言葉も知らなかったが…） Architecture Decision Records at Spotify https://www.infoq.com/news/2020/04/architecture-decision-records/

Slide 24

Slide 24 text

#agiletechexpo Self-Service

Slide 25

Slide 25 text

#agiletechexpo https://www.rundeck.com/self-service

Slide 26

Slide 26 text

#agiletechexpo https://www.rundeck.com/self-service

Slide 27

Slide 27 text

#agiletechexpo https://www.rundeck.com/self-service

Slide 28

Slide 28 text

#agiletechexpo https://www.rundeck.com/self-service

Slide 29

Slide 29 text

#agiletechexpo やったこと ● 開発者が Self-Service で Infra をさわれるよう、 Governance を構築する ○ AWS Organizations + Terraform ＆ GitHub - CODEOWNERS ● これまでのリリースプロセスを自動化

Slide 30

Slide 30 text

#agiletechexpo 詳細は割愛

Slide 31

Slide 31 text

#agiletechexpo 職能横断のより正確な実装を目指して

Slide 32

Slide 32 text

#agiletechexpo 専門性の高い役割を担う人が増えたこの頃、カスタマーサポートも開発部に　 ※人数もハコの数も適当開発部

Slide 33

Slide 33 text

#agiletechexpo 専門性の高い役割を担う人が増えたこの頃、カスタマーサポートも開発部に　 ※人数もハコの数も適当開発部 SRE QA PdM PdD Web / Mobile

Slide 34

Slide 34 text

#agiletechexpo この頃の様子 ● 相変わらず、職能横断チームを組んで仕事をする ● 開発者が望めば Terraform のコードを書いて Pull Request を送ることができる状態に ○ とはいえ、すぐに定着しなかった ● 次第に一部のチームが大所帯へ ○ エンジニア人数増加にともない、リリース回数が増え、社内で「リリース待ち」という発言もチラホラ ● マイクロサービスアーキテクチャの採用がはじまった

Slide 35

Slide 35 text

#agiletechexpo ● 技術支援とよばれる Enabling team を明示的に設置 ● 大きくなったチームを小さくする ● いくつかの技術的な問題を解決するため、 Kubernetes への移行をはじめた当時、目指していたこと

Slide 36

Slide 36 text

#agiletechexpo Enabling team

Slide 37

Slide 37 text

#agiletechexpo https://teamtopologies.com/resources

Slide 38

Slide 38 text

#agiletechexpo “通過地点” として目指したもの Stream-aligned team Stream-aligned team Stream-aligned team Platform team Enabling team

Slide 39

Slide 39 text

#agiletechexpo “通過地点” として目指したもの Stream-aligned team Stream-aligned team Stream-aligned team Platform team Enabling team SREが基盤開発の役割を強める技術支援や SREが支援 Engineer, QA，PdM, PdD

Slide 40

Slide 40 text

#agiletechexpo Kubernetes

Slide 41

Slide 41 text

#agiletechexpo ● そもそもコンテナで運用したかった ○ VMのB/G Deployは時間がかかる ○ VMだとOSライブラリのバージョン統一が（めっちゃがんばらない限り）むずかしい ● 最終的に、マイクロサービスと本体を1つの基盤にのせたかった ○ それぞれの環境構築を行うと、柔軟な検証環境構築のコストが高かった ● 複数サービスを今後ものせる前提での管理の容易さを重視 ○ 今日はここでいう管理の容易さは詳細割愛 …今度、社の開発ブログを誰かが書きます（予定）なんで Kubernetes 移行？（ちなみにEKS / Fargate）

Slide 42

Slide 42 text

#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

Slide 43

Slide 43 text

#agiletechexpo チームのリーダーを明示する

Slide 44

Slide 44 text

#agiletechexpo チームの中に、明示的にリーダー（≠マネージャー）を置いた ※人数もハコの数も適当開発部

Slide 45

Slide 45 text

#agiletechexpo チームの中に、明示的にリーダー（≠マネージャー）を置いた ※人数もハコの数も適当開発部わたしリーダーの皆さんリーダーの皆さんリーダーの皆さんリーダーの皆さん

Slide 46

Slide 46 text

#agiletechexpo 最近の様子 ● 相変わらず、職能横断チームを組んで仕事をする ● Stream-aligned team の増加・成長に伴い、技術支援や SRE が大忙し ● 開発者による Infra 環境構築の Pull Request 作成がほぼ当たり前に ● マイクロサービスもさらに新しいものが増え始めた

Slide 47

Slide 47 text

#agiletechexpo ● 大所帯のチームをばらして小さなチームにしたは良いが、それだけだと全体最適になっていないのでは？ ○ チーム内部の一次情報なしに評価ってできない ■ じゃあ、チームの中にいる誰かをマネージャーに？ ■ でも評価のためだけにマネージャーへの道を進んでもらうのはそれでいいんだっけ？ ○ そういえば技術情報の横連携をする際にも、チームからだれか一人いてくれると… e.g. ライブラリのバージョンアップとそれに関する影響範囲の確認 ○ あ、そういえばそういえばチームの採用のときも… 当時、考えていたこと（リーダーなんで明示？）

Slide 48

Slide 48 text

#agiletechexpo リーダーを設置してみてどうか ● 良い予感はしている ○ 一年後くらいに、どこかで話せれば良いなー ● 役割をドキュメントにして伝えるプロセスを踏んだが、なにか不満があったら Pull Request が飛んでくるだろうとも思っている ○ スタディストには handbook リポジトリがあり、マネージャーやリーダーの役割のドキュメント等はそこで管理されている

Slide 49

Slide 49 text

#agiletechexpo 今なにが起こっているか・考えているか 1 ● 複数チームが所属するチームのマネージャー（私）の役割はコーチにシフトしつつある ● 私がチームの邪魔をしないことが一番大事だというのを最近はあらためて自分に言い聞かせている

Slide 50

Slide 50 text

#agiletechexpo 今なにが起こっているか・考えているか 2 ● Enabling team だけでなく Complicated Subsystem team の役割が欲しい ○ いまは部分的に Enabling team がこの役割を担っているが、責務が多すぎる ● Stream-aligned team をより Full Cycle に近づけたい ○ Infra 構築だけでなく、サービス運用に関わる責務もより委譲したい e.g. モニタリング設計・実装、OnCall、負荷試験設計・実施

Slide 51

Slide 51 text

#agiletechexpo 言いたかったこと

Slide 52

Slide 52 text

#agiletechexpo 顧客と向き合う小さなチームを大事に

Slide 53

Slide 53 text

#agiletechexpo そのためにはリソース効率ではなく、顧客重視

Slide 54

Slide 54 text

#agiletechexpo でも職能横断チームだけあれば良いわけじゃない

Slide 55

Slide 55 text

#agiletechexpo （職能横断チームとその他チームの）コミュニケーションパターンは技術と組織一体で考える

Slide 56

Slide 56 text

#agiletechexpo 組織構造といいつつ、結局はそこにいる “人たち” でしかない

Slide 57

Slide 57 text

#agiletechexpo ごきげんに成果を出すことを目指し続けます

Slide 58

Slide 58 text

#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 Diﬀerence 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