エンジニアのポートフォリオの作り方は？未経験でも実力が伝わる作品と見せ方

GitHubのアカウントはある。作りかけの自作サービスもある。それでも応募ボタンの手前で手が止まり、代表作選びだけが先送りになりがちです。

選考や商談でポートフォリオを開く人は、どこを見ているのでしょうか。

見ている点は多くありません。動くものがあるか、どこまで自分がやったか、なぜその技術を選んだか。作品の数より、任せて最後まで仕上げられる再現性が伝わるかで決まると想定して組み立てます。

この記事はフロントエンド、バックエンド、インフラ、データのエンジニア職向けです。LPやコーポレートサイトの制作が中心の方は、別記事のほうが近い内容になります。

扱うのは職種別の見せ方、READMEの実物例、公開前のNG、転職と受注の分岐、2本立ての進行表、提出前チェックです。

まずは手元のリポジトリを一覧にして、並べ替えるところから。

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

エンジニアのポートフォリオは、作った成果物とソースコードをまとめ、実力をその場で確認できる形にしたものです。読み手になるのは、応募先の採用担当か、仕事を任せるかどうかを判断する発注者です。

紙の書類と違い、書いてあることを開いて確かめられます。デモURLを開けば動作が見え、リポジトリを開けばコードの書き方が見えます。

比べる相手	その書類・作品が伝えるもの	エンジニアのポートフォリオとの違い
履歴書・職務経歴書	経歴、所属、担当してきた業務の範囲	経歴の中身をコードとデモで裏づける
デザイナーのポートフォリオ	完成したビジュアルそのものと並べ方	評価の重心はコードの読みやすさと技術選定

職務経歴書なら「ECサイトの改修を担当」の1行で済む内容が、ポートフォリオでは画面・コード・技術選定の理由まで展開されます。見栄えのよいテンプレートに並べても、コードとデモが確認できなければ判断は進みません。

実務経験が浅いほど、この確かめられる形が効いてきます。経歴の行数で勝負できない代わりに、動くものと考えた過程で見てもらえるからです。

作らなくてよい場合もある

全員に要るわけではありません。実務3年以上で、職務経歴書に設計判断と改善の記録まで書けるなら、優先度は下がります。応募先が提出を求めていない場合も同じで、その時間は職務経歴書の解像度を上げるほうに回せます。

一方、未経験や実務1〜2年目、これから受注を増やす段階では話が変わります。経歴で語れない部分を、動くものが肩代わりするからです。

職種をまたいだ全体像から確認したい場合は、ポートフォリオの作り方は職種別でどう違うかもあわせて読んでみてください。

ポートフォリオに載せる基本の6項目

載せる項目は6つです。制作物の概要、ソースコード、公開URL、工夫点と技術選定の理由、経歴と技術スタック、連絡先。職種が変わっても、この大枠は共通です。

項目	書く内容	読み手が確かめること
制作物の概要	何を解決するものか、誰が使うか	目的を言語化できているか
ソースコード	リポジトリのURL、主要ファイルの場所	読みやすいコードを書けるか
公開URL（デモ）	実際に触れる環境、テスト用アカウント	動くところまで仕上げられるか
工夫点と技術選定の理由	つまずいた点、選んだ理由、代替案	自分で考えて選べるか
経歴と技術スタック	経験年数、使用言語、担当範囲	依頼できる領域はどこか
連絡先	連絡手段、稼働状況や返信の目安	連絡が取れるか

抜けると評価しづらくなるのは、ソースコードと公開URLの2つ。どちらも言葉ではなく現物で確認できる項目だからです。

チーム開発の作品なら、自分の担当を書き添えるだけで印象が変わります。「認証まわりのAPI実装とテストを担当」のように範囲を限定したほうが、全体を曖昧に名乗るより伝わります。

同じテーマの作品が並んだときに差がつくのは、次の3点です。

• 独自性：自分が困ったことを題材にすると、作った理由をそのまま説明できます
• 需要のある技術：応募先や案件で使われている技術を含めると、読み替えの手間が減ります
• 読みやすいコード：命名、ディレクトリ構成、コミット単位まで見られます

選考の評価観点を公開している企業の例

読み手がコードを一行ずつ精読するとは限りません。とはいえ、どこを見ているかは公開情報からある程度たどれます。

次の2件は、企業のテックブログで公開された記述です。どちらもポートフォリオの評価基準として公開されたものではありません。

公開元（ブログ名）	公開されている記述	何についての観点か
QUO CARD Digital Innovation Lab（株式会社クオカード、2024年3月公開）	指定技術スタックの適用、フレームワークやライブラリの適切な利用、実行可能性、仕様に沿った動作、変数名やクラス名・関数名が実態を明確に反映しているか、Null安全性、コードフォーマットの整合性、再代入しないなどベストプラクティスの遵守、オーバーエンジニアリングしていないか、適切な単体テストが作成されているか	選考で提出するコーディングテストの採点観点
クロスマート Tech Blog（2023年9月公開）	自社のフロント技術と近しい技術の知識や経験、自走力（開発をある程度進められる意味）、自走力（技術研鑽の意味）、軟技能（コミュニケーション能力、問題解決能力等）	面接に開発メンバーとして同席した一エンジニアの所感

表の語は各社の原文どおりです。「軟技能」は、チームでの伝え方や協働の姿勢にあたる部分だと読み替えてください。

クオカード側が見ているのは提出されたコードの中身、クロスマート側は面接での受け答えです。2件を合わせて読むと、動くこと、読めることは両方に出てきます。

