目次を表示する

共通基盤の設計軸 2026 ─ 抽象・責務・非機能要件を設計する 15 章

組織と境界 ─ Conway's Law / Team Topologies

組織と境界 ─ Conway’s Law / Team Topologies

技術的に優れた基盤を作っても、それを担う組織が機能しないと基盤は成功しない。逆に、組織の構造が基盤の構造を決める。これが Conway’s Law。

この章では組織側から共通基盤を見る。技術論ではない、だが技術論と同じくらい重要。

Conway’s Law（コンウェイの法則）

Melvin Conway 1968 年の論文 の有名な観察：

Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.

組織のコミュニケーション構造が、システム設計を決める。

例：

graph LR
  subgraph "5 つの開発チーム"
    T1[Team 1]
    T2[Team 2]
    T3[Team 3]
    T4[Team 4]
    T5[Team 5]
  end

  subgraph "出来上がるシステム"
    S1[Module 1]
    S2[Module 2]
    S3[Module 3]
    S4[Module 4]
    S5[Module 5]
  end

  T1 -.作る.-> S1
  T2 -.作る.-> S2
  T3 -.作る.-> S3
  T4 -.作る.-> S4
  T5 -.作る.-> S5

  Note1[境界が組織と一致する]

「3 つのチームでコンパイラを作ると、3 段階のコンパイラができる」と Conway 自身が言った。

Inverse Conway Maneuver

望むシステム構造を実現するために、組織を先に作り変える。

これが Inverse Conway Maneuver。「Platform Team を別チームとして作る」「Bounded Context を別組織にする」という動きはすべてこの戦略。

graph TB
  Want[望ましいシステム構造] --> Org[それに合わせて組織を再編]
  Org -. Conway's Law .-> System[組織通りのシステムが自然に出来る]

  style System fill:#e1ffe1

Team Topologies の 4 つの Topology

Skelton & Pais の Team Topologies は 組織パターンを 4 種類に分類：

graph TB
  S[Stream-aligned Team<br/>事業価値の流れに沿う]
  P[Platform Team<br/>共通基盤を提供]
  E[Enabling Team<br/>知識・スキルを伝える]
  C[Complicated Subsystem Team<br/>複雑な専門領域]

  P -. 提供 .-> S
  E -. 支援 .-> S
  C -. 専門サブシステム .-> S

  style S fill:#e1f5ff
  style P fill:#fff4e1
  style E fill:#e1ffe1
  style C fill:#ffe1e1

Stream-aligned Team

事業の stream（流れ） に沿ったチーム。注文ドメイン / 顧客ドメイン / マーケティングドメインなど。価値を直接届ける。

Platform Team

Stream-aligned Team の cognitive load を下げる ためのチーム。共通基盤を提供。直接価値を届けないが、間接的に価値を増幅する。

Enabling Team

専門知識（DevOps / Security / Mobile など）を stream-aligned team に伝える チーム。一時的にチームに入って支援する。知識転移が責務。

Complicated Subsystem Team

特殊な専門性が必要な subsystem（ML model、暗号モジュールなど）を担当。全社的に共有するが、Platform より深く専門的。

Platform Team の 3 つの責務

Team Topologies が定義する Platform Team の責務：

  1. TVP の提供（第 2 章で扱った Thinnest Viable Platform）
  2. Self-service の維持：利用者が依存ではなく on-demand で使える
  3. Continuous improvement：利用者のフィードバックで進化

これらが揃わないと、Platform Team は gatekeeper になり下がる。

Anti-pattern：Gatekeeper Platform Team

graph TB
  S1[Stream Team A] -- 「サービス追加お願いします」--> P[Platform Team]
  S2[Stream Team B] -- 「DB 追加お願いします」--> P
  S3[Stream Team C] -- 「環境変数変えてください」--> P
  P -- 「順番に対応します」--> Q[Queue が積み上がる]

  Note1[Platform Team が bottleneck になる]

  style Q fill:#ffe1e1

これでは Platform Team が遅延の原因 になる。Self-service が原則。

良い Platform Team

graph TB
  S1[Stream Team A] -- self-service --> P[Platform]
  S2[Stream Team B] -- self-service --> P
  S3[Stream Team C] -- self-service --> P

  PT[Platform Team] -. 改善・支援 .-> P
  PT -. office hour / docs .- S1
  PT -. office hour / docs .- S2

  Note1[Platform Team は基盤の改善に集中]

  style P fill:#e1f5ff
  style PT fill:#fff4e1

