エンジニアのポートフォリオ評価方法｜GitHub の見方を非エンジニア向けに

採用候補のエンジニアから「私のスキルは GitHub をご覧ください」と URL を提示されたものの、開いた画面に並ぶリポジトリの一覧や英語の README、緑色のマス目を見て、何をどう判断すればよいか手が止まってしまった経験はないでしょうか。コードを書いたことがない立場で「技術力」を評価する場面が、ここ数年で急に増えています。

外部エンジニアの活用が一般化する一方で、社内に技術評価ができる人材を抱えていない、あるいは在籍していても多忙で一次評価に巻き込めない企業は少なくありません。結果として、人事や事業責任者の方が「分からないなりに評価する」という難しい状況に置かれているのが実情です。

このとき多くの方が抱えるのは、技術そのものへの理解不足以上に「自分の評価が間違っていて、社内で『見抜けない人』だと思われるのが怖い」という心理的な負担です。判断の正解が見えないまま面談を進め、後から「なぜあの候補者を選んだのか」と問われたときに根拠を示せるだろうかと不安になります。

結論からお伝えすると、ポートフォリオや GitHub の一次評価は、技術が分からなくても十分に行えます。コードの中身を読まずに「開発姿勢」「コミュニケーション能力」「継続性」を読み取る視点に絞れば、非エンジニアの担当者でも候補者の輪郭をつかむことができます。

本記事では、ポートフォリオを見せられたときの目線移動から、GitHub 画面の見方、ポートフォリオがない候補者への代替評価ルート、そして一次スクリーニングで社内会議にそのまま持ち込める評価シート例までを整理してお伝えします。「全部わかろうとしない」スタンスで、必要なところだけ持ち帰っていただければ十分です。

なぜエンジニアのポートフォリオ評価で発注企業はつまずくのか

外部エンジニアの採用において、非エンジニアの担当者が一次評価を担うケースは年々増えています。フリーランスや複業エンジニアの活用が当たり前になる一方で、社内の体制が追いついていないという構造的な問題があります。

非エンジニア担当者が技術評価を任される構造

経済産業省「IT人材需給に関する調査」でも、IT人材の不足は深刻な課題として継続的に指摘されています（経済産業省「IT人材需給に関する調査」）。多くの企業で外部人材の活用が現実解となっていますが、その採用窓口は人事・総務・事業企画など、必ずしも技術に明るくない方が担うことが少なくありません。

社内にエンジニアがいる場合でも、一次面談から技術責任者を巻き込むのは現実的に難しいケースが多いものです。「忙しい技術メンバーの時間を奪う前に、人事側で候補者を絞り込んでほしい」という要請を受けて、非エンジニアの担当者が GitHub やポートフォリオを開く、というのが典型的な流れです。

この状況で「分からなくて当然」と割り切れず、自分の評価能力を疑ってしまうのは自然な反応です。ただ、これは個人の能力不足ではなく、技術評価の前線に非エンジニアが立たされている構造そのものに起因します。

「コードの良し悪し」と「人材としての良し悪し」は別物

評価を難しく感じる理由のひとつに、「ポートフォリオ評価＝コードの技術的な良し悪しを判定すること」という思い込みがあります。実際にはこの 2 つは別の評価軸です。

コードの細部を読み解く作業は、技術責任者やテックリードの仕事として後工程に回せます。一次スクリーニングで本当に必要なのは「この候補者と一緒に仕事ができそうか」「自分の頭で考えて手を動かしてきた人か」「説明能力はあるか」という、人材としての適性の見極めです。これは技術が分からなくても観察できます。

一次スクリーニングで非エンジニアが見るべき領域

本記事で扱うのは、コードの中身を読まずに、ポートフォリオや GitHub から読み取れる以下の 3 領域です。

• 開発姿勢: 計画的に取り組んでいるか、目的を持って制作物を作っているか
• コミュニケーション能力: 第三者に伝わる説明を書けるか、自分の仕事を言語化できるか
• 継続性: 一過性ではなく、継続的に学習・制作してきた痕跡があるか

これらは技術用語の知識がなくても、文章の質や情報の整理のされ方から十分に観察できる領域です。「コードの良し悪しは技術者に任せる、人材としての輪郭は自分で見る」と役割を割り切ることが、評価を進める第一歩になります。

エンジニアのポートフォリオで見るべき 5 つの視点

