+++ 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時代にエンジニアの技術評価で重視される3つの軸は何ですか？" answer = "①「調べながら解く」能力（検索・ドキュメント参照・AI活用を使って問題を解くプロセスを評価）、②問題の再定義力（「何を解くべきか」を疑う力。AIが解の生成を速くした分、問題の質が差になる）、③知らないことへの向き合い方（「わかりません」で止まらず「どうやって調べるか・前提を疑えるか」が評価の中心になっている）。従来型の暗記ベースの評価から、情報活用プロセスの評価に移行しています。" [[extra.faqs]] question = "「知らないことへの向き合い方」を採用面接でどう評価すればいいですか？" answer = "「全く知らない技術領域の問題を初めて解くときの手順を教えてください」という質問が効果的です。「わかりません」で終わる候補者と「まずドキュメントを探し、次に類似ケースを確認し、わからなければ前提から疑う」と答える候補者では明確な差が出ます。また「過去にAIが間違えた経験はありますか？その時どうしましたか」という質問も、AIへの過信か適切な懐疑かを確認するのに有効です。" [[extra.faqs]] question = "AIコーディングツールを使った採用選考はどう設計すればいいですか？" answer = "「AI使用可能」のオープンブック形式でコーディングテストを実施します。評価は解の正確さだけでなく、AI活用の判断とプロセスを評価します。面接後に「どこをAIに頼んで、どこを自分で考えたか」を聞くと、AIとの協働能力が分かります。AIに全部投げる候補者と、要件定義・設計の判断は自分で行いAIを実装補助に使う候補者の違いが明確に出ます。" [[extra.faqs]] question = "新しいエンジニア評価軸を採用現場に導入するときの注意点は何ですか？" answer = "2点あります。①既存の面接官の習慣を変えるには、新評価軸の「良い回答例・悪い回答例」を具体的に示す必要があります。「プロセスを評価する」だけでは各人の判断基準がバラバラになります。②「AIを使えること」を必須要件にすると、ツールに慣れているだけの候補者を選んでしまうリスクがあります。ツールの習熟度でなく「AIの出力を適切に評価・修正できるか」という判断力を軸にすることが重要です。" +++ AIが開発の標準ツールになった今、エンジニアの採用評価も変わらざるを得ない。 「コーディングテストの結果が良い」だけでは測れない能力が、現場では求められている。実際の採用現場で変わった評価軸を3点にまとめた。 --- ## 評価軸1：「調べながら解く」能力 従来のコーディングテスト：ドキュメントなし、メモリ内の知識で解く。 AI時代の現場の実態：検索、ドキュメント参照、AIとの対話を使いながら問題を解く。 この乖離が大きくなっている。「AIなし環境でのコーディングテスト」で高得点でも、実際の業務で「AIと一緒に考える」ことが苦手な人がいる。逆に「暗記は苦手だが、情報を統合して素早く動く」人はコーディングテストのスコアが平凡でも現場で力を発揮する。 **評価の変え方：** コーディングテストを「オープンブック」にする。検索可能、AIへの質問可能という条件で実施する。評価するのは「解の質」だけでなく「情報を組み合わせてどう解にたどり着いたか」のプロセス。 面接でコードを見せてもらう場合も「これを書いた時にどこで詰まりましたか、何で解決しましたか」という質問を加える。 --- ## 評価軸2：「問いの立て方」 AIは「どう解くか」の部分は高速化する。しかし「何を解くべきか」の問いを立てるのは人間だ。 エンジニアに「この機能の仕様書を書いてください」と依頼した時、良いエンジニアは「この機能はなぜ必要ですか」「誰が使いますか」「使わないケースはどれですか」と聞いてくる。そこから書かれた仕様書と、依頼されたままに書いた仕様書は、品質が全く違う。 AIを使いこなすエンジニアは、AIへのプロンプト設計でも同じことをする。「コードを書いて」より「このユーザーがこういう操作をした時に、こういう理由でこういう状態を期待しているが、現状の実装でどんな問題が起きうるか」という問い方をする。 **評価の変え方：** 「この仕様でシステムを設計してください」という問題より、「この状況でどんな問いを立てますか」という形式の評価問題を使う。 面接では「前の職場で、最初の問いが間違っていたと気づいた経験はありますか。その時どうしましたか」と聞く。 --- ## 評価軸3：「チームでの文脈共有能力」 AIを使うと個人の生産性は上がる。しかし、AIが書いたコードの意図を他のメンバーに伝えられなければ、チームの生産性は上がらない。 AI時代に重要性が上がった能力： - ドキュメントを書く習慣（自分だけが理解しているコードは負債になる） - レビューで「なぜこう書いたか」を説明する能力 - 「AIが提案したが採用しなかった理由」を説明できること **評価の変え方：** 「過去に書いた中で、他のメンバーが引き継ぐのが難しいと感じたコードはありますか。その時どうしましたか」と聞く。 技術面接で見せてもらうコードについて「このコードをチームに引き継ぐとしたら、何を説明しますか ？」という質問をする。ここでの説明の質が、チームでの価値に直結する。 --- ## 何が変わっていないか 「コードを速く書ける」「バグを少なくできる」「パフォーマンスを意識できる」という基本は変わっていない。 AIがコードを生成するようになっても、「そのコードが正しいかを判断する能力」は人間が持つ必要がある。AIの出力を評価するための基礎的な技術力は、むしろ重要性が増している。 AIで変わったのは「どこに時間をかけるべきか」だ。単純な実装のスピードより、判断の質に時間を使えるエンジニアの価値が上がっている。 --- ## 採用面接への反映（実用例） | 従来の評価 | AI時代の評価に加えるもの | |---|---| | コーディングテスト（クローズドブック） | プロセスを見る（検索可能条件で） | | 技術知識の確認 | 「知らない技術にどう向き合うか」の確認 | | 設計力の確認 | 「問いの立て方」の確認 | | 過去の実績確認 | 「チームにどう伝えたか」の確認 | 評価軸を変えることより、「なぜその軸を見るか」をチームで共有することの方が難しい。新しい評価基準を採用チーム全体で合意してから、面接に組み込む順序が重要だ。 --- ## 関連記事 - [AIエンジニアを採用しても活かせない組織のパターン](/n/ai-engineer-hired-but-underused/) — 評価軸を変えても活かせない組織側の問題 - [AI採用でカルチャーフィットを評価できない理由](/n/ai-hiring-culture-fit-limits/) — 技術評価とカルチャー評価の両立の難しさ - [AI採用スクリーニングと人間判断の境界線](/n/ai-screening-human-judgment-line/) — AI時代のエンジニア評価でAIツールをどこに組み込むか