TL;DR（この記事の要約）

• エンジニア組織のスケーリングは「人を増やす」だけでは破綻する。フェーズごとに採用戦略・マネジメント体制・評価制度をセットで設計する必要がある

• 10人以下のシード期は「カルチャーフィットと技術の幅」、30人前後の成長期は「専門職と中間マネジメントの確保」、50人超の拡大期は「採用の仕組み化と組織設計」が最重要テーマ

• 30人の壁・50人の壁を乗り越えるには、EMやテックリードの採用を先行させることが鍵

• 急拡大のフェーズでは採用スピードと品質のトレードオフが発生しやすい。構造化面接と評価基準の標準化で質を担保する

• 採用だけでなくオンボーディングと定着施策をセットで回すことで、拡大期の離職率上昇を防げる

エンジニア組織のスケーリング採用戦略｜10人→100人の成長フェーズ別ガイド

「エンジニアを10人から30人に増やしたら、なぜか開発速度が落ちた」「50人を超えたあたりから退職者が増え始めた」

スタートアップの経営者やVPoEがよく口にするこの課題。実はエンジニア組織の拡大で起きる問題の多くは、採用の量ではなく「スケーリングの設計」が不足していることに原因がある。

人を増やせばプロダクト開発が加速する——この前提は、一定規模を超えると通用しなくなる。組織が大きくなるほどコミュニケーションコストは指数関数的に増え、意思決定は遅くなり、カルチャーは希薄化する。

この記事では、エンジニア組織を10人から100人超へスケールさせる際に、各フェーズで何を優先し、どんな人材を採用し、どう体制を整えるべきかを実践的に解説する。

このページでわかること:

• エンジニア組織のフェーズ別（10人以下・10〜30人・30〜50人・50〜100人超）の採用戦略

• 「30人の壁」「50人の壁」を乗り越えるための具体的な施策

• 急拡大期の採用品質を維持する仕組みの作り方

• スケーリングに耐えるマネジメント体制と評価制度の設計

• 拡大期に離職率を上げないためのオンボーディング・定着施策

1. エンジニア組織のスケーリングが難しい構造的な理由

なぜ「人を増やす＝開発力アップ」にならないのか

フレデリック・ブルックスが『人月の神話』で指摘した通り、ソフトウェア開発チームに人を追加しても生産性は線形に伸びない。むしろ短期的には下がることすらある。

その理由はシンプルだ。

• コミュニケーションパスの爆発: n人のチームでは最大 n(n-1)/2 の1対1の関係が生まれる。10人なら45通り、30人なら435通り、100人なら4,950通り

• コンテキスト共有のコスト: 新メンバーが「自走」できるまでの立ち上がり期間、既存メンバーのメンタリング工数が発生する

• 意思決定の遅延: 関係者が増えるほど合意形成に時間がかかり、小回りが利かなくなる

• カルチャーの希薄化: 暗黙知で共有されていた開発文化が、人数増加に伴い伝わりにくくなる

スケーリングに必要な3つの軸

エンジニア組織を健全にスケールさせるには、採用・体制・制度の3軸を同時に回す必要がある。

この3軸のどれかが欠けると、採用しても定着しない、体制は作ったが評価がないので不満が溜まる、制度はあるがチーム構造がフィットしない——といった問題が起きる。

2. フェーズ1：シード期（〜10人）の採用戦略

このフェーズの特徴

エンジニアが創業メンバー含め数人〜10人程度。全員がフルスタック寄りで、技術選定からインフラ構築、フロントエンド開発まで幅広く担う。コミュニケーションは口頭やSlackで完結し、ドキュメントは最小限。

採用で最も重視すべきこと

技術の幅 × カルチャーフィット × 自走力。 この3つが揃った人材を妥協なく採る。

シード期の1人の採用ミスは致命的だ。10人のチームで1人が機能しなければ、チーム全体の10%がロスになる。100人の組織なら1%で済むが、初期フェーズでは取り返しがつかない。

シード期に採用すべき人材像:

• 特定の専門領域を持ちつつ、隣接領域もカバーできるT字型スキル

