ポートフォリオは「作って終わり」ではなく、面接官に意思決定の背景と実装力を同時に伝えるための資料だ。豪華な見た目よりも、コードとREADME、技術選定の説明、運用を前提とした設計のほうが評価されやすい。本記事では、実際に見られる観点と最低限整えるべき構成を解説する。
面接官が最初に見るのは「動くかどうか」ではない
採用側は短時間で多くの候補者を評価する必要があるため、最初に見るのはREADMEとリポジトリの構成だ。どれだけ機能が豊富でも、セットアップ手順が書かれていなかったり、README冒頭で「何のアプリか」がすぐにわからないと、次の画面へ進んでもらえないこともある。
dodaやレバテックの公開コラムでも、エンジニアのポートフォリオ評価の第一印象は「1分で概要が掴めるかどうか」で決まる傾向が示唆されている。つまりREADMEは「読み物」ではなく「ダッシュボード」として設計するべき資料と捉えたい。
READMEに最低限書くべき要素
ポートフォリオのREADMEには、以下の要素を順に並べるとスキャンしやすい。
- プロジェクト概要：何を解決するアプリか、1〜2行で
- デモURLとスクリーンショット：動作イメージが即座に伝わるように
- 技術スタック：言語・フレームワーク・DB・インフラ
- アーキテクチャ図：構成の全体像（シンプルなもので可）
- 技術選定の理由：なぜその技術を選んだか
- 工夫した点と、今後改善したい点
- セットアップ手順：cloneからローカル起動まで
とくに「技術選定の理由」と「改善したい点」は差がつきやすい項目だ。学んだばかりのフレームワークを「流行っているから」と採用するのではなく、「要件と他選択肢を比較した上での採用理由」まで言葉にできると、実務に入った後の判断力を感じさせる。
コミット履歴とブランチ戦略も見られている
評価者の中には、コミットログを遡って作業の粒度とコミットメッセージの品質を確認する人もいる。1回のコミットで数百行を詰め込み、メッセージが「update」「fix」だけだと、実務レベルでの履歴管理への感度が低いと判断されかねない。
最低限、以下のような運用ができているかを振り返っておきたい。
- コミットが機能単位・修正単位に分割されている
- メッセージが「何を」「なぜ」変えたかを短く示している
- mainへの直pushではなく、ブランチ＋プルリクエストで運用されている
- 不要なファイル（.DS_Store、node_modulesなど）が.gitignoreされている
個人開発でプルリクエストを出す必要は必ずしもないが、「自分で自分にレビューコメントをつけたPR」が残っていると、セルフレビューの習慣が伝わりやすい。
デプロイと運用：動くものをURLで見せる
ローカルでしか動かないアプリは、面接官にとって評価コストが高くなる。VercelやCloud Run、Fly.ioなど無料・低コストで公開できる手段が整っている今、「URLを踏めば動く状態」を用意しておくことは事実上の必須要件になりつつある。
デプロイまで済ませておくと、以下の観点でも自然に加点される。
- 環境変数の扱いを理解しているか
- 本番環境と開発環境を分けて考えられているか
- エラー時の表示やログに配慮しているか
- 独自ドメインやHTTPSの設定経験があるか
さらにCI（GitHub ActionsでのLint・テスト実行）が組まれていると、実務での品質担保意識が伝わる。作品そのものの機能数よりも、運用を前提とした設計ができているかのほうが、転職市場では評価されやすい領域だ。
題材選び：規模より「課題設定」で差をつける
ポートフォリオは大作である必要はない。むしろ、身近な課題を自分の視点で切り取っているかのほうが印象に残る。SNSクローンやECサイトは題材として多すぎるため、差別化に工夫が必要だ。
以下のような観点で題材を選ぶと、語れる材料が増える。
- 自分や家族、チームの実課題を解くために作ったもの
- 既存サービスの不満から着想し、独自の切り口を加えたもの
- 特定技術（リアルタイム通信、全文検索、決済など）の学習を目的に据えたもの
面接官は「何を作ったか」よりも「なぜそれを作ろうと思ったか」「どう意思決定したか」を深掘りしてくる。題材の段階から説明可能性を意識しておきたい。
まとめ
- READMEは「読み物」ではなく「1分で概要が掴めるダッシュボード」として設計する。
- 技術選定の理由と改善したい点を言語化できているかで、実務レベルの差が見える。
- コミット履歴・ブランチ運用・.gitignoreなど、履歴の扱いも評価対象。
- URLを踏めば動く状態まで整えると、運用前提の設計力が伝わりやすい。
（本記事は一般的な市場情報をもとにした編集部の見解です）
