現役エンジニアのための
ポートフォリオの作り方｜採用担当が見ている5つの軸と2026年版テックスタック
ポートフォリオで採用担当者が見ているのは「何を作ったか」ではない。「どう作ったか」と「なぜその技術を選んだか」だ。コード行数や派手な機能ではなく、要件定義から運用までの一連の意思決定が評価対象になる。
この記事では、未経験・現役エンジニアの両方を対象に、採用評価の実際の軸、2026年時点で選ぶべき技術スタック、README の書き方、6ステップの制作プロセス、そしてやってはいけないアンチパターンまでを実務目線でまとめた。
TABLE OF CONTENTS
なぜ現役エンジニアにもポートフォリオが必要なのか
「実務経験があるのだから職務経歴書で十分」と考える現役エンジニアは少なくない。しかし2026年の採用市場では、経験者ポジションでもポートフォリオ提出を求められるケースが増えている。理由は3つある。
- NDAで業務コードを見せられないため、技術力を可視化する手段が他に存在しない
- ジョブ型雇用への移行に伴い、職能の証明責任が応募者側に移っている
- 採用担当者の選考時間が短い。書類だけでは差別化できず、リンク1つ送れる準備があるかで通過率が変わる
特にWeb系・自社開発企業では「実際に作れるかどうか」が重視される傾向が強く、書類選考の段階で GitHub プロフィールに目を通す担当者が大半を占める。プライベートリポジトリでも構わないが、説明可能な状態にしておくことは現役にとっても必須となっている。
採用担当者がポートフォリオを見る平均時間は数分〜十数分程度というデータが各種転職メディアで共通して指摘されている。「とりあえず作った」ではなく、最初の30秒で価値が伝わる設計が必要。READMEの冒頭1〜2行と、トップページのファーストビューが勝負どころになる。
採用担当者が見ている5つの評価軸
各種転職エージェントの解説と現場の採用担当の発言を整理すると、評価軸は概ね次の5つに集約される。コード量や派手な機能は副次的で、軸はあくまで「思考プロセスの可視化」にある。
| 評価軸 | 具体的に見られていること |
|---|---|
| 課題設定 | 誰のどんな課題を解くのか。技術ありきではなくユーザー価値起点で語れるか。 |
| 技術選定の合理性 | なぜこの言語/フレームワークを選んだか。代替候補と比較した上での意思決定があるか。 |
| 設計と実装 | ディレクトリ構成、命名、責務分離、テスト。コードを読む価値があるか。 |
| 運用・改善 | デプロイ環境、CI/CD、ログ、エラー監視。「動く」止まりではなく「動かし続ける」想定があるか。 |
| 継続性 | commit 履歴に「考えながら作った」痕跡があるか。一発リリースで放置されていないか。 |
このうち、現役エンジニアと未経験者で最も差が出るのは「運用・改善」の軸だ。テストが書かれている、CIが回っている、エラーログが取れる、デプロイが自動化されている——こうした業務寄りの要素は、未経験者には出しづらく、経験者にとっては最も差別化しやすい。
未経験者と経験者で「求められる水準」はどう違うか
同じ「ポートフォリオ」という言葉でも、未経験と経験者では評価軸の重みが大きく違う。両方を意識すると焦点がぼやけるので、自分のポジションに合わせて作り込み方を変えるべきだ。
| 観点 | 未経験〜実務1年未満 | 実務2〜5年 | 実務5年〜/SR以上 |
|---|---|---|---|
| 主目的 | 自走力の証明 | 専門領域の証明 | 設計判断と影響範囲の証明 |
| 推奨規模 | 中規模1本＋小物2〜3本 | テーマ特化型1本 | OSS貢献／設計記事＋小規模デモ |
| 必須要素 | 要件→実装→改善のサイクル | テスト・CI/CD | 意思決定の記録（ADR等） |
| NG例 | チュートリアル丸写し | 機能だけ多い・テスト無し | 技術選定の説明が無い |
未経験者が最低限おさえるべき水準
未経験者の場合、規模より「要件を自分で立てて、設計して、実装して、振り返って改善した」一連のサイクルが回せていることが最優先。Railsチュートリアルや教材の改変止まりだと、たとえ動いていても評価されにくい。
1本は「自分が解きたい身近な課題」をテーマに据え、3週間〜2ヶ月かけて作り込むのが目安。GitHubの commit 履歴が学習プロセスごと見られるので、毎日少しずつでも積み上げると説得力が出る。
経験者が抑えるべきポイント
経験者は「業務で何ができるか」を、業務コードを見せずに証明する必要がある。ここで効くのが「テーマ特化型」のポートフォリオだ。例えば「自分はバックエンドで認証基盤に強い」と言いたければ、認証だけに特化した最小のSaaS基盤を作って、設計判断を README に書く。雑食的に作るより、深掘りした方が信号として強い。
関連トピックとして、面接でポートフォリオが評価されるかは応募先の選び方にも左右される。エージェント比較の観点はエンジニア向け転職エージェント7選を機能比較で整理している。
ポートフォリオが固まったら、評価してくれる場に出す
制作物の評価軸は応募先で大きく変わる。スカウト型・エージェント併用で「自分のポートフォリオを正しく読める担当者」に届けることで、選考通過率は明確に上がる。
エンジニア向け転職サービスを見る2026年版・技術スタックの選び方
「何で作るか」は、評価軸でいうと技術選定の合理性に直結する。流行りに乗ること自体は問題ない。問題は「なぜそれを選んだか」を説明できないことだ。以下は2026年5月時点で、現場で実際に使われている技術と、ポートフォリオで採用するときの注意点を整理したものだ。
フロントエンド
- Next.js (App Router)：2026年時点でWeb系自社開発の事実上の標準。SSR/SSG/RSCの使い分けを README で説明できれば強い
- Remix / TanStack Start：Next.js一強への代替として浮上。実装意図を明確に書ければ差別化になる
- SvelteKit：「軽量さ」「DXの良さ」を軸にした選定理由が説明できれば良い選択肢
バックエンド
- Go：マイクロサービス・APIサーバー文脈で評価が高い。型と並行処理を生かした設計が見せられる
- Node.js (Hono / Fastify)：フロントとの統一感を狙うならアリ。Expressは2026年現在では「古い」印象を与えやすい
- Ruby on Rails：「素早く作れる」点は今でも強い。スタートアップ志望なら通用する
- Python (FastAPI)：AI/ML文脈を絡める場合の最有力。SaaS基盤としてもアリ
インフラ・運用
- Vercel / Cloudflare Workers：個人開発でも本番運用しやすい。コスト管理の意思決定を書けると評価される
- AWS (ECS/Lambda)：実務寄りの環境を再現したい場合の本命。コストとセットで語ること
- Docker + GitHub Actions：CI/CDが回っているだけで「運用視点がある人」と判断されやすい
「新しい技術を使ったから評価される」のではなく、「なぜそれを選んだかを説明できるから評価される」。LLM/RAG、エッジコンピューティング、tRPC など2026年のトレンドを取り入れても、選定理由が「触ってみたかったから」止まりだと加点にならない。
ポートフォリオに必要な構成要素
ポートフォリオサイト（自己紹介ページ）と、リポジトリ（個別の制作物）の2層構造で考える。自己紹介ページは1枚で完結させ、各制作物の詳細はGitHubリポジトリに任せる、というのが最もコスパが良い。
自己紹介ページ（1ページ完結）
- 名前と連絡先：本名 or 一貫したハンドルネーム、メール、SNS、GitHubアイコン
- 得意領域の1行サマリー：「Goでバックエンド」など30文字以内
- 技術スタック：言語/フレームワーク/クラウド/DBをカテゴリ別に
- 制作物のショーケース：3〜5本、各々サムネ＋一言説明＋詳細リンク
- 職歴・学習歴：時系列。期間と役割を明示
- 外部発信：Zenn/Qiita/X、登壇歴、OSSコントリビュート
個別リポジトリ（制作物ごと）
- READMEの先頭に「誰のどんな課題を、どう解いたか」
- デモURL or スクリーンショット（GIF推奨）
- 技術選定の理由と代替候補との比較
- ER図/アーキ図/シーケンス図（Mermaid推奨）
- 環境構築手順（README通りに動くこと）
- テストカバレッジバッジ・CIバッジ
- 今後の改善計画 or 開発日誌
GitHub README で差をつける書き方
採用担当者がリポジトリを開いて最初に見るのは README だ。コードを細かく読む時間はないので、READMEの質がそのまま評価になる。テンプレ的な構成でも、書き込み方で大きく差がつく。
READMEで最も多い失敗は「動かし方の手順だけ書いて、なぜ作ったかが書いていない」パターン。動作手順は二の次で構わない。最初の3スクロール分に「課題」「技術選定」「工夫したポイント」が入っているかを確認すること。
6ステップで作るポートフォリオ制作プロセス
「何から始めればいいか分からない」を解消するために、実際にゼロから作る場合の手順を6ステップにまとめた。所要期間は中規模1本で3週間〜2ヶ月が現実的なライン。
Step 1：テーマ選定（2〜3日）
自分が解きたい課題を3つ書き出し、「実装規模」「技術的に伸ばしたい領域」「採用ターゲットの志望度」の3軸で点数化する。ユーザーが自分1人でも構わない。重要なのは「自分が継続して触りたくなる」テーマであること。
Step 2：要件定義と設計（3〜5日）
機能リストを作り、優先度をMust/Should/Could/Won'tでMoSCoW分類する。データモデルをER図に、画面遷移を簡単なワイヤーフレームに落とす。この段階で「最初にリリースする最小スコープ」を決めること。完璧を目指すと永遠に終わらない。
Step 3：技術選定とリポジトリ準備（1〜2日）
使う技術を決め、READMEのスケルトンを先に書く。「なぜこの技術にしたか」を最初に書ききっておくと、開発中もブレない。.gitignore、CI設定、テスト設定、Lint/Formatterを最初に入れておくと後半でやり直しが減る。
Step 4：実装（2〜6週間）
1日1コミット以上、できれば意味のある単位でこまめに commit する。「fix」「update」だけのコミットメッセージは避け、「Why」を書く。詰まったポイントや調査ログは Issue や Discussion に残しておくと、後で開発日誌として使える。
Step 5：デプロイと運用設定（3〜5日）
本番環境にデプロイし、エラー監視（Sentryなど）、アクセス解析、CI/CDを整える。「動く」だけでなく「動かし続けられる」状態にする。コスト試算もREADMEに入れておくと運用視点があると判断されやすい。
Step 6：READMEと自己紹介ページ仕上げ（3〜5日）
READMEを書き直し、スクリーンショットを撮り、デモGIFを作る。自己紹介ページ（1枚もの）から各リポジトリへのリンクを通す。最後に知人エンジニアに30分だけ見てもらってフィードバックを受けると、見落としを潰せる。
やってはいけないアンチパターン
採用担当者やテックリードから繰り返し指摘されている「マイナス評価につながる」パターンを6つ挙げる。1つでも当てはまったら修正したい。
Railsチュートリアル・Udemy教材のコピペで作って、独自要素がない。学習履歴としては価値があるが、ポートフォリオとしては評価されない。最低1機能は自分のオリジナル要件を加えること。
READMEに「動かし方」しか書いていない。「なぜ作ったか」「なぜこの技術か」を書く。これが無いと評価軸の半分以上を満たさない。
機能を詰め込みすぎて、各機能の作り込みが甘い。テスト未整備のまま機能数だけ多いのは逆効果。3機能を深くの方が10機能を浅くより評価される。
最終 commit が半年以上前、Issue が放置、CIが赤いまま。動いていないリポジトリは「過去の遺物」として扱われる。提出前に必ず最新化すること。
本番デプロイされておらず、デモURLが無い。READMEに「ローカルで動かしてください」と書いてあっても、採用担当者はそこまでしない。触れる状態にしておくこと。Vercel/Cloudflareの無料枠で十分。
リポジトリ名・README冒頭が「My App」「Portfolio Project」のような曖昧名。具体的な機能・対象が分かる名前に変える。検索性も上がる。
レベル別の到達ライン目安
「自分のポートフォリオは通用するレベルか」を測る目安。応募先のレベル感によって求められる水準は変わるが、ざっくりの座標として参考にしてほしい。
| レベル | 到達ライン | 想定応募先 |
|---|---|---|
| Lv.1 入門 | 動くアプリ1本、READMEあり、GitHub公開 | 研修ありSES、未経験OK求人 |
| Lv.2 基礎 | テスト一部、デプロイ済、技術選定理由あり | 受託、SES（高単価）、自社開発スタート |
| Lv.3 中級 | CI/CD、ER図、テストカバレッジ可視化、開発日誌 | Web系自社開発、スタートアップ |
| Lv.4 上級 | OSS貢献 or 設計記事、複数リポジトリで一貫した方針 | メガベンチャー、外資テック |
| Lv.5 SR以上 | 影響範囲を語れる事例、ADRや設計記事、登壇歴 | SR/Lead、テックリード、CTO候補 |
注意したいのは、Lv.5が最強ではなく、応募先のレベルに対して過剰でも過小でもダメということ。スタートアップにLv.5の重厚なADR集を見せても刺さらないし、メガベンチャーにLv.1のチュートリアル丸写しを出しても通らない。応募先に合わせて1〜2段階上を狙うのが現実的なライン。
応募先のレベル感がつかめない場合は、エージェントに「自分のポートフォリオを送って通用しそうな企業群を逆引きしてもらう」のが早い。具体的な使い分けはエンジニア転職エージェントおすすめ｜AI×3社併用で内定率を最大化する戦略ガイドを参照してほしい。
スキルが足りないと感じたら、学習を組み合わせる
Lv.2→Lv.3、Lv.3→Lv.4の壁は、独学で越えるのが難しいラインでもある。実務直結のカリキュラムや、現役エンジニアからのコードレビューが受けられる環境を併用すると、ポートフォリオの完成度が一段上がる。
エンジニア向け学習サービスを見るまとめ
// この記事のキーポイント
- 採用担当者が見ているのは「成果物」ではなく「思考プロセス」。技術選定の理由とプロセスをREADMEに書ききる
- 評価軸は5つ：課題設定 / 技術選定 / 設計実装 / 運用改善 / 継続性
- 未経験は「自走力の証明」、現役は「テーマ特化」が勝ち筋
- 2026年の標準スタックは Next.js + Go / Node / Rails / FastAPI、デプロイは Vercel / Cloudflare が現実的
- 制作は6ステップ。3週間〜2ヶ月を目安に、Step 3で技術選定理由を書ききっておくとブレない
- READMEは「動かし方」より「なぜ作ったか」「なぜこの技術か」を先に
- 応募先のレベルに対して1〜2段階上のポートフォリオを目指す
ポートフォリオは「作って終わり」ではなく、応募活動と並走しながら継続的に磨き込むものだ。半年後の自分が見て「もう少しこう書くな」と思える程度には、こまめにアップデートし続けたい。書き出した6ステップを今日のうちに着手すれば、3週間後には最低限の到達ラインを越えられる。