• 「これは自分の仕事じゃない」と言わない当事者意識

• 0→1のプロダクト開発経験（既存の仕組みがない環境で成果を出せる）

• 創業者のビジョンに共感し、不確実性を楽しめるマインドセット

採用チャネルの使い分け

シード期は採用専任がいないことがほとんど。CTOや創業者が自ら採用活動を行うケースが多い。

リファラルが最優先だが、「知り合いだから」で採用基準を甘くするのは禁物だ。友人でも同じ基準で選考し、入社後のギャップを防ぐ。リファラル採用の制度設計についてはエンジニア採用を加速させるリファラル制度の作り方と成功事例で詳しく解説している。

シード期の求人票で伝えるべきこと

シード期のスタートアップは知名度がない。だからこそ、求人票（JD）で「なぜこの会社で働く価値があるのか」を具体的に伝えなければならない。

• 解決しようとしている課題の大きさ: 「XX業界のYYという課題を解決する」——市場規模と課題の具体性を示す

• 技術的なチャレンジ: 「ゼロからアーキテクチャを設計できる」「技術選定の裁量がある」

• チームの構成と人柄: 「元XX社のCTOが率いる3人のチーム」——誰と働くのかが最大の判断材料

• ストックオプションを含む報酬の全体像: 基本給だけでなく、SOの付与割合と想定リターンを正直に伝える

求人票の詳しい書き方はエンジニアが応募したくなる求人票（JD）の書き方完全ガイドを参照してほしい。

シード期のアンチパターン

• 「いい人がいたら採る」の受け身スタンス: シード期こそ経営者が能動的に採用に動くべき。プロダクトロードマップに紐づいた採用計画を立てる

• 「安く採れる人」を優先する: シード期のエンジニアは組織のDNAを作る存在。報酬をケチると後で大きなツケを払うことになる

• 全員同じタイプの人材を揃える: 技術の幅を確保するために、得意領域が異なるメンバーを意図的に採用する

• リファレンスチェックを省略する: 少人数だからこそ1人の影響が大きい。前職の同僚に仕事ぶりを確認する手間を惜しまない

• カジュアル面談を飛ばしていきなり選考に入る: シード期の候補者は「この会社、本当に大丈夫か？」という不安を抱えている。まずはカジュアルに会社のビジョンを伝え、候補者の疑問に丁寧に答える場を設けることが重要だ

3. フェーズ2：初期成長期（10〜30人）の採用戦略

このフェーズの特徴

プロダクトマーケットフィット（PMF）が見え始め、機能追加や新規プロダクト開発のために人員を急拡大するフェーズ。シリーズA〜Bの資金調達後にこのフェーズに入ることが多い。

「口頭で伝わっていた」ことが伝わらなくなり、チーム分割の必要性が出てくる。CTOが全メンバーを直接マネジメントする限界が見え始めるタイミングでもある。

「30人の壁」の正体

30人の壁とは、以下のような問題が同時多発的に起きる状態を指す。

• CTOのマネジメント限界: 1人で10〜15人を超えるメンバーを見るのは現実的に困難。1on1、目標設定、評価、採用面接——CTO1人では回らなくなる

• 暗黙知の崩壊: 「うちではこうやる」というルールが文書化されておらず、新メンバーが迷子になる

• チーム間のサイロ化: チームを分割した途端、チーム間の情報共有が滞り始める

• 採用品質のばらつき: 面接官が増えるほど、評価基準にばらつきが出る

このフェーズで採用すべき人材

最優先: 最初のエンジニアリングマネージャー（EM）

30人の壁を突破するための最重要採用がEMだ。CTOがピープルマネジメントから解放され、技術戦略やアーキテクチャに集中できるようになる。

EMに求める要件:

• 5〜10人のエンジニアチームのマネジメント経験

• 1on1・目標設定・評価のスキル

• 採用面接の設計・実施経験

• 技術的なバックグラウンド（コードレビューができるレベル）

