「GitHubなんて見られてない」は本当か?エンジニア転職で評価される人・されない人の違い

「GitHubなんて実際は見られていない」「ポートフォリオを頑張っても意味がない」といった意見は、エンジニア転職ではよく見かけます。実際、GitHubを提出したのに面接で触れられず、不安になった人もいるでしょう。

しかし、採用現場ではGitHubは普通に見られています。ただし、GitHubだけで採用が決まるわけではありません。返信が遅い、日程調整ができない、質問に正しく答えられないなど、技術以前の部分で評価が止まる人もいます。

この記事では、GitHubは本当に見られているのか、採用側がどこを見ているのか、評価される人・されない人の違いを解説します。

目次

GitHubは本当に見られているのか?

「GitHubなんて見られていない」という話は、エンジニア界隈ではかなり頻繁に語られます。

しかし結論から言えば、GitHubは普通に見られています。

ただし、「全員が細かく精査されるわけではない」というのも事実です。
この認識のズレが、「GitHubなんて意味ない」という意見につながっています。

実際の採用現場では、「GitHubを見る企業」と「そこまで重視しない企業」がありますし、さらに言えば、「GitHubをしっかり見る段階まで進む応募者」と「そこに到達する前に評価が止まる応募者」が存在します。

そのため、「GitHubを提出したのに全然触れられなかった」という人と、「GitHubをかなり深く見られた」という人が同時に存在するのです。

「GitHubなんて見られてない」と感じる理由

まず、多くの人が「GitHubは意味がない」と感じる理由から整理してみましょう。
一番多いのは、「提出したのに触れられなかった」というケースです。

例えば、

  • GitHubを送ったのに面接で何も言われなかった
  • 個人開発について質問されなかった
  • ポートフォリオの感想がなかった
  • 書類選考で普通に落ちた
  • 技術試験だけで終わった

こうした経験をすると、「結局見てないじゃん」と感じるのは自然です。

特に未経験転職では、「GitHubを頑張れ」と散々言われるため、期待値がかなり高くなっています。
その結果、「全然触れられない」という体験をすると、ギャップが生まれます。

しかし、ここで重要なのは、採用側は応募者一人ひとりを何時間もかけて分析しているわけではない、ということです。

特に応募数が多い企業では、短時間で大量の応募者を見ています。
採用担当も現場エンジニアも、本業の合間に採用対応をしているケースが多いため、現実にはかなり忙しいです。

そのため、「この人は最低限仕事が成立しそうか」という部分を先に見ています。

例えば、採用担当が以下のような内容を送ったとします。

面接可能日時を3つほどいただけますでしょうか。あわせてGitHub URLと現在の転職状況についてもご共有ください。

しかし返ってきた回答が、

来週なら空いてます

だけだった場合、採用側はかなり不安になります。
これは単なるメールマナーの問題ではありません。

実務では、

  • 要件確認
  • 仕様相談
  • レビュー返信
  • バグ報告
  • 顧客対応
  • Slackコミュニケーション

など、文章コミュニケーションが大量に発生します。

つまり、「質問の意図を理解して、必要な情報を返せるか」は、実務能力にかなり直結しているのです。
採用側は、

この人はGitHub以前に、業務コミュニケーションが成立するだろうか?

という視点で見ています。

そのため、GitHubを深掘りする前に評価が止まってしまうケースがあります。
これが、「GitHubなんて見られてない」と感じる大きな原因の一つです。

実際にはGitHubを見る企業はかなり多い

一方で、GitHubをしっかり見る企業もかなりあります。
特に以下のような企業では、その傾向が強いです。

  • 自社開発企業
  • スタートアップ
  • CTOが採用に入る会社
  • 少人数開発組織
  • 技術広報に力を入れている会社
  • エンジニア文化が強い会社

