フリーランスエンジニアのGitHubアピール術｜スカウト・案件獲得につながるプロフィール設計

エージェント担当者から「念のため GitHub の URL も併せていただけますか」と言われたとき、自分のアカウントを開いて少し怯んでしまった経験はないでしょうか。直近の案件はすべて NDA 縛りでコードを外に出せず、Pinned には数年前の練習リポジトリ、Contribution グラフ（いわゆる草）も薄い。それでもスカウトメールに「GitHub を拝見して」と書かれている以上、見られている事実からは逃げられません。

このとき多くの方が「もっとコードを公開しなければ」「個人開発をゼロから作らなければ」と焦ります。ただ複業や本業の現場稼働を抱えながら、週末にゼロベースで OSS を立ち上げるのは現実的ではありません。そして実のところ、エージェントやスカウターは「個人開発を量産しているか」を見ているわけではないのです。

採用側がフリーランスエンジニアの GitHub を見るとき、判断したいのは「コードが書けるかどうか」だけではありません。スキルシートや経歴書では伝わりにくい「継続性」「コミュニケーションのトーン」「業務委託コードを公開してしまうような線引きの甘さがないか」といった、一緒に仕事をするうえでの安心材料を確認しに来ています。つまり、見られているのはコードの量ではなく信頼のシグナルです。

本記事では、エージェント・スカウター・クライアント担当者が GitHub のどこを何のために見ているのかを 5 つのポイントに分解したうえで、NDA 案件中心で公開コードが少なくても信頼を伝えるためのプロフィール設計・Pinned 設計・README の書き方・草の維持方法を、複業エンジニアの生活で続けられる手順に落とし込みます。週末 2〜3 時間で「最低限ここまで」、余裕があれば「次の週末でここまで」と段階的に整備できる構成にしています。

なお、関連するアウトプットの整え方としてフリーランスエンジニアのポートフォリオやスキルシート・経歴書の書き方もあわせて参考にしてください。GitHub・ポートフォリオ・スキルシートは「同じ人物を別の角度から見せる三点セット」として一貫させると、案件獲得の精度が上がります。

フリーランスエンジニアにとってGitHubが「案件獲得の名刺」になる理由

エージェント経由で案件を獲得する場合でも、直接スカウトで声がかかる場合でも、近年は GitHub の URL を求められる場面が確実に増えています。まず、なぜ今このタイミングで GitHub が案件獲得の起点になっているのか、そして採用側が何を読み取ろうとしているのかを整理します。

スカウト・面談でGitHub URLを聞かれる場面が増えている背景

レジュメやスキルシートに記載される技術スタックは、表面的にはどの方でも似た構成になりがちです。「Next.js・TypeScript・AWS」と書かれていても、実際にどのレベルでどんな関わり方をしてきたかは紙面からは読み取れません。

採用側はこのギャップを埋めるための補足情報として GitHub を見ています。エージェント担当者が「URL も併せてください」と言うときは、スキルシートだけでは語りきれない技術的な肌感や、活動の継続性を案件元（クライアント企業）に提示したい意図があります。スカウターからのメッセージに「GitHub を拝見して」と書かれている場合も同様で、書類選考の前段としてアカウントを覗き、面談に呼ぶ価値があるかを判断しているわけです。

つまり GitHub は「ある／ない」のチェック項目ではなく、スカウト・面談・契約という一連の意思決定を後押しする「動く名刺」として機能しています。

採用側がGitHubから読み取ろうとしている3つのシグナル

採用側が GitHub プロフィールから読み取りたい情報は、大きく以下の 3 つに整理できます。

• スキルシグナル: スキルシートに書かれた技術スタックが、実際のアウトプットと矛盾していないか。Pinned や直近のコミットで触れている言語・フレームワークが、提案案件の技術スタックと噛み合うか。
• 継続性シグナル: 直近 3〜6 ヶ月で何かしらの活動があるか。長い空白期間がある場合、その理由が説明可能か（業務委託でのクローズドな開発が中心なのか、稼働を空けていたのか）。
• 人柄シグナル: Issue や PR のコメントのトーン、README の書き方、コミットメッセージの粒度から伝わる「一緒に仕事をしたいと思える人物像かどうか」。