EMの採用についてはCTO・VPoE・EM採用を成功させるエンジニアリングマネージャー採用ガイドで詳しく解説している。

次に優先: テックリード

チームを機能別（バックエンド/フロントエンド/インフラなど）またはプロダクト別に分割する際、各チームの技術的な意思決定者としてテックリードが必要になる。

テックリードに求める要件:

• 担当領域での設計・実装のリード経験

• コードレビューを通じたチームの技術力底上げができる

• プロダクトマネージャーやデザイナーとの折衝・調整力

• ジュニアメンバーへのメンタリング意欲

テックリードはEMと違いピープルマネジメントを主務としない。しかし、技術的な意思決定を通じてチームの方向性を示す役割であるため、コミュニケーション力と影響力が必須だ。

専門職の採用開始

シード期はフルスタック寄りの人材で回していたが、このフェーズからは専門性の高い人材が必要になる。

• SRE/インフラエンジニア: ユーザー数の増加に伴い、可用性・パフォーマンスの要求が高まる。CI/CD基盤の整備やモニタリング体制の構築を担う。SRE・インフラエンジニア採用の完全ガイドも参考に

• QAエンジニア: テスト自動化・品質保証の仕組みづくり。手動テストの属人化を解消する

• セキュリティエンジニア: 顧客データ増加に伴うセキュリティ体制強化。SOC2やISMSの取得を見据えた体制づくり

チーム分割の設計

10人を超えたら、2〜3チームへの分割を検討する。分割の軸は大きく2パターン。

パターン1: 機能軸（レイヤー別）

• バックエンドチーム / フロントエンドチーム / インフラチーム

• メリット: 技術的な専門性を高めやすい

• デメリット: チーム間の調整コストが増える

パターン2: プロダクト軸（フィーチャーチーム）

• プロダクトA チーム / プロダクトB チーム / 基盤チーム

• メリット: エンドツーエンドで開発完結、自律性が高い

• デメリット: 技術的な統一性が保ちにくい

一般的に、プロダクト軸の方がスケーリングに向いている。各チームが独立して意思決定・デリバリーできるため、人数が増えてもコミュニケーションコストが爆発しにくい。

ドキュメント文化の立ち上げ

10人まではSlackでの口頭伝達で回っていたことが、チーム分割後は通用しなくなる。このタイミングでドキュメント文化を意図的に作る必要がある。

最低限整備すべきドキュメント:

• アーキテクチャ概要図: システム全体の構成と各コンポーネントの役割

• ADR（Architecture Decision Records）: 技術的な意思決定の経緯と理由を記録

• 開発環境セットアップ手順: 新メンバーが1日目にローカル環境を構築できるレベルの詳細さ

• コーディング規約・レビュー基準: チーム間で品質基準を揃える

• インシデント対応マニュアル: 障害発生時の連絡フロー・初動対応手順

ドキュメントは「書いて終わり」ではなく、PRのテンプレートにドキュメント更新のチェック項目を入れるなど、メンテナンスの仕組みもセットで整備する。

採用体制の強化

このフェーズからは、CTOや創業者だけで採用を回すのは無理がある。

• 採用担当の専任化: 人事専任がいなければ、業務委託でもいいのでリクルーターを確保する

• 面接官のトレーニング: EMやテックリードが面接を担当するなら、評価精度を高める面接官トレーニングが必須

• 構造化面接の導入: 面接官ごとの評価ブレを防ぐために、構造化面接の設計を進める

4. フェーズ3：急成長期（30〜50人）の採用戦略

このフェーズの特徴

月に3〜5人ペースでエンジニアが入社する急拡大期。採用、オンボーディング、チーム再編が同時並行で進む。シリーズB以降の企業に多い。

このフェーズで最も起きやすい問題は、**「採用は順調だが、組織としてのパフォーマンスが落ちている」**という状態だ。

急成長期の3大課題

課題1: 採用品質の低下

採用人数のプレッシャーから、選考基準を無意識に下げてしまうケースが非常に多い。「ポジションが空いているから」「応募が来たから」で採用を進めると、半年後に大量離職という最悪のシナリオに陥る。

