フリーランスのGitHub活用術｜ポートフォリオとしてのプロフィール作成法
この記事のポイント
- ✓フリーランスエンジニアがGitHubをポートフォリオとして活用する方法を解説
- ✓プロフィールREADMEの書き方
- ✓ピン留めリポジトリの選定基準
「ポートフォリオサイトを作るべきですか？」と聞かれたら、「まずGitHubを整えろ」と答える。
理由は単純。クライアントやエージェントの技術担当者は、ポートフォリオサイトよりもGitHubのほうを先に見る。実際のコードが見えるGitHubは、スキルの証明として最も信頼性が高い。
僕自身、GitHubプロフィールを整備してからスカウトの件数が月2〜3件から月8〜10件に増えた。その具体的な方法を解説する。
なぜGitHubがポートフォリオとして有効なのか
| 評価軸 | ポートフォリオサイト | GitHub |
|---|---|---|
| スキルの証明力 | 中（見た目だけの可能性） | 高（実コードで判断） |
| 更新コスト | 高（デザイン・実装が必要） | 低（コミットするだけ） |
| 技術者からの信頼度 | 中 | 高 |
| 非技術者への訴求力 | 高 | 低 |
技術者が見るならGitHub、非技術者が見るならポートフォリオサイト。両方あるのが理想だが、優先度はGitHubが上だ。
ポートフォリオサイトの作り方は「フリーランスのポートフォリオの作り方」を参照。
GitHubプロフィールREADMEの作り方
GitHubでは、ユーザー名と同名のリポジトリにREADME.mdを置くと、プロフィールページに表示される。これを活用する。
含めるべき情報
| セクション | 内容 | 重要度 |
|---|---|---|
| 自己紹介 | 職種、経験年数、得意領域 | ★★★★★ |
| 技術スタック | 使用言語・フレームワーク（アイコン付き） | ★★★★★ |
| 実績・経験 | 手がけたプロジェクトの概要 | ★★★★☆ |
| 連絡先 | メール、SNS、ポートフォリオサイト | ★★★★☆ |
| GitHub Stats | コントリビューション統計 | ★★★☆☆ |
| ブログリンク | 技術ブログへの誘導 | ★★★☆☆ |
良いプロフィールの構成例
## Hi, I'm [名前] 👋
[1〜2行の自己紹介：職種 × 経験年数 × 得意領域]
### 🛠 Tech Stack
[アイコンバッジで視覚的に表示]
### 📌 Featured Projects
[ピン留めリポジトリの補足説明]
### 📊 GitHub Stats
[github-readme-statsのウィジェット]
### 📫 Contact
[連絡先リンク]
避けるべきパターン
- 情報過多：スクロールしないと読めないほど長い
- 装飾過剰：GIFアニメやバッジが多すぎて目が疲れる
- 更新放置：「2024年の目標」が残っているなど
ピン留めリポジトリの選定基準
GitHubプロフィールでは最大6つのリポジトリをピン留め（Pinned）できる。ここが最も重要な見せ場だ。
選ぶべきリポジトリの条件
| 条件 | 理由 |
|---|---|
| READMEが充実している | 第一印象で「ちゃんとしている」と思わせる |
| コードが整理されている | リファクタリングされたコードは好印象 |
| テストがある | テストを書く文化を持っていることの証明 |
| 最近更新されている | 放置リポジトリは評価が下がる |
| 実用的なプロジェクト | TODO アプリより実際に使われているツール |
| デモURLがある | 動くものが見られると説得力が段違い |
ピン留めの構成パターン
6枠の配分として推奨するのはこのパターン。
| 枠 | 内容 | 目的 |
|---|---|---|
| 1〜2 | メインのプロダクト/サービス | 技術力の証明 |
| 3 | OSSコントリビューション | コミュニティへの貢献 |
| 4 | ユーティリティライブラリ | 汎用性のアピール |
| 5 | 技術的チャレンジ | 学習意欲・好奇心 |
| 6 | プロフィールREADME | 自己紹介 |
リポジトリのREADMEテンプレート
各リポジトリのREADMEは「30秒で概要が把握できる」構成にする。
必須要素
| セクション | 内容 |
|---|---|
| プロジェクト名 + 一言説明 | 何をするものか |
| スクリーンショット/デモURL | 動く姿が見えると評価が上がる |
| 技術スタック | 使用技術の一覧 |
| セットアップ手順 | ローカルでの動かし方 |
| アーキテクチャ概要 | 設計の意図（簡潔に） |
差がつくポイント
- Why（なぜ作ったか） を書く：技術選定の理由が見えると好印象
- 課題と解決策 を書く：問題解決能力のアピールになる
- パフォーマンス指標 を書く：「レスポンス200ms以下」など具体的な数字
コントリビューショングラフの戦略
あの「緑色のマス目」は見た目以上に影響力がある。
草を生やすための戦略
ぶっちゃけ、毎日コミットする必要はない。ただし長期間の空白はマイナスになる。
| パターン | 印象 |
|---|---|
| 毎日緑（濃い） | 最高（実際にこれを維持するのは難しい） |
| 週3〜4回 | 良好（現実的で好印象） |
| 月に数回 | 普通（マイナスにはならない） |
| 数ヶ月空白 | マイナス（活動していない印象） |
効率的に草を生やす方法
- 個人プロジェクトを小さく始める：日記アプリでもCLIツールでもOK
- 技術ブログをGitHubで管理：記事のpushでもコントリビューションになる
- OSSのIssueに取り組む：good first issueラベルから始める
- dotfilesを管理する：設定ファイルの更新もコミット対象
GitHubプロフィールの最適化チェックリスト
以下の項目を1つずつ潰していく。
| 項目 | 状態 | 効果 |
|---|---|---|
| プロフィール写真を設定 | □ | 信頼性向上 |
| Bioに職種・専門分野を記載 | □ | 検索でヒット |
| プロフィールREADMEを作成 | □ | 第一印象の最適化 |
| ピン留めリポジトリを6つ設定 | □ | スキルの証明 |
| 各リポジトリにREADMEを追加 | □ | プロジェクトの理解 |
| コントリビューショングラフが活発 | □ | 継続性の証明 |
| SNS/連絡先リンクを設定 | □ | コンタクトの容易さ |
| 不要なフォークリポジトリを整理 | □ | ノイズの削減 |
GitHubを案件獲得に直結させる方法
GitHubを整えたら、次は案件獲得の動線を作る。
1. 経歴書・提案文にGitHubリンクを入れる
案件に応募する際、GitHubリンクを必ず含める。特にエンジニア案件では、経歴書にGitHubリンクがあるだけで書類通過率が上がる。
2. LinkedInプロフィールにGitHubを紐付ける
海外案件やスカウトを狙うなら、LinkedInとの連携は必須。
3. 技術ブログからGitHubに誘導する
Zenn、Qiitaなどの技術ブログ記事内で、関連するリポジトリへのリンクを貼る。「記事を読んで興味を持つ→コードを見る→信頼する→案件につながる」の流れができる。
まとめ
- GitHubはエンジニア最強のポートフォリオ
- プロフィールREADME、ピン留めリポジトリ、コントリビューショングラフの3つを整える
- 各リポジトリのREADMEは「30秒で伝わる」構成に
- 整えたGitHubを経歴書・提案文に必ずリンクする
スキルの証明は「見せ方」で大きく変わる。同じスキルでも、GitHubが整備されているかどうかで単価に月5〜10万円の差が出る。
営業や提案のコツは「フリーランスの営業術」で詳しく解説している。
@SOHOでスキルを評価してもらえる案件を探そう
@SOHOは手数料0%・直接取引OKのフリーランス案件サイト。GitHubを整えたら、実力を正当に評価してくれるクライアントと直接つながろう。報酬の100%が手元に入る。
この記事を書いた人
榊原 隼人
フルスタックエンジニア・テックライター
SIerで8年間システム開発に携わった後、フリーランスエンジニアに転身。React/Next.js/Pythonを中心に開発案件をこなしながら、技術系の記事を執筆しています。
