エンジニアポートフォリオの作り方6STEP｜題材24選（NG例と公開手順）

エンジニアとして転職を考えたとき、ポートフォリオを用意すべきかどうかで迷ったことはないでしょうか。

実務経験がある方の場合、選考でポートフォリオの提出を求められる場面は多くありません。ただし、生成AIの普及で動くものを短時間で作れるようになったことで、評価の重心は完成度そのものから、なぜその設計にしたのかを自分の言葉で説明できるかどうかへ移っています。

ポートフォリオは必須ではないものの、用意しておけば職務経歴書だけでは伝えきれない判断の質を示す材料になります。

この記事では、以下の内容を解説します。

• ポートフォリオに載せる項目と作成ツールの選び方
• 題材選びから公開までを進める6つのSTEP
• 職種別に選べる題材の具体例24種類
• 実際に公開されている作例から読み取れる評価のポイント
• 権利や機密情報でつまずかないための注意点

転職を控えていて、自分の実力をどう伝えるか迷っているエンジニアの方に、判断の材料と具体的な進め方をお伝えしているので、ぜひ参考にしてください。

エンジニアのポートフォリオとは？

ポートフォリオとは、自分が作ったものと、その制作過程をまとめて公開した資料のことです。エンジニアの場合はWebサイトやGitHubのリポジトリとして公開する形が一般的で、応募書類とは別の役割を担います。

ここでは、次の4点を整理します。

• 選考でポートフォリオが果たす役割
• 履歴書・職務経歴書との使い分け
• デザイナーのポートフォリオとの考え方の違い
• 経験の有無によって見られる箇所が変わること

それでは、順に見ていきましょう。

選考におけるポートフォリオの役割

ポートフォリオの役割は、書類に書いた経歴を裏づけることです。職務経歴書に設計や実装の経験を書いても、その言葉だけでは技術の使い方や判断の質までは伝わりません。実際に動くものと、そこに至る過程の記録があれば、書かれた内容が事実として確認できます。

ただし、中途採用の選考でポートフォリオの提出が必須になる場面は多くありません。エンジニア特化の転職エージェント「テックゴー」では日々エンジニア向けの求人を扱っていますが、ポートフォリオの提出を応募条件に挙げている企業は限られます。

書類選考の段階では職務経歴書が判断の中心にあり、ポートフォリオは面接で技術の話を深めるための材料として使われる場面のほうが多いです。そのため、制作が終わるまで応募を待つ必要はなく、並行して進める順序で問題ありません。

とくに補える範囲が広いのは、現職では扱っていない技術を試している場合や、担当工程が限られていて設計まで関わっていない場合です。実務で示せない領域があるほど、ポートフォリオの価値は上がります。

逆に、現職の経験だけで応募先の求める内容を十分に説明できるなら、無理に用意しなくても選考は進みます。

履歴書・職務経歴書との違い

3つの書類は、伝える対象がそれぞれ異なります。役割が重なっているようで、実際には補い合う関係にあります。

職務経歴書には守秘義務の制約があり、担当したシステムの詳細まで書けない場合があります。その点、個人で作ったものであれば、コードも設計資料も制限なく公開できます。 前職の内容を伏せざるを得ない環境にいる方ほど、ポートフォリオで補える余地は大きいでしょう。

一方で、ポートフォリオだけを充実させても選考は通りません。採用担当者が最初に読むのは職務経歴書であり、そこで興味を持たれてはじめてポートフォリオが開かれます。順序としては職務経歴書を先に仕上げ、そのうえで足りない部分をポートフォリオで補う形が現実的です。

書類の書き方については、次の記事でも解説しています。ぜひ参考にしてください。

ITエンジニアの職務経歴書の書き方完全ガイド｜評価される構成と実例を徹底解説

デザイナーのポートフォリオとの違い

ポートフォリオという言葉はデザイナーの世界から広まったため、作り方を調べるとデザイナー向けの情報が多く出てきます。しかし、評価される箇所は両者で大きく違います。

デザイナーのポートフォリオでは、成果物そのものの見栄えや表現力が評価の中心です。並べた作品の質が、そのまま実力として読み取られます。対してエンジニアの場合、見えている画面よりも、その裏側にあるコードと設計が判断材料になります。画面が地味でも、構成が整理されていて意図が説明されていれば評価は成立するのです。

この違いを取り違えると、労力の配分を誤ります。デザイン用のテンプレートを使ってサイトの見た目を作り込んだものの、肝心のコードやREADMEが手薄という状態は、エンジニアの選考ではもったいない結果になります。時間をかけるべきは、見た目の装飾ではなく、何をどう考えて作ったかを残す部分です。

ただし、フロントエンドのなかでもデザイン寄りの職種では、UIの完成度が評価対象に含まれる場合があります。応募先がどの領域を担う職種なのかによって、力の入れどころを判断しましょう。

未経験者と経験者で見られる点が変わる

同じポートフォリオでも、実務経験の有無によって採用担当者の見る箇所は入れ替わります。

未経験者の場合、判断できる材料がポートフォリオしかありません。そのため、どこまで自力で作れるか、学習をどう進めてきたかという到達点と姿勢が中心に見られます。チュートリアルをなぞっただけの内容では、この2点が読み取れないため評価が伸びません。

経験者の場合、実務経験という判断材料がすでにあります。そこでポートフォリオに求められるのは、経歴の補強です。なぜその技術を選んだのか、何を実装して何を見送ったのかという判断の理由が、経験者にとっては最大の見どころになります。 完成度の高さそのものは、実務経験がある前提であれば当然のものとして受け取られます。

生成AIの普及で、動くものを短時間で用意できるようになりました。その結果、成果物の完成度だけでは差がつきにくくなり、設計の意図を自分の言葉で説明できるかどうかが評価の分かれ目になりつつあります。この傾向は、経験者ほど強く表れるでしょう。

エンジニアがポートフォリオを作る7つのメリット

ポートフォリオは必須ではないものの、用意しておくと選考の場面以外でも効いてきます。主なメリットは、以下の7つです。

• 職務経歴書では伝わらない実力を示せる
• 書類選考の通過率を上げられる
• スキルのミスマッチを防げる
• 面接で話す材料が手に入る
• 言葉での自己PRが苦手でも伝えられる
• エンジニア同士のつながりが生まれる
• 副業や案件獲得の営業資料になる

それぞれのポイントを確認していきます。

職務経歴書では伝わらない実力を示せる

職務経歴書に書けるのは、担当した工程と成果の要約です。使用技術を並べても、その技術をどの深さまで扱えるかまでは読み取れません。経験年数が同じ2人が並んだとき、書面上の差はごくわずかになります。

ポートフォリオがあれば、そこにコードと設計が残ります。命名の一貫性や、テストの有無、ディレクトリの切り方といった細部から、採用担当者は書面よりも多くの情報を受け取るでしょう。言葉で「設計ができます」と書くよりも、設計されたものを1つ見せるほうが早く伝わります。

とくに効くのは、担当工程が限られている環境にいる場合です。運用や保守が中心で設計に関われていない方が、個人開発で設計から手がけた記録を残しておけば、実務では示せない範囲まで評価の対象を広げられます。

書類選考の通過率を上げられる

書類選考では、応募者の経歴が募集要件に届いているかが判断されます。経歴が要件と少しずれている場合、書面だけでは判断がつかず見送りになることがあるのです。

ポートフォリオは、その判断材料を増やします。たとえば業務系システムの経験しかない方がWeb系の企業に応募する場合、実務の経歴だけでは適性が読み取れません。応募先で使われている技術で作ったものを添えておけば、経歴の不足を補う根拠になります。

ただし、書類選考でポートフォリオが必ず開かれるとは限りません。開かれる前提で職務経歴書を薄く書いてしまうと逆効果になるため、あくまで補強として添えましょう。

スキルのミスマッチを防げる

入社後に「聞いていた技術と違った」と感じる状況は、選考の段階で技術の実態がすり合っていないことから起きます。書面のやり取りだけでは、双方が同じ言葉を別の意味で使っていても気づけません。

ポートフォリオを提出すると、企業側は応募者の技術の現在地を具体的に把握できます。その結果、入社後に任される範囲の見通しが立ちやすくなり、想定とのずれが減るのです。採用側が正確に判断できる状態は、応募者にとっても不本意な入社を避けることにつながります。

