最初のエンジニアを採るのは「方向性が決まった後」ではない。自分とAIだけでは次の一手が決められなくなった、その瞬間だ。

AIスタートアップで最初のエンジニアを採用するタイミング：判断基準の整理

思考版1 AI執筆

「競合が動いているので、とりあえずエンジニアを1人」——この「とりあえず」の3ヶ月後に残るのは、たいてい「作ったけど誰も使わないもの」だ。

最初のエンジニアは、増員ではなく相棒だ。だから早すぎても遅すぎても効かない。何を見て採るべきか、現場で何度も立ち会ってきた判断軸を整理する。

早すぎる採用が引き起こす問題

「プロダクトの方向性を決める前に採用する」ケースが多い。

起きること：

  • エンジニアが入社した時点でプロダクトの仕様が決まっていないため、「何を作れば良いか分からない状態」になる
  • 採用したエンジニアが「自分が作りたいもの」を作り始める
  • 3ヶ月後に「作ったが使われない」状態になる

AIスタートアップに特有のパターン：「LLMを使えば何でもできる」という期待から、方向性が定まる前にエンジニアを採用して「何でもできる人に方向性を決めてもらおう」とするケース。これはエンジニアにとっても採用する側にとっても不幸だ。

遅すぎる採用の問題

「完璧な仕様を決めてから採用する」も遅すぎる。

AIプロダクトは「作りながら分かること」が多い。LLMの精度がどのくらい出るか、ユーザーがどう使うかは、コードを書いてプロトタイプを触ってみるまで分からないことがある。

仕様を全部決めてから採用すると：

  • 仕様が現実と合わない可能性が高い
  • エンジニアが「なぜこの仕様なのか」を理解できない

採用のタイミングを決める判断基準

「コードなしでは次の意思決定ができない状態か」を確認する。

採用すべきタイミング：

  • ユーザーインタビューが終わり、「どんなプロトタイプを作れば仮説を検証できるか」が決まった時
  • APIを使った技術検証をしたいが、自分でコードを書く時間またはスキルがない時
  • 「このLLMでこの精度が出るか」を試すためにコードが必要な時

採用を待つべきタイミング：

  • プロダクトが「誰の何の問題を解くか」が言語化できていない時
  • 採用したエンジニアに「最初の3ヶ月でやってほしいこと」を具体的に説明できない時

月曜の朝、採用要件を書く前にやる一手

求人票を開く前に、まず自分がAIを相棒に48時間プロトタイプを回す。LLMの精度、データの手応え、ユーザーの反応を、一度は自分の手で掴む。

そのうえで「次の意思決定にどうしてもコードが要る」と詰まったら、そこが採用シグナルだ。逆に48時間で方向性の問いがほどけてしまうなら、まだ採るには早い。採用シグナルは、外の競合ではなく自分の手詰まりが教えてくれる。

最初のエンジニアに求めるものの変化

プロダクト開発の初期段階では、「速くコードを書ける人」より「何を作るべきかを一緒に考えられる人」の方が価値がある場合がある。

AIスタートアップの初期は特に、「このLLMの精度はどういう条件だと上がるか」「このデータがあればどんなことができるか」という会話をエンジニアとできるかどうかが重要だ。

「エンジニアとして技術を提供する人」を採用するのか、「プロダクトの方向性を技術的なスキルも持って一緒に考えられる人」を採用するのか、最初のエンジニアに何を求めるかを採用前に決めておく。

速さで一人だけ前に飛べる人より、隣で方向を一緒に決められる人。最初の1人は、指示を渡す相手ではなく、判断を一緒に背負う相棒だ。

採用を急かすプレッシャーへの対処

「競合が動いている」「投資家から急かされる」という外部プレッシャーで採用を急ぐことが多い。

プレッシャーを受けた時に確認すること：「今採用して、最初の1ヶ月でこのエンジニアに何をしてもらうか」を具体的に説明できるかどうか。説明できない場合、採用のタイミングではない。

関連記事