GitHubポートフォリオの作り方｜フリーランスエンジニアの案件獲得につなげる見せ方

GitHubポートフォリオがフリーランスエンジニアに効く理由

GitHubは、フリーランスの営業資料として有力な選択肢の一つです。理由は3つあります。「読める・動くコード」で実装力を示しやすい、面談前にスキル差を吸収できる、継続的なアウトプットが信頼につながる場合がある、という点です。

WebサイトのポートフォリオやスキルシートPDFに比べ、GitHubは更新が容易で、コミット履歴という「時系列の証拠」が自動的に積み上がります。エージェント担当者や発注元の技術面談官の間では、プロフィールURLやピン留めリポジトリが先に見られることもあります。

発注者・エージェントが見ている観点（本記事で扱う4軸）

• 何を作れるか（実装スタック・アウトプットの種類）

• どう設計するか（README・ディレクトリ構成・技術選定の言語化）

• 直近も手を動かしているか（コミット履歴・草の状態）

• 連絡しやすいか（プロフィールREADMEの連絡導線）

発注者は「読める・動くコード」を見たい

スキルシートに「React、TypeScript、5年」と書かれても、書き手のレベルは判断しづらいものです。実際のリポジトリを見れば、コンポーネント設計・型の付け方・テストの書き方・コミット粒度から実力を推し量れます。発注側にとってGitHubは、面談時間を短縮できる有力な事前資料です。

面談前にスキルを可視化できる

面談で「どんなコードを書きますか」を口頭で説明するより、リポジトリのURLを共有するほうが伝達コストが低くなります。フリーランスエンジニアの面談で聞かれる質問は技術詳細に踏み込むケースが多く、事前にGitHubを見てもらえていれば技術質問がスムーズに進みます。

継続コミットが信頼感につながることがある

契約更新のタイミングで、発注側は「継続的に手を動かしているか」を気にする場合があります。案件外の時間でも学習・OSS活動が続いていれば、キャッチアップ速度への信頼につながる場合があります。強い草を毎日埋める必要はありませんが、直近3〜6か月にコミットが途絶えていないことは意識したい指標です。継続受注は実績・面談・単価・稼働条件など複数要因で決まるため、コミット履歴だけを過度に重視する必要はありません。

ミニFAQ

• Q. スキルシートがあればGitHubは要らない？

• A. スキルシートは経歴の概要、GitHubは実装力の証拠、と役割が違います。両方あるとエージェント経由の案件・直案件どちらでも有利です。役割分担は職務経歴書とスキルシートの違いも参考になります。

GitHubプロフィールREADMEの整え方

プロフィールREADMEは、ユーザー名と同名のリポジトリを作り、その直下にREADME.mdを置くと、プロフィールトップに表示される仕組みです。GitHubの「顔」に相当し、閲覧者が最初に見る1画面になります。ここで「何のフリーランスか／稼働可否／連絡導線」が伝わらないと、その先のリポジトリまで読まれない可能性が高くなります。

作成手順は、GitHubで自分のユーザー名と同名のリポジトリを作り、公開設定にし、README.mdを追加するだけです。詳細はGitHub公式ドキュメントのプロフィール設定を参照してください。

何のフリーランスなのかを1行で書く

冒頭1行は肩書きに使います。「フリーランスのフロントエンドエンジニア」「Rails中心のWebアプリ開発フリーランス」など、得意領域と役割を1行に凝縮します。「エンジニア」だけでは幅が広すぎ、案件マッチングの精度が落ちます。

得意領域・稼働可能日数の書き方

肩書きの下に、得意領域（言語・フレームワーク・ドメイン）と稼働可能日数を書きます。「週3〜4日稼働可能／リモート希望」など、案件マッチングに直結する情報を優先します。単価は公開しない選択でも問題ありません。公開する場合は、想定する契約形態（月額／時給）と稼働条件をセットで書くと誤解を減らせます。単価公開が有利に働くかは、直案件・エージェント案件・単価帯・交渉余地によって変わるため、一律に推奨できるものではありません。

問い合わせ導線を必ず載せる

問い合わせ先が書かれていないGitHubは、営業資料として機能しにくくなります。メールアドレス・X（旧Twitter）・LinkedInのプロフィールURLなど、連絡経路を最低1つは明示します。連絡経路を用意することで、問い合わせのハードルを下げられます。

ミニFAQ

• Q. 顔写真は必要？

