コードの品質と「自分で作った跡」を確認している

採用担当者が未経験者のGitHubを見るとき、完成された実務レベルのコードだけを見ているわけではありません。どこまで自分で考えて作ったか、どの部分で詰まり、どのように直したかが見えるかを確認します。ディレクトリ構成に意図があるか、エラー処理が書かれているか、変数名や関数名が読みやすいかといった点から、学習の深さが伝わります。

未経験・学習段階では、完成度よりも基礎の理解が見られます。動くものを作っただけで終わらず、なぜその書き方にしたのかをREADMEやコミット履歴で説明できる状態にすると、学習した内容が外から確認しやすくなります。採用側にとっては、入社後に学びながら伸びる人かどうかを判断する材料になります。

コントリビューション履歴で学習の継続性を見ている

GitHubのプロフィールページには、コミットやプルリクエスト、イシューの作成などの行動がカレンダー状に記録されます。この履歴は、未経験者の学習が一時的なものか、一定期間続いているものかを確認する材料になります。集中して作った日だけがある状態よりも、学習内容に合わせて更新が積み上がっている状態のほうが、継続して技術に向き合っている印象につながります。

ただし、毎日無理にコミットを作る必要はありません。学習内容が進んだとき、エラーを解決したとき、機能を追加したときに記録が残っていれば、十分に学習証跡として機能します。大切なのは更新回数そのものではなく、何を学び、どのように変えたかが履歴から読み取れることです。

READMEの有無が説明力の証明になる

リポジトリにREADMEがあるかどうか、あった場合にどの程度の内容が書かれているかも確認されます。READMEは、何を作ったかを自分の言葉で説明する場所です。未経験者の場合、コードだけを置いても、なぜその制作物を作ったのか、どこを学習したのかが伝わりにくくなります。

エンジニアの仕事では、実装した内容を他の人に説明する場面があります。READMEを丁寧に書ける人は、学習内容を整理し、相手に伝える力があると判断されやすくなります。コードだけが置いてあるリポジトリよりも、目的・使用技術・工夫した点が書かれているリポジトリのほうが、未経験段階の学習証跡として機能します。

コミットメッセージに何をしたかを残す

コミットメッセージは、変更内容を短く記録する場所です。「update」「fix」「test」のような一語だけのメッセージが続くと、何を学び、何を直したのかが外から分かりません。採用担当者が履歴を見たとき、メッセージの具体性が学習過程の理解しやすさにつながります。

記録の形式は複雑にする必要はありません。「ログイン画面の入力チェックを追加」「一覧ページの表示崩れを修正」のように、どの部分に何をしたかが一文で分かる形にします。英語でも日本語でも問題ありません。未経験・学習段階では、かっこよさよりも、変更内容が読み取れることを優先します。

学習の単位でコミットを区切る

学習中のリポジトリで起こりやすいのが、複数日の変更をまとめて一度にコミットする形です。この場合、どの段階で何を学んだかが見えにくくなります。学習証跡として見せる場合は、作業の区切りごとに履歴が残っているほうが、積み上げが伝わりやすくなります。

一つの機能を作り終えたとき、エラーを解決して動くようになったとき、参考にした内容を自分のコードとして書き直したときなどが区切りになります。一日の終わりに、その日に進めた内容を一度コミットとして残すだけでも、学習の流れが見える状態になります。

業務コードや教材の丸写しを公開しない

現職や過去の職場で扱ったコードをそのままGitHubに公開することは、情報管理の観点から問題になる場合があります。企業の機密情報や顧客データに関わるコードが含まれていると、採用側からセキュリティ意識に不安を持たれる可能性があります。

また、教材やチュートリアルをそのまま写しただけのリポジトリも、学習証跡としては伝わりにくくなります。教材を使う場合でも、画面構成を変える、機能を追加する、READMEに自分が理解した内容を書くなど、自分で考えた部分を残します。この違いが、未経験者の学習の深さを示す材料になります。

採用担当者が最初に知りたい情報を先に書く

READMEを読む採用担当者が最初に知りたいのは、このリポジトリが何のためのものかという点です。プロジェクトの概要、使用技術、何を学ぶために作ったか、この三点が最初の段落に入っていると、全体を理解しやすくなります。

インストール手順やセットアップの説明は大切ですが、それより前に何を作ったかを一文で説明すると、読み手の理解負担が下がります。技術スタックの一覧は見やすくまとめ、なぜその技術を使ったかを一言添えると、単なる学習記録ではなく、自分で選んだ理由がある制作物として伝わります。

技術選定の理由を簡潔に添える

「ReactとNode.jsを使用しました」という記載だけでは、技術名の一覧で終わりやすくなります。「画面を部品ごとに分けて作る練習としてReactを使いました」のように、選んだ理由を一行加えると、学習目的が見えます。未経験者の場合、何を知っているかだけでなく、なぜその技術を学んだかも評価材料になります。

