GitHubコミット少ないエンジニア転職、面接の通し方

「このリポジトリ、正直コミット数が少ないんですが……」——面接の最後、逆質問のタイミングでそう切り出す候補者に、これまで何度も会ってきました。GitHubのプロフィールを開くと緑のマスはまばらで、直近3ヶ月はほぼ白いまま。それでも技術面接を通過していく人は珍しくありません。

私はIT・Web業界を中心に800名以上の転職支援に携わっていますが、選考結果を分けているのは草の量ではなく、少ないコミットから「何を選び、何を諦めたか」をどれだけ言葉にできるかです。今回は、コミット数至上主義に頼らないGitHubの見せ方を、実際の面接でのやり取りを交えてお伝えします。

目次

1. 「GitHubコミット少ない」でエンジニア転職は本当に不利になるのか
2. 面接官が見ているのは「量」ではなく「選択と断念」の理由
3. 相談事例、業務多忙で草が生えないSESエンジニアの悩み
4. 職務経歴書とREADMEで「選択と断念」を言語化する書き方
5. 個人開発の時間が取れないときの代替策
6. よくある疑問に答えます
7. GitHubの草が本当に少ないと、書類選考の時点で落とされますか
8. 個人開発のリポジトリは何本公開すればいいですか
9. 最終コミットが1年以上前でも大丈夫ですか
10. プライベートリポジトリしかない場合、面接でどう見せればいいですか
11. コーディングテストがあるなら、GitHubは準備しなくてもいいですか
12. GitHubのプロフィールに自己紹介文を書いた方がいいですか
13. チュートリアルをなぞっただけのリポジトリしかない場合はどうすればいいですか
14. 業務で書いたコードをそのまま個人のGitHubに上げてもいいですか
15. まとめ、コミット数を稼ぐより言葉にする

「GitHubコミット少ない」でエンジニア転職は本当に不利になるのか

「コミットが少ない」「草が生えていない」という悩みは、面談の場でよく聞きます。特に人手不足のSES常駐先や受託案件で稼働時間が長い人ほど、平日夜も土日も個人開発に充てる余力がなく、GitHubを開くと最後の更新が半年前ということも珍しくありません。

このイメージを裏付けるようなデータもあります。人材サービスのLAPRASが2022年3月に実施したエンジニア約1,100名へのアンケート調査では、GitHubで年1回以上何らかのアウトプットをしているエンジニアの約9割が転職経験者で、うち約4割は転職を3回以上経験していたと報告されています。

一方でアウトプット未経験者でも6割は転職経験があり、差はあってもゼロと百の話ではありませんでした（出典：LAPRAS「エンジニア約1000名にキャリアアンケート調査」）。なお、これは「アウトプットする人ほど転職経験者が多い」という相関を示した調査で、コミットが少ないと選考で不利になるかを直接調べたものではありません。2022年3月時点の調査なので、最新の相場そのものというより、傾向の参考として読んでください。

現場の実感としても近い数字です。GitHubのアウトプットは「転職しやすさ」を保証する免罪符ではなく、採用側が候補者を判断する材料の一つに過ぎません。コミット数がゼロに近くても書類選考を通過する人がいる一方、草がびっしり生えていても一次面接で見送られる人もいます。ここに矛盾はなく、見ている軸自体がそもそも違うだけです。

企業の種類によっても重視度は変わります。自社開発のスタートアップやメガベンチャーでは、技術選定を候補者自身がどこまで担ってきたかを見たい現場エンジニアがGitHubを開くことが多く、逆にSIerや受託開発中心の企業では、コーディングテストや職務経歴書の記載内容の方を重視し、GitHubのURLを聞かれないまま選考が終わることも珍しくありません。応募先の開発体制がどちらに近いかで、事前に用意する熱量の配分を変えて構いません。

「少ないコミット」と「何年も放置されたコミット」も、面接官の受け止め方は別物です。直近半年で数件しか動きがなくても、最終更新が最近であれば「今も手を動かしている」証拠として読まれます。一方で最終コミットが2〜3年前のまま止まっているリポジトリは、放置と見なされて逆にマイナスに働くことがあるため、応募直前に1つだけでも軽く手を入れておくと印象が変わります。

「GitHubの草は意味がない」と割り切る人もいますが、これも半分は正しく半分は言い過ぎです。草の量そのものに意味はありませんが、草がある期間とない期間を照らし合わせると、繁忙期と落ち着いた時期の見当がつきます。面接官の中には「この空白期間は何をしていたんですか」と、業務の繁忙度合いを確認する質問として使う人もいて、意味がないというより読み方が一つではないというのが実態に近いと感じています。

面接官が見ているのは「量」ではなく「選択と断念」の理由

