技術選定で問われる8つの深掘り質問と回答の型を解説【技術面接 集中講座 #2】

• 1. 技術選定の深掘り質問が来るタイミング

• 2. 個別技術の選定理由で聞かれる8の質問

• 3. 技術選定で回答に詰まる人の3つの共通点

• 4. 技術選定を語れる人になるための準備法

• 5. まとめ

1. 技術選定の深掘り質問が来るタイミング

技術選定の深掘りは、ポートフォリオの全体感を確かめた後に行われます。「この技術を選んだ理由は？」と全体の方針を聞かれ、答えると、面接官は「では、なぜこの言語を使用したのか？」「なぜこのDBにしたのか？」と、一段ずつ掘り下げてきます。それまでに回答していた思考が、個別技術でも一貫しているかを確かめているのです。

2. 個別技術の選定理由で聞かれる8の質問

ここからは、8つの質問を順に見ていきます。各質問は、「よくあるNGな回答例」「面接官が見ているポイント」「回答の型」の3つで構成します。

質問1｜なぜこの言語を選んだのですか

■ よくあるNGな回答例

「TypeScriptを使いたかったので」「業務でよく使われているから」「型安全だから」と、言語の一般的なメリットを並べるだけになりがちです。「Reactを使うのでJavaScript/TypeScriptは必然」と、フレームワークに引っ張られた答えになることもあります。「Goで作ってみたかった」と興味起点で答えるケースも多いでしょう。いずれも、言語自体の特徴は語れても、「このアプリの要件に対して、なぜこの言語が合うのか」が抜けています。

■ 面接官が見ているポイント

見られているのは、「言語特性とアプリ要件のマッチングを意識して選んだか」です。実務では、言語選定は組織や既存資産、市場の影響も受けますが、学生のポートフォリオでは、純粋に「要件から言語を選んだ理由」を語れるかが問われます。「業務でよく使われるから」だけでは、深く検討していない印象を持たれやすいでしょう。逆に、要件から言語を選んだ筋道を語れれば、十分に評価されます。

なお、「この言語を勉強したかったから」という動機も、それ自体は問題ありません。ただしその場合は、「その言語で何を学びたかったか」「別の言語で同じアプリを作るならどう違うか」を深掘りされることがあります。答えを準備しておきましょう。

■ 回答の型

「アプリの主要要件→その要件に効く言語特性→候補言語の比較→採用理由」の流れで語ります。要件と言語特性を紐づけるのがポイントです。

▼回答イメージ

「多数の同時接続をさばくリアルタイム通知が中心機能だった。GoとNode.jsを候補にした。I/Oの並行処理はNode.jsも得意なので決め手にはならないが、多数の同時接続時のメモリ・スケジューリング効率、型の堅さ、シングルバイナリで運用が楽な点を総合してGoを選んだ」

質問2｜なぜこのフレームワーク／ライブラリを選んだのですか

■ よくあるNGな回答例

背景や文脈なしに、「Next.jsは情報が多いから」「Reactで一番メジャーだから」と、情報量や人気度だけを理由にしてしまいます。「SSRもSSGもできるから」と機能を並べるだけで、なぜそれが必要だったかが見えない答えになりがちです。他にも、「チュートリアルでよく使われるから」と、学習導線に流された理由を正直に話してしまうケースもあります。FWの機能は説明できても、「自分のアプリでなぜそのFWが必要か」の根拠が薄いのです。

■ 面接官が見ているポイント

見られているのは、「FWの選定はトレードオフの集合体」だと理解しているかです。何を取り、何を捨てたかを言語化できるかが、分かれ目になります。

■ 回答の型

「FWに求めた機能→候補FW→採用FWで得たもの・捨てたもの→採用判断」の流れで回答しましょう。トレードオフを明示することがポイントです。

▼回答イメージ

「コンテンツの更新が多くSEOも必要だったため、動的なSSR（更新の少ないページはSSG/ISR）が要ると判断した。Next.jsとNuxt.jsを候補にし、ReactエコシステムのUIライブラリやサードパーティ統合、採用市場の広さからNext.jsを選んだ。Nuxt.jsは記法のシンプルさに魅力があったが、今回使いたかったUIライブラリのReact版が充実していた点で判断した」

