エンジニアのポートフォリオ一覧｜職種別の中身と作り方

エンジニアのポートフォリオに載せる中身は、目指す職種によって変わります。バックエンドなら API（Application Programming Interface）とデータの設計、フロントエンドなら実際に触れる画面、インフラ・SRE（Site Reliability Engineering）なら構成図とコードで管理した設定、AIエンジニアならモデルの評価の方法と再現できるコードというように、採用する側が確かめたい力が職種ごとに違うためです。

経験者の転職では、ポートフォリオは職務経歴書に書いた業務の実績を裏づける資料として使います。Offers に掲載されたエンジニア職の正社員求人を見ても、成果物に触れるのは主に歓迎条件と選考の流れの欄で、応募の条件の中心は実務経験です。

エンジニアのポートフォリオは業務の実績を裏づける資料

エンジニアのポートフォリオは、GitHub のリポジトリ、公開中のアプリや Web サイト、技術ブログ、設計資料のように、技術力を確かめられる成果物を選んで説明を添え、1か所にまとめたものです。経験者の転職で書類選考の中心になるのは職務経歴書の業務の実績で、ポートフォリオはその実績を裏づけ、面接で設計の判断を説明する材料になります。

言葉の意味と、デザイナー職など他の職種との使い分けは「ポートフォリオとは｜IT職の転職で求人が見る中身」で扱っています。

求人票で成果物が出てくるのは主に歓迎条件と選考の流れ

Offers に掲載されたエンジニア職の正社員求人1,765件では、必須条件に「3年以上」のような実務経験の年数を書く求人が51.1%あるのに対し、歓迎条件で成果物や社外へのアウトプット（オープンソースソフトウェア＝OSS への貢献・技術ブログ・登壇など）に触れる求人は3.9%でした。選考の流れの欄では、コーディングテストや技術課題を書く求人が12.0%、成果物の提出や共有に触れる求人が1.3%です。

必須条件の欄で成果物や社外へのアウトプットの語に触れる求人も1.3%ありますが、多くは情報発信を積極的に行うといった姿勢の書き方です。

出所: Offers（株式会社overflow）調べ・エンジニア職の正社員求人 n=1,765・2022年3月〜2026年9月掲載。

応募の条件の中心は実務経験で、ポートフォリオは歓迎条件に該当する活動を示すときや、選考で技術力を説明するときの材料になります。職務経歴書で業務の実績を先に固め、その裏づけとして職種に合う成果物を選ぶ順番が、求人票の求め方に合った準備です。

求人票の欄ごとの内訳と、業務の実績を職務経歴書で示す方法は「エンジニアの転職に成果物は必要か｜経験者の実績の示し方」で詳しく扱っています。

職種別のポートフォリオに載せる中身の一覧

エンジニアのポートフォリオに載せる成果物は、バックエンドなら API とデータベースの設計、フロントエンドなら動く画面、インフラ・SRE なら構成図とコードで管理したインフラの設定が中心です。モバイルなら公開中のアプリ、AIエンジニアなら評価の方法と再現できるコード、PdM なら課題の発見から判断までの記録が軸になります。

バックエンドエンジニアは API とデータの設計を示す

バックエンドエンジニアのポートフォリオでは、API の設計、データベースの設計、認証やエラー処理の作り方を、コードと説明の両方で示します。画面よりコードで判断される職種なので、GitHub のリポジトリを入口にし、README（リポジトリの入口に置く説明のファイル）に API の一覧、データの関係を示す ER（Entity Relationship）図、テストの方針を書いておくのが基本です。

コードの品質も評価の対象になります。命名、テストコード、CI（変更のたびに自動でテストを回す仕組み）、適切に分けたコミットの履歴は、実務での開発の進め方を示す材料です。扱うデータ量を想定してインデックスやキャッシュを設計したなら、その想定と判断を書き添えてください。

フロントエンドエンジニアは触れる画面と表示の工夫を示す

フロントエンドエンジニアのポートフォリオは、採用する担当者が実際に操作できる状態で見せるのが基本です。GitHub Pages・Vercel・Netlify などで Web アプリを公開し、レスポンシブ対応、入力のしやすさ、読み込みの速さ、状態管理の設計を触って確かめてもらいます。