ディレクトリ構成を示す場合も、なぜその構成にしたかをREADMEの中で簡潔に説明します。チュートリアルをそのまま実装したものと、自分で考えて構成を変えたものの違いが伝わりやすくなります。読み手がコードを開く前に、制作物の狙いを理解できる状態を作ります。

書きすぎない・完璧を目指しすぎない

READMEを丁寧にしようとして、長い説明を用意することに時間をかけすぎると、肝心の実装や学習が進みにくくなります。採用担当者がREADMEを読む時間は限られているため、一目で概要が分かる構成になっているかが重要になります。

完成度よりも、プロジェクトの目的・使用技術・動かし方・工夫した点が揃っているかを確認します。デモ画像や画面キャプチャがあると動作を理解しやすくなりますが、テキストだけでも基本情報が揃っていれば十分に機能します。読み手が知りたい順番で情報を置くことが、READMEの整え方の中心です。

個人情報・機密情報の混入を確認する

READMEやコードの中に、APIキー、パスワード、個人情報、勤務先の社名、教材の有料部分などが含まれていないか確認します。公開リポジトリに一度アップロードした情報は、削除してもコミット履歴に残る場合があります。

環境変数の管理には.envファイルを使い、.gitignoreに記載して追跡対象から外します。この管理ができているかどうかは、未経験者であっても実務を意識しているかの判断材料になります。コードの内容だけでなく、公開する情報の扱い方も学習証跡の一部として見られます。

見せるリポジトリと学習メモ用リポジトリを分ける

GitHubには、完成度の異なるリポジトリが混在しがちです。採用担当者がプロフィールページを訪れたとき、どのリポジトリを見ればよいかが分かりにくい状態では、学習内容が伝わりにくくなります。応募時に見せるリポジトリと、学習メモに近いリポジトリを分けると、プロフィール全体の印象が整います。

GitHubには、リポジトリをプロフィールページにピン留めする機能があります。代表として見せたいものをここに設定すると、訪問者が最初に目にする制作物を選べます。目指す職種に合ったリポジトリをピン留めすると、未経験からどの方向に学習しているかが伝わりやすくなります。

プロフィールのbioに志望領域と学習中の技術を明記する

GitHubのプロフィールには、bioと呼ばれる短い自己紹介欄があります。「フロントエンドエンジニア志望」「React・Next.js・TypeScriptを学習中」といった形で、目指している方向と扱っている技術を書いておくと、リポジトリを見る前に文脈が伝わります。

技術の一覧を多く並べるより、今注力している領域を絞って書くほうが、未経験者の学習方針として伝わりやすくなります。何でも学んでいるように見える状態よりも、目指す職種と制作物がつながっている状態のほうが、採用担当者が評価しやすくなります。

プロフィールREADMEで全体像を見せる

GitHubには、自分のユーザー名と同名のリポジトリを作成すると、プロフィールページにREADMEが表示される機能があります。ここに自己紹介、学習中の技術、取り組んでいるプロジェクトの概要を記載すると、プロフィール全体の案内として機能します。

長文にする必要はありません。現在取り組んでいること、代表リポジトリへのリンク、学習している技術が入っていれば、訪問者は全体像をつかみやすくなります。定期的に更新できる場合は学習の進捗を反映させると、継続して動いている状態が伝わります。

技術記事との連携で学習の思考過程を見せる

QiitaやZennといった技術情報プラットフォームへの投稿と、GitHubリポジトリを相互にリンクすると、コードだけでは伝わりにくい学習の思考過程が見えやすくなります。この実装で詰まったこと、調べたこと、解決したことを記事として残すと、学習の中身が外から確認できます。

記事の本数を増やすことより、GitHubのリポジトリとつながりのある内容になっているかが重要です。一つの制作物を作りながら、詰まった箇所を記事に残すと、コードと文章の両方で学習の流れを示せます。未経験者にとっては、完成物だけでなく、理解して進めた過程を伝える材料になります。

職務経歴書でGitHubの内容を言語化する

GitHubに何があるかよりも、それを職務経歴書でどう説明するかのほうが、採用担当者への伝わり方に影響します。GitHubのURLを記載するだけでは、リポジトリの内容が評価につながりにくい場合があります。自己PR欄や学習内容の欄に、GitHubで取り組んでいるプロジェクトの概要・使用技術・取り組んだ理由を短く記載します。

例えば、「Reactを使ったToDoアプリをGitHubで公開しています。ユーザー認証機能の実装に取り組み、入力チェックとエラー表示の改善を重ねています」という一段落があると、GitHubのURLが単なるリンクではなく、確認する価値のある情報として機能します。

自分のGitHubがどの段階にあるかを確認する

GitHubの整え方は、未経験からの就職・転職活動のどの段階にいるかによって優先順位が変わります。応募前の段階では、見せるリポジトリを選び、READMEとプロフィールを整えることが中心になります。面接に進んだ後は、GitHubのリポジトリを面接で話す材料として使えるかどうかが重要になります。

GitHubを整えること自体が目的になると、学習や応募準備が止まりやすくなります。書類で見せるためなのか、面接で説明するためなのか、学習の整理として使うのかを分けると、今直す場所が明確になります。