• A. 必須ではありません。ただし、アイコン画像は設定したほうが読者の印象に残りやすくなります。イラスト・シンボルでも問題ありません。

ピン留めリポジトリ6枠の選び方

GitHubのプロフィールには、任意のリポジトリを最大6件までピン留めできます。この6枠は営業導線の中心になりやすい場所です。ランダムな一覧より、ピン留めのほうが先に見られやすいため、「最初に見てほしい6件」を意識的に選ぶことを基本方針にします。

発注者が最初に見る枠と考える

ピン留めは、履歴書の「職務経歴の要約欄」に近い役割です。発注者は上から順に3〜6件をざっと眺め、詳細を見るか判断します。1件目・2件目に配置するリポジトリは、想定案件のスキル要件に近いものを置きます。

学習リポジトリ一辺倒にしない

ピン留めが「Reactチュートリアル」「Rails入門」ばかりだと、実務経験が伝わりにくくなります。学習ログは1〜2枠にとどめ、残りは実務相当の設計・複数機能を持つプロダクトに振り分けます。個人プロダクト・OSSコントリビュート先・技術検証リポジトリなど、実装意図が読める構成が理想です。

選び方フロー（実務適性ベース）

以下の順で候補を絞ると選びやすくなります。

1. 想定案件のメイン技術スタックに近いリポジトリを2件選ぶ

2. 設計判断が読めるリポジトリ（ディレクトリ構成・設計方針が読み取れるもの）を1件選ぶ

3. OSSへの具体的なPR実績や、貢献内容が読み取れるリポジトリがあれば1件選ぶ（フォークやIssue参加だけでは実装力が伝わりにくいため、貢献範囲が説明できる形にする）

4. 技術記事・ブログの元コードや、CI/CDを組み込んだリポジトリを1件選ぶ

5. 残り1枠は、直近3か月以内に更新のあるリポジトリを選ぶ

ミニFAQ

• Q. リポジトリが少ない場合はどうすればいい？

• A. まずは業務で触れている技術の小規模プロダクトを1〜2件作り、READMEを整えるところから始めます。件数より、1件ごとの完成度が優先されます。実績が少ないフェーズの見せ方は実績が少ないスキルシートの書き方の考え方が応用できます。

リポジトリのREADMEに書くべき7項目

ピン留めしたリポジトリを開いた発注者は、READMEを読みます。ここで詰まると次のリポジトリに移られてしまいます。READMEは「読みやすい順序」で情報を配置し、書き手の設計思考が伝わる構成にします。

1. 何を解決するリポジトリか（1行サマリ）

冒頭に、このリポジトリが解決する課題を1行で書きます。「タスク管理API」ではなく「小規模チーム向けのタスク管理API（Rails 7 / PostgreSQL）」のように、対象と技術スタックを含めます。

2. 技術スタック

使用言語・フレームワーク・データベース・主要ライブラリを箇条書きします。README更新時点で使用している主要バージョンを明記しておくと、閲覧者が「保守されているスタックか」を判断しやすくなります。

3. デモ・スクリーンショット

動くものはスクリーンショット、動画、あるいはデプロイURLを載せます。動作が視覚的に伝わると、READMEを最後まで読んでもらえる確率が上がります。

4. セットアップ手順

「git clone」から起動までを3〜5ステップで書きます。手順に不備があると、閲覧者の「動かして試す」意欲が削がれます。可能なら、Dockerで起動できる構成にしておくと確認コストが下がります。

5. アーキテクチャ・ディレクトリ構成

主要ディレクトリの役割を数行の表で示します。設計判断（なぜこの構成にしたか）を1〜2文添えると、実務レベルの思考が伝わります。

6. 動作要件・前提

対応OS、必要な言語バージョン、外部サービスのアカウント要否などを明記します。「うちの環境で動かなかった」を避けるための情報です。

7. ライセンス・作者情報

MIT・Apache 2.0など、ライセンスを明示します。作者情報はプロフィールへのリンクで代替できます。OSSとして誰かに使ってほしいなら、コントリビュートガイドを別ファイルで整えます。

コミット履歴と「草」の見せ方

GitHubのプロフィールには、コントリビューショングラフ（通称「草」）が表示されます。継続的に手を動かしているかの目安として、発注者が見るポイントです。ただし、毎日埋めることが目的化すると、コミットの質が下がります。

毎日コミットが目的化しない