面接の場でも、作ったものを起点に「うちではこういう構成で開発している」という具体的な話が引き出せます。求人票の文言だけではわからない現場の実態を確認する手がかりにもなるでしょう。

転職後のミスマッチについては、次の記事でも解説しています。ぜひ参考にしてください。

エンジニア転職で失敗した人の特徴とは？よくある後悔と成功するための対策を解説

面接で話す材料が手に入る

面接では、技術に関する質問への回答が抽象的になりがちです。前職の話は守秘義務の制約があり、細部まで踏み込めない場面もあります。

自分で作ったものであれば、その制約がありません。なぜその構成にしたのか、どこで詰まってどう解決したのかを、具体的な事例として話せます。面接官の側も、目の前にある成果物を見ながら質問できるため、会話が深まりやすくなるでしょう。

さらに、話す材料を用意する過程そのものが面接対策になります。制作中に「なぜこの方法を選んだのか」を言語化しておけば、面接直前に慌てて準備する必要がなくなるでしょう。

言葉での自己PRが苦手でも伝えられる

面接で自分の強みを話すのが苦手だという声は、エンジニアからよく聞きます。実力があっても、その場で言葉にするのが得意とは限りません。

ポートフォリオがあれば、伝達の手段が言葉だけではなくなります。書いたコードや残した設計資料が、口頭の説明を補ってくれます。その場の話し方に左右されず、時間をかけて整理した内容をそのまま届けられる点は、話すのが苦手な方にとって大きな助けになるでしょう。

書き言葉のほうが得意な方であれば、READMEや技術記事に考えを丁寧に残しておく方法がおすすめです。面接官がそれを読んだうえで質問してくれるため、ゼロから説明する負担も減ります。

自己PRの作り方については、次の記事でも解説しています。ぜひ参考にしてください。

自己PRが書けないエンジニア必見！短時間で仕上がる転職に強いPRの作り方を解説

エンジニア同士のつながりが生まれる

公開したものは、採用担当者だけが見るわけではありません。技術記事やリポジトリが同じ課題を抱えた人の目に留まり、そこから交流が生まれることがあります。

技術ブログを続けている方のなかには、記事をきっかけに勉強会やコミュニティへ参加するようになったという例もあります。そうしたつながりは、情報の入り口を増やします。社内では触れられない技術の実情や、他社の開発体制の話が入ってくるようになるからです。

転職を考えるうえでも、こうした情報は判断の助けになります。求人票や面接だけでは見えない部分を、実際に働いている人から知れる機会が増えるためです。

副業・フリーランスの営業資料になる

作ったものは、転職以外の場面でも使えます。副業や業務委託の案件に応募するとき、発注側が最初に見るのは実績です。公開している成果物があれば、そのまま提案資料として提示できます。

案件ベースの仕事では、報酬は単価で決まります。過去に何を作ったかを示せると、単価の交渉で不利になりにくくなるでしょう。実務の案件が守秘義務で出せない場合でも、個人開発の成果物であれば制限なく見せられます。

ただし、転職を主目的とするなら、営業資料としての側面は副産物と考えておきましょう。応募先ごとに見せ方を変えると軸がぶれるため、まずは転職の選考で伝えたい内容を優先して構成するのが得策です。

エンジニアのポートフォリオに掲載する項目

掲載する項目に決まった型はありませんが、採用担当者が知りたい情報はおおむね共通しています。

押さえておきたい項目は、次の7つです。

• 自己紹介・経歴
• 保有スキルと使用技術
• 制作物の概要とデモURL
• ソースコード（GitHubリンク）
• 制作意図と工夫した点
• 設計資料（ER図・画面設計・構成図）
• 連絡先・SNSアカウント

それでは、順に見ていきましょう。

自己紹介・経歴

自己紹介は、閲覧者が最初に読む部分です。ここで何をしている人なのかが伝わらないと、その先の成果物も文脈なしで読まれることになります。

書く内容は、担当してきた領域と得意分野を中心に、3〜5行程度にまとめれば十分です。長い経歴を書き連ねるより、フロントエンドを中心に5年、直近は設計から関わっている、といった簡潔な記述のほうが読み手には届きます。詳しい職歴は職務経歴書の役割なので、ここでは重複させません。

なお、実名や所属企業を出すかどうかは自由です。現職に知られたくない場合は、ニックネームで運用しても選考上の不利にはなりません。 実際に、ハンドルネームだけで技術発信を続けているエンジニアは多くいます。

ただしSNSやGitHubのアカウントに本名や所属が表示されていると、そこから特定されるため、公開前に各サービスのプロフィール設定を確認しておきましょう。

保有スキルと使用技術

スキルの一覧は、応募先が求める技術と自分の経験が重なっているかを判断してもらう部分です。言語やフレームワークを羅列するだけでなく、どの程度扱えるかまで書くと精度が上がります。

記載の粒度は、次のように分けると読み手が判断しやすくなります。

扱える技術を多く見せようとして、触った程度のものまで並べるのは逆効果です。 面接で深く聞かれたときに答えられないと、記載内容そのものの信頼が下がります。実務で使ったものと、そうでないものは分けて書きましょう。

スキルの整理については、次の記事でも解説しています。ぜひ参考にしてください。

エンジニアのスキルマップの作り方｜職種別に見る評価されるスキルとは

制作物の概要とデモURL

制作物の紹介では、何を解決するものなのかを最初に書きます。技術構成から入ると、読み手は目的がわからないまま詳細を読むことになるためです。

あわせて、実際に動いている画面へのリンクを載せます。コードだけが置かれていて動作を確認できない状態だと、閲覧者は自分の環境で構築しなければならず、そこで読むのをやめられてしまいます。無料で使えるホスティングサービスは複数あるので、公開までは済ませておきましょう。

デモを公開できない事情がある場合は、操作画面のスクリーンショットや短い動画を用意します。ログインが必要な機能があるなら、試用できるアカウント情報を記載しておくと親切です。

ソースコード（GitHubリンク）

エンジニアの選考では、コードそのものが最も具体的な判断材料になります。リポジトリを公開し、制作物の紹介からリンクをたどれる状態にしておきましょう。

見られるのは、実装の正しさだけではありません。コミットの粒度、ブランチの運用、コメントの残し方といった、日々の開発の進め方が現れる部分も含まれます。1回のコミットにすべての変更をまとめてしまうと、開発の過程が追えなくなり、判断材料が減ります。

複数のリポジトリを公開している場合は、見てほしいものをプロフィールにピン留めしておきましょう。学習用に作った小さなリポジトリが並んでいる状態だと、どれが本命なのか伝わらないためです。

制作意図と工夫した点

生成AIの普及で、動くものを短時間で用意できるようになりました。その分、完成度だけでは差がつきにくくなり、なぜそう作ったのかという判断の部分が評価の中心に移っています。

書いておきたいのは、次の4点です。

• どんな課題を解決しようとして作ったか
• 検討した技術の候補と、選ばなかった理由
• 実装するときに詰まった箇所と、その解決方法
• 意図的に実装しなかった機能と、その判断の背景

とくに4つ目は書かれることが少ないものの、評価につながる項目です。何を作らないかを決められる人は、限られた時間のなかで優先順位をつけられる人だと受け取られます。実務でも同じ判断が求められるため、そこを言葉にしておく価値は大きいでしょう。

実際に公開されている作例のなかには、採用した技術ごとに他の候補を並べ、選定の理由を1つずつ書き残しているものがあります。UIライブラリを選ぶ際に3つの候補を比較し、ドキュメントの充実度を決め手にしたという記述などです。こうした記録があると、面接での説明もそのまま組み立てられます。

設計資料（ER図・画面設計・構成図）

設計資料を載せているポートフォリオは多くありません。だからこそ、用意しておくと差がつく項目です。

載せておきたい資料は、次の3種類です。

• データベースの構造を示すER図
• 画面遷移と各画面の構成を示す図
• サーバーやサービスの配置を示す構成図

