エンジニア面接の技術力評価は、基礎技術力・問題解決力・設計思考・学習能力・協働力の5軸に配点を割り振り、レベル別に合格基準を変えて測るのが基本です。技術力は「知っているか」ではなく「未知の問題にどう向き合うか」で差が出るため、質問と課題を事前に設計し、面接官全員が同じ基準で採点できる状態をつくることが精度を左右します。

TL;DR（この記事の要約）

• エンジニア面接の技術力評価は基礎技術力・問題解決力・設計思考・学習能力・協働力の5軸でバランスよく設計する

• 評価精度を高めるには段階的な面接プロセス（基礎確認→実技→深掘り）が有効

• ジュニア・ミドル・シニアのレベル別に質問と評価基準を変えることで、適切な見極めができる

• 職種別（フロントエンド・バックエンド・インフラ）の専門評価項目を加えることでミスマッチを防ぐ

• AI時代の技術面接ではAIツール活用力やAI出力のレビュー能力も評価軸に加える必要がある

• 面接官のバイアス排除と構造化面接の導入が、評価ブレの防止に直結する

このページでわかること

この記事では、エンジニア面接における技術力評価の設計方法を体系的に解説します。

• 技術力を正しく測るための5つの評価軸と配点設計

• レベル別（ジュニア・ミドル・シニア）の質問例と評価ポイント

• 職種別（フロントエンド・バックエンド・インフラ）の専門評価

• AI時代に追加すべき技術面接の新しい評価軸

• 面接官が陥りやすい評価バイアスとその回避策

想定読者: エンジニア採用に関わる人事担当者、エンジニアリングマネージャー、面接官を務めるエンジニア。

なぜエンジニア面接の技術力評価は難しいのか

エンジニア面接の技術力評価が難しい理由は、技術の階層が深く、職務経歴書の記載と実際の習熟度が一致しにくいことにあります。背景には次の3つの構造的要因があります。

1. 技術の専門性と階層の深さ

同じ「JavaScript得意です」でも、DOM操作レベル（初級）からV8エンジンの内部動作理解（エキスパート）まで大きな幅があります。面接の限られた時間で候補者の実際のレベルを把握するには、意図的に設計された質問と評価基準が不可欠です。

2. 実務経験と知識のギャップ

「Docker 3年経験」と記載されていても、実態は「先輩が作ったDockerfileでdocker runを実行していただけ」というケースは珍しくありません。このギャップを見抜くには、実際の経験に基づいた深掘り質問が必要です。

3. 面接官側の技術的知識の限界

非エンジニアの人事担当者が技術力を正確に評価するのは構造的に困難です。技術面接には現場のエンジニアの参加が不可欠であり、人事はカルチャーフィットやコミュニケーション力の評価に集中する役割分担が効果的です。

評価精度が採用コストに直結する理由

技術力評価の精度は、そのまま採用コストに跳ね返ります。人材が不足している市場では、選考基準を曖昧にしたまま「とりあえず会ってみる」運用に流れやすく、面接工数だけが増えていきます。

【市場データ】IT人材の不足規模 経済産業省「IT人材需給に関する調査」（2019年公表）では、IT人材の不足が2030年時点で最大約79万人に達すると試算されています。母集団が構造的に不足する市場では、限られた候補者を正確に見極める評価設計そのものが競争力になります。 出典: 経済産業省「IT人材需給に関する調査」（2019年）

採用ミスマッチが発生すると、人材紹介手数料・研修コスト・プロジェクト遅延による機会損失など、年収の数倍に相当するコストが発生するとされています。技術力評価の精度を上げることは、採用コストの最適化に直結する重要な取り組みです。採用要件の明確化については「エンジニア採用ペルソナ設計ガイド」、ミスマッチの防ぎ方は「エンジニア採用のミスマッチ防止ガイド」も参考になります。

技術力評価の5つの軸と配点設計

技術力評価は「何を、どの比重で測るか」を面接前に決めておく必要があります。配点を決めずに面接に入ると、面接官ごとに重視する項目がずれ、同じ候補者への評価が食い違います。以下の5軸は、多くのエンジニア採用で共通して使える評価フレームワークです。