こうした企業では、履歴書や職務経歴書だけでは分からない部分をGitHubで見ています。例えば、

  • 本当にコードを書いているのか
  • どのくらい継続して勉強しているのか
  • 技術に興味を持っているのか
  • 作り切る力があるのか

などです。

特に若手や未経験採用では、GitHubはかなり重要です。
なぜなら、実務経験が少ない人の場合、企業側は「この人は実際にどこまで手を動かせるのか」を知りたいからです。

最近は、プログラミングスクール卒業者も増えています。
しかし、スクール卒業だけでは、「本当に理解しているのか」「実際に自力で開発できるのか」が分かりません

例えば、スクール教材をそのままなぞっただけの人と、自分で調べながらエラーを解決している人では、実際の現場適応力がかなり違います。
GitHubを見ると、その差がある程度見えてきます。

READMEの書き方、コミット履歴、試行錯誤の跡、技術選定などから、

この人はちゃんと考えながら作っているな

という空気感が伝わることがあります。
つまりGitHubは、「コードの完成品を見る場所」というより、「開発への向き合い方を見る場所」に近い側面もあるのです。

「GitHubを見ない会社」も確かに存在する

一方で、GitHubをそこまで重視していない企業もあります。例えば、

  • 大量採用系企業
  • 非IT企業の情報システム部門
  • エンジニア採用に慣れていない会社
  • SES中心の企業
  • 一次面接を人事だけで回している会社

などです。
こうした会社では、GitHubを技術的に深く評価できる人がいないケースもあります。
そのため、

  • 職務経歴書
  • 資格
  • 面接の受け答え
  • 転職回数
  • 年齢

などが中心になることがあります。
この場合、本当にGitHubがあまり見られていないケースもあります。
そのため、「GitHubは絶対見られる」と断言するのも違います。
正しく言えば、見る会社はかなり見るし、見ない会社はほぼ見ないです。
だからこそ、「GitHubが意味ない」という話と、「GitHubが評価された」という話が両方存在するのです。

GitHubだけで採用が決まるわけではない

ここを勘違いしている人はかなり多いです。

エンジニア採用というと、「コードが書ければ勝ち」というイメージを持っている人もいます。
特にSNSでは、「コミュ力より技術力」という価値観が強く語られがちです。

しかし、現実の採用はもっと総合評価です。
実際には、「技術力があるか」以前に、「仕事として成立するか」がかなり見られています。

技術以前の部分で落ちる人は本当に多い

採用側からすると、エンジニアは単なる「プログラムを書く人」ではありません。
実際の業務では、

  • PMとの認識合わせ
  • デザイナーとの調整
  • 顧客との打ち合わせ
  • 営業との連携
  • レビュー対応
  • チーム相談

など、コミュニケーションが大量に発生します。
特に最近はリモートワークが増えているため、「文章コミュニケーション能力」は以前よりさらに重要になっています。
SlackやChatworkだけで仕事が進む場面も珍しくありません。
そのため、採用では以下のような部分もかなり見られています。

  • レスポンス速度
  • 質問理解力
  • 会話の成立
  • 日程調整能力
  • 報連相
  • 相手への配慮

特に多いのが、「質問に正しく答えられていない」ケースです。
例えば、

  • 希望年収
  • 稼働開始可能日
  • 面接可能日時

の3つを聞いているのに、

年収は450万円希望です

だけ返ってくるケースがあります。

これは驚くほど多いです。
採用側としては、

実務でもこうなるのでは?

という不安を持ちます。

エンジニアの仕事は、単にコードを書くことではありません。
相手の要求を整理し、必要な情報を返し、認識を揃える仕事でもあります。
つまり、GitHub以前に、「業務の基礎コミュニケーション」が見られているのです。

「返信が遅い」は想像以上に印象が悪い

これもかなり現実的な話です。
もちろん、即レスが正義というわけではありません。

しかし、

  • 返信が3日以上ない
  • 日程調整が止まる
  • リマインドしないと返ってこない
  • 面接前日に返信が来る

