GitHubプロフィールだけでは伝わらないこと——ポートフォリオとスキルシートの役割の違い

GitHubのコントリビューションで技術力は見せられる。でも「どんなチームで、どんな役割で、何を解決したか」はコードからは読み取れない。ポートフォリオとスキルシートの使い分けを整理する。

---

「GitHub見てもらえればわかります」の落とし穴

技術力に自信があるエンジニアほど、こう言いがちだ。「GitHubを見てもらえればわかります」。

気持ちはわかる。きれいにメンテされたリポジトリ、活発なコントリビューション、OSSへのPR。これらは間違いなく技術力の証明になる。

でも、ひとつ見落としていることがある。案件の入り口でGitHubを見ている人は、ほとんどいない。

SES、SIer、フリーランス。業態を問わず、案件やプロジェクトの入り口になるのはスキルシートだ。エージェントの営業がクライアントに提案するとき、最初に渡すのはスキルシート。クライアントのPMが面談前に目を通すのもスキルシート。GitHubのURLが載っていたとしても、開いて中身を読む営業は正直なところ希少だ。

なぜか。GitHubを見る人と、案件の窓口にいる人はセグメントが違うからだ。GitHubのコードを読んで評価できるのは同じエンジニアだ。でも案件の最初のフィルタリングをしているのは、営業やPMや人事。彼らが知りたいのは「この人にどんな仕事を任せられるか」であって、コードの品質ではない。

たとえるなら、GitHubは「作品」だ。料理人で言えば実際に作った料理そのもの。一方、スキルシートは「お店の看板」だ。看板がなければ、どれだけ美味い料理を作れても、お客さんはお店の存在に気づかない。見てもらう・見てもらわないに関わらず、自分という存在を伝える最初の接点がスキルシートだ。

GitHubとスキルシートは役割が違う。どちらが上でも下でもない。でも「技術力があるからスキルシートは別にいい」というのは、率直に言って怠慢だ。技術力があるなら、それを伝えるための看板もちゃんと整えるべきだ。

---

GitHubで「伝わること」と「伝わらないこと」を整理する

ここで一度、GitHubから読み取れる情報と読み取れない情報を整理しておこう。

GitHubから伝わること

• コードの書き方、設計の思想、技術的な引き出し
• 使っている技術スタック、興味のある分野
• OSSへの関心、コミュニティへの貢献姿勢
• 学習意欲、アウトプットの頻度

これらは技術者同士の評価では非常に有効だ。コードレビューの文化があるチームなら、GitHubを見て「この人のコードなら安心だ」と判断できる。

GitHubからは伝わらないこと

• どんなチーム構成で、どんな役割を担っていたか
• プロジェクトの規模感（何人チーム、何ヶ月、どんな業界）
• 非技術者（PM、クライアント）とどう協業していたか
• 課題に対して、なぜその技術選定をしたのかの判断プロセス
• 障害対応やトラブルシューティングの経験
• 上流工程（要件定義、設計レビュー）への関わり

特にSESやフリーランスの案件選定では、「チームでどう動けるか」が重要な選定基準になる。以前「エンジニアに求められる「コミュ力」は、明るさじゃない」でも書いたが、技術力は前提で、その先の「一緒に働けるか」で選ばれるかどうかが決まる。

この「一緒に働けるか」の情報は、GitHubからは読み取れない。

もう一度強調しておくと、GitHubが無意味だと言っているわけじゃない。技術力の証明としてGitHubは最強のツールだ。でも、案件獲得のプロセスにおいて「最初に見られるもの」はGitHubではなくスキルシートだ。入り口を通過しなければ、作品を見てもらう機会すら来ない。

---

ポートフォリオ・GitHub・スキルシート——3つの使い分け

エンジニアが自分を伝えるためのツールは、大きく3つある。それぞれ役割が違う。

ポートフォリオ：「何を作れるか」の証明

個人開発や副業で作ったプロダクトを見せるもの。完成物のクオリティ、UI/UXのセンス、企画力が伝わる。特に自社開発企業への転職や、フリーランスの直接営業で力を発揮する。

GitHub：「どう書くか」の証明

コードそのものの品質、設計思想、技術的な深さが伝わる。エンジニア同士の評価で最も信頼される。OSSコントリビューションがあれば、コミュニティへの関与も示せる。

スキルシート：「どう働くか」の証明

チーム開発でどんな役割を果たしたか、どんな課題をどう解決したか。プロジェクトの文脈込みで自分の経験を伝えるもの。SES・フリーランス・転職の書類選考で最初に見られる資料。

この3つは競合関係にない。補完関係だ。

ポートフォリオで「何が作れるか」を見せて、GitHubで「どう書くか」を証明して、スキルシートで「どう働くか」を伝える。3つが揃っていると、エンジニアとしての全体像がくっきり見える。

問題は、多くのエンジニアがこの中の1つか2つしか用意していないことだ。特にGitHubが充実している人ほど、スキルシートを軽視しがちだ。