1. 基礎技術力（30点） — 応用の土台となる知識と実装力。コーディング課題や概念説明で確認する

2. 問題解決力（25点） — 未知の問題に対するアプローチ。デバッグ体験談や設計課題で確認する

3. 設計思考（20点） — システム全体を俯瞰する力。アーキテクチャ設計問題で確認する

4. 学習能力（15点） — 技術変化への適応力。新技術習得の体験談や学習方法で確認する

5. 協働力（10点） — チーム開発での貢献。コードレビュー経験や過去のチーム事例で確認する

配点はポジション要件に応じて調整します。評価項目を面接官間で揃える仕組みは「エンジニア採用の面接スコアカード設計ガイド」で詳しく解説しています。

職種別の配点調整

ポジションの特性に応じて、追加の評価項目を設定します。フロントエンドならUI/UX理解度やブラウザ最適化知識、バックエンドならDB設計やセキュリティ意識、インフラなら障害対応力やIaC経験など、職種固有のスキルに追加配点を加えることで、より精度の高い評価が可能になります。

配点を決めるときに外してはいけない観点

採用コンサル営業を経て現在はエンジニアとして開発している立場から見ると、評価軸の設計で失敗するのは「求人票に書いた要件」と「面接で測る項目」が別物になっているケースです。スカウト運用の現場でも、求人票では「設計経験」を求めているのに面接では基礎文法の確認に時間を使ってしまい、判断材料が集まらないまま合否を決める場面がありました。配点表をつくったら、求人票の必須要件と1対1で対応しているかを必ず突き合わせてください。

段階的な面接プロセスの設計

面接は1回で全項目を測るのではなく、段階を分けたほうが精度が上がります。候補者の緊張をほどきながら情報を積み上げ、後段で深掘りする構成が有効です。

1. 第1段階：アイスブレイクと基礎確認（15〜20分） — 経歴の整合性、転職理由、技術への姿勢を確認する

2. 第2段階：実技による技術力確認（30〜40分） — コーディングや設計課題で「実際にできるか」を確認する

3. 第3段階：深掘りと将来性の確認（20〜30分） — 実技の内容を起点に判断力と成長ポテンシャルを掘り下げる

第1段階：アイスブレイクと基礎確認（15-20分）

最初から技術的に難しい質問を投げると、候補者が緊張して本来の実力を発揮できないリスクがあります。まずはリラックスした雰囲気で、コミュニケーション能力の初期評価、技術的な経歴の整合性、転職理由の妥当性、技術に対する姿勢や志向性を確認します。

第2段階：実技による技術力確認（30-40分）

面接プロセスの中核です。「できます」という自己申告と「実際にできる」の間にあるギャップを確認します。制限時間は30-40分、難易度は段階的に設定し、思考プロセスを声に出してもらうのがポイントです。完璧な解答より、問題へのアプローチと思考の深さを重視します。

コーディング課題の設計は「コーディング試験設計ガイド」、ペアプログラミング形式は「ペアプロ・ライブコーディング面接ガイド」、試験ツールの選び方は「コーディング試験ツール選定ガイド」もあわせてご覧ください。

第3段階：深掘りと将来性の確認（20-30分）

実技の結果を踏まえ、技術的な判断力や成長ポテンシャルを掘り下げます。「先ほどの課題で別のアプローチは検討しましたか？トレードオフをどう考えましたか？」のように、実技の内容を起点にした深掘り質問が効果的です。

レベル別の面接質問と評価ポイント

同じ質問を全レベルに使うと評価がぶれます。ジュニアには基礎と学習姿勢、ミドルには設計判断、シニアには技術的リーダーシップと、測る対象を明確に切り替えてください。

ジュニアエンジニア（経験1-3年）：基礎力と学習姿勢の確認

ジュニアエンジニアの面接では、基礎がしっかりしているかを最優先で確認します。応用力や設計力は入社後の成長に期待できるため、現時点での土台の堅さと学習意欲に焦点を当てます。

Q1: 「一番得意な言語について、なぜその言語を選んだのか、どんな特徴があるのか教えてください」