これらがあると、実装だけでなく設計まで考えて作ったことが伝わります。上流工程への転向を考えている方にとっては、実務では担当していない領域を示す材料にもなるでしょう。作図ツールで描いたものを画像として貼るだけでよく、時間もかかりません。

あわせて、ディレクトリ構造を図で示しておくと、コードを読む前に全体像がつかめます。 公開されている作例のなかにも、処理の流れ図とディレクトリ構造の両方をREADMEに載せているものがあります。閲覧者の負担を減らす工夫として参考になります。

連絡先・SNSアカウント

見た人が連絡を取れる状態にしておきます。企業側から声がかかる可能性もあるため、問い合わせの手段は用意しておきましょう。

メールアドレスを直接書くのが不安であれば、問い合わせフォームを設置するか、SNSのアカウントを載せる方法があります。技術記事を投稿しているサービスのアカウントも並べておくと、成果物以外の活動もあわせて見てもらえます。

ただし、私生活の内容を投稿しているアカウントを載せると、意図しない情報まで伝わりかねません。技術発信用と私用でアカウントを分けるか、載せる範囲を選びましょう。

ポートフォリオの作成方法とツールの選び方

公開する手段は複数あり、どれを選ぶかで伝わる内容も変わります。ここでは、次の6つの方法を取り上げます。

それぞれの向き不向きを確認していきましょう。

自作のWebサイト

自分でコードを書いてサイトを作る方法です。サイトそのものが制作物になるため、フロントエンドを担当する方にとっては一石二鳥になります。

使う技術は自由に選べますが、応募先で使われているものに寄せると評価につながりやすくなります。

実際に公開されている作例のなかにも、Next.jsとTypeScriptで構築し、CSSの設計手法やUIライブラリまで含めて技術構成を公開しているものがあります。ホスティングまで含めた一連の流れを自分で組めることが、そのまま伝わる形です。

ただし、制作に時間がかかる点は避けられません。サイトの構築に集中するあまり、肝心の制作物が手薄になっては本末転倒です。 転職活動と並行して進めるなら、既存のテンプレートを土台にして中身の記述に時間を割く判断も現実的でしょう。

GitHubリポジトリとREADME

サイトを用意せず、GitHubのリポジトリだけで済ませる方法です。エンジニアの選考では、この形でも十分に成立します。

やることは、リポジトリを公開し、READMEに必要な情報を書くことです。制作物の概要、デモのURL、技術構成、セットアップ手順、設計図を1ページにまとめれば、ポートフォリオとして機能します。閲覧する側もコードと説明を同じ場所で確認できるため、負担が小さくて済みます。

見せたいリポジトリはプロフィールにピン留めしておきましょう。ピン留めは6つまで設定でき、並び順も指定できます。学習用の小さなリポジトリが上位に並んだままだと、本命が埋もれてしまいます。

時間をかけずに用意したい経験者には、この方法が最も効率的です。 サイトの構築という工程を省いても、伝えたい内容は変わらないためです。

Notion

ドキュメント作成サービスを使う方法です。ページを作って公開設定にするだけで、URLを共有できる状態になります。

見出しや表、画像を組み合わせて構成できるため、複数の制作物を並べて整理するのに向いています。制作の記録を書き足していく使い方もしやすく、更新の手間がかかりません。作りながら並行して書き進められる点は、他の方法にない利点です。

一方で、Notionで作ったページ自体は技術力を示すものになりません。中身の記述で勝負する形になるため、制作物の説明や設計の記録を厚くしておきましょう。

ノーコードツール（Wix・STUDIOなど）

コードを書かずにWebサイトを作れるサービスです。デザインの整ったテンプレートが用意されており、短時間で見栄えのするサイトが完成します。

ただし、エンジニアの選考では慎重に考えましょう。サイトの見た目が整っていても、そこから技術力は読み取れません。 むしろ、自分で作らなかった理由を面接で聞かれる可能性があります。

とはいえ、公開までの速度を優先したい場面はあります。応募が迫っていて制作物の説明を早く形にしたい場合や、フロントエンド以外の職種で見た目に労力を割きたくない場合には、選ぶ価値があるでしょう。

その場合は、制作物のリポジトリへのリンクを目立つ位置に置いて、判断材料がコードにあることを示しておくのがおすすめです。

スライド・PDF

資料形式でまとめる方法です。企業から提出を求められた場合や、面接の場で説明しながら見せる用途に向いています。

構成は、1つの制作物につき数ページを目安にします。概要、技術構成、設計図、詰まった箇所とその解決、といった順に並べると、説明の流れがそのまま作れます。面接で話す内容を先に整理しておける点が、この形式の利点です。

ただし、資料は公開されないため、企業側から見つけてもらう経路にはなりません。スカウトを受ける機会を増やしたいなら、Webで公開する方法と併用しましょう。

Qiita・Zennの技術記事との併用

制作物とは別に、技術記事を投稿しておく方法です。実務経験がある方にとっては、これが最も取り組みやすい手段かもしれません。

記事に書くのは、大きなテーマである必要はありません。実務で遭遇したエラーの原因と解決方法、設定を変更した際の記録といった短い内容でも、積み重ねると学び方の姿勢が伝わります。実際に、備忘録として短い記事を書き続けているエンジニアのブログもあります。

大手求人媒体の事例では、技術を試した記録をうまくいかなかった点も含めて発信していたことが評価につながり、スキルの差があってもキャッチアップできる根拠として受け取られた例が紹介されています。完成した成果物がなくても、考えた過程を残しておけば判断材料になります。

記事を投稿するサービスは複数ありますが、投稿先を分散させると読み手が追いにくくなります。自作サイトを持っている場合は、各サービスの記事を一覧で表示できるようまとめておくと、閲覧者が全体を把握しやすくなるでしょう。

エンジニアのポートフォリオの作り方【6STEP】

作る手順が決まっていると、途中で迷って止まることがなくなります。進め方は、次の6つのSTEPに分けられます。

1. 題材と要件を決める
2. 設計する
3. 実装する
4. READMEを書く
5. デプロイして公開する
6. 第三者レビューを受けて改善する

それでは、順に見ていきましょう。

STEP1：題材と要件を決める

最初に決めるのは、何を作るかと、どこまで作るかです。この2つを決めずに手を動かし始めると、機能を足し続けて終わらなくなります。

題材が決まったら、要件を書き出します。書くのは、解決したい課題、実装する機能、実装しない機能の3点です。とくに実装しない機能を先に決めておくと、作業の範囲が固定されて完成までたどり着けます。

要件は、テキストファイル1枚に箇条書きで残しておけば十分です。この記録が、あとでREADMEに書く制作意図の下書きになります。

あわせて、使う技術とその理由もこの段階でメモしておきましょう。作り終えてから思い出そうとすると、判断の経緯が抜け落ちます。

STEP2：設計する（ER図・画面設計・構成図）

要件が固まったら、実装に入る前に設計します。この工程を残しておくと、実装だけでなく設計まで考えて作ったことが伝わります。

作成するのは、次の3種類の図です。

• テーブルの構造と関係を示すER図
• 画面の遷移と各画面の要素を示す図
• サーバーやサービスの配置を示す構成図

作図ツールで描いたものを画像として書き出し、リポジトリに入れておきます。厳密な記法にこだわる必要はなく、他人が見て構造を把握できれば十分です。

とくに上流工程への転向を目指す方にとって、この工程は重要な意味を持ちます。現職で設計を担当していない場合、設計ができることを示す材料が実務にはありません。個人開発の設計資料が、その空白を埋める役割を果たします。

STEP3：実装する（ブランチ運用・コミットの粒度）

実装では、コードの中身と同じくらい、進め方の記録が見られます。採用担当者はコミットの履歴から、日々の開発の進め方を読み取ります。

意識したいのは、次の2点です。

• 機能ごとにブランチを切って作業する
• 1つの変更につき1つのコミットにまとめる

すべてを1回のコミットで済ませてしまうと、どう作ったかが追えなくなります。逆に、意味のない細かいコミットが並ぶのも読みにくくなるため、機能や修正の単位でまとめましょう。コミットメッセージは、何をしたかが1行で伝わる書き方にします。

実務でチーム開発をしている方なら、現場と同じ進め方をそのまま持ち込めば問題ありません。 個人開発だからと運用を崩すと、かえって普段の仕事ぶりを疑われます。