繰り返しになるが、GitHubは「作品」、スキルシートは「看板」だ。腕のいい料理人が看板も出さずに裏路地で店を開いても、客は来ない。作品のクオリティと、看板の整備は、別の仕事だ。両方やるべきだし、両方やってこそプロだ。

---

スキルシートでしか伝えられない情報とは

では、スキルシートでしか伝えられない情報とは何か。具体的に挙げてみる。

逆に言えば、以下の情報がスキルシートに書かれていなければ、読む側は「この人がどう働くか」を判断する材料がない。GitHubが充実していても、ここが空白だと書類選考を通過できない。

プロジェクトの規模と背景

「5名チームで、toB向けSaaSの新規機能開発を6ヶ月担当」。この情報だけで、読む側は「この人はどのくらいの規模感の仕事をしてきたか」を把握できる。GitHubの個人リポジトリからは、こういった文脈は伝わらない。

担当フェーズと役割

要件定義から入ったのか、設計から入ったのか、実装だけなのか。リーダーだったのか、メンバーだったのか、レビュワーだったのか。同じ「Reactの経験あり」でも、どのフェーズでどう関わったかで評価はまったく変わる。

課題解決のストーリー

「何が問題で、自分がどう動いて、結果どうなったか」。前回の記事「エンジニアの自己PRを「STAR法」で構造化する」で紹介したフレームワークがまさにこれだ。このストーリーはスキルシートの自己PRや経歴詳細でしか伝えられない。

チームへの貢献

コードレビューの文化を作った、オンボーディング資料を整備した、障害対応フローを改善した。こういった「チームを良くする動き」は、GitHubにもポートフォリオにも載らない。でも現場では非常に高く評価される。

コミュニケーションの姿勢

「報連相の型」の記事でも書いたが、チーム開発における報連相の質や、非技術者との協業経験も、スキルシートの経歴詳細で初めて伝えられる情報だ。「要件定義フェーズでクライアントとのヒアリングを担当」と書いてあるだけで、その人のコミュニケーション力が伝わる。

「月単価100万超えのエンジニアの共通点」を見ても、技術力だけで上に行けた人はほぼいない。スキルシートで「自分がチームにどう貢献したか」を言語化できるかどうかが、単価にも直結する。

---

GitHubとスキルシートを連携させるベストプラクティス

GitHubとスキルシートは、別々に存在するよりも連携させたほうが効果的だ。具体的なやり方をいくつか紹介する。

スキルシートにGitHubリンクを載せる

シンプルだけど効果的。スキルシートの基本情報欄やポートフォリオ欄にGitHubのURLを記載する。「もっと詳しく技術面を見たい方はこちら」という導線を作れる。

ただし、リンクを載せるなら最低限の整備はしておきたい。プロフィールREADMEが空、リポジトリの説明が未記入、数年前のコードが放置されている状態だと、逆効果になりかねない。

経歴とリポジトリを対応づける

スキルシートの経歴詳細に「関連リポジトリ：github.com/xxx/yyy」と添えておく。こうすると、技術力を深掘りしたい面談担当者がすぐにコードを確認できる。もちろんNDAに抵触しない範囲に限るが、個人開発やOSS貢献であれば問題ないケースが多い。

GitHubのREADMEからスキルシートの共有リンクを貼る

逆方向の連携もできる。GitHubのプロフィールREADMEに「詳しい経歴はこちら」としてスキルシートの共有リンクを貼る。GitHubを見た技術者が「この人の仕事全体像を知りたい」と思ったとき、ワンクリックでアクセスできる。

Skillsheet-Port なら共有リンクに有効期限やパスワードを設定できるので、公開範囲をコントロールしながらGitHubと連携できる。匿名公開モードを使えば、氏名や連絡先を伏せたまま経歴だけを見せることも可能だ。

▶ 無料でスキルシートを作ってみる → https://www.skillsheet-port.com/

---

まとめ——コードだけでは伝わらない。「どう働くか」を言語化しよう

GitHubは強力なツールだ。技術力を証明するには、これ以上のものはない。

でもそれだけでは、「この人に仕事を任せられるか」は判断できない。どんなチームで、どんな役割で、何を解決してきたか。この情報を伝えるのがスキルシートの仕事だ。

GitHubとスキルシートは、どちらが偉いかという話じゃない。技術力と仕事力、両方を伝えて初めて、エンジニアとしての全体像が見える。

案件の入り口に立つのはスキルシートだ。そこを通過して初めて、面談があり、技術の話ができ、GitHubを見てもらえる。看板を出さずに「作品を見ればわかる」では、チャンスの入り口に立てない。

**コードで「どう書くか」を証明し、スキルシートで「どう働くか」を伝える。**この両輪が揃っているエンジニアは、どの現場でも選ばれる。

GitHubを磨くのと同じくらいの熱量で、スキルシートも整えてみてほしい。技術力があるなら、なおさらだ。その技術力を正しく伝える看板がないのは、もったいないどころではない。