この質問で確認できること:

• 技術選択に明確な理由があるか

• 言語の特徴（メリット・デメリット含む）を理解しているか

• 継続的な学習意欲があるか

良い回答の特徴: 選択理由が明確で、言語の長所だけでなく短所も認識している。他の言語との比較や学習の方向性にも言及できるとなお良い。注意すべきは「会社で使っているから」「何となく」など、主体的な選択の意図が見えない回答です。

Q2: 「バージョン管理システムを使った開発で、困った経験はありますか？どう解決しましたか？」

チーム開発の実務経験、トラブルシューティング能力、経験から学びを得る姿勢を確認できる質問です。具体的なエピソードがあり、原因特定から解決、さらに再発防止策まで言及できると高評価です。

コーディング課題の評価基準（ジュニア向け）:

ミドルエンジニア（経験3-7年）：設計力と実務の深さ

ミドルエンジニアには、自分で設計・実装判断ができる力を求めます。基礎力の確認に加え、実務での問題解決経験と設計思考を重点的に評価します。

Q3: 「これまでで一番苦労したバグについて教えてください。原因の特定から解決までのプロセスを詳しく聞かせてください」

実務経験の深さが如実に現れる質問です。体系的なデバッグアプローチ、根本原因の特定能力、再発防止策の検討（チーム全体への横展開）、技術的な深さを確認します。

Q4: 「API設計で重要だと思うポイントを3つ教えてください」

一貫性（命名規則、HTTPメソッドの使い分け）、セキュリティ（認証・認可、入力値検証）、拡張性（バージョニング、ページネーション）の3観点を、実体験を交えて説明できるかがポイントです。

システム設計課題（ミドル向け）:

「社員500名規模の勤怠管理システムを新規構築します。出退勤の打刻、有給申請・承認、管理者レポート、スマートフォン対応が必要です。どのようなアーキテクチャで設計しますか？」——要件整理、技術選択の理由、スケーラビリティ、セキュリティ・運用面の配慮を各25点で評価します。

シニアエンジニア（経験7年以上）：技術的リーダーシップと判断力

シニアエンジニアには、個人の技術力だけでなく、チームや組織に対する技術的なリーダーシップを期待します。

Q5: 「技術的負債について、どのように向き合っていますか？」

技術的負債の定量的な把握、優先順位をつけた改善アプローチ、経営層への説明能力、チーム全体を巻き込む推進力を評価します。単に「リファクタリングした」ではなく、棚卸し→定量化→優先順位→段階的改善→効果測定というサイクルを説明できるかがポイントです。

Q6: 「チームメンバーのスキルレベルがバラバラな時、どうやってプロジェクトを進めますか？」

マネジメント能力と技術的リーダーシップを確認する質問です。タスクの分配、メンタリング、コードレビューの設計など、チーム全体のアウトプットを最大化する視点がポイントです。面接後の合否判定会議（デブリーフ）の進め方については「エンジニア採用の面接デブリーフと合否判定の仕組み化ガイド」で解説しています。

レベル別の合格ラインの目安

同じ評価シートを使いながら、通過ラインだけをレベルで変えるのが運用上もっとも簡単です。目安は次の通りです。

1. ジュニア（1〜3年） — 総合60%以上。基礎技術力と学習能力で下限を割っていないことを重視する

2. ミドル（3〜7年） — 総合70%以上。問題解決力と設計思考のいずれかで高得点が出ていることを条件にする

3. シニア（7年以上） — 総合80%以上。設計思考と協働力の両方が水準を満たしていることを必須とする

職種別の専門評価

5軸の共通評価に加えて、職種固有の観点を1〜2問足すとミスマッチが大きく減ります。共通質問だけでは、その職種で本当に必要な深さに届きません。

フロントエンドエンジニア

「デザインができる＝優秀」という誤解に注意が必要です。パフォーマンス最適化、アクセシビリティ、SEO対策、ブラウザ互換性対応、保守性の高いコード設計といった技術的な深さを評価します。

Q7: 「Webページの読み込み速度を改善する方法を、できるだけ多く挙げてください」

