バックエンドエンジニア技術面接、DB設計かシステム設計か

「システム設計のフレームワークは完璧に叩き込んだのに、聞かれたのはインデックスの張り方だけだった」——技術面接を終えた候補者から、拍子抜けしたような報告を受けることがあります。

IT・Web業界を中心に800名以上の転職支援に携わってきましたが、バックエンドエンジニアの技術面接で不合格になる相談の多くは、実力不足ではなく準備した領域と、面接官が深掘りしたい領域がずれていたことが原因です。今回は、DB設計とシステム設計のどちらを深掘りされやすいかを、面接前にある程度予測して準備の優先順位を決める方法を、実際の相談事例とともにお伝えします。

目次

1. バックエンドエンジニアの技術面接、DB設計とシステム設計どちらを深掘りされるか
2. DB設計に強い面接官が聞いてくる質問と評価軸
3. システム設計に強い面接官が聞いてくる質問と評価軸
4. 求人票の技術スタック記載と面接官の経歴から、深掘りの重心を逆算する方法
5. 求人票の技術スタック欄の書き方を読む
6. 面接官の役職・経歴からポジションの重心を読む
7. 予測できたら、職務経歴書の書き方もそちらに寄せる
8. カジュアル面談で面接官の専門性を事前に確認する質問例
9. 社員数の少ない企業ほど、面接官一人がDBとシステム設計の両方を担当する
10. 実際にあった例、求人票の技術スタックだけを見て準備の重心を誤ったケース
11. まとめ、DB設計かシステム設計かは面接官の専門性で決まる

バックエンドエンジニアの技術面接、DB設計とシステム設計どちらを深掘りされるか

バックエンドエンジニアの技術面接対策を調べると、正規化やインデックスといったDB設計の頻出質問集と、要件確認からボトルネック対策まで進めるシステム設計面接のフレームワークが、それぞれ独立した記事として大量に出てきます。ところがこの2つを同時に、しかも「自分が受ける面接ではどちらが本命か」という視点で扱った情報にはほとんど出会いません。

バックエンドエンジニアの業務範囲自体が、RDBMSの選定からAPI設計、システム全体のアーキテクチャ検討まで広いことが背景にあります。dodaエンジニアITの職種解説でも、バックエンドエンジニアの仕事は要件をもとにした機能の具現化からアーキテクチャ検討、Oracle・SQL Server・MySQL・PostgreSQLといったRDBMS選定の知識まで及ぶとされており(参考：バックエンドエンジニアとは？仕事内容やスキル｜dodaエンジニアIT)、担当領域の広さが逆に「面接官ごとに聞きたいことが違う」という現象を生んでいます。

以前の記事(現場エンジニア面接官と人事・役員面接官、評価軸が違う理由)では、同じ現場エンジニアでも、人事や役員と比べて技術の解像度を見る、という役割の違いを取り上げました。今回はその一段先、同じ現場エンジニアの面接官どうしでも、専門領域によって深掘りの中身が変わるという話です。DB専任のエンジニアとインフラ・アーキテクチャ寄りのエンジニアでは、同じ「技術的な突っ込み」でも矛先がまったく違います。

DB設計に強い面接官が聞いてくる質問と評価軸

DBA出身者やデータ基盤チームの担当者、あるいはSIerでの基幹システム保守経験が長いメンバーが面接官に立つと、質問はデータそのものの扱いに集中しやすくなります。頻出するのは次のようなテーマです。

この手の面接官が本当に見ているのは、用語を暗記しているかどうかではありません。「なぜそのインデックスを張ったのか」「なぜそのタイミングで非正規化したのか」という、自分の設計判断を理由込みで説明できるかを確認しています。N+1問題を例に挙げると、「発生に気づいて修正しました」で終わる候補者と、「ログのクエリ発行回数を見て気づき、Eager Loadingに切り替えた結果、レスポンスタイムが◯割縮んだ」まで語れる候補者とでは、面接官の受け取り方がまったく違います。

実際にDB専任の面接官が候補者に投げた質問で印象に残っているのは、「そのインデックス、書き込みが多いテーブルに張って困ったことはありますか」という一言でした。インデックスを張れば読み取りは速くなりますが、書き込み・更新のたびにインデックスの再構築コストがかかります。この読み取りと書き込みのトレードオフを自分の失敗談として語れるかどうかで、評価が大きく分かれた場面を私は何度も見てきました。