対策:

• 採用基準をスコアカード化して全面接官で共有する: 「なんとなく良い」ではなく、5段階評価の具体的な行動指標を設定する。たとえば「コーディング力: 3点 = 主要言語で標準的な課題を自力で解ける」「5点 = 複雑な問題に対して最適なアルゴリズムを選択し、エッジケースも網羅できる」といった粒度で定義する

• バーレイザー制度の導入: Amazonが実践する手法で、採用チーム外の第三者が「この人は現メンバーの上位50%に入るか」をチェックする。バーレイザーが「NO」と判断した場合は採用しない、という明確なルールを設ける

• 不採用理由の記録と振り返り: 月次で採用委員会を開き、判断基準のキャリブレーションを実施する。「先月の不採用者10名の理由を振り返り、基準にブレがなかったか」を確認する

課題2: オンボーディングの破綻

月に数名が入社する状況では、個別対応のオンボーディングは回らなくなる。「入社して1か月経ったが、まだ環境構築が終わっていない」「メンターが忙しくて放置されている」——こうした状態が常態化すると、新メンバーの早期離職に直結する。

対策:

• オンボーディングの型化: 入社初日・1週目・2週目・1か月目のマイルストーンを定義

• バディ制度: メンターとは別に、気軽に質問できるバディ（同僚）をアサイン

• セルフサーブ型のドキュメント整備: 開発環境構築手順、アーキテクチャ概要、コーディング規約を1か所にまとめる

オンボーディングの詳細はエンジニアのオンボーディング完全ガイドを参照してほしい。

課題3: ミドルマネジメントの不足

30人を超えると、EMが1〜2人では足りなくなる。EM1人あたりの適正な直属メンバーは5〜10人。30人の組織なら最低3人、50人なら5人以上のEMが必要だ。

ところが、EMの採用は難易度が高い。技術力とマネジメント力を兼ね備えた人材は市場に少なく、年収レンジも高い。

対策:

• 内部昇格の仕組みを作る: テックリードの中からマネジメント適性のある人材をEM候補として育成する

• 外部採用と内部昇格を併用: 全員を外部から採るのは非現実的。内部昇格7割、外部採用3割くらいのバランスが目安

• EM候補にマネジメント研修を提供: 1on1のやり方、フィードバックの技法、目標設定（OKR/MBO）の設計を体系的に学ぶ機会を作る

採用チャネルの多角化

10〜30人フェーズではリファラルとダイレクトスカウトが中心だったが、月3〜5人の採用ペースを維持するにはチャネルの多角化が必須になる。

採用チャネルの最適な選び方はエンジニア採用媒体の選び方を参考にしてほしい。

5. フェーズ4：拡大期（50〜100人超）の採用戦略

このフェーズの特徴

エンジニア組織が50人を超えると、「スタートアップの延長線」ではなく組織として設計する必要が出てくる。属人的な運用は限界を迎え、制度・プロセス・ツールによる仕組み化が求められる。

「50人の壁」を乗り越える組織設計

VPoE/VP of Engineeringの設置

50人を超えたら、エンジニア組織全体を統括するVPoEの配置を検討する。CTOが技術戦略・アーキテクチャに集中し、VPoEがピープルマネジメント・採用・評価制度を担う「CTOとVPoEの分業モデル」は、多くの成長企業が採用している形態だ。

チーム構造の再設計

50〜100人規模では、以下のような階層構造が一般的になる。

ポイントは、1チーム5〜8名を維持すること。Amazonの「Two-Pizza Team」（ピザ2枚で足りるサイズ）は有名だが、実際に機能するチームサイズはこの範囲に収まることが多い。

エンジニアラダー（キャリアパス）の整備

50人を超えると、「どうすれば昇進できるのか」「自分のキャリアはどこに向かうのか」という疑問が噴出する。等級制度とキャリアパスが明文化されていないと、優秀なエンジニアから辞めていく。

• IC（Individual Contributor）トラック: ジュニア → ミドル → シニア → スタッフ → プリンシパル