「1文字修正のコミット」で埋めた草は、しばらく見れば履歴が薄いと分かってしまいます。質のあるコミットを週3〜5件、直近3〜6か月継続するイメージが現実的です。空白期間があっても、直近が動いていれば十分に評価されます。

業務案件のコミットを混ぜる（NDA範囲内で）

業務案件のコミットは、契約や社内ルールで問題ない範囲であれば、privateリポジトリで行っても草に反映されます（プロフィール設定で「Include private contributions on my profile」を有効にする必要があります）。private contributionsの表示で直近の活動量を補足できます。公開可否の判断はクライアントとの契約条項が優先されるため、事前確認を必ず行います。

過去のprivateリポジトリ設定を確認

プロフィールに草を表示していても、privateコミットが除外設定になっていると、実際の活動が見えないことがあります。GitHubの設定画面（Settings → Profile → Contributions & Activity）で「Include private contributions on my profile」をオンにしておきます。詳細はGitHubのコントリビューション表示設定ドキュメントを参照してください。

ミニFAQ

• Q. 草が薄い時期があるとマイナス評価？

• A. 直近3〜6か月に一定の活動があれば、過去の空白期間は大きな減点になりにくいものです。ブランクの説明を面談で用意しておけば十分に対応できます。

GitHub Pagesで作品ページを公開する

GitHub Pagesは、リポジトリ内の静的ファイルをそのままWebサイトとして公開できる仕組みです。リポジトリのREADMEだけでなく、動くデモを公開できるため、フロントエンド・Web系のフリーランスや静的デモを見せやすい案件と相性が良い機能です。バックエンド中心のフリーランスは、Swagger UI・API仕様書のホスティング用途で活用する選択肢もあります。

公開は、リポジトリのSettings → Pagesから公開ブランチを選ぶだけで完了します。独自ドメインの設定にも対応しています。詳細はGitHub Pages公式ドキュメントを参照してください。

公開の際の注意点

APIキーや認証情報が含まれるコードを、GitHub Pagesで公開しないよう注意します。フロントエンドのビルド結果を公開する場合でも、環境変数の埋め込みや「.env」ファイルの取り扱いに気をつけます。「動くから公開」ではなく「見せてよい範囲で公開」が原則です。

GitHub Actionsのバッジで実務能力を示す

各リポジトリのREADME先頭に、GitHub Actionsのワークフロー実行結果を示す「バッジ」を貼れます。バッジは「テストが通っている」「ビルドが成功している」ことを一目で示すため、最低限の自動テストやビルド確認を行っていることが伝わりやすくなります。バッジはあくまで補助的なシグナルで、テスト内容の質までは示せない点は意識しておきます。

CI/CDの実装を「見える化」する

「.github/workflows/」配下にYAMLを配置し、テスト・Lint・ビルドを自動化しておくと、コミットのたびに実行結果が更新されます。バッジがGreenなら「今動くコード」であることが証明されます。

テスト・Lint・ビルドの3種セット

公開用の主要リポジトリでは、テスト結果・Lint結果・ビルド結果の3種のバッジを付けると分かりやすい場合があります。CI/CDに慣れていない発注者にとっても、「Green＝動くコード」という直感が働きます。小規模な検証用リポジトリでは過剰になることもあるため、リポジトリの目的に応じて選びます。

NDA下で業務コードが出せない場合の代替戦略

フリーランスエンジニアの多くは、業務案件の成果物を公開できません。契約書のNDA条項で公開制限があるケースが一般的です。この場合、業務コードを公開しない前提でGitHubを整える設計に切り替えます。

業務相当の小規模再実装リポジトリを作る

業務で使った技術スタックを、個人プロジェクトとして小規模に再実装します。「業務で扱っている技術のミニ版」を1〜2件作れば、実装力の証拠になります。業務案件そのものを公開する必要はありません。

個人プロダクトで技術要素を証明する

「認証・支払い・ファイルアップロード」など、業務で頻出する技術要素を含むミニアプリを1つ作ります。これで、実務適性を証明する素材が揃います。個人プロダクトは、面談の技術質問にも答えやすくなる副次効果があります。

ブログ・技術記事のリンク集約

コードを公開できなくても、技術記事は書けます。QiitaやZenn、個人ブログの記事URLをプロフィールREADMEに集約すれば、「何を考えているエンジニアか」が伝わる情報源になります。書けるアウトプットは全てGitHubに集約する発想です。

ミニFAQ

• Q. 業務内容を伏せた抽象的な記事でも意味がある？