RDBMSとNoSQLの選定理由も、DB寄りの面接官がよく確認するテーマです。「なぜPostgreSQLではなくDynamoDBを選んだのか」と聞かれたとき、「スケールしやすいから」だけで止まる候補者と、「アクセスパターンがキー単位の読み取りに偏っていて、複雑なJOINが不要だったから」まで説明できる候補者とでは、聞こえ方がまるで違います。この種の質問は正解を当てさせたいのではなく、選定の理由を自分の言葉で持っているかを確かめる意図の方が強いというのが私の理解です。

システム設計に強い面接官が聞いてくる質問と評価軸

一方、SRE・インフラ出身のメンバーやテックリード、CTO・VPoEクラスが面接官に立つと、話の重心は個々のテーブル設計から、システム全体の構成に移ります。多くの記事で紹介されている進め方は、次のような順序です。

この形式で評価されるのは、正解の構成図を暗記しているかではなく、曖昧な要件から自分で前提を置いて意思決定を組み立てられるかという思考プロセスです。「読み込みが多いシステムなのでキャッシュを挟みます」だけで終わらせず、「キャッシュの無効化はどう扱うか」「キャッシュヒット率が下がった場合にどう気づくか」まで踏み込んで話せるかどうかで、面接官の反応は変わります。

DB設計面接との一番の違いは、単一の正解に収束しないという点です。DB設計の質問には「このケースなら複合インデックスを張るべき」という比較的明確な答えがありますが、システム設計は「読み取り整合性を犠牲にしてでもスケールを優先する」といったトレードオフの選択そのものが評価対象になります。だからこそ、面接官は候補者の判断に対して「では逆に、書き込みの整合性を優先するとどう変わりますか」と揺さぶりをかけてくることが多く、ここで一貫した理由づけを保てるかが分かれ目になります。

DB設計面接でよくあるNG回答は、「正規化はしています」「インデックスは適切に張っています」のように、判断の基準を語らずに結果だけを述べて終わることです。面接官が本当に聞きたいのは「適切」の中身なので、ここで会話が止まってしまうと、実務経験そのものを疑われかねません。システム設計面接でのNG回答は逆に、要件を確認せずいきなり完成形の構成図を描き始めることです。「想定ユーザー数は」「読み書きの比率は」と自分から聞き返さずに設計を進めてしまうと、実際の現場で仕様を確認せずに実装を始めるタイプだと受け取られるリスクがあります。

情報処理推進機構(IPA)のシステムアーキテクト試験の定義でも、システムアーキテクトは「業務とITのグランドデザイナー」として、ネットワークやデータベースといった専門分野と連携しながら上流工程を主導する立場とされています(参考：システムアーキテクト試験｜IPA)。国の技術者試験の区分でも、データベースの専門性とシステムアーキテクチャの専門性は別のものとして扱われているわけです。技術面接で聞かれる領域が面接官によって割れるのは、この専門性の分かれ方が現場にそのまま持ち込まれているだけだと私は見ています。

求人票の技術スタック記載と面接官の経歴から、深掘りの重心を逆算する方法

ここまでの話を読んで、「結局は面接官次第で運任せではないか」と感じた人もいると思います。ただ私の実感では、面接前の情報からある程度まで予測できる場面が思っている以上に多いです。エージェントとして候補者の面接対策に付き合う中で、私が実際に確認しているポイントを2つに分けてお伝えします。

求人票の技術スタック欄の書き方を読む

求人票の「必須要件」「歓迎スキル」の欄に並ぶ技術名の傾向で、その企業がどちらの専門性を重視しているかがある程度見えます。「MySQLのパフォーマンスチューニング経験」「大規模データのスキーマ設計経験」のようにDB周りの技術が具体的な粒度で列挙されている求人は、社内にDB専任のポジションがあるか、少なくともDBの深い知見を持つメンバーが選考に関わっている可能性が高いと見ています。

逆に「マイクロサービス」「イベント駆動アーキテクチャ」「メッセージキュー」「Kubernetes」といった、システム全体の構成要素を示す単語が並ぶ求人は、面接でもアーキテクチャレベルの議論になりやすい傾向があります。求人票の技術スタック欄は、採用担当者が「今このスキルを持つ人が社内で評価されている」という実感をもとに書いていることが多く、現場で誰が困っているかがそのまま反映されていると考えてよいと思います。

