技術面接（二次面接）。コーディング・システム設計・行動面接で、対等に確かめ合う　【フェーズ4-5｜ITエンジニアの卵に贈る、就活の書】

2026年8月20日 08:15

【お知らせ】本連載は、2026年9月20日に全記事を全面アップデートしました。

　この記事は本気でITエンジニアになりたい！ という学生さんたちに向けて就活プロセスを伝える「ITエンジニアの卵に贈る、就活の書」シリーズの一本です。シリーズ全体の目次はこちら（扉記事）からご覧いただけます。

　エンジニアを目指す学生のみなさん、こんにちは。クオリティアーツの池田です。

　ITエンジニアの卵に贈る、就活の書・フェーズ4-5の記事です。前回のフェーズ4-4では、一次面接（人事・若手エンジニア）のお話をしました。書類の言葉を自分の言葉に変え、フェーズ2〜フェーズ3で積み上げてきたものを対話の素材として持ち込む実践でした。

　今回はフェーズ4の各論の3本目、技術面接の実践に入ります。二次面接として、テックリード・リーダー層との技術対話が始まる局面です。コーディング面接、システム設計面接、行動面接。技術面接は、これまで積み上げてきたものが最も直接に問われる場です。

　ただし、先に3つ、はっきりさせておきます。

　1つ目。技術面接が、すべての会社にあるわけではありません。新卒採用で技術面接やコーディング面接を実施している企業の割合を示す統計は、調べた範囲では見つかりませんでした。ですから、この記事は「多くの会社で標準的に行われている」とは書きません。あるかどうかは、その会社に聞いて確かめます。聞き方は3章に置きました。

　2つ目。専門用語が大量に出てきます。ですので、この記事は1章を丸ごと用語の説明にあてました。分からなくなったら、1章に戻ってください。

　3つ目。情報系の学部ではない方、まだ何も作っていない方のための章を、4章に置きました。先にそちらを読んでいただいても構いません。

　そのうえで、大切なことをお伝えします。技術面接は、知識の量を測る場ではありません。知識は前提として要りますが、測られているのはその知識をどう使って考えるかのほうです。序章-1のプロフェッション、序章-2の世界基準、序章-3の生き方としてのエンジニア、そしてScientist・Engineer・Ethicsの三本柱。これらは、技術面接での対話の中に、そのまま出てきます。

この記事のポイント

技術面接があるかどうかは会社によります。実施率の統計は確認できませんでした。選考でコードを書く場面があるかを、聞いて確かめてください。
測られているのは知識の量ではなく、知識をどう使って考えるかです。問題の理解を確かめ、思考を声に出し、詰まったら相談する。この3つが土台です。
新卒でエンジニアになった人の4人に1人は文系大学卒です（レバテック、2023年11月、n=2,342）。情報系でない方への章を、4章に置きました。

1. この記事で使う言葉

　この記事には、業界の言葉がたくさん出てきます。知らない言葉でつまずかないように、先にまとめて置いておきます。分からなくなったら、ここに戻ってきてください。

　役職と役割

テックリード：チームの技術的な判断を引き受ける役割の人です。何をどう作るかを決め、若手のコードをレビューします。管理職ではないことが多く、会社によって「主任」「リード」など呼び名が変わります。
リーダー層：テックリードと同じか、少し上の層です。技術に加えて、チームの動き方まで見ます。

　選考の言葉

局面：この連載では、選考で確かめられる中身の種類を「局面」と呼んでいます。フェーズ4の総論で8つの局面を挙げていますが、面接が8回あるという意味ではありません。実際の平均選考回数は2.1回です（マイナビ2026年卒企業新卒内定状況調査、n=1,366）。会社によって、8つの局面は1回や2回の面接に圧縮されます。
縦串：この連載を通して繰り返し出てくる考え方のことです。この記事では「技術との向き合い方」と読み替えてもらって構いません。
Scientist・Engineer・Ethicsの三本柱：この連載が使っている、エンジニアの姿勢の3分類です。Scientist＝筋道を立てて考える、Engineer＝動くものを作りきる、Ethics＝人に迷惑をかけない判断をする。この3つだと思ってください。

　開発の現場で使う略語

PR（Pull Request）：GitHubで「このコードを本体に取り込んでください」と出す申請のことです。他の人がそれを読んで指摘するのがコードレビューです。
E2Eテスト：End to End テスト。画面の操作から結果まで、利用者と同じ道筋で一通り動かして確かめるテストです。
CI/CD：コードを更新するたびに、自動でテストを流し、問題なければ自動で公開まで進める仕組みのことです。
ポストモーテム：障害が起きたあとの振り返り記録のことです。誰が悪かったかではなく、何が起きてどう防ぐかを書きます。
DAU：1日にサービスを使った人の数。SLA：「これだけは止めません」と約束する稼働率（99.9%なら、1年で約8時間45分までの停止）。O(N^2)：入力が2倍になると処理時間が4倍になる、という処理量の増え方の表し方です。「オーダーエヌ二乗」と読みます。

　全部を覚える必要はありません。この記事を読むあいだだけ、ここを開いておいてください。

2. 前提1：技術面接は、知識テストではなく、対等な技術対話

　まず、技術面接の位置づけを確かめます。多くの学生さんが持ちがちな誤解があります。「技術面接は、知識テストだ」という誤解です。

　ここは、正確に切り分けます。知識が要らない、という意味ではありません。アルゴリズムもデータ構造も設計のパターンも、知っていたほうが当然できることが増えます。この記事の後半でも、テスト設計技法や設計の道具立てを、名前を挙げて扱います。