ここからは、ポートフォリオや GitHub のリポジトリを開いたときに「どこを見るか」を 5 つの視点に整理してお伝えします。技術的な判断を伴わず、文章と構成から読み取れる観点に絞っています。

視点 1｜README（解説文）が読み手を意識して書かれているか

GitHub の各リポジトリには README と呼ばれる解説文書が置かれていることが多く、画面を下にスクロールすると本文として表示されます。この README が「何を作ったのか」「なぜ作ったのか」「どう動かすのか」を、初見の読み手に伝わる形で書かれているかを最初に確認してください。

良い例の特徴としては、冒頭に制作物の概要が 2〜3 行で述べられている、スクリーンショットや図が貼られている、目次や章立てがある、といった点があげられます。逆に「セットアップ手順だけが羅列されている」「コードしか書かれていない」「英語と日本語が混在して読みにくい」といった README は、第三者への説明意識が薄い可能性を示します。

技術的な内容を理解する必要はありません。「自分が読み手として置いていかれていないか」だけを判断基準にしてください。

視点 2｜制作物の「目的」と「課題」が言語化されているか

優れたエンジニアは、自分が何を解決するために作ったのかを言語化できます。README の冒頭または「背景」「動機」といった見出しに、制作の目的や解決したい課題が書かれているかを確認してください。

たとえば「業務で繰り返し発生する集計作業を自動化するため作成」「個人の家計簿を毎月手動で集計するのが面倒だったので作成」のように、課題が具体的に書かれていれば、ビジネスの文脈で物事を考えられる人材である可能性が高いといえます。

逆に「練習のため」「学習のため」しか書かれていない場合は、課題発見から取り組む姿勢が見えにくく、業務の文脈で考えるトレーニングが不足しているかもしれません。完全にネガティブな評価ではありませんが、評価の参考情報になります。

視点 3｜担当範囲・使用技術・工夫した点が説明されているか

特にチーム開発の経験がある候補者の場合、ポートフォリオ内で「担当範囲」「使用技術」「工夫した点」が明示されているかを確認してください。チーム開発では複数人で1つのプロダクトを作るため、候補者が具体的にどの部分を担当したのかが分からないと、実力を見誤る原因になります。

「フロントエンドの画面設計とデータ取得処理を担当」「3名チームのうち、自分はサーバー側を担当」のように担当範囲が明確に書かれていれば、自分の仕事を客観的に説明できる人材です。「工夫した点」も同様で、技術選定の理由や設計上のトレードオフを言語化できているかは、思考の深さを示すサインになります。

視点 4｜一定期間にわたって継続的な活動の痕跡があるか

GitHub のプロフィール画面には、過去 1 年間の活動量を可視化したヒートマップ（俗に「草」と呼ばれます）が表示されます。緑色の濃淡で 1 日ごとの活動量を示すグラフです。

ここで見るべきは「濃さ」ではなく「継続性」です。毎日活動している必要はありません。週 1〜2 回でも構わないので、一定期間にわたって活動が続いている痕跡があれば、継続的に学習・制作してきた候補者である可能性が高くなります。

逆に「直近 1 ヶ月だけ集中的に活動して、それ以前はほぼ空白」というパターンは、ポートフォリオ作成のためだけに駆け込みで取り組んだ可能性も考慮に入れる必要があります。即座にネガティブと決めつけるのではなく、面談で「最近 GitHub の活動が活発ですね、何かきっかけがあったのですか」と聞くきっかけにしてください。

視点 5｜自分が困った課題を解決する自主制作物があるか

ポートフォリオの中に、業務や学習課題とは別の「自分が困ったから作った」自主制作物があれば、強いポジティブシグナルです。日常生活の小さな不便（家計簿、献立管理、勉強記録など）を自分の手でツール化する姿勢は、「言われたことだけをやる人」と「自分で課題を見つけて動ける人」を分ける重要な指標です。

業務委託・フリーランス契約では、発注側が細かい指示を出せない場面が多くあります。自走できる人材かどうかを見極める材料として、自主制作物の有無は強い判断材料になります。

GitHub の画面構成と非エンジニアの目線移動

ここからは、候補者から GitHub の URL を提示されて画面を開いた瞬間に、どこを見ればよいかを具体的にお伝えします。技術用語は最小限に絞り、画面上の位置で説明します。

プロフィール画面で確認すること

