エンジニアリングチームをスケールさせる方法（すべてを破綻させずに）

約15人以上に成長したすべてのエンジニアリングチームは、同じ居心地の悪い過渡期を経験したことがあります。5人の頃、チームは迅速で、足並みが揃い、生産的でした。15人になる頃には、物事は明らかに遅くなっていました。30人になる頃には、メンバーは物を作るよりも調整することに多くの時間を費やすようになり、あらゆる問題に対する解決策は「もう一つ会議が必要だ」というものであるかのように思われました。

この時点で、大抵は文化やコミュニケーション能力、あるいは個人のパフォーマンスを非難したくなるのが本能です。しかし、実際の原因は構造的なものです。小規模チームを効果的にしていた仕組みはスケールせず、新しい仕組みへの意図的な投資がなければ、一人採用を増やすごとに既存のチームの生産性は徐々に低下していきます。これはブルックスの法則がリアルタイムで働いている状態であり、1975年から文書化されています。

幸いなことに、変曲点は予測可能であり、各段階での破綻を防ぐための投資は十分に理解されています。

ステージ1：5〜15人のエンジニア

5人のエンジニアの場合、チームは文脈の共有（コンテキスト）を通じて機能します。重要な決定はすべて、全員がその場に居合わせて行われました。全員がシステム全体を把握しています。コミュニケーションは有機的であり、距離の近さや日々の会話を通じて行われます。ドキュメント化は不要です。なぜなら、ドキュメントそのものがチームだからです。

10人から15人のエンジニアの間で、最初の亀裂が現れます。新しい採用者は初期の意思決定の場にいなかったため、創業エンジニアが暗黙のうちに持っている背景（コンテキスト）を持っていません。システムは、もはや単一の人物が完全に理解できるレベルを超えて成長しています。かつては隣の人に声をかければ解決していた疑問も、今では誰に聞けばいいのかを突き止める必要があります。

この段階で投資すべきこと：

文書化されたアーキテクチャの意思決定。 すべての重要な技術的選択は、その理由、検討された代替案、およびその決定を下すに至った制約とともに文書化されるべきです。これは今行うのは安価ですが、後から再構築するには途方もなく費用がかかります。アーキテクチャ設計書（ADR）の作成には15分しかかかりませんが、下流工程での意思決定の再審議に費やされる何時間もの時間を節約できます。

オンボーディング・ドキュメント。 システムの概要、スタートガイド、チームの規約ドキュメントは、これらを知っている人々がまだ周りにいて書くことができるうちに執筆してください。オンボーディングが遅れることによるコストは採用のペースに比例してスケールし、そのペースはまさにこれから加速しようとしています。

検索可能なナレッジシステム。 エンジニアリングの知識をどこに蓄積するか、早いうちに決定してください。Slackのスレッドや口頭での説明は残りません。既存のアクティビティから自動で作成されるWikiは、誰にも追加の作業を強いることなく知識をキャプチャできるため理想的です。

ステージ2：15〜30人のエンジニア

ここは、スケーリングの痛みが最も集中する場所です。チームは、暗黙知が自然に循環しなくなるほどには大きく、しかし、知識システムの欠如によって誰かがそれを構築せざるを得なくなるほどには小さいため、フォーマルなナレッジシステムが構築されていません。その結果、半年前には存在しなかった隙間から物事がこぼれ落ちてしまうという、苦痛に満ちた中間領域となります。

現れる兆候：

新しい採用者が読むべき包括的な資料がないため、オンボーディングに数週間ではなく数ヶ月かかるようになります。文脈の伝達を同期的に行う必要があるため、会議が急増します。シニアエンジニアは、特定の知識の唯一の情報源であるため、絶えず中断されるようになります。元の思考プロセスが記録されていないため、同じ決定が何度も議論されることになります。

この段階で投資すべきこと：

チームの境界とオーナーシップ。 明確なシステムオーナーシップを持つサブチームに分割します。Amazonの「2枚のピザチーム」モデルは機能しますが、それはチーム間のナレッジ層が十分に強固であり、チームAがチームBのシステムの状況を把握するために、チームBの作業を中断させる必要がない場合に限られます。

非同期第一のコミュニケーション規範。 文脈の共有や日常的な決定には、デフォルトで文書化された、検索可能なコミュニケーションを使用します。同期的な時間は、クリエイティブな仕事、対立の解決、および重要な決断のために確保します。分散型のチームにはこれが最も痛切に必要ですが、同じ場所にいるチームにも恩恵があります。

