エンジニア転職ポートフォリオの作り方【5ステップ】

「ポートフォリオって、何を作ればいいかわからない」——これ、エンジニアが転職活動を始めたとき、いちばん最初につまずく壁だと思います。ぼく自身、SIerからWeb系企業への転職を経験していて、当時のポートフォリオ作りには正直めちゃくちゃ悩みました。この記事では、転職で通用するポートフォリオの作り方を5ステップで解説します。やってよかったこと・やらなきゃよかったことも含めて書いていきます。

本記事の要約
・ポートフォリオは「採用担当者に技術力と人柄を伝えるツール」と理解することが最初の一歩
・作るものは「README付きのGitHubリポジトリ」+「動くWebアプリ」の2点セットが基本
・中身のクオリティより「なぜ作ったか」の説明が採用担当者に刺さる
・完成度100%を目指さず、まず公開することが大事
・転職エージェントに見せてフィードバックをもらうと改善速度が上がる
タケPM
この記事を書いた人

タケPM

SIerからフリーランスPMへ転身。リモートワーク・転職・副業のリアルな話を体験ベースで発信しています。

そもそもエンジニアの転職ポートフォリオとは何か

「ポートフォリオって結局なんなの?」という話から始めます。ここを誤解したまま作ると、方向性ごとずれてしまうので、最初に整理しておきたいです。

ポートフォリオとは、自分のスキル・実績・考え方を採用担当者や現場エンジニアに伝えるための「作品集」のことです。デザイナーが自分のデザイン作品を一覧にして見せるのと同じイメージで、エンジニアの場合は「自分が作ったアプリやコード」がそれにあたります。

で、結論から言うと、ポートフォリオの目的は「技術力を証明すること」だけじゃないと思っています。採用担当者が見たいのは、「この人はどんな課題意識を持っているか」「どんな開発プロセスで考えているか」「うちのチームで一緒に働けそうか」という点なんです。コードの美しさよりも、そっちの方が意外と大事で。

ポイント
ポートフォリオ=作品集ではなく「自分という人材を伝えるプレゼン資料」と考えると、何を作ればいいかが見えてきます。

職務経歴書との違い

職務経歴書は「過去の経験を文字で説明するもの」です。一方、ポートフォリオは「実際に動くもの・コードを見せるもの」。この違いはかなり大きくて、エンジニア採用では職務経歴書だけだと正直弱いことが多いです。

特に未経験・経験浅めの方、あるいはSIerからWeb系への転職を考えている方は、ポートフォリオがあると一気に書類通過率が上がると感じています。ぼく自身の転職活動でも、GitHubのリンクを職務経歴書に添付してからメンション反応が変わりました。

転職に有効なポートフォリオの「型」を知る

何を作るかで迷う時間が一番もったいないです。まずは「型」を知って、そこから自分にあわせてアレンジするのが早いと思います。

エンジニアの転職ポートフォリオには、大きく分けて3つの形式があります。

①GitHubリポジトリ形式

GitHub(ギットハブ)とは、ソースコードを管理・公開できるプラットフォームです。エンジニアが「自分のコードを他の人に見せる場所」として最もよく使います。

自分が作ったアプリのコードをGitHubに公開して、そのURLを職務経歴書に添付する——これが現場でいちばん多く使われている形式だと思います。ポイントは後述しますが、READMEというファイルに「このアプリを作った理由」を書くのがめちゃくちゃ重要です。

②Webアプリ公開形式

実際にブラウザで動くアプリを作って、URLを共有する形式です。採用担当者がコードを読めない場合でも「触れる」ので、インパクトは大きいです。

無料で公開できるサービスもいくつかあって、たとえばVercelRenderなどが使いやすいと思います。フロントエンドやフルスタック系の方には特におすすめです。

③ポートフォリオサイト形式

自分のプロフィール・スキル・作品一覧をまとめた「自己紹介サイト」を作る形式です。デザイナー兼エンジニアや、フリーランスを目指す方にはとくに有効です。ただ、転職活動メインであれば「①+②」の組み合わせの方が費用対効果は高いかなと思います。