あわせて、詰まった箇所とその解決方法をメモに残しておきましょう。面接で聞かれる場面が多く、あとから思い出すのが難しい部分です。

STEP4：READMEを書く

READMEは、リポジトリを開いた人が最初に読む文書です。ここが空欄だと、コードを読む前に離脱されます。

書いておきたい項目は、次のとおりです。

実際に公開されている作例のなかには、これらを1ページにまとめたドキュメントを用意しているものがあります。プロジェクトの概要から技術スタック、ディレクトリ構造、セットアップ手順、デプロイ方法、コーディング規約までが順に並んだ構成です。

コーディング規約を書く場合は、その根拠となる技術記事へのリンクを添えると、判断の裏づけまで伝わります。なぜその書き方を選んだかが示せるためです。

STEP5：デプロイして公開する

作ったものは、公開して初めて見てもらえます。ローカルでしか動かない状態では、閲覧者が自分の環境で構築しなければならず、そこで読むのをやめられてしまうでしょう。

無料で使えるホスティングサービスは複数あり、リポジトリと連携させれば自動でデプロイされる仕組みも用意されています。公開までの作業は、慣れていれば数十分で終わります。

また、公開する前にAPIキーやパスワードがコードに直接書かれたまま公開されていないかどうかは、必ず確認してください。 環境変数として外に出し、設定ファイルはリポジトリから除外しておきましょう。

公開したあとは、実際にURLを開いて動作を確認します。ローカルでは動いていた機能が本番環境でエラーになるケースは珍しくありません。エラーが表示されたままの状態で見られると、評価は大きく下がります。

STEP6：第三者レビューを受けて改善する

自分で書いたコードや文章は、抜けに気づきにくいものです。公開したら、誰かに見てもらいましょう。

見てもらう相手は、同僚でも、勉強会で知り合ったエンジニアでも構いません。頼みにくい場合は、技術記事として制作の記録を投稿すると、コメントで指摘が入ることがあります。

依頼するときは、見てほしい観点を伝えると具体的な意見が返ってきます。

READMEを読んで何を作ったか伝わるか コードの構成に不自然な箇所はないか 動かして詰まる場面はないか

指摘を受けたら、直せる範囲から手を入れます。ただし、すべてを反映しようとすると終わりません。公開したあとも育てていくものと考えて、優先度の高いものから対応しましょう。

ポートフォリオの題材が決まらないときの4つの考え方

何を作るかで手が止まる方は多くいます。題材を見つける切り口は、次の4つです。

それぞれのポイントを確認していきます。

身近な不便から題材を選ぶ

自分が普段感じている不便を解消するものを作る方法です。作る動機がはっきりしているため、なぜこれを作ったのかという質問に迷わず答えられます。

探す範囲は、業務に限りません。家計の記録、読んだ本の管理、趣味の記録といった日常の作業でも構いません。手作業で繰り返している場面や、既存のサービスでは物足りない部分が題材になります。

採用担当者が見ているのは題材の斬新さではなく、課題をどう捉えて解決策に落とし込んだかです。 ありふれたテーマでも、自分の困りごとから出発していれば説明に厚みが出ます。

逆に、面接映えを狙って興味のないテーマを選ぶと、深く聞かれたときに答えが続きません。

志望職種の実務内容から逆算する

応募したい職種の求人票を読み、そこで使われている技術や扱う領域から題材を決める方法です。実務経験と応募先の要件にずれがある場合、そのずれを埋める手段になります。

進め方は、次のとおりです。

• 応募候補の求人票を3〜5社分読む
• 共通して求められている技術や経験を書き出す
• そのうち実務で経験していないものを選ぶ
• その技術を使う必然性がある題材を考える

たとえば業務系システムの経験しかない方がWeb系企業を目指す場合、求人票に並ぶフレームワークやクラウドサービスのうち、触れていないものが浮かび上がります。それを使った小さなアプリを1つ作れば、経歴の空白を埋める根拠になるでしょう。

ただし、技術を使うこと自体が目的になると、機能に一貫性がなくなります。使いたい技術が決まったら、その技術が活きる題材を選び直しましょう。

既存サービスの一機能を作り替える

すでにあるサービスの機能を1つ選び、自分で作り直す方法です。仕様を考える工程を省けるため、短期間で形にできます。

選ぶのは、サービス全体ではなく機能単位です。たとえば投稿サービスなら通知の仕組みだけ、予約サービスなら空き枠の判定だけ、といった切り出し方をします。範囲が狭いほど、内部の作りに時間を割けます。

この方法には利点がもうひとつあります。既存のサービスがどう動いているかを観察したうえで自分なりの設計に落とすため、なぜこの構成にしたのかという説明が、既存の実装との比較として組み立てられます。 判断の理由を示す材料として使いやすい形です。

なお、画面のデザインや文言をそのまま複製するのは避けましょう。作るのは機能の仕組みであって、見た目の再現ではありません。

学習過程で詰まった作業を自動化する

日々の作業のなかで、手間だと感じている工程を自動化する方法です。実務と並行して進めやすく、規模も小さく収まります。

題材になりやすいのは、次のような作業です。

• 定期的に同じ手順で集めている情報の収集
• 手作業で整形しているデータの変換
• 複数のツールをまたいで転記している内容の連携
• 環境構築の手順をまとめたスクリプト

規模が小さいため、これ1つでは物足りないと感じるかもしれません。ただし、実務経験がある方の場合、大きな成果物より小さくても完成しているもののほうが評価されます。使い続けているツールであれば、実際に役立っている事実そのものが説得力になるでしょう。

作ったあとは、なぜ自動化しようと思ったのか、どれだけ手間が減ったのかを記録しておきます。課題を見つけて解決する動き方が、そのまま伝わる材料になります。

職種別に見るポートフォリオの題材24選

同じ題材でも、職種によって見せるべき部分は変わります。ここでは、6つの職種ごとに4案ずつ紹介します。

それでは、順に見ていきましょう。

フロントエンドエンジニア

フロントエンドでは、画面が動くことよりも、その裏側の設計が見られます。状態をどう持ち、どこで描画を分けたかという判断が評価の対象です。

題材の例は、次の4つです。

• 条件で絞り込める検索と一覧の画面
• 下書き保存と入力チェックを備えた投稿フォーム
• 複数の指標を切り替えて表示するダッシュボード
• 再利用できるUI部品をまとめたコンポーネント集

画面の見栄えより、コンポーネントの分割とテストの有無に時間を割きましょう。 公開されている作例のなかにも、UI部品のカタログを作るツールとブラウザ操作の自動テストを組み込み、部品ごとに動作を確認できる状態にしているものがあります。実務でチーム開発をしている前提が伝わる構成です。

バックエンドエンジニア

バックエンドでは、テーブルの設計とAPIの作りが中心に見られます。画面がなくても成立するため、APIだけを公開する形でも構いません。

題材の例は、次の4つです。

• 認証と権限の管理を備えたAPI
• 在庫や予約の重複を防ぐ仕組みを持つ処理
• 外部サービスと連携してデータを取り込むバッチ
• 検索条件が複雑な一覧を返すエンドポイント

とくに評価されやすいのは、同時に処理が走った場合の対処を考えている題材です。予約の重複や在庫の引き当てといった場面で、どう整合性を保つかは実務でも問われる論点になります。ER図を添え、そこまで考えて設計したことを示しましょう。

APIを公開する場合は、仕様書もあわせて用意します。エンドポイントごとの引数と返り値がわかる状態にしておくと、閲覧者がコードを追わずに全体像をつかめます。

インフラ・クラウドエンジニア

インフラでは、作ったものより、その構成を再現できる形で残せるかが見られます。手作業で構築した環境は評価につながりません。

題材の例は、次の4つです。

• コードで記述したクラウド環境の構成一式
• 複数のコンテナを組み合わせた開発環境
• 自動でテストとデプロイまで進むパイプライン
• 障害の検知と通知を組み込んだ監視の仕組み

構成を記述したファイルをリポジトリに置き、実行すれば同じ環境が立ち上がる状態にしておきましょう。 構成図を添えて、どのサービスをどうつないだかを図で示すと、コードを読む前に意図が伝わります。