　違うのは、測り方です。知識の暗記量を点数にする場ではなく、持っている知識を、目の前の問題にどう当てて考えるかを見る場です。ですから、知らないことが出てきたときに何をするかまでが、そのまま見られています。知らないと言えることも、測られているうちの1つです。

　序章-1で立てたプロフェッションの視座、序章-2の世界基準の視座、序章-3の生き方としてのエンジニアの姿勢、そして序章の全体を貫くScientist・Engineer・Ethicsの三本柱（科学的な思考／工学的な実装／倫理的な判断）。これらは、技術面接での問題への取り組み方、答えの導き方、対話の質に、自然と滲み出ます。

　面接官は、あなたが問題を解けるかを観ているのではありません。あなたがどう考え、どう対話し、どう学び続けようとしているかを観ています。企業側から見れば、技術面接は、実務でこの人に技術判断を任せられるか、チームで一緒にコードと向き合えるかを確かめる場でもあります。同じ論理で、あなたも、面接官の質問の粒度、コードレビューの視点、システム設計への向き合い方から、その会社の技術文化の厚みを確かめられます。技術面接は、双方向の技術対話の場です。

3. 技術面接は、実際にどう進むのか

　技術面接を受けたことがない方にとって、いちばん怖いのは「何が起きるか分からない」ことだと思います。ここで、進み方そのものをお話しします。

3-1. まず、正直にお伝えしておくこと

　新卒採用で技術面接やコーディング面接を実施している企業の割合を示す統計は、調べた範囲では見つかりませんでした。採用支援会社の解説記事はいくつもありますが、母集団を持った数字は確認できませんでした。ですので、この記事は、「多くの会社で標準的に行われている」という書き方をしません。

　つまり、みなさんが受ける会社で技術面接があるかどうかは、その会社に聞くしかありません。これは調べれば分かることなので、次の一手が決まります。

説明会やカジュアル面談で、「選考では、実際にコードを書く場面はありますか」と聞く
面接の案内が来たら、「当日は、どのような形式で、何分程度を想定されていますか」と返信で聞く

　この2つは、応募前でも応募後でも使えます。聞いて嫌がられる質問ではありません。むしろ、これに答えられない会社のほうが、選考の設計を持っていないということです。

3-2. 当日の進み方

　形式は会社によって違いますが、コーディング面接の進み方は、おおよそ次の順です。

顔合わせと、簡単な自己紹介
問題が提示される（画面共有、共有エディタ、専用サービスなど）
こちらが問題を理解できているかを、面接官と確かめる時間
実装する。声に出しながら進めることを求められることが多い
動かして確かめる
逆質問

　所要時間は会社によって違い、横断的な統計は確認できませんでした。案内メールに書かれていることがほとんどなので、そこで確かめてください。書かれていなければ、聞いてください。

3-3. よくある不安に、先に答えます

　言語は選べますか。多くの場合、選べます。案内の時点で「使用言語は自由です」「◯◯でお願いします」と書かれます。書かれていなければ聞いてください。CとPythonしか書けないなら、Pythonで受けて構いません。Pythonは実務でも広く使われている言語です。

　手が止まったら、どうなりますか。止まります。全員止まります。大事なのは、止まったまま黙らないことです。「いま、◯◯のところで詰まっています。△△という方法を考えていますが、どう思われますか」と声に出してください。8-5でもう一度扱います。

　完成しなかったら不合格ですか。会社によります。ただ、完成だけを見る会社なら、そもそも面接官が同席する必要はありません。同席しているということは、途中の考え方を見たいということです。

　調べてもいいですか。これも聞いてください。「検索してもよろしいでしょうか」と最初に確認するのは、減点ではありません。実務では調べながら書きます。

　ここまでを踏まえて、当日いちばん効くのは、3の「問題の理解を確かめる時間」を飛ばさないことです。ここを飛ばして書き始めると、違うものを作って時間を失います。

4. 情報系ではない方、作ったものがない方へ

　ここまで読んで、「自分は対象外だ」と感じた方がいるはずです。情報系の学部ではない。Webアプリを作ったことがない。GitHubにリポジトリがない。その方に向けて、この節を書きます。

4-1. 新卒でエンジニアになった人の、出身は幅があります

　数字を1つ置きます。レバテックが2023年11月にエンジニア経験者2,342人に行った調査では、新卒でエンジニアとして入社した人のうち、文系大学卒が24.7%でした（理系大学卒は28.6%）。4人に1人は、文系学部の出身です。

　この調査からは「情報系かどうか」の内訳までは取り出せません。ただ、情報系の学部を出ていることが、エンジニアになる条件ではないことは、この数字からはっきり言えます。機械、電気、化学、物理、生物、そして文系。そこから入った人が、現に大勢います。

4-2. ただし、差がないという話ではありません

　ここは正直に書きます。作ってきた量の差は、実在します。この節は、その差をなかったことにするためのものではありません。差があるという前提のうえで、いまいる場所から何ができるかをお話しします。

　「今から間に合いますか」への答えも、はっきり書きます。間に合う人と、間に合わない人がいます。分けるのは、残り時間ではなく、ここから毎週なにかを作って残すかどうかです。

4-3. 卒業研究のスクリプトは、素材になります

　いちばんお伝えしたいのはここです。研究で書いた解析スクリプトは、技術面接の素材として使えます。

　たとえば、流体解析や測定データの処理でPythonを書いてきた方なら、次のことを語れるはずです。

