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

• システムデザイン面接は、候補者の設計思考・トレードオフ判断・コミュニケーション力をまとめて評価できる選考手法

• コーディング試験では見えない「大局的な技術判断力」を可視化できるのが最大の強み

• 評価は要件整理・アーキテクチャ設計・スケーラビリティ・トレードオフ説明・コミュニケーションの5軸で行う

• 出題は自社プロダクトに近い題材を使うと、候補者のドメイン適応力も同時に測れる

• AI時代には「AIインフラ設計」や「推論コスト最適化」といった新しい評価観点が加わりつつある

このページでわかること

この記事では、エンジニア採用におけるシステムデザイン面接の設計・運用・評価について体系的に解説します。

• システムデザイン面接が他の選考手法と何が違うのか

• どのポジション・レベルで導入すべきか

• 具体的な出題パターンと評価ルーブリックの作り方

• 面接官の準備と当日の進行フロー

• AI時代に求められる新しい評価観点

• 少人数スタートアップでの始め方

「ミドル〜シニアエンジニアの設計力をどう見極めればいいのか分からない」「コーディング試験だけでは判断できない」という課題を持つ採用担当者・エンジニアリングマネージャーに向けた実践ガイドです。

システムデザイン面接とは何か｜他の選考手法との違い

定義と位置づけ

システムデザイン面接とは、候補者に「あるシステムを設計してください」という抽象的なお題を出し、要件の整理からアーキテクチャの設計、スケーラビリティの検討までを一貫して議論する面接形式です。

GAFAMをはじめとするテック企業では、ミドル〜シニアレベルのエンジニア採用において標準的な選考プロセスに組み込まれています。日本でもメガベンチャーやスタートアップを中心に導入が進んでいます。

コーディング試験との違い

コーディング試験がアルゴリズムの「正解を導く力」を測るのに対し、システムデザイン面接は「正解のない問題に対して合理的な判断を積み重ねる力」を測ります。

ペアプログラミング面接・構造化面接との使い分け

ペアプログラミング面接は「チームで一緒にコードを書く力」を測る手法です。構造化面接は「過去の行動パターンから将来のパフォーマンスを予測する」手法です。

システムデザイン面接が評価するのは、これらとは異なるレイヤーの能力です。

• 抽象的な要件を具体的な設計に落とし込む力

• 複数の技術選択肢の中からトレードオフを考慮して判断する力

• スケーラビリティ・可用性・コストのバランスを取る力

理想的な選考フローでは、これらを組み合わせて多角的に評価します。たとえば「構造化面接（行動面接）→ コーディング試験 → システムデザイン面接」のように段階を設計すると、候補者の技術力と人物面をバランスよく見極められます。選考フロー全体の設計については「エンジニア採用の選考フロー設計完全ガイド」も参考にしてください。

どのポジション・レベルで導入すべきか

対象ポジションの目安

システムデザイン面接は、すべてのエンジニアポジションに一律で導入する手法ではありません。以下の基準で判断してください。

導入を強く推奨するポジション:

• テックリード / アーキテクト

• シニアバックエンドエンジニア

• SRE / インフラエンジニア（シニア以上）

• CTO / VPoE 候補

• プラットフォームエンジニア

導入を検討すべきポジション:

• ミドルレベルのバックエンドエンジニア（3年以上の経験）

• フルスタックエンジニア（設計判断を求められるロール）

• データエンジニア（データパイプライン設計の評価）

導入しなくてよいポジション:

• ジュニアレベル（経験2年未満）

• フロントエンド専任（UIコンポーネント設計は別の評価手法が適切）

• QAエンジニア（テスト設計は別の形式で評価）

経験年数と出題難易度の対応

出題難易度を候補者のレベルに合わせないと、正確な評価ができません。シニアに簡単すぎる課題を出すと差がつかず、ミドルに難しすぎる課題を出すと全員が沈黙する面接になります。

ポジション別の導入判断フレームワーク

