開発プロセス・方法論

Team Topologies

（ちーむとぽろじーず）

一言でいうと

4つのチームの型と3つの関わり方だけを使って、開発の流れが速くなるように組織を組み直す枠組みです。Platform EngineerやEnabling QAといった職種名の背景にもなっています。

Matthew SkeltonとManuel Paisによる書籍で、初版は2019年9月7日にIT Revolution Pressから刊行されました。公式サイトによれば、2019年以降、複数の業種で組織の変革に用いられています。第2版は2025年9月23日に出ています。

エンジニア採用の文脈では、Platform EngineerやEnabling QAといった職種名の背景としてこの枠組みが参照されることが増えています。職種の定義を読むとき、どのチーム型を指しているかがわかると理解が速くなります。

組織構造がそのままシステムの構造に現れる、という経験則への対処です。チームの数と関わり方が増えるほど、調整の手間が増え、変更を出すまでの時間が伸びます。

この枠組みは、チームを4つの型に絞り、関わり方を3つの様式に限定します。組み合わせを減らすことで、調整の経路を意図的に設計できるようにします。

まず、価値を届ける単位で動くチーム（ストリームアラインドチーム）を中心に置きます。その負荷を下げるために、共通基盤を提供するプラットフォームチーム、専門性で支援するイネイブリングチーム、複雑な領域を引き受けるチームを配置します。

関わり方も設計します。協働する、サービスとして提供する、一時的に支援する、の3つを、期間を決めて使い分けます。恒久的な協働は避けるのが原則です。

組織構造を意図的に設計している、あるいはしようとしている組織です。プラットフォームチームやイネイブリングチームという言葉が併記されていれば、その型の職務として募集していると読めます。

検索で引きやすいのはSREです。Platform Engineerは国内で表記が揺れており、プラットフォームエンジニアや基盤エンジニアと書かれることも多いため、この呼称のままでは取りこぼします。

自社側では、そのチームがどのチームを支える立場かを決めておきます。支援の相手が定まっていない場合、名前だけの導入です。候補者には、前職で自分のチームが誰に何を提供していたかを聞きます。