面接官はポートフォリオの何を見ているのか【エンジニア就活生向け】
「ポートフォリオを作ったけど、本当にこれで評価されるのかわからない」
「面接官ってどこを見てるんだろう。完成度？コードの量？それともデザイン？」
「一生懸命作ったのに、面接でほとんど聞かれなかった…」
ポートフォリオを用意したエンジニア就活生なら、こんな不安を一度は感じたことがあるはずです。
実は、面接官がポートフォリオで見ているポイントは、多くの就活生が思っている場所とズレていることが多いです。「完成度が高いほど評価される」「技術スタックが多いほど印象がいい」という思い込みが、評価を下げてしまうケースは珍しくありません。
この記事では、エンジニア採用担当者の発信するnoteや採用企業の公式見解・調査など、実際の採用現場に近い一次情報をもとに、面接官がポートフォリオで本当に見ているポイントを解説します。
"完成度"より"語れる"作品を。3ヶ月でオリジナルアプリを開発！
- 受講生数1.2万人突破！満足度は95.5%
- 専属メンターのレビューで"評価される書き方"が身につく
- 面接で「なぜ」に答えられる作品が3ヶ月で完成
目次
前提：面接官はすでに「同じようなポートフォリオ」に飽きている
採用担当者はポートフォリオの「パターン」を知っている
まず最初に、厳しい現実をお伝えします。
IT系企業でエンジニア採用に携わってきた久松剛氏（合同会社エンジニアリングマネージメント代表・慶應義塾大学博士）は、自身のnoteの中で採用担当の目線をこう語っています。
プログラミングスクール卒業者の最終課題がそのまま提出されるケースが非常に多く、結果として以下のような作品で「飽きている」と指摘しています。
エンジニア採用担当者が語る新卒・未経験エンジニアが今作るべき「自主制作物」「ポートフォリオ」｜久松剛 より
- TwitterやInstagramのクローンアプリ
- 某フリマアプリのクローン
- 架空の会社のコーポレートページ
- 「ポートフォリオサイト」という名のLP
これはプログラミングスクール出身者が急増したことで起きた現象です。同氏は「○○スクールを卒業しました、だけだとどのくらいの実力がついているのか、適性があるのかさっぱり分からない」とも述べており、スクール卒業という肩書きだけでは差別化にならない実態が浮かび上がります。
つまり、「作ること」はもはや前提条件です。面接官は「どう作ったか」「何を考えて作ったか」を見ています。
面接官がポートフォリオで本当に見ている3つのこと
採用担当者の声と、採用企業・人材エージェントの見解を複数照合した結果、面接官がポートフォリオで評価しているポイントは一致して以下の3つに収束します。
- 技術力：コードの品質と実装の正確さ
- 構造力：設計・整理する思考力
- 伝達力：他者に伝えるドキュメント能力
それぞれ詳しく見ていきましょう。
技術力：コードの品質と実装の正確さ
面接官が技術力を評価するとき、最初に見るのはコードそのものです。ただし、「どのくらい多くの機能を実装したか」ではなく、「どのくらい丁寧にコードを書いているか」が評価の中心です。
エンジニア採用に特化した社内SEナビの媒体によると、評価の対象となる具体的な指標は以下のようなものです。
- 冗長なコードがなく効率的に書かれているか
- セキュリティ対策が考慮されているか
- 適切なアルゴリズムが選択されているか
- コメントが丁寧に書かれているか
久松氏も、採用担当が見たい素養として「丁寧さ」と「きちんと入れられたコメント」を筆頭に挙げています。コードの「癖」や「工夫の跡」から、候補者の実装力と技術的な成熟度を読み取ろうとしているのです。
また「新しい技術やトレンド技術を取り入れている姿勢」も評価ポイントになります。ただしそれは後述するように、「なぜその技術を選んだか」の説明とセットでなければ意味を持ちません。
構造力：設計・整理する思考力
コードが動くかどうかだけでなく、「どういう設計で作ったか」が面接官には見えています。これは、将来チームで開発するときに「一緒に働けるか」を判断するための重要な軸です。
具体的には、以下の点が評価対象になります。
- フォルダ構成が論理的に整理されているか
- ファイル名・変数名・関数名の命名規則に一貫性があるか
- 各モジュールやコンポーネントの責務が適切に分離されているか
- バージョン管理（Gitのコミット）が適切に残されているか
久松氏も「継続したGitHubへのコミット」を自主制作物に含まれていてほしい要素として明示しています。GitHubの「草の生え具合」つまりコミット頻度を見ることで、継続してプログラミングをしているかどうかを確認しているのです。
コードや構成から一貫した設計方針が読み取れる場合、単に動くものを作るだけでなく、持続可能なシステムを構築する意識があると評価されます。
伝達力：他者に伝えるドキュメント能力
意外と見落とされがちですが、面接官はREADMEやコメントなどのドキュメントにも注目しています。なぜなら、ドキュメンテーション能力はチーム開発において極めて重要なスキルだからです。
評価のポイントは以下の通りです。
- READMEにプロジェクトの目的・使い方・技術構成・起動方法が書かれているか
- 第三者がスムーズに理解・利用できるよう配慮されているか
- コード内のコメントが、複雑なロジックの意図を伝えているか
- コミットメッセージが内容を適切に表しているか
久松氏は「提出物なので見せることを意識したものをお願いしたい」と述べており、テスト用に入力したサンプルデータにも「hoge」「hage」のような雑な文字が残っていることを問題視しています。ポートフォリオは採用担当者に「見せるもの」であるという意識が、細部に表れます。
面接官が「見たくない」ポートフォリオの特徴
評価されるポイントと同様に重要なのが、「評価を下げるポートフォリオ」の特徴です。久松氏が採用担当者として明示的に「見たくない」と述べているものを整理すると、以下のようになります。
面接官が見たくないポートフォリオの特徴は、以下の通りです。
- 教材のコピペ（いわゆる「写経」）をそのまま提出している
- 外部サービスの画像・バナーを無断で使用している（著作権違反）
- フロントエンジニア志望なのにHTML/CSSしかなく、動的な処理がない
- 実際に動くURLが存在しない（デプロイされていない）
教材のコピペをそのまま提出している
プログラミングスクールの最終課題をそのまま提出するケースは、採用担当者にはすぐ見抜かれます。「教材にはない要素を自分で探して組み込めているか」が「自走できるか」の判断基準になっており、オリジナルの要素がないポートフォリオは自走力のない候補者と見なされてしまいます。
実際に動くURLが存在しない
久松氏は「実際に動作するURLをHerokuなどにアップロードしておくのも重要」と明言しています。ソースコードだけ提出してデプロイ（公開）されていない状態では、採用担当者がレビューするコストがかかる上に「本当に動くのか」が確認できません。結果として「かなりの割合で500や404が返ってくるケースが多く、心象がよくない」とも述べています。
面接で必ず聞かれる「なぜ」への答えを準備できているか
ポートフォリオを提出した後、面接では成果物の内容を深掘りされます。このときに最も重要なのが、「なぜそう作ったか」を自分の言葉で語れるかです。
採用担当者が面接でよく投げかける質問は以下の通りです。
- なぜそのプログラミング言語・フレームワークを選んだのですか？
- 他の選択肢と比較してどんなメリット・デメリットを考慮しましたか？
- 最も技術的に苦労した点はどこで、どう解決しましたか？
- もし最初から作り直すとしたら、どこをどう改善しますか？
- リファクタリングは行いましたか？その意図は何ですか？
これらはすべて「成果物の裏にある思考プロセス」を引き出すための質問です。社内SEナビの見解でも「採用担当者が見るべき本質は成果物の裏側にある候補者の思考プロセスや技術的な工夫」と明記されており、完成度より思考プロセスを見られているという点は複数の採用側の声で一致しています。
裏を返せば、どんなにシンプルな作品でも「なぜ作ったか・何を工夫したか・どこで詰まってどう解決したか」を語れる人の方が、多機能なアプリを作ったけど何も説明できない人より評価されます。
評価されるポートフォリオに共通する5つの要素
ここまでの内容を踏まえて、採用担当者から評価されるポートフォリオに共通する要素を整理します。これらは久松氏のnoteおよび複数の採用媒体の見解が一致している部分です。
- フレームワークを使用している
- 条件分岐やロジックが含まれている
- 基本的なDBの操作が実装されている
- GitHubに継続的なコミットがある
- 実際に動くURLが発行されている
フレームワークを使用している
HTML/CSSだけのサイトではなく、Rails・Django・React・Next.jsなどのフレームワークを使った実装が求められます。「フロントエンジニア志望なのにHTML/CSSしかないサイト」はコーディングであってプログラミングとは言い難い、と久松氏は述べています。
条件分岐やロジックが含まれている
「現代のフレームワークにおんぶに抱っこだとDBへのインプットと結果の表示くらいはすぐにできてしまうので論理的思考力をうかがい知ることはできない」という指摘の通り、やや凝った条件分岐などを含めることで論理的思考力が伝わります。
基本的なDBの操作が実装されている
ユーザーデータや投稿データなど、データの作成・取得・更新・削除（CRUD）の操作が実装されているかは基本的な確認ポイントです。
GitHubに継続的なコミットがある
GitHubの「草の生え具合」は、継続的に学習・開発しているかを視覚的に示します。就活のためだけに突貫で作ったのか、日常的にプログラミングをしているのかが一目でわかります。
実際に動くURLが発行されている
Vercel・Render・Railway・Herokuなどのサービスを使ってデプロイし、実際にアクセスできる状態にしておくことは必須です。さらに久松氏は「特に頑張ったソースコードへのリンク」も提示することを推奨しており、「このファイルを見てほしい」という意図を明示することでレビューの解像度が上がります。
「技術スタックの多さ」は評価されない
多くの就活生が誤解している点として、「使った技術が多いほど評価される」という思い込みがあります。しかし採用の現場では、技術選定の理由と目的の一貫性の方がはるかに重要です。
社内SEナビの見解では「話題の技術や複雑なアーキテクチャの採用が、候補者の実力やプロジェクトへの適合性を示すわけではない」と明記されています。小規模なアプリに過度に複雑なマイクロサービスアーキテクチャを採用したり、明らかにオーバースペックなライブラリを導入したりするケースは「技術選定の妥当性に疑問を抱かざるを得ない」とも述べています。
「なぜそのフレームワークを選んだのか」「他の選択肢と比較してどのように判断したのか」を説明できない技術スタックは、むしろマイナスの印象を与えることがあります。1つの技術スタックを深く理解した上で選んだ、という説明ができるポートフォリオの方が評価されます。
ポートフォリオを面接で語るための準備チェックリスト
作品を用意したら、面接前に以下の点を自分で確認しておきましょう。これらは採用担当者が面接で確認しようとしているポイントとほぼ一致します。
- なぜこのアプリを作ろうと思ったか（動機・課題意識）
- なぜこの技術スタックを選んだか（選定理由と比較検討）
- 最も工夫した箇所はどこか（技術的な意思決定）
- 開発中に最も苦労したことは何か（問題解決のプロセス）
- 振り返って改善したい点はあるか（自己評価・成長意欲）
- 実際に動くURLはあるか（デプロイの完了）
- GitHubのREADMEは第三者が読めるレベルか（伝達力）
これらすべてに自分の言葉で答えられる状態になっていれば、面接官の「なぜ」に動じることなく答えられます。
【就活に使えるポートフォリオを作るなら】GeekSalonへ
「ポートフォリオを作りたいけど、何を作ればいいか決まらない」
「作り始めたけど、評価される水準かどうかわからなくて不安」
そんな方には、大学生限定プログラミングスクール GeekSalon（ギークサロン） がオススメです。
GeekSalonでは、3ヶ月でゼロからオリジナルアプリを完成させるカリキュラムが用意されており、卒業制作として作った作品はそのまま就活のポートフォリオとして活用できます。専属メンターが「なぜこう実装したか」を言語化する手助けも行うため、面接で語れる作品に仕上がります。
受講生数は1.2万人を突破、満足度は95.5%、継続率は約80%。気になった方は、毎日開催している無料説明会にお喋り感覚で参加してみてください！
"完成度"より"語れる"作品を。3ヶ月でオリジナルアプリを開発！
- 受講生数1.2万人突破！満足度は95.5%
- 専属メンターのレビューで"評価される書き方"が身につく
- 面接で「なぜ」に答えられる作品が3ヶ月で完成
まとめ｜面接官はポートフォリオの「裏側」を見ている
この記事で取り上げた採用担当者・採用媒体の声をまとめると、面接官がポートフォリオで見ているのは一貫して同じことです。
- 完成度や機能の多さではなく、コードの丁寧さ・思考の跡
- 技術スタックの多さではなく、選んだ理由の一貫性と妥当性
- 作品の派手さではなく、GitHubのコミット履歴・READMEの丁寧さ
- 成果物そのものではなく、「なぜ作ったか」を語れるか
- デプロイされていない作品は、実質的に評価の土俵に立てない
エンジニア就活においてポートフォリオは、「あなたがどんな思考でコードを書く人間か」を伝えるための最も強力なコミュニケーションツールです。完璧な作品より、「自分の言葉で語れる作品」を1つ仕上げることが、就活を有利に進める最短ルートです。