自動生成されるドキュメント。 この段階では、エンジニアリング活動（PR、Slackでの議論、ミーティング、設計決定）の量が、手動でドキュメント化できる範囲を超えてしまいます。GitHub、Slack、そして会議から自律的に作成・更新される自動ドキュメント生成こそが、開発スピードに合わせてスケールする唯一のアプローチです。

ステージ3：30〜50人以上のエンジニア

この規模になると、エンジニアリング組織はそれ自体が独立した組織となり、サブチーム、マネージャー、クロスファンクショナルな依存関係が存在し、多くのエンジニア同士が直接話したことがないほどの人数になります。

この段階での兆候は異なります：

チーム間のナレッジのサイロ化が、開発スピードにおける最大の制約になります。チーム横断的なプロジェクトには、広範な調整会議が必要になります。組織としての知識が、在籍期間の長い一握りのエンジニアに集中し、彼らの離職が深刻な混乱を招く原因となります。新メンバーの立ち上がりに時間がかかりすぎるため、チームの実質的な力は、 headcount（人員数）が示唆するよりも小さくなります。

この段階で投資すべきこと：

統合されたナレッジ層。 すべてのエンジニアリングの知識、アーキテクチャ文書、決定記録、システム文書、オンボーディングガイド、チームWikiは、一つの場所から検索可能であるべきです。チームAのエンジニアがチームBのシステムを理解する必要がある場合、会議を設定するのではなく、それを検索して解決できるようにすべきです。

ナレッジ保持システム。 50人以上のエンジニアがいると、離職は常に発生します。誰かが離職するたびに、その背景情報（コンテキスト）が失われます。日々のエンジニアリング活動から継続的に知識をキャプチャすることで、誰が出入りしてもドキュメントは残り続けます。知識が個人の頭の中ではなくシステム内に存在するため、属人性（バス係数）のリスクが減少します。

AI対応のドキュメント。 この規模になれば、エンジニアリングのワークフロー全体でAIツールをほぼ間違いなく使用しているはずです。これらのツールは、アクセスできる文書化された文脈（コンテキスト）と同等の質しか発揮できません。包括的で、最新で、検索可能なナレッジベースがあることで、社内のすべてのAIツールの効果が向上します。

直感に反する真実

最もよくスケールするチームは、最も早く採用するチームでも、最も経験豊富なエンジニアを擁するチームでもありません。彼らは、知識インフラが必要になる前に投資を行うチーム、特に人間の仲介者を必要とせずに知識にアクセスできるようにするチームです。

2026年の調査もこれを支持しています。構造化されたスケーリングアプローチに従った企業は、生産性向上までの時間を37%改善しながら、スケーリングコストを42%削減しました（Deloitte Tech Trends）。最も重要な構造は「知識の構造」です。なぜなら、それが新入社員がどれだけ早く生産的になるか、チームがどれだけ効果的に調整できるか、そしてシニアエンジニアの時間がどれだけ中断から守られるかを決定するからです。

これらの投資を行うのに最適な時期は、チームが成長し始める前でした。次に最適な時期は、次の変曲点が訪れる前の「今」です。

よくある質問

最初に投資すべき、最も重要なことは何ですか？ アーキテクチャ設計書（ADR）とシステムの概要文書です。これらは作成するのに数時間しかかかりませんが、意思決定の再審議を防ぎ、オンボーディング時間を短縮することで、下流工程で何百時間もの時間を節約できます。それ以外のすべてのこと（自動生成ドキュメント、正式なチーム境界、非同期の規範）は、この基盤の上に成り立ちます。

開発スピードを落とさずに、どうやってこれらの投資を行えばよいでしょうか？ これこそが重要な葛藤であり、だからこそ自動生成されるドキュメントが重要なのです。すでに発生しているエンジニアリング活動から自動的に生成されるドキュメントであれば、エンジニアが開発を止めてドキュメントを書き始める必要はありません。知識は、追加のタスクとしてではなく、業務の副産物としてキャプチャされます。

どれくらいのチーム規模からこれを意識し始めるべきでしょうか？ この投資は、早い段階（5〜15人）で行うのが最も安価で効果的です。通常、痛みは15〜30人で深刻になります。50人以上になると、遡及的な投資は高価で混乱を伴うものになります。もしこれを読んでいるあなたのチームが15人未満であれば、最適なタイミングにいます。

関連の読み物：ナレッジのスケーリング問題、今なお正しいブルックスの法則、なぜチームの開発スピードが遅くなるのか、エンジニアリング・オンボーディングの真のコスト。 関連ページ：自動生成ドキュメント、エンジニアリングチーム向け、ナレッジの保持。