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

• SaaS企業のエンジニア採用は「事業フェーズ × プロダクト成熟度」で戦略が根本的に変わる。汎用的な採用ノウハウをそのまま適用すると、採用ミスマッチが頻発する

• シード期は**「何でもやれる人」を1〜3名**、シリーズAは**「専門性と再現性を持つ人」を5〜15名**、シリーズB以降は**「仕組みで回せるチーム」を30名以上**で構成するのが基本設計

• SaaSならではの職種（グロースエンジニア、SRE、データエンジニア）の採用タイミングを間違えると技術負債が加速する

• ARR（年間経常収益）に連動した採用予算設計と、T2D3の成長カーブに合わせた要員計画がSaaS特有の論点

• フェーズごとに候補者に刺さるEVP（従業員価値提案）が異なる。「0→1の面白さ」と「スケールの面白さ」を使い分ける

SaaS企業のエンジニア採用戦略｜フェーズ別の採用設計と実践ガイド

「SaaSのシリーズAで資金調達したけど、エンジニアが全然採れない」 「PMF前にフルタイムのエンジニアを雇うべきか、業務委託で回すべきか」

SaaSスタートアップの経営者やCTOから、こうした相談を頻繁に受ける。

SaaS企業のエンジニア採用には、一般的なWeb企業やSIerとは異なる固有の難しさがある。プロダクトが「売り切り」ではなく「継続利用」を前提とするため、開発組織に求められるスキルセットもマインドセットも独特だ。さらに、資金調達のフェーズによって使える予算も採るべき人材像もまるで違う。

この記事では、SaaS企業に特化したエンジニア採用戦略を、シード期・シリーズA・シリーズB以降のフェーズ別に整理する。

このページでわかること

• SaaS企業のエンジニア採用が「普通の採用」と異なる5つの理由

• シード〜シリーズB以降のフェーズ別に採るべきエンジニア像と人数の目安

• ARRベースの採用予算設計とT2D3に連動した要員計画

• SaaS特有の職種（グロースエンジニア・SRE・データエンジニア）の適切な採用タイミング

• フェーズ別のEVP設計と候補者への訴求ポイント

• よくある採用失敗パターンと防止策

1. SaaS企業のエンジニア採用が「普通の採用」と異なる5つの理由

SaaS企業のエンジニア採用には、ビジネスモデルに起因する固有の特徴がある。これを理解せずに「一般的なエンジニア採用のベストプラクティス」を適用すると、採用後のミスマッチにつながりやすい。

1-1. プロダクトのライフサイクルが「永続」

SaaSは売り切りのソフトウェアと違い、顧客が使い続ける限りプロダクトを改善し続ける必要がある。つまり、エンジニアには「作って終わり」ではなく**「作り続ける力」**が求められる。

具体的には以下のスキルが重視される。

• 技術負債を意識した設計判断

• 後方互換性を保ったAPI設計

• 段階的なリファクタリング能力

• 長期的なコードベースのメンテナンス力

受託開発やSIer出身のエンジニアが「スキルは高いのにSaaSでパフォーマンスが出ない」ケースの多くは、この「永続的なプロダクト開発」への適応が課題になっている。

1-2. ビジネスメトリクスへの感度が必要

SaaSエンジニアには、ARR・MRR・チャーンレート・LTVといったビジネス指標への理解が求められる。機能開発の優先順位がこれらの指標に直結するためだ。

「技術的に面白いから作る」ではなく「この機能を作るとチャーンが何%下がるか」を考えられるエンジニアかどうか。この視点は選考時に確認すべき重要な評価軸になる。

1-3. マルチテナント・スケーラビリティの技術課題

SaaSプロダクトは複数の顧客が同一基盤を共有するマルチテナント構造が一般的だ。これに伴い、以下のような技術課題が発生する。

• テナント間のデータ分離とセキュリティ

• 顧客数増加に伴うパフォーマンス劣化への対応

• 大口顧客のカスタマイズ要求と汎用性のバランス

• SLA（サービスレベル保証）に耐えうる可用性設計