自分で調べて進められるか、を挙げているのはクロスマートだけです。少なくともこの2件では、機能の多さや技術名の新しさは挙がっていません。

細部まで見る選考もあります。クオカードの観点にはNull安全性やコードフォーマットの整合性も並んでおり、提出物の種類で読み方は変わると考えておくほうが安全です。

発注者が何を見ているかを明文化した公開資料は見つけられませんでした。受注の場面について書いた部分は、公開情報からの推論です。

経験の段階で変わる重心

同じ項目を並べても、前に出すものは段階で変わります。

段階	前に出すもの	補足として置くもの
未経験・学習中	自作サービス、学習記録、技術記事	職歴、保有資格
実務1〜2年目	業務で扱った技術と担当範囲、個人開発	学習中の技術
実務3年以上	担当した設計判断と改善の記録	学習教材の成果物

実務1〜2年目なら、業務で使った技術を職務経歴として書き、その裏づけに個人開発を置く並びが素直です。業務そのもののコードを載せる場合は、後半の注意点を先に確認してください。

ポートフォリオの作り方の5つの手順

作り方の流れは、次の5手順に整理できます。上から順に進めれば、途中で手が止まりにくくなります。

1. 載せる制作物を決める
2. ポートフォリオの置き場所を選ぶ
3. ソースコードとデモURLを公開する
4. 経歴と技術スタックを書く
5. 公開して更新し続ける

つまずきやすいのは1つ目です。新しい作品を作り始める前に、いまあるリポジトリを棚卸ししてください。

載せる制作物を決める

手持ちのリポジトリを、まず全部並べてください。並べ替える軸は1つ、応募先や案件で使う技術に近いかどうか。目安は代表作3〜5点です。

多いほど強いわけではありません。読み手が最初の1点で判断をやめることもあると想定して、順番を決めます。

基準は3つ。動く状態まで持っていけるか。担当範囲を説明できるか。応募先や案件と技術が重なるか。

チュートリアルをなぞっただけのものは、改造を足して自分の判断を入れてから候補にします。並び順は読み手が見ていく順序になるので、いちばん自信のある1点を先頭に置いてください。

代表作3〜5点という数は、本記事で置いた運用目安です。応募先が指定する提出数があれば、そちらが優先されます。

ポートフォリオの置き場所を選ぶ

代表作を並べる場所は、作品ごとのデプロイ先とは別に決めます。ここを先に決めないと、作品ができても応募フォームのURL欄に貼るものが定まりません。

置き場所	作成コスト	更新のしやすさ	向いている用途	URLの渡しやすさ
GitHubプロフィールREADME	低い、ファイル1つ	リポジトリを編集するだけ	転職	ユーザー名のURL1本で済む
Notionの公開ページ	低い	画像や図を貼りやすい	転職と受注の両方	共有リンクを発行して渡す
自作の1枚サイト	高い、実装と運用が要る	デプロイの手間がかかる	受注	独自ドメインで渡せる
ZennやQiitaのプロフィール	低い	記事が主役になる	転職、学習の記録	プロフィールURL1本
クラウドソーシングのプロフィール	低い	サイト内の入力欄で完結	受注	相手はサイト内で見るため外部へ飛ばない前提
転職サービスの職務経歴欄	中くらい	サービス内で完結	転職	相手が会員でないと見えないことがある

GitHubのプロフィールREADMEは、ユーザー名と同じ名前のパブリックリポジトリのルートに、中身のあるREADME.mdを置くと表示されます。

2020年7月より前に同名のリポジトリを作っていた場合は自動では表示されず、リポジトリで「プロフィールで共有」を押す操作が要ります。

実務1〜2年目で転職を優先するなら、プロフィールREADMEに代表作へのリンクを並べる形で足ります。見た目そのものを売るフロントエンドや、名刺代わりのURLが要る受注の場面だけ、1枚サイトを足せば十分です。

応募フォームのURL欄には、原則としてこの置き場所のURLを1本だけ貼ります。GitHubの記入欄が別に用意されているフォームなら、そこにはリポジトリのURLを入れてください。

ソースコードとデモURLを公開する

公開設定に切り替える前に、コミット履歴をスキャンします。プライベートで育てたリポジトリをPublicにする瞬間が最も事故が起きる地点で、手順は後半のNG節にまとめました。

スキャンを終えたら、READMEの冒頭からデモURLへ飛べるようにします。ログインが要るサービスなら、テスト用アカウントを用意しておくと、その場で触ってもらえます。

公開先は作品の型で選ぶと迷いません。

代表作の型	向いている公開先	避けたい構成
静的サイト、SPA	Cloudflare Pages、Vercel（用途に注意）	サーバー側の処理を無理に押し込む
API付きWebアプリ	Render、Cloudflare Workers	初回表示が遅いまま放置する
DBを使うアプリ	Supabase、Neon	接続情報をコードに直書きする
分析ノートブック	GitHubのリポジトリに.ipynbを置く	生データを一緒に公開する

分析ノートブックをGoogle Colabの共有リンクだけで渡すと、共有範囲の設定漏れで相手が開けない事故が起きます。GitHubは.ipynbをそのまま表示するので、リポジトリを主にしてColabのリンクは補助に回すほうが確実です。

無料枠の条件は改定されます。そこで、主要6サービスの現況を同じ日に各社の公式ページで確認し、一覧にしました。

