数十人から数百人のエンジニアへと組織をスケールするにはどうすればよいか？

Question

Accepted Answer

数十人から数百人へのスケーリングは、滑らかな成長ではなく**一連のフェーズ変化**です。30人で機能することは100人で、そして再び300人で機能しなくなります。CTOは各段階で通信、意思決定、リーダーシップを再設計する必要があります。

## 考え方

```text
WHAT CHANGES AS YOU SCALE
- Communication: informal → structured (you can't all be in one room)
- Decisions: centralized → delegated to trusted leaders
- Structure: one team → domains → divisions/platforms
- Leadership: ICs → managers → managers-of-managers you must develop
- Process: ad hoc → lightweight standards & paved roads
```

制約要因は**製品を構築する**ことから**製品を構築する組織を構築する**ことへ移行します。

## 具体例

40人のエンジニアで個人的にすべての技術的決定を下していたCTOは、250人への道のりで、ディレクターを採用して育成し、意思決定権を定義してボトルネックにならないようにし、廊下での調整を明確なチームインターフェースとプラットフォームチームに置き換えます。

## トレードオフと落とし穴

- **落とし穴：** founder/CTOが委譲を拒否し、ボトルネックになる。
- **落とし穴：** 大企業のプロセスを丸ごとコピーして速度を落とす。
- 構造の層が増えるたびにオーバーヘッドが追加される；痛みの直前に追加し、前ではない。

## なぜ重要なのか

ほとんどの組織は、スケーリング時にエンジニアあたりの生産性を大幅に失い、時にはより多くの人数でより少なく出荷します。

フェーズ変化をうまくナビゲートし、委譲し、リーダーを育成し、自律性のために構造化することは、一部の企業が数百人で速く留まり、他社が停滞する方法です。

これはシニアテクニカルリーダーの最も難しく、最も定義的なテストの1つです。