責務で考える組織と 第三世代のSRE グロービス・デジタル・プラットフォーム SRE 沼⽥重太朗 2024年12⽉5⽇ SREのリアル｜組織フェーズに合わせたSREの役割とは

⾃⼰紹介 沼⽥ 重太朗 株式会社グロービス グロービス・デジタル・プラットフォーム SREチーム チームリーダー（2020〜） 前職までは主に⾦融系インフラエンジニア TerraformやAtlantisが好き @chroju 2

グロービス・デジタル・プラットフォームについて 3 ビジネススクールを主体とするグロービスにて2016年発⾜ 育成ノウハウやコンテンツのデジタルサービス化を、マルチプロダクトで推進

今⽇話したいこと 複数事業を展開するグロービスにおいて SREという組織の「責務」をどのように考えてきたか 4

SREチームとプロダクトとの関わり 5 GLOBIS 学び放題 GLOPLA LMS ナノ単科 ……etc SRE Auroraバージョン アップしませんか？ 最近、エラー 増えてません？ 新しい インフラ欲しい IAM user ください Argo CD 動かないです SaaSの利⽤料⾦ 先⽉⾼いなぁ…… 脆弱性の ニュースが出てる！ 503出てるけど 何かわかります？

組織設計の⼀般論で考える 『チームトポロジー』でのキーは認知負荷とコミュニケーション “チームトポロジーでは、チームの認知負荷を制限し、 チーム間のコミュニケーションを明確に設計する必要がある。 “ （マシュー・スケルトン, マニュエル・パイス 著, 原⽥ 騎郎, 永瀬 美穂, 吉⽻ ⿓太郎 訳. チームトポロジー. ⽇本能率協会マネジメントセンター. 2021. “Chapter 1 組織図の問題”より） 6

SREチームにチームトポロジーを当てはめると？ 7 GLOBIS 学び放題 GLOPLA LMS ナノ単科 ……etc SRE Auroraバージョン アップしませんか？ 最近、エラー 増えてません？ 新しい インフラ欲しい IAM user ください Argo CD 動かないです SaaSの利⽤料⾦ 先⽉⾼いなぁ…… 脆弱性の ニュースが出てる！ 503出てるけど 何かわかります？ 増えていく プロダクトの 認知負荷 担当範囲の 広さによる 認知負荷 多くのチームとの コミュニケーション

組織が育つにつれて業務は複雑化していく 8 プロダクトが少なく タスクもコミュニケーションパスも多くない プロダクトが増えるほど 認知負荷は増えていく

9 1. 増えていくプロダクトの認知負荷 2. 担当範囲が広いことによる認知負荷 3. 多くのチームとのコミュニケーション

10 1. 増えていくプロダクトの認知負荷 2. 担当範囲が広いことによる認知負荷 3. 多くのチームとのコミュニケーション

セルフサービス化、オーナーシップの委譲 プロダクトサイドの⾃律性が⾼まるようイネイブリングしていく 11 503が出ているので 原因調査お願いします レスポンスが遅いから Datadogで調べてみよう 環境変数の値を 変更してください 環境変数を変更したいので Pull Requestを出しました 🤔 SREがボトルネックに成り得る 信頼性はプロダクトの関心にしたい Nice! ✨

委譲のための取り組み 12 コミュニケーションの実績計測

委譲のための取り組み 13 ドキュメンテーション

委譲のための取り組み 14 モブプロ

委譲のための取り組み 15 成熟度モデル（WIP）

16 1. 増えていくプロダクトの認知負荷 2. 担当範囲が広いことによる認知負荷 3. 多くのチームとのコミュニケーション

SREの責務を減らす コーポレートIT関連の業務は、ISチームを新設して責務を分ける 17 • AWS • SendGrid • Datadog • GitHub • Docker Hub • AWS • SendGrid • Datadog ISチーム管轄 • GitHub • Docker Hub

SRE内部でも責務を細分化する 18 ミッションを限定して、タスクスイッチなどの認知負荷を減らす Platform SRE Collaboration SRE EKS、Datadogなど 効率的なSREingのための プラットフォーム構築 プラットフォーム活⽤や SREプラクティス導⼊を プロダクトサイドと推進

19 1. 増えていくプロダクトの認知負荷 2. 担当範囲が広いことによる認知負荷 3. 多くのチームとのコミュニケーション

SREチームのコミュニケーション先 事業との繋がり、横断チーム同⼠の繋がり 20 GLOBIS 学び放題 GLOPLA LMS ナノ単科 ……etc QA SRE IS DevEx 基盤(認証) Product Success

プロダクションミーティング 21 特定プロダクトと、全横断チームが⽉に1回⼀堂に会する会議体 元はSRE bookに書かれているプラクティスだが ⾮機能要件上の課題を広く捉えるために Product Successの枠組みで実施 例えばインシデント対応1つ取っても、 信頼性観点=SRE、品質やテスト観点=QAなど 各チームでの役割がある “各チーム個別に連携しているとボールが 落ちる部分もありそうなので、Product Success全体で顔を合わせながら認識を 合わせていくのが⼤事” あるプロダクトでのキックオフの際に 開発サイドから寄せられた発⾔

ミクロからマクロまで様々な接し⽅を考える 22 Pull Request モブプロ プロダクション MTG プロジェクトの 組成 定常的に繰り返されるものは 最⼩限のインタラクションへ 置き換える 不確実性が⾼い部分は コミュニケーションを 仕組みとして固定してしまう

23 まとめ

おさらい 24 1. 増えていくプロダクトの認知負荷 ⇒SREingの責務を「分散」 2. 担当範囲が広いことによる認知負荷 ⇒チーム境界や責務の再設定 3. 多くのチームとのコミュニケーション ⇒コラボレーションを促す会議体設計

The Third Age of SRE 25 “All engineers can wear an SRE hat as part of their job, and at least smaller organizations will then stop hiring dedicated SREs. “ (Björn “Beorn” Rabenstein / Grafana Labs) (Emil Stolarsky, Jaime Woo. 97 Things Every SRE Should Know. O'Reilly Media, Inc. 2020. “Chapter 98. The Third Age of SRE“) 第⼀世代 Googleのみが占有的にSREを実践 第⼆世代 SRE booksによる知識拡散、専任SREの増加 第三世代 すべてのエンジニアが部分的にSREに グロービスSREの⽬指す⽅向性は「第三世代」のSRE

組織設計は終わることなく模索が必要 26 タックマンモデルが描いた統⼀や安定はやってこない（かも） “最近の研究では、このモデルが必ずし も正しくないことがわかってきた。 チームが存続している間、混乱はずっと 続くというものだ。” (チームトポロジー. “Chapter 3 チームファースト思考“ より) 形成期 混乱期 統⼀期 安定期 散会期

We are hiring 27 だから⼀緒にやりませんか？