「毎日コミットしなくていい、継続性が大事」という助言はよく見かけますが、実際に面接官として同席した現場の話を聞くと、継続日数そのものを気にしている人はほとんどいません。見られているのは、コミットの数ではなく、その少ない履歴から読み取れる判断の跡です。

私が面接同行や振り返りの場で聞いてきた質問には、共通する型があります。「なぜこの構成にしたのか」「なぜこのライブラリを選んだのか」「時間の制約で実装しなかった機能は何か」——いずれもコミットの量ではなく、その裏にある意思決定を掘り下げる質問です。

例えば、あるバックエンドエンジニアの候補者は、在庫管理の個人開発アプリについて「なぜRDBではなくNoSQLを選んだんですか」と聞かれました。コミット数は30程度、最終更新は4ヶ月前という状態です。その候補者は「検索よりも書き込みの頻度が高いと想定して、書き込みコストの低いDynamoDBを選びました。ただ集計クエリが弱くなるのは分かっていたので、そこは実装せずREADMEに課題として書き残しました」と答え、面接官から「実装できなかった理由まで自分の言葉で説明できるのはいいですね」という評価につながりました。

逆に評価が伸びなかったケースもあります。同じ質問に対して「学習のために使ってみたかったので」とだけ答えた候補者は、技術選定の理由を掘り下げられず、そこで会話が止まってしまいました。技術を選んだ理由と、その技術で何を諦めたかをセットで語れるかどうかが、評価の分かれ目になっています。

フロントエンドの候補者にも同じ型の質問が飛びます。家計簿の個人開発アプリを見せたある候補者は「状態管理はなぜContextではなくグローバルなstateライブラリを入れたんですか」と聞かれ、「入力フォームが増えるほどContextの再レンダリングが気になっていたので、規模の割に大げさかもしれないと迷いつつ導入しました。結果としてオーバーエンジニアリング気味になった自覚はあります」と、選んだ理由だけでなく反省点まで答えました。面接官はその後「実装のやり過ぎに自分で気づけるのはいいですね」とコメントし、コミット数は12件しかないリポジトリでしたが、そこは一切問題にされなかったそうです。

モバイルエンジニアの面接でも構造は同じです。写真管理の個人開発アプリを作ったある候補者は「なぜローカルDBにRealmではなくSQLiteを直接使ったんですか」と聞かれ、「学習コストをかけてRealmを覚えるより、まず素のSQLiteでデータ設計の基礎を固め直したかった。将来データ量が増えたらRealmへの移行も検討している、とREADMEに書いています」と答え、面接官から「あえて遠回りを選ぶ判断ができるのはいい」というコメントをもらっていました。あえて簡単な技術を選んだ理由を語れることも、立派な判断の説明になります。

面接官がGitHubを開かないまま終わることも珍しくありません。忙しい現場エンジニアほど事前準備の時間が取れず、面接本番でその場に見せてもらう形を好む人もいます。待っているだけでは評価材料として扱われないので、自己紹介や逆質問のタイミングで「個人開発でこういう判断をしました」と自分から一言触れておくと、聞かれなくても伝わります。

この「選んだ理由と諦めた理由をセットで語る」という受け答えは、GitHub関連の質問に限った話でもありません。業務経験を聞く質問でも、面接官は同じ構造の答えを求めています。個人開発の説明で先に練習しておくと、他の質問への答え方も自然と同じ型に揃っていくので、面接全体の受け答えの質を底上げする副次効果があります。

逆に、量を稼ぐために簡単なコードばかり積み上げるのも考えものです。簡単なコードが並ぶだけだと、量があってもスキルが低く見えることがあります。質とは、難しいことをしているかではなく、判断の理由を語れるかどうかです。

ポイント： コミットが多い人ほど有利になるわけではありません。コミット履歴を眺めながら「なぜ」「その結果どうした」を10秒で答えられるかどうかで、面接官の受け止め方は大きく変わります。

相談事例、業務多忙で草が生えないSESエンジニアの悩み

画面共有で開いたGitHubのプロフィールページに、緑のマスがほとんど並んでいない——そんな画面を見せながら、Bさん（31歳・経験6年、SES常駐でtoC向け受託案件を担当するフルスタックエンジニア）は開口一番「これ、まずいですよね」と聞いてきました。

直近半年のコミットは合計8件。深夜までかかる炎上案件が続き、個人開発どころか休日はほぼ寝て終わる生活だったそうです。応募を考えていた自社開発のスタートアップは技術力を重視する社風だと聞いていて、Bさんは書類の時点で落とされると思い込んでいました。

Bさんが転職を考えたきっかけは、客先の案件がプロジェクトごとに変わり、同じ技術を深める前に次の現場へ回されることへの焦りでした。「手を動かした量では自社開発の人に勝てない」という前提から相談が始まったので、まず私が伝えたのは、比べるべきは量ではなく、限られた時間の中でどう判断してきたかという点だということでした。