• マネジメントトラック: TL → EM → シニアEM → VPoE

両トラックの報酬レンジを揃え、「マネージャーにならないと年収が上がらない」問題を解消することが重要だ。キャリアパス設計の詳細はエンジニアのキャリアパス設計で採用力と定着率を高める実践ガイドを参照してほしい。

採用の仕組み化

月5〜10人ペースの採用を回すには、属人的な採用活動では限界がある。

ATSの本格導入

候補者管理、面接スケジュール調整、評価記録をATSで一元管理する。50人超の採用規模では、スプレッドシート管理はもう通用しない。ATSの選び方はエンジニア採用に最適なATSの選び方と運用ガイドで解説している。

採用KPIダッシュボードの構築

以下のKPIを週次でモニタリングする。

KPIの設計と運用についてはエンジニア採用KPI完全ガイドで詳しく解説している。

採用委員会の設置

週次の採用委員会で以下を議論する。

• 各ポジションの進捗状況

• ボトルネックの特定と対策

• 面接評価のキャリブレーション

• パイプラインの充足度

採用ブランディングへの投資

50人を超えると、「知名度がないから採れない」問題が顕在化する。この段階で採用ブランディングに本格投資する企業と、しない企業では、1年後の採用力に大きな差がつく。

• テックブログの定期発信: 月2〜4本のペースで技術記事を公開する。単なる技術Tipsだけでなく、「なぜその技術選定をしたのか」「どんな課題をどう解決したのか」というストーリーを発信する。テックブログでエンジニア採用力を高める技術広報の始め方ガイドを参考に

• カンファレンス登壇・スポンサー: エンジニアが外部カンファレンスで登壇することで、技術力のアピールと認知拡大を両立する。登壇を「業務」として認め、準備時間を業務時間内で確保する制度があると、エンジニアの登壇意欲が高まる

• 採用ピッチ資料の整備: 候補者向けの会社紹介資料を作成し、カジュアル面談で活用する。技術スタック、開発プロセス、チーム構成、キャリアパス、報酬体系を1つの資料にまとめる。エンジニア向け採用ピッチ資料の作り方も参考にしてほしい

• SNS・ソーシャルリクルーティング: X（Twitter）やLinkedInでの発信を組織的に行う。エンジニア個人の技術発信を推奨し、会社のアカウントと連携させる。詳しくはエンジニア採用のSNS活用完全ガイドを参照

• OSS活動の推進: 自社プロダクトの一部をOSSとして公開する、既存OSSへのコントリビュートを業務として認める、といった取り組みがエンジニアコミュニティでの認知度を高める

6. スケーリング期の報酬戦略と人材獲得競争

成長フェーズ別の報酬設計

組織のフェーズによって、報酬戦略も変わる。

シード〜シリーズA（〜10人）

• 市場相場の80〜90%の基本給 + ストックオプション（SO）で総報酬を補う

• SOの付与比率は初期メンバーほど高く設定（0.1〜1.0%程度）

• 「将来のアップサイド」を語れることが採用上の武器

• 福利厚生は最小限でいい。代わりに「技術書購入補助」「カンファレンス参加費全額負担」など、エンジニアが直接恩恵を感じる制度を優先する

シリーズA〜B（10〜30人）

• 市場相場の90〜100%の基本給を目指す

• SOの付与比率は下がるが、会社の成長ストーリーで補完

• 評価制度の導入に合わせて、昇給の仕組みを明文化する

• 年次の報酬見直しサイクルを導入し、「いつ・どの基準で昇給するか」を透明化する

シリーズB〜C（30〜100人超）

• 市場相場の100〜110%の基本給が必要になるケースが多い

• RSU（譲渡制限付き株式ユニット）への移行を検討する企業も

• EMやスタッフエンジニアなどハイレイヤーは個別交渉が発生しやすい。報酬バンドの上限を柔軟に設定できるようにしておく

• 競合他社のオファーに対抗するためのカウンターオファー基準を事前に定めておくと、意思決定が速くなる