「うちのポジションに導入すべきか？」を判断するための3つの問いがあります。

1. そのポジションは日常的に設計判断を求められるか？ → Yes なら導入推奨

2. 入社後に他チームやステークホルダーとアーキテクチャの議論をする場面があるか？ → Yes なら導入推奨

3. ジュニアメンバーの設計をレビュー・指導する役割があるか？ → Yes なら導入推奨

3つのうち2つ以上が Yes であれば、システムデザイン面接は有効な評価手段です。逆に、すべてが No の場合はコーディング試験やペアプログラミング面接で十分な可能性が高いでしょう。

また、「現在は設計判断を求めないが、半年後にはテックリードを任せたい」というポテンシャル採用の場合も、システムデザイン面接は有効です。ただし、評価基準を「現時点の設計力」ではなく「設計に対する思考の筋の良さ」に調整する必要があります。

評価ルーブリックの設計｜5つの評価軸と採点基準

システムデザイン面接の最大の課題は「評価基準が曖昧になりがち」という点です。面接官ごとに重視するポイントが違えば、採用判断にブレが生じます。

以下の5軸でルーブリックを設計することを推奨します。

1. 要件整理力（Problem Framing）

「どんなシステムを作るか」に飛びつく前に、要件を整理できるかを見ます。

Strong（高評価）:

• 機能要件と非機能要件を自ら切り分けて質問する

• ユーザー規模・トラフィック量の概算を確認する

• スコープを明確にして「今回は〜に絞る」と宣言する

Weak（低評価）:

• 質問なしにいきなり設計を始める

• 前提条件を確認せず、自分の思い込みで進める

• スコープが曖昧なまま全体を網羅しようとする

要件を整理せずにアーキテクチャの議論に入る候補者は、実務でも「要件の抜け漏れ」を起こすリスクが高いとされています。

2. アーキテクチャ設計力（Architecture Design）

システム全体の構成を合理的に設計できるかを評価します。

Strong:

• コンポーネント間の責務分離が明確

• データフロー（読み書きの流れ）を論理的に説明できる

• API設計が一貫しており、エンドポイントの命名・レスポンス設計が適切

Weak:

• コンポーネントの役割が曖昧で、すべてが密結合

• データの流れを聞かれても説明できない

• 「とりあえずマイクロサービスで」と理由なく選択する

3. スケーラビリティ・信頼性（Scalability & Reliability）

「10倍のトラフィックが来たらどうするか」を問いかけたときの対応を評価します。

Strong:

• 水平スケーリング・キャッシュ・CDNの使い分けを説明できる

• 単一障害点（SPOF）を特定し、冗長化の方針を示せる

• CAP定理を意識した判断ができる

Weak:

• 「サーバーを増やす」だけで具体策がない

• 障害シナリオを聞いても答えられない

• データの整合性と可用性のトレードオフを理解していない

4. トレードオフ説明力（Trade-off Analysis）

技術選択には必ずトレードオフがあります。そのトレードオフを言語化できるかが重要です。

Strong:

• 「Aを選ぶとXが得られるが、Yを犠牲にする。今回はXを優先する理由は〜」と明確に説明する

• SQLとNoSQLの選定理由を要件に紐づけて説明できる

• コスト・パフォーマンス・開発速度の観点を複合的に考慮する

Weak:

• 「このDBがベストプラクティスなので」と根拠なく断言する

• トレードオフを聞かれても「特にない」と答える

• 一つの選択肢しか検討しない

5. コミュニケーション力（Communication）

面接中のコミュニケーションの質は、入社後のチーム内での振る舞いを予測する重要な指標です。

Strong:

• 図を描きながら説明し、面接官と認識をすり合わせる

• 「ここは自信がないので確認させてください」と率直に言える

• 面接官のフィードバックを柔軟に取り入れて設計を修正する

Weak:

• 一方的に話し続け、面接官の反応を見ない

• 指摘を受けても自分の案に固執する