入力の境界で落ちた経験：データが空だった、1行しかなかった、桁が想定外だった。8-4で扱う境界値分析は、まさにこれです。名前を知らずに実践していたなら、名前を付けるだけで語れます。
速度が問題になった経験：ループが遅くて、書き方を変えた。配列の持ち方を変えた。これは処理量の話であり、コーディング面接で問われる話と地続きです。
数字が合わなかった経験：結果がおかしくて、原因を切り分けた。どこまでは正しいと確かめて、どこから疑ったか。これは、そのまま技術面接で問われる考え方です。

　足りないのは、経験ではなく、経験に名前を付けて語れる形にする作業であることが、かなりあります。

4-4. それでも足りないものと、その埋め方

　そのうえで、研究のスクリプトだけでは埋まらないものがあります。他人が読む前提で書いた経験と、人に見える場所に置いた経験です。

　埋め方は、順番で書きます。上から順に、1つずつでかまいません。

いま手元にあるスクリプトを、GitHubに1つ公開する。READMEに「何を計算するものか」「どう動かすか」「なぜこの作りにしたか」を書く。これだけで、見える場所に置いた経験になります。
そのスクリプトに、テストを1つ書く。データが空のときに落ちないことを確かめるだけで構いません。
詰まって直した経験を、1本の記事にする。公開の場所はどこでも構いません。
小さくていいので、授業でも研究でもないものを1つ作る。研究とは別の文脈で作ったものがあると、語れる幅が変わります。

　1から4は、この順にやってください。1を飛ばして4から始めると、見える場所に何も残りません。

　なお、ここで挙げた4つは、フェーズ2の各論でそれぞれ1本ずつ扱っています。時間があるなら、そちらを読んでください。この節は、時間がない方のための最短経路です。

5. 前提2：技術面接の対話相手は、テックリード・リーダー層

　技術面接の面接官は、多くの企業で次のいずれかです。

テックリード：実装力・思考プロセス・技術判断の対話
リーダー層：技術に加えて、チームでの立ち位置・学び続ける姿勢
シニアエンジニア：現場のリアルな技術対話

　いずれも、フェーズ4-2でいうテックリード・リーダー層です。会社によって主任、リードなど呼び名が違いますが、同じ層です。なお、マネージャという名前は、課長相当の役職名として使われることのほうが多い言葉です。二次面接の相手の呼び名としては使いません。

　面接の案内で名前と所属が分かったら、その方の発信を面接の前に確認します。登壇スライド、note、Xなど。その方が何を考えて技術を選んできたかを踏まえて、話を始められます。フェーズ3-3で扱った技術発信の読み込みが、ここで直接活きます。

　ただし、技術発信が見つからない会社のほうが多いことも、はっきりお伝えしておきます。社員が数十名から百数十名の会社で、技術ブログを持ち、登壇し、個人が名前を出して発信している。これは少数派です。発信がないことを、そのまま「良くない会社」と読まないでください。発信のない会社を別の手で測る方法は、フェーズ3-3に1章分置いてあります。発信がなければ、そこで確かめてから面接に臨んでください。

　なお、この記事で扱うことは、フェーズ2で積み上げてきたものと、序章から育ててきた技術との向き合い方が素材になります。技術面接は、そこまでに手を動かしてきた人ほど準備が効く場です。手を動かしてこなかった方は、4章を先に読んでください。

6. 技術面接の3つの局面

　技術面接で扱われる内容は、企業によって差がありますが、次の3つが標準的な局面です。

6-1. 局面1：コーディング面接

ホワイトボード、共有エディタ、専用プラットフォーム（HackerRank、Codility、LeetCode形式）などで、その場で実装する
アルゴリズムとデータ構造の理解、実装力、テストの書き方が問われる
面接官が観ているのは、コードの正しさだけでなく、思考プロセスの言語化

6-2. 局面2：システム設計面接

「◯◯というサービスを設計するとしたら、どう作りますか」というテーマで、大枠から詳細まで設計を対話する
スケーラビリティ、可用性、データ設計、API設計、セキュリティ、監視の視点が問われる
面接官が観ているのは、正解を出すことではなく、トレードオフを言語化する力

6-3. 局面3：行動面接（Behavioral Interview）

過去の経験について、具体的な状況・行動・結果を語る
STAR法（Situation・Task・Action・Result）で答える形が多い
フェーズ4-4のガクチカ（4層構造）と重なるが、技術文脈での掘り下げが中心
面接官が観ているのは、あなたが技術の場でどう考え、どう動くか

　3つの局面すべてで、Scientist・Engineer・Ethicsの三本柱が問われます。この視座で準備することが、技術面接の質を上げる根本です。

7. Scientist・Engineer・Ethicsの三本柱を、技術面接でどう立てるか

　序章から降ろしてきたScientist・Engineer・Ethicsの三本柱を、技術面接の対話でどう立てるかを整理します。

7-1. Scientist（科学的な思考）：技術面接での立ち現れ方

問題を、まず分解する。何が入力で、何が出力で、どんな制約があるか
仮説を立てて、検証する。この設計で正しく動くか、どこで失敗しうるかを言葉にする
なぜそう考えたかを、根拠と共に語る（勘や経験則だけで進めない）
不明な点は、面接官に対等に質問する（分からないことを認め、対話で解消する）

　技術面接でScientistの姿勢が立つ例：

　「この問題は、入力がN個の整数の配列、出力が特定の条件を満たす部分列と理解しました。制約として、Nの大きさが◯◯までなら、O(N^2)のアプローチが許容されそうです。まず、素朴なO(N^2)の解を書いて、動作を確認してから、O(N log N)の改善案を考えたいと思います。この方針でよろしいでしょうか」

7-2. Engineer（工学的な実装）：技術面接での立ち現れ方