コストの設計まで書けると、さらに踏み込んだ内容になります。どの構成を選び、なぜその規模に収めたかを説明できると、運用の視点があることが伝わるためです。

データ・機械学習エンジニア

この領域では、精度の高さより、そこに至る過程が見られます。データをどう扱い、結果をどう検証したかが判断材料です。

題材の例は、次の4つです。

• 公開データを集めて整形するまでの処理
• 予測モデルの作成と精度の比較検証
• 分析結果を可視化するダッシュボード
• 定期実行でデータを更新する仕組み

用意するのは、実行できるノートブックだけでは足りません。なぜその特徴量を選んだか、どの手法と比較したか、どこで精度が伸び悩んだかを文章で残しましょう。過程の記録がないと、既存のコードを動かしただけに見えます。

なお、扱うデータには注意が必要です。個人情報を含むものや、利用規約で再配布が禁じられているものは使えません。公的機関が公開しているデータを選べば、この問題は避けられるためおすすめです。

モバイルアプリエンジニア

モバイルでは、端末ならではの制約をどう扱ったかが見られます。通信が不安定な状況や、画面サイズの違いへの対処が論点になります。

題材の例は、次の4つです。

• 通信できない状態でも使える記録アプリ
• 位置情報を使って周辺の情報を表示するアプリ
• 端末のカメラで撮影して加工するアプリ
• 通知で行動を促すリマインダーアプリ

ストアに公開するところまで進めば、審査を通す工程も経験として示せます。ただし公開には費用と時間がかかるため、そこまで求められる場面は多くありません。動作を録画した短い動画をREADMEに添えれば、公開しなくても伝わります。

複数の端末で動作を確認したことを書き添えると、実務での配慮が伝わります。特定の機種でしか試していない状態は、評価を下げる要因になるためです。

社内SE・業務システム

社内SEを目指す場合、技術の高度さより、業務の流れを整理して仕組みに落とす力が見られます。誰がどう使うかを考えた設計が評価されます。

題材の例は、次の4つです。

• 申請と承認の流れを管理するワークフロー
• 資産や備品の貸出状況を記録するシステム
• 複数のツールをつなぐ業務の自動化
• 問い合わせ内容を蓄積して検索できる仕組み

作るときは、業務フローの図を先に作りましょう。誰がどの順番で操作し、どこで承認が入るかを整理した図があると、現場を理解したうえで設計したことが伝わります。技術構成より、この図のほうが評価に効く場面もあります。

なお、現職の業務をそのまま題材にする場合は注意が必要です。実在の帳票や項目名をそのまま使うと、社内の情報を外に出すことになります。業務の型は借りつつ、具体的な内容は架空のものに置き換えましょう。

実務未経験からポートフォリオを作る場合の進め方

実務経験がない場合、判断材料はポートフォリオしかありません。押さえておきたい進め方は、次の5つです。

• 志望職種を決めてから題材を選ぶ
• 要件を自分で決めた過程を残す
• 学習教材の課題をそのまま出さない
• 実装範囲を絞って公開までを優先する
• 学習期間と学んだ順序を併記する

それでは、順に見ていきましょう。

志望職種を決めてから題材を選ぶ

作りたいものを先に決めると、必要な技術が広がりすぎます。フロントエンドもバックエンドもインフラも少しずつ触った状態は、どの職種でも中途半端に見えてしまいます。

先に決めるのは、応募する職種です。職種が決まれば、使う技術も、見せるべき部分も自動的に絞られます。未経験の選考では、扱える技術の幅より、1つの領域をどこまで掘り下げたかが見られます。

職種の選び方に迷う場合は、求人票を読んで仕事内容を比べるところから始めましょう。未経験を受け入れている求人が多い領域と、そうでない領域があるため、その差も判断材料になります。

未経験からの職種選びについては、次の記事でも解説しています。ぜひ参考にしてください。

未経験でIT企業への転職を成功させるロードマップ！転職しやすい職種も紹介

要件を自分で決めた過程を残す

未経験者のポートフォリオで最も差がつくのは、要件を自分で決めたかどうかです。実装の巧拙は経験の差がそのまま出ますが、何を作るか決める過程には経験年数が関係しません。

残しておきたいのは、次の4点です。

• どんな課題を解決しようとしたか
• 誰が使う想定で作ったか
• 実装した機能と、その優先順位をどう決めたか
• 実装しないと決めた機能と、その理由

面接では、この部分が繰り返し聞かれます。実務経験について質問できない分、どんな考えで作ったかへの質問が増えるためです。制作中にメモを取っておけば、そのまま回答の材料になるでしょう。

生成AIを使って実装した場合も、隠す必要はありません。どこを任せて、どこを自分で書いたか、その判断基準を説明できる状態にしておきましょう。中身を理解しないまま動いているコードは、質問された時点で見抜かれます。

学習教材の課題をそのまま出さない

学習サービスやスクールの課題を、そのまま提出するのは避けましょう。同じ教材を使った応募者が同じ構成のものを出してくるため、採用担当者には見分けがつきません。

とはいえ、教材で作ったものを土台にすること自体は問題ありません。手を加える方向としては、次の3つがあります。

• 教材にはない機能を追加する
• 題材を変えて、同じ構成で作り直す
• 使う技術を1つ入れ替えて実装し直す

どれを選んでも、なぜその変更を加えたかを説明できる状態にしておきます。教材との差分こそが、自分で考えた部分として評価されます。 変更した箇所と、その過程で詰まった内容をREADMEに書き残しておきましょう。

なお、未経験者の作るものが実務の水準に届かないのは採用担当者も前提として見ています。届かないことを気にするより、考えて作った跡が残っているかを優先しましょう。

実装範囲を絞って公開までを優先する

未経験の方が陥りやすいのは、機能を増やし続けて完成しない状態です。学習しながら作っていると、新しく覚えた技術を試したくなり、範囲がどんどん広がります。

避けるには、最初に決めた要件を守ることです。追加したい機能が出てきたら、公開したあとの改善として記録に回します。動くものが1つ公開されている状態と、作りかけのものが手元にある状態では、伝わる情報がまったく違います。

目安としては、中核となる機能が3つ程度あれば十分です。登録して、一覧を表示して、条件で絞り込める。この程度でも、設計と実装の考え方は伝わります。

公開したあとに機能を足していけば、コミットの履歴が継続して残ります。作り続けている記録そのものが、学習を止めていない証拠になるでしょう。

学習期間と学んだ順序を併記する

未経験者の場合、どれくらいの期間で何を身につけたかが判断材料になります。同じ完成度でも、3ヶ月で到達したのか2年かかったのかで、受け取られ方は変わります。

書き添えたいのは、次の内容です。

• 学習を始めた時期と、制作にかけた期間
• どの順番で技術を学んだか
• 途中でつまずいた箇所と、どう乗り越えたか

順序を書くと、学び方の進め方が読み取れます。基礎から積み上げたのか、作りながら覚えたのかによって、入社後の伸び方の見通しも変わってくるためです。

なお、期間を実際より短く書くのは避けましょう。 面接で細部を聞かれたときに整合しなくなり、内容全体の信頼を失います。時間がかかったなら、そのうえで何を身につけたかを書けば問題ありません。

実務経験者がポートフォリオを作る場合の進め方

経験者の場合、実務という判断材料がすでにあります。そのうえで何を足すかが論点です。

押さえておきたい進め方は、次の3つです。

• 前職の成果物は抽象化して載せる
• 個人開発では設計判断の理由を見せる
• 副業・案件獲得も見据えて構成する

それでは、順に見ていきましょう。

前職の成果物は抽象化して載せる

エンジニア特化の転職エージェント「テックゴー」に寄せられたご相談のなかでも、前職で作ったものをどこまで見せてよいかという質問は多く挙がっています。ここで混同されやすいのは、職務経歴書に書ける範囲と、コードや画面を外に出せる範囲が別のものだという点です。

担当した案件の規模や使用技術は選考で当然に話す内容ですが、成果物そのものを公開できるかは権利と契約の問題として切り分けて考えましょう。

