【ITニュース解説】Turn a GitHub project into three resume bullets a recruiter will believe

履歴書にGitHubプロジェクトを載せる際、その書き方一つで採用担当者に与える印象は大きく変わる。多くの人が「React、Node.js、PostgreSQLを使ってフルスタックWebアプリを構築した」といった記述をするが、これは事実であっても、採用担当者にとってはほとんど情報にならない。なぜなら、何千人もの開発者が同様の技術スタックでアプリを構築しているからだ。採用担当者が本当に知りたいのは、あなたがどんな問題を解決したのか、プロジェクトのどの部分を自分で担当したのか、そしてその成果がどのように確認できるのか、という具体的な情報である。

効果的なプロジェクト記述は、主に以下の3つの質問に答える形で構成されるべきだ。

1. プロジェクトは何を解決するのか？ この質問には、コードをまったく知らない人でも理解できるような一文で答える必要がある。単に技術を使って何かを作った、というだけでなく、そのプロジェクトがどのような課題や不便を解消したのか、具体的な価値を示すことが重要だ。例えば、「カフェのスタッフがシフト交換に使うWhatsAppグループで、リクエストがよく見失われていた問題を解決した」といった具体的な課題を挙げることで、あなたの開発が単なる技術の習得だけでなく、実際のニーズに応えていることをアピールできる。

2. 個人的に何をしたのか？ プロジェクトがチームで開発された場合、自分が具体的にどの部分を担当し、どのような貢献をしたのかを明確にする必要がある。これにより、あなたの役割とスキルセットが正確に伝わる。例えば、「マネージャーがワンクリックで承認し、両方のスタッフにメールで通知する承認システムを実装した」といった形で、自分が関わった具体的な機能とその成果を記述する。ただ「承認システムを実装した」と書くよりも、それがユーザーにとってどのような変化をもたらしたのかを伝えることで、より実践的なスキルがあることを示せる。

3. どんな証拠があるのか？ あなたの主張が事実であることを裏付ける証拠を提示する。これには、自動テストのコード、デプロイ済みのライブデモ、詳細なREADMEファイル、あるいは具体的な測定可能な結果などが含まれる。採用担当者は、これらの証拠を通して、あなたが記述した内容を検証できる。例えば、「ダブルブッキングや40時間以上の残業制限といったスケジューリングルールをカバーする41の自動テストを作成した」と記述すれば、具体的なテストの数と、それがカバーする業務ロジックの複雑さを提示でき、あなたの信頼性と技術力を証明できる。

これらの3つの質問すべてに答えられない箇条書きは、単なる技術のリストに過ぎない場合が多い。

具体的な例を挙げてみよう。仮に、カフェのスタッフがシフトを交換するための「ShiftSwap」というアプリを構築したとする。その履歴書には、以下のような情報が書かれているとしよう。

• カフェの12人のスタッフがWhatsAppグループでシフト交換しており、リクエストが頻繁に見失われていた。
• Next.jsとPostgreSQLを使ってアプリを構築し、Vercelにデプロイした。
• マネージャーがワンクリックでシフト交換を承認でき、承認すると両方のスタッフにメールが届く。
• ダブルブッキングや40時間以上の残業制限など、シフトルールをカバーする41のテストを作成した。
• このアプリは3ヶ月間カフェで使用されている。

この情報を基に、先述の3つの質問に答える形で履歴書の記述を改善できる。

• 改善前：「React、Node.js、PostgreSQLを使ってフルスタックWebアプリを構築した。」

• 改善後：「12人のカフェチームのWhatsAppグループでのシフト管理問題を解決するため、シフト交換アプリ（Next.js, PostgreSQL）を構築した。」 この記述では、具体的な問題と対象ユーザーが明確になり、採用担当者はプロジェクトの目的を瞬時に理解できる。使用技術は補足情報として括弧内に移動する。

• 改善前：「承認システムを実装した。」

• 改善後：「スタッフ間でシフトが失われることを防ぐため、マネージャーがワンクリックで承認し、両スタッフにメールで確認通知を送るシステムを追加した。」 機能がユーザーにどのような恩恵をもたらしたのか、その「変化」に焦点を当てることで、単なる機能実装以上の価値を示せる。

• 改善前：「テストを作成した。」

• 改善後：「ダブルブッキングや40時間以上の残業制限といったスケジューリングルールをカバーする41の自動テストを作成し、堅牢性を確保した。」 具体的なテストの数と、それがカバーする業務ルールを示すことで、あなたのプロジェクトへの理解度と品質への意識をアピールできる。

これらの改善された記述は、すべてプロジェクトのREADMEファイルやリポジトリ内に存在する情報に基づいている。

もし、構築したサイドプロジェクトに実際のユーザーや具体的な数値データがない場合でも、エンジニアリングの側面を詳細に記述することで、あなたの能力を示すことができる。例えば、以下のように記述できる。

• 「公開デモとセットアップ手順書を含むシフト交換プロトタイプ（Next.js, PostgreSQL）を構築し、デプロイした。」 ユーザーがいなくても、動くプロトタイプが存在し、それを試せる環境があることを示せる。

• 「ダブルブッキングや残業制限を防ぐためのスケジューリングルールを設計し、その機能を41の自動テストで検証した。」 設計思想や品質保証への取り組みを具体的に示せる。

• 「シフト交換リクエストに対する楽観的UI更新を選択し、競合する編集処理とのトレードオフについてREADMEに記述した。」 技術的な選択とその理由、メリット・デメリットを理解し、ドキュメントとして残す能力があることを示せる。

このように、「効率を40%向上させた」といった検証が難しい数値データがなくても、採用担当者はリポジトリを開いてあなたの記述の信憑性を確認できる。検証可能な情報に基づいた記述は、信憑性の低い大げさな数値よりもはるかに信頼される。

履歴書にプロジェクトを記述する際は、以下の点を確認すると良いだろう。 各箇条書きが問題または結果を示し、技術スタックは副次的な情報となっているか。 もしプロジェクトに他の貢献者がいる場合、自分が担当した部分が明確に記述されているか。 記載されたすべての主張が、リポジトリ、README、またはライブデモで確認可能か。 数値データがある場合、それが裏付けられているか。 リポジトリへのリンクは、ログインしていないブラウザからでも機能するか。 READMEの最初の3行でプロジェクトの概要が簡潔に説明されているか。

これらの点を踏まえ、あなたのGitHubプロジェクトを魅力的な履歴書の記述に変えることで、採用担当者に自身のスキルと貢献度を効果的にアピールできるだろう。