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

• ペアプログラミング面接とライブコーディング面接は、候補者の思考プロセス・コミュニケーション力・問題解決の進め方をリアルタイムで評価できる選考手法

• テイクホーム課題や筆記テストでは見えない「チームで働く力」を可視化できるのが最大の強み

• 面接官は「試験官」ではなく**「同僚」としてふるまう**のが設計の基本原則

• 課題の難易度設定・時間配分・評価ルーブリックを事前に標準化しておかないと、面接官ごとの評価ブレが起きる

• AI時代にはコードの暗記力ではなく、AI出力を検証・改善する力を測る設計へのアップデートが必要

このページでわかること

• ペアプログラミング面接とライブコーディング面接の違いと使い分け

• 課題設計の具体的な手順と「良い課題」の条件

• 面接官の役割設計とトレーニング方法

• 評価ルーブリックの作り方と運用のコツ

• AI時代に対応した出題・評価の再設計

• リモート環境での実施方法とツール選定

• 候補者体験を高める運用の工夫

1. なぜ今「実技系面接」が注目されているのか

エンジニア採用の選考手法は、ここ数年で大きく変化している。

従来主流だった「経歴の確認＋技術質問」だけでは、候補者の実務能力を正確に測れないという課題がある。レジュメ上のスキルセットと実際のコーディング力が一致しないケースは多い。

一方で、テイクホーム課題（持ち帰り型）は候補者の負担が大きく、選考辞退の原因になりやすい。コーディング試験全般の設計については「エンジニア採用のコーディング試験設計と公平な評価の実践ガイド」で詳しく解説している。転職活動中のエンジニアは複数社を並行して受けており、「課題に8時間かけてください」と言われた時点で離脱してしまう。

こうした背景から、面接時間内に完結し、かつ実務に近い能力を評価できる手法として、ペアプログラミング面接とライブコーディング面接の導入が広がっている。

実技系面接のメリット

• 思考プロセスが見える: 正解にたどり着くまでの過程を観察でき、「考え方」を評価できる

• コミュニケーション力の評価: 技術的な議論・質問の仕方・説明能力がリアルタイムで分かる

• カルチャーフィットの判断材料: 一緒に働いたときのイメージが湧きやすい

• 候補者側の負担軽減: 面接時間内で完結するため、テイクホーム課題より拘束時間が短い

実技系面接のリスク

• 緊張によるパフォーマンス低下で実力が測れない

• 面接官のスキルによって評価の質が大きくブレる

• 設計が甘いと「ただコードを書かせるだけの場」になる

これらのリスクは、後述する設計と運用の工夫で大幅に軽減できる。

2. ペアプログラミング面接とライブコーディング面接の違い

混同されやすいこの2つの手法は、面接官の関与度と評価ポイントが異なる。

ライブコーディング面接

概要: 候補者が1人でコードを書き、面接官はその過程を観察する。必要に応じて質問やヒントを出す。

評価の重点:

• 独力での問題分解力

• コードの品質（可読性、命名、構造化）

• デバッグ・エラーハンドリングの力

• 制限時間内のタイムマネジメント

向いているケース:

• ジュニア〜ミドルレベルの技術力を客観的に測りたい

• アルゴリズムやデータ構造の基礎力を確認したい

• 選考の初期フェーズで足切り的に使いたい

ペアプログラミング面接

概要: 面接官と候補者が一緒にコードを書く。面接官は「同僚」として振る舞い、相互にコミュニケーションを取りながら課題を進める。

評価の重点:

• 協働・コミュニケーション力

• 他者の意見を取り入れる柔軟性

• 技術的な議論・提案力

• コードレビューに近いやりとりの質

向いているケース:

• チームワーク重視の開発組織

• ミドル〜シニアレベルのエンジニア選考

• 候補者体験を重視したい場合（対話的で一方的に「試される」感覚が減る）

使い分けの判断基準

実際には両方を選考フローに組み込む企業も多い。選考フロー全体の設計については「エンジニア採用の選考フロー設計完全ガイド」を参照してほしい。たとえば、1次選考でライブコーディング（基礎力確認）→ 2次選考でペアプログラミング（協働力確認）というフローは効果的だ。