サービス	2026年8月11日に公式ページで確認した内容	デモ運用への影響
Cloudflare Pages	無料プランはビルド500回/月、1サイト20,000ファイル、1ファイル25MiBまで	スリープはなし。効いてくるのはビルド回数と同時ビルド数
Vercel（Hobby）	非商用の個人利用に限定。報酬を受けてサイトを制作・更新・ホストする行為は商用扱い。Fast Data Transferの目安は月100GB	受注の窓口サイトやクライアント案件の設置は有料プランか他社へ
Render	750インスタンス時間/月。受信がない状態が続くとスピンダウンし、復帰には数十秒〜1分ほどかかる。無料のPostgresは作成から一定期間で期限切れになる	初回表示の待ち時間と、DBの期限切れを前提に組む
Fly.io	新規顧客へのプラン提供は終了。従来の無料枠は旧Hobby等の既存組織にのみ残る	これから始める人は従量課金。無料前提で選ばない
Supabase	無料プランは活動が少ないプロジェクトを一時停止することがある	停止するとデモが開かない。応募前に復帰させる
Neon	無料プランはストレージ0.5GB/プロジェクト。アイドル状態が続くと自動停止し、無料プランでは解除できない	停止からの復帰は速く、初回の待ちだけ見込む

出典：Render 無料プラン／Cloudflare Pages 制限／Vercel フェアユース。あわせてFly.io 料金／Supabase 本番移行前チェック／Neon プランも参照。

商用利用の線引きは、受注に寄せる人ほど先に確認してください。Vercelの無料プランは非商用の個人利用が前提で、報酬を得た制作物や受注営業の窓口サイトは有料プランか他社に置きます。

Cloudflareは100サイトを超える用途にWorkers側を案内しているため、規模が大きくなる場合も公式で確認します。

スリープする環境に置くなら、動作を撮ったGIFか短い動画をREADMEの先頭に添えます。起動待ちの間に離脱されても、何が動くかは伝わるからです。公開後は自分のスマートフォンからも開き、表示崩れやエラーが出ないかを見ておきます。

経歴と技術スタックを書く

技術スタックは、使ったことがあるものと、実装まで担当したものを分けて書きます。ひとまとめにすると、面接で認識のずれが出ます。

• 実装できる：ゼロから設計して書いた経験がある
• 業務で使用した：既存コードの改修や部分的な実装を担当した
• 学習中：学習教材や個人開発で触れた段階

経歴は、期間・チーム人数・自分の担当を1行で書くと読みやすくなります。「5名のチームで6か月、管理画面のフロントエンド実装を担当」のように、範囲を限定した書き方が伝わります。

公開したあとに更新し続ける

公開して終わりにすると、READMEの内容と実際のコードがずれていきます。月に1回程度を目安に、リンク切れ、依存パッケージの更新、デモの動作を見直す時間を取ってください。

応募先や案件に合わせて、先頭に置く作品を入れ替えるのも有効です。1つのポートフォリオを全提出先で使い回すより、順番と説明文だけ差し替えるほうが手間の割に効きます。更新履歴が残ること自体も、手を動かし続けている証拠になります。

職種別に変わる作品の見せ方

エンジニアとひとくくりにされがちですが、見せるべき対象物は職種で変わります。読み手が最初に開く場所も違います。

6項目の骨格は職種が変わっても同じです。変わるのは、その上に何を1点足すか。フロントなら操作感、バックエンドならテスト、インフラなら構成図、データなら前処理の記述です。

フロントエンドは表示と操作感で見せる

読み手はまずデモURLを開き、次にコードを見ます。だから最初の1画面が作品そのものです。

見せどころは、画面の見た目よりも操作したときの挙動にあります。入力エラーの出し方、読み込み中の表示、スマートフォンでの崩れの有無といった、実務で問われる部分を整えておきます。

表示速度に手を入れたなら、どこを直したかを短く添えてください。測定した数値がないなら、手を入れた箇所だけを事実として書き、効果は断定しない書き方にします。

なお、コーポレートサイトやLPの制作が中心の方は、評価される観点が異なります。受注を前提とした見せ方はWeb制作のポートフォリオの作り方にまとめています。

バックエンドはAPI設計とテストで見せる

画面が地味になりやすい職種なので、リポジトリの中身で語ります。READMEにAPIの一覧と、リクエストとレスポンスの例を載せると、読み手の負担が減ります。

見られるのは、エンドポイントの切り方、エラー処理、認証の実装、そしてテストの有無です。テストコードが1つでも入っているだけで、業務での扱いやすさの印象が変わります。

データベース設計を載せるなら、ER図を画像で置いてください。テーブル名の付け方や正規化の判断は、そのまま設計力の説明になります。

インフラは構成図とコードで見せる

成果物が画面に出ない職種なので、読み手が最初に開くのは構成図です。どのサービスをどうつないだのかが、1枚の図で分かる状態にします。

そのうえで、構成をコードで管理した記録を置きます。TerraformやAnsibleなどの設定ファイルをリポジトリに残し、READMEに構築手順を書けば、再現できる形になります。

• 構成図（クラウドサービス名とネットワークの区分が分かるもの）
• IaCのコードと実行手順
• 監視・バックアップの設定と、その理由

無料枠や手元の検証環境で組んだ構成でかまいません。読み手が見たいのは規模ではなく、なぜその構成にしたかの説明だからです。

データは前処理と可視化で見せる

分析職では、きれいなグラフより、そこに至る前処理の記述が読まれます。欠損値の扱い、外れ値の判断、特徴量の作り方といった判断が中身だからです。

ノートブック形式で公開し、セルごとに何をしたかのコメントを残してください。使ったデータの出所は、分析結果そのものより先に問われます。公開データを使う場合は、利用条件の範囲内かを確認してから載せます。

