本選考に向けてポートフォリオを見直そう！やりがちな失敗から見るチェックポイント

• サマーインターンと本選考で変わる評価軸

• 本選考でやりがちなポートフォリオの失敗4つ

• リファクタリングの全体像

• 【土台】まず「見てもらえるポートフォリオ」にする

• ①READMEで設計思想を示す

• ②ハッカソンやインターンの経験でチーム貢献をアピールする

• ③実務適性を示すためにやっておきたい配慮

• ④AIで書いたコードの説明責任を果たす

• 本選考前・最終チェックリスト

• まとめ

サマーインターンと本選考で変わる評価軸

まず、サマーインターンと本選考で「ポートフォリオの何が見られているか」を確認しておきましょう。

サマーインターンの選考と本選考で「同じ成果物なのに、なぜか評価されない」という壁にぶつかる理由は、ポートフォリオで評価される観点が変わるからです。サマーでは「動くコードが書けるか」という実装力が中心でした。本選考では、その先の「なぜそう作ったか」や「チームでどう貢献できるか」まで見られるようになります。

このように評価軸が変わるのは、本選考がサマーインターンとは違い採用の可否を判断する場だからです。技術力が十分なだけでなく、自社に馴染んで働き続けてくれるか、ミスマッチで早期離職しないかを慎重に判断しているといえます。

そのため、単に技術力を示すだけではなく、企業のチームやカルチャーにフィットすることをポートフォリオでも示す必要があるのです。

本選考でやりがちなポートフォリオの失敗4つ

本選考でやりがちなポートフォリオの失敗を把握しておくことで、どのように対策すべきかが見えてきます。次の4つのうち、当てはまりそうなものがないかチェックしてみましょう。

① 技術選定の理由を答えられない

モダンな技術を使ったアプリが、サマーでは高く評価されることがあります。その成功体験のまま本選考に臨むと、思わぬ深掘りで答えに詰まってしまうかもしれません。たとえば「なぜNext.jsを選んだのですか」「どのページを、なぜSSR／SSG／CSRで出し分けたのですか」と問われたとき、「流行っていたから」「勉強したかったから」としか言えず、答えに詰まってしまいます。

② チームでの貢献が見えない

ハッカソンやインターンの成果物を、チームのリポジトリへのリンクだけで載せている場合があります。面接官が見たいのは「チームが何を作ったか」ではなく、「あなたが何を書き、どの課題をどう解決したか」です。課題解決の過程が書かれていなければ、チームにどのように貢献できる学生なのかが分からないでしょう。

③ AIで書いたコードを説明できない

ChatGPTやCopilotを使い、短時間でポートフォリオを作る人は珍しくありません。ところが本選考の技術面接では、画面共有して特定のコードについて質問されることがあります。生成されたコードの構造や挙動を自分の言葉で説明できないと、自分の理解が相手に伝わらないまま終わってしまいます。

④ READMEがチーム開発で通用する水準に達していない

GitHubを単なるコード置き場としており、READMEが技術名の箇条書きで終わっている状態です。企業は「他の人がこのリポジトリをCloneして動かせるか」を通じて、実務への適性があるかを見ています。READMEが不十分だと、チームで働くときの配慮が伝わりにくくなります。

リファクタリングの全体像

リファクタリングを進めていくには、まず「見てもらう」ための土台作りを行い、次に思考やチーム貢献をアピールするためのブラッシュアップを行いましょう。

採用担当者は、本選考になると何百・何千もの応募に目を通さなければなりません。一人ひとりのESやポートフォリオを見れるのは、忙しい業務の合間です。読みにくい資料はそれだけで確認に時間がかかりますし、読んでもしっかりと理解できない可能性があります。だからこそ、まず「見てもらえる土台」を固める必要があります。

土台が整ってはじめて、設計や貢献を正確に評価できる段階になります。そのうえで、設計思想やチームへの貢献が伝わるポートフォリオを作りこみましょう。具体的な見直しのポイントと方法は次の章から解説していきます。

【土台】まず「見てもらえるポートフォリオ」にする

限られた時間でポートフォリオを見てもらうには、最初の数十秒で「見る価値がある」と伝わることが重要です。ここで足切りされないための基準が、以下の3点です。

すぐ触れる状態にする

• ・デプロイして、他の人がすぐ操作できる状態にする

