エンジニア組織は「人を増やす」では伸びない。20人・50人・200人で変わるもの
エンジニアリング組織を大きくしようとするとき、多くのリーダーは反射的に「採用を増やす」と考える。だが人を足せば足すほど、調整(コーディネーション)のコストが膨らみ、増えた人数ぶんの成果が出ないことがある。Ido Green の記事「Ownership over hiring」は、スケールの本質は頭数ではなく**オーナーシップ(誰が何に責任を持つか)**を広げることだ、と論じている。
テックリードやマネージャーなら一度は当事者になる話で、しかも生成AIでコードが安く作れるようになった今こそ効いてくる視点でもある。以下、元記事の主張を自分なりに整理して紹介する。原文はこちら: https://greenido.dev/2026/06/11/what-changes-at-20-50-and-200-engineers/
増えるのは人だけではなく「調整税」
記事の核にあるのは、成長の各ステージで「新しい調整税(coordination tax)」が発生する、という見方だ。人が増えるほど、誰かと誰かが話を合わせる必要が増え、その手間が組織の成長スピードを上回り始めると、スケールはむしろ減速する。
Green が強調するのは、プロセスやツール、組織図そのものよりも、オーナーシップの明確さが決め手になるという点だ。エンジニアが「自分は何を所有しているのか、なぜそれを所有するのか、それが壊れたときに何が起きるのか」を理解している状態。これがあるかないかで、同じ人数でも組織の強さが変わる。
ここで面白いのが、規模が小さいうちは「多少の重複(ダブり)を許したほうが、新しい組織の境界線とそれに伴う調整コストを生むより安い」という指摘だ。きれいに分業することが常に正解ではない。境界を引くこと自体にコストがかかる。
生成AIはオーナーシップを不要にしない
もうひとつの軸が、生成AIとの関係だ。Green の立場ははっきりしている。AIによってコードの生成はほぼタダになったが、それはオーナーシップの重要性をむしろ高める。
コードが安く大量に出てくるほど、レビューし、保守し、アーキテクチャの一貫性を保つ仕事の比重が増すからだ。「コードを生成するのは今や安い。明確なオーナーシップを作るのは依然として高い」という一文が、記事全体を貫いている。
20人・50人・200人で何が変わるか
記事は組織規模を3つの節目に分けて、それぞれ何がボトルネックになるかを描く。
20人前後 スピードに全振りする段階
プロセスは最小限でいい。エンジニアは顧客と直接やり取りし、チームはサービスをエンドツーエンドで所有し、オンコール(障害対応当番)まで持つ。この段階では、共通基盤を作る「プラットフォームチーム」は時期尚早であることが多い、と Green は言う。まだ抽象化すべき共通項が固まっていないのに基盤を作ると、かえって足かせになる。
50人前後 調整税が顔を出す段階
これまで暗黙のうちに成立していたコミュニケーションが、意図的な努力なしには回らなくなる。プロセスが必要になるが、ここで「成熟した会社に見せたい」という動機でプロセスを入れると、形だけの(パフォーマティブな)ものになりがちだ。
この規模で新たなボトルネックになるのは、コードを書くことではなくコードレビューだ。論点は「どれだけ多く作れるか」から「その変更をどれだけ自信を持って出せるか」へ移る。
200人前後 組織設計そのものが勝負になる
リーダーの仕事が「開発を管理する」から「チームの集合体という系(システム)を管理する」へ変わる。拠点やタイムゾーンをまたいで調整コストが複利的に膨らむ。
この規模になって初めて、プラットフォームチームが経済的に意味を持つ。記事はおおよそ80〜100人を超えたあたりを目安として挙げている。そして上場後は外部への説明責任が加わり、スピードと予測可能性を同時に最適化することが求められる。スタートアップ的な機動力と、構造の両立という難題だ。
実務に効く4つの判断軸
記事から取り出せる、現場で使える指針をまとめておく。
プロセスは「症状」として扱う。 新しい手続きを提案するときは必ず「これは何の問題を解決するのか」と問う。プロセスは現実の問題から生まれるべきで、成熟して見せたいという願望から生まれてはいけない。
プラットフォームチームはゲートキーパーではなく加速装置にする。 エンジニアを「顧客」とみなす product team のように振る舞い、成功は顧客(=他チーム)の開発スピードや、障害対応がどれだけ改善したかで測る。
オンコールは組織の本音を映す検知器として読む。 アラートは実際に行動につながるものか、障害はチームに本当に「所有」されているか、ポストモーテムは実際の改善を生んでいるか。ここに、名目だけのオーナーシップか本物かが表れる。
上場後はスピードと予測可能性を同時に追う。 どちらか一方ではなく、構造とスタートアップ文化のバランスを意識して設計する。
読んでみての所感
私自身がこの記事で得心したのは、「重複を恐れすぎるな」という部分だ。境界を引いてきれいに分けることが、しばしば調整コストという見えにくい税を生む。早すぎる分業や早すぎるプラットフォーム化は、エンジニアならつい正義だと思いがちだが、規模に対して前のめりすぎると逆効果になる、という戒めとして読める。
生成AIの文脈も実感に近い。コードが安くなるほど、価値の重心は「誰がこれを保証し、面倒を見るのか」という人間側の責任に寄っていく。ツールが賢くなるほどオーナーシップ設計が効く、という主張は、これからのチーム運営を考えるうえで持っておきたい補助線だと思う 🧭
なお、本稿は記事の主張を要約・再構成したもので、規模の数字(20/50/80〜100/200)は元記事が挙げる目安であり、あらゆる組織に当てはまる絶対値ではない点は補足しておく。
出典: Ido Green「Ownership over hiring」。ニュースレター『Leadership in Tech』で紹介。原文: https://greenido.dev/2026/06/11/what-changes-at-20-50-and-200-engineers/