結論は、図とあわせて1〜2文で言い切ります。読み手が最初に知りたいのは、その分析で何が分かったのかです。

READMEで実力を伝える

リポジトリを公開するだけでは、読み手はどこから見ればよいか分かりません。READMEは作品の入口であり、ここの出来で読まれるかどうかが決まります。

GitHubの公式ドキュメントは、READMEに含めるとよい情報を挙げています。プロジェクトが行うこと、有益な理由、使い始め方、ヘルプの入手先、メンテナンス者とコントリビューターの5つです。

この並びは、そのまま作品紹介の骨格として使えます。出典：GitHub Docs READMEについて

READMEに書く項目の雛形

次の順で書くと、読み手が上から読むだけで判断できます。

1. 概要：何を解決するものかを1〜2文で。長い前置きは置きません
2. スクリーンショットまたはGIF：動いている状態を最初の1画面で見せます
3. デモURL：テスト用アカウントがあれば併記します
4. 使用技術：言語、フレームワーク、データベース、インフラを箇条書きに
5. 技術選定の理由：なぜそれを選んだか、比較した候補は何か
6. 工夫した点と課題：つまずきと、その解決方法
7. セットアップ手順：手元で動かすための最小限のコマンド
8. 今後の予定：未実装の機能を正直に書きます

上から3つ目までで読むのをやめる人がいると想定して、概要・画像・デモURLを先頭に固めます。

枠だけでは書き出しにくいので、埋めたあとの状態を1本置きます。個人開発の予約管理アプリを想定した記入例で、架空のプロダクトです。実際のREADMEでは、太字にしたラベルの位置に ## デモ のような見出しを書きます。

デモ用のアカウントは、閲覧と作成だけに権限を絞った専用のものを用意してください。実在の個人情報は入れず、他のサービスと同じパスワードも使いません。

書き込みができるデモなら、データを定期的にリセットする仕組みを入れておきます。メール送信や決済、外部通知はダミーに差し替えます。

サンプルの使い方は単純で、太字ラベルの下の中身を自分の情報に置き換えるだけです。リポジトリ内の別ファイルを参照するときは、相対リンクで書くとクローンした人の手元でも開けます。

技術選定の理由はビフォーアフターで直す

この項目は、書き換え前と後を並べると差がはっきりします。

悪い例：「Reactを使いました。状態管理にはReduxを使っています。」

良い例：「一覧画面で絞り込みのたびに全件を取り直しており、操作するたびに待ち時間が出ていました。取得済みのデータをクライアント側に保持し、絞り込みは手元の配列で処理する形に変えました。結果として、絞り込みの操作で通信が発生しなくなりました。」

違いは、課題・手段・結果の3文になっているかどうか。この型は職種を問いません。データ職なら「毎回手作業で集計しており、月末に半日かかっていた。取得と整形をスクリプトにまとめ、日次で実行するようにした。集計作業がなくなり、確認だけで済むようになった」と書けます。

採用した技術の名前ではなく、その技術を選ばせた課題が書いてあるかが読まれます。測った数値があるなら添え、測っていないなら効果は断定せず、変えた事実だけを書いてください。

技術選定の理由は面接や商談でそのまま質問されます。書く内容は、自分の言葉で説明できる範囲に収めます。

生成AIを使った部分の書き方

生成AIで書いたコードを載せてよいかどうかは、書き方しだいです。ただし、その前に確認することがあります。

応募先や案件側が、AI利用の可否や申告方法を定めている場合があります。選考要項や募集要項を先に読み、利用が認められない選考に気づかないまま進める事態を避けてください。

利用を隠さない：使った範囲をREADMEに1行で書きます。記載例は「画面の雛形生成にAIを使用。データモデルと権限設計は自作で、生成コードは全て読み合わせて修正しています」です。

全行を説明できる状態にする：意味の分からないまま残っているコードは、面接でそこだけ質問されると崩れます。読んで説明できない行は、消すか書き直すのが安全です。

設計判断と検証で差を出す：AIが書ける範囲が広がるほど、評価の重心は「なぜその設計にしたか」と「どう検証したか」に移ると考えて準備しておくと安全です。テストを書いた範囲、レビューで直した点、選ばなかった案をREADMEに残しておくと、この2つが伝わります。

GitHubで見られる場所

READMEの外側も見られます。ソースコードの管理の仕方に、日々の作業の質が出るためです。

見られる場所	良い状態	避けたい状態
コミット履歴	変更単位が小さく、メッセージで内容が分かる	「update」だけが並ぶ、1コミットに全機能
ブランチ運用	機能単位で分かれ、マージの流れが追える	mainへの直接コミットのみ
Issue、プルリクエスト	課題と対応が記録されている	記録がなく経緯が追えない
README	冒頭で概要とデモに到達できる	初期生成のまま放置
デモ	URLを開くと動く	リンク切れ、エラー画面

個人開発でもIssueを立てて自分で潰していけば、進め方の記録が残ります。公開したかどうかではなく、公開の質で差がつく部分です。

実務経験が少なくても作品をそろえる方法

作品がゼロの状態から、いきなり自作サービスを完成させようとすると途中で止まりやすくなります。段階を踏むほうが、結果的に早く形になります。

• 写経：教材どおりに手を動かし、書き方と全体像をつかむ段階
• 改造：写経したものに機能を足し、自分の判断を入れる段階
• 自作サービス：自分が困っていることを題材に、ゼロから設計する段階
• OSS貢献と技術記事：他者のコードに関わり、学びを外に出す段階