• ・ログインが必要なら、テストアカウントのログイン情報をREADMEに書く

• ・成果物は複数デプロイし、コミットの履歴で継続を示す

特にテストアカウントの記載漏れは、起こりがちです。採用担当や面接官がアプリを動かせないまま終わると、その成果物を見てもらう機会を逃してしまいます。忘れずに記載しておきましょう。

READMEの冒頭に要点を置く

忙しい相手がすぐにポートフォリオの概要を理解し動かせるよう、最初の数行で「何を解決するアプリか」「どう動かすか」が分かる状態にします。

コードの可読性を上げる

レバテックルーキーが採用支援をする中で、採用を行うエンジニアからいただく最も多いポートフォリオの指摘は可読性です。次の点を見直しましょう。

• ・インデントやスペースを揃える（指摘として最も多い）

• ・命名規則に一貫性を持たせる

• ・コピペを減らし、共通処理は関数にまとめる

• ・マジックナンバーをなくし、意図をコメントで補う

命名を例にすると、違いは次のとおりです。

OK例は、関数名を読むだけで「IDからユーザーを取得する」と分かります。読み手が中身を追わずに理解できる状態が、可読性の高いコードです。

見てもらえるポートフォリオと見落とされるポートフォリオの違い

最後に、ポートフォリオ全体の印象を分ける違いをまとめました。

①READMEで設計思想を示す

土台が整ったら、READMEを「設計プロセスが読めるドキュメント」へブラッシュアップしましょう。機能紹介で終わらせず、次の5項目を書き加えるのがおすすめです。

1. 解決したかった課題

何を作ったかの前に、なぜ作ったかを書きます。「締め切りを忘れがちな学生の課題を解決したい」のように、ユーザーやビジネスの視点で書くと、開発の目的が伝わります。小さくても、自分の課題意識から生まれた独自性をアピールしましょう。

2. 技術選定のロジック

使った技術をただ並べるのではなく、なぜそれを選んだかと、見送った代替案まで書きます。

この一段が、面接での「なぜ？」に自分の言葉で答える準備になります。

3. システム構成図・ディレクトリ構成

全体像を図で示し、主要なディレクトリの役割を短く説明します。設計を俯瞰できる人だと伝わるでしょう。

4. こだわった技術的アプローチ

パフォーマンス改善、テストコード、CI/CDなど、実務で工夫したポイントを書きましょう。「一覧取得のN+1問題をDebugbar等で検知し、Eager Loading（with()）で発行クエリを101本→2本に削減、表示を約800ms→約120msに短縮した」のように、検知手段・対処・定量結果をセットで書くと説得力が出ます。

5. 運用の痕跡・今後の改善案

デプロイして終わりにせず、使ってもらって得た気づきと、修正の記録を残します。「知人5人に使ってもらい、通知機能の要望が多かったため追加した」のように、改善を回した跡が、実務適性の証拠になります。

5項目をまとめると、READMEの骨組みは次のようになります。

②ハッカソンやインターンの経験でチーム貢献をアピールする

ハッカソンやインターンの成果は、チームのリンクだけで終わらせないようにしましょう。自分が何をしたかを、READMEとGitの履歴で見えるようにします。

• ・担当した機能やレイヤーを明記する（例：認証機能とAPI設計を担当）

• ・自分のPRやコミットへのリンクを置く

• ・直面した技術的・組織的な課題と、その解決を書く

• ・コミット履歴で、自分の貢献を裏づける

READMEに、次のような記述を足すと分かりやすくなります。

「チームで何を作ったか」ではなく「自分がどこで価値を出したか」が一目で分かると、自分自身の実力として伝わります。

③実務適性を示すためにやっておきたい配慮

可読性に加えて、「他の人がすぐ動かせるか」も、実務への適性として見られます。チームで成果を出せると示すための基準になります。

• ・Linterやフォーマッターを設定し、コード規約を自動でそろえる

• ・コミットを意味のある粒度に分け、メッセージで変更意図が読める

• ・Dockerなどで、環境構築を一発起動できるようにする

• ・テストコードを用意する

• ・CI（GitHub Actions等でpush時にLint・テストを自動実行）を最低限回す

• ・READMEにセットアップ手順と動作環境を書く

コミットの粒度は、次のような違いです。

NG：「fix」「更新」だけのメッセージが並ぶ

