チームトポロジーの観点で見直すプラットフォーム開発組織

ogp

はじめに
チームトポロジーとは
プラットフォーム開発組織に存在した課題
- SRE何でも屋問題
- 中長期課題に取り組めない問題
チームトポロジーを元にした組織見直し
- SRE Deskを3つのDeskに分割
- SRE DeskとPlatform Engineering Deskの違いを明文化
見直しの効果
見直しを通じての所感
最後に

はじめに

こんにちは。enechainでCTOを務めている@sutochin26です。

enechainでは、組織拡大に伴いSRE/Platform関連業務を行うチームの体制見直しを行ないました。
その際に、チームトポロジーの考え方を参考にする事で方針の言語化がしやすくなり、認識合わせの助けになりました。

SREとPlatform Engineeringをチームトポロジー視点で定義すること自体は新しくはないですが、本記事では実際に現場で生じていた課題と共にお話します。
同じような課題を抱える方々の参考になればと思います。

チームトポロジーとは

日本国内では2021年後半に「Team Topologies」の書籍が出版され話題を呼びました。
逆コンウェイ戦略をベースとして、開発組織のデザインについて多くの事例と共に体系的に語られています。

特に、以下の4つのチームタイプ、3つのインタラクションモード（チーム間のコミュニケーション方法）により組織内におけるチームの在り方を言語化していることが特徴的です。

チームタイプ

チームタイプ	概要
ストリームアラインドチーム	ビジネスドメインに沿って継続的に開発するチーム。プロダクト開発チーム等
イネイブリングチーム	特定のテクニカル(プロダクト)ドメインのスペシャリストが集まり、ストリームアラインドチームの新技術キャッチアップ等を支援するチーム
コンプリケイテッドサブシステムチーム	システムの中で、高度な専門知識を必要とするパーツを開発・保守するチーム
プラットフォームチーム	内部サービスを提供することで、ストリームアラインドチームの下位サービスの開発の必要性をなくすチーム

インタラクションモード

インタラクションモード	概要
コラボレーション	密にコミュニケーションをとって働く形。短期間で終わる必要がある
X-as-a-Service	最小限のコラボレーションでAPI等を利用、または提供する形
ファシリテーション	1つ以上のチームが別のチームからコーチしてもらう形

最初にこれらの用語を見た時は「クセの強い書籍だな」と感じ、最初の数ページで読むのをやめていました。
しばらく経って、自身の向き合う課題に対してチームトポロジーの考え方が助けになることに気づき、改めて読み直して業務に繋げたのが今回の話になります。

プラットフォーム開発組織に存在した課題

enechainでは、2年以上前からSRE Deskというチームが存在しており、Platform Engineering, SRE, Securityという3つの領域を担当していました。
このチームは、App EngineやCloud Functionsをベースに稼働していた初期のサービス郡をすべてGKEに載せ替えるなど、特にPlatform Engineering領域で重要な役割を果たしていました。 cloud.google.com

複数の責務が1つのチームに集中していることや、「SRE Desk」という名称と実態との乖離には課題感があったものの、当時は人数が少なかったこともあり、そのままの状態でしばらく運用していました。
しかし、事業が拡大するにつれて徐々に課題が大きくなり始めました。

SRE何でも屋問題

開発初期からSRE Deskが中央集権的にクラウドインフラを管理してきた結果、「インフラのチーム」という印象が根付いてしまったと同時に、「プロダクトエンジニアがインフラを触れない（権限・ケイパビリティの両面において）」という状況も作ってしまっていました。
その結果、あらゆるインフラ関連の依頼がSRE Deskに集中し、事業の拡大に伴い依頼が増えると「SREの対応待ち」という状況が目立つようになりました。

SRE Desk主導でプロダクトチームに対するGKE関連の育成サポートはしていたものの、権限委譲に関する仕組み化やアナウンスを明確をしてこなかったために、中央集権的な状況が大きく変わることはありませんでした。

中長期課題に取り組めない問題

1つのチームで複数の責務を持ってしまったため、中長期的なミッションを掲げることが難しくなっていました。
また、上述の”何でも屋問題”に伴い、目の前の課題に忙殺されてしまい、中長期の話をしたくても「それどころではない」という状態になってしまっていました。
事業状況に合わせた振る舞いも難しくなっており、このままだと下請け的な組織になってしまうという危機感もありました。

チームトポロジーを元にした組織見直し

上述のような課題について、SRE Deskのメンバーからも改善提案があり、同時に優秀なメンバーを複数名迎えられたこともあって、組織の見直しを行うことを決めました。

SRE Deskを3つのDeskに分割

まず、複数の機能を持つSRE Deskを以下の3つのDeskに分割することにしました。

SRE Desk
Platform Engineering Desk
Security Desk

