10人から100人へ - エンジニア組織が壊れる瞬間と再生

コミュニケーションの経路数はN(N-1)/2で増える。10人のチームなら45通りで済む対話が、100人では4,950に膨張する¹。研究や業界レポートでは、ソフトウェア組織が規模を一桁伸ばす局面で、リードタイム（コードの変更が本番に届くまでの時間）や品質に関わる指標が悪化しやすいことが繰り返し報告されている²⁵。さらに、DevOps研究の代表的な調査では、短いリードタイムかつ高頻度デプロイの組織ほど、復旧時間（MTTR: Mean Time to Restore）が短く、変更失敗率も低い傾向が示されている³⁴。拡大は善でも悪でもない。ただ、構造が要請する現実がある。組織はアーキテクチャに影響し、アーキテクチャは組織を規定する。だから壊れる瞬間を見極め、再生の設計図を用意することが、経営と開発の両輪を前に進める唯一の方法になる。

壊れる瞬間はどこで起きるのか

エンジニア組織は10人前後の頃、口頭での調整と個人の機動力で回る。暗黙知が潤滑油となり、仕様の変更もその場で合意してすぐにコードに落とせる。しかし30人を過ぎると、同じやり方は急速に摩耗する。依存関係の未解消がリリース頻度の律速段階となり、QAやセキュリティレビューの待ち行列が可視化される。リードタイムはしばしば倍増し、重要なプロジェクトほど後半で遅延が累積する。この段階で典型的なのは、英雄的な個人に負債が集中し、意思決定が詰まり、障害時のエスカレーションが「その人待ち」になる現象だ。

研究データでは、マネージャーの健全なスパン・オブ・コントロール（1人が直接見る人数）はおおむね6〜8名に収斂する傾向がある⁶。100人規模で同じ意思決定速度を保つには、意思決定の粒度と権限の配置を再設計しなければならない。アイデアから本番反映までの経路に存在するハンドオフ（受け渡し）の回数が増えるほど、変更失敗率は上昇し、復旧に要する時間も延びる²。開発の健全性をモニターするなら、デプロイ頻度・変更のリードタイム・変更失敗率・MTTRという4指標を、客観的な「壊れ具合のセンサー」として置くのが出発点になる⁷。

暗黙知が毒に変わる瞬間

10人規模では、設計思想・運用ルール・例外処理が個人の頭の中にあっても大きな破綻は起きにくい。ところが100人では、同じ暗黙知が波及性の高い不整合を生む。APIの互換性ポリシーが口約束のまま変更されると、下流で障害が連鎖する。セキュリティレビューの基準が人ごとに違えば、製品ラインごとに脆弱性の分布が偏在する。暗黙知は摩擦を減らす潤滑油であると同時に、スケール時には見えない砂粒にもなる。

スパン・アンド・レイヤーの崩壊

100人規模で、1人のEM（Engineering Manager）が10名以上を直接見ると、1on1の頻度が月1以下に落ち、フィードバックが遅延する。技術意思決定のレイヤーが薄いまま人数だけ増えると、架空の「委員会」が乱立し、決めるための会議が成果物の代替物になる。決定権限と責任範囲を図式化し、非対称な依存を切ることが再生の起点になる。

スケールに耐える設計図：チーム設計×計測×信頼性

壊れ方は多様でも、再生の設計は共通化できる。キーワードはチームの種類とインタラクションの設計、計測の中枢化、そして認知負荷の削減だ。Team Topologiesは実務的なフレームで、基軸となるストリーム指向チームに、プラットフォームチーム、イネーブリングチーム、複雑サブシステムチームを必要に応じて配置する⁸。重要なのは名前ではなく、チームが担う価値の流れとインタラクションモード（X as a Service＝サービス提供、コラボレーション、ファシリテーション）を明示し、可能な限りX as a Serviceへ収束させることだ⁹。これにより、個々のチームの認知負荷（頭に載せる情報量）を一定に保てる。