このうち多くの方が意識しているのは「スキルシグナル」だけです。しかし、フリーランスエンジニアの場合は契約形態の自由度が高い分、採用側にとって「人柄シグナル」と「継続性シグナル」の重要度が相対的に上がります。短期間で関係を構築し、リモートでスムーズに進められるかどうかは、コードの巧拙以上に契約判断を左右する要素になるためです。

本記事のスコープと前提

本記事では、稼働中の案件が NDA 縛りで業務コードを外に出せないことを前提に話を進めます。週末 2〜3 時間程度の整備時間で取り組めるよう、最低限のラインと余裕がある場合の発展ラインを分けて提示します。

なお、前提として強調しておきたいのは、業務委託で書いたコードを GitHub に上げる行為は契約違反になり得るという点です。「コードを公開しないと案件が取れない」という発想を一旦脇に置き、「公開できない経験をどう信頼に変換するか」を考える方向に切り替えていきます。権利・契約の線引きは後ほど詳しく扱いますが、ここで意識を切り替えておくと残りのセクションが頭に入りやすくなります。

エージェント・スカウターがGitHubで確認する5つのポイント

採用担当・エージェント・スカウターが GitHub プロフィールを開いてから判断までに見るのは、おおむね数十秒から長くても数分です。その短時間でどこを見ているかを 5 ポイントに分解します。整備の優先順位を決める際の物差しとして使ってください。

ポイント1: プロフィール上部の名前・自己紹介・所在地・公開メール

最初に視線が向かうのはプロフィールページの上部、アバター画像の右側です。名前（または日本語ハンドル）・Bio（自己紹介）・所在地（Location）・公開メールアドレスの 4 点が揃っているかが確認されます。

悪い例は、Bio が空欄、Location が空欄、メールも非公開という「素のまま」の状態です。これは「対外的に発信する意図のないアカウント」と受け取られ、案件相談の窓口として機能しないと判断されます。

良い例は、Bio に「Web フロントエンドのフリーランス／TypeScript・React・Next.js」のような一行プロフィールがあり、Location に活動拠点（例: Tokyo, Japan）、公開メールに案件相談用のアドレスが入っている状態です。これだけで「連絡可能・属性が明確」という基礎信頼が成立します。

ポイント2: Pinned repositoriesで何を上に固定しているか

次に視線が向かうのが Pinned repositories の枠です。GitHub のプロフィールでは最大 6 つまでリポジトリを固定表示できます（Pinning items to your profile - GitHub Docs）。

悪い例は、Fork したまま放置のリポジトリ、数年前のチュートリアル写経、README が空のままの実験リポジトリが Pinned の上位に並んでいる状態です。Pinned は「この人がアピールしたい代表作」として解釈されるため、ここに弱いものを置くと全体評価が引っ張られます。

良い例は、たとえ小さくても「目的・技術スタック・自分の役割」が README に明記されたリポジトリが並んでいる状態です。後ほど詳しく扱いますが、Pinned に置く玉は新規に作らなくても、既存の小さなリポジトリを整備するだけで十分案件獲得の補強になります。

ポイント3: Contributionグラフ（草）の濃淡と空白期間

プロフィールページ中央に表示される Contribution グラフ、いわゆる「草」も確認対象です。ただし、ここで誤解しがちなのは「毎日緑にしないと評価が下がる」という思い込みです。

スカウター・エージェントが草から読み取りたいのは、毎日の連続性よりも「直近のアクティビティ」と「空白期間の説明可能性」です。直近 3 ヶ月の中で何かしら動きがあれば「現役で動いているエンジニア」と認識されますし、空白期間があっても業務委託の常駐中で private contributions が見えていないなら、そのことが Bio や README に書かれていれば問題視されません。

