その気持ち、すごくよく分かります。GitHubが「エンジニアの履歴書」と言われるほど重要だからこそ、どうアピールすればいいのか悩みますよね。
でも、ご安心ください！採用担当者が見ているポイントは、実は決まっています。
この記事では、多くの採用担当者が見ているGitHubの評価ポイントを7つに絞って、具体的に解説していきます。
卒業生のGitHubを例に、実践的な視点でお伝えしますので、ぜひ最後まで読んであなたのポートフォリオを最強の武器に変えましょう！
▼動画でサクッと知りたい方はこちら▼
【未経験者必見】GitHubで見られる7つの評価ポイント
それでは早速、採用担当者がチェックしている7つのポイントを見ていきましょう！
今回参考にさせていただいた、RUNTEQ卒業生にアプリはこちら
清水さん作成「BUZZ BASE」
①草（Contribution Graph）
（ひさじゅ）
「草」とは、GitHubでの活動量を可視化したContribution Graphのこと。緑色の濃淡で、日々の活動量が示されます。
採用担当者がまずここを見る理由は、あなたの「学習の継続性」を知りたいからです 。
草が毎日生い茂っていれば、「この人はコツコツと学習を続けられる人だな」という好印象を与えられます。逆に、草がまばらで白い部分が目立つと、「学習意欲に波があるのかな？」「途中で挫折してしまうタイプかも…」と、継続力を疑われてしまう可能性があります 。
面接で「毎日学習しています！」とアピールしても、草が生えていなければ説得力がありません 。まさに、嘘がつけない「開発記録」なのです 。
濃い緑で埋め尽くすのが理想ですが、まずは薄い緑でもいいので、毎日続けることを意識しましょう 。「ぽっかり真っ白な期間」を作らないことが大切です。
- GitHubの「草」は、学習の継続性を示す重要な指標
- 採用担当者は、草を見て日々の学習習慣をチェックしている
- 真っ白な期間があると、学習意欲を疑われる可能性があるため、毎日少しでも活動することが大切
②READMEの記述内容
（ひさじゅ）
READMEは、そのリポジトリ（プロジェクト）の説明書です。
採用担当者はここを見て、「あなたが作ったものが何なのか」、そしてあなたに「ドキュメンテーション能力があるか」を判断します 。
自分が作ったアプリのことは、自分が一番よく分かっていますよね。だからこそ、説明が一人よがりになりがちです 。
初めて見る人にも内容が伝わるように、以下の情報を分かりやすく記載することが重要です。
- アプリの概要・URL: どんなアプリで、何ができるのか 。
- 開発背景: なぜこのアプリを作ろうと思ったのか、どんな課題を解決したかったのか 。
- 主な機能一覧: GIF動画などを使って、実際の動きを見せるとさらに分かりやすい 。
- 使用技術と選定理由: なぜその技術を選んだのかを説明する 。
- ER図やインフラ構成図: 設計スキルをアピールできる 。
特に、開発背景や技術の選定理由まで書かれていると、「この人は目的意識を持って開発ができるんだな」と高く評価されます。
READMEは、あなたの「伝える力」をアピールする絶好の機会です。チーム開発では、テキストで正確に情報を伝えるコミュニケーション能力が必須。
READMEを丁寧に書くことで、チーム開発への適性も示すことができるのです。
- READMEは、初めて見る人にもアプリの全体像が伝わるように書く
- 開発背景や技術選定理由を盛り込むことで、課題解決能力や論理的思考力をアピールできる
- 丁寧なREADMEは、円滑なコミュニケーション能力やチーム開発への適性を示す証になる
③開発フロー
（ひさじゅ）
「え、個人開発なのにissueやプルリクエストまで見るの？」と驚いた方もいるかもしれませんが、結構見られています！
採用担当者は、あなたが「チーム開発の進め方を理解しているか」を確認したいのです 。
実際の現場では、issueでタスクを管理し、プルリクエスト（プルリク）でコードレビューを依頼するのが一般的です 。たとえ一人での開発であっても、このフローを擬似的に実践することで、「この人は入社後もスムーズにチームに溶け込めそうだな」という印象を与えることができます 。
issueやプルリクの本文も重要です。「自分だけが分かればいいや」と適当に書くのはNG 。
「何をしたのか」「なぜそうしたのか」「レビューしてほしいポイントはどこか」など、第三者が見ても分かるように、丁寧に記述する習慣をつけましょう 。
issueとプルリクエストは、チーム開発における重要なコミュニケーションツール 。その書き方一つで、あなたの評価は大きく変わります。
- 個人開発でも、issueやプルリクエストを活用した開発フローを実践する
- issueやプルリクの本文は、第三者が見ても分かりやすいように丁寧に書く
- このフローを実践することで、チーム開発への適性をアピールできる
＼ 現場の開発フローが学べる！ ／
無料で話を聞いてみる ▶︎▶︎
④コードの可読性
（ひさじゅ）
いよいよ、コードの中身です。採用担当者は、すべてのコードを隅々まで読むわけではありません。しかし、主要なロジックなどを抜き打ちでチェックし、「読みやすいコードを書ける人か」を見ています 。
特に、以下のようなコードは避けるべきです。
- マジックナンバー: `find(1)` のように、意味の分からない数字を直接コードに書き込むのはNGです 。定数にするなど、誰が見ても意味が分かるようにしましょう 。
- linterを通していない汚いコード: RuboCopなどのlinter（コード整形ツール）を使っていない、インデントがバラバラなコードは「雑な仕事をする人」という印象を与えてしまいます 。
さらに、「テストコードを書いているか」も非常に重要な評価ポイントです 。現場ではテストコードを書くのが当たり前 。ポートフォリオでも、最低でもカバレッジ（テストの網羅率）50%程度は書いておくと、学習意欲の高さをアピールできます 。
「とりあえず動けばいい」ではなく、将来誰かがこのコードを読むことを意識して、綺麗にリファクタリングする習慣をつけましょう。
- 採用担当者は、コードの可読性を抜き打ちでチェックしている
- マジックナンバーや整形されていないコードは、マイナス評価に繋がる
- テストコードを書くことは必須。品質への意識の高さを示せる
⑤Gitのお作法
（ひさじゅ）
「Gitの作法」とは、コミット履歴やブランチの切り方などのことです 。こんな細かいところまで？と思うかもしれませんが、あなたの「仕事の丁寧さや性格まで見えてくる」とよく言われることがあります。
チェックされるのは主に以下の2点です。
- コミットの粒度とメッセージ: 大量のファイル修正を1つのコミットにまとめていませんか？ コミットは「1機能」「1タスク」など、意味のある単位でこまめに行うのが基本です 。そして、コミットメッセージには「何を変更したのか」が分かるように、適切な内容を記述しましょう 。
- ブランチ名の付け方: `feature/add-login-function` のように、何のためのブランチか一目で分かるような、適切な名前を付けているかも見られています 。
忘れていて一気にコミットしたりすると、「計画性のない人なのかな」と思われてしまうことも 。
日頃から丁寧なGitの操作を心がけることが、評価に繋がります。
- コミットは意味のある単位でこまめに行い、分かりやすいメッセージを付ける
- ブランチ名は、その作業内容が分かるように適切に命名する
- 丁寧なGitの使い方は、計画性や仕事の丁寧さのアピールになる
⑥使用技術やフレームワークの種類
（ひさじゅ）
READMEに記載する使用技術のセクションも、重要なアピールの場です。
採用担当者は、あなたが「どんな技術に興味を持ち、それをなぜ選んだのか、論理的に説明できるか」を見ています 。
「スクールで習ったから」「流行っているから」という理由だけでは、「自分の意見がない人なのかな」と思われてしまいます 。
なぜその言語やフレームワークを選んだのか。
「〇〇という機能を実現したかったから、××という特徴を持つこの技術が最適だと考えた」のように、自分の言葉で、その選択がベストである理由を語れることが重要です 。
また、スクールで習った技術だけでなく、少しチャレンジングな技術を取り入れていると、「探究心のある人だな」と評価が上がります。バージョンが古い技術を使っていないか、といった点もチェックされるので注意しましょう。
技術選定の理由は面接でもよく聞かれる質問です 。事前にREADMEにまとめておくことで、面接対策にもなりますね。
- 使用技術は、なぜそれを選んだのかという「選定理由」とセットで説明する
- 「流行っているから」ではなく、自分の実現したいことから逆算して論理的に語れることが重要
- 新しい技術に挑戦する姿勢は、学習意欲の高さとして評価される
⑦オリジナル作品の有無
（ひさじゅ）
最後の、そして最も重要なポイントが、「オリジナルの作品があるかどうか」です。
チュートリアルをなぞっただけの作品や、どこかの教材をコピーしただけのアプリでは、残念ながら評価されません。
エンジニアに最も求められるのは「課題解決能力」だからです 。
採用担当者は、あなたが「自ら課題を発見し、それを解決するための手段としてアプリケーションを企画・設計・実装できるか」を知りたいのです。
例えば、「自分自身の原体験から生まれた課題を、技術で解決する。」このようなストーリーのあるオリジナル作品は、他の誰にも真似できない、あなただけの強力なアピールになります 。
誰かの作ったものではなく、あなただからこそ作れるアプリケーションを、自信を持ってポートフォリオに掲げましょう。
- AIに仕事を奪われているのは「指示通りにコードを書くだけ」のプログラマー
- チュートリアルや模倣ではない、オリジナルの作品が必須
- エンジニアに求められる「課題解決能力」を示すことが最も重要
- 自分自身の課題感から企画・設計・実装した作品は、高く評価される
まとめ：GitHubはあなたを伝える最強の武器！自信の持てるポートフォリオを作ろう
未経験からエンジニアを目指す上で、採用担当者が見ているGitHubの7つのポイントをご紹介しました。
- 草（Contribution Graph）：学習の継続性
- READMEの記述内容：ドキュメンテーション能力
- 開発フロー：チーム開発への適性
- コードの可読性：綺麗なコードを書く意識
- Gitのお作法：仕事の丁寧さ
- 使用技術：技術への探求心と論理的思考力
- オリジナル作品の有無：課題解決能力
こうして見ると、GitHubは単なる成果物置き場ではなく、あなたのスキル、学習意欲、人柄、そしてポテンシャルまで伝えるための、最強のプレゼン資料だということがお分かりいただけたのではないでしょうか。
「自分のポートフォリオが、本当にこれで良いのか不安…」
そう感じた方もいるかもしれません。確かに、評価されるポートフォリオを独学で作り上げるのは、簡単なことではありません。
RUNTEQは、まさにそんなあなたのためのプログラミングスクールです。
私たちは、単にプログラミングを教えるだけでなく、今回ご紹介したような「採用担当者に見られること」を徹底的に意識したポートフォリオ作成を、現役エンジニアの講師がマンツーマンでサポートします。
もし今、「何から始めればいいか分からない」「自分のポートフォリオを一度見てほしい」と感じているなら、ぜひ一度RUNTEQの無料カウンセリングに参加してみてください✨
📍無料カウンセリングでできること
- あなたの状況に合わせたポートフォリオ戦略のご提案
- 転職市場のリアルな情報や、評価される技術について
- RUNTEQのカリキュラムやサポート体制の詳細説明
- 学習に関する不安や疑問点の解消
- 現役エンジニアでもあるキャリアアドバイザーへの質問
無理な勧誘は一切ありませんので、「ちょっと話を聞いてみたい」くらいの気持ちで大丈夫です。あなたのポートフォリオ作成を、私たちが全力でサポートします。
＼ まずはサクッと相談！ ／
無料で話を聞いてみる ▶︎▶︎
あなたのエンジニアとしての挑戦を、心から応援しています！
編集後記
最後までお読みいただき、ありがとうございます！RUNTEQ広報担当です。
今回の記事を作成するにあたり、改めて「GitHubはエンジニアの履歴書」という言葉の重みを実感しました。
一つひとつのコミット、一枚のREADME、そしてオリジナルの作品に込めた想い。そのすべてが、採用担当者に「あなた」という人間を伝えています。
この記事で紹介した7つのポイントを意識するだけで、あなたのGitHubは間違いなく、より魅力的なものになるはずです。
しかし、何より大切なのは、あなた自身が「これは自信作だ！」と胸を張って言えるポートフォリオを作り上げることです。
RUNTEQは、そのための技術力はもちろん、課題解決への思考プロセスや、自走する力を育む場所です。
もしあなたが、「本気でエンジニアになりたい」「後悔しないポートフォリオを作りたい」と強く願うなら、私たちは全力でその想いに応えます。
無料カウンセリングは、そのための第一歩です。あなたの熱意を、ぜひ私たちに聞かせてください。画面の向こうで、お待ちしています！
＼ 簡単30秒で予約完了！ ／
無料で話を聞いてみる ▶︎▶︎