候補者の GitHub の URL を開くと、最初にプロフィール画面が表示されます。左側に候補者の名前・自己紹介文・所属、右側に「Pinned」と呼ばれる固定リポジトリ（本人が見せたい代表作）が並んでいるレイアウトです。

最初に見るべきは「自己紹介文」と「Pinned」の 2 箇所です。自己紹介文には経歴・専門分野・得意領域が書かれていることが多く、候補者が自分をどう位置づけているかが分かります。Pinned には本人が「これを見てほしい」と選んだ代表作が並んでいるため、評価対象として最も優先度の高いリポジトリです。

リポジトリ一覧の見方

プロフィール画面の上部メニューから「Repositories」を選ぶと、候補者の全リポジトリ一覧が表示されます。ここで確認したいのは 2 点です。

ひとつは「Fork」という表示の有無です。Fork とは他人のリポジトリを複製したものを指し、必ずしも本人が作ったプロダクトとは限りません。Fork 表示があるリポジトリは「他人の制作物を参考にしたもの」、Fork 表示がないリポジトリは「本人がゼロから作ったもの」と区別して見てください。

もうひとつは「最終更新日」です。リポジトリ名の横に「Updated last week」「Updated 2 years ago」のように、最終更新からの経過時間が表示されます。最近活動しているリポジトリと、放置されているリポジトリを区別するのに使えます。

個別リポジトリの README で見るポイント

個別リポジトリを開くと、上部にファイルやフォルダの一覧、下部に README の本文が表示されます。下部の README が、先ほどお伝えした「視点 1〜3」の評価対象です。

長文を全部読む必要はありません。冒頭の 200〜300 字程度で「何を作ったか」「なぜ作ったか」が伝わるかどうかを判断してください。スクリーンショットや動作デモの GIF アニメーションが貼られていれば、視覚的に内容を把握できるよう配慮されているサインです。

スター数・草の正しい解釈

GitHub にはリポジトリごとに「Star」と呼ばれる、お気に入り登録のような機能があります。スター数が多いほど他のエンジニアから注目されているリポジトリですが、これは候補者個人の実力評価には必ずしも直結しません。

スター数が多いのは「世の中に役立つツールを作った」「世間で話題になった」結果であり、個人の実力指標としては偏りがあります。OSS 活動を本格的に行っている候補者でないかぎり、スター数 0〜数件は普通です。スター数が少ないからといってネガティブに評価する必要はありません。

同様に、プロフィール画面の活動ヒートマップ（草）の濃さも、絶対的な指標ではありません。GitHub には「プライベートコントリビューションを表示」という設定があり、これがオフになっている場合、プライベートリポジトリへのコミットは草に反映されません。業務コードをプライベートリポジトリで管理しているエンジニアは、実際には日々コードを書いていても草が薄く見える傾向があります。あくまで「個人活動の継続性」を見る目安として捉えてください。

鵜呑みにすべきでない指標

最後に、見た目で印象に残りやすいものの、評価指標としては慎重に扱うべきポイントをお伝えします。

• リポジトリ数の多さ: 数が多くても、Fork や学習用の小さなリポジトリが大半というケースは珍しくありません。数より中身です
• 古い OSS への単発コミット: 有名な OSS への 1 行修正は、初心者でも可能なケースが多く、深い貢献とは限りません
• 使用プログラミング言語の数: 「使える言語が多い＝実力が高い」とは限りません。1 つの言語を深く使い込んでいる方が、業務上は有用なケースが多いです

これらは候補者を否定する材料ではありませんが、表面の数字だけで「優秀」と判断する根拠にはなりません。

コード品質を技術者以外が判断するコツ

「コードを読めない自分にコード品質の判断は無理」と感じる方も多いと思います。ですが、コードそのものを読まなくても、周辺情報から品質の手がかりを掴むことができます。

コードを読まなくても観察できる「周辺情報」

リポジトリ内のファイル構成だけでも、いくつかのシグナルが読み取れます。

• README.md の充実度: 既にお伝えした通り、説明の質はそのまま開発姿勢を反映します
• tests・test フォルダの有無: テストコードを書く習慣がある候補者は、品質意識が高い傾向があります（ただし、必須ではありません）
• .gitignore ファイルの存在: 不要なファイルを除外する基本的な設定があるかは、開発の基礎習慣を示します
• LICENSE ファイルの存在: ライセンスを明示しているリポジトリは、公開意識が高いサインです