質問3｜他にどんな選択肢を比較検討しましたか

■ よくあるNGな回答例

もっとも避けたいのは、「今なら別の選択肢を知っていて、こういう理由でそちらが良いと思う」というフォローもなく、「他は考えていません」「これしか知らなかったので」と言い切ってしまうことです。「他にも色々ありますが、これが一番良いと思いました」と、比較対象を曖昧にぼかすこともあります。候補名は出せても、「なぜ採用しなかったか」まで踏み込めていない場合が多いです。

■ 面接官が見ているポイント

見られているのは、「複数の選択肢を持ち、その上で選ぶ」という意思決定の基本動作です。一択で選んでいると、視野の狭さを疑われる可能性があります。比較検討の有無は、情報収集力や批判的思考力の表れです。

■ 回答の型

最低2つの比較対象を準備し、「採用しなかった理由」まで言語化します。「Aを選んだのは○○のため」だけでなく、「Bを選ばなかったのは△△だから」もセットで語ると、トレードオフ思考が伝わります。

▼回答イメージ

「状態管理はZustandを採用したが、Reduxとjotaiも候補だった。ReduxはRedux Toolkitでボイラープレートを減らせるものの、今回の規模には機能が過剰と判断した。jotaiはアトム単位で軽量だが、将来チームで触る前提でドキュメント量と学習コストを重視しZustandにした」

質問4｜なぜこのDBを選んだのですか

■ よくあるNGな回答例

「PostgreSQLが一番情報が多いので」「MongoDBはスキーマレスで楽だから」と、学習コストの観点で答えてしまいます。「RDBは正規化できるから安心」「NoSQLはスケールするから」と、用語レベルの一般論で済ませることもあります。自分のアプリのデータ構造から選定理由を語れる学生は、少ないのが実情です。

■ 面接官が見ているポイント

見られているのは、「データ構造とアクセスパターンを理解した上でDBを選べるか」です。DB選定は、アプリ全体のアーキテクチャを規定する重要な判断です。根拠なく選んでいると、データ設計への意識が薄いと受け取られかねません。RDBとNoSQLの選択は、データの関係性と一貫性要件で決まる、という基本原則を踏まえているかが見られます。

■ 回答の型

「データの構造（リレーションの有無）→アクセスパターン（読み書き比率・クエリの複雑度）→一貫性要件→DB選定」の流れで回答しましょう。データ特性から選定理由を導きます。

▼回答イメージ

「ユーザーと投稿に強いリレーションがあり、JOINクエリが頻発する。整合性が重要だったのでRDB（PostgreSQL）を選んだ。NoSQLも候補にしたが、JOIN相当の処理がアプリ側に染み出すため不採用とした」

質問5｜なぜこのインフラ構成にしたのですか

■ よくあるNGな回答例

「Renderが使いやすかったから」と、運用の楽さだけで答えてしまいます。「AWSを使いたかったので」と、学習目的を理由にすることもあります。運用コストやスケーラビリティ、デプロイのしやすさなどを体系的に語れる学生は多くありません。

■ 面接官が見ているポイント

見られているのは、「インフラ選定の評価軸を複数持っているか」です。コストだけ、機能だけで選んでいると、バランス感覚を疑われます。実務では「コスト×スケーラビリティ×運用負荷×学習コスト×既存資産」などの多軸で判断します。複数の軸で比較できるかが、分かれ目です。

■ 回答の型

「アプリの要件（トラフィック予測・データ量・予算）→インフラに求める機能→候補比較→採用判断」の流れで回答しましょう。現実的な制約を起点に回答すれば十分です。

▼回答イメージ

「個人開発でトラフィックは少なく、コストを抑えたかった。フロントはVercelの無料枠で十分、バックエンドはコンテナで動かしたかったのでRenderにした。AWSはオーバースペックと判断した」

質問6｜認証方式の選定理由は何ですか

■ よくあるNGな回答例

「Auth0を使ったので簡単でした」「Firebase Authenticationが楽だから」と、マネージドサービスの便利さだけを語ってしまいます。「JWTで認証しています」と実装技術名を答えるだけで、なぜJWTを選んだかを説明できないことも多いです。「セッションとJWTの違い」を聞かれて答えられないケースも、よく起こります。

■ 面接官が見ているポイント

