ポートフォリオ面接で聞かれる10の質問｜面接官が見ているポイントを解説

• 1. なぜ「技術力があっても落ちる」のか
• 2. ポートフォリオ面接の典型的な流れ（3フェーズ）
• 3. 【冒頭フェーズ】自己紹介とポートフォリオの全体像
• 4. 【中盤フェーズ】技術と設計の深掘り
• 5. 【終盤フェーズ】運用・反省・未来
• 6. スキルのある学生が陥る5つのアンチパターン
• 7. ポートフォリオ面接の評価につながりやすくする4ステップ準備法
• 8. まとめ

1. なぜ「技術力があっても落ちる」のか

技術力が高い学生ほど「良いものを作れば伝わる」と考えがちです。しかし、面接官はポートフォリオを通じてその人の思考や姿勢を見ています。完成度をアピールしても、判断の理由を語れなければ評価は伸び悩みます。

面接官の評価は、大きく4つの軸に分かれます。技術力だけでなく、思考プロセスやコミュニケーション、カルチャーフィットも見られます。それぞれの軸で何が問われるのかを、下の表にまとめました。

技術力はこの4軸のうちの1つにすぎません。残りの3軸を意識せずに臨むと、技術力が高くても総合評価で見劣りすることがあります。だからこそ、思考や伝え方まで準備しておくと安心です。

2. ポートフォリオ面接の典型的な流れ（3フェーズ）

ポートフォリオ面接は、冒頭・中盤・終盤とそれぞれのフェーズごとに面接官が見ているものが異なります。流れをつかんでおくと、どの質問にどう備えればよいかが見えてきます。

冒頭フェーズは、作品の全体像と人柄を確認する時間です。中盤フェーズは技術と設計を深掘りする面接の本体にあたります。終盤フェーズでは、運用視点や反省、成長意欲が問われます。時間配分の目安は、下の表のとおりです。

ここで挙げた時間は、あくまで目安です。30分以上かけてポートフォリオを深掘りする面接は、主にWeb系（自社開発企業）の技術面接を想定しています。本選考の一次面接は逆質問や志望動機も含むため、深掘りの時間はより短くなる傾向があります。

3. 【冒頭フェーズ】自己紹介とポートフォリオの全体像

冒頭フェーズの目的は、作品の概要把握と人柄の確認です。最初の5〜10分では、技術の深掘りはまだ始まりません。面接官は作品の全体像をつかみながら、話し手の人物像を見ています。ここで全体像をうまく伝えられると、後半の深掘りも進めやすくなります。

質問1｜なぜこのテーマを選んだのか

この質問では、テーマ選びの背景にある「あなたの世界の見方」が問われます。面接官は、技術そのものより、ユーザーや業界の課題に興味を持てるかを見ています。

スキルのある学生ほど、ここで抽象的な答えになりがちです。「自分が普段使うアプリを作りたかった」「学生向けにあると便利だと思った」のような答えは、当たり障りがありません。「Reactを学びたかったので、それで作れそうなものを考えた」と技術起点で語る人もいます。答えは出ても、面接官が知りたいテーマへの興味は伝わりにくいでしょう。

技術はあくまで手段であり、解決すべき課題への興味がないと長く活躍しにくいと考えられます。だからこそ、テーマ選びの理由は、その人の価値観を映す材料になります。

回答は「原体験→観察した課題→なぜ自分が解決したいか」の流れで語ると伝わります。たとえば「自分が学習管理で困った経験から、同じ悩みを持つ学生が多いと考え、このアプリを作った」のように、個人的な体験を起点にしましょう。

質問2｜このアプリで解決したい課題は何か

この質問で問われるのは、課題の「解像度」です。面接官は、漠然と「便利にしたい」ではなく、誰がどの場面でどう困っているかを具体化できるかを見ています。

技術力の高い学生は、機能の言い換えで答えてしまいがちです。「○○を効率化したい」「管理が大変な人を助けたい」といった答えは、機能を作る目的にとどまります。プロダクト用語を並べるだけになることもあります。「誰がどう困っているか」の具体度が足りないと、課題発見の力は伝わりません。

プロダクト開発の本質は、課題発見にあります。ここの解像度が低いと、「機能を作る人」と受け取られかねません。

回答は「誰が・いつ・どう困っているか」の3点セットで語ると具体的になります。たとえば「就活アプリを3つ以上使う大学2〜3年生が、応募状況を一覧できず提出期限を逃している」のように、場面まで具体的に伝えましょう。

質問3｜このアプリの概要を3分で説明してください

この質問では、コミュニケーション能力とメタ認知能力が問われます。面接官が見ているのは、技術の詳細ではなく、全体像が3分で伝わるかどうかです。エンジニア以外の聞き手にも分かるように説明できるかが、分かれ目になります。

