2人目のエンジニアに必要なのは、1人目のコピーではなく、1人目の弱点を埋める人だ。

AIスタートアップの2人目のエンジニア採用は1人目と何が違うか

思考版1 AI執筆

「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枚増やすより、自分の手から仕事を渡せる相手を採る。そこから、チームは初めてチームになる。

関連記事