「いつかこうやって分割したいよね」という話自体はSRE Desk内でもよく出ていましたが、チームトポロジーで言うところの"認知負荷"がチームの限界を超えてきたのを感じて、このタイミングで実施を決めました。
個人的に、単純な開発速度だけではなく、認知負荷・オーナーシップといった定性的な要素をチーム分割のファクターと捉えている点はチームトポロジーの好きな所です。
1つ1つのチームの人数は最低限の人数にはなってしまいましたが、それでも実行する必要性を感じて実行しました。

SRE DeskとPlatform Engineering Deskの違いを明文化

組織分割の中で明確にする必要があったのがSRE DeskとPlatform Engineering Deskの違いです。
チームのミッションだけでなく、期待されるコミュニケーションに至るまで明文化することで、他のチームからの接し方も変えてもらう必要がありました。

具体的には、以下のように定義をしました。

チーム	ミッション	チームタイプ	インタラクションモード
SRE Desk	全プロダクトのReliability向上に責任を持つ	イネイブリングチーム	ファシリテーション（定常時）, コラボレーション（プロダクト開始時や重要機能実装時）
Platform Engineering Desk	プラットフォーム領域において、各開発チームのデベロッパー体験の最大化に責任を持つ	プラットフォームチーム	X-as-a-Service

【SRE Desk】
SRE Deskは「イネイブリングチーム」に分類しています。これはテクニカルコンサルティングを行うようなチームです。
SREに関する深い知見を持ち、それを他のチームに伝えるコミュニケーション（ファシリテーション）を取ります。
また、SRE Deskは重要な開発案件がある際にはプロダクトチームと密に連携を取る（コラボレーション）こともあります。
具体的には以下のようなインタラクションのイメージです。

コラボレーション
- プロダクトチームと共にSLO/SLIを設計・実装
- プロダクトチームと共にObservabilityを担保するための実装
ファシリテーション
- SRE的な考え方、実装方法を各プロダクトチームに伝える

【Platform Engineering Desk】
Platform Engineering Deskは「プラットフォームチーム」に分類しており、X-as-a-Serviceのインタラクションを基本としています。

これは分割前のSRE Deskと比べると非常に大きな変化です。
今までは「インフラに関する依頼を受け、とにかく実行する」というインタラクションをとっていましたが、そうではなく、各開発チームに対してサービスを提供し、それを自由に使ってもらうという思想になっています。

チームトポロジーの中では以下のような考えが重要視されています。

クラウドチームはアプリケーションのインフラは作らない。実際のプロビジョニング等はプロダクトチームに渡す
ノンブロッキングであること。相手に待ちを発生させない仕組みを作る

この考えを元に、単純に「依頼に応える」のではなく、「プロダクトチームが自ら課題を解決出来る仕組みを整える」という方向に大きく方向性を変えています。

以下の取り組みは、全社のプラットフォーム品質統制とプロダクトエンジニアの開発体験最大化の両立を目指した取り組みの一例であり、弊社におけるPlatform Engineeringの新しい形になります。 techblog.enechain.com

見直しの効果

チーム分割はほんの1ヶ月前に実施しましたが、既に見えている効果もあります。

まず、各メンバーの責任が明確になり、オーナーシップを持ちやすくなりました。
Platform Engineering Deskでは2,3年後の事業状況まで見据えてロードマップが描かれ、SRE DeskではSLO/SLIに関するイネイブリングや導入支援にフォーカスした動きが主となりました。
プロダクトチームからの依頼は、プロダクトチーム側で解決出来るよう仕組みを整える動きが強まっており、「人を採用してどうにかしよう」というような人力に頼る雰囲気はなくなりました。

こういった諸々の考え方について、CTOである私とSRE Desk/Platform Engineering Deskの間で共通認識・共通言語が持てていることは非常に大きな意味があると感じます。
数年後のロードマップについて議論する際の考え方のブレも非常に小さくなりました。

見直しを通じての所感

チームトポロジーを読んで、「組織構造のデザインはシステムアーキテクチャを考えるのと同様に重要な仕事」というのを改めて考えさせられました。
とはいえ、今のenechain規模の組織をデザインした経験は自分にはなく、今までは過去に在籍した組織のデザインを参考に考えていました。

今回、チームトポロジーの考え方を元に、ある程体系的に組織構造・チームの在り方について考えることが出来ました。なんとなくやっていたことが言語化されたような感覚で、判断にもブレがなくなったのを感じます。
色々な人に影響を及ぼす仕事だからこそ、「言語化して実行した」という事には大きな意味があったと思います。

今後、このような考え方を全開発メンバー達と共有し、組織間のインタラクションを最適化していったり、組織の未来像について共通認識を持つことも私の重要な役割だと考えています。