「GitHub見てください」で止まるエンジニアが損する理由——3つの役割を整理
「技術力はGitHubを見てもらえればわかります」——そう言いたくなる気持ちはわかる。
だが案件の入り口でGitHubを見ている人は、ほとんどいない。
この記事では、GitHub・ポートフォリオ・スキルシートの3つの役割の違いを整理し、連携のベストプラクティスを紹介する。
この記事は GitHubプロフィールだけでは伝わらないこと——ポートフォリオとスキルシートの役割の違い のダイジェスト版です。
「スキルシートでしか伝えられない情報」の詳細は、上記の完全版をどうぞ。
「GitHub見てもらえればわかります」の落とし穴
技術力に自信があるエンジニアほど、こう言いがちだ。「GitHub見てください」。きれいにメンテされたリポジトリ、活発なコントリビューション、OSSへのPR。これらは確かに技術力の証明になる。
だがひとつ見落としがある。案件の入り口でGitHubを見ている人はほとんどいない。
SES・SIer・フリーランスを問わず、案件の入り口になるのはスキルシートだ。エージェントの営業がクライアントに提案するとき、最初に渡すのはスキルシート。クライアントのPMが面談前に目を通すのもスキルシート。GitHubのURLが載っていても、開いて読む営業は希少だ。
理由はシンプルで、GitHubを見る人と案件の窓口にいる人はセグメントが違うからだ。GitHubのコードを評価できるのは同じエンジニア。だが案件の最初のフィルタリングをしているのは営業・PM・人事であり、彼らが知りたいのは「この人にどんな仕事を任せられるか」だ。
たとえるなら、GitHubは「作品」、スキルシートは「お店の看板」だ。看板がなければ、どれだけ良い作品を持っていても入り口に立てない。
GitHubで伝わること / 伝わらないこと
GitHubから読み取れる情報と読み取れない情報を整理しておきたい。
| 観点 | GitHubで伝わる | GitHubでは伝わらない |
|---|---|---|
| コードの品質 | ✅ 書き方・設計思想・技術的な引き出し | |
| 技術スタック | ✅ 使っている技術・興味のある分野 | |
| 学習姿勢 | ✅ コミット頻度・OSS貢献 | |
| チーム構成・役割 | ❌ 何人チームで、どんな役割だったか | |
| プロジェクト背景 | ❌ 業界・規模感・期間 | |
| 課題解決プロセス | ❌ なぜその技術を選んだかの判断プロセス | |
| 非技術者との協業 | ❌ PM・クライアントとどう協業したか | |
| 上流工程の経験 | ❌ 要件定義・設計レビューへの関わり | |
| チームへの貢献 | ❌ コードレビュー文化の醸成・オンボーディング整備等 |
SESやフリーランスの案件選定で重要視されるのは、右側の「伝わらないこと」の方だ。技術力は前提で、その先の「一緒に働けるか」で選ばれるかが決まる。
3つのツールは補完関係にある
エンジニアが自分を伝えるツールは大きく3つある。それぞれ役割が違い、競合関係ではなく補完関係だ。
| ツール | 役割 | 得意な場面 |
|---|---|---|
| ポートフォリオ | 「何を作れるか」の証明 | 自社開発企業への転職・フリーランスの直接営業 |
| GitHub | 「どう書くか」の証明 | エンジニア同士の評価・OSSコミュニティ |
| スキルシート | 「どう働くか」の証明 | SES・フリーランス案件・書類選考の入り口 |
ポートフォリオで「何が作れるか」を見せて、GitHubで「どう書くか」を証明して、スキルシートで「どう働くか」を伝える。3つが揃っていると、エンジニアとしての全体像がくっきり見える。
多くのエンジニアがこの中の1つか2つしか用意していない。特にGitHubが充実している人ほどスキルシートを軽視しがちだ。だが作品のクオリティと、看板の整備は別の仕事であり、両方やって初めてプロと言える。
▶ 「スキルシートでしか伝えられない情報」の詳細はこちら → GitHubプロフィールだけでは伝わらないこと
GitHubとスキルシートを連携させるベストプラクティス
GitHubとスキルシートは別々に存在するよりも、連携させた方が効果的だ。
スキルシートにGitHubリンクを載せる。 基本情報やポートフォリオ欄にGitHubのURLを記載し、「技術面を深掘りしたい方はこちら」という導線を作る。ただしリンクを載せるならプロフィールREADMEや主要リポジトリの最低限の整備は必要だ。放置されたリポジトリが並んでいると逆効果になる。
経歴とリポジトリを対応づける。 スキルシートの経歴詳細に「関連リポジトリ: github.com/xxx/yyy」と添えておくと、技術力を深掘りしたい面談担当者がすぐコードを確認できる。NDAに抵触しない範囲、つまり個人開発やOSS貢献に限るが、効果は大きい。
GitHubのREADMEからスキルシートへ逆リンクを貼る。 GitHubのプロフィールREADMEに「詳しい経歴はこちら」としてスキルシートの共有リンクを貼る。GitHubを見た技術者が「この人の仕事全体像を知りたい」と思ったとき、ワンクリックでアクセスできる。
この逆方向の連携は特にQiitaユーザーに相性がいい。Skillsheet-Port なら共有リンクに有効期限やパスワードを設定できるので、公開範囲をコントロールしながらGitHub連携ができる。匿名公開モードを使えば、氏名や連絡先を伏せたまま経歴だけを見せることも可能だ。
まとめ
- 案件の入り口はGitHubではなくスキルシート
- GitHubは「コードの品質」を証明するが、チーム内での役割や課題解決プロセスは伝えられない
- ポートフォリオ・GitHub・スキルシートは補完関係。3つ揃うとエンジニアの全体像が見える
- GitHubとスキルシートは相互リンクで連携させると効果的
コードで「どう書くか」を証明し、スキルシートで「どう働くか」を伝える。この両輪が揃っているエンジニアは、どの現場でも選ばれる。技術力があるなら、それを正しく伝える看板も整えておきたい。
▶ 完全版ガイドはこちら → GitHubプロフィールだけでは伝わらないこと
▶ 無料でスキルシートを作ってみる → https://www.skillsheet-port.com/