報酬設計の詳細はエンジニア採用で勝つための報酬設計と年収戦略の完全ガイドを参照してほしい。

大手テック企業との人材獲得競争

50人を超えたあたりから、メガベンチャーやGAFAMとの人材獲得競争が本格化する。報酬だけで勝負するのは現実的ではない。

報酬以外の差別化ポイント:

• 技術的なチャレンジの大きさ: 「大企業では味わえない0→1の経験」「プロダクトの根幹に関われる」

• 意思決定のスピードと裁量: 「提案した翌週には実装に着手できる」

• 成長環境: 「急成長フェーズの組織作りに関われる」「半年でチームリードに」

• カルチャーフィット: 「このメンバーと一緒に働きたいと思える」

EVP（従業員価値提案）を明文化し、採用活動の全タッチポイントで一貫したメッセージを発信することが重要だ。エンジニア採用EVP設計ガイドで具体的な手順を解説している。

副業・業務委託の戦略的活用

急拡大期に正社員だけで人員を充足させるのは難しい。副業・業務委託エンジニアの活用は、採用のボトルネックを緩和する有効な手段だ。

• 専門性の高い領域（SRE、セキュリティ、データ基盤など）を業務委託で補う: 正社員採用が難しいポジションは、まず業務委託で技術力を確保しながら、並行して正社員採用を進める

• 「お試し転職」としての業務委託: 候補者と企業の双方がフィット感を確認してから正社員オファーに移行する。入社後のミスマッチを大幅に減らせる

• 業務委託→正社員のコンバージョン設計: 業務委託期間中の評価基準、正社員への転換条件、報酬の調整方法を事前に設計しておく

副業・業務委託の活用方法については副業・業務委託エンジニアの活用で採用力を強化する完全ガイドで詳しく解説している。

7. スケーリングを支える採用プロセスの設計

フェーズ別の選考プロセス設計

組織の規模に応じて、選考プロセスも進化させる。

シード期（〜10人）: シンプル＆スピード重視

成長期（10〜30人）: 技術評価の深化

拡大期（30人〜）: 構造化＆標準化

ポイントは、フェーズが進んでも選考リードタイムを4週間以内に収めること。候補者は複数社を並行して受けている。選考が長引けば、他社にオファーを出された時点で離脱される。選考スピードの改善についてはエンジニア採用リードタイム短縮ガイドを参考にしてほしい。

面接評価の標準化

組織が大きくなるほど、面接官の数も増える。面接官ごとの評価基準がバラバラだと、採用品質は維持できない。

スコアカードの設計例:

各項目を1〜5段階で評価し、合計スコアと面接官のコメントを記録する。月次で面接官同士のキャリブレーション会議を実施し、「3点の基準がAさんとBさんでズレていないか」を確認する。

採用における現場エンジニアの巻き込み方

スケーリング期は面接の負荷が現場エンジニアに集中しがちだ。週に3〜4件の面接が入ると本業の開発に支障が出る。

負荷を分散する仕組み:

• 面接官のローテーション制: 全エンジニアが月1〜2回面接を担当する仕組みにする

• 面接官の稼働上限を設定: 週2件まで、など明確なルールを決める

• 面接への参加を評価に反映: 採用活動への貢献を人事評価に組み込む

• カジュアル面談の分業: エンジニアはカジュアル面談を担当しない、などリクルーターと役割を分ける

8. 急拡大期に離職率を上げないための定着施策

なぜ急成長期に離職が増えるのか

急拡大するエンジニア組織では、以下の理由で離職率が上昇しやすい。ソフトウェアエンジニアの年間離職率は一般的に20〜25%程度と言われており、急成長期にはこの数値がさらに上振れする傾向がある。

• 「自分の居場所がなくなった」感覚: シード期から在籍する古参メンバーが、組織の変化についていけず疎外感を感じる。「あの頃の方が楽しかった」という声が出始めたら危険信号だ

• マネジメントの質の低下: 急造EMの経験不足により、メンバーのケアが行き届かない。1on1が形骸化したり、評価に対する不満が蓄積する