動くコードを、段階的に完成させる（一度に完璧を目指さない）
エラーケース、境界値、テストの視点を最初から持つ
可読性・保守性・拡張性を意識した実装（他の人が読んで理解できる形）
世界基準の道具立て（言語標準ライブラリ、業界標準のアルゴリズム）を自然に使う

　技術面接でEngineerの姿勢が立つ例：

　「まず、素朴な実装で動くコードを書きます。その後、境界値（空の配列、要素が1つの配列、要素が全て同じ配列）をテストで確かめます。パフォーマンスの改善案は、動くコードを確保してから議論させてください」

7-3. Ethics（倫理的な判断）：技術面接での立ち現れ方

公衆の福利に関わる判断（データ設計でのプライバシー、セキュリティ、可用性の判断）
失敗を隠さない姿勢（自分の実装のバグを、面接官に対等に共有する）
他者の実装を、批判ではなく学びとして扱う（例：既存の実装を参照する場合、その意図を汲む）
技術の限界を、正直に認める（自分が知らないことを、知らないと言える）

　技術面接でEthicsの姿勢が立つ例：

　「この設計だと、ユーザーの個人情報が◯◯というテーブルに集中します。運用フェーズでのプライバシー保護の観点から、暗号化とアクセス制御を検討する必要があると考えます。この判断について、御社の設計方針を伺ってもよいでしょうか」

　Scientist・Engineer・Ethicsの三本柱を、コードと対話に滲ませる。これが、技術面接で最も強く問われる姿勢です。

8. コーディング面接での、5つの姿勢

　コーディング面接に臨むときの、5つの姿勢を整理します。

8-1. 姿勢1：問題文を丁寧に読み、面接官に確認する

　問題を読んだら、まず問題の理解を面接官と共有します。「この問題は、こう理解しました。制約はこうで、想定される入力サイズはこの範囲、と考えました。合っていますか」。この最初の確認が、対等な対話の入口です。

8-2. 姿勢2：思考プロセスを声に出す

　コーディング面接では、黙って考え込むより、思考を声に出す方が対話が深まります。「まず、素朴な解を考えます。二重ループで、O(N^2)。この解で、時間計算量が制約に合うかを確認します」。面接官は、コードだけでなく、思考の道筋を評価しています。

8-3. 姿勢3：段階的に実装する

　完璧なコードを一度に書こうとしない。素朴な解を書いて、動作を確かめ、その後で改善する。この段階的な進め方が、Engineerの姿勢そのものです。

8-4. 姿勢4：テストの視点を持つ

　実装が終わったら、テストケースを声に出して確認します。「境界値として、空の入力、要素が1つの入力、全て同じ値の入力を試します。想定通り動きます」。

　この境界値の考え方には、境界値分析という名前がついています。入力の範囲の端（最小値、最大値、その1つ内側・外側）に不具合が集中しやすいという経験則に基づく、ソフトウェアテストの基本技法です。似た技法に同値分割があります。入力を「同じ結果になるはずの集合」に分けて、各集合から代表値を1つずつ選んでテストする考え方です。技法の名前を知らなくても実践している学生さんは多いですが、名前を添えて語れると、自分がどういう筋道でテストケースを選んだのかを、自分でも面接官でも追える形になります。テストの視点は、実務でのコードレビューの視点そのものです。

　もう一歩踏み込んだ話をします。テスト設計技法は、境界値分析・同値分割だけではありません。状態遷移テスト（状態の遷移を1本ずつテストする）。デシジョンテーブルテスト（条件と結果の組み合わせを表にする）。ペアワイズテスト（パラメーターの組み合わせ爆発を抑える）。コーディング面接で「与えられた要件に対して、いくつテストケースを設計しますか」と問われたとします。たとえば、こう答えられるとします。「素朴に思いつくのは10ケースですが、境界値分析で入力の端を洗い、同値分割で入力集合の代表を選ぶと、実質18ケース程度に整理できると考えます」。面接官には、「バグを1つ思いつく」学生と、「テストケースを網羅する」学生の差が伝わります。バグの1件をランダムに思いつく姿勢と、テストケースを技法で網羅する姿勢とでは、実務での品質への向き合い方が大きく違います。

　良い会社の技術面接では、実装コードの正しさだけでなく、候補者がどんなテストケースを思いつくか、どんなエラーケースを先出しできるかまで問われます。逆に、実装コードの動作確認だけで面接が終わり、テストの話題が全く出てこない技術面接は、その会社のテスト文化の薄さを示すシグナルにもなり得ます。学生としても面接官としても、この観点は双方向に働きます。

8-5. 姿勢5：詰まったときは、対等に相談する

　コーディング面接で詰まることは、当たり前にあります。詰まったときに、面接官に対等に相談できるかが、面接での姿勢の分岐点です。「ここで詰まっています。◯◯というアプローチを考えていますが、他に方向性があれば、ヒントをいただいてもよいでしょうか」。この対等な相談は、実務でのペアプログラミングの姿勢そのものです。

9. システム設計面接での、5つの姿勢

　システム設計面接では、次の5つの姿勢を整えます。

9-1. 姿勢1：要件を、面接官と対等に確認する

　「◯◯というサービスを設計してください」と言われたら、まず要件を面接官と対等に確認します。「想定するユーザー規模は、DAU10万人と考えてよいでしょうか。読み込みと書き込みの比率は、9:1程度と想定しますか。可用性の要求は、SLA 99.9%と考えますか」。この最初の要件確認が、システム設計の土台です。

9-2. 姿勢2：大枠から詳細へ、段階的に設計する