開発経験のある学生は、過剰か過小のどちらかに振れがちです。最初の30秒で技術スタックを並べ始めたり、機能を一つひとつ説明して3分に収まらなかったりします。逆に「ToDo管理アプリです」と一行で終えてしまう人もいます。どちらの場合も、全体像が3分では伝わりません。

3分プレゼンの型に沿って整理すると、過不足なく伝えられます。最初の30秒（約150字）で「何のアプリか・誰のためか」を述べ、次の60秒（約300字）で主要機能と使い方を説明します。続く60秒（約300字）で使った技術と設計のポイントを語り、最後の30秒（約150字）で工夫した点と今後の展開を添えると、構成が安定するでしょう。

質問4｜一人で作りましたか、複数人で作りましたか

この質問では、開発体制に応じてあなたが何を語れるかが問われます。個人開発とチーム開発で見られるポイントは異なりますが、どちらでも評価されるため、自分のケースに合った語り方を準備しておくと、どんな体制でも落ち着いて答えられます。

よくある失敗は、事実だけで答えてしまうことです。「一人で作った」「友達3人で作った」と述べ、複数人の場合に自分の担当範囲を語れず「全員でやった」と曖昧になることがあります。一人で作った経験を、他人と作ったことのない弱みとして後ろ向きに語る人もいます。

個人開発では、設計から実装まで一人で意思決定できた点が評価されます。技術選定やスケジュール管理、トレードオフをすべて自分の判断でこなした強みを語りましょう。一人で作った経験を、弱みに見せる必要はありません。

また、チーム開発では、自分の貢献範囲と他のメンバーとの境界を明確にすると、面接官は評価しやすくなります。コードレビューやタスク分担などの協働経験も語れると良いでしょう。たとえば「3人チームで開発し、私はフロントエンドとAPI設計を担当しました」のように、担当範囲を具体的に語りましょう。なお、この質問は事実確認で終わらず、チーム開発では「意見が割れたときどう決めたか」「コンフリクトやレビューでどう立ち回ったか」まで掘られることが多いので、自分の意思決定が見えるエピソードを一つ用意しておくと強いです。

4. 【中盤フェーズ】技術と設計の深掘り

中盤フェーズは、技術面接の本体にあたります。15分ほどかけて、技術と設計の判断を深掘りされる時間です。ここでは個別の論点を細かく追うより、全体像と典型的な質問、回答の型を押さえておくと対応しやすくなります。

質問5｜なぜこの技術スタックを選んだのか

この質問で問われるのは、要件に対するトレードオフをどう考えたかという意思決定プロセスです。技術選定はエンジニアの基本的な意思決定であり、ここで思考が見えないと「言われた技術を使う人」と受け取られる場合もあります。

スキルのある学生は、個別技術のメリットを単発で並べがちです。「Reactを使いたかった」「TypeScriptは型安全だから」のように、理由がバラバラに並ぶことがあります。「業務でよく使われるから」と外部の評価軸で答える人もいます。答えはあっても、選定の筋道が見えません。

回答は「要件→制約→候補→トレードオフ→選択」の流れで語ると筋が通ります。個別技術の深掘り（たとえば「なぜNext.jsではなくReact単体か」「なぜRESTでGraphQLでないか」）は、面接では派生質問として展開されます。その具体的な答え方の型は第2章で扱うので、ここではスタック全体の方針を総論で答えると、整理しやすいでしょう。

質問6｜アーキテクチャ全体の設計判断の根拠

この質問では、コードを書く前の設計判断ができるかが問われます。実務では実装より設計に時間がかかり、その判断の質がプロダクトの将来を左右するといえるでしょう。ここを言葉にできないと、「実装はできるが設計はできない人」と受け取られることもあります。

技術力の高い学生は、構成の説明に終始しがちです。「フロントとバックを分けて、REST APIでつないでいます」と、どう作ったかを語ってしまいます。聞かれているのは「なぜそうしたか」です。「一般的な構成なので」と答える人もいますが、要件まで掘り下げた根拠には届きません。

回答は「機能要件→非機能要件→制約→設計判断」の流れで説明すると伝わります。たとえば「画面遷移のたびにフルリロードが入ると入力中の状態が失われるため、状態を保持して操作を滑らかにしたかった」と語れます。そのうえで「SEOや初回表示の速さは要件上の優先度が低く、SSRを導入する複雑さに見合わないと判断した」と、選ばなかった選択肢の検討まで添えると説得力が増します。