もう一つ見落とされがちなのが、求人票の「募集の背景」欄です。「データ量の増加に伴いパフォーマンス改善が急務」と書かれていればDB側の課題感が強く、「サービス拡大に伴いアーキテクチャの刷新を進めている」と書かれていればシステム設計側の課題感が強い、というように、その会社が今まさに困っている領域がにじみ出ていることが多いです。技術スタック欄よりも背景欄の方が、面接官の関心を素直に反映しているケースすらあります。

面接官の役職・経歴からポジションの重心を読む

もう一つの手がかりは、面接案内メールや会社のエンジニア紹介ページに載っている面接官の肩書き・経歴です。LinkedInやカジュアル面談の案内に「元DBA」「データ基盤チームリード」といった経歴が出ていれば、DB設計の深掘りに備えた方がいい可能性が高いですし、「SRE出身」「インフラ基盤の立ち上げ経験」「CTO」「VPoE」といった肩書きであれば、システム全体のアーキテクチャやスケーラビリティの議論に時間を割かれる可能性が高くなります。

求人票と面接官の経歴、この2つの情報がずれているときは要注意です。求人票にはDB関連の技術要件が並んでいるのに、実際に一次面接に出てくるのはインフラ出身のテックリードだった、というケースも珍しくありません。この場合、求人票は「配属先チームが欲しい人材像」を表し、面接官は「その面接段階で評価を担当する人」を表しているだけなので、両者が一致するとは限らないと理解しておく必要があります。求人票だけでなく面接官の経歴まで合わせて確認することで、予測の精度はかなり上がります。

予測できたら、職務経歴書の書き方もそちらに寄せる

深掘りの重心が予測できたら、面接対策だけでなく職務経歴書やスキルシートの書き方も調整しておくと効果的です。DB設計寄りの深掘りが濃厚な企業であれば、職務経歴欄に「テーブル設計・インデックス設計を主導」「クエリのボトルネックを特定しレスポンスを◯割改善」のように、データ周りの成果を具体的に前に出します。

システム設計寄りの企業であれば、「サービス分割の意思決定に参加」「負荷試験の結果をもとにキャッシュ層を追加」のように、構成レベルの判断を書いた方が、書類の時点で面接官の関心と合致しやすくなります。同じ実務経験でも、どちらの成果を前に出すかで書類通過後の面接の空気がまるで別物になる、という場面に何度も立ち会っています。

カジュアル面談で面接官の専門性を事前に確認する質問例

求人票と経歴からの予測には限界があるので、可能な場面では選考前のカジュアル面談やエージェント経由のヒアリングで、直接確認してしまうのが一番確実です。ただ「次の面接官はどんな人ですか」とだけ聞いても、当たり障りのない答えしか返ってこないことが多いので、聞き方を工夫する必要があります。

エージェント経由で応募している場合は、企業側の採用担当に対して、担当エージェントから面接官の専門領域を確認してもらうこともできます。私自身、面接前に企業へ「今回の面接官の方は、DBとインフラどちらのバックグラウンドが強い方でしょうか」と一言確認するだけで、候補者に渡せる情報の解像度がまったく変わる、という経験を何度もしています。企業側も候補者にちぐはぐな準備をされて時間を無駄にするより、事前に方向性がすり合っている方が選考をスムーズに進められるので、聞かれて嫌がられる質問ではありません。

ポイント： 「どちらが本命か分からないから両方完璧に準備する」という発想は、時間が限られた転職活動では非効率です。求人票・面接官の経歴・カジュアル面談での確認、この3つの情報を組み合わせて優先順位をつけてから深掘りする方が、結果的に両方の理解も深まります。

事前確認の機会が取れなかった場合でも、面接本番の冒頭で聞いてしまう方法があります。自己紹介が終わったタイミングで、「今日はDB設計とシステム全体の構成、どちらを中心に伺えますか」と一言確認するだけで構いません。面接官も準備してきた質問の方向性を答えるだけなので身構える必要がなく、この一言で残り時間の話し方を組み立て直せます。私が同行した面接ではありませんが、候補者からは「聞いてよかった、聞かなければ的外れな説明を続けるところだった」という感想を繰り返し受け取っています。

社員数の少ない企業ほど、面接官一人がDBとシステム設計の両方を担当する

ここまでDB設計担当とシステム設計担当を分けて説明してきましたが、社員数が20〜30人規模のスタートアップや、バックエンドチームが3〜4人しかいない企業では、この区分けがそもそも成立しないことがあります。CTOやテックリード一人が、DBのスキーマ設計からインフラ構成まで全部見ている場合、面接でも両方の質問が同じ面接官から矢継ぎ早に飛んでくることになります。

