+++ title = "AIスタートアップでエンジニアを採用する時に、絶対に妥協しない3つの基準" date = 2026-06-08 description = "初期メンバー採用のプレッシャーがある中でも、AIスタートアップが絶対に妥協してはいけない採用基準" [taxonomies] tags = ["HR×AI", "AIスタートアップ", "エンジニア採用", "採用基準", "スタートアップ"] [extra] public = true belief_version = 1 ai_written = true one_true_sentence = "AIスタートアップの初期エンジニア採用で「今すぐ動いてくれる人」を優先すると、半年後に「コードが動いているが誰も保守できない」状態になる。" [[extra.faqs]] question = "AIスタートアップの初期エンジニア採用で、絶対に妥協してはいけない基準は何ですか？" answer = "3つの基準があります。①「なぜそう作ったか」を説明できる（コードの説明能力）、②「分からない」を言える（不確実性の正直な開示）、③「ユーザーにとって価値があるか」を判断軸にできる（ユーザー視点）。この3つは採用後の修正コストが高いため、プレッシャーがあっても妥協しないことが重要です。" [[extra.faqs]] question = "「なぜそう設計したか」を面接で確認するための有効な質問はありますか？" answer = "「最近書いたコードで一番気に入っている設計を教えてください。なぜそう設計しましたか」が有効です。良い回答は具体的な制約・トレードオフ・代替案の検討が含まれます。「速かったから」「慣れているから」だけの回答は説明能力が低い可能性があります。チームに引き継ぐことを想定した設計の言語化ができるかが初期エンジニア採用の重要な評価軸です。" [[extra.faqs]] question = "「分からない」と言えるエンジニアを面接で見分けるにはどうすればよいですか？" answer = "「面接の準備をしてきた中で、答えられるか自信のない質問はありますか」と直接聞きます。正直に「これは分からない」と答えられるエンジニアは、業務でも不確実性を適切に開示できます。また「このシステムの精度は？」と聞いた時に「高いと思います」ではなく「テストした範囲ではX%ですがこのケースでは低下します」と答えられるかを確認します。" [[extra.faqs]] question = "「今すぐ動いてくれる人」を採用した場合、半年後に何が起きますか？" answer = "コードは動いているが誰も保守できない技術的負債が積み上がります。「分からない」を言えない人が複数いると問題が大きくなるまで誰も気づきません。ユーザー視点のないエンジニアが多いと技術的には動くがユーザーが使わないプロダクトになります。初期採用の妥協は後から修正するコストが非常に高く、チームカルチャーそのものを変えることが必要になる場合があります。" +++ AIスタートアップでの初期エンジニア採用は、プレッシャーとの戦いだ。 「早く採らないと開発が止まる」というプレッシャーの中で採用基準を下げると、後で取り返しのつかない問題になる。 絶対に妥協しなかった3つの基準を整理する。 --- ## 基準1：「なぜそう作ったか」を説明できること コードを書くことと、コードを説明することは別の能力だ。 初期の「速く動く」フェーズで入ってきたエンジニアが「自分にしか分からないコード」を積み上げると、採用コストより大きな技術的負債になる。 **面接での確認方法**: 「最近書いたコードで、一番気に入っている設計を教えてください。なぜそう設計しましたか」という問いで、説明の具体性と根拠の明確さを見る。 --- ## 基準2：「分からない」を言えること スタートアップでは、誰も正解を持っていない問題を解くことが多い。 「分からないのに分かったふりをする」エンジニアは、問題が大きくなってから発覚する。「これは分からないので確認します」と言えるエンジニアは、小さいうちに問題を止められる。 特にAIスタートアップでは、LLMの精度や動作に不確実性がある。「このシステムの精度は？」という問いに「高いと思います」ではなく「テストしている範囲ではX%ですが、このケースでは低下します」と答えられるかどうかを確認する。 **面接での確認方法**: 「面接の準備をしてきた中で、答えられるか自信のない質問はありますか」と聞く。正直に答えられるかを見る。 --- ## 基準3：「ユーザーにとって価値があるか」を判断軸にできること エンジニアは技術的に面白い問題に集中しがちだ。スタートアップで最初に大事なのは、「技術的に面白いか」ではなく「ユーザーが使えるか」だ。 AI系スタートアップでは、「LLMを使ったら精度が高くなった」という技術的な達成に満足して、「精度が高くなったがユーザーが使いにくい」という問題を見落とすことがある。 **面接での確認方法**: 「過去に作ったものの中で、ユーザーに一番使ってもらえたものは何ですか。なぜだと思いますか」という問いで、ユーザー視点での評価ができるかを見る。 --- ## 「今すぐ動いてくれる人」の罠 採用プレッシャーがある時、「とにかく今すぐ開発を進められる人」を優先したくなる。 この基準で採用を続けると： - コードの品質や説明ができない人が積み上がり、後から入ったエンジニアが「このコードは何？」という状態になる - 「分からない」を言えない人が複数いると、問題が大きくなるまで誰も気づかない - ユーザー視点を持たないエンジニアが多いと、技術的には動くがユーザーが使わないプロダクトになる 初期採用での妥協は、後から修正するコストが高い。 --- ## 関連記事 - [AIスタートアップで最初のエンジニアを採用するタイミング：判断基準の整理](/n/ai-startup-first-engineer-timing/) — 妥協しない採用基準を持てる状態になるタイミングの見極め方 - [AIエンジニアを採用しても活かせない組織のパターン](/n/ai-engineer-hired-but-underused/) — 採用基準を満たしたエンジニアが活かされない組織側の問題 - [AIスタートアップの2人目のエンジニア採用は1人目と何が違うか](/n/ai-startup-second-engineer-different/) — 初期の採用基準が2人目以降に与える影響