なお「状態を保持したい」こと自体はSSRでも実現できるので、「状態を保ちたい＝SPA」と一対一で結びつけず、状態保持・操作性（クライアントサイドルーティングの根拠）と、SSRを見送った理由（SEO・初回表示の優先度と導入コスト）を別の軸として語ると、鋭い面接官にも崩されません。

質問7｜一番難しかった課題と解決アプローチ

この質問で見られているのは、困難に直面したときの仮説検証プロセスです。エンジニアリングは問題解決の連続であり、問題への向き合い方そのものが評価対象になります。

開発経験のある学生は、症状の説明から入りがちです。「○○のバグに苦労した」「実装が分からず困った」と出来事を語り、「調べて解決した」と手段を一言で済ませることもあります。最後の学びまで構造化して語れる学生は多くありません。出来事は語れても、仮説検証のプロセスとして再構成されていないのです。

困難を一つも語れないと、「挑戦の幅が見えにくい」と受け取られやすくなります。ただし、順調だったことが挑戦していない証拠になるわけではありません。設計で難所を先回りして潰した、という語り方も有効です。「先回りで潰した」が評価されるのは、なぜそれが難所になると事前に見抜けたのか、どんな代替案と比べたのかまで語れる場合に限られます。単に「難しいことはなかった」で済ませると、かえって挑戦の浅さと受け取られやすいので、逃げ道として使わないようにしましょう。面接官はトラブルの有無より、向き合い方を見ています。

回答はSTARフレームに学びを加えた「STAR+L」で構造化すると伝わります。状況・課題・行動・結果に学びを足し、「Aという問題にBという仮説を立て、Cで検証し、Dで原因を特定し、Eで解決した」と語ります。最後に「この経験から○○を学んだ」と添えると、仮説検証のサイクルが伝わるでしょう。

質問8｜AIをどこまで使ったか

この質問は、AI時代のエンジニアの新しい評価軸です。面接官は「AIに任せる範囲」と「自分で判断する範囲」の境界を引けているか、出力の品質保証ができているかを見ています。

スキルのある学生は、使い方の表面で答えがちです。「コード補完で使った」「分からないところを聞いた」と述べたり、「便利なので全部任せた」と中身を説明できなかったりします。「全部書いてもらった」と言うものの、どこを任せ、どこを自分で判断したかの境界を語れないこともあります。

回答は「使ったツール→任せた範囲→自分で判断した範囲→品質保証の方法」の流れで語ると明確になります。たとえば「定型的なコードやテストのひな型はAIに任せ、設計と認証フローは自分で書いた」と境界を示します。理由として「仕様変更時に深く理解していないと修正できない領域だから」と添えましょう。さらに「AIの出力は意図を確認し、ユニットテストで検証してからコミットした」と品質保証まで語ると説得力が増します。

5. 【終盤フェーズ】運用・反省・未来

終盤フェーズでは、運用視点と反省、成長意欲が問われます。10分ほどで、技術の深掘りはほぼ終わっています。より広い視点から、エンジニアとしての姿勢が見られる時間です。

質問9｜実サービスとしてスケールさせるなら、どこを改善するか

この質問で問われるのは、作って終わりではなく運用視点を持っているかです。実務では新規開発より既存システムの保守や改善のほうが多く、ここを語れないと「実務感のない学生」と受け取られる場合もあります。

技術力の高い学生は、用語レベルの一般論で答えがちです。「サーバーを増やす」「DBを分散する」「キャッシュを使う」のように、流行の言葉を並べることがあります。自分のアプリの具体的なボトルネックを特定したうえでの改善案には、なっていません。

回答は「ボトルネック仮説→計測方法→改善案」の流れで語ると説得力が出ます。たとえば「DBクエリがN+1問題でボトルネックになりうる。開発時はORMの発行SQLやクエリログで確認し、本番ではAPMで継続的に計測する。解消にはEager Loadingのほか、ケースに応じてバッチ取得やキャッシュも検討する」のように、自分のアプリの構造を踏まえて答えましょう。

質問10｜もう一度作り直すなら、どこを変えるか

この質問では、学習姿勢と振り返りの力が問われます。エンジニアは作ったあとに振り返り、次に活かす習慣が大切です。過去の自分を客観的に見られるかが、ここで問われています。

スキルのある学生は、抽象的な反省で答えがちです。「コードが汚い部分を直したい」「テストを書きたい」と述べたり、「全部書き直したい」と過剰に自己批判したりします。「特に変えるところはない」と答えて、成長意欲のなさが伝わってしまうこともあります。当時の判断と今の判断の差分が、語られないのです。

