GitHubを、公開の場のハブとして育てる。作った成果物を束ねて、世界に見せる【フェーズ2-5｜ITエンジニアの卵に贈る、就活の書】

【お知らせ】本連載は、2026年9月20日に全記事を全面アップデートしました。

　この記事は本気でITエンジニアになりたい！ という学生さんたちに向けて就活プロセスを伝える「ITエンジニアの卵に贈る、就活の書」シリーズの一本です。シリーズ全体の目次はこちら（扉記事）からご覧いただけます。

　エンジニアを目指す学生のみなさん、こんにちは。クオリティアーツの池田です。

　ITエンジニアの卵に贈る、就活の書・フェーズ2-5の記事です。前回のフェーズ2-4では、技術書を血肉にする3拍子の話をしました。今回はフェーズ2「作る」の実践各論11本のうちの3本目、GitHubを、公開の場のハブとして育てるというお話です。フェーズ2全体のハブ記事としての位置づけも兼ねます。

　GitHubは、学生時代のみなさんが最も長い時間、最も目立たない形で、しかし最も確かに、自分の軌跡を残せる場所です。授業も、卒業研究も、技術書の写経も、ハッカソンの成果物も、個人開発も。そのほとんどが、最終的にGitHubに集まっていきます。フェーズ2の各論はGitHubというハブに束ねられて、はじめて世界に見える形になる。ここでの積み上げが、就活の書類選考の1枚目に強く効いてきます。

　まだアカウントを持っていない人も、この記事の読者です。3章の最初に、ゼロから始める手順を置きました。お金はかかりません。学年も関係ありません。

　この記事は、フェーズ2全体の「公開の場のハブ」として位置づけています。GitHubへの残し方は、この記事に集約しました。以降の各記事は、それぞれ固有の道具立てを主役に扱います。GitHubの育て方については、いつでもここに戻ってきてください。

この記事のポイント

• GitHubは、フェーズ2の各成果物を束ねて世界に見せるハブです。書類選考の提出物として公式に明示している会社があります。

• アカウントは無料で、今日作れます。学年は関係ありません。怖ければ、自分だけが見える状態から始めてかまいません。

• 育てる層は3つ。プロフィール、Publicリポジトリ、Contributionsとコミット履歴です。まず1本、READMEを添えて置くところから。

1. GitHubは、世界のエンジニアが集まる舞台

　GitHubは、単なるバージョン管理サービスではありません。世界のエンジニアが集まり、コードを共有し、学び、対話する舞台です。

　Linux（OSの中核）、React（Webの画面を作る道具）、PostgreSQL（データベース）。名前だけなら聞いたことがあるかもしれません。世界を支えるOSS（オープンソースソフトウェア。誰でもソースコードを読めて、改良に参加できるソフトウェア）の多くが、GitHub上で開発されています。世界のテックカンパニーも、重要な成果物の多くをGitHubで公開しました。

　学生時代のみなさんがGitHubにアカウントを持ち、そこに自分のポートフォリオを積み上げていく。それは、世界の本物のエンジニアたちと、同じ土俵に自分を乗せることでもあります。その入口が、GitHubのアカウントページから開いています。

　多くのIT企業が、書類選考や面接の前に、候補者のGitHubを検索します。株式会社メルカリの新卒書類選考では、ブログやGitHub、研究内容、作品などを添付するように公式に指示されています（出典：メルカリ公式採用サイト、2026年9月時点）。面白法人カヤックの「つくったもの選考」は、GitHubやポートフォリオサイトのURLだけで応募できる枠です。

　GitHubは、就活の書類選考の実質的な一部として、企業側にはっきり位置づけられています。

　なお、高専や大学の推薦で就職先が決まる人もいると思います。その場合、GitHubが書類選考で効く場面は、少ないかもしれません。それでも、入社してからの土俵の高さとして、ここでの積み上げは確かに効いてきます。その理由は、6章で扱います。

2. プロフェッションから見た GitHub の意味

　序章-1で、私はエンジニアという職業を、公衆の福利を担うプロフェッションとして位置づけました。IEEE-CS/ACMのソフトウェアエンジニア倫理綱領の第1原則は、公衆の福利を最優先することを求めています。