転職活動のポートフォリオとして最も効果的なのは「GitHubリポジトリ+動くWebアプリ」の2点セットです。ポートフォリオサイトは後回しでも問題ないと思います。

5ステップで作るエンジニア転職ポートフォリオ

実際にやってみた話をします。ぼくがWebベンチャーへ転職する際に試行錯誤したことを踏まえて、5ステップに整理してみました。順番通りに進めると迷いにくいと思います。

STEP 1:応募先に合わせてテーマを決める

「何を作るか」より先に「誰に見せるか」を考えます。これ、意外と大事で、応募する企業の業種・技術スタックにあわせてテーマを選ぶだけで、刺さり方がぜんぜん違ってきます。

たとえば、ECサイト系の企業に応募するなら商品管理やカート機能のあるアプリ、SaaS系ならダッシュボードや認証機能を含むもの——という具合です。「自分が作りたいもの」と「応募先が評価しやすいもの」が重なると一番いいです。

  • 応募先の業種・サービスタイプをリサーチする
  • 求人票に書かれている技術スタックを確認する
  • 自分のスキルと応募先ニーズが重なるテーマを選ぶ

STEP 2:「小さく動くもの」を最速で作る

最初から完璧なものを作ろうとしないことが、ぼくが一番反省したポイントです。正直、ぼくは最初の転職活動のとき、アプリ設計に1ヶ月かけすぎて結局完成が遅れました。

まず2週間で「動く最低限のもの」を完成させることを目標にするのがおすすめです。CRUDの基本機能(データの作成・読み取り・更新・削除)があれば、転職ポートフォリオとして十分成立します。

ポイント
ToDoアプリ・ブログ・家計管理ツールなど、シンプルで「なぜ作ったか説明しやすいもの」が最初のポートフォリオには向いています。

STEP 3:GitHubに公開してREADMEを書く

コードができたらGitHubに公開して、READMEを書きます。READMEとは、リポジトリ(ファイルをまとめた場所)のトップページに表示される説明文のことです。

採用担当者がコードを見るとき、まずREADMEを読みます。ここに書くべき内容はこの4つです。

  • このアプリを作った理由・解決したかった課題
  • 使用した技術スタック(言語・フレームワーク・DBなど)
  • アプリの主な機能一覧
  • 動作確認用のURL(デモアプリのリンク)

「なぜ作ったか」の部分を丁寧に書くと、技術力以外の思考プロセスが伝わるので、採用担当者の印象に残りやすいです。ここが一番手を抜かない方がいい部分だと思います。

STEP 4:デモ環境を作って「触れる状態」にする

コードを読めない採用担当者にもアピールするために、実際に動くデモ環境を用意します。

フロントエンドのみのアプリならVercel、バックエンドを含むフルスタックアプリならRenderが無料から使えます。デプロイ(アプリをサーバーに公開すること)の手順も、それぞれのサービスのドキュメントに日本語で書いてあるので、調べながらでも対応できると思います。

注意
無料プランのサービスはサーバーがスリープ状態になることがあります。採用担当者に共有する前に自分でアクセスして、ちゃんと動くか確認しておきましょう。

STEP 5:エージェントや現役エンジニアにフィードバックをもらう

ポートフォリオができたら、一人で抱え込まずに外部からの目を入れることを強くおすすめします。

転職エージェントに見せてフィードバックをもらうのが一番手っ取り早いです。エージェントは企業の採用担当者と日々やり取りしているので、「どんなポートフォリオが通過しやすいか」をリアルタイムで把握しています。無料で使えてフィードバックもくれるので、使わない理由がないと思っています。

エンジニア転職に強いエージェントとしては、レバテックキャリアGeeklyなどが有名です。IT・Web系に特化しているので、技術的な観点でのフィードバックも期待できます。

やってよかったこと・やらなきゃよかったこと

実際にやってみた経験から、正直に書きます。成功談だけ並べても参考にならないので。

やってよかったこと3つ

  • コミット履歴(変更の記録)を細かく残した:開発プロセスが見える化されて、面接での話のネタになった
  • テストコードを1本だけでも書いた:「品質意識がある」という印象を与えられた気がします
  • READMEにスクリーンショットを貼った:コードを読まなくてもアプリの全体像が伝わって、反応がよかった