ファイル名の英語が分からなくても、「テスト関連のフォルダがある／ない」「説明書きの長さ」「ファイル数の多さ」程度は誰でも観察できます。

コミットメッセージから読み取れる開発姿勢

個別リポジトリ画面の「Commits」というリンクを押すと、コードの修正履歴（コミット履歴）が一覧で表示されます。各コミットには「コミットメッセージ」と呼ばれる短い説明文が付いています。

このコミットメッセージが「修正」「更新」「fix」「update」のような一語だけで終わっているか、それとも「ログイン機能のバリデーション処理を追加」「集計バグの修正：日付境界の取り扱いを修正」のように、何をなぜ変更したのかが書かれているかを確認してください。

後者の書き方ができる候補者は、自分の作業を他者に伝える意識があり、チーム開発でも円滑に協業できる可能性が高くなります。これは技術が分からなくても、日本語または英語の文章の質として観察できます。

社内エンジニアに 5 分で相談するための質問テンプレート

自分で判断しきれない箇所は、社内のエンジニアに相談するのが最善です。ただ、忙しいエンジニアに「この候補者を評価してください」と URL を投げるだけでは、相手の時間を大きく奪ってしまいます。

時間を取らせない聞き方として、以下のテンプレートを参考にしてください。

〇〇さん、お忙しいところすみません。採用候補者の GitHub を確認しています。私の方で以下の点までは確認できました。

• Pinned リポジトリ 3 つの README は読みやすく、目的・担当範囲・工夫した点が書かれていました
• 直近 6 ヶ月の活動は継続的にあります
• 自主制作物として家計簿アプリと社内ツールを公開しています

残りで判断がつかない点が以下の 2 つです。5 分だけ見ていただいて、コメントいただけないでしょうか。

• 〇〇のリポジトリで使われている技術スタックが、当社の今回の案件と相性が良いか
• △△のリポジトリのコード品質を、上級者から見てどう評価するか

このように「自分で見た範囲」と「判断がつかない範囲」を切り分けて相談することで、エンジニア側は短時間で本質的なコメントを返せます。「全部見てほしい」と丸投げするのではなく、「ここまで自分で見て、ここから先が分からない」という伝え方が、エンジニアにとってもありがたい相談の形です。

ポートフォリオや GitHub がない候補者をどう評価するか

ここまでポートフォリオ・GitHub がある前提でお伝えしてきましたが、現実には「GitHub の URL を聞いたら空のアカウントだった」「ポートフォリオは持っていません、と言われた」というケースも頻繁に発生します。

ポートフォリオが「ない」のは普通という前提理解

エンジニアの大多数は、業務で書いたコードを公開できません。多くの企業ではソースコードが機密情報として管理されているため、本人がいくら優秀でも「公開可能な制作物」を持っていないのが普通です。

つまり「GitHub が空＝低スキル」と判断するのは早計です。むしろ、公開できるポートフォリオを持っているのは、個人活動で時間を割いてきた一部のエンジニアに限られます。経験年数が長く優秀なエンジニアでも、GitHub のアカウントを持っていない、または業務外の活動をしていない方は珍しくありません。

ポートフォリオがない候補者を機械的に除外せず、別の評価ルートで判断する姿勢が求められます。

職務経歴書から読み取る代替評価

ポートフォリオがない場合、職務経歴書の「具体性」が最も重要な評価対象になります。良い職務経歴書には、以下のような情報が具体的に書かれています。

• プロジェクト規模: 期間・チーム人数・自分の担当範囲
• 使用技術: 単なる技術名の羅列ではなく、その技術を選んだ理由や使い方
• 成果: 「処理時間を 5 分から 30 秒に短縮」「障害発生件数を月 10 件から 2 件に削減」など、数値で説明できる成果
• 役割: 設計フェーズから入ったのか、実装のみか、運用も担当したのか

逆に「〇〇社にて〇〇開発に従事」のような抽象的な記述しかない場合、現場で何をしていたかが見えません。具体性の濃淡だけでも、候補者の経験の深さは推測できます。

面談での口頭ヒアリングを評価に変える質問例

面談の場で、ポートフォリオに頼らず候補者の実力を引き出す質問例をいくつかお伝えします。

• 「最近 1 年で一番苦労した案件について、何が難しくてどう乗り越えたかを 3 分でお話しください」: 課題の言語化・思考プロセスの深さが見えます
• 「ご自身の強みと弱みを、過去のプロジェクトの具体例とセットでお話しください」: 自己分析能力と客観性が見えます
• 「今回の当社の案件で、現時点で気になっている点や懸念点があれば教えてください」: 業務に対する解像度・関心の深さが見えます