　GitHubに自分のコードを公開するという行為は、この視座から見ると、単なる自己アピールではありません。あなたの学びと工夫を、次に学ぶ誰かのために、世界に開いておくという行為です。あなたの拙い1年生のコードが、5年後にどこかの誰かの入口になっている、ということも起こり得ます。世界のOSSは、こうした無数の連鎖の上に成り立っています。

　GitHubを、日常の一部として育てる。これは、就活のためだけの話ではありません。専門職として生涯続く、公衆への貢献の1歩目でもあります。

3. GitHubを育てる3つの層

　GitHubの育て方には、3つの層があります。層が深くなるほど、就活の場面での重みも増していきます。

3-1. その前に。まだアカウントを持っていない人へ

　「GitHubのアカウントを持っていない」という人が、ここを読んでいると思います。大丈夫です。今日、作れます。

　先に、不安を3つ片付けておきます。

• お金はかかりません。個人がPublicリポジトリを置くのは無料です。それどころか、学生だと確認できれば、GitHub Student Developer Packで有料のツールも無償になります（フェーズ2-4の6章で扱いました）

• 英語のままでなくて大丈夫です。GitHubの画面は、設定を1か所変えれば日本語表示にできます

• 学年は関係ありません。大学1年でも、高専の5年でも、専門学校の2年でも、就活が目前でも、作った日から積み上がります。「もう遅い」ということはありません

　やることは、これだけです。

1. github.com を開いて、Sign up（登録）を押す

2. メールアドレスとパスワードと、アカウント名を決める

3. 届いたメールのコードを入力する

　メールアドレスは、学校のものでも個人のものでもかまいません。ただし、卒業すると学校のアドレスは使えなくなります。長く使うなら、個人のアドレスにしておくと安心です。

3-1-1. 手元のコードを、GitHubに置く

　ここが、いちばん最初の壁です。自分のパソコンのフォルダにあるコードを、どうやってGitHubに持っていくのか。

　その前に、言葉を1つ。リポジトリとは、1つのプロジェクトの置き場のことです。フォルダだと思ってかまいません。GitHubにコードを置くというのは、リポジトリを作って、そこにファイルを入れることです。

　置き方は、2つあります。

• 画面から置く：GitHubで新しいリポジトリを作り、ファイルをドラッグして置く。コマンドを1つも打たずに済みます

• コマンドで置く：授業で習った「git commit」と「git push」が、これです。自分のフォルダをGitHubにつなぐ設定を一度すれば、あとはコマンドで上げ下ろしできます

　最初の1本は、画面から置くで構いません。動く実感を先に取ってください。コマンドは、2本目以降に覚えれば間に合います。

3-1-2. 怖かったら、Privateから始めていい

　「下手なコードを世界に見せるのが怖い」。これは、当たり前の気持ちです。

　リポジトリは、Private（自分だけが見られる状態）でも作れます。まずPrivateで作って、操作に慣れて、「これなら見せてもいいかな」と思えたときにPublic（誰でも見られる状態）に切り替える。この順番で、まったく問題ありません。切り替えは、設定画面のボタン1つです。

　名前も、ハンドルネームで構いません。本名だと検索で見つけてもらいやすい、という利点はありますが、就活で自分からURLを伝えるなら、ハンドルネームでも何も困りません。

　1つだけ、先に知っておいてください。コミットには、設定したメールアドレスが記録され、公開されます。個人のアドレスを出したくない場合は、GitHubが用意している非公開用のアドレスを使う設定があります。アカウントを作ったら、最初に確認しておくと安心です。

　なお、実機がないと動かないものを作っている方（組込み、制御、ロボット、計測）は、GitHubにコードを置くだけでは、読む側が動かせません。動画・配線図・構成の説明をセットにする方法を、フェーズ2-2の2-1-1に書きました。この記事の3つの層は、それを前提にしたうえで、そのまま使えます。

3-2. 層1：アカウントとプロフィール

　アカウントができたら、プロフィールを整えます。ここは30分で終わります。

• 一貫したアカウント名：本名でもハンドルネームでもかまいません。Zenn、Qiita、Speaker Deck、Xなど、他にアカウントを持っているなら名前を揃えておくと、同じ人だと分かってもらえます