逆に、半年以上完全に動きがない状態で、その理由が読み取れない場合は「現役性」が疑われやすくなります。

ポイント4: 主要リポジトリのREADMEとコミット粒度

Pinned に固定されたリポジトリのうち、興味を引かれたものをクリックして中身を見ます。ここで確認されるのは README の充実度とコミット粒度です。

README で見られているのは、リポジトリの目的・解決している課題・技術スタック・セットアップ手順・自分の役割（個人開発か、Fork からの貢献か）です。コミット粒度では、巨大な単発コミット（update files のような大雑把なメッセージ 1 つで数十ファイル変更）ではなく、論理単位で分割された小さなコミットと意図の伝わるメッセージが好まれます。

業務で他のメンバーと共同開発する際に求められる作法と同じものを、自分のリポジトリでも実践しているかが見られています。

ポイント5: Issue・PR・コメント欄の対人コミュニケーション

最後に、もし OSS への貢献履歴があれば Issue や PR のコメントが確認されます。バグ報告の Issue で再現手順を丁寧に書けているか、PR のレビューコメントで相手の意図を尊重しつつ建設的に議論できているかといった、対人コミュニケーションの実例です。

ここはコードと違って「飾る」ことが難しい領域であり、普段の働き方が透けて見えます。フリーランスとしてリモート中心で動く場合、テキストコミュニケーションの質は契約継続にも直結するため、採用側にとって非常に重要なシグナルになります。

なお、スカウト経由で面談に進む流れ全般についてはスカウトが来ない原因と改善もあわせてご覧ください。GitHub の整備と並行して、スカウト媒体側のプロフィールも見直すと、入口の数自体を増やせます。

NDA案件中心でも信頼を伝えるプロフィール設計

ここからは具体的な整備手順に入ります。最初に取り組むべきは、業務委託コードを公開してはいけないという前提を確認したうえで、「公開できない経験」をどう言葉で残すかです。

業務委託コードを公開してはいけない理由と著作権の線引き

業務委託や派遣で書いたコードの著作権は、原則として委託元（クライアント企業）に帰属します。契約書には「成果物の著作権はすべて委託者に譲渡する」「業務上知り得た情報を第三者に開示してはならない」といった条項が含まれているのが一般的です。

これらに該当するコードを自分の GitHub に公開すると、著作権侵害および NDA 違反に該当する可能性があります。たとえコメントを削除しても、ロジック構造やファイル構成が特定できれば「成果物の流用」と判断されることがあるため、リポジトリ名を変えれば良い・特定の関数だけ抜き出せば良い、という発想は危険です。

「業務で書いた便利ユーティリティだから個人として公開したい」というケースも、原則は委託元の許諾を得てからにします。許諾なしで公開して案件が継続できなくなるリスクと、信頼を得るために得られるリターンは見合いません。本記事の以降の手順は、すべて「業務委託コードは GitHub に上げない」前提で組み立てます。

公開できない経験を「言葉」で残すプロフィールREADMEテンプレート

公開できないコードの代わりに残せるのが、経験を言語化した文章です。GitHub では、自分のユーザー名と同じ名前のリポジトリを作成し、その中に README.md を置くと、プロフィールページの上部にその内容が表示されます（Managing your profile README - GitHub Docs）。

このプロフィール README に、以下のような要素を盛り込みます。

• 一行自己紹介: 肩書き・専門領域・現在のスタンス（例: 「Web フロントエンドのフリーランス／TypeScript・React・Next.js を中心に、要件定義から実装まで担当」）。
• 直近の案件概要（NDA配慮）: 業界・規模感・自分の役割を抽象度高く記載（例: 「2024〜2025: SaaS スタートアップで Next.js による管理画面リプレイス・API 設計に参画（NDA のため詳細は面談時にお伝えします）」）。
• 対応可能な領域とスタック: 言語・フレームワーク・クラウドサービス・得意なフェーズ（要件定義・実装・レビュー・テスト）を箇条書きで列挙。
• 稼働状況／案件相談の窓口: 現在稼働中／週N日稼働可／フル稼働可、といったステータスと連絡導線。