結論として、実務で作ったものはそのままでは公開できません。業務として書いたコードの著作権は、原則として勤務先に帰属するためです。著作権法では、会社の指示にもとづいて従業員が職務上作成したプログラムについて、契約や就業規則に別段の定めがない限り会社が著作者になると定められています。

とはいえ、実務の経験をポートフォリオに反映する方法はあります。取れるのは、次の3つです。

• 同じ課題を、自分で書き直した別の実装として作る
• 業務の型だけ借りて、扱う内容を架空のものに置き換える
• コードは載せず、設計の考え方を技術記事として書く

移せるのは考え方であって、成果物そのものではありません。 承認フローを扱う社内システムを担当していたなら、フローの設計思想は書けます。ただし、実在の帳票、項目名、取引先名、画面のキャプチャは対象外です。

判断に迷ったときは、その情報が社外に出て困るかどうかを基準にしましょう。困る可能性が少しでもあるなら載せない、で問題ありません。

個人開発では設計判断の理由を見せる

経験者が個人開発を見せる場合、動くものを作った事実自体は評価されません。実務でやっていることの延長だと受け取られるためです。差がつくのは、なぜその構成にしたかという判断の部分になります。

書き残しておきたいのは、次の4点です。

• 検討した技術の候補と、比較した観点
• 最終的に選んだ理由と、見送った理由
• 実装の途中で方針を変えた箇所と、その経緯
• 今から作り直すなら、どこを変えたいか

実際に公開されている作例のなかには、採用した技術ごとに他の候補を並べ、選定の理由を書き残しているものがあります。UIライブラリを3つ比較し、対応状況と部品の種類、ドキュメントの充実度を観点として挙げたうえで決めた、といった記述です。

判断の観点まで書かれていると、同じ状況に置かれたときの動き方が読み手に伝わります。

方針を変えた経緯を書ける点も、経験者ならではの強みです。一度選んだ構成で問題が出て、別の方法に切り替えた記録があると、実務で起きる想定外への対応力が示せます。うまくいった話だけを並べるより、説得力は上がるでしょう。

副業・案件獲得も見据えて構成する

作ったものは、転職の選考が終わっても残ります。副業や業務委託の案件に応募するときには、そのまま実績として提示できます。案件ベースの仕事では報酬が単価で決まるため、過去に何を作ったかを示せる状態は交渉の場面で効いてきます。

とはいえ、両方に向けて作り分けると軸がぶれます。転職を主目的とするなら、選考で伝えたい内容を優先して構成しましょう。副業での活用は、あとから見せ方を足せば済む話です。

具体的には、次のように使い分けられます。

同じリポジトリでも、READMEの構成を少し変えるだけで両方に対応できます。まずは選考向けに作り込み、必要になったら見せ方を足す順序が現実的です。

制作期間の目安と「公開する」を決める3つの基準

作り込みを続けて公開が遅れるのは、よくある失敗です。期間を区切って公開に踏み切るための基準は、次の3つです。

• 制作期間は2〜4週間を上限に置く
• 実装する機能に優先順位をつける
• 公開してから育てる前提に切り替える

それぞれのポイントを確認していきます。

制作期間は2〜4週間を上限に置く

働きながら進める場合、確保できるのは平日の夜と休日です。この条件で無理なく形にできる範囲として、2〜4週間を上限に置くと現実的な計画が立ちます。

期間を先に決めると、作る範囲も自然に決まります。逆に範囲から決めると、必要な期間が読めず、気づけば数ヶ月が過ぎている状態になりがちです。転職活動には応募や面接の準備もあり、制作だけに時間を使い続けられるわけではありません。

なお、この期間はゼロから作る場合の目安です。技術記事を書く方法を選ぶなら、1本あたり数時間で公開できます。個人開発の時間が取れないなら、そちらに切り替える判断も選択肢に入れましょう。

期間を延ばしたくなったら、応募の時期から逆算します。求人は動きが速く、良い条件のものほど早く埋まります。制作を優先して応募が遅れると、本来の目的から外れてしまうでしょう。

転職活動の進め方については、次の記事でも解説しています。ぜひ参考にしてください。

エンジニアが転職するベストなタイミングとは？決断すべきサインも紹介

実装する機能に優先順位をつける

期間内に収めるには、作る機能を絞ります。思いついた順に着手すると、中核となる部分が最後まで残り、期限が来たときに動かない状態になります。

分け方は、次の3段階で考えると整理できます。

• これがないと成立しない機能
• あると使いやすくなる機能
• 余裕があれば足したい機能

最初の段階に入るものだけを実装対象とし、残りは公開後の課題として記録しておきます。何を作らないと決めたかは、それ自体が評価につながる材料です。 優先順位をつけた過程をREADMEに残しておけば、判断できる人材であることが伝わります。

見た目の調整は、最後に回しましょう。配色やレイアウトに時間を使うと、肝心の機能が間に合いません。エンジニアの選考で見られるのは画面の裏側であり、装飾に費やした時間は評価に反映されにくい部分です。

公開してから育てる前提に切り替える

完成してから公開しようとすると、いつまでも公開できません。手を入れたい箇所は作るほど増えていき、区切りが自分では見つけられなくなります。

そんなときは考え方を切り替えましょう。公開は完成の合図ではなく、途中経過を外に出す作業です。動く状態になったら公開し、そのあとで改善を重ねていけば問題ありません。むしろ、公開後もコミットが続いている状態は、作り続けている記録として読み取られます。

公開してよいかどうかは、次の3点で判断できます。

• 中核となる機能が動作し、エラーが表示されない
• READMEを読んで何を作ったかが伝わる
• 認証情報や個人情報がリポジトリに残っていない

この3点を満たしていれば、細部が粗くても公開して構いません。未完成のまま手元に置いておくより、公開して見てもらったほうが得られるものは多くなります。 レビューを受けて直す流れも、公開してはじめて動き出します。

なお、3つ目については見落とすと影響が大きいため、公開前に必ず確認しましょう。

参考にしたいエンジニアのポートフォリオ作例

実際に公開されているものを見ると、構成の考え方がつかめます。ここでは、掲載の許可をいただいた2つの作例を紹介します。

どちらも制作物を並べたギャラリー形式ではなく、技術発信の場をそのままポートフォリオとして機能させています。実務経験がある方にとって、現実的に取りやすい形です。

ドキュメントを整えた技術ブログ型の作例

1つ目は、ヌギーさんが運営する技術ブログです。

サイトはNext.jsとTypeScriptで構築されており、スタイルの記述方法やUIライブラリまで含めた技術構成が公開されています。記事はブログ上のものだけでなく、外部の投稿サービスに書いたものもタブで切り替えて一覧できるようになっており、発信内容の全体像がひと目で把握できる作りです。

参考になる点は、大きく2つあります。

1つ目は、サイト自体のドキュメントを1ページにまとめていることです。 プロジェクトの概要から技術スタック、ディレクトリ構造、機能一覧、環境構築の手順、デプロイ方法、コーディング規約までが順に並んでいます。README.mdに書くべき項目がそのまま揃っており、何を書けばよいか迷ったときの見本になります。

2つ目は、技術選定の理由を記事として残していることです。採用した技術ごとに検討した他の候補が併記され、なぜそれを選ばなかったかまで書かれています。UIライブラリの選定では3つの候補を比較し、対応状況、部品の種類、ドキュメントの充実度という観点を挙げたうえで判断した経緯が読み取れる形です。

さらに、ブログを作った動機そのものも記事として公開されています。学んだことをまとめたい、開発する題材が欲しかった、という素直な理由が書かれており、題材選びに悩む方の参考になるでしょう。

参考：Ask Nugey!（ヌギーにきいて！）

備忘録を積み重ねた記録型の作例

2つ目は、おばけさんが運営する技術ブログです。

こちらは前述の作例とは方向性が異なり、実務で遭遇した内容の記録が中心です。1記事あたりの分量は短く、詰まった箇所と解決方法が簡潔にまとめられています。扱っている範囲も、フロントエンドのライブラリからターミナルの設定、テスト実行時の環境まで幅広く、日々の業務のなかで触れた領域がそのまま現れています。

参考になるのは、1本ずつの内容が短くても、積み重なることで学び方の姿勢が伝わる点です。 大きなテーマで書こうとして手が止まるより、詰まった内容をその都度残していくほうが続きます。個人開発の時間を確保しにくい方にとって、取りやすい方法だといえるでしょう。