• プロフィール文：自分の関心事、志望する技術ドメイン、いま学んでいることを、3〜5行で

• プロフィールREADME：READMEとは、リポジトリの説明を書くファイルのことです。自分のアカウント名と同じ名前のリポジトリを作ると、その中のREADMEがアカウントページのトップに表示されます。使っている言語、作ったものへのリンク、技術ブログのURLを置く場所です

• アイコン：顔写真でなくてもよい。同じアイコンを他のプラットフォームでも使う

　これだけで、あなたの名前を検索した企業の担当者は、GitHubのアカウントページから、あなたの全体像を1枚で受け取れるようになります。

3-3. 層2：Public リポジトリ

　次に、Public リポジトリを育てていきます。ここが、GitHub 育成の中心です。

　Public リポジトリには、次のような種類のものが置かれます。

• 個人開発のプロダクト

• 授業や卒業研究の実装（フェーズ2-3で扱った演習や、卒業研究の実装）

• 技術書を読んで作ったコード（フェーズ2-4で扱った写経、スクラッチ実装、アレンジ）

• ハッカソンの成果物（フェーズ2-6で扱う）

• 技術ブログの記事に対応するコード（記事から辿れるように）

• OSSに修正を送ったときの、自分の手元のコピー（7章で扱います）

• 自分の開発環境の設定ファイル（同じ環境を作り直せる形で公開する文化があります）

　数の話をする前に、大事なことを1つ。まず1本です。0本の状態から、いきなり10本にはなりません。今日1本、READMEを添えて置く。そこが全部の出発点です。

　そのうえで目安を挙げるなら、丁寧なREADMEと動く実装が揃ったものが5本あれば、書類選考でも面接でも十分に語れます。これは、私が会ってきた学生さんのうち、話が深くなった人の手元にあった数です。残りは、練習や実験の置き場として増えていけば十分です。

　数を稼ぐことよりも、1本の質のほうが、はるかに大事です。フェーズ2-2で扱った公開の3条件（公開されている、意図が追える、公開してよい質）を、まず1本で満たしてください。

3-4. 層2.5：テストコードは、リポジトリの「もう1つの顔」

　Public リポジトリを見る側は、実装コードだけでなく、テストコード（そのコードが正しく動くかを自動で確かめるためのコード）にも目を向けます。READMEにテストの実行方法が書かれているか。テスト用のフォルダに、一定量のテストがあるか。これらは、「動くコードを書いた」だけでなく「動くことを自分で確かめ続けている」という証拠になります。

　テストの厚みには、テストピラミッドという考え方があります。土台に、部品ひとつひとつを確かめる単体テストを数多く。その上に、部品を組み合わせて確かめる結合テストを。頂点に、実際の画面操作を通して確かめるテストを少しだけ。この比率で積む、という考え方です。

　すべてのリポジトリでピラミッドを完璧に作る必要はありません。ただ、まず単体テストから積むという順番を知っておくと、個人開発でテストを書き始めるときの迷いが減ります。

3-4-1. テストを、自動で回す

　テストコードを書くだけでも十分な一歩です。そこにGitHub Actions（コードを更新するたびに、決めた作業を自動で実行してくれる仕組み）を1つ加えると、リポジトリの見え方が一段変わります。

　コードを更新するたびにテストが自動で走り、その結果が緑か赤で表示される。テストが緑で通り続けている状態を、実行の履歴が証拠として残す。これは、実装コードとは別の、地味だけれど強い評価軸です。

　設定そのものは、10行ほどの短い設定ファイルで書けます。書き方は公式ドキュメントとサンプルが充実しているので、そちらを頼ってください。ここで押さえてほしいのは、テストと自動実行の組み合わせが、GitHubの見え方を変える、という1点だけです。

3-5. 層3：Contributionsとコミット履歴

　3つ目の層が、Contributionsグラフとコミット履歴です。GitHubのプロフィールページには、日々の活動を緑色のマスで示す Contributions グラフがあります。