やらなきゃよかったこと3つ

  • 完成度を高めようとして公開を先延ばしにした:結果的に転職活動の開始が2ヶ月遅れました
  • 流行りの技術を詰め込みすぎた:面接で「なぜこの技術を選んだか」を説明できなくて困った
  • ポートフォリオサイト作りに時間をかけすぎた:見栄えより中身の方が採用担当者には刺さると後から気づいた

採用担当者が実際に見ているポイント

エージェントと話したり、採用側の立場の人から聞いた話をもとに整理してみます。「ポートフォリオで見られているのってコードの質だけじゃないの?」という疑問に答えます。

技術面で見られていること

  • コードが読みやすく整理されているか(変数名・関数名が適切か)
  • セキュリティの基本的な配慮があるか(パスワードの平文保存などしていないか)
  • コミット履歴が適切に残っているか

技術以外で見られていること

  • 「なぜこのアプリを作ったか」の課題意識が明確か
  • ユーザー目線で考えられているか(使いやすさ・UI設計)
  • 自分の言葉で説明できるか(面接でのプレゼン力)

正直、コードの細部より「この人はなぜこれを作ったのか・何を解決したかったのか」を面接で聞かれることの方が多い気がします。ポートフォリオは面接の「話のネタ」でもあるので、自分の言葉で説明できないものは作らない方がいいと思います。

こんな人はポートフォリオを早めに用意すべき

「ポートフォリオって絶対必要なの?」と思っている方もいると思うので、正直な見解を書いておきます。

ポートフォリオが特に効果的な人

  • SIerからWeb系・スタートアップへの転職を目指している人
  • 実務経験が3年未満で、職務経歴書だけでは実力が伝わりにくい人
  • 未経験・異業種からエンジニア職への転職を目指している人
  • フリーランス転向を視野に入れていて、実績をゼロから作りたい人

ポートフォリオがなくても進めやすい人

  • 大手企業での実務経験が5年以上あり、職務経歴書で実績が十分に語れる人
  • 業務でOSS(オープンソースソフトウェア)に貢献している記録がある人
  • マネジメント・PM職への転職を目指している人(コードよりマネジメント経験が評価される)

「自分がどっちに当てはまるか」は転職エージェントに相談するのが一番正確だと思います。ぼく自身も転職時にエージェントへの相談で「ポートフォリオあった方が絶対いい」とはっきり言ってもらって、動くことができました。

まとめ:転職ポートフォリオは「完璧」より「早く出す」が勝ち

記事の要点をまとめます。

  • ポートフォリオは「技術力の証明」だけでなく「思考プロセスを伝えるプレゼン資料」
  • 作る形式は「GitHubリポジトリ+動くWebアプリ」の2点セットが転職活動の基本
  • READMEに「なぜ作ったか」を丁寧に書くことが採用担当者に刺さるポイント
  • 完成度100%を目指さず、まず2週間で動くものを公開することを優先する
  • 転職エージェントに見せてフィードバックをもらうと改善速度が大幅に上がる

で、結論から言うと、ポートフォリオ作りで一番やっていはいけないのは「完璧にしてから公開しよう」という考え方だと思います。ぼくも最初の転職活動でこれをやって、時間をかなりロスしました。まず動くものを作って公開して、フィードバックをもらいながら改善する——このサイクルを回す方が、結果的に早く仕上がります。

次のアクションとして、まずGitHubのアカウントを作って、作りたいアプリのテーマを1つ決めてみてください。それだけで十分なスタートです。

この記事を書いた人 タケPM

タケPM

新卒でSIerに入社後、Web系企業への転職を経て、現在はフリーランスのプロジェクトマネージャーとして複数の案件を掛け持ちしています。リモートワーク歴は5年以上。転職・フリーランス転向・リモートワークと、自分が経験してきたことをそのまま書いています。きれいに整理された情報より、泥臭いリアルを優先して発信するのがモットーです。

タケPMの記事をもっと読む →