　いきなり詳細に踏み込まない。まず、大枠（クライアント・サーバー・データベース・キャッシュ・キューなどの主要コンポーネント）を描き、その後で各コンポーネントの詳細に踏み込みます。この段階的な設計は、実務でのアーキテクチャ設計のプロセスそのものです。

9-3. 姿勢3：トレードオフを、明示的に議論する

　システム設計に、唯一の正解はありません。トレードオフの議論が、設計面接の核心です。「一貫性を強く保つならRDBMSを選びますが、書き込みスループットを優先するならNoSQLも選択肢です。今回の要件では、一貫性を優先すべきと考えます」。トレードオフを言語化する力が、Scientistの姿勢そのものです。

9-4. 姿勢4：世界基準の道具立てを、自然に使う

　設計の対話では、道具の名前が出てきます。最初は、種類だけ分かっていれば足ります。

クラウド：サーバーを自前で持たずに借りる（AWS、Google Cloud、Azure）
コンテナ：動く環境ごと包んで、どこでも同じに動かす（Docker、Kubernetes）
監視：動いているものの状態を、外から見えるようにする（Datadog、Grafana、Prometheus）
CI/CD：更新のたびに自動でテストして公開する（GitHub Actions、CircleCI）

　この4種類が分かっていれば、設計の対話にはついていけます。細かい製品名は、必要になったときに覚えれば間に合います。

　大事なのは名前の数ではありません。名前を挙げるだけなら誰でもできます。「なぜそれを選ぶのか」を1つでも自分の言葉で言えることのほうが、はるかに効きます。使ったことのない道具の名前は、無理に出さないでください。「使ったことはありませんが、◯◯のために要るものだと理解しています」で構いません。

9-5. 姿勢5：セキュリティ・プライバシー・可用性・テスト容易性を、後付けにしない

　設計の初期から、セキュリティ・プライバシー・可用性の視点を持ちます。「認証はどうするか、個人情報の暗号化はどう扱うか、障害時のフェイルオーバーはどう設計するか」。これらを最後に付け加えるのではなく、大枠の設計と同時に議論する姿勢が、Ethicsの姿勢そのものです。

　もう1つ、意識しておきたい観点がテスト容易性 (Testability) です。「このコンポーネントは、外部サービスをモックに差し替えてテストできる設計か」「機能ごとに切り分けてテストできる構成か」。テスト容易性は、可用性やセキュリティと並ぶ非機能要件の1つであり、あとから設計に組み込もうとすると難しくなる性質を持ちます。設計の対話の中で「この部分は単体でテストしやすいように分離しておきたいです」と一言添えると、その会社が後工程まで含めて設計を考えているかどうかを、返ってくる応答から確かめられます。

　テスト容易性を語るために、1つだけ言葉を覚えてください。依存性注入（DI、Dependency Injection）です。データベースや外部サービス、ファイル、時計といった外から借りてくるものを、プログラムの中で直接呼ばずに、引数として受け取れる形にしておく設計のことです。こうしておくと、テストのときだけ本物ではなく偽物を渡せるので、単体でテストが書けます。

　偽物にはモック、スタブ、フェイクなどの呼び分けがありますが、面接で使い分けを問われることは、新卒ではまずありません。「本物の代わりを渡してテストする」という考え方だけ持っていれば足ります。

　良い会社のシステム設計面接では、面接官がテスト容易性の観点を積極的に問います。「この設計で、単体テストはどう書きますか」「本番の外部APIに依存せずに、統合テストを回す方法は」「デプロイ後、この機能が正しく動いていることを、どんな指標でモニターしますか」。逆に、こうしたテスト容易性・可観測性の話題が全く出ないシステム設計面接は、その会社が「動けば良い」文化に留まっていることの、静かなシグナルにもなり得ます。設計面接での対話の中身から、その会社の非機能要件への向き合い方が透けて見えます。

10. 行動面接での、3つの姿勢

　行動面接（Behavioral Interview）は、過去の経験について具体的に語る場です。フェーズ4-4のガクチカの4層構造（状況・課題・行動・結果と学び）が土台になりますが、技術面接での行動面接には、次の3つの姿勢を加えます。

10-1. 姿勢1：技術的な判断のプロセスを、具体的に語る

「そのプロジェクトで、なぜその技術を選定したか」
「実装で困難だった場面と、どう乗り越えたか」
「チームでのコードレビューで、どのようなフィードバックを受け、どう改善したか」

　技術判断のプロセスを、根拠と共に語る。フェーズ2-8で扱った技術ブログの記事を書く姿勢と、根本は同じです。

10-2. 姿勢2：失敗した経験を、正直に語る

　行動面接では、失敗した経験を隠さない姿勢が問われます。フェーズ2-4で扱った「読む・作る・書き残す」の3拍子で身につけたことのうち、失敗を通して学んだことを語れると、自分がその経験から何を持ち帰ったのかが、自分のなかでも輪郭を持ちます。

「実装したものが動かず、原因を探るのに1週間かかった話」
「レビューで指摘されて、自分の設計判断の甘さに気づいた話」
「本番環境で発生させたバグと、その後の再発防止策」

　失敗を仕組みで受け止める姿勢は、良い会社の技術文化と一致します（フェーズ1-1、フェーズ3-3）。行動面接で失敗を正直に語ることは、Ethicsの姿勢の実践でもあります。

10-3. 姿勢3：学びを、次の挑戦につなげる姿勢を語る

　過去の経験を語るだけでなく、そこから得た学びを、これからどう活かすかを語ります。

「あの失敗から、レビューで指摘されないための事前チェックリストを、自分の中で持つようになりました」
「あのプロジェクトで学んだシステム設計の視点は、その後の個人開発でも活きています」
「あの技術書を読んで身につけた思考法を、今も日々の実装で使っています」