状態だと、採用側はかなり不安になります。

なぜなら、実務でも同じことが起こる可能性を想像するからです。

特に受託開発やSESでは、

  • 顧客返信
  • 障害報告
  • 納期調整
  • チーム連携

など、「連絡」が仕事そのものに直結しています。

そのため、「GitHubは強いけど連絡が不安定な人」より、「GitHubは普通だけどコミュニケーションが安定している人」のほうが採用されるケースも普通にあります。

SNSでは、「技術力だけで評価してほしい」という意見もあります。
しかし現実には、「仕事として成立するか」が見られているのです。

「優秀そうだけど採りたくない」は本当に存在する

GitHubを見ると、

技術的にはかなり頑張っているな

と感じる人はいます。
しかし、それでも不採用になるケースがあります。
理由として多いのは、

  • 会話が成立しない
  • 指摘への反応が強すぎる
  • 相手の話を聞かない
  • 技術マウントが強い
  • 自分語りが止まらない

などです。

エンジニア界隈では、「技術力さえあればいい」という考え方もあります。
しかし現実の組織運営では、チームで成果を出す必要があります。

そのため、「優秀だけど扱いづらい人」より、「普通に会話できて仕事を進めやすい人」が評価されるケースもかなり多いです。

特に日本企業では、その傾向は強めです。
「一緒に働けるか」という視点は、想像以上に大きいのです。

採用側はGitHubのどこを見ているのか?

「GitHubを見ています」と言われると、多くの人は「高度なアルゴリズム」や「複雑な設計」を想像します。

しかし、実際にはもっと基本的な部分を見られていることが多いです。

READMEはかなり重要

READMEは本当に重要です。
なぜなら、「説明能力」が見えるからです。
例えば、

  • 何を作ったのか
  • なぜ作ったのか
  • 技術構成
  • 起動方法
  • 工夫ポイント

などが整理されているだけで、かなり印象は変わります。逆に、

  • READMEが空
  • 何のアプリか分からない
  • 起動方法が不明
  • スクリーンショットなし

状態だと、かなり見づらくなります。

採用側は、作品研究をしているわけではありません。

短時間で判断しています。
だからこそ、「分かりやすさ」が重要なのです。
特に現場エンジニアは、READMEから「この人は他人に伝える意識があるか」を見ていることがあります。

実務では、コードを書くことだけでなく、他人が理解できる状態にすることが重要だからです。

「完成させているか」はかなり見られる

初心者ほど、

大規模サービスを作らなきゃ

「」と考えがちです。
しかし、採用側はそこまで求めていません。

むしろ見ているのは、「最後まで作り切ったか」です。
例えば、

  • ログインできる
  • エラー処理がある
  • READMEがある
  • デプロイされている
  • 最低限UIが整っている

こうした基本が整っているだけで印象はかなり変わります。
未完成の巨大SNSより、小さくても完成した家計簿アプリのほうが評価されることは普通にあります。

なぜなら、実務で最も重要なのは、「完成させる力」だからです。

実際の仕事では、「途中まで作れます」より、「最後まで責任を持って仕上げられます」のほうが重要です。
そのため、「完成している」という事実そのものが評価対象になります。

コミット履歴からも仕事感は見える

コミット履歴も意外と見られています。例えば、

  • commit message が全部「fix」
  • 初日に100ファイル一括コミット
  • 半年以上更新ゼロ

などは、少し雑な印象を持たれます。
もちろん、個人開発なので完璧である必要はありません。しかし、

  • 小さくコミットしている
  • 継続的に触っている
  • 何を変更したか分かる

だけでも、「仕事感」がかなり出ます。
実務経験者ほど、このあたりに自然な実務感が出るため、採用側も見ています。

また、コミット履歴からは、「この人は継続できるタイプか」も見えます。
エンジニアは短距離走ではなく、かなり長期戦の仕事です。
そのため、「地道に積み上げられる人か」は、意外と重要な評価ポイントです。