• 説明が抽象的で、図やメモを使わない

採点シートの例

各軸を1〜4で採点するシンプルな形式を推奨します。

合計16点以上をシニアレベルの合格ライン、12点以上をミドルレベルの合格ラインとするのが目安です。ただし、いずれかの軸で「1」がつく場合は合計点に関わらず慎重に判断してください。

ルーブリック運用のポイント

ルーブリックは「作って終わり」ではありません。実際に運用する中で以下の改善を継続してください。

• 面接後すぐに採点する：記憶が鮮明なうちに採点する。翌日に採点すると、面接の印象が薄れて「なんとなく良かった/悪かった」という曖昧な評価になりがち

• 採点理由をメモに残す：点数だけでなく「〇〇の質問に対して△△と回答し、□□の観点が欠けていた」のように具体的な根拠を記録する

• 面接官2人の場合は独立採点：まず各自が独立して採点し、その後すり合わせる。先に相手の評価を聞くと、アンカリングバイアスが発生する

• ボーダーラインケースの判断基準を明確にする：合格と不合格の境界にいる候補者の扱いを事前に決めておく（例：「迷ったらもう1回面接」「コミュニケーション軸を重視」など）

出題パターンと進行フロー｜45分の使い方

推奨する時間配分

45〜60分のシステムデザイン面接は、以下の時間配分で進行するのが標準的です。

45分の場合:

• 0〜5分：アイスブレイク・お題の提示

• 5〜15分：要件整理・スコープの確認

• 15〜30分：ハイレベル設計・コンポーネント設計

• 30〜40分：深掘り（スケーラビリティ・障害対策）

• 40〜45分：質疑応答・候補者からの質問

この時間配分を候補者にも最初に共有すると、候補者が時間を意識して進められます。

出題パターンの例

自社プロダクトに近い課題を出す場合と、汎用的な課題を出す場合の2パターンがあります。

汎用的な出題例（ミドル向け）:

• URL短縮サービスを設計してください

• ツイートのタイムライン機能を設計してください

• ファイルアップロード・共有サービスを設計してください

汎用的な出題例（シニア向け）:

• リアルタイム通知システムを設計してください

• 分散タスクキューシステムを設計してください

• レート制限（Rate Limiter）を設計してください

自社プロダクトに寄せた出題例:

• 「当社のサービスの〇〇機能を1から設計するとしたら、どう設計しますか」

• 「当社のデータパイプラインの一部をリアーキテクチャするとしたら」

自社プロダクトに寄せた出題は、候補者のドメイン適応力を測れるメリットがあります。一方で、候補者ごとのドメイン知識の差が結果に影響する点には注意が必要です。過度にドメイン固有の知識を要求しないよう設計しましょう。

出題の具体例：詳細な問い方

お題の出し方によって、面接の質は大きく変わります。良い出し方と悪い出し方を比較します。

悪い例： 「チャットアプリを設計してください」

これだけだとスコープが広すぎて、候補者は何から手をつけていいか迷います。

良い例： 「月間アクティブユーザー100万人が利用するリアルタイムチャットサービスを設計してください。1対1のメッセージ送受信を核とし、メッセージの永続化と既読管理が必要です。まず機能要件と非機能要件を整理するところから始めてください。」

具体的な規模感と中心機能を提示しつつ、要件整理のフェーズを明示的に求めることで、候補者がスムーズにスタートできます。

さらに、深掘り用の追加質問を2〜3個用意しておくと、候補者のレベルに応じて面接の深さを調整できます。

• 「ユーザーがオフラインのときにメッセージを送った場合、どう処理しますか？」

• 「このシステムを5カ国に展開する場合、何を変更する必要がありますか？」

• 「メッセージの検索機能を追加するとしたら、アーキテクチャにどんな変更が必要ですか？」

面接官の介入ポイント

システムデザイン面接は「候補者に1人で話させる」面接ではありません。面接官は適切なタイミングで介入して議論を深める役割を担います。