　学びが次の挑戦につながる姿勢は、生き方としてのエンジニアの姿勢そのものです。

11. 技術面接での逆質問。技術文化を確かめる問い

　技術面接の後半でも、逆質問の時間が用意されます。技術面接での逆質問は、現場の技術文化を確かめる問いに絞ります。

　先に、大事な注意を1つ。意味が分かっていない言葉で質問しないでください。「E2Eテストのカバー範囲は」と聞いて、面接官から「E2Eというと、どのあたりを想定されていますか」と返されたら、そこで止まります。返ってきた答えを受け止められる質問だけを使ってください。

　この章の問いには、答えの何を聞き取るかを添えました。聞き取り方が分からない問いは、使わないという判断で構いません。下に行くほど前提知識が要ります。上から3つだけ選んで持っていくのが、実際には一番うまくいきます。

11-1. 技術判断のプロセスに関する問い

「直近1年で、御社が技術選定で最も悩んだ判断は、どのようなものでしたか」
「技術負債の返済に、どのように取り組まれていますか」
「新しい技術の導入は、どのようなプロセスで決まりますか」

11-2. コードレビュー・品質管理に関する問い

　前提知識がなくても使える問い（数字が返るので、そのまま受け止められます）

「直近1か月のデプロイ回数と、Pull Requestがマージされるまでの平均日数を教えてください」
- 聞き取り方：「整備状況はどうですか」と聞くと「進めているところです」で永遠に答えられます。数字で聞けば、答えは1つです。数字が出てこない場合は、社内でも測っていないということです。
「若手が出したコードを、誰が読む決まりになっていますか。決まっていない場合もありますか」
- 聞き取り方：誰が読むかが決まっているなら、レビューが仕組みとして回っています。「気づいた人が見ます」なら、人によって当たり外れがあります。
「障害が起きたあと、振り返りを記録に残す決まりはありますか」
- 聞き取り方：記録に残す会社は、同じ障害を人の記憶に頼らずに防ごうとしています。「その都度、口頭で共有しています」なら、次の人には伝わりません。

　用語を分かっている方向けの問い

「テストコードとCI通過は、マージの必須条件になっていますか」
「品質保証やQAの専任担当はいますか。開発とQAの役割分担を教えてください」
「テスト設計技法について、社内で勉強会や研修は行われていますか」

11-3. 学び続ける文化に関する問い

「業務時間で、技術ブログを書いたり勉強会に登壇したりできる仕組みは、実際にありますか」
「新卒エンジニアが、社外のカンファレンスに派遣される機会は、どのくらいありますか」
「エンジニアの中で、OSSへの貢献が業務評価に組み込まれる仕組みはありますか」

11-4. 現場の日常に関する問い

「面接官の◯◯さんが、直近1年で最も伸びたと感じる技術領域は、何ですか」
「新卒エンジニアが、1年目にどこで最も詰まる場面が多いですか」
「チームで、失敗事例をどのように共有・活用されていますか」

11-5. 技術文化の日常を確かめる問い

「入社後5年間で、業務で扱う技術スタックがどう変わる見込みですか」（技術スタックの更新計画）
「開発するシステムのアクセシビリティ対応プロセス（WCAG準拠、スクリーンリーダー対応、多言語対応など）を教えてください」（序章-1で扱った公衆福祉への責任の実践）
「業務指示や情報共有で使っているツールと、口頭指示との使い分けを教えてください」（Slack、タスク管理ツール、Wiki、GitHub Issueによる文書化）

　これらの問いへの答えの粒度で、その会社の技術文化の厚みが立ち現れます。抽象的な答えしか返ってこない会社は、社内で技術の言語化が進んでいないシグナル。具体的な答えが返ってくる会社は、日常的に技術文化が根付いているシグナル。

11-6. その席に、技術で上がってきた人が座っているか

　もう1つ、この局面でしか確かめられないことがあります。目の前のテックリード・リーダー層が、どうやってその席に到達したのかです。

　多くの会社で、テックリードは、管理職にならずに技術で上がっていく道（専門職ラダー）の入口にあたる役割です。そこに誰がどうやって座ったのかは、その会社が技術者をどう扱っているかの、いちばん手前の証拠になります。

「テックリードになられるまで、どういう道を歩まれましたか」
「この役割は、等級としてはどのあたりに位置づけられていますか」
「エンジニアが管理職にならずに上がっていく道は、等級として用意されていますか。いま、その等級にいる方は何人いらっしゃいますか」

　技術で上がった人が、技術のリードに座っている。当たり前に思えますが、そうでない会社もあります。年次で回ってきた、人が足りないから任された。そう返ってくるなら、技術のリードが、技術の実力とは別の理屈で決まっているということです。その理屈は、みなさんが数年後に評価されるときの理屈でもあります。

　制度についても、あるかどうかではなく、いま何人いるかで聞いてください。制度だけあって在籍者がゼロなら、その道は実質的にありません。

12. 技術面接の道具立てから読み取れる、その会社の技術力の測り方

　技術面接の中身と道具立ては、その会社が「技術力をどう測るか」の確かさを、率直に映します。

　良い会社の技術面接では、次のような道具立てと形式が使われる場面が多いです。