3. 課題設計の具体的な手順

面接の成否を分けるのは、課題の質だ。課題設計を適当にやると、評価の精度が下がるだけでなく、候補者に「この会社の技術力は大したことない」という印象を与えてしまう。

良い課題の5つの条件

1. 実務に近い 競技プログラミングのような問題ではなく、日常の開発業務に近い課題を出す。API設計、データ変換、小規模なリファクタリングなど。

2. 段階的に深められる 基本実装 → 機能拡張 → エッジケース対応、のように段階的に難易度を上げられる設計にする。候補者のレベルに応じて到達点が変わるため、ジュニアからシニアまで同じ課題で評価できる。

3. 制限時間内に完了可能 基本実装が制限時間の50〜60%で完了できる難易度に設定する。残りの時間で発展的な議論ができる余裕を持たせる。

4. 特定の技術に依存しすぎない 「Reactの特定のフックの使い方を知っているか」ではなく、「状態管理の考え方を理解しているか」を測れる課題にする。ただし、採用ポジションが特定技術を前提とする場合は例外。

5. 正解が1つではない 複数のアプローチが可能な課題にすることで、候補者の設計判断力を評価できる。

課題設計の具体的なステップ

ステップ1: 評価したい能力を明確にする

まず「この面接で何を測りたいのか」を定義する。

• 基礎的なコーディング力（構文、ロジック、データ構造）

• 設計力（抽象化、モジュール分割、責務の分離）

• 問題解決の進め方（仮説→検証のサイクル）

• コミュニケーション（考えの言語化、質問の仕方）

欲張って全部を1つの課題で測ろうとしないこと。1つの課題で測る能力は2〜3個に絞る。評価基準の設計については「エンジニア採用の構造化面接設計ガイド」のルーブリックの考え方も参考になる。

ステップ2: 課題のプロトタイプを作る

社内のエンジニアに実際に解いてもらい、以下を検証する。

• 想定時間内に基本実装が完了するか

• 複数のアプローチが可能か

• 課題文の解釈にブレがないか

ステップ3: ルーブリック（評価基準）を同時に作る

課題とセットで評価基準を作る。これを後回しにすると、面接官ごとの「なんとなくの印象」で合否が決まってしまう。ルーブリックの具体的な作り方は後述する。

ステップ4: 定期的に課題を更新する

同じ課題を長期間使い続けると、口コミサイトやSNSで課題内容が流出するリスクがある。半年に1回は課題のローテーションを行う。

課題例：バックエンド編

基本課題: REST APIのエンドポイントを1つ実装する

「ユーザーの注文履歴を取得するAPIを設計・実装してください。入力はユーザーIDで、直近30日分の注文をページネーション付きで返してください。」

• 基本: APIの設計とデータ取得ロジックの実装

• 発展1: ページネーションの設計（カーソルベース vs オフセットベース）とその選択理由

• 発展2: キャッシュ戦略の議論

• 発展3: エラーハンドリング・バリデーション

課題例：フロントエンド編

基本課題: 既存コンポーネントのリファクタリング

「この検索フォームコンポーネントは動作するが、状態管理が複雑になっている。リファクタリングしてください。」

あらかじめ「動くが改善の余地があるコード」を準備しておく。

• 基本: 状態の整理と不要な再レンダリングの排除

• 発展1: カスタムフックへの切り出し

• 発展2: アクセシビリティの改善提案

• 発展3: テストコードの追加

4. 評価ルーブリックの作り方と運用

「なんとなく良かった」「コミュニケーションが上手だった」では、再現性のある採用判断にならない。ルーブリックを使って評価を言語化・数値化する。

ルーブリックの基本構造

各評価軸に対して4段階（1〜4）でスコアリングする。

評価軸の例（ペアプログラミング面接）:

問題分解力

• 4（優秀）: 問題を適切なサイズに分解し、優先順位をつけて取り組める

• 3（合格）: 問題を分解して段階的に進められる

• 2（改善要）: 問題を分解しようとするが、手順が不明確

• 1（不合格）: 問題全体に一度に取り組もうとし、行き詰まる

コミュニケーション