見た目の作り込みに加えて、フレームワークを選んだ理由、コンポーネントの分け方、アクセシビリティへの配慮を README に書くと、設計の考え方まで伝わるはずです。フロントエンドの作り方の詳細は「フロントエンドエンジニアの転職用ポートフォリオの作り方」で扱っています。

インフラエンジニア・SRE は構成図とコードで管理した設定を示す

インフラエンジニアや SRE のポートフォリオは、画面で見せられる成果物が少ないぶん、中心になるのは構成図・コードで管理したインフラの設定・運用の手順書といった文書です。AWS（Amazon Web Services）・Google Cloud・Azure などのクラウドで構築した経験があれば、構成図と Terraform などの IaC（インフラの構成をコードで管理する方法）のコード、監視とアラートの設定を並べると、実務の水準が伝わります。

可用性とコストのどちらを優先したか、障害が起きたときにどこから切り分けるかといった判断も書き添えてください。手作業の手順を自動化した経験があれば、自動化の前と後で手順がどう変わったかを書いておくと、改善の大きさを読み手が測れます。

モバイルエンジニアは公開中のアプリと設計の判断を示す

モバイルエンジニアのポートフォリオは、App Store や Google Play で公開中のアプリがあれば、それが中心の材料です。ストアのページへのリンクに加えて、操作の様子を撮った短い動画、リポジトリ、対応した OS（オペレーティングシステム）のバージョンと端末の範囲を添えると、端末を手元に持っていない読み手にも動きが伝わります。

Swift や Kotlin で作ったネイティブアプリか、Flutter などで両方の OS に向けて作ったアプリかによって、説明すべき点は変わります。通信が切れたときの扱い、画面の描画の速さ、リリースと不具合の修正をどう回したかを説明に入れてください。

AIエンジニア・機械学習エンジニアは評価の方法と再現できるコードを示す

AIエンジニアや機械学習エンジニアのポートフォリオで中心になるのは、モデルの精度の数字そのものより、課題をどう定式化し、どのデータで、どの指標を使って評価したかの説明です。リポジトリに環境の定義、データの取得や前処理の手順、学習と評価のコードがそろっていれば、同じ結果をほかの人が手元で再現できます。

大規模言語モデル（LLM）を使ったアプリなら、評価に使った質問と期待する回答の組、プロンプトや検索の仕組みを変えたときの結果の違い、応答の速さと費用の見積もりを書くと、運用まで考えて作っていることが伝わります。うまくいかなかった手法とその理由も、判断の過程を示す材料のひとつです。

機械学習エンジニアの求人の需要は「機械学習エンジニアの将来性｜需要と求人の変化」で扱っています。

PdM はプロダクトの課題と判断の記録を示す

PdM（プロダクトマネージャー）のポートフォリオは、コードの代わりに、担当したプロダクトの改善事例をまとめた資料が中心です。事例ごとに、見つけた課題、判断の根拠にした情報（利用データやユーザーへのインタビュー）、優先順位の付け方、書いた仕様、追った指標と結果を並べると、プロダクトを前に進める考え方が伝わります。

エンジニア出身の PdM なら、技術的な制約を踏まえて開発の範囲を調整した場面が、開発チームとの協働の仕方を示す材料です。PdM の役割と求められるスキルは「プロダクトマネージャーとは｜役割・スキル・キャリア」で扱っています。

採用する側はポートフォリオで課題・判断・結果の流れを読む

採用する側がポートフォリオで確かめるのは、使える技術の多さより、どんな課題に対して、なぜその技術や設計を選び、結果がどうだったかという判断の流れです。制作物ごとに次の4点をそろえて書くと、職種を問わず読み手が評価しやすくなります。

動く状態で見せること、コードの読みやすさ（命名・コメント・テスト）、チームでの開発の進め方（プルリクエスト・コードレビュー・ブランチの運用）も、職種を問わず評価の材料です。個人の制作物でも、Issue とプルリクエストで作業を区切って進めておけば、チーム開発の作法が伝わります。