介入すべきタイミング:

• 候補者がスコープを広げすぎているとき → 「今回は〇〇に絞りましょう」

• 候補者が詰まっているとき → 「〇〇についてはどう考えますか？」とヒントを出す

• 候補者が一つの選択肢に固執しているとき → 「別の方法だと何がありますか？」

• 残り時間が少ないとき → 「スケーラビリティの話に移りましょう」

介入しすぎに注意:

• 自分の「正解」に候補者を誘導しない

• 候補者の発言を否定して萎縮させない

• 技術的なマウンティングをしない

ヒントを出した後に候補者がどう反応するかも評価ポイントです。ヒントを柔軟に取り入れて設計を改善できる候補者は、チームワーク力が高いと判断できます。

AI時代のシステムデザイン面接｜新しい評価観点

2026年現在、AI技術の急速な進展により、システムデザイン面接にも新しい評価観点が加わりつつあります。

AIインフラ設計の知見

LLMベースのサービスが増える中、以下のようなAIインフラ関連の設計判断を問う企業が増えています。

• ベクトルDBの選定と検索パイプラインの設計

• 推論コスト（API呼び出しコスト vs セルフホスティング）の最適化判断

• モデルのレイテンシとユーザー体験のバランス設計

• RAG（Retrieval-Augmented Generation）アーキテクチャの設計

ただし、AI固有の設計知識を全ポジションに求めるのは適切ではありません。「AIプロダクトを開発するチーム」「AIインフラを運用するチーム」の採用に限定して導入するのが現実的です。

AI支援前提の面接設計

候補者がAIツール（ChatGPT、GitHub Copilotなど）を使える前提で面接を設計する企業も出始めています。

この場合、評価基準は「AIが出した設計案をそのまま使うか、批判的に検証して改善できるか」にシフトします。AIが提案するアーキテクチャの弱点を見抜き、改善提案ができる候補者は高く評価されます。

一方、AIツールの利用を許可すると、面接の標準化が難しくなる側面もあります。導入は段階的に、まずは「AIなしのシステムデザイン面接」で基礎力を評価し、オプションとして「AI支援ありの深掘りセッション」を追加するアプローチがバランスが取りやすいでしょう。

LLMアプリケーション設計の出題例

AI時代に特化したシステムデザインの出題例を紹介します。AIプロダクトを開発するチームの採用では、以下のようなお題が有効です。

• 「社内ドキュメントに対する質問応答システム（RAGベース）を設計してください。ドキュメント数は10万件、同時利用者は500人を想定します」

• 「ユーザーの自然言語入力からSQLクエリを生成するText-to-SQLサービスを設計してください」

• 「画像生成AIのAPIを使ったバッチ処理システムを設計してください。1日10万枚の画像を生成し、品質チェックを経て配信する流れです」

これらの出題では、従来の設計力に加えて以下の観点を評価できます。

• ベクトルDBの選定理由（Pinecone / Weaviate / pgvector など）

• Embedding生成のバッチ処理 vs リアルタイム処理の判断

• LLMのAPI呼び出しコストとレイテンシのトレードオフ

• ハルシネーション対策としてのガードレール設計

• モデルのバージョン管理と評価パイプラインの設計

AI時代に重要度が増す評価観点

従来のシステムデザイン面接でも評価していた項目の中で、AI時代に特に重要度が増しているものがあります。

• トレードオフ分析力：AIは「最適解」を一つ提示しがちだが、実務では複数の選択肢を比較検討する力が不可欠

• 曖昧さへの耐性：要件が不明確な状態で前に進める力は、AI化が進んでも人間に求められる

• コスト意識：クラウド・AIサービスのコスト構造を理解した設計判断

出題の作り方と注意点｜公平性を担保する設計

良い出題の条件

システムデザイン面接の出題には、以下の条件を満たすことが求められます。

必須条件:

• オープンエンド：唯一の正解がなく、複数のアプローチが可能