ポートフォリオに載せる価値が生まれるのは、改造の段階からです。写経したままの成果物は他人の設計をなぞった記録であり、判断の跡が残らないからです。

職種別の題材カタログから選ぶ

題材が浮かばないまま「何か作らないと」と考えても手は動きません。職種ごとに、着手しやすい題材を3つずつ挙げます。制作の目安は本記事で置いた想定で、平日夜と週末に手を動かす前提です。

職種	題材	制作の目安	入れると評価される機能	陳腐化しやすい点
フロントエンド	世帯で入力を分担する家計アプリ	2週間程度	画面を先に更新し、失敗したら元に戻す作り	ToDoアプリ単体は差がつかず、共有か権限を足す
フロントエンド	条件で絞り込める求人一覧	週末2日程度	URLに条件を持たせた検索とページング	見た目の模写だけで終わる
フロントエンド	入力しやすさを詰めた予約フォーム	週末2日程度	キーボード操作と読み上げへの対応	入力チェックが未実装のまま
バックエンド	予約や在庫の重複を防ぐAPI	2週間程度	トランザクションと一意制約、APIテスト	作成と削除だけのAPIは差がつかない
バックエンド	画像アップロードの非同期処理	2週間程度	キューと再試行、失敗時の通知	同期処理のままで設計の話ができない
バックエンド	権限つきの社内メモ共有	3週間程度	役割別の権限とトークンの失効	ログイン機能だけでは既製品と比べられる
インフラ	静的サイトのCI/CD一式	週末2日程度	テストとデプロイの自動化	手動デプロイのままでは題材にならない
インフラ	コンテナ構成のIaC化	3週間程度	ネットワークから再現できる構成コード	管理画面の手作業スクリーンショットだけ
インフラ	監視とアラートの構成	2週間程度	メトリクス収集、通知、障害時の手順書	構成図だけで運用の記述がない
データ	公開統計を使った地域比較の可視化	週末2日程度	前処理の再現手順とデータ出所の明記	グラフだけで判断の記述がない
データ	テキスト分類の小さなモデル	2週間程度	評価指標の選び方と誤分類の分析	精度の数字だけを載せる
データ	定期取得と集計のパイプライン	2週間程度	スケジュール実行と差分更新	利用条件を確認しないままの取得

題材そのものより、右の2列を説明できるかで評価が変わります。足した機能と、避けた陳腐化。この2つが言えれば、題材の派手さは要りません。

作品がまだない段階の代替アウトプット

作品が仕上がるまでの間も、示せるものはあります。学習の記録は、続ける力の裏づけとして読まれます。

ZennやQiitaでの技術記事は、つまずきと解決を言語化する練習にもなります。記事のURLをポートフォリオに添えれば、説明する力の手がかりになります。

OSSへの小さなプルリクエストも有効です。ドキュメントの誤りの修正や翻訳の追補から始められます。ハッカソンや勉強会での登壇も、日付と内容が残っていれば実績として書けます。

模写やチュートリアルを載せるときの注意

模写やチュートリアルの成果物を載せること自体は問題ありません。ただし、どこまでが教材どおりで、どこからが自分の実装かを明記してください。書かないまま並べると、他人の成果を自分の実力と誤認させる形になります。

READMEに「◯◯の教材をもとに作成し、検索機能とテストを追加」と1行入れるだけで済みます。この1行で、正直さと自分の担当範囲の両方が伝わります。

転職用と受注用で変わる見せ方

同じ作品でも、読む人が変われば知りたいことが変わります。転職の選考担当が見るのは技術の幅、発注者が見るのは頼んだときに困らないかどうかです。

比較する点	転職・就職用	フリーランス・副業の受注用
読む人	採用担当、現場のエンジニア	発注担当、事業主
重視される点	技術の幅と深さ、コードの質	納品までの進め方、連絡の取りやすさ
先頭に置くもの	代表作とGitHub	実績と対応できる範囲
添える情報	技術選定の理由、テスト	稼働状況、担当範囲、連絡手段
想定される次の場面	技術面接での深掘り	見積もりと契約の相談

転職と受注のどちらに寄せるかを決める

迷ったら、次の4問にYesかNoで答えてみてください。

1. 半年以内に、正社員での転職活動を予定しているか
2. 実務が未経験、または1年未満か
3. 週20時間以上を、安定して確保できるか
4. 単価よりも技術の幅を伸ばしたいか

回答の組み合わせで、進むルートが決まります。週20時間という線引きは、本記事で置いた目安です。

回答の傾向	進むルート	先頭に置く作品	省いてよい項目
1と2がYes	転職優先	設計の説明を長く書ける自作サービス1点	料金の考え方、稼働できる時間帯
1がNo、2もNo、3がYes	受注優先	納品物の形に近い制作物（LP、業務改善ツール）	技術選定の細かい比較、テスト戦略の詳述
1がNoで2がYes	まず改造1点と自作1点を作る	動く状態まで仕上げた1点目	料金表、対応可能な稼働時間
1と3がYesで4がNo	転職を軸に、受注実績を1件だけ足す	自作サービス、その次に受注案件1件	受注用の料金表、対応可能な稼働時間
1も3もNo	1点目を仕上げることに絞る	いま手元でいちばん進んでいる1点	3点そろえる前提の並び順の検討

寄せ先が決まったら、代表作3点の組み合わせもそれに合わせます。