見られているのは、「アプリの要件に対して認証方式を選んだ筋道を語れるか」です。Auth0やFirebase Authなどのマネージドサービスを使うこと自体は一般的で、減点にはなりません。問題は、自前実装した認証を深掘りされた際に、トークンの保存方法やXSS・CSRF対策を説明できないことです。マネージドなら選定理由（開発コスト・セキュリティ責任の委譲など）、自前実装なら技術判断を、筋道立てて語れるかが分かれ目です。セッション vs JWT、Cookie vs LocalStorage、OAuth vs 独自実装の意味を理解しているかが見られます。

■ 回答の型

「認証要件（SNSログイン要否・MFA要否）→セキュリティ要件→開発コストとのバランス→選定」の流れで回答しましょう。セキュリティ観点を含めると、評価につながります。

▼回答イメージ

「ユーザーの心理的負担を下げるためGoogleログインを優先したかった。独自実装よりFirebase Authenticationを採用し、クライアントで取得したIDトークンをサーバーに渡し、Firebaseのセッションを表すCookie（HttpOnly＋Secure）をサーバー側で発行する構成にした。トークンをJSから触れるLocalStorageに置かないことで、XSSが起きてもトークン文字列を盗まれにくくするためだ。Cookie方式はCSRFのリスクが生じるため、SameSite=Laxを基本にしつつ、状態を変更するAPIにはCSRFトークンも併用した」

質問7｜状態管理の判断はどのようにしましたか

■ よくあるNGな回答例

「Reduxを使いました」「Zustandが流行っているから」と、ライブラリ名だけで答えてしまいます。「useStateで十分でした」と、理由なしの選択を答えることもあります。「いつ外部の状態管理ライブラリを使うべきか」という判断軸を持っていない学生が多いのです。

■ 面接官が見ているポイント

見られているのは、「過剰設計を避けつつ、必要な複雑度には対応できるか」です。小規模アプリにReduxを入れるのは過剰、グローバル状態が複雑なアプリにuseStateだけでは不足です。アプリの規模や状態の共有範囲に応じた選定ができているかが、分かれ目になります。状態管理は、技術選定で特にバランス感覚が問われる領域です。

■ 回答の型

「状態の種類（ローカル／サーバー／共有グローバル）→共有範囲→複雑度→ライブラリ選定または不採用」の流れで回答しましょう。状態の種類を分けて語ります。

▼回答イメージ

「サーバー状態はTanStack Queryに分離した。その結果、グローバルに持つべきクライアント状態は3画面間で共有する設定程度に減り、Reduxは過剰と判断してuseContextで対応した。共有するのは更新頻度の低い設定値なので、Contextの値更新による再レンダリングのコストも問題にならないと判断した」

質問8｜テストはどのように行いましたか

■ よくあるNGな回答例

「テストは書いていません」「時間がなくて書けませんでした」と、正直に答えて終わってしまいます。また、「ユニットテストを書きました」と漠然と答えるだけで、何を・どこまで・なぜテストしたかを説明できないこともあります。カバレッジは気にしていても、テスト戦略を語れないケースが大半です。

■ 面接官が見ているポイント

見られているのは、「テストを書く（書かない）判断の根拠を語れるか」です。何をテストし、何をテストしないかの判断を言語化できているかが、分かれ目です。なお、テストを書いていないこと自体は、減点ではありません。実務でも、テストの優先度は要件によって変わります。書いていない場合でも、その理由と今後の方針を語れれば評価されます。

■ 回答の型

書いている場合は「テスト対象の選定理由→テスト種別（ユニット／統合／E2E）→カバレッジの考え方→不足部分」の流れで回答しましょう。書いていない場合は「書けなかった理由→本来書くべきだった箇所→次回は何から書くか」を語ります。どちらも「テストへの考え方」を見せることが大切です。

▼回答イメージ

「影響度が最も高い料金計算ロジックだけ優先してユニットテストを書き、主要動線はE2Eを1本通すに留めた。UIの細かな表示は変更が多く費用対効果が低いと判断し、あえて書かなかった」

3. 技術選定で回答に詰まる人の3つの共通点

ここまでの8問に共通する、回答に詰まるパターン3つを整理して解説します。

共通点1｜単一の理由しか持っていない