• 技術負債の蓄積: 急ピッチの開発で負債が溜まり、「この会社では良い技術経験が積めない」と感じるエンジニアが出てくる。特にシニアエンジニアほどこの問題に敏感だ

• 採用ミスによる組織文化の変容: 基準を下げた採用が文化を壊し、「前のほうが良かった」と思う人が辞める。1人の不適切な採用が、周囲の3〜5人の離職を引き起こすこともある

• キャリアパスの不透明さ: 組織が急拡大する中で「自分は今後どうなるのか」が見えなくなる。等級制度や昇進基準が整備されていないと、外部にキャリアの可能性を求め始める

定着率を維持するための具体的施策

1. 1on1の仕組み化

EMとメンバーの1on1を最低隔週で実施する。1on1の内容は以下の3テーマでローテーション。

• キャリア・成長（月1回）: 中長期のキャリア目標と現在のギャップ

• 業務・パフォーマンス（隔週）: タスクの進捗、ブロッカーの解消

• コンディション（随時）: モチベーション、チームの雰囲気、困りごと

2. エンゲージメントサーベイの導入

四半期に1回、匿名のエンゲージメントサーベイを実施する。以下の項目をスコアリング。

• 仕事のやりがい

• チームの心理的安全性

• マネージャーへの信頼

• キャリア成長の実感

• 報酬への納得感

スコアが前回から大幅に下がったチームには、VPoE/EMが介入してヒアリングを行う。

3. 技術負債の計画的返済

開発リソースの15〜20%を技術負債の返済に充てるルールを設ける。「新機能開発だけが評価される」状態を避け、リファクタリングやテスト基盤の改善も正当に評価する。技術負債と採用力の関係については技術負債が採用力を蝕む？エンジニア採用と技術負債の関係と対策ガイドで詳しく解説している。

4. 古参メンバーへのケア

シード期から在籍するメンバーは、組織の急拡大に最もストレスを感じやすい。

• 組織変更の際は事前に個別で相談する。全体アナウンスの前に、影響を受けるメンバーには1on1で丁寧に説明する

• 新しい役割（テックリード、アーキテクトなど）を提示する。組織拡大は古参メンバーにとってキャリアアップの機会でもある

• 「変わること」だけでなく「変わらないこと」（技術的なこだわり、カルチャーの核）も明確にする

• 古参メンバーを新メンバーのメンターやオンボーディングバディに起用し、組織の中での存在価値を再確認できる機会を作る

5. 退職予兆の早期検知

以下のシグナルが見られたら、EMやVPoEが早期に介入する。

• 1on1でのフィードバックが急に減った（諦めの兆候）

• コードレビューやチーム議論への参加が消極的になった

• 有給取得が急に増えた（面接に行っている可能性）

• 業務範囲を超えた自己学習の報告がなくなった

退職は「突然」起きるように見えるが、実際にはその2〜3か月前にシグナルが出ていることが多い。早期に気づいて対話の場を設けることが、離職防止の最も効果的な手段だ。

定着施策の全体像はエンジニアの離職を防ぐ！定着率を高めるリテンション実践ガイドを参照してほしい。

9. スケーリングのロードマップ：6か月で何をすべきか

現在10人→半年で20人を目指す場合のアクションプラン

現在30人→半年で50人を目指す場合のアクションプラン

採用計画の詳しい立て方はエンジニア採用計画の立て方を参考にしてほしい。

FAQ（よくある質問）

Q1. エンジニア組織を急拡大するとき、採用スピードと採用品質はどちらを優先すべきですか？

採用品質を優先すべきだ。 採用基準を下げて人数を揃えても、パフォーマンスの低いメンバーはチーム全体の生産性を下げる。さらに、不適切な採用は早期離職につながり、採用コストが二重にかかる。ただし、品質を維持しながらスピードを上げることは可能だ。選考プロセスの無駄を省く（面接のオンライン化、書類選考の自動化）ことで、品質を落とさずリードタイムを短縮できる。

Q2. EMの採用が難しいのですが、社内からの登用と外部採用のどちらが良いですか？

