場面
「ツールを足したのに、なぜ開発者の負担は減らないのか」
開発者向けに新しいCLIを作った。Backstageを立てた。Terraformモジュールを整えた。CI/CDを刷新した。それぞれ使いやすいはずだ。
ところが、現場の声はこうだ。「Backstageでサービスを生成して、Terraformモジュールでインフラを書いて、CLIでデプロイして、Datadogで監視を確認する。でも、Backstageの YAML と Terraformの変数の関係が分からない。CLIのオプションがTerraformの何を上書きするのかも分からない。結局Slackで聞きに行く」。
ツールが増えた。学ぶべきものも増えた。
このパターンは、Platform Engineering で最も狡猾なアンチパターンのひとつだ。抽象を増やしているつもりが、実は認知負荷を増やしている。第10話で「Cognitive load を下げるはずが上げてしまう」というアンチパターン名がついている現象だ。
なぜこうなるのか。問題の根は、「認知負荷とは何か」を測らずに足し算しているからだ。Team Topologies が提供する道具は、この測定と削減を体系的に行うための設計言語だ。本章では、Cognitive Load 理論の3分類、Team Topologies の4チームと3 interaction mode、TVPと「3つの実例が出るまで抽象化を待つ」原則、そして Inverse Conway Maneuver の正しい使い方を整理していく。
この章を読み終えると、次の3つができるようになる。
- 自社のチームが背負っている認知負荷を、Intrinsic / Extraneous / Germane の3分類で見分けられる
- Team Topologies の4チームタイプと3 interaction mode で、自社の組織を地図化できる
- TVP と「3つの実例が出るまで抽象化を待つ」原則を、自分のプラットフォーム化判断に適用できる
Cognitive Load の3分類
認知負荷理論は、もともと教育心理学者 John Sweller が1980〜90年代に体系化したものだ。Team Topologies はこれをソフトウェア組織に応用した。
3種類の認知負荷がある。
| 種類 | 意味 | 例 | プラットフォーム的扱い |
|---|---|---|---|
| Intrinsic（内在的） | 課題本来の難しさ・必要なスキル | アルゴリズムの選択、ドメインモデリング | 訓練で軽減可能。残しておきたい |
| Extraneous（外在的） | 仕組み・ツール・無駄な手続き由来 | Terraformの細かい構文、デプロイ手順 | プラットフォームで削減すべき主対象 |
| Germane（関連的） | 専門性・ドメイン知識への深まり | 自社プロダクトのビジネスロジック理解 | 残しておきたい・伸ばしたい |
ポイントは、3つすべてを下げればよいわけではない ことだ。
❌ 認知負荷を一律に下げようとする発想
→ ドメイン知識（Germane）まで隠してしまうと、
開発者は自分のプロダクトで何を作っているか分からなくなる
✅ Extraneous を選択的に削減する発想
→ 「Cloud Run の起動引数の正解」「IAM 設定の細部」のような
プロダクトの本質と関係ない知識をプラットフォームの内側に封じ込める第7話で見た 10X の Terraform モジュール化は、この Extraneous の選択的削減 の典型だ。GCP固有のIAM設定や Cloud Run の細かいパラメータ（Extraneous）をモジュールに封じ込め、開発者には「何を作りたいか」（Germane）に集中してもらう。
“The platform team provides internal services to reduce the cognitive load that would be required from stream-aligned teams.” — Team Topologies (Skelton & Pais, 2019)
Platform Engineering の存在意義を一言で言えば、これに尽きる。Stream-aligned team の Extraneous Cognitive Load を構造的に削減し、Germane な仕事に集中できる状態を作る。
Cognitive Load Assessment
Team Topologies は Cognitive Load Assessment という測定ツールも提供している（GitHub: TeamTopologies/Team-Cognitive-Load-Assessment）。チームメンバーに「自分が今背負っている認知負荷を、Intrinsic / Extraneous / Germane に分けてスコアリングしてもらう」というシンプルなアセスメントだ。
数字を取ること自体に意味があるのではない。チームメンバーの「認知負荷についての言語」を揃えることに意味がある。「いま負荷が高い」と言ったとき、それが「ドメインを学ぶ負荷」なのか「Terraformの細部を覚える負荷」なのかが分かれば、対処法が変わる。
Team Topologies の4チームタイプ
組織を「認知負荷を最適化する単位」として再設計する道具が、Team Topologies の4チームタイプだ。
graph TD
A[Stream-aligned team<br/>業務ドメインに沿った主役] --> X[認知負荷<br/>Intrinsic + Germane]
B[Platform team<br/>共通能力を提供] --> A
C[Enabling team<br/>一時的支援] --> A
D[Complicated-subsystem team<br/>深い専門知識] --> A
style A fill:#dfd
style B fill:#ddf
style C fill:#fdf
style D fill:#ffd| チームタイプ | 役割 | 例 |
|---|---|---|
| Stream-aligned team | 業務ドメインに沿った主役チーム。価値の流れ（stream）に沿って end-to-end を所有する | プロダクトの「決済」「検索」「ユーザー認証」など、機能領域別チーム |
| Platform team | Stream-aligned teamが使う共通能力を提供する | 10X SRE（Service Kit/Team Kit）、freee Platform Delivery、Sansan Platform Engineering Unit |
| Enabling team | 一時的に Stream-aligned team に張り付き、新しい技術や習慣の習得を支援する | LayerX Enabling、SmartHR の社内開発者コミュニティ運営 |
| Complicated-subsystem team | 深い専門知識が必要な、複雑なサブシステムを担当 | ML プラットフォーム（Uber Michelangelo）、検索エンジン、暗号系基盤 |
第7話で見た国内SaaSの組織を、この4分類で再解釈してみよう。
- 10X：SREチームが Platform team として動き、Stream-aligned team（プロダクト開発チーム）に Service Kit / Team Kit を提供する
- カケハシ：Embedded SRE は Stream-aligned team に近接する Enabling team 的な存在、Platform SRE が Platform team として横断基盤を担う
- Sansan：Platform Engineering Unit が Platform team、Embedded SRE が Enabling team、Bill One SRE のような独立チームは半ば Stream-aligned team の一部
- freee：SRE 4分割（Platform / Enabling / Cloud Governance / DBRE）は明示的に Team Topologies の語彙で組まれている
このマッピングを行うと、第7話で見た「ハイブリッド型」が、Team Topologies の語彙で Platform team + Enabling team の組み合わせ として整理できる。日本のSaaS各社が独自に到達した組織パターンが、Team Topologies のフレームに自然と収まることが分かる。
3つの interaction mode
チームタイプだけでは組織設計は完成しない。チーム間の 相互作用パターンを3つに限定するのが Team Topologies のもうひとつの核心だ。
| Interaction mode | 意味 | 期間 |
|---|---|---|
| X-as-a-Service | 一方が他方にサービスを「提供」する関係。Selfサービスで使える | 永続的 |
| Collaboration | 2チームが密に協働して新しい問題を解く関係 | 一時的（数週間〜数ヶ月） |
| Facilitating | 一方が他方の学習を「促進」する関係 | 一時的 |
graph LR
A[Stream-aligned A] -->|Collaboration| B[Stream-aligned B]
C[Platform team] -->|X-as-a-Service| A
C -->|X-as-a-Service| B
D[Enabling team] -->|Facilitating| A
D -->|Facilitating| BPlatform team と Stream-aligned team の関係は X-as-a-Service が基本 だ。プラットフォームを使う側は、毎回プラットフォームチームと打ち合わせる必要はない。ドキュメントとセルフサービスインターフェイスがあれば動ける。これが第8話で見た「採用任意」「内部顧客」の運営思想を、相互作用のレベルで実装した形だ。
Enabling team は Facilitating だ。「やってあげる」のではなく「できるようになるよう促す」。一時的に張り付いて、習得が終わったら離れる。LayerX の Enabling、Sansan の Embedded SRE が「教える側として動く」とされているのは、まさにこのモードだ。
Collaboration は意図的に時限的 にする。問題が解けて知識が共有されたら、X-as-a-Service か Facilitating に格上げ／降格する。Collaboration を永続化すると、両チームが共同責任を抱える時間が長引き、認知負荷が増える。
❌ 悪いパターン：
全ての関係が Collaboration（毎回打ち合わせ）
→ チーム間の調整コストが認知負荷を圧迫する
✅ 良いパターン：
日常は X-as-a-Service（セルフサービス）、
新しい問題が出たときだけ Collaboration、
学習機会には Enabling team が Facilitating第6話で見た Tailscale のようなインフラ3名のスタートアップは、X-as-a-Service の薄いプラットフォームを「Wikiページ + Slackチャンネル」レベルで運営している。これは TVP（次節）の最小実装でもある。
TVP（Thinnest Viable Platform）：最小限から始める
第8話で触れた TVP を、ここでは原則のレベルで深く扱う。
A TVP is a careful balance between keeping the platform small and ensuring that the platform is helping to accelerate and simplify software delivery for teams building on the platform. — Team Topologies
TVP の本質は、「最小限で価値が出る形を作って、需要があるところだけ厚くする」 だ。物理的な実装の薄さではなく、ユーザーから見たときの薄さが重要。
具体的に何が薄さを定義するか。
- 意思決定が明確：「推奨ツールはこれです」「困ったらここに聞いてください」が一覧で分かる
- 問い合わせ先が一意：Slackチャンネルがひとつ、担当者が明確
- 情報が散らばっていない：READMEとWikiが何箇所にも分散していない
- 手順が短い：5ステップ以内で初回デプロイができる
最初から Backstage と Terraform モジュールと CI/CD と監視と権限管理を全部用意する必要はない。Wiki ページ1枚と Slack チャンネル1つで TVP として成立する。
なぜ TVP が重要か。理由は2つある。
第一に、早く始めれば早くフィードバックが得られる。Field of Dreams（“Build it and they will come”）アンチパターンを避ける唯一の方法は、小さく始めて使ってもらいながら学ぶことだ。
第二に、過剰抽象化を避けられる。ここで関係するのが次の原則「3つの実例が出るまで抽象化を待つ」だ。
「3つの実例が出るまで抽象化を待つ」
ソフトウェア界には Sandi Metz の有名な格言がある。
Prefer duplication over the wrong abstraction.（誤った抽象化より重複を選べ） — Sandi Metz, The Wrong Abstraction (2014)
Platform Engineering における共通化判断にも、この原則がそのまま使える。Rule of Three：「3つの実例が出るまで抽象化を待つ」。
具体的にはこうだ。
状況1：1チームが特定の問題（例：マルチリージョンデプロイ）を解いている
→ 共通化しない。そのチーム固有の解として残す
状況2：2チームが似たような問題を解いている
→ まだ共通化しない。違いを観察する
状況3：3チーム目が現れた
→ 共通点と相違点を比較し、共通化する範囲を決める
→ 抽象化の方向性が、3つの実例から逆算できるなぜ早すぎる抽象化が危険か。1チーム目の解を「共通解」として固定すると、2チーム目・3チーム目の異なる要件を吸収できないからだ。結果として、後発チームは共通基盤に「無理に合わせる」か、「逸脱して独自実装する」かの2択を迫られる。前者は認知負荷を増やし、後者は共通基盤を形骸化させる。
3チームの実例が揃うと、**「どこが本当に共通で、どこが各チーム固有か」**が見える。共通の核と、各チームのカスタマイズポイントを切り分けて設計できる。
これは第8話の TVP（最小限から始める）と表裏一体だ。最小限から始めて、3つの実例が出てから厚くする。
国内事例で言えば、Sansan が Bill One → Contract One → Sansan Data Intelligence へ認証基盤を展開した過程は、最初から共通基盤を作ったのではなく、Bill One での実装が成熟してから他に展開したことが特徴的だ。1プロダクトでの実例を成熟させてから、横展開している。
Cognitive Leakage：抽象が漏れる
抽象化のもうひとつの落とし穴を、Thoughtworks は Cognitive Leakage と呼んだ。
Cognitive Leakage：抽象に隠した複雑性が、いつか問題として噴き出す現象 — Thoughtworks: Cognitive leakage
Terraformモジュールが「いい感じに動く」状態を作っても、いざ障害が発生したときには、モジュールの内側で何が起きているかを開発者が理解する必要がある。普段は隠せていた認知負荷が、トラブル時に一気に漏れ出す。
これは Joel Spolsky の “All non-trivial abstractions, to some degree, are leaky”（すべての自明でない抽象は、ある程度漏れる）という古典的観察と同じ系譜にある。
Cognitive Leakage を見越した設計とは何か。
- Sensible defaults + Escape hatches：デフォルトは賢く、しかし「逃げ道」を残す。プラットフォームから外れた使い方ができる
- Observable internals：内部状態が観測可能。ブラックボックスにしない
- Documentation that explains “why”：手順だけでなく「なぜこの設計か」を文書化する
- On-call ownership clarity：トラブル時に誰が一次対応するかが明確
第10話で扱う「Bottleneck化」アンチパターンは、Cognitive Leakage 対策が抜けたときに発生する。すべての異常がプラットフォームチームに飛び込んでくる構造を作ると、彼らがボトルネックになる。Self-Service と Escape Hatch を併設することが、これを防ぐ唯一の方法だ。
Conway’s Law と Inverse Conway Maneuver
組織と技術の同型性を語る上で外せないのが、1968年に Mel Conway が観察した法則だ。
Any organization that designs a system… will produce a design whose structure is a copy of the organization’s communication structure. — Mel Conway, 1968
組織の構造は、その組織が作るシステムの構造と同型になる。チーム間の境界が、サービス間の境界として現れる。コミュニケーションパスが API 境界として現れる。
Inverse Conway Maneuver は、この観察を逆向きに使う発想だ。望むアーキテクチャを先に決めて、それに合わせて組織構造を変える。Team Topologies は事実上「Inverse Conway Maneuver の実装ガイド」と位置づけられている。
ところがここに、よくある誤解がある。
❌ 「Inverse Conway Maneuver は組織変更ありき」
→ 「マイクロサービス化したいから、まず組織を機能別チームに分割しよう」
→ 組織を変えただけでは、システムは変わらない
✅ 「アーキテクチャと組織は反復的に共進化させる」
→ 望ましいアーキテクチャの方向性を決める
→ 既存組織のうち、その方向と矛盾するチーム境界だけを修正する
→ アーキテクチャの一部を変える
→ さらに矛盾するチーム境界を修正する
→ ...の繰り返しTeam Topologies の著者たちが繰り返し強調するのは、**Conway’s Law を「使い倒す」**ということだ。組織を一度に大改造するのではなく、Stream-aligned team / Platform team / Enabling team / Complicated-subsystem team という4チームタイプに 段階的にマッピングしていく。3 interaction mode を 段階的に整理していく。
第7話で見た カケハシの民主的アプローチ は、まさにこの段階的進化の典型だ。隔週30分のSRE横断定例で「共通言語化」してから、AWS命名規則の統一を合意し、RACI を整備していく。組織図の一斉変更ではなく、会話の積み重ねで組織と技術を共進化させている。
ハイブリッド型を Team Topologies で再解釈する
第7話で観察した「Platform SRE × Embedded SRE のハイブリッド型」を、Team Topologies の語彙で精密に書き直してみよう。
| 国内SaaS | Platform team | Enabling team | Stream-aligned team | Interaction modes |
|---|---|---|---|---|
| 10X | SRE（Terraformモジュール、SLO） | （明示的なEnablingは少ない） | プロダクト開発チーム | X-as-a-Service中心 |
| カケハシ | Platform SRE | Embedded SRE | プロダクトチーム | X-as-a-Service + Facilitating |
| Sansan | Platform Engineering Unit | Embedded SRE | プロダクトチーム + Bill One SRE | X-as-a-Service + Facilitating + Collaboration（横断チーム） |
| freee | Platform / Cloud Governance / DBRE | Enabling | プロダクト開発チーム | X-as-a-Service + Facilitating |
| Visional | プラットフォーム基盤推進室（ORE） | （事業内SRE Group） | 各事業のプロダクトチーム | X-as-a-Service中心 |
ここから読み取れることは2つある。
第一に、4チームタイプはほぼすべての国内事例に当てはまる。Team Topologies が提供する語彙は、現実の組織を観察するための強力なレンズだ。
第二に、国内事例では Enabling team の存在が際立つ。海外事例（Spotify、Netflix、Uber、Mercari）では Platform team 中心の語り口が多いが、国内では「Embedded SRE が教える側として動く」「横断会で合意する」といった Facilitating の文化が強い。第5話・第7話で観察した「形式的な権限委譲より会で合意する」日本的進化は、Team Topologies の Enabling + Facilitating の組み合わせとして再解釈できる。
これは Conway’s Law が逆向きに作用している例だ。日本の組織文化（合意形成・段階的変革・対話重視）が、Enabling 中心のチーム構造として現れていると言える。
✅ 良い設計 / ❌ 悪い設計
組織と技術を共進化させるときの典型的な誤解と、それを避ける選択を整理しておく。
❌ 悪い設計：
- 「マイクロサービス化したいから組織を機能別に分割する」
→ Inverse Conway Maneuver の誤用。組織変更だけでシステムは変わらない
- 「Cognitive load を一律に下げる」
→ Germane（ドメイン知識）まで隠してしまう。
開発者は自分のプロダクトで何を作っているか分からなくなる
- 「1チームの実例から共通基盤を作る」
→ 早すぎる抽象化。Wrong Abstraction の罠
- 「すべての関係を Collaboration（毎回打ち合わせ）にする」
→ 調整コストが認知負荷を圧迫する
- 「抽象を増やせば認知負荷は下がる」
→ ツールが増えるほど学ぶべきものも増える矛盾
✅ 良い設計：
- 「Extraneous Cognitive Load を選択的に削減する」
→ Intrinsic と Germane は残す。Terraformの細部のような外在的負荷だけ封じる
- 「3つの実例が出るまで抽象化を待つ」
→ Rule of Three。共通点と相違点を3例で見極める
- 「日常は X-as-a-Service、新規問題は Collaboration、学習は Facilitating」
→ 3 interaction mode を意図的に使い分ける
- 「TVPから始める。Wikiページ1枚も立派なプラットフォーム」
→ 最小限で価値が出る形を作って、需要があるところだけ厚くする
- 「Sensible defaults + Escape hatches」
→ Cognitive Leakage を見越して、逃げ道を残す設計次章へ
ここまで、Cognitive Load の3分類、Team Topologies の4チームと3 interaction mode、TVP、「3つの実例が出るまで抽象化を待つ」原則、Conway’s Law と Inverse Conway Maneuver を見てきた。
これらの設計原則を 失敗するとどうなるか を体系的に扱うのが、次の第10話だ。13個のアンチパターンを「症状・根本原因・脱出法」の3点セットで整理する。
- Field of Dreams：誰も使わないプラットフォーム
- Backstage導入で満足する：Portal-only Mindset
- Bottleneck化：プラットフォームチームが詰まる
- Cognitive load を下げるはずが上げてしまう：本章の延長線
- 他社模倣：Spotifyの解を20人のスタートアップに移植する罠
- Day 2を考えない：ローンチ後の劣化
これらは、本章で見た原則を守らなかったときに発生する具体的な失敗パターンだ。読者が自分の組織で「これが起きていないか」を観察するための診断道具として使ってほしい。
問い：あなたのチームが今背負っている認知負荷を、Intrinsic / Extraneous / Germane に分けるとしたら、どの割合になるか。Extraneous が3割を超えていたら、それはプラットフォームで構造的に削減できる対象だ。
参考文献
- Team Topologies (Skelton & Pais, 2019) — 4チームタイプ・3 interaction mode の理論的土台
- Team Topologies: What is a TVP? — Thinnest Viable Platform の定義
- Team Cognitive Load Assessment (GitHub) — 認知負荷測定ツール
- Martin Fowler: Conway’s Law — Inverse Conway Maneuver
- Martin Fowler: Team Topologies (bliki) — 解説
- Sandi Metz: The Wrong Abstraction (2014) — Prefer duplication over the wrong abstraction
- Thoughtworks: Cognitive leakage — 抽象が漏れる現象
- Joel Spolsky: The Law of Leaky Abstractions — Leaky Abstraction の古典
- Platform Engineering: Understanding Abstraction Layers — 「3つの実例が出るまで抽象化を待つ」原則
- DevEx: What Actually Drives Productivity (Noda et al., ACM Queue 2023) — Cognitive Load を含む3次元