これらの経験を持つエンジニアは市場に限られるため、「SaaS経験者」へのスカウト競争は激化しやすい。

1-4. 資金調達フェーズで採用予算が劇的に変わる

SaaSスタートアップの多くは外部資金調達を行う。シード期に数千万円だった年間採用予算が、シリーズAで数億円に跳ね上がることも珍しくない。

この変化に採用体制が追いつかないと、「お金はあるのに人が採れない」というボトルネックが発生する。各フェーズに応じた採用チャネルと体制の準備が必要だ。

1-5. 職種の多様化タイミングがビジネスフェーズに連動

SaaS企業では、事業の成長に応じて必要なエンジニア職種が明確に変わる。

この「いつ、どの職種を採るか」の判断を誤ると、プロダクトの成長が止まるか、逆に早すぎる専門化で組織が硬直化する。

2. シード期（PMF前〜直後）のエンジニア採用戦略

シード期は「正解がまだ見えない」フェーズだ。プロダクトの方向性自体が週単位で変わる可能性がある。この時期に採用すべきエンジニア像と採用手法を整理する。

2-1. 採用すべき人材像：「T字型×起業家マインド」

シード期に採るべきは、一つの専門領域を持ちつつ幅広く動ける「T字型」のエンジニアだ。

必須要件:

• フロントエンド・バックエンド・インフラを一人でカバーできる技術力

• ビジネス要件を自分で解釈し、技術的な意思決定を下せる自律性

• 「完璧な設計」より「素早い仮説検証」を優先できるマインド

• 曖昧さへの耐性（仕様が固まっていない状態で手を動かせる）

あると望ましい要件:

• SaaS企業での開発経験

• 0→1のプロダクト立ち上げ経験

• B2B領域のドメイン知識

2-2. 採用人数の目安：1〜3名

シード期のエンジニアチームは、創業者（技術共同創業者がいる場合）を含めて2〜4名が目安だ。

この時期にエンジニアを5名以上採用するのはリスクが高い。PMF前はプロダクトの方向転換（ピボット）が起きる可能性があり、大人数の組織はピボットの足枷になる。

2-3. 採用チャネル：リファラルと業務委託が中心

シード期で最も有効な採用チャネルは以下の2つだ。

リファラル採用: 創業メンバーの直接的な人脈が最大の武器。SaaS業界は人材の流動性が高く、前職の同僚や技術コミュニティのつながりが有効に機能する。

業務委託→正社員転換: いきなり正社員として採用するリスクを避けるため、まず業務委託で一緒に働いてみる手法。SaaSスタートアップでは一般的なアプローチで、3〜6か月の業務委託期間を経て正社員オファーを出すケースが多い。詳しくはトライハイヤー戦略の実践ガイドで解説している。

この段階でスカウト媒体を使う場合は、候補者一人ひとりに丁寧なパーソナライズメッセージを送ることが重要だ。シード期の企業は知名度がないため、定型文では返信が来ない。

2-4. 報酬設計：ストックオプション（SO）の活用

シード期は現金報酬で大手に勝てない。ここで武器になるのがストックオプション（SO）だ。

• 市場水準の70〜90%の現金報酬 ＋ SOの組み合わせが一般的

• SOの付与量は、初期メンバーほど手厚くする（エンジニア1〜3号には全体の1〜3%程度が目安）

• べスティング条件（4年・1年クリフが標準）を事前に明確にする

• SOの価値を候補者に説明する際は、過度に楽観的なバリュエーション予測を避ける

2-5. シード期の採用でよくある失敗

失敗1: 大企業出身のシニアエンジニアを採用して合わなかった 技術力は高いが、「決められた要件を高品質で実装する」スタイルの人は、仕様が流動的なシード期にフラストレーションを抱えやすい。

失敗2: 友人だからという理由で共同創業者にした 技術力や相性の見極めが甘いまま、友人関係だけでCTOに据えてしまうケース。後から技術方針の不一致が表面化し、創業チームが分裂するリスクがある。

失敗3: 安さ優先でジュニアだけを採用した コストを抑えるためにジュニアエンジニアだけで構成すると、設計レビューや技術的な意思決定を行える人がおらず、技術負債が急速に蓄積する。

