AIスタートアップの初期エンジニア採用で「今すぐ動いてくれる人」を優先すると、半年後に「コードが動いているが誰も保守できない」状態になる。

AIスタートアップでエンジニアを採用する時に、絶対に妥協しない3つの基準

思考版1 AI執筆

AIスタートアップでの初期エンジニア採用は、プレッシャーとの戦いだ。

「早く採らないと開発が止まる」というプレッシャーの中で採用基準を下げると、後で取り返しのつかない問題になる。

絶対に妥協しなかった3つの基準を整理する。

基準1：「なぜそう作ったか」を説明できること

コードを書くことと、コードを説明することは別の能力だ。

初期の「速く動く」フェーズで入ってきたエンジニアが「自分にしか分からないコード」を積み上げると、採用コストより大きな技術的負債になる。

面接での確認方法: 「最近書いたコードで、一番気に入っている設計を教えてください。なぜそう設計しましたか」という問いで、説明の具体性と根拠の明確さを見る。

基準2：「分からない」を言えること

スタートアップでは、誰も正解を持っていない問題を解くことが多い。

「分からないのに分かったふりをする」エンジニアは、問題が大きくなってから発覚する。「これは分からないので確認します」と言えるエンジニアは、小さいうちに問題を止められる。

特にAIスタートアップでは、LLMの精度や動作に不確実性がある。「このシステムの精度は？」という問いに「高いと思います」ではなく「テストしている範囲ではX%ですが、このケースでは低下します」と答えられるかどうかを確認する。

面接での確認方法: 「面接の準備をしてきた中で、答えられるか自信のない質問はありますか」と聞く。正直に答えられるかを見る。

基準3：「ユーザーにとって価値があるか」を判断軸にできること

エンジニアは技術的に面白い問題に集中しがちだ。スタートアップで最初に大事なのは、「技術的に面白いか」ではなく「ユーザーが使えるか」だ。

AI系スタートアップでは、「LLMを使ったら精度が高くなった」という技術的な達成に満足して、「精度が高くなったがユーザーが使いにくい」という問題を見落とすことがある。

面接での確認方法: 「過去に作ったものの中で、ユーザーに一番使ってもらえたものは何ですか。なぜだと思いますか」という問いで、ユーザー視点での評価ができるかを見る。

「今すぐ動いてくれる人」の罠

採用プレッシャーがある時、「とにかく今すぐ開発を進められる人」を優先したくなる。

この基準で採用を続けると：

  • コードの品質や説明ができない人が積み上がり、後から入ったエンジニアが「このコードは何？」という状態になる
  • 「分からない」を言えない人が複数いると、問題が大きくなるまで誰も気づかない
  • ユーザー視点を持たないエンジニアが多いと、技術的には動くがユーザーが使わないプロダクトになる

初期採用での妥協は、後から修正するコストが高い。

関連記事