エンジニアのポートフォリオサイトは、リポジトリの置き場ではなく依頼の入口。発注者が確かめる4点と、載せ方
案件を取るためのエンジニアのポートフォリオサイトは、コードを並べる場所というより、「この技術課題を、この条件で任せられるか」を読み取ってもらう場所です。GitHubのリンクが貼ってあっても、どれが自分の担当で、どんな体制で、いつから、どのくらい稼働できるのかが書かれていなければ、発注者は問い合わせの前に迷いやすくなります。
2026年9月のCareerChain調査(フリーランス522人、フリーランスの活用経験・予定のある企業の人事・採用担当者508人)では、企業が実力を判断しやすくなる情報の上位は、技術力・専門性のレベル(48.6%)、スキルの再現性・応用力(47.0%)、プロジェクトで担った役割・業務内容(41.1%)でした(リリースに載っているのは3項目です)。この調査は発表元(CareerChain)の自社調査で、企業側の回答者は人事・採用担当者です。エンジニアの発注者全体の傾向とは言い切れないため、目安として読んでください。
1. GitHubがあっても、自分のサイトが要るのはなぜか
GitHubはコードを見せる場所、案件獲得用のサイトは担当範囲と条件まで一か所で読んでもらう場所、という役割の違いがあります。同じ制作物を使っても、載せる情報が変わります。
| 項目 | GitHubのみ | 案件獲得用のサイト |
|---|---|---|
| 載せるもの | リポジトリ、README、更新履歴 | 制作物に加え、担当範囲、技術の範囲、進め方、稼働条件 |
| 読む人が知れること | コードの書き方と更新の頻度 | 同じ種類の依頼を任せられるか |
| 読んだあとの動き | リポジトリを開いてコードを確かめる | 依頼の内容と条件を当てはめて、問い合わせるかを決める |
(上の表は筆者の整理です。)@SOHOの解説では、GitHubのピン留めは最大6件で、READMEは「30秒で概要が把握できる」構成にするとされています(2026年8月更新)。GitHubを使わない、という話ではありません。GitHubのリンクをサイトに置き、サイト側で担当範囲と条件を補う形になります。
2. 発注者が確かめている4点は何か
確かめていると考えられるのは、担った役割、技術の範囲、進め方、稼働条件の4点です。前の2点は上の調査の項目に近く、後の2点は発注の実務から考えた筆者の見方です。
1点目の担った役割は、調査のプロジェクトで担った役割・業務内容(41.1%)に近い項目です。要件の整理から設計、実装、テスト、運用までのどこを担ったのか、チームの人数と自分の位置づけはどうだったのかを書き分けます。「Webアプリを開発しました」だけでは、一人で作ったのか、一部の機能だけを実装したのかが読み取れません。
2点目の技術の範囲は、技術力・専門性のレベル(48.6%)やスキルの再現性(47.0%)に近い項目です。使った言語やフレームワークを並べるだけでなく、その技術でどんな課題を解いたかを1行添えると、再現性が伝わりやすくなります。技術名の並べ方が評価に結びつくかは、調査では確かめられていません。
3点目の進め方について、調査では、企業が実力を評価するときに参考にする情報として、面談での受け答え(60.8%)、スキルテスト・実技課題(46.5%)、経歴書・プロフィール(44.5%)が上位でした。調査に「進め方」に当たる項目はありません。ただ、面談の受け答えがリリース掲載の項目の中で最も高い(60.8%)ことから、面談の前に進め方を文章で読めると、判断材料が増えると筆者は考えます。見積もりの出し方、報告の頻度、レビューの受け方、仕様変更の扱いなどが当たります。
4点目の稼働条件は、稼働できる日数と時間帯、開始できる時期、契約の形態、単価の考え方です。制作物を読み終えた発注者が最初に確かめたくなる情報なので、制作物と同じページに置く意味があります。
実力を伝える・見極めることが難しい理由としては、「面談という短時間・限られた接点では測れない」(55.8%)に次いで、「一緒に働いた人でないと分からない部分があり、その評価・裏づけがない」(44.6%)が挙がりました。コードからは、連絡の速さや納期への向き合い方までは読み取れません。進め方と条件を文章で書くと、その部分を補えます。
3. 案件1件ずつに、何をどの順で書くのか
案件ごとに「概要と課題、役割と体制、技術、成果物、結果と条件」を同じ順に並べます。形がそろっていると、発注者は案件を比べやすくなり、書く側も次の実績を足すときに迷いません。
| 順 | 項目 | 書く内容の例 |
|---|---|---|
| 1 | 概要と課題 | 何のシステムで、どんな課題があったか。例:予約管理を電話からWebに移したい飲食チェーン |
| 2 | 役割と体制 | 担当した工程、チームの人数、自分の位置づけ |
| 3 | 技術 | 言語、フレームワーク、インフラ。選んだ理由が一言あれば添える |
| 4 | 成果物 | 公開できるデモ、画面の画像、リポジトリ |
| 5 | 結果と条件 | 数字で言える結果、期間、稼働の形 |
@SOHOの解説では、READMEには名前と一言説明、スクリーンショットかデモURL、技術スタック、セットアップ手順、アーキテクチャ概要を入れ、差がつく点として作った理由、課題と解決策、「レスポンス200ms以下」のような具体的な数値が挙げられています(2026年8月更新)。サイトの案件ページにも、この考え方を応用できると筆者は考えます。
数字は、発注者の許可と計測の裏づけがあるものだけを書きます。手元に数字がない案件に、無理に数字を足す必要はありません。数字の代わりに、課題と役割が具体的であれば、読み手は再現性を判断しやすくなると考えられます。
4. 守秘で載せられない業務は、どう見せるのか
載せてよいかは、契約書の秘密保持条項と、発注者への確認で決まります。自分の判断で載せるかどうかを決めない、というのが前提です。
マイナビエージェントの解説(2022年5月)では、業務で作成した制作物の著作権は企業側にあるため、ポートフォリオへの掲載は許可を得ておく必要があるとされています。秘密保持条項については、筆者の補足です。出典は発行から時間がたっているため、実際の可否は個別の契約書で確かめてください。
載せられない業務は、「飲食チェーン向け予約管理システム、バックエンドを3人チームで担当、Go・PostgreSQL」のように、顧客名を伏せた形で、業種・役割・技術だけを書く方法があります。発注者は顧客名がなくても、似た依頼を任せられるかを判断できます。@SOHOの解説では、退職時などに汎用化できるロジックだけを自分の公開リポジトリへ移す場合の注意として、機密情報・顧客名・業務固有の情報を完全に削除した状態にするとされています。ただし、移してよいかどうかは契約と発注者への確認が先です。
5. 実績がまだ少ないときは、何を載せるのか
実績が少ないうちは、個人で作った制作物を、そうと分かる形で載せるのが一つの方法です。@SOHOの解説では、個人プロジェクトでもポートフォリオは作れるとされ、例としてTodoアプリやECサイトのクローンが挙がっています。転職向けのマイナビエージェントの解説では、独力で作ったオリジナル作品は採用担当者の目に留まりやすいとされています。案件の発注者に同じことが言えるかは、出典からは分かりません。
個人制作物は、実案件と区別がつくように書きます。例えば「個人開発(予約管理を想定した業務アプリ)」のように、想定した課題と、自分が担った範囲を明記します。実案件と同じ型で書くと、実績が増えたときにそのまま差し替えられます。
受けたい分野に近い制作物を先に置きます。ポートフォリオに載せる件数に公的な基準はなく、@SOHOの解説では5〜8件が適切とされています(少なすぎると実績不足に見え、多すぎると1件ごとの印象が弱まるため)。
6. エージェントや紹介があっても、自分のサイトが要るのか
他の経路は入口として使い、判断に必要な情報を一か所にまとめる場所として自分のサイトを置く、という分け方ができます。
フリーランス協会の「フリーランス白書2025」(調査2024年11月〜12月、集計対象1,053名、フリーランス・パラレルキャリア活動者)では、仕事の獲得経路(複数回答)は、人脈(知人の紹介を含む)72.8%、過去・現在の取引先61.0%、自分自身の広告宣伝活動(Web・SNS・新聞・雑誌など)33.4%、エージェントサービス25.3%、クラウドソーシング23.3%でした。最も収入が得られる経路は、人脈35.6%、過去・現在の取引先29.9%です。この調査は全職種が対象で、エンジニアに限った数字ではありません。
紹介が中心の人でも、紹介された発注者は、連絡の前にその人の名前を検索するかもしれません。そのとき、制作物と条件が一か所にまとまっていれば、紹介のあとの判断が進みます。ホームページが必要かどうかの判断基準は、別の記事「フリーランスにホームページは必要か」で扱っています。
7. 案件の追加や条件の見直しを続けるには、サイトをどう持つのか
案件の追加や稼働条件の見直しを続けるには、個人サイトの制作・保守を月額で任せ、更新の手を自分の作業から外す持ち方があります。案件のたびに実績を足し、稼働条件を見直す作業は、開発が忙しい時期ほど後回しになります。
Freelance Growthは、プランにより、個人サイトの制作・保守に加えて、SNS運用やGoogle検索広告の運用まで任せられます。STARTERはサイトのみです。公式サイトの表記では、すべて税別で、初期サイト制作費は全プラン0円、最低契約期間は6ヶ月です。月額9,800円のSTARTERは個人サイト1ページの制作と基本保守で、実績・ポートフォリオ、提供サービス、料金、問い合わせフォーム、スマホ対応を含みます。ページを増やす場合は1ページあたり月額2,000円(税別)のオプションです。XまたはInstagramの運用は上位プランに含まれ、Google検索広告を含むプランでは、広告の出稿費が月額とは別にかかります。案件の獲得や問い合わせ件数は保証していません。解約の条件は、相談時に個別に案内するとされています(2026年10月23日時点の公式サイトの表記)。
どの案件を載せるか、稼働条件をどう見せるかが決まっていなくても、相談はできます。ヒアリングで得意分野や実績、増やしたい案件をうかがい、実績が少ない場合も、制作物や経験をもとに見せ方を一緒に整理します。掲載する作品や実績の素材は、ご自身で用意していただきます(公式サイトの記載)。
よくある質問
GitHubのURLを送るだけでは足りませんか。
足りる場合もありますが、発注者が知りたい担当範囲や稼働条件は、リポジトリからは読み取れません。サイトに担当範囲と条件を書き、GitHubへのリンクをそこから張る形にすると、発注者の確認の手間が減ります。
単価はサイトに載せたほうがよいですか。
載せるかどうかは、受けたい依頼の幅で決まり、正解は一つではありません。載せない場合は、見積もりに必要な条件(作りたいものの種類、期間、稼働の形、希望の開始時期)を聞く問い合わせフォームにすると、最初のやり取りで話が進みます。
技術スタックは、どこまで書けばよいですか。
実務で使った技術と、個人開発で触れた技術を分けて書きます。経験の深さが違うものを同じ列に並べると、発注者が実力を読み違えるためです。
会社員の副業でも、サイトに実績を載せてよいですか。
本業で作った制作物は、会社の著作物にあたる場合があるため、載せる前に契約や社内の決まりを確かめてください。副業で作った制作物も、依頼元との契約で公開の可否が決まります。Freelance Growthは、副業として活動中の方も相談できると案内しています。
まとめ
案件を取るためのエンジニアのポートフォリオサイトは、担った役割、技術の範囲、進め方、稼働条件の4点が読めるように作ります。案件は1件ごとに書く型をそろえ、載せられない業務は顧客名を伏せて業種・役割・技術で見せます。案件や条件の見直しを続けたいときは、個人サイトの制作・保守を月額で任せ、プランによってはSNS運用まで任せる方法があります(7章)。
案件と条件を置く場所から相談したい方へ
職種と活動状況をフォームに書いて送れます。初期サイト制作費0円、月額9,800円(税別)から、最低契約期間は6ヶ月です。案件の獲得や問い合わせ件数は保証しません。
- 相談・お見積もりは無料です
- 初期サイト制作費0円の月額制
- SNS運用・Google検索広告もまとめて相談できます
出典
- CareerChain「フリーランスの『実力評価』の実態と課題」(2026年10月6日発表。調査2026年9月1〜4日、フリーランス522人・企業の人事・採用担当者508人)
- @SOHO編集部「フリーランスのGitHubポートフォリオ」(2026年1月21日公開・8月19日更新)
- マイナビエージェント「エンジニアのポートフォリオ」(2022年5月24日。転職向けの解説)
- 一般社団法人プロフェッショナル&パラレルキャリア・フリーランス協会『フリーランス白書2025』(調査期間2024年11月1日〜12月14日、集計対象1,053名。p.12・p.14)
- Freelance Growth 公式サイト(料金プラン・ご利用の流れ、2026年10月23日確認)