3. シリーズA（PMF後〜成長初期）のエンジニア採用戦略

PMFを達成し、ARRが1〜5億円に成長するフェーズ。プロダクトの方向性が定まり、「同じことを、もっと速く、もっと安定して」できる体制を作る時期だ。

3-1. 採用すべき人材像：「専門性 × 再現性」

シリーズAでは、シード期の「何でもやる」から「専門領域で成果を出す」へとシフトする。

バックエンドエンジニア:

• APIの設計・実装、データベース設計に強い

• パフォーマンスチューニングの経験

• マルチテナント環境での開発経験があると尚可

フロントエンドエンジニア:

• React/Vue/Next.jsなどモダンフレームワークの実務経験

• デザインシステムの構築・運用経験

• アクセシビリティへの理解

テックリード/シニアエンジニア:

• 技術選定と設計判断の経験

• コードレビューを通じたチーム育成力

• 事業要件を技術仕様に落とし込む翻訳力

QAエンジニア:

• 自動テスト戦略の設計・運用

• CI/CDパイプラインへのテスト組み込み

3-2. 採用人数の目安：5〜15名（累計）

シリーズAのエンジニア組織は、累計5〜15名が目安だ。この数字はARRの成長速度と紐づく。

一般的な目安として、SaaS企業のエンジニア人件費はARRの20〜40%が適正範囲とされている。ARR 3億円のSaaS企業であれば、エンジニア人件費は6,000万〜1.2億円。平均年収700万円で計算すると、8〜17名規模になる。

ただし、この数字はあくまで参考値だ。プロダクトの技術的複雑性やマーケットの競争環境によって大きく変わる。

3-3. 採用チャネル：スカウト媒体を本格活用

シリーズAでは、リファラルだけでは採用が間に合わなくなる。スカウト媒体の本格活用が必要だ。媒体の選び方についてはエンジニア採用媒体の選び方ガイドで詳しく比較している。

おすすめの媒体と使い分け:

• BizReach: ハイクラス人材（テックリード・EM候補）の採用に強い

• Forkwell / LAPRAS: エンジニア特化。技術スキルでのフィルタリングが可能

• Green: コストパフォーマンスが高い。中堅エンジニアの採用に向く

• Wantedly: 企業の「想い」での訴求が得意。カルチャーフィット重視の採用向き

• YOUTRUST: 副業・転職潜在層へのリーチに強い

スカウト文面では、SaaSプロダクトの技術的な面白さを具体的に伝えることが返信率を上げるポイントだ。「Rubyで開発しています」ではなく、「日次10万リクエストを処理するマルチテナントSaaSのバックエンドをRuby on Railsで開発しており、現在テナント分離アーキテクチャの再設計フェーズにあります」のように、具体的な技術課題を提示する。

3-4. 報酬設計：市場水準への接近

シリーズAでは、現金報酬を市場水準に近づける必要がある。SaaSエンジニアの2026年時点での市場報酬レンジは以下のとおりだ。

SOは引き続き活用するが、付与割合はシード期より小さくなる（個人あたり0.1〜0.5%程度が目安）。

3-5. シリーズAの採用でよくある失敗

失敗1: 一気に10人以上を採用して組織が崩壊 採用のスピードにオンボーディング体制が追いつかず、新メンバーが放置される。結果、早期離職が発生し、残ったメンバーの負荷が増える悪循環に陥る。月に2〜3名ペースを上限とし、受け入れ態勢を整えてから増員するのが鉄則だ。

失敗2: 「SaaS経験者」にこだわりすぎて候補者が見つからない SaaS経験はあると望ましいが、必須にすると候補者プールが極端に狭くなる。Web系自社サービスの開発経験があれば、SaaS固有の知識はオンボーディングで補える部分が多い。

失敗3: 採用ブランディングを後回しにした シリーズAのSaaS企業は「知る人ぞ知る」状態。テックブログ・技術カンファレンスでの登壇・SNSでの発信を始めないと、スカウトの返信率が上がらない。採用活動と並行して、テックブログによる技術広報やEVP設計を走らせるべきだ。