• 段階的に深掘りできる：基本設計 → スケーリング → 障害対策と、深さを調整できる

• ドメイン非依存：特定業界の専門知識がなくても取り組める（自社課題を出す場合は前提情報を提供する）

• 時間内に議論が成立する：45分で要件整理から設計議論まで完了するスコープ

避けるべき出題:

• 特定のフレームワークや言語の知識を前提とする問題

• 候補者の過去の職歴に依存する問題（「前職のシステムを説明してください」は別の面接形式）

• 正解が一つしかない問題（「〇〇のアルゴリズムを設計してください」はコーディング試験の範疇）

• 面接官自身が答えを持っていない問題

出題のバリエーション管理

同じ候補者プール（同じ職種・同じレベル）に対して同じ問題を出し続けると、問題がSNS等で共有されるリスクがあります。

対策として、3〜5問のバリエーションを用意し、ローテーションで出題することを推奨します。各問題の難易度を揃えるため、事前に社内のエンジニアで模擬面接を行い、キャリブレーションしてください。

候補者への事前案内

システムデザイン面接は候補者にとって準備が必要な面接形式です。以下の情報を事前に共有すると、候補者体験が向上します。

• 面接の形式（システムデザインのお題を議論する形式であること）

• 所要時間

• 使用ツール（ホワイトボード、Miro、Excalidrawなど）

• 評価観点の大枠（「設計力・トレードオフの議論・コミュニケーション力を見ます」程度）

• 準備の参考資料（『システム設計の面接試験』等の書籍を案内する企業もある）

事前案内を丁寧にすることは「候補者に有利な情報を与えてしまう」のではなく、「候補者が本来の力を発揮できる環境を整える」行為です。面接は試験ではなく、お互いのフィット確認の場であることを忘れないでください。

候補者への事前案内テンプレート

実際にメールやメッセージで送る案内文の構成例です。

• 面接形式の説明：「システム設計に関するお題をお出しし、45分間で一緒にアーキテクチャを議論する形式です」

• 準備のアドバイス：「特定の技術スタックの知識は問いません。設計判断の理由を言語化する練習をしていただくと、当日スムーズに進められます」

• 使用ツールの案内：「当日はExcalidrawを使用します。以下のURLから事前に操作を試していただけます」

• 評価の大枠：「設計力・トレードオフの議論・コミュニケーション力を総合的に評価します。唯一の正解がある問題ではありませんので、思考プロセスを大切にしてください」

この案内を送るだけで、候補者の緊張が和らぎ、面接中のパフォーマンスが向上します。結果として、候補者の本来の実力を正確に測定できるようになります。

面接官の準備とキャリブレーション

面接官に求められるスキル

システムデザイン面接の面接官は、コーディング試験の面接官よりも高いスキルが求められます。

必須スキル:

• 出題するシステムについて自分なりの設計案を持っている

• 候補者の発言を正確に理解し、適切なフォローアップ質問ができる

• 複数の設計アプローチの妥当性を判断できる

• 候補者のレベルに合わせて深掘りの深さを調整できる

あると望ましいスキル:

• 複数のシステムの設計・運用経験

• 面接官トレーニングの受講経験

• 構造化面接の評価手法の理解

キャリブレーションの進め方

面接官間で評価基準のズレを防ぐために、定期的なキャリブレーションセッションが不可欠です。

キャリブレーションの手順:

1. 模擬面接の実施：社内エンジニアが候補者役を演じ、面接を録画する

2. 個別採点：各面接官が独立して採点する

3. すり合わせ：採点結果を比較し、差異がある箇所を議論する

4. ルーブリックの更新：曖昧だった基準を具体化する

月1回、30分程度のキャリブレーションセッションを続けるだけで、評価精度は大幅に改善します。

面接官の心構え：「試験官」ではなく「対話相手」

システムデザイン面接で最も重要な面接官のマインドセットは、「候補者を試す」のではなく「候補者と一緒に設計を考える」姿勢です。