職種	転職に寄せる3点	受注に寄せる3点
フロントエンド	自作Webアプリ＋既存教材の改造＋技術記事1本	実案件に近いLPか管理画面＋自作Webアプリ＋改修前後の比較
バックエンド	API付きサービス＋テストを足した改造＋OSSのプルリクエスト	API付きサービス＋業務改善ツール＋OSSのプルリクエスト
インフラ	構成図つきのIaC＋CI/CD一式＋監視の構成	CI/CD一式＋移行やコスト削減の記録＋運用手順書
データ	公開統計の分析＋小さな分類モデル＋技術記事1本	定期取得と集計のパイプライン＋可視化＋分析レポート1本

どのルートでも作り直しは要りません。変えるのは並び順と、添える説明文の2つだけです。

転職用は技術面接の導線に合わせる

書類選考の段階では、開かれる時間は短いと想定しておきます。作品名と1文の概要、使用技術、デモURLが上から順に並んでいる状態を目指してください。

技術面接では、READMEに書いた内容がそのまま質問になります。技術選定の理由、つまずいた点、もう一度作るならどう変えるか。この3つは口頭で説明できるところまで準備します。

書いたことは、ほぼ確実に質問の入口になります。だから並べる技術は、説明できる範囲に絞ってください。理解が浅いものを1つ足すより、深く話せる1つを先頭に置くほうが選考は進みます。

受注用は頼んで大丈夫かに答える

発注者が知りたいのは、コードの美しさより期日までに仕上がるかどうかです。実績の並びに加えて、対応できる範囲・稼働できる時間帯・連絡手段を書き添えます。

クラウドソーシングでは、提案文の中身がそのままポートフォリオの代わりになります。各サイトの特徴はクラウドソーシングサイトの比較にまとめました。

書く順番は決まっています。冒頭3行で案件との一致点と類似実績のURL、次に担当範囲と進め方、最後に稼働時間と連絡手段。次は架空の案件（飲食店向け予約フォームの改修）に対する記入例です。

進め方の1番目に置いた初回のすり合わせは、提案の通過率を左右します。何を聞くかは初回打ち合わせで確認することにまとめました。

金額の決め方に迷うなら、フリーランスの単価相場を先に見ておくと、レンジの根拠を自分の言葉で言えるようになります。

実績が1件も公開できない段階でも、貼るものはあります。自作サービスをデモURL・画面・手順書とセットにして、納品物と同じ形で見せる方法が1つ。

受注済みの案件なら、画面のみ掲載でよいかを先方に確認します。許諾が取れるまでは、案件名を伏せた担当範囲と使用技術の記述で代えてください。

掲載可否は契約前の一言で決まる

受注した仕事をポートフォリオに載せられるかどうかは、契約前の一言で決まります。納品後に「載せていいですか」と聞くと、断られたときに打つ手が残りません。

見積もりの段階で、こちらから掲載の可否を切り出してください。「画面のみ」「社名は伏せる」「公開は納品の3か月後から」と折衷案を先に出すと通りやすく、決まった内容は書面に残します。

受注前に確認する項目は、次のとおりです。

• 業務内容：どこまでが担当範囲か、修正対応は何回までか
• 報酬額：税込か税別か、追加作業が出たときの単価
• 支払期日：いつ締めて、いつ振り込まれるか
• 納期：着手日と、中間で確認してもらう日程
• 検収条件：何をもって完了とするか
• 知的財産の帰属：著作権を移すのか、二次利用はどこまで可能か
• ポートフォリオ掲載の可否：実績として公開してよいか

このうち業務内容・報酬額・支払期日などは、発注元が事業者なら明示が求められる項目です。知的財産の帰属と掲載可否は法定の明示事項ではなく、自分から切り出して合意する項目になります。

ここを曖昧にしたまま進めると、受注実績が増えてもポートフォリオに1件も載せられない状態になります。

（参考）公正取引委員会の解説によると、取引条件を書面か電磁的方法で明示する義務は、発注側が事業者である場合の義務です。個人の消費者から直接受ける依頼は対象外になります。

報酬の支払期日の定めは、従業員を使用するなど一定の要件を満たす発注事業者が対象で、受注側も従業員を使用していない個人であることが前提です。自分の取引がどれに当たるかは、公正取引委員会 フリーランス法で確認してください。

クラウドソーシング経由は確認する項目が変わる

直請けとプラットフォーム経由では、自衛の中身が変わります。締め日と振込日を発注者に尋ねるのは直請けの話で、クラウドワークスやランサーズでは決済がサイト側にあるからです。

プラットフォーム経由で確認するのは、次の4点です。

1. 仮払いが完了したことを確認してから着手する
2. システム利用手数料が報酬から引かれる前提で見積もる
3. 検収期限による自動検収と、修正回数の上限を読んでおく
4. 外部への実績掲載は、サイトの規約と個別のNDAの両方を見る

公開前に確認したいNGと注意点

作り込むほど見落としやすいのが、公開してよい範囲の確認です。技術的な完成度より、ここが取り返しのつかない領域になります。

無断転載と業務コードの扱い

他社サイトの画像やデザイン、他人が書いたコードを、許諾なく自分の作品として載せることは避けます。参考にした教材や素材があるなら、出所と利用条件を確認してください。

業務で書いたコードは、扱いに注意が要ります。雇用されている人が職務として作ったものは、法人が著作者になる仕組み（職務著作）の対象になります。

プログラムの著作物については、法人名義で公表するという要件が不要とされています。つまり、社内でしか使っていないコードでも法人が著作者となる場合があります。出典：文化庁 著作権テキスト 令和7年度版

業務委託で書いたコードは前提が違います。契約に譲渡の定めがなければ、著作権は受託した側に残るのが原則です。

