ConwayのLawとチームトポロジーはマイクロサービスをどのように形作るか？

Question

Accepted Answer

マイクロサービスは技術的な決定と同じくらい**組織的な**決定です。**Conwayの法則**は、システムはそれを構築する組織のコミュニケーション構造を反映する — つまり、チーム構造があなたの計画の有無にかかわらず、アーキテクチャを形作ります。

## なぜ重要なのか

```text
"Organizations design systems that copy their communication structure."

3 teams that don't talk  →  3 services with awkward, accidental seams
→ Inverse Conway Maneuver: design TEAMS around the architecture you want
```

## チームの所有権

各サービスには、それを構築、デプロイ、運用する**明確な所有チーム**が必要です(「あなたがそれを構築したら、あなたがそれを運用する」)。共有所有権は放置されたサービスにつながります。

```text
Orders team   ─owns─▶ Orders service (code + deploy + on-call)
Payments team ─owns─▶ Payments service
→ autonomy: each team ships without waiting on others
```

## Team Topologies

| チームタイプ | 役割 |
|---|---|
| Stream-aligned | 製品のスライスを所有(ほとんどのチーム) |
| Platform | セルフサービスインフラを提供(CI/CD、mesh) |
| Enabling | 他のチームをプラクティスでコーチ |
| Complicated-subsystem | 深い専門分野を所有 |

目標はクロスチーム**認知負荷**とハンドオフを最小化することです。

## 落とし穴

チームを再構築せずにマイクロサービスを採用すると、古い調整パターンがアーキテクチャに漏れるため、分散モノリスが生じます。

## なぜ重要なのか

チームが1つの機能をシップするために常に調整する必要がある場合、サービス図をいくらきれいに描いても、アーキテクチャはそのカップリングを反映します。

チーム境界をサービス境界と整合させる(逆方向のConway操作)は、マイクロサービスが約束する自律性と独立デプロイメントの利点を実際に提供するもの — 組織図は設計の一部です。

チームタイプ	役割
Stream-aligned	製品のスライスを所有(ほとんどのチーム)
Platform	セルフサービスインフラを提供(CI/CD、mesh)
Enabling	他のチームをプラクティスでコーチ
Complicated-subsystem	深い専門分野を所有