画像最適化（WebP/AVIF、遅延読み込み）、CSS/JSの圧縮・ツリーシェイキング、CDN活用、キャッシュ戦略、Critical CSS、Service Workerなど。回答の数だけでなく、どの場面で使うかの判断力も評価ポイントです。

Q8: 「Virtual DOMについて、メリットとデメリットを含めて説明してください」

フレームワークを「使える」レベルと「理解している」レベルの差を確認できます。

バックエンドエンジニア

表面からは見えない部分への配慮が評価の軸です。

データベース設計課題: ECサイトのDB設計（商品・ユーザー・注文・レビュー）を出題し、正規化の適切な適用、インデックス設計、拡張性への配慮、パフォーマンスとデータ整合性のトレードオフ理解を評価します。

インフラエンジニア

障害時の対応力が最も重要な評価軸です。

Q9: 「深夜にサーバーダウンのアラートが発生しました。どのような手順で対応しますか？」

影響範囲の把握、関係者への第一報、監視ツールを活用した原因調査、応急処置と根本対応の切り分け、障害報告書の作成とチームへの知見共有——これらを体系的に説明できるかを確認します。

AI時代の技術面接で加えるべき評価軸

AIコーディングツールが標準装備になった環境では、「AIなしで書けるか」を測る意義は薄れています。評価すべきは、AIの出力を検証し、責任を持って採用できるかどうかです。詳しくは「AI時代のエンジニア技術面接リデザイン」も参照してください。

AIツール活用力の評価

GitHub Copilot・Claude Code・Cursorなどが日常の開発環境に組み込まれた今、AIをどう使いこなしているかが重要な評価軸です。

Q10: 「普段の開発でAIコーディングツールをどう活用していますか？AIが生成したコードに対して、どのようなレビュー基準を持っていますか？」

AIツールの得意・不得意の理解、出力の適切なレビュー能力、AIに依存しすぎず基礎力を維持しているかを確認します。

AI出力のレビュー能力

Q11: 「AIが生成したコードにバグやセキュリティリスクが含まれていた経験はありますか？どう対処しましたか？」

AIが生成したコードにはセキュリティリスクやパフォーマンス問題が含まれる可能性があります。これを見抜く力は今後ますます重要です。

AI不正対策

面接でのAI不正利用への対策も重要です。思考プロセスの言語化、ペアプログラミング形式でのリアルタイム対話、フォローアップ質問による理解度確認、AIが苦手な「トレードオフ判断」の出題が有効です。詳しくは「エンジニア採用のAI不正・カンニング対策ガイド」をご覧ください。

オンライン技術面接での評価設計

リモート前提の技術面接では、評価そのものより「観察できる情報が減ること」が精度低下の原因になります。対面と同等の判断材料を揃えるには、環境と進め方を設計しておく必要があります。

1. 画面共有を前提にした課題設計 — 手元で完結する課題ではなく、思考を可視化させる出題にする

2. オンラインエディタの事前共有 — 環境構築でつまずく時間を評価から切り離す

3. 通信トラブル時の代替手順を用意 — 接続不良を候補者の減点材料にしない運用を明示する

オンライン面接全体の設計は「エンジニアのオンライン面接・リモート採用ガイド」で詳しく解説しています。

面接官が避けるべき評価バイアス

技術力評価の精度を下げる最大の要因は、候補者側の実力不足ではなく面接官側のバイアスです。以下の3つは特に発生頻度が高く、対策の効果も大きい項目です。

1. 「知識の豊富さ＝優秀」の錯覚 — 最新フレームワークの知識量を実務成果と混同してしまう

2. コミュニケーション力の過小評価 — 技術的な説明力やメンタリング能力を評価対象から外してしまう

3. 圧迫面接による実力の見誤り — 過度な緊張状態で候補者本来の力を測れなくなる

バイアス1：「知識の豊富さ＝優秀」の錯覚

最新フレームワークを多く知っていることと、実務で成果を出せることは別物です。基礎がしっかりしていれば新しい技術は後から習得できますが、基礎が弱いとトレンドが変わるたびに対応できなくなります。基礎力と実装経験の深さを評価の中心に据えましょう。

