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パイプライン、サービス所有権、書かれたランブック、レビュー規範が必要です。そうしないとチームはお互いに対立して停止します。
構造をちょうど良い時に追加
小さいチームに重いプロセスを押し付けないでください(彼らを息苦しくします)、大きいチームでスタートアップの非形式性にしがみつかないでください(崩壊します)。痛みが現れたときに各構造要素を追加し、理想的には少し前に。シグナルを観察してください:マージコンフリクト増加、知識のボトルネック、不安定なデプロイ。
