チームが成長する際に、エンジニアリングプラクティスをどのようにスケールしますか？

Question

Accepted Answer

3人のエンジニアで機能するプラクティスは30人で破綻します。インフォーマルな調整、暗黙知、手動プロセスはスケールしません。シニアTLは**成長カーブより先にプラクティスを進化させ**、官僚的にならないよう十分な構造を形式化する必要があります。

## スケールが必要な領域

```text
✓ CI/CD — fast, reliable, automated; manual deploys don't survive growth
✓ TESTING — automated suites; you can't manually verify everything
✓ CODE REVIEW — clear norms, reasonable turnaround, ownership boundaries
✓ DOCUMENTATION — written knowledge replaces "ask Bob"
✓ ONBOARDING — repeatable, not bespoke per hire
✓ DECISION-MAKING — clear ownership; who decides what
✓ ON-CALL / OWNERSHIP — defined, rotated, not heroic
```

## 具体例

5人なら全員がシステム全体を理解し、手作業でデプロイします。25人になるとカオスになり、真のCI/CDパイプライン、サービス所有権、書かれたランブック、レビュー規範が必要です。そうしないとチームはお互いに対立して停止します。

## 構造をちょうど良い時に追加

小さいチームに重いプロセスを押し付けないでください（彼らを息苦しくします）、大きいチームでスタートアップの非形式性にしがみつかないでください（崩壊します）。痛みが現れたときに各構造要素を追加し、理想的には少し前に。シグナルを観察してください：マージコンフリクト増加、知識のボトルネック、不安定なデプロイ。

## トレードオフ

プロセスが多いほど、柔軟性が一貫性とスケーラビリティと交換されます。少なすぎるとチームが混乱し、多すぎるとあなたを成功させた速度が失われます。継続的に調整してください。

## なぜ重要なのか

小さいチームを成功させたプラクティスは、より大きいチームを積極的に窒息させます。

プラクティスを積極的にスケールさせるTLは成長するチームを速く保ちます。そうしないTLは、チームが成長するにつれてvelocityが崩壊するのを見ます。これがスケーリングの古典的な罠です。