学習証跡として見せるGitHubの役割

採用側が確認できるのは完成物だけではない

GitHubには、現在のコードだけでなく、変更の履歴、作業単位、説明文、公開した時期が残ります。完成した画面だけを提示するポートフォリオとは異なり、途中の修正や考え直した跡まで確認できる点が特徴です。未経験者の場合、実務経験の代わりになるものではありませんが、学習内容を自分の手で扱った証拠として使えます。

評価につながりやすいのは、難しい技術を並べた作品より、目的と実装が一致し、コードを読んだ人が変更理由を追える作品です。小規模でも、入力値の扱い、例外時の表示、データ保存、テストなどが説明されていると、基礎をどこまで理解しているかが伝わります。

プロフィールは作品への案内板として使う

公式仕様では、プロフィールに代表的なリポジトリを最大6件まで掲載できます。応募時に見てほしい作品を上段へ置き、志望職種と関係の薄い練習用リポジトリは前面に出さない構成にすると、採用側が迷いにくくなります。プロフィールREADMEには、学習中の技術、目指す職種、代表作品へのリンクを短く載せます。

プロフィールの情報量を増やしすぎると、どの作品が主役なのか分かりにくくなります。使用できる技術を広く並べるより、応募先で使う技術と、作品で確認できる技術を対応させるほうが説明として強くなります。作品名の横に「何を確かめるための制作か」を一文添えると、見る順番が伝わります。

草の多さより履歴の中身を見る

プロフィールには過去1年の活動が表示されますが、色の濃さだけで学習の深さは決まりません。空の変更や意味の薄い更新を毎日積むと、履歴を開いたときに内容とのずれが生まれます。機能追加、修正、テスト追加、説明文の更新など、実際に進んだ単位で記録を残すほうが、学習の流れを示せます。

活動が表示されない場合は、コミットに使ったメールアドレスがアカウントと結びついているかも確認します。表示上の草を増やす作業より、作品の課題を一つずつ直し、その理由を残す作業を優先すると、面接で話せる材料も同時に増えます。

見せるリポジトリを選ぶ基準

志望職種と作品の役割を対応させる

Web開発を目指す場合は、画面だけでなく、データの受け渡し、認証、入力確認、エラー時の動きなどが確認できる作品が候補になります。インフラやクラウドを目指す場合は、構成図、設定ファイル、構築手順、監視や障害時の対応記録が主な材料になります。職種によって、コード量より説明資料の価値が高い場合もあります。

複数の作品があるときは、技術の種類が多いものではなく、自分が説明できる範囲が広いものを優先します。教材の指示どおりに作った部分と、自分で追加した部分を分けて話せる作品なら、学習の出発点と現在地の差を示しやすくなります。

教材の写経から自分の制作へ移す

教材どおりのコードは、基礎操作を学んだ記録にはなりますが、そのままでは自分で考えた範囲が伝わりにくいものです。画面項目を変える、検索条件を追加する、データ構造を変える、エラー表示を加えるなど、元の教材にはない変更を入れ、その理由をREADMEへ書くと、自分の判断が残ります。

変更量を大きくすることが目的ではありません。小さな追加でも、利用者が困る場面を想定し、どの処理を変えたか説明できれば学習証跡として機能します。参考にした教材や外部コードがある場合は、出典や利用条件も書き分けます。

未完成の作品は公開目的を明記する

制作途中のリポジトリを公開する場合は、完成済みの機能、未対応の機能、現在起きている不具合をREADMEへ分けて記載します。何も説明がない未完成作品は、放置されたのか、作業中なのか判別できません。進行中であることと、次に直す内容が書かれていれば、現在の学習対象を示せます。

応募時に主役として見せる作品は、起動手順が確認でき、主要機能が動く状態が望まれます。途中作品は補足資料として扱い、代表作品と同じ位置に並べないほうが伝わりやすくなります。

コミット履歴で学習の進み方を伝える

一つの変更理由ごとに記録を分ける

画面修正、データ処理、テスト追加、説明文の変更を一度にまとめると、履歴から何を直したか読み取りにくくなります。一つの目的に沿う変更をまとめて記録すると、後から差分を開いたときに意図が伝わります。作業量が小さくても、変更理由が異なる場合は記録を分けます。

例えば、ログイン失敗時の表示を直した変更と、READMEへ起動手順を追加した変更は別に扱います。面接で作品を説明するときも、履歴を追いながら「どの課題をどう直したか」を話しやすくなります。

メッセージは変更内容が分かる一文にする

