+++ title = "「LLMが使えるエンジニア」と「ソフトウェアエンジニアリングができるエンジニア」は別の能力だ" date = 2026-06-08 description = "AI採用で混同されがちな「LLMの使い方を知っている」と「エンジニアリングの基礎がある」の違いと、採用時の判断方法" [taxonomies] tags = ["HR×AI", "エンジニア採用", "LLM", "採用基準", "AI時代"] [extra] public = true belief_version = 1 ai_written = true one_true_sentence = "「LLMが使える」と「ソフトウェアを作れる」は地続きに見えて別の筋肉で、採用要件がそこを混ぜると、半年後に誰も直せない本番が残る。" [[extra.faqs]] question = "LLMの使い方スキルとソフトウェアエンジニアリングの基礎はどう違いますか？" answer = "LLMの使い方（APIの使い方・プロンプトエンジニアリング・RAGの概念）は6ヶ月〜1年の実務と独学で習得できます。ソフトウェアエンジニアリングの基礎（保守性を考慮した設計・テスト・本番デバッグ・チーム開発）は数年の実務が必要で、両者は独立して存在します。どちらを優先するかはポジションによって異なります。" [[extra.faqs]] question = "AIプロダクトの初期プロトタイプを速く作りたい場合、どちらのスキルを優先すべきですか？" answer = "LLMの知識と実験速度を優先してください。PoC段階で何が動くかを試したい場合や、後でリファクタリングできる余裕がある場合はLLMの使い方を先に確認します。一方で本番環境で長期的に保守されるシステムや、チームで並行開発するケースではソフトウェアエンジニアリングの基礎を優先します。" [[extra.faqs]] question = "採用面接で両方のスキルを確認する質問はどう設計すればいいですか？" answer = "LLMの知識確認は「LLMのAPIを使って何を作り、コスト設計はどうしたか」「プロンプトが変わった時既存システムへの影響は」で確認します。ソフトウェアエンジニアリングの基礎確認は「書いたコードのテストをどう書くか。LLMを使った部分のテストは特に難しいが」「本番でバグが出た時どう特定するか」で確認します。" [[extra.faqs]] question = "「LLMを使って開発した経験がある方」という求人要件の問題点は何ですか？" answer = "「LLMを使ったことがある」人が集まりますが、採用担当者が本当に求めているのは「LLMを使いながら本番環境で動くシステムを作り、チームで保守できるエンジニア」のことが多いです。求人要件と面接設計が「LLMの知識」だけを確認する形になっていると、ソフトウェアエンジニアリングの基礎が弱い候補者を選んでしまいます。" +++ 「LLMが使える人が欲しい」。そう書いた求人に来た候補者は、面接でデモをさらりと動かしてみせる。プロンプトもRAGも、淀みない。なのに採用して半年、本番がある日落ちて、原因を追える人が社内に誰もいない。 顧問として採用の横に立っていると、この景色を何度も見る。「LLMが使える」と「ソフトウェアを作れる」を同じ能力だと思い込んだ瞬間に、必ず起きる。 --- ## 地続きに見えて、別の筋肉 ### 能力A：AIと組む知識 - 主要なLLMのAPIに触れて、何かを動かしたことがある - プロンプトの勘所と、モデルごとの癖を知っている - RAGやツール呼び出しの構え方がわかる ここで効くのは、AIを「道具として叩く」発想ではなく、AIを相棒として「どう組ませるか」を設計する感覚だ。この能力は独学と数ヶ月〜1年の実務で届く。ソフトウェアエンジニアリングの土台がなくても、ここまでは持てる。 ### 能力B：ソフトウェアエンジニアリングの基礎 - 半年後の自分と他人が触れる前提で、保守性を設計できる - テストで品質を担保し、壊れた箇所を切り分けられる - 本番で火が出たとき、ログから原因にたどり着ける - チームのコードベースに、波風立てず機能を足せる こちらは数年の実務でしか積み上がらない。そしてAの知識とは独立して存在する。AIと上手く組める人が、必ずしも本番を支えられるわけではない。逆もまた然り。 --- ## なぜ混ざるのか 求人に「LLMを使って開発した経験がある方」と書けば、集まるのは文字どおり「LLMを使ったことがある人」だ。 だが採用側が本当に欲しいのは、たいてい「AIを相棒に本番で動くものを作り、半年後にチームへ渡せるエンジニア」のほうだ。要件と面接が能力Aしか測っていないと、土台の弱い候補者を、自分の手で選んでしまう。 要件の言葉と、面接で測っているものがズレている。これは候補者の問題ではなく、設計の問題だ。 --- ## どちらを優先するかは、ポジションが決める ### 能力A（AIと組む）を優先するとき - AIプロダクトの初期プロトタイプを、とにかく速く立てたい - 何が刺さるかを試す段階で、捨てる前提で動かしたい 実験の速さがすべてを決める局面では、土台より「AIとどれだけ速く組めるか」を採る。 ### 能力B（土台）を優先するとき - 長く保守される本番を作る - チームで並行して開発する - 既存のコードベースにAI機能を足していく ここでは判断が逆になる。AIと組む勘所は後から渡せるが、土台は時間でしか積めない。迷ったら土台を採る——速さは教えられるが、設計の筋肉は教えるのに年単位かかるからだ。 --- ## 月曜から使える、ひとつの実技課題 面接で言葉のキャッチボールをしても、能力Aと能力Bは見分けにくい。だから問いだけでなく、両方が同時に出る一手を渡したい。 **渡すのは、30分の実技課題ひとつ。** わざと少しだけ散らかった小さなコードベースを用意し、こう頼む。 > 「ここにAI機能をひとつ足してください。そのあと、本番でこのエラーログが出ました。原因を追って直してください」 この一手で、能力Aと能力Bが同じ画面に並ぶ。 - AIと組む知識 → 機能を足す手つき、プロンプトとテストの置き方に出る - 土台 → 散らかったコードへの振る舞い、ログから原因へたどる足取りに出る きれいに動いたかより、**詰まったときに何を頼り、どう独り言を言うか**を見る。能力Aだけの候補者はログの前で固まり、能力Bだけの候補者はAIを相棒として組み込めず手で書ききろうとする。両方ある人は、AIに任せる所と自分で握る所を、迷わず切り分ける。 --- ## 採用は、すごい人を採るゲームではない 採用は「いちばんすごい人」を採るゲームではなく、「半年後にチームへ渡せる人」を採るゲームだ。 「LLMが使える人が欲しい」と書く前に、決めることがひとつある。このポジションで半年後に困るのは、AIと組めないことか、本番を支えられないことか。先にそこを決めれば、要件の言葉も、面接の一手も、自然と揃う。 --- ## 関連記事 - [AIエンジニアを採用しても活かせない組織のパターン](/n/ai-engineer-hired-but-underused/) — スキル評価の誤りが採用後の活躍度に与える影響 - [AI採用でカルチャーフィットを評価できない理由](/n/ai-hiring-culture-fit-limits/) — スキル評価を超えた採用判断の考え方 - [AIスタートアップで非エンジニア職を採用する方法](/n/ai-startup-engineer-hiring-criteria/) — エンジニア採用と非エンジニア採用の要件設計の違い