これらの質問は技術知識を問うものではないため、非エンジニアの面接官でも実施可能です。回答の具体性・論理性・自己客観視の有無に注目してください。

簡易技術試験・トライアル発注という選択肢

書類と面談だけで判断しきれない場合、簡易技術試験やトライアル発注も選択肢になります。

簡易技術試験は、社内エンジニアに 1〜2 時間の課題を作ってもらい、候補者に取り組んでもらう方法です。ただし、優秀な候補者ほど時間を惜しむ傾向があるため、報酬や時間負担への配慮が必要です。

トライアル発注は、本契約前に短期間（1〜2 週間程度）の小さな案件を発注し、実際の働き方を見る方法です。コストはかかりますが、書類や面談では分からない「実際の納品物の品質」「コミュニケーションのテンポ」「課題発見能力」を直接観察できます。発注金額の数倍のリターンがある選択と考える企業も増えています。

一次スクリーニングで使える評価シート例

ここまでお伝えした視点を、社内会議でそのまま使える評価シートにまとめます。エクセルや Google スプレッドシートにコピーして、候補者ごとに記入してご活用ください。

評価シート（テーブル形式）

判定の目安は以下の通りです。

• ◎: 期待を上回る。複数の制作物で確認できる
• ○: 期待水準を満たす。一定数の制作物で確認できる
• △: 基準は満たすが、深さは限定的
• ×: 確認できない、または期待を下回る
• 不明: 自分では判断がつかない（社内エンジニアへの相談対象）

シートの使い方と運用上の注意

このシートは「点数化して合計点で判定する」目的では設計していません。あくまで「どこを見たか」「どこが判断つかなかったか」を可視化するためのツールです。

運用上の注意として、以下を意識してください。

• 無理に判定を埋めない: 自分で判断できない項目は「不明」のままで構いません。「不明」項目を社内エンジニアへの相談材料として活用してください
• × が多くても即除外しない: ポートフォリオの提示がないだけで業務経験が豊富な候補者もいます。職務経歴書や面談での確認とセットで判断してください
• 複数候補者を同じシートで比較する: 同じ視点で複数人を見ると、相対的な強みが見えやすくなります
• 採用判断は技術責任者と合議する: このシートは一次スクリーニング用です。最終判断は技術評価ができる方と合議してください

シートをそのまま社内会議の議論の叩き台として使うことで、「なんとなく良さそう」「印象が悪い」といった主観評価から、観点ベースの議論に移行できます。

まとめ｜ポートフォリオ評価は「全部わからなくてよい」

最後に、本記事でお伝えした内容を整理します。

エンジニアのポートフォリオを非エンジニアの担当者が評価するときは、コードの中身を読む必要はありません。以下の 5 つの視点で、文章と構成から読み取れる範囲を確認してください。

1. README が読み手を意識して書かれているか
2. 制作物の目的・課題が言語化されているか
3. 担当範囲・使用技術・工夫した点が説明されているか
4. 一定期間にわたって継続的な活動の痕跡があるか
5. 自分が困った課題を解決する自主制作物があるか

GitHub の画面を開いたら、プロフィールの自己紹介と Pinned リポジトリの README から見始めてください。スター数や草の濃さは、必ずしも実力指標ではないため、過大評価しないように注意してください。

ポートフォリオがない候補者を機械的に除外せず、職務経歴書の具体性、面談での口頭ヒアリング、簡易技術試験・トライアル発注などの代替評価ルートを組み合わせて判断することも重要です。

そして最も大切なのは、技術評価を 100% 一人で抱え込まないことです。一次スクリーニングで「ここまで自分で見た、ここから先が判断つかない」と切り分けたうえで、社内エンジニアや外部パートナーに相談する姿勢こそが、適切な役割分担です。「全部わからなくてよい」と割り切ることが、よい採用判断につながります。

外部エンジニアの採用・活用をより体系的に進めたい方向けに、お役立ち資料として「フリーランスエンジニアの採用から活用までのプロセスをまとめたガイド」もご用意しています。本記事の評価シートに加えて、契約形態の選び方やオンボーディング設計まで含めた実践的な内容になっていますので、ぜひあわせてご活用ください。