計測の中枢には、開発速度と品質を同時に捉える4指標を置く⁷。現場のダッシュボードには、変更のリードタイム、デプロイ頻度、変更失敗率、MTTRを同じ縮尺で出し分ける。指標は飾りではなく、賭け方を変えるレバーだ。SREの実務で知られるSLO/エラーバジェットは、速度と信頼性のトレードオフを数値で表現する。目標を満たす余白が十分なら新規開発のスロットを広げ、超過したなら改修・品質改善に自動で切り替える。経営の意思決定も、感覚ではなくエラーバジェットの消費率と紐づけると、議論は原則ベースになる¹⁰。

アーキテクチャは組織図で決まる

コンウェイの法則を逆に使う。将来の望ましいアーキテクチャを先に描き、それに対応するチーム境界を設計する¹¹。ドメインごとに公開APIと変更契約（互換性ルール）を明確にし、段階的移行のパターン（フェーズドロールアウト、シャドートラフィック、カナリア）を共通言語にする¹²。CI/CDはゴールデンパス（推奨の最短経路）を提供することで、毎回の選択コストを削る。トランクベース開発（長期ブランチを作らず小刻みに統合）と小さなバッチを標準にすれば、失敗時の影響半径が小さくなり、MTTRは自然に短くなる²。

認知負荷を測る

認知負荷は感覚で語られがちだが、実は測れる。オンコールのページ件数、コンテキストスイッチの回数、必須ドキュメントの平均読了時間、レビュー待ちの滞留時間。「一週間、同じ目的のために手を止めずに働けたか」という問いを定点で回収するだけでも、ボトルネックの位置が見えてくる。プラットフォームは「最短で本番に価値を届ける」ための土木工事であり、採用広報ではない。便利さの証拠は利用率と通過時間に宿る⁸。

再生の実践：100人への移行を乗り切る

例えばBtoB SaaSでは、社員数が30人から80人へ伸びた頃に月次リリースへ後退し、障害対応に常時複数名が張り付く状態が続く、といった事象が珍しくない。延滞する案件は営業に跳ね返り、MRRやARRの伸びに影響が出ることもある。こうした局面で有効だった施策として、まずプロダクトの価値の流れに沿って、請求・データ連携・管理画面などのストリームに責任を割り振り、既存の横断チームは解体せずに役割を再定義するアプローチがある。SREを独立させ、SLOとエラーバジェットを導入し、障害の分類と復旧の自動化に投資する。プラットフォームは認証、観測基盤、デプロイの三本柱に絞り、他は奨励ではなく提供停止という厳しさで整理する¹⁰。

再生は人の動きから始まる。EMは6〜8名のスパンに再調整し、週次の意思決定フォーラムで、アーキテクチャに関わる論点だけを扱う場を分離する⁶。プロダクト側はベットサイズを小さくし、6週間のタイムボックスで価値を検証するサイクルを回す。加えて、ADR（Architecture Decision Record）で重要な判断を一枚に残し、議論の履歴を「探せる資産」に変える¹³。こうした取り組みを積み上げると、数週間〜数ヶ月のスパンで、月次から週次へのデプロイ改善や、リードタイムとMTTRの大幅短縮が実現する例も少なくない。営業の案件化リードタイムが短くなり、コスト・オブ・ディレイの削減が粗利率に反映されることも報告されている¹⁴。

意思決定の再配分

権限設計は、抽象語でなく日々の迷いを減らす粒度で書き下す必要がある。例えば、公開APIの互換性ポリシーは誰がどの条件で変えられるのか。SLO違反時に開発と信頼性のどちらを優先するかのルールは何か。「誰が、いつ、何をもって決めるか」を事前に明らかにしておくと、会議の数が減るだけでなく、決められない時間がなくなる。

プロセスは軽く、約束は強く

拡大の局面では、重たいプロセスを積み上げたくなるが、最終的に現場の速度を奪う。必要なのは、軽くて強い約束だ。レビューのSLI、テストの合格基準、ロールバックの所要時間、セキュリティ修正の最長放置時間。運用で守る約束を少数に絞り、破られた場合の自動アクションを仕込む。人の努力に頼らず、仕組みで律するほど、スケール時の品質は安定する¹⁰。