「NDA のため詳細は面談時にお伝えします」と明示することは、機密保持を守れるエンジニアであることのシグナルになります。これは「公開コードがない」というネガティブを「契約遵守できる」というポジティブに転換する書き方です。

連絡導線（メール・X・個人サイト）と稼働状況の見せ方

採用側が GitHub のプロフィールを見て「この人に声をかけてみたい」と思った瞬間、連絡導線が見当たらないと機会を取りこぼします。次の 3 点を整えておくと、入口を増やせます。

• 公開メール: GitHub のプロフィール設定で公開メールを設定する。案件相談専用のアドレスがあれば、それを使う。
• X（旧 Twitter）リンク: 業務で技術発信をしている場合は連携。ただし、技術と無関係な発信が多い場合は連携せず、別の専門用アカウントを作る選択肢もあります。
• 個人サイト／Zenn／Qiita: 技術記事を継続的に書いている場合は積極的にリンク。プロフィール README からも案件相談導線として明示する。

稼働状況は「稼働中／週末のみ／フル稼働可」のように、月ごとの更新でも良いので「いま声をかけて良いか」が分かる形にしておきます。古い情報のままだと「もう稼働できないのかな」と判断されて声がかからない、という機会損失が起こります。

アイコン・ユーザー名・ハンドルの整え方

最後に、アイコン画像とユーザー名（ハンドル）の整え方です。アイコンが GitHub デフォルトのままだと「アカウントを使い込んでいない」印象を与えるため、顔写真または一貫したイラストアイコンに変えます。ここで、X・Zenn・Qiita・LinkedIn と同じアイコンを使うと、媒体横断で「同一人物」と認識されやすくなり、検索からたどってもらいやすくなります。

業務用アカウントと個人用アカウントを分けるかどうかは判断が分かれますが、フリーランスとして案件獲得を目指すなら「仕事用」をメインに据え、個人趣味リポジトリはそちらにまとめるか別アカウントに移すのが整理しやすい運用です。

Pinned repositoriesで「案件獲得に直結するリポジトリ」を選び・整える

プロフィール上部が「動く名刺」だとすれば、Pinned は「代表作の陳列棚」です。最大 6 つの枠で何を見せるかを設計します。

Pinned 6枠の使い分け（OSSコントリビュート／個人開発／技術検証／プロフィールREADME）

業務委託コードを置けない前提で、Pinned に固定する候補は次の 4 タイプに分類できます。

• タイプ A: 小さな OSS コントリビュート: 既存の OSS リポジトリを Fork して PR を出し、マージされたものを Pinned に固定する。マージされた PR があるリポジトリは「他者と協働できる証拠」として強く機能します。
• タイプ B: 自分の課題を解決する個人開発: ToDo アプリのような汎用例ではなく、自分の業務や生活で実際に使う小さなツール（CLI、Slack Bot、ブックマークレットなど）。「課題ドリブンで作った」というストーリーがあると説得力が増します。
• タイプ C: 技術検証用の小さなサンプル: 新しいフレームワークや API を試したサンプルリポジトリ。「最近気になっている技術を手を動かして確認した記録」として位置づけます。
• タイプ D: プロフィール README リポジトリ自体: 前述のユーザー名と同名のリポジトリ。Pinned に固定すると、プロフィール README の存在感が増します。

6 枠すべてを埋めようとせず、3〜4 枠だけ厳選するほうが「これが代表作」というメッセージが明確になります。スカスカの 6 枠より、整った 3 枠のほうが評価されます。

各リポジトリの最低限の整備チェックリスト

Pinned に置くリポジトリは、最低限以下を README に書いておきます。