　このグラフには、あなたの日常性が表れます。毎日1コミットしなくてもいいのですが、週に何日か、月に何度か、緑のマスが灯っている状態が続いているかどうかは、書類選考の担当者に、あなたの学びの継続性を伝えます。

　同時に、コミットのメッセージも見られています。メッセージが「fix」「update」ばかりのリポジトリと、何を、なぜ変えたかが1行で伝わるリポジトリでは、書類選考での重みが違います。

　今日から変えられる習慣です。授業の課題でも、「バグ修正」ではなく「入力が空のときに落ちる問題を修正」と書く。それだけで違います。コミット1つ1つに意図が滲む形で書く習慣は、社会人になってからも実務で重宝します。

4. GitHubを育てる、世界基準の道具

　GitHubを日常の一部として、そしてフェーズ2の公開の場のハブとして育てるとき、周辺の道具立ても、世界基準のものに揃えていくと、成果物の強度が上がります。

　先に言っておきます。全部を知る必要も、全部を使う必要もありません。そういう種類の道具があると知っておくだけで十分です。

• エディタ：コードを書くための道具。VS Code が定番です

• AIコーディングアシスタント：エディタの中でコードの補完や相談ができる道具

• テスト：言語ごとに、標準的なテストの道具があります

• 自動実行（CI/CD）：GitHub Actions。テスト、ビルド、公開までを自動で回します

• 依存関係の管理：使っているライブラリが古くなったら、自動で更新を提案してくれる道具

• セキュリティ検査：コードの中の危なそうな書き方を、自動で指摘してくれる道具

• プレビュー公開：コードを更新するたびに、動く状態のWebページを自動で用意してくれる仕組み

• Issue と Project：やることや困りごとを、リポジトリの中で管理する機能

　これらは、世界のテックカンパニーが日常的に使っている道具立てです。学生時代のうちに、このうち1つを自分のリポジトリで動かしてみる。それだけで、書類選考でも面接でも、話せることが1つ増えます。

　最初の1つに選ぶなら、テストの自動実行です。動くコードと、動くことを確かめるコードの両方を持っている証拠になります。READMEに貼られた小さなバッジ1つが、控えめな見た目のわりに、確かな配慮として伝わります。

　なお、ここに挙げた道具の多くは、個人利用なら無料か、無料で使える範囲があります。有料のものも、GitHub Student Developer Packで在学中は無償になるものが少なくありません（2026年9月時点）。在学中に、使い倒してください。

5. 世界基準のスタックで、共通言語を持つ

　GitHubに置くコードのスタック（言語・フレームワーク・実行環境の組み合わせのこと）にも、少しだけ気を配ってほしいところがあります。

　世界のテックカンパニーで日常的に使われているスタックで組まれたリポジトリは、書類選考でも面接でも、共通言語で会話が始められます。志望する領域に合う組み合わせを1つ選び、Publicリポジトリで一定量のコードを書いておく。それだけで、書類の1枚目の伝わり方が変わります。

　志望する領域でいま何が使われているかは、求人の募集要項を何社か読めば見えてきます。逆に、募集要項に並ぶ道具立てが一世代前のものばかりなら、それも応募先を眺めるときの手がかりになります。

　1点だけ、はっきりさせておきます。古い道具立ての保守そのものは、社会インフラを支える大切な仕事で、批判の対象ではありません。ここで問いたいのは、「その会社が、新しい道具に若手を触れさせる機会を、日常的に提供しているかどうか」の1点だけです。この問いは、フェーズ3からフェーズ4の企業リサーチと面接の対話の中で、じっくり確かめていくことになります。

6. 学生時代からGitHubに乗せることは、本物のエンジニアと同じ土俵に上がること

　ここで、就活の本質に関わる話を1つ書きます。

　GitHub（そして同じ位置づけを持つGitLab）は、単なるバージョン管理ツールではありません。世界基準の開発現場では、開発・レビュー・自動テスト・自動デプロイ・運用・チーム対話・知識共有・OSS貢献のすべてが交差するハブとして使われます。

　この使いこなしの深さには、段階があります。私は、応募先を眺めるための物差しとして、5段階に整理しています。一般に決まった定義があるわけではなく、私が現場を見てきて作った物差しです。