私がまず確認したのは、コミット数ではなく「唯一きちんと動いているリポジトリが何なのか」でした。Bさんには前職で作った予約管理アプリの個人開発版があり、コミットは少ないものの機能はひと通り動いています。問題は、READMEに機能一覧が箇条書きされているだけで、なぜその構成にしたのかがまったく書かれていなかったことです。

そこでREADMEに、認証をFirebase Authにした理由（自前実装の工数をかけず予約フローの実装に時間を割きたかった）と、あえて実装しなかった機能（決済連携。個人開発の期間内では検証環境を整える時間が取れないと判断して見送った）を書き加えてもらいました。

二次面接（現場エンジニア同席）で、面接官から「決済、なんで入れなかったんですか」と聞かれたBさんは、READMEに書いた通り「期間内に決済まで検証する時間が取れないと判断して、予約フローの完成度を優先した」と即答できました。コミット数の少なさそのものは一度も話題に上らなかったそうです。

選考は通過し、Bさんは今も忙しい業務の合間を縫って、同じリポジトリに月1回ペースで小さな改善を重ねています。「毎日コミットしなきゃ、という強迫観念がなくなった」というのが、本人が挙げる一番の変化でした。

職務経歴書とREADMEで「選択と断念」を言語化する書き方

Bさんの例のように、変えるべきは個人開発の量ではなく、言語化のフォーマットです。READMEと職務経歴書のどちらにも応用できる型を、ここで整理します。

Bさんの場合、READMEを直した前後で内容がどう変わったかを整理すると、次のようになります。項目自体は増やさず、既に書いてあった機能一覧に「理由」を足しただけです。

職務経歴書にも同じ型で書き足せます。私が実際に添削で入れる文面は、例えば次のようなものです。「個人開発：予約管理アプリ（Next.js／Firebase）——認証実装のコストを抑え予約フローの開発に集中するためFirebase Authを採用。決済連携は検証期間の制約により意図的に見送り、README上に今後の拡張として明記」。1〜2行で十分で、プロジェクトの全機能を説明する必要はありません。

この型は職種を問わず使えます。データエンジニアの候補者を支援した際は、個人開発の分析基盤について「バッチ処理はAirflowではなく素のcronで組んだ理由は、ジョブの本数が3つしかない規模でAirflowを立てる運用コストの方が重いと判断したため。ジョブが増えたら移行する前提でREADMEに書いている」という一文を職務経歴書に足しただけで、面接官から「規模に応じた判断ができる人」という評価コメントをもらえたことがあります。

なぜこの型が効くかというと、採用側が実務でも同じ種類の判断を毎日下しているからです。過剰な設計にせず、かといって手を抜かず、その場の制約の中で最適解を選ぶ——個人開発の説明がそのまま実務のシミュレーションとして読まれるので、コミット数より判断の質に評価が寄るのは自然な流れだと感じています。

ポイント： 職務経歴書に書く個人開発の説明は1プロジェクトにつき2〜3行が目安です。詳しく書きすぎると要点がぼやけ、面接での深掘り質問の余地も減ってしまいます。

面接直前で作り直す時間がなくても、15分あれば見せ方は変えられます。私が候補者に勧めているのは次の3つです。

これだけでも、コミット履歴の見た目自体は変わりませんが、面接官が受け取る情報の質は確実に変わります。

個人開発の時間が取れないときの代替策

複数のリポジトリを公開している人ほど有利、というのも実は思い込みです。面接官は限られた面接時間の中で1〜2個のリポジトリを開けば十分と考えていることが多く、本数より、そのうち1つを深く語れるかどうかが見られています。10個の中途半端なリポジトリより、1個の「なぜ」を説明できるリポジトリの方が評価は高くなります。

前職の規定でリポジトリを公開できないという相談も多く受けます。その場合は、コード自体を見せられなくても、構成図やデータフローを自分で描き起こして面接で見せることができます。私が支援した候補者の中には、A4一枚のアーキテクチャ図をPDFにして画面共有し、「コードそのものはお見せできませんが、構成はこの通りです」と前置きした上で、設計判断だけを説明して通過した人もいました。面接官が知りたいのはコードの中身より思考の順序なので、図があれば代替として十分機能します。

コミットの代わりになるアウトプットは、コード以外にもあります。業務で解決した技術的な工夫をZennやQiitaに匿名化して書く、小さなOSSのissue報告や1件のプルリクエストを丁寧に説明できるようにしておく、といった形です。GitHubの草だけを基準にせず、技術的な思考の跡が残っているかどうかで考えると選択肢は広がります。