4. シリーズB以降（グロース期）のエンジニア採用戦略

ARRが10億円を超え、組織が30名以上になるフェーズ。「個人の力」から「仕組みの力」へと、採用・開発の両面で転換が求められる。

4-1. 採用すべき人材像：「仕組み化 × 専門深化」

グロース期では、シード期・シリーズAでは後回しにしていた専門職の採用が本格化する。

SRE（Site Reliability Engineer）:

• 可用性99.9%以上を維持するためのインフラ設計

• 障害対応の仕組み化（オンコール体制・ポストモーテム運用）

• SaaSのマルチテナント環境でのパフォーマンス管理

SREの採用タイミングは「顧客数が100社を超えたあたり」が目安。これを超えると、インフラの安定性がチャーンレートに直結し始める。

データエンジニア:

• プロダクトの利用データを分析基盤に集約

• ビジネスチームが使えるダッシュボード構築

• 顧客行動データに基づく機能改善の推進

SaaSではデータがプロダクト改善の生命線だ。データ基盤の整備が遅れると、意思決定が「勘と経験」に依存し続けることになる。

エンジニアリングマネージャー（EM）:

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

• 採用・評価・育成の運用

• 他部門（CS・セールス・プロダクト）との連携

EMの採用は「エンジニアが15名を超えたら」検討すべきだ。CTOやテックリードがマネジメントとプレイヤー業務を兼務し続けると、両方の品質が下がる。EMの具体的な採用方法はエンジニアリングマネージャー採用ガイドを参考にしてほしい。

セキュリティエンジニア:

• SOC2/ISMSなどの認証取得対応

• 脆弱性診断と改善の運用

• セキュリティインシデント対応体制の構築

エンタープライズ顧客の獲得を狙う場合、セキュリティ体制の強化は必須。大口案件の商談で「セキュリティ専任者がいない」と伝えると、それだけで失注することもある。

4-2. 採用人数の目安：30名以上（累計）

グロース期のエンジニア組織は30〜100名規模になる。この規模になると、以下のような組織設計が必要だ。

• チーム分割: 機能別（フロント/バック/インフラ）またはプロダクト領域別（顧客向け機能/社内向け機能/基盤）

• テックリードの配置: 各チームに1名のテックリードを配置し、技術的な意思決定を分散

• 横断チーム: SRE・セキュリティ・データなどの横断チームを設置

4-3. 採用チャネル：多角化と仕組み化

グロース期では、単一の採用チャネルに依存しない多角的なアプローチが必要だ。

ダイレクトスカウト: 引き続き主力チャネル。ただし、採用担当1名が送れるスカウトの量には限界がある。採用担当を複数配置するか、スカウト運用を外部パートナーに委託する判断が必要になる。

人材紹介エージェント: シニアクラス・マネジメント層の採用では、エージェント活用が有効。SaaS業界に精通したエージェントを2〜3社に絞り、密な連携体制を築くのがポイント。

リファラル制度の本格運用: 30名以上の組織になれば、リファラル採用を「制度として回す」ことが可能になる。紹介インセンティブの設計、社内告知の仕組み化、紹介プロセスの簡素化を整備する。リファラル制度の具体的な設計方法はリファラル制度の作り方と成功事例を参照してほしい。

採用イベント・カンファレンスのスポンサー: SaaS企業向けのカンファレンス（SaaSway、ALL STAR SAAS CONFERENCEなど）やエンジニア向けカンファレンスでのスポンサーシップ・登壇は、認知拡大に有効だ。

4-4. 報酬設計：競争力のあるパッケージ

グロース期のSaaS企業は、メガベンチャーやGAFAM（外資テック）と人材を取り合う場面が増える。報酬だけで勝負するのは難しいが、以下のポイントで差別化できる。

• RSU/SOの期待リターン: IPO前のSaaSの場合、SOの期待リターンがGAFAMのRSUを上回る可能性がある。候補者にその計算ロジックを透明に説明する

• 昇給の速度: 大企業と比べ、実力に応じた昇給スピードが速いことを具体的に示す