面接官が腕組みをして黙々とメモを取る面接は、候補者に強いプレッシャーを与えます。結果、本来の力を発揮できず、正確な評価ができなくなります。

理想的な面接官の振る舞いは以下のとおりです。

• 候補者の説明に対して「なるほど、それは〇〇という観点ですね」と要約して確認する

• 「面白いアプローチですね。一方で〇〇の場合はどうなりますか？」とポジティブに深掘る

• 候補者が良い指摘をしたときは「いい質問ですね」「重要なポイントです」と認める

• 自分の意見を押し付けず、「別のアプローチだとどうなりますか？」とオープンに問いかける

この姿勢は候補者体験を向上させるだけでなく、候補者の「チームで働く力」をより正確に評価する手段でもあります。リラックスした環境でこそ、候補者の素の思考プロセスが見えるからです。

シャドーイング制度

新しく面接官になるメンバーには、まずベテラン面接官の面接に同席（シャドーイング）させ、2〜3回の見学後に「副面接官」として参加、その後「主面接官」にステップアップする段階的な育成が効果的です。面接官育成の体系的な進め方については「エンジニア採用の面接官トレーニング」で詳しく解説しています。

リモート面接でのシステムデザイン面接の進め方

リモート・ハイブリッド勤務が一般化した現在、システムデザイン面接もオンラインで実施するケースが増えています。

ツール選定

オンラインでシステムデザイン面接を行う場合、候補者がリアルタイムに図を描けるツールが必要です。

よく使われるツール:

• Excalidraw：シンプルで動作が軽い。候補者にアカウント作成を求めない

• Miro：テンプレートが豊富。チーム利用にも向く

• Google Jamboard の後継（FigJam等）：Googleアカウントがあれば利用可能

• draw.io（diagrams.net）：無料で高機能。ただし操作がやや複雑

候補者が使い慣れていないツールの場合、操作に時間を取られて本来の設計力が発揮できない可能性があります。ツールの案内と簡単なチュートリアルを事前に共有してください。

リモート面接での注意点

• 画面共有のトラブル対策：候補者の環境によっては画面共有がうまくいかないことがあるため、代替手段（チャットでURLを共有、口頭で説明など）を準備する

• ネットワーク遅延への配慮：候補者が考えている時間なのか、回線が途切れているのかを区別する

• 録画の同意：面接の録画は候補者の明示的な同意が必要。同意が得られない場合は録画せずにメモで記録する

リモートならではの工夫

リモート環境では対面に比べて「空気を読む」コミュニケーションが難しくなります。面接官は以下の工夫を意識してください。

• 相槌を意識的に増やす：対面なら自然にできる相槌が、リモートでは途切れがち。候補者が話しているときは頻繁にうなずく

• 沈黙の意味を確認する：候補者が沈黙したら「考えている時間ですか？」と声をかけ、プレッシャーを軽減する

• 画面共有の切り替えを最小限にする：候補者がホワイトボードツールと資料を行き来する必要がないよう、情報は事前に共有する

• アイスブレイクを長めに取る：対面に比べて緊張が解けにくいため、冒頭のアイスブレイクを2〜3分多めに取る

少人数スタートアップでの導入ガイド

「面接官が2人しかいない」「採用が月1〜2件しかない」というスタートアップでも、システムデザイン面接は導入できます。

ステップ1：まず1問だけ作る

最初から5問のバリエーションを用意する必要はありません。自社プロダクトの主要機能をベースにした1問を作り、社内で模擬面接を実施してください。

作り方の例:

• 自社サービスの「検索機能」「通知機能」「課金システム」などから題材を選ぶ

• 実際のアーキテクチャは候補者に見せず、ゼロから設計してもらう

• 模擬面接で45分以内に議論が成立するスコープに調整する

ステップ2：ルーブリックを簡略化する

前述の5軸のルーブリックが理想ですが、最初は3軸に絞っても構いません。