理想は併用だ。 内部昇格のメリットは、プロダクトや組織文化への理解が深いこと。デメリットは、マネジメント経験が浅いこと。外部採用のメリットは、マネジメント経験が豊富なこと。デメリットは、組織にフィットするまで時間がかかること。内部昇格7割・外部採用3割くらいのバランスが現実的だ。内部昇格の場合は、EMとしてのトレーニング（1on1の技法、フィードバック、目標設定）を必ず提供する。

Q3. 30人の壁を乗り越えるために最初にやるべきことは何ですか？

最初のEMを採用（または内部登用）すること。 CTOがピープルマネジメントとテクノロジーマネジメントの両方を抱えている状態が、30人の壁の本質的な原因であることが多い。EMがピープルマネジメントを引き受けることで、CTOは技術戦略に集中でき、組織全体の意思決定品質が上がる。

Q4. チームを分割するタイミングの目安はありますか？

1チーム8〜10人を超えたら分割を検討する。 スクラムの推奨チームサイズ（3〜9人）を参考にすると、8人前後が1チームの上限だ。ただし、人数だけでなく「デイリースタンドアップが15分以内に終わらない」「PRレビューの待ち時間が長くなった」「チーム内のコミュニケーションコストが増えた」といったシグナルも判断材料になる。

Q5. 拡大期にエンジニアの離職率が上がり始めました。最も効果的な対策は？

まず退職者へのエグジットインタビューで原因を特定することが先決だ。 離職の原因がマネジメント不足なのか、報酬なのか、技術負債なのか、カルチャー変容なのかで打ち手がまったく異なる。その上で、エンゲージメントサーベイを導入して全体の傾向を把握し、スコアが低い領域から優先的に対策する。即効性があるのは1on1の質の向上とキャリアパスの明確化だ。

Q6. 外部のエンジニア採用支援（RPO）を活用すべきタイミングはいつですか？

月3人以上のペースでエンジニアを採用する必要があり、かつ社内リクルーターが1名以下の場合。 採用活動にはスカウト送信、書類選考、面接調整、候補者フォローなど多くのオペレーション業務がある。月3人以上の採用を内製で回すには、最低でもリクルーター1名＋採用アシスタント1名が必要。そのリソースがない場合は、RPOの活用で採用スピードを維持しながら品質を確保できる。RPOの選び方はエンジニア採用代行（RPO）の選び方と成功事例を参照してほしい。

Q7. リモートワーク環境でのエンジニア組織スケーリングで注意すべき点は？

コミュニケーション設計とドキュメント文化の構築が最重要。 リモート環境では「隣の席の人に聞く」ができないため、暗黙知がさらに伝わりにくくなる。非同期コミュニケーション（ドキュメント、Issue、ADRなど）を基本とし、同期コミュニケーション（ミーティング）は必要最小限にする。オンボーディングもリモート前提で設計し直す必要がある。リモート環境の採用戦略についてはリモート・ハイブリッド時代にエンジニア採用力を高める実践ガイドを参照してほしい。

まとめ：スケーリングは「採用して終わり」ではない

エンジニア組織のスケーリングは、単なるヘッドカウントの積み上げではない。採用・体制・制度の3軸を、フェーズに合わせて同時に進化させることが成功の鍵だ。

各フェーズで優先すべきことを整理すると:

• 〜10人: カルチャーフィットと技術の幅を最優先した採用

• 10〜30人: 最初のEMの確保とチーム分割の実施

• 30〜50人: 採用品質の維持、オンボーディングの型化、ミドルマネジメントの育成

• 50〜100人超: 組織設計の本格化、制度・プロセスの仕組み化、採用ブランディング

焦って人を増やしても、体制と制度が追いつかなければ組織は内側から崩壊する。逆に、スケーリングの設計を先行させれば、人が増えるほど開発力は加速する。

techcellarでは、エンジニア採用の戦略設計から実行支援まで、組織のフェーズに合わせたサポートを提供しています。 スケーリング期の採用にお悩みの方は、ぜひお問い合わせからご相談ください。