「便利だから」「人気だから」「業務で使われているから」と、1つの理由で技術を選んでいます。実務では、コストや学習負荷、将来性、チーム適合性など、複数の軸で判断するのが普通です。単一の理由は、思考の浅さとして判断されかねません。特に質問1や質問4で出やすいパターンです。

各技術について、3つほど選定軸を持ちましょう。たとえばPostgreSQLなら、「データの関係性」「クエリの複雑度」「将来のスケール」などです。

共通点2｜採用しなかった選択肢を語れない

採用理由は説明できても、「他にも検討したか」と聞かれると詰まります。選択肢を1つしか持っていないのは、比較していないことの証しです。特に質問3や質問7で出やすいパターンです。

各技術について、最低2つの代替候補を頭に入れましょう。「採用しなかった理由」も含めて整理しておきます。

共通点3｜自分のアプリの特性と紐づけられない

「Next.jsは○○ができる」「PostgreSQLは○○が強い」と一般論は語れても、「自分のアプリでなぜそれが必要だったか」に紐づけて語れません。特に質問2や質問5で出やすいパターンです。

技術選定の答え方は、必ず「アプリの要件→求める技術特性→採用」の流れにします。技術の一般的な説明から始めないようにしましょう。

■ 個人開発しか経験がない場合は？

ここまで技術選定は「実務では組織や既存資産、市場で決まる」とお伝えしてきました。個人開発しか経験がないと、「自分には語りようがない」と感じるかもしれません。しかし個人開発は組織の制約がない分、要件を自分で定義でき、「要件起点」で選定を語れる強みがあります。さらに、「もしチームが5人なら」「もし月100万リクエストなら」と実務を仮定して一言添えると、制約下での判断力も示せます。

4. 技術選定を語れる人になるための準備法

作成した段階では「そこまで深く技術選定について考えていなかった」という方もいらっしゃるかもしれません。しかし、当時を振り返り「この観点でやはり適切だった」「今ならこうする」という考えを伝えられれば、面接では十分に評価されます。

最後に、技術選定を語れるようにするための準備を4ステップに分けて解説します。

Step1｜ポートフォリオの「技術選定マップ」を作る

紙やドキュメントに、使った技術を縦に並べ、次の3列を埋めます。1つ目は採用理由（このアプリの要件＋技術特性）、2つ目は採用しなかった代替候補（最低1つ）、3つ目は採用後の振り返り（実際に使ってみてどうだったか）です。埋められない技術があれば、それは面接で詰まる質問になりやすい箇所です。

Step2｜一つの技術を「30秒・1分・3分」で説明できるようにする

時間の制約で、答え方は変わります。30秒なら結論と最重要の理由のみ、1分なら候補比較と採用判断、3分なら要件・トレードオフ・採用後の振り返りまで含めるイメージです。面接では「簡単に教えてください」とも「詳しく深掘りしたい」とも言われます。両方の引き出しを準備しておきましょう。

Step3｜「もし○○なら別の技術を選んでいた」を考える

各技術について、「アプリの要件が違っていたら別の技術を選んでいたか」を考えます。これができると、選定が要件に依存していること、つまり思考停止で選んでいないことが伝わります。以下のように説明できると良いでしょう。

「今回は型安全性とエコシステムの豊富さからTypeScript＋Next.jsを選んだ。もし開発スピードを最優先する小規模アプリだったらRailsを選んでいた。フルスタックで規約に沿って高速に書ける利点が、CRUD中心の小規模では効くからだ」

Step4｜模擬面接で「なぜ」を5回掘られる練習をする

面接官は「なぜ？」を繰り返して掘ってきます。「なぜReact？」に対して理由Aを述べると、「なぜAだとReactなのか？」から理由Bを回答すると、「なぜBが重要？」へと続きます。5回掘られても答えられる準備を、最も自信のある技術について行いましょう。深く語れる技術が1つあることが、差別化につながります。

5. まとめ

技術選定は、「個別技術の一般論」ではなく「アプリの要件との紐づけ」で語ることが大切です。8つの質問に共通するのは、要件から逆算して手段を選び、採用しなかった候補まで語れるかどうかでした。「採用理由」だけでなく「採用しなかった代替候補」も準備し、8つすべてについて技術選定マップを作っておきましょう。