ただし著作権が自分にあっても、守秘義務の条項や、画面と顧客名を出してよいかは別の話です。実際の掲載可否は、そちらで決まります。

掲載の可否は自己判断せず、雇用契約や就業規則、業務委託契約の条項を確認してください。判断がつかないときは、所属先の担当窓口や専門家に相談を。この記事では一般的な注意点の紹介にとどめます。

守秘義務と、リポジトリに残る認証情報

顧客名、システム構成、未公開の施策など、業務で知った情報には守秘義務がかかることがあります。契約書に秘密保持の条項が入っていないかを確認するのが先です。

実務経験を見せたいなら、案件名を伏せ、担当範囲と使用技術だけを抽象化して書く方法があります。「toB向け予約システムのAPI実装を担当」といった粒度なら、具体的な情報に踏み込まずに経験を示せます。

エンジニア特有の落とし穴が、公開リポジトリに残る認証情報です。APIキー、アクセストークン、本番環境の接続先、実在の個人情報を含むテストデータ。直近のファイルから消しても、コミット履歴に残っていれば読み取れます。

公開設定に切り替える前に、次の3ステップで確認します。

1. スキャンする：gitleaksやtrufflehogで、作業ツリーだけでなくコミット履歴まで検査します
2. 履歴から除去する：見つかったらgit filter-repoかBFG Repo-Cleanerで履歴を書き換えます
3. キーを失効させて再発行する：対象のキーやトークンを無効化し、新しいものを発行します

2番目には続きがあります。強制プッシュしても、古いコミットはサーバー側に残り、コミットのSHAをたどれば読める状態が続きます。

そこでGitHub Supportに連絡し、参照の解除とキャッシュされた表示の削除を依頼します。伝えるのは、リポジトリ名、影響したプルリクエストの数、git filter-repoが出力したFirst Changed Commitです。

他人のフォークに渡ったコミットは、GitHub側では消せません。フォークの所有者に個別に依頼する形になり、連絡先はGitHubからは提供されません。

だからこそ、一度公開されたキーは流出したものとして扱い、失効と再発行まで済ませます。除去は再発行の代わりになりません。

再発を防ぐ運用への切り替えも、同じタイミングで済ませます。接続情報は.envに切り出し、.gitignoreに追加してください。

GitHubのSecret scanningは、公開リポジトリでは無料で自動的に動きます。個人アカウント向けのプッシュ保護も既定で有効で、公開リポジトリへのプッシュを止めます。

ただし止まるのは、提供元が発行するトークンなど対応済みのパターンです。自作の署名鍵、DBの接続文字列、実在の個人情報を含むテストデータは止まりません。

非公開リポジトリで同じ検査を使うには有料の製品が要ります。無料の範囲で作業している人ほど、公開前のスキャンを手順として残しておいてください。

作り込みすぎと、公開後の放置

機能を足し続けて完成しない状態は、公開の機会そのものを失わせます。動く範囲を区切り、未実装の部分はREADMEに「今後の予定」として書けば十分です。

逆に、公開後に放置されたポートフォリオも評価を下げます。リンクが切れ、デモが動かず、技術スタックが古いままだと、いまの実力が読み取れません。公開して直し続けている状態そのものが、説明の一部になります。

提出前セルフチェック

提出直前に上から潰せる形にまとめました。前半は公開してよいかの確認、後半は伝わり方の確認です。

公開してよいかの確認(1つでも空欄なら公開しない)

• [ ] gitleaksなどでコミット履歴までスキャンした
• [ ] 接続情報は.envに切り出し、.gitignoreに追加した
• [ ] プッシュ保護が効く状態か確認した（公開リポジトリは既定で有効）
• [ ] 過去に公開したキーやトークンは失効させて再発行した
• [ ] 業務コード、顧客名、社内限りの情報が含まれていない
• [ ] 無断転載の素材（画像、デザイン、他人のコード）がない

伝わり方の確認

• [ ] 各作品の冒頭に、何を解決するものかの概要が1〜2文ある
• [ ] デモURLを開いて動く（別の端末とブラウザでも確認した）
• [ ] ログインが要る作品にテスト用アカウントを書いた
• [ ] チーム開発の作品に、自分の担当範囲を書いた
• [ ] 技術選定の理由が、課題・手段・結果の3文になっている
• [ ] 教材やチュートリアルをもとにした部分を明記した
• [ ] 生成AIを使った範囲を1行で書いた
• [ ] 載せたコードは、全行を口頭で説明できる
• [ ] スマートフォンで開いて、表示が崩れていない
• [ ] READMEと作品ページのリンクがすべて開く
• [ ] 応募フォームに貼るURLを決めた
• [ ] 代表作の並び順が、応募先や案件と重なる技術の順になっている

前半の6項目は、1つでも空欄なら公開しないでください。取り返しがつかない領域だからです。

後半は、空欄になっている理由を自分の言葉で説明できるなら、そのまま提出して構いません。この線引きは本記事で置いた運用目安です。満点を待つと、提出の機会のほうが先に流れます。

手札の量で選ぶ2つの進行表

手元に代表作の候補が2点以上あるなら2週間、1点以下なら4週間で組みます。時間の見積もりは、前章の題材カタログと同じ前提です。平日夜と週末に手を動かす想定で置いています。

どちらの進行表でも、3点そろうのを待たずに応募を始められる地点を用意しました。

既存2点以上なら2週間で仕上げる