• Level 0：そもそもGitを業務で使っていない。一世代前の道具や、ZIPファイルのやり取りが中心

• Level 1：GitHubやGitLabを導入しているが、ただのファイル置き場としてしか使えていない。Pull Request（変更を提案してレビューを受ける仕組み）も自動実行も、実質的に動いていない

• Level 2：Pull Request中心の進め方が回っている。ここが世界標準の入口

• Level 3：テスト・ビルド・公開の自動実行が回り、開発と運用の中核として機能している

• Level 4：課題管理、知識共有、依存関係の自動更新、社員のOSS貢献支援まで含め、仕事の中核として使いこなしている

　ここでは、就活の観点からいちばん大切な1点だけをお伝えします。

　それは、学生時代に自分のポートフォリオをGitHubに乗せることは、Level 3から4の会社の現役エンジニアと、同じ土俵に自分を乗せることだ、という1点です。

　あなたが自動テストの設定を1つ書き、Pull Requestを出して、テストを緑にした瞬間。あなたの手つきは、世界のテックカンパニーのエンジニアの手つきと、道具立てとしては同じものになります。拙くても、道具立てが同じなら、土俵は同じです。

　世界中のエンジニアが集うのと同じ場所に、あなたの名前と成果物が並ぶ。これが、学生時代からGitHubに乗せることの本当の意味です。

　この「同じ土俵」の視点は、就活で2つの方向に効いてきます。

　1つは、書類選考の場で、あなた自身の土俵の高さが伝わること。Publicリポジトリの中身、READMEの丁寧さ、自動テストの有無、Contributionsグラフの日常性。ここから、書類選考の担当者は、あなたがどの段階の土俵で日常を作ってきたかを読み取ります。

　新卒でLevel 4まで到達している必要は、まったくありません。Level 2に一歩入っているだけで、私の実感では十分に目立ちます。

　もう1つは、企業を選ぶ側の物差しになること。学生時代にLevel 3の土俵で日常を作ってきた人が、Level 1の職場に入ると、入社1日目から土俵が下がります。学生時代に身につけた道具立ての多くが業務では使えず、日常のリズムも変わる。この差が1〜3年目の伸び方に出てくる、というのが私の実感です。

　あなたの学生時代の土俵の高さを、就職後も下げないでほしい。

　先ほど触れた推薦就職の話も、ここにつながります。選考でGitHubを見られなくても、入った先がどの段階の土俵かは、あなたのこれからに効きます。推薦の面談でも、下に挙げる問いは同じように使えます。

　応募前に、志望する企業の名前でGitHubを検索し、公開しているリポジトリの活気を眺めてみてください。そして面談の場で、「開発はPull Request中心ですか」「テストの自動実行は何を使っていますか」と聞いてみる。この2つだけで、その会社の土俵の高さの手がかりが取れます。この確かめ方は、フェーズ3-6でも扱います。

7. OSSへのコントリビューションで、第三者の目利きを通す

　GitHubを育てる中で、多くの学生さんが「難しそう」と感じるのが、OSSへの貢献です。誰かが公開しているソフトウェアを、直したり足したりして、本家に取り込んでもらうことを指します。

　取り込まれると、そのプロジェクトの貢献者一覧や更新履歴に、あなたの名前が残ります。自分で公開した作品とは重みの違う、第三者が目を通した実績です。

　最初の1歩として、次のような小さな貢献から始められます。

• 説明書の誤字修正、日本語訳の改善：多くのOSSは、説明書の改善を歓迎しています。コードを1行も書かずに始められます

• エラーメッセージの改善提案：自分がハマった場所を、次の人のために直す

• 使い方のサンプルを1つ足す：説明書の最初の例を、分かりやすくする

• 日本語訳への参加：有名なライブラリの日本語ドキュメントは、有志の翻訳で成り立っています

• 小さなバグの報告と修正：使っていて気づいた不具合を報告し、直せそうなら直して送る

　いきなり有名な大きいプロジェクトに送る必要はありません。自分が実際に使っていて、ありがたいと思っている小さめのOSSに、一手間を返す。この規模から始めると、無理なく続けられます。