あわせて、GitHubで公開されている個人開発リポジトリの作りも参考になります。READMEには、動作を確認できるデモのURL、処理の流れを示した図、ディレクトリ構造、実行コマンドの一覧が並んでいます。

加えて、コーディング規約が根拠となる技術記事へのリンク付きで書かれており、なぜその書き方を採用したかまで確認できる構成です。

リポジトリにはUI部品を確認するツールやブラウザ操作の自動テスト、継続的な統合の設定も組み込まれています。個人開発でありながらチーム開発と同じ体制で進めた記録が残っており、実務での進め方がそのまま伝わる形になっています。

参考：Obake Engineer Blog

採用担当者に評価されるポートフォリオの5つの共通点

評価される作りには、いくつかの傾向があります。押さえておきたい共通点は、次の5つです。

• 既存のものをなぞらず、独自の要素を加えている
• 実務で使われている技術を選んでいる
• 使う人を想定して設計している
• コードが読みやすく整理されている
• 制作の意図と過程が記録されている

それでは、順に見ていきましょう。

独自性を加える

同じ構成のものが並ぶと、採用担当者には見分けがつきません。学習サービスの課題や、公開されているチュートリアルをそのまま作ったものは、この状態になります。

独自性といっても、誰も思いつかない題材を探す必要はありません。ありふれたテーマでも、自分の状況から出た課題であれば説明に厚みが出ます。加えるべき要素は、次のようなものです。

• 実際に自分が困っている場面を題材にする
• 既存のサービスにない機能を1つ足す
• 想定する利用者を具体的に絞り込む

評価されるのは題材の珍しさではなく、なぜそれを作ろうと思ったかを説明できるかどうかです。 面接では必ず動機を聞かれるため、そこで詰まらない題材を選びましょう。

需要のある技術を選ぶ

使う技術は、実務で採用されているものから選びます。趣味で触れている技術も学びにはなりますが、選考の材料としては応募先で使われているもののほうが伝わります。

判断の材料になるのは、求人票です。応募候補を数社分読み比べると、共通して挙がっている技術が見えてきます。そこから、自分が実務で扱っていないものを選べば、経歴の空白を埋める役割も果たせるでしょう。

一方で、新しい技術を試した記録にも価値があります。出たばかりのフレームワークを触ってみた内容を記事にしておくと、情報を追い続けている姿勢が伝わります。

ただし、それだけで構成すると実務との接点が見えなくなるため、中核となる制作物は実務で使われている技術で作りましょう。

ユーザー目線で設計する

技術的に正しく作られていても、使う人のことが考えられていないと評価は伸びません。実務では、動くことと使えることは別の問題として扱われるためです。

見られるのは、細かい配慮の部分です。入力を間違えたときにどんなメッセージが出るか、処理に時間がかかるときに待っていることが伝わるか、操作を取り消せるかといった箇所が該当します。こうした配慮があると、利用者を想定して作ったことが読み取れます。

READMEに、誰が使う想定かを書いておきましょう。利用者が具体的であるほど、機能を絞った理由も説明しやすくなります。 全員に向けたものより、特定の場面を想定したもののほうが設計の筋が通ります。

読みやすいコードに整える

コードを読むのは、同じ職種のエンジニアです。書き方の癖や整理の仕方から、チームで一緒に働けるかどうかが判断されます。

意識したいのは、次の点です。

自動整形のツールと静的解析のツールを導入しておくと、書き方のばらつきは機械的に揃います。設定ファイルをリポジトリに含めておけば、そうした環境を整えたこと自体も伝わるでしょう。

コーディング規約をREADMEに書く場合は、その根拠となる技術記事へのリンクを添えると、判断の裏づけまで示せます。なぜその書き方を選んだかが説明できる状態は、実務での議論にも耐える姿勢として受け取られます。

制作意図とストーリーを伝える

生成AIの普及で、動くものを短時間で用意できるようになりました。その結果、完成度そのものでは差がつきにくくなり、判断の過程が評価の中心に移っています。

残しておきたいのは、うまくいった話だけではありません。方針を変えた経緯や、詰まって解決に時間がかかった箇所こそ、実務での動き方が表れる部分です。 一度選んだ構成で問題が出て別の方法に切り替えた記録があると、想定外の事態への対応力が伝わります。

書く順序としては、課題の発見、検討した選択肢、選んだ理由、詰まった箇所とその解決、今なら変えたい点、という流れが組み立てやすくなります。この順で書いておけば、面接での説明もそのまま使えるでしょう。

なお、この記録は制作中に書き残すのが確実です。作り終えてから思い出そうとすると、判断の細部が抜け落ちます。メモの形で構わないので、その場で残しておきましょう。

評価を落とすNGなポートフォリオ

作り方を誤ると、提出しないほうがよかったという結果にもなります。避けたい状態は、次の6つです。

• チュートリアルをなぞっただけになっている
• READMEがなく何を作ったか伝わらない
• デプロイされておらず動作を確認できない
• バグやエラーが放置されている
• デザインに凝りすぎて中身が伝わらない
• 技術選定の理由を説明できない

それでは、順に見ていきましょう。

チュートリアルをなぞっただけになっている

公開されている手順書や学習教材の内容を、そのまま形にしただけの状態です。採用担当者は同じものを何度も見ているため、すぐに判別されます。

問題は、判断材料が何も得られない点にあります。手順どおりに進めた結果には、自分で考えた箇所が含まれません。技術力も、課題を解決する力も、そこからは読み取れないのです。

土台として使うこと自体は問題ありません。 機能を足す、題材を変える、使う技術を入れ替えるといった手を加えれば、その差分が自分で考えた部分になります。加えた変更と、そう判断した理由をREADMEに書いておきましょう。

READMEがなく何を作ったか伝わらない

リポジトリを開いてもコードだけが並んでいる状態です。閲覧者は、何のために作られたものかわからないまま読み進めることになります。

多くの場合、そこで離脱されます。採用担当者が1件のポートフォリオにかけられる時間は限られており、内容を推測しながら読み解く余裕はありません。せっかく作ったものが、読まれずに終わってしまいます。

最低限、概要とデモのURLと技術構成の3点は書いておきましょう。この3行があるだけで、続きを読むかどうかの判断ができるようになります。コードの質より前に、読んでもらえる状態かどうかが問われます。

デプロイされておらず動作を確認できない

公開されておらず、手元で構築しないと動かせない状態です。閲覧者に環境構築の手間をかけさせることになり、実際に動かしてもらえる可能性は低くなります。

無料で使えるホスティングサービスは複数あり、リポジトリと連携させれば自動でデプロイされる仕組みも用意されています。公開までの作業は、慣れていれば短時間で終わります。

事情があって公開できない場合は、代わりの手段を用意しましょう。操作画面のスクリーンショットを並べるか、動作を録画した短い動画を添えれば、実際に動くことは伝わります。何も用意しないまま提出するのは避けたい状態です。

バグやエラーが放置されている

公開はされているものの、開くとエラーが表示される状態です。この場合、内容を見てもらう以前の段階で評価が下がります。動作確認をしないまま提出したと受け取られるためです。

とくに多いのは、手元では動いていたのに公開先ではエラーになるケースです。環境変数の設定漏れや、参照先の違いが原因になります。公開したら、必ず実際のURLを開いて確認しましょう。

確認しておきたいのは、次の点です。

• 主要な機能がひととおり動作する
• 入力を誤ったときにエラーが処理されている
• スマートフォンの画面幅でも表示が崩れない

すべての不具合をなくす必要はありません。ただし、開いた瞬間に見える箇所のエラーは必ず直しておきましょう。 そこで読むのをやめられると、中身は評価の対象になりません。

デザインに凝りすぎて中身が伝わらない

見た目を作り込んだ結果、肝心の制作物やコードが埋もれている状態です。凝った演出が入っていても、エンジニアの選考で見られるのは画面の裏側になります。

原因の多くは、デザイナー向けの情報を参考にしたことにあります。ポートフォリオという言葉はデザイナーの世界から広まったため、作り方を調べると見せ方に関する情報が多く出てきます。しかし評価される箇所は、両者で異なります。