1. 設計力：合理的なアーキテクチャを提案できるか

2. トレードオフ：技術選択の理由を説明できるか

3. 対話力：面接官とスムーズに議論を進められるか

各軸をPass / Fail の2段階で判定するだけでも、「なんとなくの印象」で合否を決めるよりも格段に精度が上がります。

ステップ3：振り返りを蓄積する

面接後に面接官同士（2人だけでも）で5分の振り返りを行い、「この質問は機能した」「この部分は候補者が混乱した」といったフィードバックを蓄積してください。10回の面接を経れば、自社に最適化された評価プロセスが出来上がります。

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

失敗1：面接官が「正解」を持ちすぎている

面接官が自分の設計案を「正解」として持っていると、候補者の別アプローチを正当に評価できなくなります。

対策： 面接前に「この問題には3つ以上の妥当なアプローチがある」ことを確認し、ルーブリックに複数の合格パターンを記載する。

失敗2：候補者に沈黙が続く

候補者が何を話せばいいか分からず沈黙する場合、出題のスコープが広すぎるか、候補者のレベルと出題の難易度が合っていない可能性があります。

対策： 「まず、このシステムのユーザーは誰で、何をしたいと思いますか？」とガイドの質問を用意しておく。

失敗3：技術トリビアの質問大会になる

「CAP定理を説明してください」「Kafkaの内部構造は？」といった知識問題を連発すると、設計力ではなく暗記力を測る面接になります。

対策： 知識の確認は設計の文脈の中で行う。「このシステムでメッセージキューを使う場合、どのような選択肢がありますか？なぜその選択をしますか？」のように設計判断と紐づける。

失敗4：時間配分のミス

要件整理に30分かけてしまい、設計の議論が10分しかできなかったというケースは頻発します。

対策： 面接官がタイムキーパーを務め、各フェーズの時間を明確に管理する。「あと5分で要件整理を終えて設計に入りましょう」と声をかける。

失敗5：候補者体験が悪い

システムデザイン面接は候補者にとって緊張度が高い面接形式です。「何を評価されているか分からない」「面接官が無表情で反応がない」といった体験は、優秀な候補者の辞退につながります。

対策： 冒頭で面接の流れと評価観点を説明する。面接中は相槌やフィードバックを積極的に行い、「一緒に設計を考えている」雰囲気を作る。候補者体験（CX）の改善手法については「エンジニア採用CXを改善して辞退率を下げる実践ガイド」も参照してください。

システムデザイン面接の効果測定

導入したシステムデザイン面接が本当に採用精度の向上に貢献しているかを測定しましょう。

追跡すべき指標

• 入社後パフォーマンスとの相関：システムデザイン面接で高評価だった候補者が入社後も高いパフォーマンスを発揮しているか

• 面接官間の評価一致率：同じ候補者に対する面接官の評価がどの程度一致しているか（Cohen's kappa係数で測定）

• 候補者の面接体験スコア：面接後アンケートで「公平に評価されたと感じたか」「面接の内容は適切だったか」を確認

• 選考辞退率の変化：システムデザイン面接の導入前後で選考辞退率に変化があるか

改善サイクルの回し方

四半期に1回、上記の指標をレビューし、ルーブリック・出題・面接官のフィードバックを更新するサイクルを回してください。

「入社後にパフォーマンスが高い人材が面接で高評価を受けていたか」のデータが蓄積されると、評価基準の妥当性を客観的に判断できるようになります。

FAQ（よくある質問）

Q. システムデザイン面接はミドルレベルの候補者にも実施すべきですか？

A. 経験3年以上であれば実施する価値はあります。ただし、出題の難易度をミドル向けに調整し、「基本的なシステム構成を説明できるか」「技術選択の理由を言語化できるか」にフォーカスした評価基準にしてください。ジュニアレベルに対してはコーディング試験やペアプログラミング面接の方が適切です。