日程	やること	目安の時間
Day 1	既存リポジトリの棚卸しと、代表作3点の選定・置き場所の決定	2時間
Day 2	.envと.gitignoreの整理、gitleaksでの初回スキャン、プッシュ保護の確認	2時間
Day 3〜4	1点目のデプロイとREADME作成	合計6〜8時間
Day 5〜9	2点目と3点目のデプロイとREADME作成	1点あたり3〜4時間
Day 10〜11	提出前セルフチェックと、履歴の最終確認	合計2〜3時間
Day 12〜14	技術選定の理由を口頭で説明して録音し、詰まった箇所をREADMEに反映	1点あたり30分

応募を始めてよいラインは、1週目の終わりです。2点のデモが開き、READMEの冒頭3行が書けていれば、3点目を作りながら応募して構いません。

2週間で収まるのは、新しく作らず手元のリポジトリから選ぶ前提だからです。

手札1点以下なら4週間で組む

作りかけが1本だけ、あるいはゼロという状態なら、作る時間を織り込みます。題材は前章のカタログから選びます。

週	やること	目安の時間	応募を始めてよいライン
Week 1	.envと.gitignoreの整理と初回スキャンを済ませ、手元の1点を動く状態まで仕上げてREADMEを書く	8〜10時間	まだ応募しない。1点目のデモが開く状態を作る
Week 2	選んだ教材や既存コードに機能とテストを足し、改造の1点を仕上げる	8〜10時間	2点そろった時点で、応募と提案を始めてよい
Week 3	週末2日で作れる規模の1点を追加し、3点の並び順を決める	8〜10時間	応募と並行。先頭の1点を応募先に合わせて入れ替える
Week 4	提出前セルフチェックと履歴の最終確認、技術選定の理由の録音	4〜6時間	3点そろい、チェックを通過した状態

2週目の終わりで応募を始めるのは、3点目を作る期間に選考の待ち時間を重ねるためです。

録音すると、書けているのに言えない箇所が見つかります。面接や商談で聞かれるのは、まさにその部分です。

まとめ

最初の一歩は、新しい作品作りではありません。手元のリポジトリを一覧にして、応募先や案件に近い順に並べ替えるところからです。

この棚卸しと、置き場所を1つ決める作業は、今日の2時間で終わります。そのうえで、先頭に置く1点のREADMEの冒頭3行を書いてみてください。何を解決するものか、誰のためか、どこで動くか。

この3行が書けた作品から、代表作として提出できる状態になります。

次の1本は、寄せ先で分かれます。転職に寄せるならポートフォリオの作り方は職種別でどう違うかへ、受注に寄せるならWeb制作のポートフォリオの作り方へ進んでください。

よくある質問

ポートフォリオは全員に必要ですか？

必須ではありません。実務3年以上で、職務経歴書に設計判断や改善の記録まで書けるなら優先度は下がります。応募先が提出を求めていない場合も同様で、その時間は職務経歴書の解像度を上げるほうに回せます。未経験や実務1〜2年目、これから受注を増やす段階では、用意しておくと判断してもらいやすくなります。

未経験の場合、作品は何点そろえればよいですか？

代表作3〜5点が運用上の目安です。応募先が提出数を指定していれば、そちらが優先されます。点数を増やすより、動く状態まで仕上がっているか、自分の担当範囲を説明できるかを先に満たしてください。最初の1点で判断が終わることもあるため、いちばん自信のある作品を先頭に置きます。

業務で書いたコードをそのまま載せてよいですか？

自己判断は避けてください。雇用されて職務として書いたコードは法人が著作者になる場合があり、業務委託でも守秘義務の条項が別に関わります。雇用契約や就業規則、業務委託契約の条項を確認し、判断がつかないときは所属先の担当窓口や専門家に相談してください。案件名を伏せ、担当範囲と使用技術だけを書く方法もあります。

生成AIで書いたコードを載せてもよいですか？

使った範囲をREADMEに1行書き、載せたコードを全行説明できる状態にしてあれば、問題になりにくい書き方です。応募先や案件側がAI利用の可否や申告方法を定めていることがあるため、選考要項や募集要項を先に確認してください。読んで説明できない行は、消すか書き直すほうが安全です。

デモの公開先は無料のサービスで足りますか？

多くの場合は足ります。ただし一定時間で自動停止する仕様や、無料プランでの商用利用の制限があるため、応募や提案の直前に必ずURLを開いて動作を確かめてください。報酬を得た制作物や受注の窓口サイトを置く場合は、各サービスの商用利用の条件を公式ページで確認してから決めます。

参考文献・出典

• GitHub Docs READMEについて
• GitHub Docs プロフィールREADMEの管理
• GitHub Docs リポジトリからの機密データの削除
• GitHub Docs シークレットスキャンについて
• QUO CARD Digital Innovation Lab コーディングテストについて
• クロスマート Tech Blog フロント面接に開発メンバーとして参加した所感
• 文化庁 著作権テキスト 令和7年度版
• 公正取引委員会 フリーランス法
• Render 無料プラン
• Cloudflare Pages 制限
• Vercel フェアユースガイドライン
• Fly.io 料金
• Supabase 本番移行前チェック
• Neon プラン

代表作の点数、制作の目安時間、進行表の日数、稼働時間や見直しの頻度、セルフチェックの提出ラインは、本記事で置いた運用目安です。統計にもとづく数値ではありません。

最終更新: 2026-08-11／各サービスの無料枠は2026年8月11日に公式ページで確認。引用した2社の記事の公開時期は表のとおりで、参照日は2026年8月11日です。

この記事を読んだ方におすすめ