• 4（優秀）: 考えを自発的に言語化し、面接官と建設的な議論ができる

• 3（合格）: 聞かれれば考えを説明でき、フィードバックを取り入れられる

• 2（改善要）: 説明が少なく、面接官が引き出す必要がある

• 1（不合格）: 無言でコーディングを続け、対話がほぼ成立しない

コード品質

• 4（優秀）: 命名・構造が明確で、エッジケースも考慮。レビュー不要なレベル

• 3（合格）: 読みやすいコードで基本的な設計原則を守っている

• 2（改善要）: 動くコードだが、可読性や構造に改善の余地が多い

• 1（不合格）: 動かないコード、または著しく可読性が低い

設計判断

• 4（優秀）: トレードオフを理解した上で設計を選択し、理由を明確に説明できる

• 3（合格）: 合理的な設計を選び、聞かれれば理由を説明できる

• 2（改善要）: 設計の選択理由が不明確、またはベストプラクティスから乖離

• 1（不合格）: 設計の意思決定ができない、または一貫性がない

ルーブリック運用の3つのルール

ルール1: 面接直後にスコアリングする

記憶が鮮明なうちに採点する。他の面接官と合議する前に、まず個人の評価を確定させること。先にスコアを出してから議論することで、声の大きい人に引っ張られるのを防げる。

ルール2: スコアには必ず根拠メモを添える

「コミュニケーション: 3」だけでなく、「ハッシュマップの選択理由を聞いた際に、時間計算量の観点から論理的に説明できた」のように具体的な場面を記録する。

ルール3: 四半期に1回キャリブレーションを行う

面接官全員で過去の評価事例を振り返り、スコアの基準がズレていないか確認する。「この候補者のコミュニケーションを3にした理由は？」と議論することで、評価の目線を揃えていく。

5. 面接官の役割設計とトレーニング

実技系面接では、面接官のスキルが候補者体験と評価精度に直結する。面接官のトレーニングなしに導入すると、失敗する可能性が高い。

ペアプログラミング面接での面接官の振る舞い

やるべきこと:

• 冒頭で「一緒に仕事をするイメージで進めましょう」と明確に伝える

• 候補者が詰まったら、答えではなく「次に考えるべき方向」をヒントとして出す

• 「なぜその設計にしたのか」「他にどんなアプローチがあるか」とオープンな質問をする

• 良いアプローチには「いいですね」とリアクションする

やってはいけないこと:

• 腕組みをして無言で見つめる（圧迫面接になる）

• 候補者のコードを即座に否定する

• 自分の好みのアプローチに誘導する

• 候補者の発言中に遮って正解を言う

ライブコーディング面接での面接官の振る舞い

やるべきこと:

• 「質問があればいつでも聞いてください」と伝える

• 5分以上完全に詰まっている場合はヒントを出す

• 実装の途中で「ここまでの設計意図を教えてください」と確認を入れる

やってはいけないこと:

• 制限時間のカウントダウンをプレッシャーとして使う

• 候補者のタイピングミスや些細なシンタックスエラーを指摘する

• 見ていて不安な表情をする

面接官トレーニングの進め方

ステップ1: シャドウイング（2〜3回）

経験豊富な面接官の面接に同席し、進め方・ヒントの出し方・評価のつけ方を観察する。

ステップ2: リバースインタビュー（1〜2回）

社内のエンジニアを「候補者役」として模擬面接を行う。終了後に候補者役からフィードバックをもらう。

ステップ3: 本番＋振り返り（3回）

実際の面接に面接官として参加し、毎回ベテラン面接官と振り返りを行う。スコアのつけ方の差異があれば議論する。

一般的に、面接官として独り立ちするまでに6〜8回の面接経験が必要とされている。面接官トレーニング全般については「エンジニア採用の面接官トレーニング｜評価精度を高める実践手法」も参考にしてほしい。トレーニングへの投資を惜しまないことが、長期的な採用品質の向上につながる。

6. AI時代の実技系面接の再設計

GitHub CopilotやCursorといったAIコーディングアシスタントの普及により、実技系面接の前提が変わりつつある。AI時代の技術面接全般については「AI時代のエンジニア技術面接リデザイン」でも解説している。