コーディング面接：GitHub上でのLive Coding、gist共有、CodeSandbox、Replit、Codespaces。事前に共有されたリポジトリを使って、Pull Requestを起点にレビュー模擬まで進める
システム設計面接：ホワイトボード、Miro、Figma、Google Jamboard、Excalidraw を使って、コンポーネント図とデータフローを対話しながら描く
テスト設計の実演：与えられた要件に対して、境界値・同値クラス・状態遷移を、その場で分析して見せる
コードレビュー模擬：既存のコード（少し古い、あるいは意図的に問題を仕込んだコード）に対して、レビューコメントを口頭で述べる
技術文献の読み合わせ：候補者が書いた技術ブログの記事や、応募先の公式技術ブログの記事を題材に、対等な議論をする

　これらの道具立ては、コード、システム、テスト、レビュー、文書、というエンジニアの日常のすべての側面から候補者を測ろうとする姿勢の表れです。

　いっぽう、一部の企業の技術面接では、次のような形式が中心になることもあります。

Javaや.NETの文法クイズ（「finalとfinallyとfinalizeの違いを説明してください」）
SQL構文の暗記問題（「INNER JOINとOUTER JOINの違いは」）
業務系フレームワーク（Struts、独自SIerフレームワーク、WebForms）の記法問題
Windows Server運用の暗記型質問（「IISのアプリケーションプールとは」）
情報処理技術者試験の過去問レベルの選択式問題

　念のため、繰り返しお伝えしておきます。これらの知識自体が悪いわけではありません。Java、SQL、Windows Serverの運用スキルは、いまも重要な仕事の土台です。ここで問いたいのは、技術面接という限られた対等な対話の時間を、その会社が何に使おうとしているか、の1点です。文法クイズと暗記型質問だけで技術面接が終わる会社は、技術力を「知識の暗記量」で測る旧い枠組みに留まっている、と読めます。逆に、コーディング・システム設計・テスト設計・コードレビュー模擬まで幅広く扱う会社は、技術力を「実装・思考・対話・レビューの厚み」で測る、世界基準に近い枠組みを持っています。

　学生としての判断材料は、明確です。技術面接の中身と道具立てから、その会社の技術力の測り方の確かさが読み取れます。カジュアル面談や説明会の段階で、「技術面接ではどのような形式・道具立てで進めますか」と聞いてみると、会社ごとの答え方の差にはっきり気づきます。

12-1. では、暗記型の面接が来ると分かったら

　ここまで読んで、自分の志望先は、どうも後者のほうらしい、と思った方がいるはずです。その場合にどうするかを、正面から書きます。

　まず、受けないという選択肢を先に置きません。測り方が旧くても、良い仕事をしている会社はあります。測り方は、その会社を見るための材料の1つであって、それだけで決める材料ではありません。

　そのうえで、準備は分けてください。

出そうな範囲を、その会社の募集要項から逆算する。使っている言語と基盤が書いてあります。JavaとOracleと書いてあるなら、問われるのはそこです。範囲を絞れば、暗記型の準備は思ったより短時間で終わります。
暗記の準備と、考え方の準備を、両方やる。暗記型の質問に答えたうえで、「実際に書いたときは、◯◯で詰まりました」と一言足せる状態にしておく。この一言があるかないかで、同じ正解でも残り方が変わります。
逆質問だけは、11章の上から3つを持っていく。面接の形式が旧くても、こちらが確かめる権利は変わりません。デプロイ回数とレビューの決まりは、どんな会社にも聞けます。

　そして、面接の形式が旧いことと、入社後に学べないことは、同じではありません。11章の問いへの答えのほうを、判断材料にしてください。

13. 技術面接で、注意深く聴きたい面接官の姿勢

　技術面接では、面接官の姿勢から会社の技術文化の厚みを、直接確かめられます。

13-1. 良い姿勢のシグナル

コーディング面接で、思考プロセスを対等に議論できる（正解を求めるだけでなく、対話の質を評価する）
システム設計面接で、トレードオフを一緒に議論する（一方的に答えを教えるのではなく、共に考える）
失敗事例を、面接官自身が正直に共有する（「私も◯◯というプロジェクトで失敗した経験があります」）
学生の逆質問に、具体的な事例で答える（抽象論で逃げない）
面接官自身が、技術のことを自分の言葉で語る（用意された広報資料の言葉ではなく）

13-2. 注意深く聴きたいシグナル

コーディング面接で、正解にたどり着くことだけを求める（思考プロセスへの関心が薄い）
システム設計面接で、面接官が用意した「正解」に誘導する（対等な議論の姿勢が薄い）
失敗事例を聞いても、抽象的な回答しか返ってこない（社内で失敗が言語化されていない）
学生の逆質問に、具体的な答えが返ってこない（社内で技術文化が言語化されていない）
面接官自身の言葉ではなく、決まったフレーズが並ぶ（面接官のトレーニングが薄い、または本人が技術を語れない）

　技術面接での面接官の姿勢は、その会社の日常のコードレビューの姿勢と、驚くほど一致します。

　ここで、一次面接と同じ読み方が効きます。面接官は、その会社が学生に見せてよいと判断した人です。つまり、目の前の技術対話は、その会社が外に出せる上限の側にあります。その上限が、社内の日常を下回ることは、まずありません。いちばん良い状態を見せているはずの場で技術の話が続かないなら、日常の技術の話はそれより下にあると考えたほうが安全です。

　最後に、この3つだけ観てください。面接官が、学生の質問に自分の言葉で答えられるか。技術判断のプロセスを、具体的な事例で語れるか。失敗事例を、個人の責任ではなく仕組みの話として語れるか。この3つは、面接の技術ではありません。日頃やっていることしか、その場では出てきません。

まとめ

　本記事では、技術面接（二次面接／テックリード・リーダー層）の実践をお話ししました。

　長い記事になりました。これだけ持って帰っていただければ足ります、という4点を先に置きます。