• 目的: このリポジトリで何を解決しようとしているか、または何を試したか。
• 技術スタック: 使用言語・主要ライブラリ・フレームワーク・ホスティング先。
• デモ URL またはスクリーンショット: GitHub Pages や Vercel など無料ホスティングで動くデモがあると強い。動かせない場合はスクリーンショット 1〜2 枚でも代替可能。
• セットアップ手順: 他の方が手元で動かせるよう、npm install から起動までの最小手順。
• 自分の役割・工夫: 個人開発なら全工程を担当しているはずですが、その中で「特に工夫した点」を 2〜3 行で書く。Fork からの貢献なら「どの部分の PR をマージしてもらったか」を明示する。

このチェックリストを満たした README があるリポジトリは、たとえ規模が小さくても「これを書いた人と話してみたい」と感じさせます。

「Fork」「Star」しかしていないアカウントをPinned候補に育てる小さな貢献の作り方

「OSS にコントリビュートしたことがない」「Star は押すけど PR は出したことがない」という方も多いはずです。ここから Pinned 候補を育てるには、いきなり大きな PR を狙わず、以下のような小さな貢献から始めるのが現実的です。

• タイポ修正の PR: README やドキュメントの誤字脱字を修正する PR。受け入れられやすく、最初の 1 PR を経験するハードルが下がります。
• 翻訳の PR: 英語ドキュメントの日本語化や、日本語ドキュメントの英語化。技術力よりも丁寧さが評価される領域です。
• 小さなバグ修正: good first issue ラベルが付いた Issue を探し、再現と修正を試みる。マージまで至らなくても、Issue でのやり取り自体が「対人シグナル」として残ります。
• 動作確認レポート: 新しいリリースを試して、自分の環境で動いたかをコメントするだけでも、メンテナーへの貢献になります。

これらを少しずつ積み上げて、貢献したリポジトリを Pinned に固定すれば、「他者と協働できる人」としての証拠になります。

NGパターン（toy app・チュートリアル写経・README空・パスワード混入）

逆に、Pinned に置くと評価を下げてしまうリポジトリのパターンも押さえておきます。

• toy app の量産: 「React で ToDo アプリを作ってみた」のような汎用チュートリアル系。同じものを多数の方が公開しているため、差別化にならず「初学者っぽさ」が前に出ます。
• チュートリアル写経: 公式チュートリアルをそのまま動かしただけのリポジトリ。「学習中」のシグナルにはなりますが、案件獲得という観点では弱いです。
• README が空のリポジトリ: README が # my-app だけのリポジトリ。「中身を説明する気がない」と受け取られます。
• パスワード・APIキーの混入: .env をコミットしてしまったまま放置されている。セキュリティ意識への疑念が決定的になります。Pinned 以前にリポジトリの整理が必要です。

これらに該当するリポジトリは、Pinned から外す、もしくは Private に切り替えるだけで全体評価が改善することが多いです。

プロフィールREADMEで「人柄・コミュニケーション能力」を伝える書き方

ここまでで「コードや構成」で見せる準備は整いました。次は「人柄」を伝えるレイヤーです。プロフィール README はこの目的のために最適なスペースです。

プロフィールREADMEの作り方（同名リポジトリの作成手順）

プロフィール README は、自分のユーザー名と同じ名前のリポジトリを Public で作成し、その中に README.md を置くだけで有効になります。たとえばユーザー名が taro-yamada なら、taro-yamada/taro-yamada というリポジトリを作り、README.md を追加する形です。

作成すると、プロフィールページ（https://github.com/taro-yamada）のアバター画像の下に README の内容が表示されます。詳細手順は GitHub 公式の Managing your profile README を参照してください。

5ブロック構成テンプレート

プロフィール README に何を書くか迷ったら、次の 5 ブロック構成を出発点にしてください。

## Profile
Web フロントエンドのフリーランス／TypeScript・React・Next.js を中心に、
要件定義から実装・レビューまで担当しています。

