ポートフォリオやGitHubは必要？業務委託で実績を示す方法と整え方

業務委託の多くの案件では、実績の中心はスキルシートと面談での説明で、ポートフォリオやGitHubは必須ではありません。業務で書いたコードは取引先のものであることが多く、公開できないのが普通だからです。ポートフォリオやGitHubは、スキルシートを裏付ける補足として使うものと考えます。

ただし、補足が効く場面もあります。経験の浅い領域に応募するとき、画面や動きを見せたほうが早い職種のとき、技術の選び方や書き方そのものが問われるときです。この記事では、効く場面と効きにくい場面、公開してはいけないもの、見せるときの整え方を整理します。

業務委託で実績が見られる場所

業務委託の選考では、実績はおおむね次の順で見られます。

1. スキルシート：書類選考で、案件の必須スキルと経験が合うかを見る
2. 面談：担当した内容を、自分の言葉で具体的に説明できるかを見る
3. 補足の資料：スキルシートだけでは伝わらない部分を補う

ポートフォリオやGitHubは3つ目に当たります。スキルシートの内容が案件と合っていなければ、補足の資料がよくても選考は進みにくくなります。先に整えるのはスキルシートです。書き方はスキルシートの基本の記事をご覧ください。

ポートフォリオが効く場面・効きにくい場面

経験の浅い領域へ応募する考え方は未経験の領域の記事で解説しています。

公開してはいけないもの

ポートフォリオやGitHubを整えるときに、最も気をつけたいのは、業務で扱った情報を出さないことです。

• 取引先や会社員時代の業務で書いたコード（一部の抜き出しも含む）
• 業務のリポジトリをもとにした複製
• 設計書や画面のキャプチャ、社内の資料
• 取引先の名前が分かるリポジトリ名やコミットのメッセージ
• アクセスキーやパスワード、接続先の情報

業務で書いたコードの権利が誰にあるかや、どこまでが秘密にあたるかは、契約の内容で決まります。「自分が書いたから公開してよい」とは限りません。考え方は成果物の著作権の記事と秘密保持契約の記事、スキルシートでの線の引き方は守秘義務とスキルシートの記事で解説しています。個別の判断が必要な場合は、専門家にご相談ください。

GitHubを見せるときの整え方

見てほしいリポジトリを絞る

アカウントのURLだけを渡すと、読み手はどこを見ればよいか分かりません。案件に関係のあるリポジトリを2〜3個に絞り、それぞれのURLを個別に示します。GitHubでは、プロフィールの画面に特定のリポジトリを固定して表示することもできます。

READMEに4つのことを書く

読み手が最初に開くのはREADMEです。次の4つがあると、短い時間で中身が伝わります。

1. 何のためのものか：解決したい課題を一、二文で
2. 構成：使った技術と、その技術を選んだ理由
3. 動かし方：手元で動かす手順、または画面のキャプチャ
4. 見てほしい点：工夫した設計、テストの書き方など

技術を選んだ理由は、面談で聞かれやすい点でもあります。READMEに書いておくと、面談の準備にもなります。

「量」より「説明できること」

コミットの頻度や、リポジトリの数を気にする必要はあまりありません。読み手が見るのは、書き方が整っているか、テストがあるか、なぜその作りにしたかを説明できるか、といった中身です。古いリポジトリが多い場合は、見せたいものとそうでないものを分けておきます。

コード以外で実績を示す方法

ポートフォリオはコードだけではありません。職種によっては、コード以外のもののほうが伝わります。

• 技術記事：実務に近い問題の調べ方や解決の過程を書いたもの
• 登壇の資料：勉強会などで話した内容
• 資料の型：PM・PMOやコンサルであれば、進捗報告や課題管理の資料の構成を、架空の内容で再現したもの
• OSSへの関わり：Issueの報告や、取り込まれた修正
• 資格：知識の範囲を示す補足として

PM・PMOの資料の型を見せる場合は、実際の案件の資料を加工するのではなく、架空の内容で一から作ります。数字や名前を置き換えても、構成や言い回しから取引先が分かってしまうことがあるためです。

公開する前に見直すこと

ポートフォリオやGitHubを人に見せる前に、次の点を見直します。

1. 業務の情報が入っていないか：取引先の名前、業務のコード、社内の資料、接続先の情報
2. 履歴に秘密の情報が残っていないか：過去のコミットに、鍵や設定ファイルがないか
3. READMEだけで中身が分かるか：目的、構成、動かし方、見てほしい点
4. 動く状態か：手順どおりに動くか。公開しているサイトなら表示が崩れていないか
5. 古いものの扱い：今の自分の書き方と大きく違う古いものは、見せる対象から外すか、作った時期を書く
6. 利用規約や権利：使った素材やデータ、ライブラリの利用条件に反していないか

特に6は見落としやすい点です。公開されているデータや画像でも、使い方に条件が付いていることがあります。

スキルシートや面談での見せ方

スキルシートに載せるときは、URLだけでなく「何を見てほしいか」を一言添えます。分野別の載せ方は、Pythonのスキルシートの記事やReactのスキルシートの記事など、職種ごとの記事でも触れています。

面談で見せる場合は、オンライン面談の画面共有で、READMEや動く画面を数分で見せられるように準備しておきます。面談の時間は限られているため、見せるのは一つに絞り、残りは「詳しくはこちら」とURLを示す程度にとどめます。画面共有の注意点はオンライン面談の記事をご覧ください。

面談で見せたあとに、発注側から追加でコードの説明を求められることもあります。その場合に備えて、見せたリポジトリのうち、自分がいちばん手をかけた部分がどこかを、すぐに開ける状態にしておくと、落ち着いて説明できます。

これから作るなら何を作るか

ポートフォリオがなく、これから作る場合は、次の考え方で選ぶと、手間に対して効果が出やすくなります。

• 狙う案件の業務に近いもの：応募したい案件の業務内容で使う技術・構成に近づける
• 小さく完結するもの：大きなものを途中で止めるより、小さくても動いて説明できるもの
• 実務で足りない部分を補うもの：スキルシートで弱い部分を、一つだけ埋める

作ったものは、実務の経験とは分けて書きます。個人で作ったものを実務の経験のように書くと、面談で深く聞かれたときに説明がかみ合わなくなります。

よくある質問

GitHubのアカウントがない、または中身がほとんどないと不利ですか？

実務の経験が十分にある領域の案件では、大きく不利になることは少ないと考えられます。業務のコードは公開できないのが普通だと、発注側も分かっているためです。経験の浅い領域に応募する場合は、補足として小さなものを用意しておくと、話の材料になります。

会社員時代に書いたコードの一部を、ポートフォリオに載せてもよいですか？

避けてください。業務で書いたコードの権利や秘密の扱いは、就業規則や契約で決まっていることが多く、一部の抜き出しでも問題になることがあります。同じ考え方を示したい場合は、業務とは関係のない題材で一から書き直します。判断に迷う場合は、専門家にご相談ください。

PMやPMOでもポートフォリオは必要ですか？

必須ではありません。PM・PMOの案件では、担当した規模や役割、進め方をスキルシートと面談で説明できることが中心です。補足として、架空の内容で作った資料の型を用意しておくと、進め方を具体的に伝えやすくなります。