回答は「設計・実装・機能」のどのレベルを変えたいかを明確にすると伝わります。当時知らなかった技術や設計パターンを今知っているなら、それを根拠にしましょう。たとえば「当時は状態遷移が追いにくかったが、今なら状態遷移ロジックをuseReducerに集約して見通しを良くし、副作用はuseEffectなどに切り出して責務を分離する」のように具体化できます。

6. スキルのある学生が陥る5つのアンチパターン

ポートフォリオ面接では、スキルのある学生ほど陥りやすい失敗の型があります。技術力が高いがゆえのつまずきが多く、事前に知っておくと避けやすくなります。代表的な5つを見ていきましょう。

1. モダンな技術スタックを並べて満足してしまう

「React・Go・Kubernetes」のような華やかな構成を使っていても、なぜ選んだか、何を実現したかを語れないことがあります。面接官が聞きたいのは技術名のリストではなく、選定の理由です。スタックの新しさそのものは、評価の対象になりにくいといえます。

2. 機能紹介で終わり、設計判断が見えない

「ログイン機能とCRUD機能と通知機能があります」と並べるだけでは、なぜその構成にしたかが伝わりません。面接官が知りたいのは、機能の数ではなく設計の判断です。どんな意図でその構成を選んだのかまで語ると、評価につながります。

3. 未完成のまま大規模なアプリを提出する

「SNSクローンを作ったが、一部の機能は動かない」といった状態は、評価を下げやすい傾向があります。規模の大きさより、最後までやり切ったかどうかが見られるポイントです。小さくても完成させたものの方が、高く評価される場合が多いと考えられます。

4. READMEが薄く、読み手への配慮が伝わらない

リポジトリを送っても、READMEに数行しか書かれていないことがあります。READMEは技術力と同じくらい選考で見られるポイントです。セットアップ手順や設計の意図まで書いておくと、読み手への配慮が伝わります。

5. サマーインターンの自信を本選考に持ち込む

技術評価で手応えを得ると、「技術さえあれば本選考も通る」と考えてしまいがちです。しかし、本選考では人物評価や志望理由、カルチャーフィットが問われます。想定外の質問で固まり、評価を落とす場合もあるでしょう。

対策として、技術以外の質問にも前もって備えておきましょう。志望理由を企業ごとに言語化し、なぜその会社なのかを自分の言葉で説明できるようにします。逆質問もいくつか用意し、面接官との対話を意識すると、人物評価の場面でも落ち着いて臨めるでしょう。

7. ポートフォリオ面接の評価につながりやすくする4ステップ準備法

ポートフォリオ面接の評価は、4つのステップで準備すると上げやすくなります。作品を作り直す必要はありません。最初に説明した評価の4軸（技術力・思考プロセス・コミュニケーション・カルチャーフィット）を意識しながら、すでにある作品を「語れる状態」に整えることがねらいです。順番に進めていきましょう。

ステップ1

最初のステップは、ポートフォリオを「技術設計レビュー資料」として再整理することです。作品を見せる資料ではなく、判断の理由を説明する資料として組み直します。これが、技術力と思考プロセスを面接官に示すための土台になります。

ステップ2

次のステップでは、「結論→課題→技術選定の理由→工夫点→反省」の型を、各質問で示した型の“土台”となる共通フレームとして使います（質問1の「原体験→課題→なぜ自分が」、質問5の「要件→制約→候補→トレードオフ→選択」、質問7のSTAR+Lなど、個別の型はこの共通フレームを質問に合わせて変形したものと捉えると対応づけやすくなります）。

技術力やカルチャーフィットは、思考プロセスを通じて伝わるものです。だからこそ、なぜそう判断したのかを型に沿って整理しておくと、どの質問にも筋の通った説明ができます。

ステップ3

3つ目のステップは、5つのアンチパターンを自分のケースで棚卸しすることです。自分がどの型に陥りやすいかを確認し、当てはまる部分を先に直しておきます。

ステップ4

最後のステップでは、第三者に「技術設計レビュー」として模擬面接をしてもらいます。思考プロセスをうまく整理できても、相手に伝わらなければ評価されません。声に出して説明し、フィードバックをもらうことで、コミュニケーション力を養えます。本番での再現性も高まるでしょう。

8. まとめ

ポートフォリオ面接では、作品の完成度よりも「なぜそう作ったのか」が問われます。技術力・思考プロセス・コミュニケーション・カルチャーフィットの4軸で評価されるため、技術力だけでは総合点が伸びにくいといえます。

冒頭・中盤・終盤の3フェーズで見られるポイントは異なり、それぞれに合った答え方を用意しておくと安心です。型に沿って準備し、アンチパターンを自分のケースで棚卸しすれば、自分の作品を自分の言葉で語れるようになります。

技術力という土台に、思考を言葉にする力を重ねて、サマーインターンの選考に臨みましょう。