• A. 抽象化された記事でも、技術選定の理由・詰まったポイントの解決手順が書かれていれば十分に評価対象になります。案件の詳細ではなく、思考プロセスを見せる意識が有効です。

ケース別解説

キャリアフェーズによって、GitHubの整え方は変わります。

未経験〜1年目

学習ログ・チュートリアル完走記録が中心になります。「量」ではなく「1本の学習を最後までやり切った証拠」が読み取れる構成にします。ピン留めは3件程度でも構いません。無理にリポジトリ数を増やすと、更新のないリポジトリが目立ちます。

経験3〜5年目

業務スタックの再実装ミニ版と、個人プロダクト1件をピン留めの主軸にします。「実務でこれを使っている」証拠と、「自主的にこれを作った」証拠の両方を並べる構成が有効です。CI/CDバッジ・READMEの整備で仕上げます。

シニア（10年以上）

OSSコントリビュートやアーキテクチャ設計記事のリポジトリを主軸に置きます。単なる実装だけでなく、「設計判断を言語化できる人」という印象を狙います。技術書・カンファレンス登壇資料のリポジトリがあればピン留めに含めます。

よくある失敗と対策

プロフィールREADMEが空

「アカウントは持っているがプロフィールが空」だと、発注者が読むものがありません。最低限、肩書き・得意領域・連絡先の3項目は書きます。

学習リポジトリだけがピン留めされている

チュートリアル完走リポジトリだけだと、実務適性が伝わりにくくなります。個人プロダクトを最低1件は作り、ピン留めに含めます。

READMEが「使い方」中心で「何のリポジトリか」が分からない

セットアップ手順だけがあり、リポジトリの目的が書かれていないケースがあります。冒頭1行の「1行サマリ」を必ず書きます。

コミットが「Initial commit」1件で止まっている

作りかけのリポジトリが放置されている状態は、印象を下げます。作りかけならprivateに戻すか、READMEに「開発中」と明記します。

GitHubポートフォリオ整備チェックリスト

このページで整理してきた内容を、実行順のチェックリストにまとめます。

• プロフィールREADMEを作成し、肩書き・得意領域・稼働可否・連絡先を書いた

• ピン留めリポジトリを6件（少なくとも3件）選定した

• ピン留めリポジトリのREADMEに、1行サマリ・技術・デモ・セットアップ・設計判断を書いた

• 「Include private contributions on my profile」を有効化した

• GitHub Actionsバッジをリポジトリに追加した（該当リポジトリのみ）

• GitHub Pagesで動くデモを公開した（該当リポジトリのみ）

• 業務コードが出せない場合の代替として、業務相当の再実装リポジトリを1件以上作成した

• 技術記事・ブログのURLをプロフィールREADMEに集約した

• 直近3か月以内にコミットがある状態を維持した

• 面談前に共有できるURLとして、プロフィールURLを準備した

まとめ

GitHubポートフォリオは、フリーランスエンジニアの営業資料として、コストと効果のバランスが優れた選択肢です。「プロフィールREADMEで1画面完結」「ピン留め6枠で実務適性を示す」「リポジトリのREADMEで設計判断を伝える」の3層で整えると、面談前にスキルが伝わる状態を作れます。

要点を整理すると次のとおりです。

• プロフィールREADMEは肩書き・得意領域・稼働可否・連絡先の4点を1画面に収める

• ピン留めは営業の主戦場。学習リポジトリだけで埋めず、実務適性が伝わる構成にする

• リポジトリのREADMEは「1行サマリ→技術→デモ→セットアップ→設計判断」の順に整える

• コミット履歴は毎日埋めるより、直近3〜6か月に継続がある状態を優先する

• NDA下で業務コードを出せない場合は、業務相当の再実装リポジトリと技術記事リンクで代替する

• GitHub Actionsバッジ・GitHub Pagesを併用すると、実務能力の可視化が進む

ポートフォリオの総論はフリーランスエンジニアのポートフォリオの作り方、案件獲得の実務はフリーランスエンジニアの直案件の取り方を合わせて読むと、営業導線が立体的に組み立てられます。

案件探しまで進めたい方は、フリコンのエンジニア向け案件情報も選択肢の一つとして活用できます。

参考リンク

• GitHub Docs：プロフィールREADMEの管理

• GitHub Docs：GitHub Pages

• GitHub Docs：GitHub Actions

• GitHub Docs：プライベートコントリビューションの表示