• プロダクトへのインパクト: 「自分が作った機能が直接ARRに貢献している実感」は、大企業では得にくいSaaS特有のやりがい

4-5. グロース期の採用でよくある失敗

失敗1: 採用基準を下げてしまう 「とにかく人が足りない」というプレッシャーから採用基準を緩めてしまうケース。一時的に人数は増えるが、パフォーマンスの低いメンバーが増えると、既存メンバーの負荷が増加し、離職の連鎖が起きる。

失敗2: マネジメント層の採用が遅れる EMやVPoEの採用を後回しにし、CTOが全員を見るスタイルを続けてしまう。30名以上のエンジニア組織をCTO一人でマネジメントするのは物理的に不可能だ。

失敗3: 専門職の採用タイミングを逃す SREやセキュリティエンジニアの採用を「まだ早い」と判断し続け、大きなインシデントが起きてから慌てて採用を始めるケース。専門職の採用には通常3〜6か月かかるため、「必要になってから」では遅い。

5. T2D3と採用計画の連動設計

T2D3とは、SaaSの成長モデルとして知られるフレームワークで、「ARRが年3倍→3倍→2倍→2倍→2倍と成長する」ことを指す。この成長カーブに採用計画を連動させる方法を解説する。

5-1. ARR成長率と採用人数の関係

SaaS企業のエンジニア採用数は、ARRの成長率に大きく影響される。以下は一般的な目安だ。

この表はあくまで参考値であり、プロダクトの技術的複雑性、PLG（Product-Led Growth）型かSLG（Sales-Led Growth）型かによっても変わる。PLG型はプロダクトへの投資比率が高く、エンジニアの比率が大きくなる傾向がある。

5-2. 「人を増やす前に仕組みを整える」の原則

T2D3を達成するために最も重要なのは、「人を2倍にすれば開発速度も2倍になる」という幻想を捨てることだ。

ブルックスの法則が示すとおり、プロジェクトへの人員追加はコミュニケーションコストの増大を招き、短期的にはむしろ開発速度を低下させる。

SaaS企業で実践すべきは以下の順序だ。

1. 自動化の徹底: CI/CD・テスト自動化・デプロイ自動化を先に整備

2. ドキュメントの整備: アーキテクチャ判断記録（ADR）、API仕様書、オンボーディングガイド

3. チーム分割の設計: コンウェイの法則を意識し、チーム境界＝プロダクト境界で分割

4. マネジメント層の先行採用: EMやテックリードをチーム拡大の「前に」配置

5. メンバーの増員: 上記の土台ができた状態で採用を加速

5-3. 採用予算の組み方

SaaS企業の採用予算は、以下の要素で構成される。

人件費（年間）:

• エンジニア人件費の目安 = ARR × 20〜40%

• 内訳: 基本給 + 社会保険料（約15%） + SO/RSU + 福利厚生

採用コスト（1人あたり）:

• ダイレクトスカウト: 50〜100万円（媒体費 + 人件費）

• エージェント: 年収の30〜35%（年収800万円なら240〜280万円）

• リファラル: 30〜50万円（紹介インセンティブ + 食事代等）

ARR 3億円の企業が年間10名採用する場合の概算:

• エンジニア人件費: 6,000万〜1.2億円

• 採用コスト: 1,000万〜2,000万円

• 合計: 7,000万〜1.4億円

この数字を投資家向けの事業計画に組み込み、資金調達額を決定する。採用予算が不足すると、せっかく調達した資金を活かしきれない。

6. SaaS企業のエンジニア選考で確認すべき5つのポイント

SaaS企業の面接では、一般的な技術力に加えて、SaaS固有の適性を確認する質問を組み込むべきだ。

6-1. プロダクト志向の確認

質問例: 「これまで関わったプロダクトで、ビジネス指標（売上・利用率・解約率など）を意識して開発した経験はありますか？具体的にどのような判断をしましたか？」

プロダクト志向のエンジニアは、技術的な選択肢を「ビジネスインパクト」の観点で語れる。「技術的にはAの方が美しいが、開発工数とリリーススピードを考慮してBを選んだ」といった判断経験があるかを確認する。