OK：「認証エラー時のメッセージを追加」「一覧APIのN+1を解消」など、意図が読める

環境構築は、READMEを見た人が数コマンドで動かせると理想的です。

この一発起動ができると、面接官が数分でアプリを動かせます。環境構築でつまずかせない配慮が、チーム開発への適性として評価されます。

④AIで書いたコードの説明責任を果たす

AIを使った開発は今や当たり前になりつつあり、使用自体をとがめられることはありません。採用において問題になるのは、使ったこと自体ではなく、中身を説明できないことです。本選考の技術面接では、コードを1行ずつ確認されることも想定して備えましょう。

• ・自分のコードを開き、「これは何をしているか」を声に出して説明できるか確認する

• ・AIが選んだ設計や書き方について、なぜこの設計になっているのかを自分で調べ直して言語化する

• ・理解が曖昧な箇所は、書き換えるか、動作を追って理解を埋める

たとえば「なぜここでキャッシュを使っているのですか」と聞かれたとしましょう。そのとき「計算コストが高く、同じ入力なら結果が一定（決定的）なのでキャッシュしています。入力（条件）が変わったらキャッシュを破棄し、変わらない場合もTTL（有効期限）で一定時間後に再計算する設計です」と答えられる状態を目指します。AIを使いこなしつつ、判断を自分でできる人だと示せるでしょう。

AIの制御が見られることもある

AIを前提とした開発で「AIをどう制御しているか」を見る面接官も増えています。ただ生成させるのではなく、ルールを決めて使いこなせているか、という観点です。次のような工夫を、ポートフォリオに残しておきましょう。

• ・AGENTS.md などのルールファイルに、AIへの指示やコーディング規約、守らせたい制約を書いておく

• ・AIが生成したコードを、レビューやテストで検証する流れを用意する

• ・どこまでAIに任せ、どこを自分で判断したかを、READMEやコミットで説明できるようにする

たとえばAGENTS.mdに、コーディング規約などのルールを書いておくと、AIの出力を一定の品質に保てます。こうした制御の工夫があると、AIと協働しながら品質に責任を持てる人だと伝わります。

本選考前・最終チェックリスト

ここまで解説したポイントを、提出前に確認できるチェックリストにまとめました。自分のポートフォリオを開いて、一つずつチェックしてみましょう。

見てもらえる状態になっているか（土台）

• ・デプロイして他の人がすぐ操作できる／テストアカウントを記載した

• ・READMEの冒頭で「何を解決するか」「どう動かすか」が分かる

• ・インデント、命名、コメントを見直し、可読性を上げた

• ・成果物が複数あり、コミット履歴で継続を示せている

設計思想やチーム貢献をアピールできているか

• ・READMEに技術選定の理由と見送った代替案を書いた

• ・システム構成図とディレクトリの役割を示した

• ・こだわった技術的アプローチを課題と効果のセットで書いた

• ・運用の痕跡と、今後の改善案を残した

• ・チーム開発では自分の担当、PR、解決した課題を明記した

• ・Linter、Docker、テスト、CIで他者が動かせる再現性を整えた

• ・コードを1行ずつ自分の言葉で説明できる

まとめ

サマーインターン選考と本選考では評価基準が異なり、本選考では実装力だけでなく「なぜそう作ったか」という設計思想や「チームにどう貢献できるか」といった実務適性が重視されます。

評価されるポートフォリオにするには、すぐに動かせるデプロイ環境やテストアカウントの明記、可読性の高いコード整理といった土台作りが不可欠です。その上で、READMEに技術選定の理由や見送った代替案、チームでの具体的な自分の役割と課題解決のプロセスを記述します。また、AIで出力したコードも含め、1行ずつの構造や選定意図を自分の言葉で説明できる状態を整えることが重要です。

ITエンジニアを目指す新卒学生向け就活エージェントならレバテックルーキー

レバテックルーキーは、レバテックが運営するITエンジニア専門の就活エージェントです。多数のITエンジニアのキャリア支援経験のあるアドバイザーが、あなたのスキルと希望に合わせた企業の紹介から、人事目線での面接対策など、就職までを一貫してサポートします。ES添削、面接対策、ポートフォリオ作成サポートなども実施していますので、まずは一度カウンセリングにお越しください。

就活アドバイザーに相談してみる