【フェーズ2-5】 GitHubを、公開の場のハブとして育てる。フェーズ2の成果物を束ねて、世界に見せる 【ITエンジニアの卵に贈る、就活の書】
この記事は「ITエンジニアの卵に贈る、就活の書」シリーズの一本です。シリーズ全体の目次はこちら（扉記事）からご覧いただけます。
エンジニアを目指す学生のみなさん、こんにちは。クオリティアーツの池田です。
ITエンジニアの卵に贈る、就活の書・フェーズ2-5の記事です。前回のフェーズ2-4では、技術書を血肉にする3拍子の話をしました。今回はフェーズ2「作る」の実践各論11本のうちの3本目、GitHubを、公開の場のハブとして育てるというお話です。フェーズ2全体のハブ記事としての位置づけも兼ねます。
GitHubは、学生時代のみなさんが最も長い時間、最もじわりと、しかし最も確かに、自分の軌跡を残せる場所です。授業も、卒業研究も、技術書の写経も、ハッカソン成果物も、個人開発も、勉強会のサンプルコードも、長期インターンの業務外での勉強も、そのほとんどは、最終的にGitHubに集まっていきます。フェーズ2の各論はGitHubというハブに束ねられて、はじめて世界に見える形になる。ここでの積み上げが、就活の書類選考の1枚目に強く効いてきます。
この記事は、フェーズ2全体の「公開の場のハブ」として位置づけています。フェーズ2-3以降の各記事では、GitHubへの残し方の詳細は本記事に集約し、各記事は各記事固有の道具立て（Zenn/Qiita、Speaker Deck/Docswell、connpass、OSSなど）を主役に扱います。GitHubの育て方については、いつでもここに戻ってきてください。
新卒の就活中の方はもちろん、第二新卒として他社の面接に臨む場面でも、GitHubの育て方は共通です。
1. GitHubは、世界のエンジニアが集まる舞台
GitHubは、単なるバージョン管理サービスではありません。世界のエンジニアが集まり、コードを共有し、学び、対話する舞台です。Linux Kernel、Kubernetes、React、Vue、Next.js、Deno、Node.js、TypeScript、Rust、Go、PostgreSQL、PyTorch、Hugging Face Transformers、Docker、Terraform。世界を支えるOSSプロダクトの多くが、GitHub上で開発されています。
Anthropic、OpenAI、Vercel、Cloudflare、Netflix、Meta、Google、Stripe、Figmaといったテックカンパニーも、多くの重要な成果物をGitHubで公開しています。
学生時代のみなさんがGitHubにアカウントを持ち、そこに自分のポートフォリオを積み上げていくということは、世界基準の本物のエンジニアたちと、同じ土俵に自分を乗せることでもあります。序章-2で語った世界基準のエンジニアの入口が、GitHubのアカウントページから開いています。この「同じ土俵」の視点は、記事の後半でもう一度立ち返ります。
多くの IT企業が、書類選考や面接の前に、候補者のGitHubを検索します。株式会社メルカリの新卒書類選考では、ブログやGitHub、研究内容、作品などを添付するように公式に指示されています（出典：メルカリ公式採用サイト）。サイボウズ株式会社は、書類選考の提出物としてGitHubとポートフォリオを公式に明示しています。面白法人カヤックの「つくったもの選考」は、GitHubやポートフォリオサイトのURLだけで応募できる枠です。
GitHubは、就活の書類選考の実質的な一部として、企業側にはっきり位置づけられています。
2. プロフェッションから見た GitHub の意味
序章-1で、私はエンジニアという職業を、公衆の福利を担うプロフェッションとして位置づけました。IEEE-CS/ACMのソフトウェアエンジニア倫理綱領の第1原則は、公衆の福利を最優先することを求めています。
GitHubに自分のコードを公開するという行為は、この視座から見ると、単なる自己アピールではありません。あなたの学びと工夫を、次に学ぶ誰かのために、世界に開いておくという行為です。あなたの拙い1年生のコードが、5年後にどこかの誰かの入口になっている、ということも起こり得ます。世界のOSSは、こうした無数の連鎖の上に成り立っています。
GitHubを、日常の一部として、そして公開の場のハブとして育てるという視座は、就活のためだけではなく、プロフェッションとして生涯続く公衆への貢献の、いちばん最初の1歩目でもあります。
3. GitHubを育てる3つの層
GitHubの育て方には、3つの層があります。層が深くなるほど、就活の場面での重みも増していきます。
3-1. 層1：アカウントとプロフィール
まず、アカウントを作ります。ここは全員が、遅くとも大学2年のうちに済ませてほしいところです。
本名かハンドルネームで、一貫したアカウント名：Zenn、Qiita、Speaker Deck、X との整合を取る
プロフィール文：自分の関心事、志望する技術ドメイン、いま学んでいることを、3〜5行で
プロフィールREADME：自分のリポジトリ `username/username` を作ると、アカウントページのトップに表示される特別なREADMEになる。使用言語、主要プロダクトへのリンク、技術ブログURL、Speaker Deck URL、Wantedly、LinkedIn などを整理して置く
アイコン：顔写真でなくてもよい。同じアイコンを他のプラットフォームでも使う
これだけで、あなたの名前を検索した企業の担当者は、GitHubのアカウントページから、あなたの全体像を1枚で受け取れるようになります。
3-2. 層2：Public リポジトリ
次に、Public リポジトリを育てていきます。ここが、GitHub 育成の中心です。
Public リポジトリには、次のような種類のものが置かれます。
個人開発のプロダクト（TypeScript + Next.js + Vercel、Python + FastAPI + Fly.io、Rust + WebAssembly、Swift + iOS など、世界基準のスタックで組んだもの）
授業や卒業研究の実装（フェーズ2-3で扱った授業の演習、卒論の実装）
技術書を読んで作ったコード（フェーズ2-4で扱った写経、スクラッチ実装、アレンジ）
ハッカソンの成果物（フェーズ2-6で扱う）
技術ブログの記事に対応するコード（記事から辿れるように）
OSS への貢献のフォーク（本家へのPRを送ったとき、自分のforkも残しておく）
設定ファイル、Dotfiles、開発環境のセットアップ（自分の開発環境を再現できる形で公開する文化がある）
学生時代のうちに、Public リポジトリの数を10〜20、そのうち5つ程度に丁寧なREADMEと動く実装を目指すのが、現実的な目安です。数を稼ぐことよりも、フェーズ2-2で扱った公開の3条件（公開されている、意図が追える、公開してよい質）を満たすことのほうが大事です。
3-3. 層2.5：テストコードは、リポジトリの「もう1つの顔」
Public リポジトリを見る側は、実装コードだけでなく、テストコードの有無と量もしっかり見ています。README にテストの実行方法が書かれているか、`tests/` や `tests/` といったディレクトリに一定量のテストがあるか、CIバッジが緑色で並んでいるか。これらは、「動くコードを書いた」だけでなく「動くことを自分で確かめ続けている」という証拠になります。
テストの厚みには、テストピラミッドという考え方があります。土台に数の多い単体テスト、その上に結合テスト、頂点に数の少ないE2E（画面操作を通した）テストを積む、という比率の考え方です。
すべてのリポジトリでピラミッドを完璧に作る必要はありませんが、まず単体テストから積むという順番を知っておくと、個人開発でテストを書き始めるときの迷いが減ります。カバレッジ（コードのうちテストで通過した割合）を計測するツールを1つ導入し、READMEにバッジを貼っておくだけでも、リポジトリの印象は変わります。
テストを、GitHub Actions で自動で回す
テストコードを書くだけでも十分な一歩ですが、そこにGitHub Actions（GitLab CIも同様）を1つ加えると、リポジトリの見え方が一段変わります。Pull Request のたびにテストが自動で走り、その結果が緑または赤で表示される。テストが緑色で通り続けている状態を、Action の履歴が証拠として残す。これは、実装コードとは別の、地味だけれど強い評価軸です。
実際の設定は10行前後のYAMLファイルで書けます。具体的な書き方、カバレッジ計測、pre-commit hookの設定などは、番外編B8「GitHub／GitLabを高度に使いこなす、その深いレベルまで」（執筆予定）で詳しく扱います。この記事で最初に押さえてほしいのは、テストと自動実行の組み合わせが、就活のGitHubの見え方を確かに変える、という1点です。
3-4. 層3：Contributionsとコミット履歴
3つ目の層が、Contributionsグラフとコミット履歴です。GitHubのプロフィールページには、日々の活動を緑色のマスで示す Contributions グラフがあります。
このグラフには、あなたの日常性が表れます。毎日1コミットしなくてもいいのですが、週に何日か、月に何度か、緑のマスが灯っている状態が続いているかどうかは、書類選考の担当者に、あなたの学びの継続性を伝えます。
同時に、コミットのメッセージも見られています。コミットメッセージが単なる `fix` や `update` ばかりのリポジトリと、コミットごとに何を、なぜ変えたかが1行で伝わるリポジトリでは、書類選考の重みが違います。Conventional Commits の型（`feat:`, `fix:`, `refactor:`, `docs:`, `test:` など）を使うかどうかは自由ですが、コミット1つ1つに意図が滲む形で書く習慣は、社会人になっても実務で重宝します。
4. GitHubを育てる、世界基準の道具
GitHubを日常の一部として、そしてフェーズ2の公開の場のハブとして育てるとき、周辺の道具立ても、世界基準のものに揃えていくと、成果物の強度が上がります。
エディタ：VS Code、Cursor、Zed、JetBrains IDE
AI コーディングアシスタント：GitHub Copilot、Cursor、Claude Code、Codeium
テスト：Jest、Vitest、pytest、Go標準の testing パッケージなど、言語ごとの標準的なテストツール
CI/CD：GitHub Actions（テスト、ビルド、デプロイの自動化）
依存関係の管理：Dependabot、Renovate
セキュリティ：CodeQL、Snyk、Semgrep
プレビュー・デプロイ：Vercel Preview、Cloudflare Pages、Netlify Deploy Previews
コードレビュー：Pull Request のセルフレビュー、レビュアーへの依頼
Issue と Project：GitHub Issues、GitHub Projects でタスクを可視化する
これらの道具は、世界のテックカンパニーが日常的に使う道具立てです。学生時代のうちに、個人開発のリポジトリに GitHub Actions を1つ設定してみる、Vercel Preview を有効にしてみる、Renovate で依存関係の自動更新を回してみる、といった小さな体験を積むと、その一つ一つが、書類選考と面接の場面で強く効いてきます。
なかでもテストコードとCIの組み合わせは、動くコードと動くことを保証するコードの両方を持っている証拠になり、README に貼られたテストのバッジ1つが、控えめな見た目のわりに確かな品質への配慮として伝わります。
5. 世界基準のスタックで、共通言語を持つ
GitHubを公開の場のハブとして育てるとき、そこに置くコードのスタックにも、少しだけ気を配ってほしいところがあります（言語・フレームワーク・実行環境の組み合わせ）。世界のテックカンパニーで日常的に使われているスタック（TypeScript + Next.js、Go + Docker + Kubernetes、Python + FastAPI、Swift + SwiftUI など）で組まれたリポジトリは、書類選考でも面接でも、共通言語で会話が始められます。学生時代のうちに、志望領域に合う世界基準のスタックを1組選び、GitHubのPublicリポジトリで一定量のコードを書いておく。これだけで、書類の1枚目の伝わり方が変わります。
どんなスタックが世界基準として名前が挙がるか、そして日本の一部の現場でいまも使われている古い世代のスタック（Windows Server + IIS + .NET Framework 4.x、Struts + JSP、jQuery依存など）との距離感を、就活の物差しにどう組み込むかは、番外編B8「GitHub／GitLabを高度に使いこなす、その深いレベルまで」（執筆予定）で詳しく扱います。
1点だけ、ここで書いておきます。古いスタックの保守そのものは、社会インフラを支える大切な仕事で、批判の対象ではありません。ここで問いたいのは、「その会社が、新しい世界基準の道具に若手を触れさせる機会を、日常的に提供しているかどうか」の1点です。この問いは、フェーズ3〜4の企業リサーチと面接での対話の中で、じっくり確かめていくことになります。
6. 学生時代からGitHubに乗せることは、本物のエンジニアと同じ土俵に上がること
ここで、就活の本質に関わる話を1つ書きます。
GitHub（そして同じ位置づけを持つGitLab）は、単なるバージョン管理ツールではありません。世界基準の開発現場では、開発・レビュー・自動テスト・自動デプロイ・運用・チーム対話・知識共有・OSS貢献のすべてが交差するハブとして使われます。
この使いこなしの深さには、はっきりとした段階があります。大きく5段階（Level 0〜Level 4）に整理できます。
Level 0：そもそもGit（GitHub／GitLab）を業務で使っていない。SVN、TFS、ZIP共有中心
Level 1：GitHub／GitLabを導入しているが、単なるバージョン管理ツールとしてしか使えていない。Pull RequestもCIも実質的に動いていない
Level 2：Pull Request（Merge Request）中心のワークフローが回っている。世界標準の入口
Level 3：GitHub Actions／GitLab CIでCI/CDが回り、DevOpsの中核として機能している
Level 4：Issues／Projects／Discussions／Dependabot／OSS貢献支援まで含め、開発・運用・知識共有の中核として使いこなしている
5段階それぞれの詳細、具体的な運用例、企業の使いこなしレベルを見分ける方法は、番外編B8「GitHub／GitLabを高度に使いこなす、その深いレベルまで」（執筆予定）で扱います。ここでは、就活の観点からいちばん大切な1点だけをお伝えします。
それは、学生時代に、あなたが自分のポートフォリオをGitHub（あるいはGitLab）に乗せるということは、Level 3〜Level 4の会社の現役エンジニアと、同じ土俵に自分を乗せるということ、という1点です。
あなたが `.github/workflows/test.yml` を1つ書き、Pull Requestを出してCIを緑にした瞬間、あなたの手つきは、NetflixやStripeのエンジニアの手つきと、道具立てとしては同じものになります。拙くても、道具立てが同じなら、土俵は同じです。世界のOSSに貢献する数百万人のエンジニアたちが集うのと同じプラットフォームに、あなたの名前と成果物が並ぶ。これが、学生時代からGitHubに乗せることの本当の意味です。
この「同じ土俵」の視点は、就活で2つの方向に効いてきます。
1つは、書類選考の場で、あなた自身の土俵の高さが伝わること。Publicリポジトリの中身、READMEの丁寧さ、CIバッジの有無、Contributionsグラフの日常性から、書類選考の担当者は、あなたがどの段階の土俵で日常を作ってきたかを、しっかり読み取ります。新卒でLevel 4まで到達している必要はまったくありません。ただ、Level 2〜Level 3くらいまで踏み込んで積み上げてきた学生は、書類の1枚目からはっきり目立ちます。
もう1つは、企業を選ぶ側の物差しになること。あなたが学生時代にLevel 3の土俵で日常を作ってきたとして、就職先がLevel 1（GitHubを単なるバージョン管理ツールとしてしか使っていない）だったら、入社1日目から土俵が下がることになります。学生時代に身につけた道具立ての多くが業務では使えなくなり、日常のリズムも変わる。この差は、1〜3年目のキャリアの伸び方に、確かな形で現れます。
念のため書きますが、Level 0〜Level 1の環境で働く技術者たちの仕事が悪いわけではありません。既存の顧客システムや社会インフラの一部は、その道具立ての上で動き続けており、維持している技術者たちの働きは、日本社会をじっくり支えています。ここで話しているのは、若手エンジニアのキャリアの選び方の話です。
あなたの学生時代の土俵の高さを、就職後も下げないでほしい。
応募前に、志望する企業のGitHub Organization（`github.com/企業名`）やGitLab Group（`gitlab.com/企業名`）を検索し、Publicリポジトリの活気を眺めてみてください。カジュアル面談で「開発はPull Request中心ですか」「CI/CDは何を使っていますか」と聞いてみるだけでも、その会社の土俵の高さの手がかりが取れます。企業の使いこなしを見分ける具体的な方法は、番外編B8で整理します。
7. OSSへのコントリビューションで、第三者の目利きを通す
GitHubを育てる中で、多くの学生さんが「難しそう」と感じるのが、OSSへのコントリビューションです。フェーズ2-2で扱ったとおり、OSS プロジェクトの Contributors 欄、Changelog、リリースノートの謝辞に自分の名前が載ることは、第三者の目利きが働く場所での実績として、圧倒的な重みを持ちます。
最初の1歩として、次のような小さな貢献から始められます。
ドキュメントのtypo修正、日本語訳の改善：多くのOSSは、ドキュメントの改善Pull Request を歓迎します
エラーメッセージの改善提案：自分がハマった場所を、次の人のために直すPR
サンプルコードの追加：READMEの Quickstart にサンプルを1つ追加するPR
翻訳への参加：Vue.js、React、Next.js、TypeScript の日本語ドキュメント翻訳など
好きなライブラリのバグ報告と修正：使っていて気づいた小さなバグを、Issueで報告してPRを送る
いきなり Kubernetes や React 本体にPRを送る必要はありません。自分が実際に使って、感謝している小さめのOSSに、感謝の気持ちで一手間を返す。この規模から始めると、無理なく続けられます。GMOペパボ株式会社は、新卒エンジニアの選考で「OSSプロダクトへのコントリビューションまたは開発経験」を公式の加点要素として明示しています（出典：GMOペパボ新卒採用サイト）。企業側も、OSSへの参加の有無を、しっかり見ています。
8. 過去のリポジトリと向き合う
GitHubを育て始めるとき、多くの学生さんが直面するのが、「過去のリポジトリが恥ずかしい」という気持ちです。1〜2年生の頃に作った拙いコード、READMEのないリポジトリ、動かない実験、他人のチュートリアルの写経のまま放置されたもの。過去の作品と正直に向き合ったとき、目を逸らしたくなる瞬間があります。
フェーズ2-2で触れたとおり、放置されたリポジトリは、あることでかえって減点材料になり得ます。ここでの選択肢は、いくつかあります。
READMEを整えて、成長の過程として位置づけ直す：1年生のときの実装、として明示すれば、それは軌跡になる
アーカイブ状態にする：GitHubのArchiveは、リポジトリを読み取り専用にする機能。「過去の作品として、いまはメンテしていない」という意志表示
プライベート化する：見せたくないものは、Private に移す（削除するより、履歴を残せる）
削除する：本当に見せたくないものは、削除も選択肢
過去の作品と正直に向き合い、いまの自分にとって公開してよい形に整える。この作業自体が、プロフェッションとしての整え直しです。
9. プロフェッションとして育つ環境を持つ会社は、GitHub の文化を持っている
シリーズ全体を貫く上位原則を、この記事でも確認します。その会社は、エンジニアをプロフェッションとして育つ環境を持っているか。
プロフェッションとして育つ環境を持つ会社は、多くの場合、社内でGitHubを実務的な道具として使いこなし、社員がOSSに貢献する文化を持っています。GitHub Enterpriseの運用、Pull Request中心の開発フロー、コードレビューの文化、社員によるOSSコントリビューションの公式支援、社内のライブラリを外部OSSとして公開する取り組み。
実例を1つ挙げます。株式会社ディー・エヌ・エー（DeNA）は、GitHub Enterpriseを運用し、OSS活動サポートやDeNA TechConを通じた技術発信を行っていることを、公式に発信しています（出典：DeNA新卒採用サイト）。
コードと開発文化への向き合い方は、経営層や部課長の言葉のなかに、いちばん正直に表れます。募集要項の「GitHubアカウント歓迎」の1行、社員が公開している技術ブログでのGit運用の記事、CTOのTwitter/X アカウントでの発信内容。これらを合わせて読んだときに、その会社がGitHub中心の文化を持っているかどうかが、そっと見えてきます。
あわせて、コードレビュー文化の姿にも注目してほしいところです。Pull Request のレビューが、実装の粒度や設計の是非、テストケースの網羅性、命名の妥当性まで踏み込んだ形で回っている会社は、コードを一人の作業ではなくチームの共有物として扱っています。逆に、レビューが「承認だけを押して終わる」形骸化した儀式になっている会社では、コードの品質は個人の技量に依存し、育つ環境は薄くなります。
カジュアル面談やオファー面談の場で、「コードレビューの1件あたりの平均所要時間や、指摘の粒度を教えてください」と聞いてみると、会社ごとに答え方が大きく違うことに気づきます。
変化の途上にある会社の姿も、それはそれで信頼できる兆候です。「うちは長年SVNだったが、いまGitへの移行を進めている」「Pull Requestは新人研修から扱っている」「レガシー案件は残っているが、新規案件はTypeScript + Next.jsで組んでいる」といった発言は、その会社が現状に留まらず、変化と付き合う姿勢を持っていることを示します。学生としては、いまの姿だけでなく、その会社の変化の向きも一緒に読み取ってほしいと思います。
まとめ
本記事では、GitHubを公開の場のハブとして育てる（＝日常の一部として、フェーズ2の各成果物を束ねる場所として育てる）お話をしました。要点は次のとおりです。
GitHub（および同格のGitLab）は、世界のエンジニアが集まる舞台です。学生時代のうちにアカウントを置き、自分の軌跡を積み上げていくことは、世界基準の本物のエンジニアたちと同じ土俵に自分を乗せることでもあります。
GitHubを構成する3つの層は、アカウントとプロフィール、Publicリポジトリ、Contributionsとコミット履歴。テストコードとCI（GitHub Actions／GitLab CI）を組み合わせるだけで、リポジトリの見え方は一段変わります。世界基準のスタック（TypeScript + Next.js、Go + Docker + Kubernetes、Python + FastAPIなど）で組んだリポジトリは、書類選考や面接で共通言語の会話を可能にします。
企業のGitHub／GitLabの使い方にはLevel 0〜Level 4の段階があり、学生時代に自分が上がってきた土俵の高さを、就職後も下げないでほしい、というのがこの記事の中心のメッセージです。技術面の深掘り（yaml例、5段階レベルの詳細、企業の使いこなしを見分ける方法、古い世代のスタックとの距離感など）は、番外編B8「GitHub／GitLabを高度に使いこなす、その深いレベルまで」（執筆予定）で扱います。
OSSへの小さな貢献としては、typo修正、翻訳、ドキュメント改善など、第三者の目利きが働く場所で実績を残す方法があります。過去のリポジトリと向き合い、READMEを整える、アーカイブ化する、Private化する、削除するといった整理も、プロフェッションとしての整え直しの一部です。企業側の視座としては、メルカリ、サイボウズ、カヤック、GMOペパボ、DeNAなど、多くの会社がGitHubを公式に評価対象にしています。
次のフェーズ2-6では、ハッカソンで、短距離の成果物を残すというお話に進みます。GitHubに積み上がっていく個人開発の中に、ハッカソンの成果物という強い1本を加えていく道です。
エンジニアの卵のみなさんへ、エール
GitHubは、確かに続けた人が勝つ場所です。派手な1つのプロダクトよりも、日常のコミットが積み上がっている軌跡のほうが、書類選考の担当者には強く伝わります。
正直に言うと、公開の場に自分のコードを置くのは、最初は誰にとっても怖いものです。「拙いコードを世界に晒すのが恥ずかしい」。その気持ちは、いまの学生さんにも、たぶん共通するのではないかと思います。ただ、25年近くこの業界を内側から見てきていま思うのは、未熟なうちから公開の場に立った人ほど、その後の育ちが速い、ということです。公開は、あなた一人の作業ではなく、世界のエンジニアたちとの対話の始まりです。
今週、なにか一つ、始めてみてください。GitHubアカウントを作り、プロフィールREADMEを1つ書く。既存のリポジトリの1つを、READMEを整えて公開してよい質に育て直す。使っている好きなOSSのドキュメントに、typo修正のPRを1つ送ってみる。どれか1つで、本記事の1歩目です。
一緒に歩きましょう。ボン・ボヤージュ。素敵な旅を。
次の記事はフェーズ2-6「ハッカソンで、短距離の成果物を残す。参加ではなく、束ねられる作品として残す」です。
#エンジニア就活 #新卒エンジニア #GitHub #OSS #プロフェッション #エンジニアの卵に贈る就活の書