6-2. 不確実性への対応力

質問例: 「仕様が十分に固まっていない状態で開発を進めた経験はありますか？そのとき、どのように判断して進めましたか？」

特にシード期〜シリーズA初期のSaaS企業では、仕様の不確実性が日常的に発生する。「まず小さく作って検証する」「仕様の曖昧な部分をプロダクトマネージャーと一緒に定義する」といった行動が取れるかを見極める。

6-3. 技術負債への向き合い方

質問例: 「過去に技術負債に直面した経験を教えてください。どのように発見し、どう対処しましたか？」

SaaSプロダクトでは、スピード優先の開発で蓄積した技術負債と向き合い続ける必要がある。「技術負債を放置するリスクを事業サイドに説明して、リファクタリングの工数を確保した」経験があるエンジニアは、SaaS環境で活躍する可能性が高い。

6-4. スケーラビリティの経験

質問例: 「ユーザー数やデータ量の増加に伴うパフォーマンス課題に対応した経験はありますか？」

マルチテナントSaaSでは、顧客数の増加とともにシステムへの負荷が増大する。N+1問題の解決、キャッシュ戦略の設計、データベースのシャーディングなど、スケーラビリティに関する実務経験を確認する。

6-5. チームワークとコミュニケーション

質問例: 「エンジニア以外の職種（CS・セールス・プロダクトマネージャーなど）と協働した経験を教えてください」

SaaS企業では、CSからのフィードバックを開発に反映する、セールスチームの要望に優先順位をつけるなど、他部門との連携が不可欠だ。「技術的に正しいこと」と「事業的に必要なこと」のバランスを取れるかを確認する。

7. フェーズ別EVP設計：候補者に何を訴求するか

EVP（Employee Value Proposition / 従業員価値提案）は、フェーズごとに刺さるポイントが異なる。

7-1. シード期のEVP：「0→1の当事者になれる」

シード期に響くメッセージは以下のようなものだ。

• プロダクトの最初の1行を書ける: 技術選定からアーキテクチャ設計まで自分で決められる

• 経営に近い距離で働ける: 創業者と毎日議論しながらプロダクトを作る

• SOの期待リターン: シード期のSOは希薄化前のため、成功した場合のリターンが大きい

• 市場を作る面白さ: まだ誰も解決していない課題に取り組める

7-2. シリーズAのEVP：「成長を牽引する中核メンバーになれる」

• 技術的チャレンジの深さ: PMF後のプロダクトをスケールさせる面白さ

• 組織づくりへの参画: チームの文化やプロセスを一緒に作れる

• キャリアの加速: 少人数組織ゆえに、テックリードやEMへの昇進スピードが速い

• プロダクトの社会的インパクト: 実際に顧客が使い、感謝される体験

7-3. シリーズB以降のEVP：「大きなスケールで成果を出せる」

• 技術的な難度の高さ: 大規模トラフィック、複雑なドメインロジック、高可用性

• キャリアパスの多様性: IC（Individual Contributor）とマネジメントの両方のキャリアラダー

• 上場前の成長フェーズに参画: IPOを経験できるチャンス

• 安定性と挑戦の両立: 資金的な安定がありながら、まだスタートアップのスピード感を持つ

7-4. EVPをスカウトメール・求人票に反映する

EVPは「社内で共有して終わり」にしてはいけない。以下の接点で一貫して訴求する。

• スカウトメール: 候補者のスキル・経験に合わせてEVPのどの要素を強調するかを変える

• 求人票（JD）: 「このポジションの面白さ」セクションにEVPの要素を具体的に記載

• カジュアル面談: EVPの内容を会話の中で自然に伝える

• オファー面談: 候補者の転職軸に合わせて、EVPの中で最も刺さる要素を提示

FAQ（よくある質問）

Q1. SaaS経験のないエンジニアを採用しても大丈夫ですか？