「コードを書く力」だけでは不十分

AIが基本的なコーディングを代行できる時代において、面接で測るべき能力は以下にシフトしている。

AIコラボレーション力

• AIが生成したコードの正しさを検証できるか

• AIへの指示（プロンプト）を適切に設計できるか

• AIの出力を元に、より良い設計へ改善できるか

メタ認知力

• 「何が分からないか」を特定し、適切な情報源（AI含む）にアクセスできるか

• 複数のアプローチの中からトレードオフを評価して選択できるか

システム思考

• 個々のコードではなく、システム全体の設計を俯瞰できるか

• 非機能要件（パフォーマンス、セキュリティ、保守性）を考慮した判断ができるか

AI時代の課題設計のポイント

1. AIが即座に正解を出せない課題を設計する

単純なアルゴリズム問題は、AIに聞けばすぐに答えが出る。代わりに、以下のような課題を設計する。

• 自社の実際のドメインに即した課題（公開情報にない文脈理解が必要）

• 要件が曖昧で、候補者自身が要件を整理する必要がある課題

• 複数の制約条件があり、トレードオフの判断が求められる課題

2. AIの利用を前提とした面接設計

面接中にAIツールの使用を禁止するのではなく、むしろ許可してその使い方を評価する、という設計が増えている。

「AIが出力したコードをそのまま使いますか？ それとも修正しますか？ 修正するならどこを、なぜ？」

この問いかけが、候補者の技術的な判断力を最も鮮明に浮き彫りにする。

3. 設計議論の比重を高める

コードを書く時間を短縮し、設計のディスカッションに時間を割く。たとえば、「この機能を実装するとしたら、どのような設計にしますか？ まず10分間、設計を一緒に議論しましょう」というアプローチだ。

7. リモート環境での実施方法とツール選定

リモートでの実技系面接は対面とは異なるチャレンジがある。適切なツール選定と運用設計が重要だ。

リモート実施で注意すべきポイント

ネットワーク環境のトラブル対策

• 面接前に候補者へ推奨環境（ブラウザ、回線速度）を案内する

• トラブル発生時のリカバリー手順を事前に決めておく（電話に切り替える、時間を延長するなど）

• 録画の可否について事前に同意を取る

コミュニケーションの補完

• 対面と違い、表情やジェスチャーが読み取りにくい

• 面接官は意識的に声に出してリアクションする

• チャット機能も併用し、URLやコードスニペットの共有に使う

ツール選定の基準

リモート実技系面接に使えるツールは、大きく分けて汎用エディタ共有型と専用プラットフォーム型がある。

汎用エディタ共有型

Visual Studio Code Live Shareのように、普段使っているエディタで画面を共有する方式。候補者が慣れた環境で作業できるメリットがある一方、セットアップに手間がかかる場合がある。

専用プラットフォーム型

CoderPadやHackerRankのように、ブラウザ上でコーディング環境が完結するサービス。セットアップが不要で、面接官と候補者が同じ画面をリアルタイムで共有できる。実行環境も内蔵しているため、コードの実行結果をその場で確認できるのが利点だ。

ツール選定では、以下のポイントを確認する。

• リアルタイム共有: 面接官と候補者が同じコードをリアルタイムで見られるか

• 言語サポート: 採用ポジションで使う言語に対応しているか

• 実行環境: ブラウザ上でコードを実行できるか

• 録画機能: 後から振り返りができるか（候補者の同意が前提）

• 導入コスト: チームの規模と面接頻度に見合うか

8. 候補者体験を高める運用の工夫

実技系面接は、候補者にとってストレスが高い。運用次第で「この会社で働きたい」にも「二度と受けたくない」にもなる。

面接前の準備で差がつく

事前情報の提供

面接の3〜5営業日前に、以下を候補者に伝える。

• 面接の形式（ペアプログラミング or ライブコーディング）

• 使用する言語・環境（候補者が事前に選べるなら選択肢を提示）

• 面接の流れとおおよその時間配分

• 評価の観点（「コードの完成度ではなく、思考プロセスを重視します」等）

• 使用するツールのURL・アクセス方法