Platform Team は 基盤を改善・進化 することに集中し、利用者の作業を代行しない。

Platform-as-a-Product

Team Topologies “Platform as a Product”：

Platform を “プロダクト” として扱う。

社内 platform でも、Stream-aligned Team を 顧客（customer） と見て：

  • ロードマップを公開する
  • フィードバックを集める
  • バージョン番号を切る
  • ドキュメントを保守する
  • マーケティングする
  • KPI を計測する

外部公開 SaaS と同じ思考で運用する。

KPI の例

KPI意味
Adoption rate何チームが使っているか
Time-to-first-win新規利用者が最初の成功までの時間
NPS利用者の満足度
Self-service ratio利用者が基盤チーム介入なしに完結できる割合
Platform-induced incident基盤起因の障害件数
DORA metricsリリース頻度、リードタイム等

これらを定期的に dashboard / レポート で公開する。Platform Team の説明責任にもなる。

組織サイズと Platform の進化

組織のサイズで Platform の形が変わる。これは前作 Platform Engineering 実践地図 の主題でもある。本章では概観を：

サイズPlatform の形
〜10 人Platform は不要、shared utility で十分
10-50 人TVP（Wiki + 軽い script）でも価値出る
50-200 人Platform Team を切り出す、Backstage 検討
200-1000 人専属 Platform Team、IDP 構築
1000+ 人Multiple Platforms, Complicated Subsystem Teams

早すぎる Platform Team は失敗する。利用者が少ない / 用途が定まっていない段階で作ると、TVP すら定まらず空回りする。

“Platform” と “Bounded Context”

DDD の Bounded Context と Platform の関係：

graph TB
  subgraph "Bounded Context: 注文"
    O[Order Aggregate]
  end

  subgraph "Bounded Context: 顧客"
    C[Customer Aggregate]
  end

  subgraph "Bounded Context: 共通基盤"
    P[Platform: 認証 / 通知 / Logging]
  end

  O -.利用.-> P
  C -.利用.-> P

  style P fill:#e1f5ff
  • Platform は別の Bounded Context として扱う
  • 自分のドメイン（認証・通知・Logging のドメイン）を持つ
  • 他 Context は API 経由で利用 する（Repository 経由ではない、利用者ドメインの Aggregate を持たない）

これが前作 DB 設計の軸 2026 ch16 で扱った「Repository が DAO に堕ちる宿命」の組織側の説明。

Platform Team が陥る罠

罠兆候対策
Build-before-customer利用者がいないのに先に作る1-2 利用者と一緒に作る
Empire-building何でも platform で囲い込むTVP を守る、責務を奪わない
Tech-first利用者の声を聞かず技術選定NPS / フィードバックを取る
Gold-plating完璧を目指して出さないIteration 速度を優先
Lock-in利用者を逃がさない設計抜け道（raw API）を残す

これらは 技術的な問題ではなく、文化・運用の問題。Platform Team の自己批判が要る。

組織と境界のチェックリスト

graph TB
  Q1[Conway's Law を意識] --> Q2[Inverse Conway Maneuver]
  Q2 --> Q3[Team Topologies 適用]
  Q3 --> Q4[Platform-as-a-Product mindset]
  Q4 --> Q5[KPI 計測]
  Q5 --> Q6[Self-service 維持]
  Q6 --> Q7[Bounded Context として独立]
  Q7 --> OK[健全な Platform Team]

  style OK fill:#e1ffe1

この章の要点

  • Conway’s Law：組織のコミュニケーション構造がシステム構造を決める
  • Inverse Conway Maneuver：望むシステムに合わせて組織を作り変える
  • Team Topologies の 4 種類：Stream-aligned / Platform / Enabling / Complicated Subsystem
  • Platform Team の責務：TVP / Self-service / Continuous improvement
  • Anti-pattern: Gatekeeper Platform（bottleneck になる）
  • Platform-as-a-Product：プロダクトとして扱う、KPI で説明責任
  • 組織サイズで Platform の形が変わる、早すぎる Platform Team は失敗
  • Platform は別の Bounded Context として扱う

次章への問いかけ

組織が決まれば基盤も決まる。だが、根本的な問いをまだ立てていない。

そもそもこの基盤、作るべきなのか？ 最終章でその判断軸 + シリーズのまとめとして 外さない 8 軸 を提示する。