組織とチーム構造をどのように設計しますか？

Question

Accepted Answer

組織設計とは**一緒に変わる仕事が一緒に存在するようにチーム境界を引くこと**であり、速く変わるものについてのクロスチーム依存関係を最小化します。構造は戦略とシステムに従うべきであり、その逆ではありません。

## 原則

```text
1. TEAMS OWN OUTCOMES, not layers (a team owns a product/domain end to end)
2. MINIMIZE DEPENDENCIES — autonomous teams ship faster
3. CONWAY'S LAW — your architecture will mirror your org; design both together
4. CLEAR OWNERSHIP — every critical area has ONE owning team
5. RIGHT SIZE — ~5–9 people; two-pizza teams
6. COGNITIVE LOAD — don't give one team more domains than it can hold
```

## ストリーム指向思考

仕事のフローを所有する長期的でストリーム指向のチームを優遇し、プラットフォームチームが他のチームの認知負荷を軽減するようにします。気まぐれではなく、構造が仕事に逆らい始めたときに再編成します。

## 落とし穴

- **機能別サイロ化**（「QAチーム」「フロントエンドチーム」など）は、すべての機能が多くのハンドオフを通過することを強制します。
- **Conway の法則を無視する**ことで、アーキテクチャが組織図を反映することに驚きます。
- **常に再編成する**ことで、毎回信頼と所有権がリセットされます。
- **曖昧な所有権**では、すべてが「共有」であるため誰にも所有されていません。

## なぜ重要なのか

構造は速度を静かに決定します。

悪い境界は終わりのない調整会議と説明責任の曖昧さを生み出します。良い境界はチームが独立して動くことを可能にします。

Conway の法則のため、組織設計は*アーキテクチャ設計*です。

チーム境界を誤ると、どれだけエンジニアリングの努力を重ねてもシステムをクリーンにすることはできません。