関連記事：プログラミングスクール選びで失敗しない5つの基準もあわせてご覧ください。
未経験からエンジニア転職を目指すうえで、ポートフォリオは書類選考を突破する最大の武器です。履歴書・職務経歴書だけでは伝わらない実装力・思考力を示せるのがポートフォリオの役割。
この記事では、採用担当者が実際にチェックしている観点と、制作手順を実務水準で解説します。
採用担当がポートフォリオで見る6つのポイント
1｜コードの可読性
- 命名規則の一貫性
- 関数・コンポーネントの適切な粒度
- コメント・ドキュメントの質
- Linter / Formatterの設定
2｜機能の実装難易度
- CRUD以上の機能があるか（認証・検索・通知・決済等）
- 非同期処理・API連携の有無
- 状態管理の設計
3｜アーキテクチャ設計
- ディレクトリ構造の整理
- 責務分離（フロント／バックエンド／DB）
- 再利用可能なコンポーネント設計
4｜技術選定の妥当性
- モダンな技術スタックか
- 技術選定の理由を説明できるか
5｜運用・デプロイ
- Gitのコミット履歴（意味のある単位）
- CI/CDの設定
- デプロイ環境（Vercel / AWS 等）
6｜開発ストーリー
- なぜこのアプリを作ったか
- 直面した課題とその解決法
- 改善の余地をどう認識しているか
ポートフォリオ制作の5ステップ
ステップ1｜テーマ選定
採用担当者の目に留まりやすいテーマの特徴：
- 自分や身近な人の課題を解決するもの
- 実際に使われる可能性がある実用的なアプリ
- CRUD以上の機能を含む（単純な掲示板は避ける）
避けるべきテーマ
- Todoアプリ・ブログ（ありふれ過ぎ、差別化困難）
- チュートリアル完全模倣作品
- ユースケースが想像しにくい実験的作品
おすすめテーマ例
- 趣味・副業の管理アプリ（読書記録、筋トレ記録、家計簿等）
- 業界特化型マッチングサービス
- 学習履歴の可視化ツール
- 地域情報のキュレーションサイト
ステップ2｜要件定義と設計
制作前に以下をドキュメント化：
- 誰のどんな課題を解決するか（ペルソナ＋ユースケース）
- 必須機能・あれば嬉しい機能を明文化
- 画面遷移図（Figma等で作成）
- DB設計図（ER図）
- API設計（エンドポイント一覧）
設計ドキュメントをREADMEに含めると、思考プロセスをアピールできます。
ステップ3｜技術選定
Web系フロントエンド志望の典型例
- 言語：TypeScript
- フレームワーク：React（Next.js）または Vue（Nuxt）
- スタイリング：Tailwind CSS / CSS Modules
- 状態管理：Zustand / Redux Toolkit
- テスト：Jest / Vitest / Playwright
バックエンド志望の典型例
- 言語：Ruby（Rails）、Python（Django/FastAPI）、Node.js（Express/NestJS）、Go
- DB：PostgreSQL / MySQL
- 認証：JWT / OAuth / セッション
- テスト：RSpec / pytest / Jest
インフラ
- デプロイ：Vercel / Render / AWS (ECS, EC2, Amplify)
- CI/CD：GitHub Actions
- コンテナ：Docker
- モニタリング：Sentry等
ステップ4｜実装と運用
Gitの使い方
- ブランチ戦略：main + feature ブランチ
- コミット単位：機能／修正／リファクタを分けて
- プルリクエスト：機能単位で作成、自己レビューを記述
- コミットメッセージはConventional Commits（feat:, fix: 等）を推奨
コード品質
- ESLint / Prettier（フロント）
- RuboCop / Black（バック）
- テストコード：最低限ユニットテストを入れる
- 型定義：TypeScript利用なら型を厳密に
ステップ5｜デプロイとドキュメント化
デプロイ
- 必ず動作するURLを用意（採用担当者がコードを読まなくても触れる）
- ログイン必須機能がある場合、テストアカウントを明記
- データベースは本番環境で動作する設計に（SQLite→PostgreSQL等）
README記載項目
# プロジェクト名
## 概要・ペルソナ・解決する課題
## 使用技術スタック（バッジ推奨）
## 主要機能一覧
## 画面キャプチャ / デモGIF
## 設計ドキュメントへのリンク（ER図・画面遷移図）
## インストール手順
## ディレクトリ構成
## 今後の改善予定
## 直面した技術的課題とその解決法
複数ポートフォリオ戦略
単一の大型ポートフォリオより、複数の作品で幅を見せる戦略も有効です。
推奨構成
- メイン作品（実用的なWebアプリ、2〜3ヶ月工数）
- 技術深掘り作品（特定技術の習得成果、1〜2週間）
- ミニ作品（APIラッパー、拡張機能等、数日）
自己紹介ポータルサイトを作る
上記を1つのポータル（自分のプロフィールサイト）に集約すると、企業側が全体像を把握しやすいです。Next.js + Vercel で簡単に作れます。
採用担当に刺さるREADMEのコツ
Before（NG例）
## 使用技術
React, Node.js, MongoDB
After（改善例）
## 使用技術スタック
- フロントエンド: Next.js 14 (App Router), TypeScript, Tailwind CSS
- 状態管理: Zustand
- バックエンド: Node.js 20, Express, Prisma
- データベース: PostgreSQL (Supabase)
- 認証: NextAuth.js (Google OAuth)
- インフラ: Vercel (フロント) + Fly.io (バック)
- CI/CD: GitHub Actions (テスト→デプロイ自動化)
## 技術選定の理由
- Next.js App Routerを採用し、Server Componentsで初期表示を高速化
- 認証はGoogle OAuthのみに絞り実装コストを抑制
- デプロイ先はフロントとバックで分離し、料金とパフォーマンスを最適化
やりがちな7つの失敗
失敗1｜チュートリアルを完全模倣
「〇〇で作るTodoアプリ」を丸写しはNG。オリジナル要素を20%以上加えましょう。
失敗2｜README未整備
READMEが薄いとコードを読んでもらえない。プロジェクト顔であることを意識。
失敗3｜デプロイされていない
GitHubリンクのみで実際に触れないと評価が下がる。必ずデプロイすること。
失敗4｜コミット履歴が雑
「update」「fix」だけのコミットメッセージは印象が悪い。意味のあるメッセージを残す。
失敗5｜テストゼロ
最低限のテストコードがあるだけで評価が上がります。
失敗6｜レスポンシブ未対応
採用担当者はスマホから確認することも多い。モバイル表示も必ず動作確認。
失敗7｜機能を盛り込みすぎ
深く作り込まれたコア機能のほうが、浅い機能を10個並べるより評価されます。
制作期間と工数の目安
| フェーズ | 所要日数 |
|---|---|
| テーマ選定・要件定義 | 3〜7日 |
| 画面遷移図・DB設計 | 5〜10日 |
| 実装（機能開発） | 40〜60日 |
| テスト・デプロイ・CI設定 | 7〜10日 |
| README・ポートフォリオサイト | 5〜7日 |
| 合計 | 約2〜3ヶ月 |
よくある質問
Q. ポートフォリオは何個必要ですか？
メイン作品1つ＋小規模作品2〜3個が理想。メイン作品に時間をかけるのが優先です。
Q. 既存のサービスを模倣して作ってもいいですか？
一部機能を参考にするのは問題ありませんが、オリジナルの改良点や独自機能を加えることが重要です。
Q. GitHubのスター数は重要ですか？
必須ではありませんが、あると目を引きやすいです。採用担当者が重視するのはコードの質とコミット履歴です。
Q. ポートフォリオの内容と応募先企業の技術スタックは合わせるべきですか？
可能であれば合わせるのが有利。Ruby on Rails中心の会社に応募するなら、Rails作品を用意すると親和性が伝わります。
Q. ポートフォリオ公開後、どこに載せれば目立ちますか？
- GitHub のREADMEトップ
- 自分のポートフォリオサイト（独自ドメイン＋Vercel等）
- 職務経歴書の「成果物」欄
- LinkedIn / Wantedly / Green のプロフィール