GitHubを評価されやすくするコツ

GitHubは単なるコード置き場ではありません。
採用では、「見せる資料」に近い側面もあります。

「採用側が読む前提」で整理す

初心者ほど、「作ること」で満足してしまいがちです。
しかし重要なのは、「読む人がいる」ことです。そのため、

  • READMEを書く
  • スクリーンショットを入れる
  • デモURLを置く
  • 技術選定理由を書く

だけでもかなり見やすくなります。

特にREADME改善はコスパが非常に高いです。
コードを劇的に改善するより、READMEを整理したほうが印象改善につながることもあります。
採用側は短時間で判断しているため、「読みやすい」はかなり重要です。

小さくても完成させる

未経験者ほど、「Twitterクローン」や「メルカリクローン」を作ろうとして止まります。
しかし採用側が見ているのは、「規模」より「完成度」です。
そのため、

  • 家計簿アプリ
  • メモアプリ
  • 勉強記録アプリ
  • シフト管理アプリ

など、小さくても完成しているほうが強いです。
完成経験は実務にかなり直結します。

また、「小さくても最後までやり切る人」は、現場でも評価されやすいです。
逆に、「壮大な構想だけど未完成」は、少し危うさを感じさせることがあります。

GitHubだけに全振りしない

最終的に重要なのはここです。どれだけGitHubが強くても、

  • 返信が遅い
  • 日程調整が雑
  • 質問に答えない
  • 会話が噛み合わない

状態だと普通に落ちます。

特に若手採用では、「一緒に働きやすいか」がかなり見られています。
そのため、GitHubを頑張ることも重要ですが、基本的なコミュニケーションを軽視しないことも同じくらい重要です。

実際、採用現場では、「GitHubは普通だけど安心して仕事できそう」という理由で採用される人もいます。
逆に、「GitHubは強いけど現場が疲弊しそう」という理由で落ちる人もいます。

エンジニア転職は、単なる技術試験ではありません。
「チームで仕事ができるか」を含めた総合評価なのです。

まとめ

  • GitHubは実際には普通に見られている
  • ただしGitHubだけで採用を決めているわけではない
  • 技術以前のコミュニケーション部分で落ちる人もかなり多い

エンジニア転職において、GitHubは非常に強い武器になります。
特に若手や未経験エンジニアにとっては、「実際に手を動かしている人か」を伝える重要な材料です。

しかし採用は、コードだけで決まるわけではありません。
返信速度、質問理解力、会話の成立など、「一緒に仕事ができるか」もかなり見られています。

そのため、GitHubを育てることはもちろん大切ですが、基本的なコミュニケーションを軽視しないことも、転職成功には非常に重要です。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

セルワークITフリーランス編集部のアバター セルワークITフリーランス編集部 セルワークITフリーランス編集部(運営:株式会社セルバ)

セルワークITフリーランス編集部は、ITエンジニア・ITフリーランス・SES人材のキャリア支援を行う「株式会社セルバ」が運営する編集チームです。

株式会社セルバは、Webシステム開発・ポータルサイト構築を中心に20年以上の実績を持ち、IT業界・人材業界の両分野において、事業運営と現場支援の両面から関わってきました。
自社サービスとして、IT人材向けの求人・マッチング・キャリア支援に関する複数のWebサービスを運営しています。

編集部では、そうした事業運営の中で蓄積されてきたITフリーランスからの相談内容、案件参画時の実例、契約・単価・キャリアに関する課題をもとに、実務に即した情報を編集・監修しています。

本メディア「セルワークITフリーランス」では、単なる一般論や表面的なノウハウではなく、現場で実際に起きている課題や意思決定のポイントを重視し、ITフリーランスが自分に合った働き方を選ぶための情報提供を目的としています。
記事はすべて、IT業界・人材業界の実務に携わる運営チームによる確認・編集体制のもとで公開しています。

目次