## 直近の関心領域
- フロントエンドのパフォーマンス改善（Core Web Vitals、RSC まわり）
- 小規模チームの CI/CD 整備（GitHub Actions、Vercel）

## 対応可能な領域
- 言語: TypeScript / JavaScript / Go（社内ツールレベル）
- フロント: React / Next.js / Vue（保守）
- バックエンド: Node.js / Hono / Express
- インフラ: Vercel / AWS（Lambda、S3、CloudFront）

## 稼働状況
- 2026年X月以降、週3〜4日の稼働で案件相談可能
- フルリモート希望。打ち合わせ時のみ都内出社対応可

## Links
- 個人サイト: https://example.com
- X: https://x.com/example
- Zenn: https://zenn.dev/example

このフォーマットは、スカウター・エージェント・クライアント担当者のいずれが見ても「次のアクション（連絡）」に移れる構造になっています。

書き方のトーン（誇張しない・気配りの言語化・更新サイクル）

プロフィール README のトーンで失敗しがちなのが「誇張」と「実績の数字羅列」です。「年間 N 案件参画」「コスト N 千万円削減」のような数字は、業務委託では検証が難しく、かえって信頼を損ねることがあります。

代わりに、案件で何に気を配ったかを 1〜2 行で書くと、フリーランスとしての姿勢が伝わります。たとえば「設計時にコードオーナーが交代しても引き継げる粒度のドキュメントを残すよう意識しています」「PR レビューでは『なぜこの設計を選んだか』を 2〜3 行コメントで添えるようにしています」といった、仕事の進め方の癖を言語化すると、人柄シグナルが立ちます。

また、稼働状況は最低でも 3 ヶ月に 1 回は見直しましょう。「2024年X月時点」と古い日付が残っているだけで、「いま声をかけて良いか分からない」という機会損失が発生します。

Issue・PR・コミットメッセージで日常的に伝わる「対人シグナル」

プロフィール README に書ききれない「日常の人柄」は、Issue・PR・コミットメッセージの普段使いに表れます。

• Issue: バグ報告を書くときは、再現手順・期待する挙動・実際の挙動・環境情報をテンプレートに沿って書く。質問の場合も、自分が試したこと・調べたことを添える。
• PR: 「なぜこの変更が必要か」「どんな選択肢を検討して、なぜこれを選んだか」をディスクリプションに残す。レビューコメントへの返信は感謝の一言を添える。
• コミットメッセージ: update files のような大雑把なメッセージは避け、fix: null チェック漏れによるエラーを修正 のように、何のために何を変えたかが分かる形にする。

これらは派手な技術力アピールではありませんが、長く一緒に働く相手としての安心感を作る最も強いシグナルです。

Contributionグラフ（草）を複業エンジニアの生活で継続させる習慣設計

ここまで整備しても、Contribution グラフが完全に真っ白だと「活動が止まっているのでは」と思われます。とはいえ、複業や本業の稼働で時間が限られる中、毎日コミットを積むのは現実的ではありません。続けられる仕組みに落とし込みます。

スカウター視点で「草」が見られている本当の理由（連続性より直近性と説明可能性）

繰り返しになりますが、スカウターが草から知りたいのは「毎日コミットする勤勉さ」ではなく、次の 2 点です。

• 直近のアクティビティ: 直近 3 ヶ月で何かしらの活動があるか。
• 空白期間の説明可能性: 空白がある場合、その理由が読み取れるか（業務委託のクローズドな稼働中、休暇、別業務に集中、など）。

毎日緑にすることを目標にすると、コミットを稼ぐためだけの無意味な作業（空コミット、READMEの小修正の連投）が増えがちですが、これは見る側にも見抜かれます。「直近に動きがあること」と「動きがない期間に説明がつくこと」を満たすのが本来のゴールです。

private contributionsを表示する設定と、業務／個人アカウントの分け方