ポートフォリオは応募先の求人票を読むところから作る

ポートフォリオ作りの出発点は、応募したい求人の必須条件・歓迎条件・選考の流れを読み、求められている技術と経験に合う成果物を選ぶことです。作り始める前に応募先を決めておくと、載せる成果物を絞れ、職務経歴書の記述ともそろえられます。

1. 求人票から求められる技術と経験を書き出す

応募先の求人の必須条件・歓迎条件から、使う言語・フレームワーク・クラウド、担う役割、歓迎される活動（OSS（オープンソースソフトウェア）への貢献や技術ブログなど）を書き出します。選考の流れにコーディングテストや技術課題があるかも、この時点で確かめておきたい点です。

企業の技術ブログや採用ページ、開発者のインタビュー記事も、使っている技術と開発の進め方を知る手がかりです。

求人の条件を確かめながら応募先を探すなら、Offers にプロフィールと職務経歴を登録しておく方法もあります。経験とスキルを見た企業からスカウトが届き、カジュアル面談で開発の体制や使っている技術を聞いてから選考に進めます。

2. 業務の実績と結びつく題材を選ぶ

新しく作る成果物は、業務で身につけた技術の延長で、応募先の仕事に近い題材を選ぶのが近道です。業務で解いた課題を一般化した小さなツール、使っている OSS への不具合の修正、設計の判断を書いた技術ブログの記事は、職務経歴書の実績と結びつけて説明できる題材です。

作る前に、対象の利用者、解く課題、主な機能、使う技術と選んだ理由を短い設計書にまとめておくと、README と面接の説明の土台になります。

3. 動く状態で公開し、README で案内する

制作物は、読み手がすぐに確かめられる状態での公開が前提です。リポジトリの README には、目的、使った技術と選んだ理由、設計で迷った点と判断、動かし方、デモの URL を書きます。

• コードはテストを含めて、保守しやすい形で書く
• コミットの履歴で、開発の進め方が追えるようにする
• README にプロジェクトの概要と技術を選んだ理由を書く
• デモサイトやストアのページを用意し、動く状態で見せる

4. ほかのエンジニアに見てもらって直す

仕上げる前に、同僚や社外の勉強会で知り合ったエンジニアに見てもらい、説明が伝わるか、足りない情報がないかを確かめます。自分では当たり前に感じる前提が README から抜けていることは多く、初めて読む人の質問は、そのまま直す箇所の目印です。

業務の成果物を載せるときは社名と非公開の情報を伏せる

業務で作ったシステムをポートフォリオに載せるときは、社名・サービス名・顧客の情報・公開前の機能・非公開の数値を外し、構成図や処理の流れを一般化して描き直します。業務で書いたコードや設計書をそのまま公開するのは避けてください。

企業名は「大手出版社の情報配信サービス」のように、業界と規模がわかる程度に抽象化します。在籍中の会社がプレスリリースや技術ブログで公開している情報なら、その URL を添えて実績の裏づけにできます。

判断に迷う情報は、就業規則や秘密保持の誓約書で扱いを確かめてから使ってください。業務のコードの著作権と営業秘密の扱いは「エンジニアの転職に成果物は必要か｜経験者の実績の示し方」で、文化庁と経済産業省の資料をもとに扱っています。

職種別ポートフォリオの要点

エンジニアのポートフォリオは、職種ごとに採用する側が確かめたい力に合わせて中身を選ぶものです。バックエンドは API とデータの設計、フロントエンドは触れる画面、インフラ・SRE は構成図と IaC のコード、モバイルは公開中のアプリ、AIエンジニアは評価の方法と再現できるコード、PdM は課題から判断までの記録を中心に据えます。

Offers のエンジニア職の正社員求人では、応募の条件の中心は実務経験で、成果物は歓迎条件と選考の流れで評価の材料になります。職務経歴書に業務の実績を書き、ポートフォリオでその実績を裏づける順番で準備してください。

自分の経験とポートフォリオがどんな企業から評価されるかは、スカウトを受け取ると確かめられます。Offers に経歴とスキルを登録しておくと、関心を持った企業から声がかかります。