痛みを前提にした変革の進め方

変革には痛みがある。役割は広がり、過去の成功パターンは揺らぐ。だが、痛みのない変革は変革ではない。現実的な進め方は、まずスコープを薄く切り、成功の定義を先に決めることだ。4指標とSLOを起点に、達成すべき状態と期間を数値で合意する⁷¹⁰。そのうえで、ストリーム単位でパイロットを走らせ、結果を見て横展開する。広報ではなく内製の事実が人を動かす。コミュニケーションは、経営・EM・個々のエンジニアの三層で同じメッセージを繰り返す。採用もまたプロダクトだと捉え、キャリアラダーと評価基準を公開し、成果と成長の回路を透明化する。変化を「誰かの負担」ではなく「仕組みの移行」として扱うと、組織は自ずと前に進む。

ROIを経営の言葉に戻す

技術投資の価値は、開発内の効率ではなく、事業の遅延コストで測る。たとえば、リードタイム短縮が契約獲得の転換率をどれだけ押し上げ、期間内にどの程度のARRを前倒しできたか。障害復旧の自動化で失われた営業時間は何時間回復したか。技術の行動指針を、経営の数直線に正しく写像することで、変革は単発のプロジェクトから継続的な運動に変わる¹⁴。

まとめ：壊れる前提で、再生を設計しよう

10から100へ向かうチームは、必ずどこかで軋む。軋みは失敗ではなく、構造が拡張を求めている合図だ。4指標とSLOで現実を可視化し、Team Topologiesの考え方で認知負荷を一定に保ちながら、アーキテクチャと組織を同時に編み直す。暗黙知を設計に、努力を仕組みに、ヒーロー依存を再現性へ。今日できることは単純だ。現在の価値の流れを描き、チーム境界を言語化し、次の四半期で動く一つのパイロットを決める。あなたの組織はどの指標から手当てを始めるだろうか。小さく始め、早く計測し、成果で納得を積み上げよう。再生は、決意ではなく設計から始まる。

参考文献

1. Saket Bansal. How To Calculate Communication Channels? iZenBridge Blog. 2019. https://www.izenbridge.com/blog/how-to-calculate-communication-channels/
2. Nicole Forsgren, Jez Humble, Gene Kim. Accelerate: The Science of Lean Software and DevOps. IT Revolution, 2018.
3. Google Cloud. DORA | State of DevOps: Deployment frequency. https://cloud.google.com/resources/state-of-devops
4. Google Cloud. DORA | State of DevOps: Time to restore service and change failure rate. https://cloud.google.com/resources/state-of-devops
5. Puppet. State of DevOps Report. https://www.puppet.com/resources/report/state-of-devops-report
6. Chatwork BizX. 組織マネジメントにおける適正人数（スパン・オブ・コントロール）に関する解説記事. https://bizx-elb.chatwork.com/organization-management/number-of-people/
7. Google Cloud. DORAの4指標（Four Keys）に関する概要ページ. https://cloud.google.com/resources/state-of-devops
8. Matthew Skelton, Manuel Pais. Team Topologies: Four Fundamental Team Types. IT Revolution. https://itrevolution.com/articles/four-team-types/
9. Team Topologies 概要ページ（インタラクション・モード等）. https://www.hawkins.io/book/team-topologies/
10. Google SRE Book. Service Level Objectives とエラーバジェット. https://sre.google/sre-book/service-level-objectives/
11. Melvin E. Conway. How Do Committees Invent?（Conway’s Law）. https://melconway.com/Home/Committees_Paper.html
12. Google SRE Workbook. Canarying Releases. https://sre.google/workbook/canarying-releases/
13. Michael Nygard. Documenting Architecture Decisions. https://github.com/joelparkerhenderson/architecture_decision_record
14. Donald G. Reinertsen. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.