技術面接があるかどうかは、会社に聞いて確かめてください。「選考で実際にコードを書く場面はありますか」。実施率の統計はありません。
問題を渡されたら、書き始める前に理解を確かめてください。ここを飛ばすと、違うものを作って時間を失います。
詰まったら、黙らずに声に出してください。「いま◯◯で詰まっています。△△を考えていますが、どう思われますか」。全員詰まります。
逆質問は、11章の上から3つだけ持っていってください。意味の分かる問いだけを使うこと。

　以下、全体の振り返りです。技術面接で測られているのは知識の量ではなく、知識をどう使って考えるかです。対話相手はテックリード・リーダー層。3つの局面は、コーディング面接、システム設計面接、行動面接。情報系ではない方、まだ作っていない方は4章から始めてください。新卒でエンジニアになった人の4人に1人は文系大学卒です。コーディング面接の5つの姿勢は、問題の理解確認、思考の言語化、段階的な実装、テストの視点、詰まったときの相談。テストの視点には境界値分析・同値分割という名前がついています。システム設計面接の5つの姿勢は、要件の確認、大枠から詳細へ、トレードオフの言語化、道具立ての理解、セキュリティと可用性とテスト容易性の先出し。道具は4種類（クラウド・コンテナ・監視・CI/CD）が分かれば対話についていけます。行動面接の3つの姿勢は、技術判断のプロセス、失敗の正直な共有、学びを次につなげる姿勢。そして、面接の中身と道具立てから、その会社が技術力をどう測っているかが読み取れます。暗記型の面接が来ると分かったら、範囲を募集要項から逆算し、暗記と考え方の両方を準備してください。

　次のフェーズ4-6では、選考プロセスの4つ目の局面・三次面接（部課長層）のお話に進みます。技術面接を通過した学生さんに、企業側が部課長層を出してくる段階です。入社後、みなさんが日常的に指揮命令系統として所属するのは、この部課長層です。後半面接の中でも最も本気で臨むべき面接に、ここから入っていきます。

エンジニアの卵のみなさんへ、エール

　技術面接は、シリーズ全体の縦串が最も強く問われる場です。同時に、みなさんが最も対等な対話を実感できる場でもあります。テックリード・リーダー層と、コードとシステム設計について、対等に議論する。この対話の中で、自分がエンジニアという職業に向き合ってきた姿勢が立ち現れます。

　私自身が就活をしたのは、だいぶ前のことです。研究室の推薦で1社だけを受けました。当時、技術面接というものが、いまのような形で広く行われてはいませんでした。技術面接は対等な技術対話である、という捉え方も、まだありませんでした。あの頃の自分に、それを伝えられていたらと思います。

　そして、技術面接で対等な対話ができる会社は、社内でも対等な技術対話が根付いている会社です。技術面接での対話の質は、入社後の1年目の伸び方を、直接予告します。技術面接を、双方向の確かめ合いの場として大切にしてください。

　今週、なにか一つ、始めてみてください。応募先がまだ決まっていなくても、今日できることを並べます。

いま手元にあるコードを、1つGitHubに公開する。授業の課題でも、研究の解析スクリプトでも構いません。READMEに「何をするものか」「どう動かすか」を書く。
そのコードで、過去に落ちた入力を1つ思い出して書き留める。データが空だった、1行しかなかった、桁が想定外だった。それが境界値分析です（8-4）。
自分が詰まって直した経験を、1つだけ文章にする。500字で足ります。行動面接の素材になります。
説明会やカジュアル面談の予定があれば、「選考で実際にコードを書く場面はありますか」と聞く。これだけで、準備すべきものが決まります。

　まずはどれか1つで構いません。ただし、1つで終わりという意味ではありません。この4つは、いずれ全部やることになります。今週はどれか1つ、というのは、始める順番の話です。

　そして、フェーズ4-6で、三次面接（部課長層）の実践でお会いしましょう。

　一緒に歩きましょう。ボン・ボヤージュ。素敵な旅を。

次の記事は、フェーズ4-6「三次面接（部課長層）。入社後の毎日を左右する人ですが、配属先の上司とは限りません」です。

この連載を読むにあたって

　事実の確認について。 法令・統計・制度の記述は、一次情報にあたって確認し、出典のリンクを各記事の末尾に置いています。それでも、誤りが混じっている可能性は、ゼロではありません。数字と法令は、リンク先の原典で確かめてから使ってください。確かめる手間ごと、この連載がお渡ししたいものです。

　調査の時点について。 記事中の法令・統計・制度は、2026年9月15日時点で確認したものです。法令は改正され、統計は毎年更新されます。読んでいる時点との差は、ご自身で埋めてください。

　生成AIの利用について。 この連載は、調査と推敲に生成AIを使っています。

　最後は、ご自身で判断してください。 就職活動は、みなさんの人生の大きな選択です。この連載がお渡しするのは、判断の物差しであって、判断そのものではありません。物差しを当てるのは、みなさん自身です。

　そして、一人で抱えないでください。 相談先があります。大学のキャリアセンター。新卒応援ハローワークは全国56か所にあり、すべて無料で、専任の就職支援ナビゲーターが担当者制でついてくれます。労働条件のことは、総合労働相談コーナー（都道府県労働局や労働基準監督署などに全国378か所）でも相談できます。

#エンジニア就活 #技術面接 #コーディング面接 #システム設計 #就活生 #エンジニア採用 #エンジニアの卵に贈る就活の書

技術面接（二次面接）。コーディング・システム設計・行動面接で、対等に確かめ合う 【フェーズ4-5｜ITエンジニアの卵に贈る、就活の書】