業務委託で常駐している間、社内 GitHub Enterprise や Private リポジトリでのコミットは、デフォルトでは自分のアカウントの草には反映されません。これを設定で表示することができます。

GitHub の Settings → Profile から「Contributions & activity」セクションに進むと、Private contributions を草に含めるか選択するチェックボックスがあります（Showing an overview of your activity on your profile - GitHub Docs）。これを有効にすると、Private リポジトリでのコミットも「Private contribution」として草に反映されます。リポジトリ名や内容は外部から見えないため、NDA 違反にはなりません。

ただし、業務先の GitHub Enterprise を自分の個人アカウントで利用している場合は注意が必要です。アカウントの所有権・メールアドレスの設定によっては、業務コミットが個人アカウントに紐づかない、あるいは逆に意図せず紐づくケースがあります。業務開始時に「業務用メールが個人アカウントにひも付いているか」を確認し、必要であれば業務用は別アカウントに分ける運用にしておくのが安全です。

週1回30分の「整備タイム」を作る複業エンジニアの運用例

複業エンジニアでも続けやすい現実的な運用として、週末などに「30 分の GitHub 整備タイム」を固定で取る方法があります。30 分で取り組める作業の例は次の通りです。

• プロフィール README の稼働状況を見直す（古い記述があれば更新）
• 直近で読んだ技術記事のメモを Zenn や GitHub の Discussions に書く
• 試した小さなコードを 1 リポジトリにまとめる
• 過去に作ったリポジトリの README を 1 行追記する
• 気になる OSS の Issue を 1 つ読んで、自分用のメモを残す

これらは「コードを書く」必要が必ずしもなく、30 分という上限を決めることで継続のハードルが下がります。週 1 回でも 1 年続けば 52 回。直近 3 ヶ月で 12 回程度の動きが残るため、「動いているアカウント」として認識される最低限のラインを超えられます。

なお、日々の開発生産性そのものを上げる工夫についてはGitHub Copilot × 複業エンジニアの生産性で扱っています。整備時間を捻出するためには、業務時間内の生産性を上げて余白を作る視点もセットで考えると現実味が増します。

コード以外で草が生える貢献（OSS Issue報告・ドキュメントPR・README改善）

GitHub の Contribution グラフは、コミットだけでなく以下のアクションでも草が生えます。

• Issue を作成する
• Pull request を作成する
• Pull request のレビューを行う
• Public リポジトリを作成する
• ディスカッションへの投稿

つまり、ドキュメント PR・Issue 報告・既存 OSS のレビュー参加でも草を生やせます。コードを書く時間が取れない週でも、利用している OSS の README の小さなタイポを直す PR を 1 つ出すだけで、その日の草を埋められます。

「コードを書かないと活動として見なされない」と思い込まず、自分の周りで小さな貢献を見つける癖を付けると、活動の継続性が無理なく維持できます。

GitHubを整えた後にやる「案件獲得への接続」

ここまでで GitHub プロフィール・Pinned・README・草の整備は一通りカバーしました。最後に、整えたアカウントを案件獲得につなげるための運用を整理します。GitHub を整えただけでは案件は来ません。整えた後にどう露出させるかが重要です。

エージェント・スカウト媒体にGitHub URLを出すときの添え方

エージェント担当者に GitHub URL を共有するときは、URL だけを送るのではなく、見どころを 1〜2 行で添えるとアカウントを開いてもらえる確率が上がります。

GitHub プロフィール: https://github.com/your-username
特に Pinned の上 2 つ（プロジェクトA・プロジェクトB）は
直近で力を入れたものです。プロフィール README に
対応領域と稼働状況をまとめています。

スカウト媒体のプロフィールでは、自由記述欄に GitHub の URL を入れたうえで、「Pinned の○○は××の検証用です」のような短い説明を添えておくと、媒体内のスカウター AI による検索ヒット率も上がります。

面談前に「見てほしいPinned」を共有する一言テクニック