「何を評価されるか分からない」状態が最も候補者のストレスを高める。候補者体験（CX）の改善全般については「エンジニア採用CX（候補者体験）を改善して辞退率を下げる実践ガイド」も併せて読んでほしい。事前に透明にすることで、候補者は実力を出しやすくなり、結果として正確な評価につながる。

ウォームアップの時間を設ける

面接開始直後に本題に入るのではなく、5分程度のウォームアップを設ける。

• 面接官の自己紹介（名前、チーム、役割）

• 面接の進め方の説明

• 「質問はいつでもどうぞ」というメッセージ

• 環境の動作確認（リモートの場合は特に重要）

面接中の工夫

「正解を出すこと」がゴールではないと伝える

冒頭で「完成しなくても全く問題ありません。どう考えたかを教えてください」と明言する。これだけで候補者の緊張が大幅に和らぐ。

困っているときのサポート

候補者が5分以上詰まっている場合は、ヒントを出す。ヒントを出したこと自体は減点にしない。ヒントを受けてどう動いたかを評価する。

タイムキープの声かけ

「あと15分です」「基本部分はここまでで大丈夫です。残りの時間で設計の議論をしましょう」など、適切にタイムキープの情報を伝える。

面接後のフォロー

フィードバックの提供

可能であれば、選考結果とともに簡単なフィードバックを提供する。「設計のアプローチは良かったが、エッジケースへの考慮が不足していた」のような具体的なフィードバックは、候補者の成長につながり、企業の採用ブランド向上にも寄与する。

不合格の場合も丁寧に

不合格の通知は、できれば人事からの定型文ではなく、面接官からの一言を添える。「技術力は十分だが、現在のチーム構成と合うポジションがなかった」のように、具体的な理由があると候補者の納得感が高まる。

9. 導入ステップ：90日ロードマップ

実技系面接をゼロから導入する場合の目安スケジュールを示す。

Day 1〜30: 設計フェーズ

• 現在の選考フローを棚卸しし、実技系面接を挿入するポイントを決定

• ペアプログラミングとライブコーディングのどちらを（またはどちらも）導入するか決定

• 課題のプロトタイプを2〜3パターン作成

• 評価ルーブリックのドラフト作成

• 面接官候補（3〜5名）の選定

Day 31〜60: パイロットフェーズ

• 社内エンジニアを候補者役にした模擬面接を各面接官2〜3回実施

• 模擬面接のフィードバックを基に課題とルーブリックを修正

• 面接官向けマニュアル（進行台本、ヒントの出し方、評価の記入方法）を整備

• リモート実施の場合、ツールの選定と動作検証

Day 61〜90: 本番導入フェーズ

• 実際の候補者で本番実施開始

• 最初の5〜10件は、面接後にベテラン面接官と振り返りを行う

• 候補者にアンケートを送り、面接体験のフィードバックを収集

• 課題・ルーブリック・運用フローの微調整

90日あればチーム全体で運用を回せるレベルに到達できる。完璧を目指すのではなく、まず小さく始めて改善を繰り返すのがポイントだ。

10. よくある失敗パターンと対策

失敗1: 課題が難しすぎる

症状: ほとんどの候補者が基本実装すら完了できない。合格率が極端に低い。

対策: 社内で中堅レベルのエンジニア3人に解いてもらい、全員が制限時間の60%以内に基本実装を完了できるか検証する。できなければ課題の難易度を下げる。

失敗2: 面接官が「試験官」になっている

症状: 面接官が腕組みをして無言で観察。候補者が萎縮してパフォーマンスが出ない。

対策: 面接の冒頭5分のスクリプトを用意し、「一緒にコードを書く場です」というメッセージを徹底する。面接官のトレーニングで「候補者役」を経験させ、試される側の心理を理解させる。

失敗3: ルーブリックが形骸化している

症状: ルーブリックは作ったが、実際の評価は「なんとなくの印象」で決まっている。

対策: 面接直後に個別でスコアリングを完了させてから、合議に入るルールを徹底する。四半期ごとのキャリブレーション会議で、過去の評価を振り返る。

失敗4: 課題が流出している