判断の目安は、リポジトリへの導線がすぐ見つかるかどうかです。トップページから数回たどらないとコードに届かない構成であれば、順序を見直しましょう。装飾に費やす時間があるなら、READMEの記述に回したほうが評価につながります。

技術選定の理由を説明できない

面接でなぜその技術を選んだかを聞かれ、答えられない状態です。生成AIの普及で完成度そのものでは差がつきにくくなった分、この質問の比重は上がっています。

答えられる状態にしておきたいのは、次の内容です。

1. なぜこの題材を選んだか
2. どの技術を比較し、何を決め手にしたか
3. 実装しなかった機能と、その理由
4. 詰まった箇所と、どう解決したか
5. 今から作り直すなら、どこを変えるか

動くものができていても、中身を理解していなければ質問された時点で見抜かれます。説明できるかどうかは、作るときの意識で決まります。 検討した候補と選んだ理由をその場で記録しておけば、あとから思い出す必要はありません。

生成AIを使って実装すること自体は問題になりません。どこを任せて、どこを自分で書いたか、その判断基準を説明できる状態にしておきましょう。使ったことを隠すほうが、整合しない受け答えにつながって不利になります。

テックゴーのアドバイザーによると、面接で評価が伸びるのは、選んだ技術の良さを説明できる人よりも、選ばなかった技術の欠点まで話せる人でした。比較した経験がなければ、選ばなかった理由は出てきません。候補を並べて検討した過程そのものが、判断できる人材である証拠として受け取られます。

ポートフォリオを公開するときの4つの注意点

公開する内容によっては、法的な問題や情報の流出につながります。確認しておきたい点は、次の4つです。

• 前職の業務成果物をそのまま載せない
• 守秘義務・NDAの範囲を確認する
• 他人のコードやデザインを無断で転載しない
• 認証情報や個人情報をリポジトリに残さない

それでは、順に見ていきましょう。

前職の業務成果物をそのまま載せない

業務として書いたコードを、そのまま公開するのは避けましょう。著作権が自分にないためです。

著作権法では、会社の指示にもとづいて従業員が職務上作成したプログラムについて、契約や就業規則に別段の定めがない限り会社が著作者になると定められています。

プログラムの場合、他の著作物と違って会社名義で公表されているかどうかは問われません。業務時間内に自分の手で書いたコードでも、権利は勤務先にあると考えておきましょう。

載せられるのは、成果物そのものではなく考え方です。同じ課題を自分で書き直した別の実装として作るか、業務の型だけ借りて扱う内容を架空のものに置き換えるか、コードは出さずに設計の考え方を技術記事として書く方法があります。

とくに気をつけたいのは、業務システムの画面キャプチャ、実在の帳票、項目名、取引先の名称です。これらは差し替えれば済む部分なので、必ず架空のものに置き換えましょう。

守秘義務・NDAの範囲を確認する

著作権とは別に、業務で知った情報の扱いにも制約があります。多くの企業は入社時に秘密保持の誓約書を交わしており、その効力は退職後も続くのが一般的です。

不正競争防止法では、営業秘密を秘密として管理されていること、事業に有用な情報であること、公然と知られていないことという3つの要件で定めています。

これらを満たす情報を持ち出したり使用したりした場合、在職中か退職後かを問わず、民事上の責任だけでなく刑事上の責任を問われる可能性もあります。

具体的に避けたいのは、次のような内容です。

• 顧客名や案件名がわかる記述
• システムの構成や内部の仕様に関する詳細
• 業務で扱ったデータそのもの
• 社内でのみ共有されている手順やノウハウ

判断に迷ったら、その情報が社外に出て困るかどうかを基準にしましょう。 少しでも困る可能性があるなら載せない、で問題ありません。手元に誓約書の控えがあれば、公開前に範囲を読み返しておくと確実です。

参考：経済産業省「営業秘密～営業秘密を守り活用する～」

他人のコードやデザインを無断で転載しない

参考にした記事のコードをそのまま貼り付けたり、既存サービスの画面をそのまま複製したりするのは避けましょう。著作権の問題に加え、選考の場では自作かどうかを確認されます。

公開されているライブラリを使う場合は、ライセンスの条件を確認しましょう。多くは利用が認められていますが、著作権表示を残すことや、同じ条件で公開することを求めるものもあります。条件を守れば問題なく使えるため、導入前に内容を読んでおきましょう。

参考にした記事や実装がある場合は、その旨をREADMEに書きます。隠すよりも、どこを参考にしてどこを自分で考えたかを明記したほうが評価は上がります。出典を示せることは、実務でも求められる姿勢です。

なお、既存サービスの機能を題材にする方法自体は問題ありません。作るのは仕組みであって、見た目の再現ではないという線を守りましょう。

認証情報や個人情報をリポジトリに残さない

APIキーやパスワードをコードに直接書いたまま公開すると、第三者に利用されかねません。公開リポジトリは常時スキャンされており、流出した認証情報が短時間で悪用される事例が報告されています。

公開する前に、次の点を確認しましょう。

• 認証情報は環境変数として外に出す
• 設定ファイルは除外の対象に加える
• 過去のコミット履歴にも残っていないか確認する
• サンプル用の設定ファイルを別途用意する

とくに3つ目は見落としがちです。現在のファイルから消しても、履歴をたどれば読み取れる状態が残ります。 一度でも公開された認証情報は流出したものとして扱い、削除ではなく再発行で対応しましょう。

なお、コード管理サービスには認証情報の検出機能があり、公開リポジトリでは無料で使えます。プッシュの時点でブロックする設定も用意されているため、有効にしておくと事故を防げます。

あわせて、テスト用に入れたデータにも注意してください。実在する氏名やメールアドレス、自分以外の個人情報が含まれていないか確認しておきましょう。

面接で評価されるポートフォリオに関する質問ならテックゴー

ポートフォリオを用意しても、それが応募先の求める内容と噛み合っていなければ評価にはつながりません。

どの技術を見せるべきか、前職の経験をどこまで出してよいか、そもそも用意する必要があるのか。こうした判断は、応募先の選考基準を知らないまま自分だけで決めるのが難しい部分です。

テックゴーは、エンジニアとITコンサル領域に特化した転職エージェントとして、企業ごとの選考の実情を踏まえたうえで、伝え方の整理からお手伝いします。

• エンジニアとITコンサル領域に特化しており、上流工程の求人を多数保有している
• 平均年収アップ金額は138万円と、収入アップの実績が豊富にある
• 年収交渉の成功率は100%で、交渉をすべて代行してもらえる
• アドバイザーは元エンジニアやITコンサル出身者が多く、技術の話がそのまま通じる
• 面接対策は回数無制限で、制作物の説明の仕方まで一緒に整理できる

技術の話が通じる相手に見てもらうと、自分では気づけない強みが見つかることがあります。まずは現在の経歴とスキルを一度整理するところから、気軽にご相談ください。

まとめ

この記事では、エンジニアのポートフォリオについて、掲載する項目から作成の手順、職種別の題材、公開時の注意点までを解説しました。

実務経験がある方の場合、選考でポートフォリオの提出を求められる場面は多くありません。ただし、生成AIの普及によって動くものを短時間で用意できるようになった結果、評価の重心は完成度そのものから、なぜその設計にしたのかを説明できるかどうかへ移っています。

大切なのは、作り込むことよりも判断の過程を残すことです。検討した技術の候補と選んだ理由、実装しなかった機能とその背景、詰まった箇所とその解決方法などの記録があれば、面接での説明もそのまま組み立てられます。制作期間は2〜4週間を上限に置き、動く状態になったら公開して、そのあとで育てていきましょう。

一方で、前職の成果物の扱いや、応募先が求める技術との噛み合わせは、自分ひとりでは判断しづらい部分でもあります。用意すべきかどうかを含めて迷っているなら、選考の実情を知る相手に相談してみるのがおすすめです。

テックゴーは、エンジニアとITコンサル領域に特化した転職エージェントです。元エンジニアやITコンサル出身のアドバイザーが多く在籍しており、技術の話を前提にしたうえで、経歴の伝え方から面接での説明の仕方まで一緒に整理します。