　企業側も、ここを見ています。GMOペパボ株式会社は、OSSへの貢献または開発経験を、新卒エンジニア選考の加点要素として公式に挙げています（出典：GMOペパボ新卒採用サイト、2026年9月時点）。

8. 過去のリポジトリと向き合う

　GitHubを育て始めるとき、多くの学生さんが直面するのが、「過去のリポジトリが恥ずかしい」という気持ちです。始めたばかりの頃に作った拙いコード、READMEのないリポジトリ、動かない実験、他人の手順をなぞったまま放置されたもの。目を逸らしたくなる瞬間があります。

　説明のないまま放置されたリポジトリは、置いておくよりも、整えたほうがいい。ただし、消す必要はありません。選択肢は4つあります。

• READMEを整えて、成長の過程として位置づけ直す：1年生のときの実装、として明示すれば、それは軌跡になる

• アーカイブ状態にする：GitHubのArchiveは、リポジトリを読み取り専用にする機能。「過去の作品として、いまはメンテしていない」という意志表示

• プライベート化する：見せたくないものは、Private に移す（削除するより、履歴を残せる）

• 削除する：本当に見せたくないものは、削除も選択肢

　過去の作品と正直に向き合い、いまの自分にとって公開してよい形に整える。この作業自体が、専門職としての整え直しです。そして、4つのうちどれを選んでも構いません。大事なのは、放置しないことだけです。

9. GitHubの文化を持つ会社は、日常の道具立てからそれが見える

　ここで、会社の側に目を向けます。GitHubを、日常の道具としてどう使っているか。

　学び続ける環境を持つ会社は、社内でGitHubを実務の道具として使いこなし、社員がOSSに貢献する文化を持っていることが多いと感じます。Pull Request中心の開発の進め方、コードレビューの文化、社員のOSS活動への公式な支援、社内で作ったものを外部に公開する取り組み。

　実例を1つ挙げます。株式会社ディー・エヌ・エー（DeNA）です。社内でのGitHubの運用、社員のOSS活動への支援、技術カンファレンスを通じた発信を、公式に打ち出しています（出典：DeNA新卒採用サイト、2026年9月時点）。

　ここで一つ、募集要項の「GitHubアカウント歓迎」の1行には、注意が要ります。歓迎すると書くのはタダです。本当に見ているなら、選考のどこかで、みなさんが出したURLの中身が話題になります。最後まで一度も触れられなかったなら、その1行は、応募のハードルを下げるために置かれていたということです。

　あわせて、コードレビューの文化にも注目してほしいところです。設計の是非、テストの抜け、名前の付け方まで踏み込んでレビューが回っている会社は、コードを一人の作業ではなくチームの共有物として扱っています。

　逆に、レビューが承認ボタンを押すだけの儀式になっている会社では、コードの質は、書いた個人の技量だけで決まります。うまくいけば個人の手柄、まずければ個人の責任。仕組みで受け止めていないから、そうなります。若手が育つ環境としては、いちばん薄い形です。

　面談の場では、「コードレビューでは、どんな指摘が多いですか」と聞いてみてください。答え方は、会社ごとに大きく違います。具体的な例がすぐ出てくる会社と、言葉に詰まる会社があります。

　変化の途上にある会社の姿も、それはそれで信頼できる兆候です。「長年別の道具を使ってきたが、いまGitへの移行を進めている」。「Pull Requestは新人研修から扱っている」。「古い案件は残っているが、新規案件は新しい組み合わせで作っている」。こうした発言は、その会社が現状に留まらず、変化と付き合う姿勢を持っていることを示します。いまの姿だけでなく、その会社の変化の向きも一緒に読み取ってほしいと思います。

まとめ

　本記事では、GitHubを公開の場のハブとして育てる話をしました。要点は次のとおりです。

　アカウントを持っていないなら、今日作れます。無料で、日本語表示にできて、学年は関係ありません。怖ければPrivateから始めて、見せてもいいと思えたときにPublicに切り替えれば十分です。最初の1本は、画面からファイルを置くだけで構いません。