症状: 候補者が明らかに準備してきた解答をそのまま書いている。

対策: 課題を3〜5パターン用意してローテーションする。半年に1回は新しい課題を追加する。課題の核心は同じでも、ドメインや要件を変えるだけで十分に流出対策になる。

失敗5: 選考フロー全体の中で位置づけが曖昧

症状: 実技系面接の結果と他の面接の結果をどう総合評価するかが決まっておらず、採用判断に活かされない。

対策: 選考フロー全体の中で「実技系面接で何を判断し、他の面接で何を判断するか」を明確に切り分ける。実技系面接の結果が合否判定にどの程度のウェイトを持つかを事前に決めておく。

FAQ（よくある質問）

Q1. ペアプログラミング面接とライブコーディング面接、どちらから導入すべき？

導入のハードルが低いのはライブコーディング面接です。面接官は観察が中心なので、面接官のスキル要件が比較的低く、トレーニング期間も短くて済みます。まずライブコーディングから始めて、運用が安定したらペアプログラミングの導入を検討するのがおすすめです。

Q2. 候補者にコーディング言語を自由に選ばせるべき？

基本的には候補者が最も得意な言語で受けてもらうのが、正確な能力評価につながります。ただし、採用ポジションが特定の言語を前提とする場合（例: Goで開発するチームにGoエンジニアを採用する場合）は、その言語を指定しても問題ありません。指定する場合は事前にその旨を伝えてください。

Q3. 面接中にGitHub CopilotなどのAIツールの使用を許可すべき？

許可を推奨します。実際の業務でAIツールを使うのであれば、面接でも同様の環境を用意するのが合理的です。AIを使って効率よく課題を進める能力自体が評価ポイントになります。ただし、「AIが生成したコードをそのまま使ったのか、検証・修正したのか」は必ず確認しましょう。

Q4. 候補者がほとんどコードを書けなかった場合、面接をどう終了する？

残り時間を設計の議論に切り替えます。「コードは一旦置いて、この課題をどう設計するか口頭で話しましょう」と提案し、技術的な思考力を別の角度から評価します。面接時間いっぱいまで沈黙が続く状況は、候補者にとっても面接官にとっても苦痛なので、柔軟に対応してください。

Q5. 実技系面接で不合格にした候補者からクレームが来ることはある？

稀にありますが、事前に評価基準を透明にし、面接後に簡単なフィードバックを返すことで大幅に軽減できます。「何で不合格になったか分からない」状態が最もクレームにつながりやすいです。選考プロセスの透明性は、企業の採用ブランドを守る投資と捉えてください。

Q6. 面接の録画は行うべき？

振り返りや面接官のトレーニングに非常に有効です。ただし、必ず候補者の同意を得てください。同意を求める際は「評価の公平性担保と面接官のトレーニングのために録画させてください」と目的を明示します。同意が得られない場合は録画なしで実施します。

Q7. 面接官は何人で実施するのが適切？

1対1（面接官1人、候補者1人）が基本です。ペアプログラミング面接は1対1が原則です。ライブコーディング面接では面接官2人（1人がリード、1人がオブザーバー）とするケースもありますが、候補者の緊張を考慮すると1対1のほうが候補者体験は良くなります。

まとめ：実技系面接は「採用力」そのもの

ペアプログラミング面接とライブコーディング面接は、導入に手間がかかる。課題の設計、ルーブリックの作成、面接官のトレーニング。一朝一夕にはいかない。

しかし、この投資は確実にリターンを生む。

• 採用精度の向上: レジュメだけでは見えない実力を評価でき、ミスマッチが減る

• 候補者体験の向上: 「この会社は技術を大切にしている」というメッセージを面接の体験で伝えられる

• 面接官の成長: 評価力の向上は、チーム内のコードレビューやフィードバック文化の改善にもつながる

まず小さく始めることだ。1つのポジションの選考に1つの課題を用意するところから始めれば、90日後にはチームの「標準的な選考プロセス」として定着できる。

エンジニア採用の選考設計でお困りの方は、techcellarの採用支援サービスもぜひご活用ください。スカウト運用だけでなく、選考プロセス全体の設計支援も行っています。