「update」「fix」だけでは、履歴一覧から変更場所と目的を判断できません。「検索結果が0件のときの表示を追加」「入力値を保存前に確認」など、対象と変更内容を一文で書きます。英語か日本語かより、本人と他者が同じ意味で読めることが大切です。

大きな変更では、一行目に概要を書き、本文へ理由や影響範囲を加える方法も使えます。公式のGit仕様でも、短い要約と詳しい説明を分ける書き方が案内されています。すべての記録を長文にせず、説明が必要な変更だけ補足します。

失敗した試行を残す範囲を決める

学習中は試行錯誤が多くなりますが、動かない状態を細かく公開し続けるだけでは読み手の負担が増えます。原因を調べ、修正が完了した単位で記録し、READMEやIssueに「何が原因だったか」を短く残すと、問題解決の跡として読みやすくなります。

履歴を書き換えて見栄えだけを作るより、実際の変更順を保ちながら不要な生成物や個人情報を除くほうが安全です。公開前に履歴全体を見返し、機密情報や教材の有料部分が入っていないかも確認します。

READMEに書く内容と読みやすい順番

冒頭で作品の目的と対象者を伝える

READMEの冒頭には、何を作ったか、誰のどんな不便を想定したか、どの機能を確認できるかを書きます。技術名の一覧から始めると、作品が何のために存在するのか分かりにくくなります。採用側が数十秒で概要を把握できるよう、最初の段落だけで作品の役割が伝わる形にします。

公開URLや画面画像がある場合は冒頭付近へ置きます。ただし、ログイン情報や外部サービスの制限があるなら、その条件も添えます。動作確認ができない場合でも、画像と説明から主要な流れを追えるようにします。

技術名より選んだ理由を書く

使用言語やライブラリは一覧で示せますが、それだけでは理解の深さを判断しにくいものです。状態管理を分けた理由、データベースを選んだ理由、認証方法を変えた理由など、制作中に行った判断を短く加えると、技術をどのように使ったかが伝わります。

採用向けのREADMEでは、技術の説明書を書く必要はありません。作品固有の課題に対して、どの方法を選び、どの結果になったかを中心に書きます。うまくいかなかった方法と改善内容も、簡潔であれば評価材料になります。

起動手順と制約を他者が試せる形にする

ローカルで動かす作品は、必要な環境、導入コマンド、環境変数の用意、起動方法を順番に記載します。特定のOSだけで確認した場合や、外部APIの利用制限がある場合は、確認済みの条件も示します。読み手が途中で迷う箇所を減らすと、コードを確認してもらえる可能性が上がります。

環境変数の値そのものは公開せず、サンプルファイルに変数名だけを載せます。秘密情報をコードへ直接書かないこと、追跡対象から外すファイルを設定することは、制作物の安全管理を示す材料にもなります。

公開前の安全確認と応募書類への載せ方

秘密情報と個人情報を履歴まで確認する

APIキー、接続情報、パスワード、個人のメールアドレス、勤務先のデータは、現在のファイルから消しただけでは履歴に残る場合があります。公開前には現在のコードだけでなく過去の差分も見返します。秘密情報を見つけた場合は、値の無効化や再発行も含めて対応します。

公式機能には秘密情報の検知や送信時の保護がありますが、検知対象外の情報まで守れるわけではありません。環境変数と除外設定を使い、公開してよいデータだけで動くサンプルへ置き換えます。

第三者のコードと画像の扱いを明記する

教材、記事、生成AI、オープンソースのコードを利用した場合は、自分が書いた範囲と外部から得た範囲を分けます。ライセンス表示が求められるものは条件に従い、画像やアイコンも利用規約を確認します。外部利用を隠すより、どこを参考にして何を変更したかを説明するほうが信頼につながります。

企業の課題選考や現職のコードは、公開許可がない限り掲載しません。似た機能を見せたい場合は、架空データを使った別作品として作り、元の業務情報が推測できない内容にします。

応募書類には見る場所まで書く

職務経歴書へURLだけを載せると、採用側が何を確認すればよいか迷います。代表作品名、制作目的、自分が担当した範囲、見てほしい機能を数行で添えます。プロフィール全体ではなく、代表リポジトリへ直接リンクする方法も使えます。

面接前には、READMEの説明と実際のコードが一致しているかを確認します。質問されやすい技術選定、困った箇所、改善予定を手元にまとめておくと、作品を見せるだけで終わらず、学習の深さを会話で示せます。

まとめ