　育てる層は3つ。アカウントとプロフィール、Publicリポジトリ、Contributionsとコミット履歴です。まず1本、READMEを添えて置く。丁寧なものが5本あれば、書類選考でも面接でも十分に語れます。テストと、その自動実行を組み合わせると、リポジトリの見え方は一段変わります。

　企業のGitHubの使い方には、私の物差しで5段階あります。学生時代にPull Requestと自動テストの土俵で日常を作ってきた人が、ファイル置き場としてしか使わない職場に入ると、入社1日目から土俵が下がります。あなたの学生時代の土俵の高さを、就職後も下げないでほしい。これが、この記事の中心のメッセージです。

　次のフェーズ2-6では、ハッカソンで、短距離の成果物を残すというお話に進みます。GitHubに積み上がっていく個人開発の中に、ハッカソンの成果物という強い1本を加えていく道です。

エンジニアの卵のみなさんへ、エール

　GitHubは、続けた人に返ってくる場所です。派手な1つの作品よりも、日常のコミットが積み上がっている軌跡のほうが、書類選考の担当者には強く伝わります。

　公開の場に自分のコードを置くのは、最初は誰にとっても怖いものです。「拙いコードを世界に晒すのが恥ずかしい」。その気持ちは、よく分かります。

　だから、怖いうちはPrivateでいい。手を動かすことと、公開することを、同時にやらなくて構いません。慣れてから、1本だけ公開する。その1本が動いたら、2本目はもっと楽になります。

　そのうえで、一つだけ。公開したコードを笑う人は、この場所にはほとんどいません。GitHubにいるのは、自分も昔は同じものを書いていた人たちです。むしろ、誰にも見られていないコードは、いつまでも直る機会がありません。怖さの正体は、見られることではなく、直される前の自分を見られることのほうです。そして、直される前の自分は、置いてみないと直りません。

　今週、なにか一つ、始めてみてください。GitHubのアカウントを作る。それだけでいい。もう持っているなら、手元のフォルダにあるコードを、1本だけ置いてみる。Privateで構いません。すでに何本かあるなら、そのうち1本のREADMEを整え直す。OSSの説明書の誤字を1つ直して送ってみる。どれか1つで、本記事の1歩目です。

　アカウントを作るところからでも、まったく遅くありません。

　一緒に歩きましょう。ボン・ボヤージュ。素敵な旅を。

次の記事は、フェーズ2-6「ハッカソンで、短距離の成果物を残す。参加した、で終わらせない」です。

この連載を読むにあたって

　事実の確認について。 法令・統計・制度の記述は、一次情報にあたって確認し、出典のリンクを各記事の末尾に置いています。それでも、誤りが混じっている可能性は、ゼロではありません。数字と法令は、リンク先の原典で確かめてから使ってください。確かめる手間ごと、この連載がお渡ししたいものです。

　調査の時点について。 記事中の法令・統計・制度は、2026年9月15日時点で確認したものです。法令は改正され、統計は毎年更新されます。読んでいる時点との差は、ご自身で埋めてください。

　生成AIの利用について。 この連載は、調査と推敲に生成AIを使っています。

　最後は、ご自身で判断してください。 就職活動は、みなさんの人生の大きな選択です。この連載がお渡しするのは、判断の物差しであって、判断そのものではありません。物差しを当てるのは、みなさん自身です。

　そして、一人で抱えないでください。 相談先があります。大学のキャリアセンター。新卒応援ハローワークは全国56か所にあり、すべて無料で、専任の就職支援ナビゲーターが担当者制でついてくれます。労働条件のことは、総合労働相談コーナー（都道府県労働局や労働基準監督署などに全国378か所）でも相談できます。

#エンジニア就活 #GitHub #OSS #リポジトリ #エンジニア志望 #技術広報 #エンジニアの卵に贈る就活の書

関連記事・参考文献等

本記事で挙げた、学生が使える情報源

• GitHub

• GitHub Student Developer Pack

• メルカリ 新卒採用サイト

シリーズ関連

• 新卒ITエンジニア 新卒研修シラバス

• 新卒エンジニア、観察ノートを開く（上巻）　観察を、始める

• 新卒エンジニア、観察ノートを開く（中巻）　両輪を、回す

• 新卒エンジニア、観察ノートを開く（下巻）　道を、選び取る