バイアス2：コミュニケーション力の過小評価

特にシニアレベルでは、技術的な説明能力・メンタリング能力・建設的な議論力がチーム全体のパフォーマンスに大きく影響します。コードレビューで一方的に指摘するだけのエンジニアは、チームの心理的安全性を損なうリスクがあります。

バイアス3：圧迫面接による実力の見誤り

候補者の本来の能力を引き出すには、リラックスできる雰囲気作り、段階的な難易度設定、思考プロセスの言語化を促すアプローチが有効です。圧迫面接は候補者体験を低下させ、採用ブランドの毀損にもつながります。

よくある質問

Q: 技術面接でコーディング課題は必須ですか？

技術力を客観的に評価するうえで非常に有効です。制限時間は30-45分、業務に直結する実践的な問題を選び、完璧な解答より思考プロセスを重視するのがコツです。詳しい設計方法は「エンジニア採用のコーディング試験設計と公平な評価の実践ガイド」をご覧ください。

Q: 非エンジニアの人事担当者でも技術面接はできますか？

基礎的な質問や論理的思考力の評価は可能ですが、技術的な深掘りには限界があります。現場のシニアエンジニアに技術面接を担当してもらい、人事は候補者体験やカルチャーフィットの評価に集中する役割分担が効果的です。

Q: リモート面接でも技術力評価はできますか？

画面共有でのコーディング過程の確認、オンラインエディタの活用、ペアプログラミング形式での対話など、適切な環境を整備すれば対面と同等の評価が可能です。

Q: 技術面接の合否基準はどう設定すべきですか？

一般的な目安として、ジュニア（1-3年）は60%以上、ミドル（3-7年）は70%以上、シニア（7年以上）は80%以上です。ただし組織の状況や求める人材像に合わせた調整が必要です。合否判定の仕組み化は「エンジニア採用の面接デブリーフと合否判定の仕組み化ガイド」をご参考ください。

Q: 面接官のスキルアップはどう進めればよいですか？

面接官トレーニングは「模擬面接の実施→振り返り→改善」のサイクルで進めるのが効果的です。まず評価基準を全面接官で共有し、同じ候補者に対する評価のブレがないかを確認します。評価が分かれたケースを題材に、何を重視すべきか議論することで、チーム全体の評価精度が向上します。月1回程度の定期的な面接官ミーティングを設けることを推奨します。具体的な進め方は「エンジニア採用の面接官トレーニングガイド」で解説しています。

Q: 面接官によって評価が食い違う場合はどうすればよいですか？

評価が割れること自体は問題ではなく、割れた理由を言語化できないことが問題です。評価シートに「その点数を付けた根拠となる候補者の発言・成果物」を必ず記録するルールにし、デブリーフでは点数ではなく根拠を突き合わせてください。根拠が同じで解釈が違うなら基準の言葉が曖昧であり、根拠が違うなら質問設計が不足しているというように、原因の切り分けができます。

多様性と公平性への配慮

構造化面接による評価基準の統一、複数面接官の配置、学歴や前職にとらわれないスキルベースの評価が基本です。リモート面接オプションの提供や、障がいのある候補者への合理的配慮など、すべての候補者が公平に実力を発揮できる環境を整えることが重要です。

まとめ

エンジニア面接の技術力評価は、準備と設計によって大きく精度が変わります。すぐに取り組めるアクションを整理します。

1. 短期（1-2週間） — 職種別・レベル別の評価マトリックスを作成し、面接官全員で評価基準を共有する

2. 中期（1-2ヶ月） — 業務に直結するコーディング課題を3-5問作成し、AI時代に対応した評価項目を追加する

3. 長期（3-6ヶ月） — 採用結果の定期分析、面接官トレーニング、候補者フィードバック収集で面接体験を改善する

技術力評価の改善は、一度やって終わりではなく、継続的なPDCAが必要です。「どの評価項目が入社後の活躍を予測できているか」を定期的に検証することで、面接プロセスの精度は着実に向上します。

採用支援のご相談はtechcellarへ。