Q. 面接時間は何分が最適ですか？

A. 45〜60分が標準です。45分あれば要件整理・設計・深掘りを一通り行えます。60分あるとスケーラビリティや障害対策まで踏み込んだ議論ができます。30分以下では表面的な議論にとどまり、正確な評価が難しくなります。

Q. ホワイトボードを使えないリモート面接ではどうすればいいですか？

A. ExcalidrawやMiroなどのオンラインホワイトボードツールで代替できます。候補者が使い慣れていないツールの場合は操作に5分ほど時間を取り、練習してもらうのが親切です。ツールの操作スキルは評価対象に含めないでください。

Q. 出題は毎回変えるべきですか？

A. 同じ職種の候補者群に対しては、3〜5問のローテーションが理想です。同じ問題を使い続けるとSNS等で共有されるリスクがあります。一方、問題を変えすぎると難易度のばらつきが生じるため、各問題の難易度を事前にキャリブレーションしておくことが重要です。

Q. 面接官は何人必要ですか？

A. 最低2人を推奨します。1人が主面接官としてお題を進行し、もう1人がメモ・評価を担当します。面接官が1人だけだと、進行しながら評価もする負荷が高く、見落としが発生しやすくなります。

Q. 候補者がAIツールを使って回答してきた場合、どう対処しますか？

A. システムデザイン面接はリアルタイムの対話形式であるため、コーディング試験ほどAIツールの影響は受けにくい面接形式です。候補者がAIの出力をそのまま読み上げている場合は、深掘り質問で「なぜその設計を選んだのか」「別のアプローチだと何が変わるか」を問いかけることで、理解の深さを確認できます。

Q. 不合格の候補者にフィードバックは提供すべきですか？

A. 可能であれば提供することを推奨します。「設計力は十分でしたが、トレードオフの説明がもう少し具体的だとよかったです」のような建設的なフィードバックは、候補者の成長を支援し、企業ブランドの向上にもつながります。法的リスクを避けるため、合否理由の詳細開示は避け、改善ポイントに絞ったフィードバックにしてください。

Q. 非エンジニアの人事担当者でもシステムデザイン面接の設計に関われますか？

A. 面接の「設計」と「実施」は分けて考えてください。出題内容や評価基準の策定はエンジニアが担うべきですが、プロセス全体の設計（時間配分、候補者への事前案内、面接後のフィードバック収集）は人事担当者がリードできます。また、面接後のデブリーフィング（振り返り）の進行役を人事が担うことで、エンジニア面接官の評価バイアスをチェックする仕組みを作れます。

Q. システムデザイン面接と技術的なポートフォリオレビューはどちらが有効ですか？

A. 両者は補完関係にあります。ポートフォリオレビューは候補者の「過去の成果物」を評価するのに対し、システムデザイン面接は「未知の問題に対するリアルタイムの思考力」を評価します。可能であれば書類選考でポートフォリオを確認し、面接ではシステムデザインで設計力を測る組み合わせが理想的です。

まとめ・次のアクション

システムデザイン面接は、ミドル〜シニアエンジニアの「設計思考力」「トレードオフ判断力」「コミュニケーション力」を総合的に評価できる、非常に有効な選考手法です。

コーディング試験だけでは見えない「大局的な技術判断力」を可視化できるため、テックリードやアーキテクトの採用には特に効果的です。

今日から始める3つのアクション:

1. まず1問作る ── 自社プロダクトの主要機能をベースにしたお題を作り、社内で模擬面接を実施する

2. ルーブリックを決める ── 5軸（または3軸）の評価基準を文書化し、面接官全員で共有する

3. 候補者への事前案内を整備する ── 面接形式・評価観点・使用ツールを候補者に事前に伝える準備をする

システムデザイン面接の設計や選考プロセス全体の改善にお悩みなら、techcellarのエンジニア採用支援サービスにご相談ください。スカウト運用から選考設計まで、エンジニア×AIの視点でサポートします。