OSSへの貢献も、数より1件の深さで十分です。あるインフラエンジニアの候補者は、使っているツールのドキュメントの誤字を直しただけの小さなPRを1件しか出していませんでしたが、「なぜそこに気づいたのか」を聞かれ、「業務で同じ手順を踏んだときに詰まった箇所だったので、次に同じところで悩む人を減らしたいと思って直しました」と答え、面接官から「日常の違和感を放置しない姿勢が伝わる」と評価されていました。PRの規模ではなく、気づきの経緯まで話せるかどうかが見られています。

私の実感では、コーディングテストやペアプログラミング形式の選考を課す企業は増えていて、その場でリアルタイムに実装力・思考の言語化力を見られる比重が相対的に高まっています。GitHubは「事前情報の一つ」、コーディングテストは「その場で確かめる材料」という役割分担が進んでいる印象で、GitHubだけに合否を左右されるという構図自体が薄れつつあります。

よくある疑問に答えます

GitHubの草が本当に少ないと、書類選考の時点で落とされますか

自社開発企業でも、GitHubのURLの有無だけで書類選考の合否を決めているケースは多くありません。職務経歴書に書かれた実務経験や技術スタックの方が優先度は高く、GitHubは面接に進んだ後の深掘り材料として使われる位置づけです。URLを載せていないこと自体を理由に落とされる心配より、載せた場合に説明できない状態の方が問題になります。

個人開発のリポジトリは何本公開すればいいですか

本数にノルマはありません。面接官が実際に開くのは1〜2個が現実的なところで、10個並んでいても全部は見られません。中途半端なリポジトリを何本も置くより、1個を「なぜこの構成にしたか」まで語れる状態にしておく方が評価につながります。

最終コミットが1年以上前でも大丈夫ですか

放置と受け取られるリスクはありますが、致命傷にはなりません。応募前にREADMEを見直して、当時の判断理由や今なら変えたい点を書き加えるだけでも、止まっている印象は和らぎます。数行の更新でも、直近のコミット日時が動くこと自体に意味があります。

プライベートリポジトリしかない場合、面接でどう見せればいいですか

コードそのものを公開できなくても、構成図や技術選定の理由は口頭・画面共有で十分説明できます。「業務規定で公開できないので、構成だけ図でご説明します」と先に断ってから話す形で問題ありません。面接官が見たいのはコードの中身よりも、そこに至った判断の過程です。

コーディングテストがあるなら、GitHubは準備しなくてもいいですか

コーディングテストとGitHubは役割が違うので、片方で完全に代替できるわけではありません。コーディングテストはその場の実装力を測るもの、GitHubは普段の判断の跡を見せるものです。ただし選考にコーディングテストが含まれる企業ほど、GitHubの準備にかける時間の優先度は下げても大きな不利にはなりにくいという実感はあります。

GitHubのプロフィールに自己紹介文を書いた方がいいですか

一言添えるだけでも印象は変わります。「業務多忙のためコミット頻度は低めですが、〇〇の設計判断を大事にしています」のような一文があると、面接官はまばらな草を見た瞬間に放置なのか多忙なのか判断できます。長い自己紹介文を作り込む必要はなく、1〜2行で今の状況を先回りして説明しておくだけで十分です。

チュートリアルをなぞっただけのリポジトリしかない場合はどうすればいいですか

書籍やUdemyの写経リポジトリしかない場合は、正直に「学習用に作りました」と伝えた上で、どこか1箇所だけでも自分で変更を加えた部分を見つけて説明できるようにしておくと印象が変わります。チュートリアル通りに動かしただけの部分と、自分の判断で変えた部分を分けて話せれば、写経であること自体は評価を下げる理由になりません。

業務で書いたコードをそのまま個人のGitHubに上げてもいいですか

これは避けてください。所属先の業務で書いたコードには機密情報や著作権が関わるため、無断で公開すると契約違反や情報漏洩のトラブルに直結します。個人開発として見せたいのは、あくまで業務時間外に自分の名義で書いたコードや、業務で得た考え方を一般化して作り直したものに限定するのが安全です。公開前には、APIキーやパスワードなどの認証情報、社内の固有名詞が履歴やコードに混ざっていないかも必ず確認してください。

まとめ、コミット数を稼ぐより言葉にする

「毎日コミットしよう」「継続がすべて」という助言をよく見かけますが、業務が忙しく余力のない人に継続を求めるのは、そもそも解決策になっていません。余力がある人にはその助言で十分ですが、余力がない人に必要なのは、今ある少ない材料をどう語るかという技術の方です。

「コミット数を稼ぐために無理に個人開発の時間を作るべきだ」という助言は、業務が忙しいエンジニアほど現実的ではありません。私がこの記事で伝えたいのは、草の量を追いかけるより、今ある少ないコミットから何を選び、何を諦めたかを言葉にする方が、面接では確実に効くということです。

次に面接を受けるときは、GitHubを開く前に、README1つを見直すところから始めてみてください。書き足すのは機能の数ではなく、そこに至った判断の理由です。それだけで、面接官との会話の質は変わります。