スタートアップのエンジニア採用支援｜最初に採る役割を決める

スタートアップのエンジニア採用支援で最初に整える対象は、採用チャネルではなく技術的な責任の優先順位です。「エンジニアを三人」と決めても、最初のバックエンドエンジニア、フロントエンドのテックリード、SRE、EMでは解く課題が違います。

事業計画が変われば、必要なエンジニアも変わります。新機能を急いでいた会社が、顧客増加によって障害対応とデータ移行を優先する場合もあります。全職種を同じ熱量で募集すると、CTOの求人レビューと技術面接が分散し、候補者への返答も開発も遅れます。

僕は、スタートアップのエンジニア採用支援を「採用担当者やCTOの代わり」と考えない方が良いと思っています。経営と開発現場が役割と採否を決め、外部支援は技術要件、求人、技術選考、KPIを社内で更新できる形へ整える方が、事業の変化へ速く対応できます。

最初に採るエンジニアの役割をプロダクト課題から決めます

採用順位は、欠員や声の大きい部門だけで決めません。採用できなかった場合に止まるプロダクト判断、既存メンバーで補える期間、入社後の立ち上がり、CTOと現場が選考へ使える時間を並べます。職種の優先順位を事業計画から決める手順は、エンジニア採用戦略コンサルの進め方にも整理しています。

仮説検証中のプロダクトでは、バックエンドとフロントエンドをまたぎ、顧客の反応まで見て実装を変えられるエンジニアが優先かもしれません。利用企業が増えて障害が開発を止めているなら、機能開発者を増やす前にSREへ渡す信頼性の責任を決めます。

CTOが全ての設計、コードレビュー、採用面接を抱えている場合は、テックリードやEMが必要です。テックリードには技術判断と設計の共有、EMには開発計画、育成、評価、エンジニア採用の運用を任せます。肩書から決めず、CTOからどの責任を移すかを書きます。

正社員採用以外の手段も比べます。機能を延期する、マネージドサービスへ置き換える、既存メンバーを育成する、期間を区切って外部の専門家へ設計を相談する方法があります。正社員として長期に持ってほしい責任が明確になった段階で採用順位を決めます。

採用期限は「今年中」ではなく、プロダクト計画とつなぎます。たとえば大規模顧客向け機能の設計開始までにテックリードが必要なら、入社後の引継ぎ期間から逆算します。求人公開、書類確認、技術選考、条件決定の予定と、CTOの面接枠を先に置きます。

求人には技術スタックより現在の制約を書きます

スタートアップの求人には「大きな裁量」「急成長」「モダンな技術」という表現が増えます。エンジニアが知りたい内容は、裁量という言葉より、誰がアーキテクチャを決め、入社者がどの範囲を変更できるかです。

求人票は、役割が必要になったプロダクト課題から書き始めます。バックエンドエンジニアなら、扱うドメイン、データ量、既存システム、今後変えたい境界を説明します。フロントエンドエンジニアなら、利用者、デザイン体制、アクセシビリティ、性能、バックエンドとの責任分担を書きます。

現在の制約も採用情報です。テストが不足している、リリースが手作業、オンコールがCTOへ集中している、技術的負債の返済時間を確保できていない状況を隠すと、入社後の期待差が広がります。制約と一緒に、入社者へ任せる改善と会社が確保する時間を伝えます。

技術スタックの経験を必須にする場合は、初日から必要な理由を説明します。TypeScriptやGoの年数だけで対象を狭める前に、別の言語や環境で似た制約を扱った経験を評価できないか考えます。スタートアップでは技術構成自体が変わるため、製品名の一致より判断の再現性が重要になる場面があります。

条件面は曖昧にしません。厚生労働省の労働条件の明示に関する案内も、ホームページなどで労働者を募集する場合に、労働時間や賃金などの労働条件を明示する必要があると説明しています。報酬、働く場所、勤務時間、オンコール、ストックオプションの条件、試用期間を、社内で決められる範囲まで具体化します。技術選定の権限やCTO候補という期待も、実際に渡せる責任と一致させます。

技術選考を事業段階とエンジニア職種に合わせます

選考工程は、慣習で増やしません。厚生労働省の公正な採用選考の基本が示すように、応募者の適性と能力を基準にします。初期プロダクトを横断して作るエンジニアと、成長後の基盤を担うSREでは、確認する能力が違います。求人で任せると伝えた仕事を、どの工程で観察するかを先に決めます。

初期のバックエンドエンジニアなら、曖昧な顧客要求を小さな実装へ分け、後から変更できる境界をどう作るかを確認できます。SREなら、障害対応の経験だけでなく、サービスレベル、監視、オンコール、機能開発との優先順位をどの情報で判断したかを聞きます。

テックリード候補には、難しい設計問題だけを出すのではなく、チームへ判断を共有し、反対意見を受け、設計を更新した経験を確認します。EM候補には、管理人数より、開発計画の不確実性を経営へ説明した経験、育成と評価、採用面接の工数をどう設計したかを聞きます。

コード課題やシステムデザイン面接を使う場合は、実際の職務に近い範囲へ絞ります。持ち帰り課題なら所要時間を明示し、長時間の無償作業を前提にしません。技術面接、現場面接、最終面接で同じ能力を繰り返し確認していないかも見直します。

面接官は候補者が現れてから探さず、CTO、テックリード、EM、現場エンジニアの担当項目と予備担当を決めます。面接後は、他の評価を見る前に候補者の発言と判断根拠を記録します。「スタートアップに合いそう」という印象を、入社後の役割と関係する証拠へ置き換えます。

候補者へも判断材料を渡します。事業上のリスク、資金や売上の詳細を開示できる範囲、プロダクトの未確定事項、技術的負債、開発チームの人数、経営者との意思決定方法を説明します。候補者が辞退を選べる情報まで提供する姿勢が、入社後の認識差を減らします。

九十日でエンジニア採用を開発組織へ引き継ぎます

最初の一か月では、経営者とCTOが優先職種、入社後の責任、必須能力、育成できる能力を決めます。求人票、採用スコアカード、技術選考へ同じ要件を反映し、CTOと現場エンジニアの面接枠も確保します。

次の一か月では、社員が週次会議、求人更新、書類確認、技術面接、評価記録を運用します。外部支援はレビューへ回り、社内の判断待ちや重複する技術選考を見つけます。候補者の選別、スカウト送信、返信対応、採否は企業自身が担います。専任者がいない状態での担当分担は、採用担当がいないIT企業のエンジニア採用で確認できます。

最後の一か月では、外部支援が参加しない週を設けます。経営者、CTOまたはVPoE、EM、採用責任者が、職種別の応募、書類確認日数、技術選考、辞退理由、現場工数を読み、改善する工程を一つ決めます。

引継ぎ資料には完成した求人票だけでなく、事業計画が変わった際に採用順位を直す方法、技術構成が変わった際に必須条件を更新する方法、面接官を追加する方法を残します。支援終了後も、開発組織が次の求人を自分たちで設計できる状態を目指します。

スタートアップのエンジニア採用支援へ相談する前に、募集中の役割を「エンジニア」ではなく、バックエンド、フロントエンド、SRE、テックリード、EMへ分けてください。最上位の一職種について、採用できなければ九十日後に止まるプロダクト判断と、CTOが兼務を続けられる期限を書きます。経営チームと開発チームの回答が分かれたら、採用チャネルより役割を決める会議から始めるべきです。役割が決まった後の接点設計は、エンジニア採用媒体の選び方で媒体ごとの工数とファネルに分けて確認できます。