SaaS経験は「あると望ましい」レベルで考えるのが現実的だ。Web系自社サービスの開発経験があれば、SaaS固有の知識（マルチテナント、サブスクリプションモデル、SLA管理など）はオンボーディングで習得可能な範囲が多い。むしろ、プロダクト志向や自律性、不確実性への耐性といった「マインドセット」の方が、後から変えにくく、選考で重視すべきポイントだ。

Q2. PMF前にフルタイムのエンジニアを正社員で採用すべきですか？

PMF前のフェーズでは、正社員採用のリスクを最小化するために業務委託からスタートするのも有効な選択肢だ。ただし、創業チームのコアメンバー（1〜2名）は正社員（またはストックオプション付きの共同創業者）として迎えることを推奨する。プロダクトの根幹を担う人材が業務委託のままだと、コミットメントの面で課題が出やすい。

Q3. SaaS企業でエンジニア採用の専任担当者を置くタイミングはいつですか？

エンジニアチームが10名を超え、年間採用目標が5名以上になったタイミングが目安だ。それ以前は、CTOや経営者が採用活動の中心を担い、必要に応じて外部のスカウト運用代行や採用コンサルタントを活用するのが効率的だ。

Q4. シリーズA直後の採用で最も優先すべき職種は何ですか？

シリーズA直後で最も優先度が高いのは「テックリード」だ。シード期に蓄積した技術負債の整理と、これから入ってくるメンバーの技術的なガイドを両立できる人材が必要になる。テックリードが不在のまま人数だけ増やすと、コードの品質がバラつき、後から修正するコストが膨大になる。

Q5. T2D3を目指す場合、エンジニア比率はどのくらいが適正ですか？

T2D3を目指すSaaS企業では、全社員に占めるエンジニアの比率は30〜50%が一般的だ。ただし、PLG（Product-Led Growth）型のSaaSではプロダクトへの投資比率が高くなるため、50%以上になるケースもある。一方、SLG（Sales-Led Growth）型では営業組織の比率が大きくなり、エンジニア比率は30%前後になることが多い。自社のGo-to-Market戦略に応じて調整すべきポイントだ。

Q6. SaaS企業の技術負債とエンジニア採用はどう関係しますか？

技術負債が蓄積したSaaSプロダクトは、エンジニアの採用難易度を直接的に上げる。候補者がコードベースや技術スタックに触れた際に「この環境では成長できない」と判断されると、内定辞退の原因になる。逆に、モダンな技術スタックと健全なコードベースを維持していることは、それ自体が強力な採用ブランディングになる。

Q7. SaaS企業でリモートワークを許可しないと採用は難しいですか？

2026年現在、エンジニアの多くがリモートワーク（フルリモートまたはハイブリッド）を求職条件に含めている。完全出社を求めると、候補者プールが大幅に狭まるのは事実だ。ただし、シード期のような密なコミュニケーションが必要なフェーズでは、週2〜3回の出社を求めるハイブリッド型が機能しやすい。重要なのは、自社のフェーズと開発スタイルに合った勤務形態を選び、それを採用時に正直に伝えることだ。

まとめ：SaaS企業のエンジニア採用は「フェーズに合わせて変え続ける」

SaaS企業のエンジニア採用に「万能の正解」はない。シード期に有効だった採用手法がシリーズBでは通用しないし、グロース期の採用基準をシード期に持ち込んでも機能しない。

重要なのは、以下の3つを常にアップデートし続けることだ。

1. 採るべき人材像の再定義: フェーズが変わるたびに、必要なスキル・マインドセットを見直す

2. 採用チャネルの最適化: リファラル中心からスカウト媒体やエージェントへ、フェーズに合わせて主力チャネルを切り替える

3. EVPの刷新: 候補者に訴求するメッセージを、自社の成長ステージに合わせて更新する

「エンジニア採用がうまくいかない」と感じたら、まず自社のフェーズと採用戦略のミスマッチを疑ってみてほしい。

エンジニア採用にお困りの方へ

techcellarでは、SaaS企業のフェーズに合わせたエンジニア採用支援を提供しています。スカウト運用代行からAIスカウト運用、採用プロセスの自動化まで、貴社の課題に合わせた支援が可能です。

まずはお気軽にご相談ください。

techcellarのサービスを見る