このケースで起きやすい失敗は、片方の準備に寄せすぎてしまうことです。求人票にマイクロサービスという単語があったからシステム設計だけを固めていったら、実際には「まずテーブル設計から聞かせてください」と切り出され、慌てて記憶を辿ることになった、という相談もありました。企業規模が小さいほど、一人の面接官が両方を横断して聞いてくる可能性を織り込んでおく必要があります。目安としては、エンジニア組織が10人を切るくらいの規模であれば、DB・システム設計どちらも基礎レベルは崩さずに、求人票や経歴から見えた重心の方に厚みを持たせる、という配分が現実的です。

企業のエンジニア組織の規模は、求人票だけでは分からないことが多いですが、採用ページの社員紹介や、LinkedIn上でその会社のエンジニア職を検索したときのヒット件数からおおよそ推測できます。エンジニアが片手で数えられる規模だと分かれば、応募段階から「面接官は一人で複数領域を見ている可能性が高い」という前提で準備を組み立てておくと、当日の想定外を減らせます。

実際にあった例、求人票の技術スタックだけを見て準備の重心を誤ったケース

「インデックスは何を基準に張っていますか」——システム設計のフレームワークを一通り叩き込んで臨んだ二次面接で、飛んできた質問に言葉が詰まった、という相談を受けたことがあります。

相談してきたのは、独立系SIerで社会保険関連の基幹システム保守を担当していた、経験8年のバックエンドエンジニアでした。応募先は不動産マッチングプラットフォームを運営する自社開発企業で、求人票の技術スタック欄には「AWS、ECS、DynamoDB、マイクロサービス構成への移行を推進中」と書かれていました。この文言だけを見て、彼はシステム設計のフレームワークを中心に対策を進め、要件確認から概算見積もり、ハイレベル構成図までの流れを何度も練習して面接に臨みました。

ところが実際に二次面接を担当したのは、前職でDBAとしてデータベース基盤の運用を長く担当していたエンジニアでした。求人票のマイクロサービス構成という記載は、あくまで会社としての中長期の技術方針であって、その面接段階で評価を担当するメンバーの専門性とは別だったわけです。冒頭の「インデックスは何を基準に張っていますか」の後も、「複合インデックスの列順はどう決めますか」「そのテーブルのカーディナリティは把握していますか」と質問が続き、正規化やインデックスの質問に対して、彼の準備は薄いままでした。結果、答えに詰まる場面が続き、その回の選考は見送りになりました。

この結果を受けて、次の応募先ではカジュアル面談の段階で「次の技術面接を担当される方は、普段どのあたりの技術領域を見ていらっしゃいますか」と確認するようにしました。すると採用担当から「二次面接はアーキテクト出身のCTOが担当し、トレードオフの説明力を重視している」という回答が返ってきました。彼はDB周りの基礎知識を落とさない範囲で維持しつつ、システム設計のトレードオフを言語化する練習に時間を集中させ、実際の面接でもキャッシュ戦略と整合性の関係について一貫した説明ができ、内定を得ています。提示された年収は前職より60万円ほど高い水準でした。

求人票の技術スタック欄だけを見て準備を決めてしまうと、彼のように的を外した練習に時間を使ってしまうことがあります。求人票・面接官の経歴・事前のヒアリング、この3つを重ねて確認する一手間が、準備時間の配分を大きく変えることを、この一件から改めて感じました。

まとめ、DB設計かシステム設計かは面接官の専門性で決まる

バックエンドエンジニアの技術面接対策というと、正規化やインデックスの用語集を覚える、あるいはシステム設計のフレームワークを暗記するという方向に意識が向きがちです。ですが実際に評価を左右しているのは、暗記量ではなく面接官が誰で、何を専門にしてきた人なのかという一点です。

同じ「バックエンドエンジニアの技術面接」というラベルの中に、DBの整合性と性能を問う面接官と、システム全体のトレードオフを問う面接官が混在している以上、対策も一律にはできません。求人票の技術スタック欄、面接官の役職・経歴、そしてカジュアル面談での一言の確認——この3つを組み合わせて深掘りの重心を予測し、限られた準備時間をどちらに厚く配分するかを決める。この逆算の発想こそが、コーディングテストの形式別の準備不足と同じくらい、技術面接の合否を左右していると私は考えています。