面談が決まったら、面談前のメッセージで「特に見ていただきたいリポジトリ」を 1〜2 つだけ事前に共有しておくのも有効です。クライアント担当者は面談前にプロフィールを見ますが、Pinned 6 枠すべてを精査する時間はありません。「××の経験について話したいので、Pinned の○○を見ていただけると話が早いです」と一言添えるだけで、面談冒頭の自己紹介がスムーズになります。

これは小さな配慮ですが、「相手の時間を尊重するエンジニア」という人柄シグナルとして機能します。

X・個人サイト・スキルシートとの相互リンク設計

GitHub・X・個人サイト・スキルシートは、すべて「同じ人物の別チャンネル」として一貫させると、検索や紹介経由で辿られた際に「同一人物」と認識されやすくなります。具体的には次のように相互リンクを張ります。

• GitHub プロフィール README → 個人サイト・X・Zenn・Qiita
• X プロフィール → GitHub・個人サイト
• 個人サイトのプロフィールページ → GitHub・X・スキルシートの公開版（あれば）
• スキルシート（PDF） → GitHub URL を冒頭に明記

スキルシートに GitHub URL を入れる際は、PDF の冒頭、名前と並んで配置すると、エージェントが資料をクライアントに展開した瞬間に GitHub を見にいく流れができます。フォーマットはスキルシート・経歴書の書き方で詳しく扱っているので、あわせて参考にしてください。

まとめ

ここまでの内容を、整備の優先順位順に整理します。

• 採用側の視点は「コードの巧拙」ではなく「信頼シグナルの集積」: スキル・継続性・人柄の 3 シグナルを GitHub から読み取ろうとしている。
• 見られているのは 5 ポイント: プロフィール上部・Pinned・草・README・対人コミュニケーション。整備の優先順位はこの順で組み立てる。
• 業務委託コードは GitHub に上げない: 著作権・NDA の線引きを最初に押さえることで、安心して残りの整備に集中できる。
• NDA 案件の経験は「言葉」で残す: プロフィール README に対応領域・直近案件の概要（NDA配慮）・稼働状況を整理して載せる。
• Pinned は 3〜4 枠を厳選: 量より「目的・スタック・役割」が明記された質。OSS の小さな PR・自分の課題ドリブンの個人開発・技術検証・プロフィール README リポジトリで構成する。
• 草は「直近性」と「説明可能性」: 毎日緑にする必要はなく、直近 3 ヶ月の動きと空白期間の説明がつくことを目指す。週 1 回 30 分の整備タイムが現実的。
• 整えた後は「接続」がセット: エージェントへの URL 共有、面談前の見どころ共有、X・個人サイト・スキルシートとの相互リンク。

今週末から取り組める最低限のチェックリストは以下です。

• プロフィール上部の Bio・Location・公開メールを埋める
• プロフィール README リポジトリを作成し、5 ブロック構成の最小版を書く
• Pinned から「toy app」「チュートリアル写経」「README 空」を外す
• 残った Pinned 3 つに、目的・スタック・役割を 3 行ずつ追記する
• スキルシートとプロフィールの稼働状況の日付を揃える

ここまでが終わったら、次の週末で次の発展ステップに進みます。

• OSS の good first issue から 1 つ選び、タイポ修正でも良いので PR を出す
• 週 1 回 30 分の整備タイムをカレンダーに固定で入れる
• Pinned 候補のリポジトリを 1 つ「目的が明確な小さな個人開発」として育てる

GitHub の整備は、コードを書くことに比べると地味な作業に感じられるかもしれません。ただ、エージェント・スカウター・クライアント担当者は確実にここを見ています。「コードを書けるか」ではなく「この人と仕事をしたいか」を伝える名刺として、週末の少ない時間を投資する価値は十分にあります。次にスカウトメッセージを受け取ったとき、GitHub URL を堂々と返せるアカウントになっていれば、本記事の目的は達成です。