+++ title = "AIスタートアップの2人目のエンジニア採用は1人目と何が違うか" date = 2026-06-08 description = "「2人目が入れば2倍速」は、なぜ裏切られるのか。1人目のコピーを採るという失敗の構造と、その回避策" [taxonomies] tags = ["HR×AI", "AIスタートアップ", "エンジニア採用", "採用設計", "組織構築"] [extra] public = true belief_version = 1 ai_written = true one_true_sentence = "2人目のエンジニアに必要なのは、1人目のコピーではなく、1人目の弱点を埋める人だ。" [[extra.faqs]] question = "2人目のエンジニア採用で「1人目と同じ人を選んでしまう」失敗を防ぐにはどうすればよいですか？" answer = "1人目のエンジニアに「今、何が一番大変か」「自分が苦手なことでチームに影響が出ていることは何か」を正直に聞くことから始めます。インフラ維持に時間がかかっているならインフラ経験者、フロントエンドが後回しになっているならフロント経験者が必要です。1人目の採用で使った評価軸をそのまま2人目に適用しないことが、最も重要な予防策です。" [[extra.faqs]] question = "2人目のエンジニアに「全部できる人」を求めてしまう理由は何ですか？" answer = "1人目採用後に技術スタックが広がり、「フロントもバックエンドもMLも全部できる人」を探し始めるケースが多いです。このような人は市場にほとんどおらず、見つかっても採用できない可能性があります。解決策は「2人目が入った3ヶ月後に何が変わっているか」を具体的に言語化することです。「開発スピードが上がる」ではなく、特定のタスクに週何時間かけているかを測定することで、必要なスキルが絞れます。" [[extra.faqs]] question = "1人目のエンジニアに2人目の採用を任せてよいですか？" answer = "完全に任せるのは避けます。1人目のエンジニアに採用を任せると、自分と似た人を選びやすくなります。1人目をプロセスに参加させながら、技術評価は1人目に任せ、「チームへの補完性」や「コミュニケーションスタイル」は創業者や外部の視点を加えます。投資家やメンターに評価に加わってもらうことで盲点が減ることがあります。" [[extra.faqs]] question = "2人目の採用を始めるべきタイミングの判断基準を教えてください。" answer = "「2人目が入った3ヶ月後に何が変わっているか」を具体的に説明できる状態になったタイミングです。プロダクトが「ユーザーに届き始めた段階」なら迅速な改善ができる人、「スケールし始めた段階」なら保守性・安定性を重視できる人が必要になります。採用の目的が言語化できない段階で採用を始めると、1人目採用と同じ失敗を繰り返します。" +++ 「2人目が入れば開発は2倍速になる」。そう信じて採用した3ヶ月後、なぜか1人目のエンジニアが前より忙しそうにしている。創業者の隣で、この光景を何度も見てきた。 原因はたいてい1つ。1人目とよく似た2人目を、採用してしまったからだ。「また同じような人を採ってしまった」という後悔は、たいてい入社後しばらく経ってから訪れる。 --- ## 1人目採用との根本的な違い **1人目のエンジニアが担う役割**：技術的な意思決定・プロトタイプの構築・技術選定・実装。「何でもやれる人」が求められることが多い。 **2人目のエンジニアが担うべき役割**：1人目が得意でないことを補完する。または1人目がやっているが量的に回らなくなっていることを分担する。 ここを取り違える企業が多い。2人目も「何でもやれる人」を採ると、1人目と2人目が同じことをできる状態になる。強みが2枚重なり、チームの穴は誰も塞がない。 AIスタートアップではこの落とし穴がさらに深い。今や「何でもやれる」一部は、開発の相棒として隣にいるAIが担い始めている。雑な実装、定型のコード、調べ物の初速——そこは人間の2人目で埋める場所ではなくなりつつある。だからこそ2人目の人間に求めるものは、ますます「1人目とAIでは届かないところ」へ寄っていく。コピーを増やす採用は、年々割に合わなくなっている。 --- ## 採用前に確認すること ### 1人目のエンジニアに聞く 月曜の朝、求人票を書き始める前に、1人目にこの2問を投げるところから始める。 > 「今、何に一番時間を取られている？」 > 「自分が苦手で、それがチームの足を引っ張っていると感じることは？」 正直な答えが、そのまま2人目の役割定義になる。例えば： - インフラ・デプロイ環境の維持に時間がかかり、機能開発の時間が取れない → インフラが得意なエンジニアが必要 - モデルの精度改善に時間をかけたいが、フロントエンドの開発も対応しなければいけない → フロントが得意なエンジニアが必要 - 設計は得意だが、実装スピードに限界がある → 実装を早く回せるエンジニアが必要 ### プロダクトの状態を確認する プロダクトが「ユーザーに届き始めた段階」なら、技術的な深さより「フィードバックを受けて素早く改善できる人」が必要。 プロダクトが「スケールし始めた段階」なら、「速さ」より「安定性・保守性を考えながら作れる人」が必要になることがある。 --- ## よくある採用の失敗パターン **「1人目と同じ基準で評価する」**：1人目の採用で使った評価軸をそのまま2人目に適用する。1人目が得意なことを2人目も評価するため、同じ強みを持つ人が採用される。 **「全部できる人を探す」**：技術スタックが広がったことで、「フロントもバックエンドもMLも全部できる人」を探し始める。そのような人は見つからないか、見つかっても採用できない可能性がある。 **「1人目に採用を任せきりにする」**：1人目のエンジニアに採用を任せると、自分と似た人を選びやすい。意識的に異なる観点を持ち込む必要がある。 --- ## 2人目採用で確認すること 採用前に「2人目が入った3ヶ月後に、何が変わっているか」を具体的に言語化する。 「開発スピードが上がる」ではなく、「今Aというタスクに週10時間かけているが、2人目が入ればそれが半分になる」のように、時間で書く。数字で書けない約束は、面接でも測れない。 この一文が書けないなら、採用時期が早すぎる。役割が決まる前に募集を始めれば、1人目と同じ失敗をもう一度なぞるだけだ。 採用は、創業者が自分の延長を増やす行為になりがちだ。だが2人目で本当に効くのは、自分が飛べない場所へ走ってくれる人を、隣に置くこと。コピーをもう1枚増やすより、自分の手から仕事を渡せる相手を採る。そこから、チームは初めてチームになる。 --- ## 関連記事 - [AIスタートアップで最初のエンジニアを採用するタイミング：判断基準の整理](/n/ai-startup-first-engineer-timing/) — 1人目採用の判断基準と2人目との違いの前提 - [AIスタートアップでエンジニアを採用する時に、絶対に妥協しない3つの基準](/n/ai-startup-engineer-hiring-criteria/) — 1人目・2人目両方に共通する妥協できない採用基準 - [技術系創業者がエンジニアを採用する時に犯しがちな間違い](/n/ai-startup-second-engineer-different/) — 2人目採用で同じ失敗をする構造的な原因