IT就活で見られるGitHubの整え方｜大学生向け

「GitHubって、草が多ければ評価される？」

結論から言うと、採用側が短時間で見たいのは草の量だけではありません。何を作ったか、なぜその技術を使い、ユーザーの声で何を変えたかが迷わず読めることのほうが大切です。

この記事では、私が開発した歩行促進Webアプリterritory_game_webを例に、大学生がIT就活へ出すGitHubとREADMEの整え方をまとめます。実装ファイルを確認し、実際の技術構成、GPSの例外処理、面積計算、友人10人のテストをもとにしています。

READMEの基本的な役割と掲載場所は、GitHub公式のREADME解説でも確認できます。この記事では、その基本へ就活で説明しやすかった実例を加えています。

READMEの最初の3行で作品を説明する
実際の技術構成
コードを読む入口になるファイル
採用側が確認しやすいREADMEの順番
そのまま使えるREADME冒頭例
技術課題は「困った」で終わらせない
友人の意見を改善前後で見せる
コミットメッセージにも判断を残す
スクリーンショットで見せたい画面
Google Maps APIキーの扱い
公開前に確認する情報
提出前チェックリスト
まとめ：GitHubで見せるのは技術名より判断のつながり
次に読む記事

READMEの最初の3行で作品を説明する

territory_game_webは、スマートフォンの位置情報を使って三角形の陣地を作り、他プレイヤーと陣地面積を競う歩行促進Webアプリです。地図上の3地点から陣地を作成し、重複を除いた総陣地面積でランキングを決めます。友人10人のテストを受け、ランキングの計算方法と計測セッションの復帰機能を改善しました。

このあとに、3地点と三角形が表示された画面、ランキング画面、スマホで計測している画面を置くと、読む側はアプリの全体像をつかみやすくなります。

実際の技術構成

分類	使用技術
フロントエンド	HTML / CSS / Vanilla JavaScript
地図表示	Google Maps JavaScript API
位置情報取得	ブラウザの Geolocation API
図形・面積処理	Turf.js / Shapely
バックエンド	Python Flask
API	REST API / JSON
データベース	SQLite
ORM	SQLAlchemy
サーバー連携	CGI経由でFlask APIを実行
セッション保存	localStorage

Google Maps JavaScript APIは、地図、現在地、マーカー、ポリゴンの表示に使っています。GPS取得はGoogle Mapsの機能ではなく、navigator.geolocationを使っています。READMEでは、この2つを「地図表示」と「位置情報取得」に分けて書くと正確です。

コードを読む入口になるファイル

index.html：Turf.jsとGoogle Maps JavaScript APIの読み込み、画面構造
src/js/app_online_checkpoint.js：地図描画、GPS監視、歩行判定、セッション復帰、ランキング表示
src/js/config.js：APIの接続先などの設定
backend/server.py：Flask API、SQLAlchemy、Shapelyによる面積計算
backend/api.py：CGIからFlaskアプリを実行する入口
backend/requirements.txt：Python依存関係

READMEから代表的なファイルへ案内すると、採用側はすべてのコードを探し回らずに済みます。行番号は変更でずれるため、GitHubの固定リンクを使う場合はコミットを指定したURLにします。

採用側が確認しやすいREADMEの順番

アプリ名と一言で分かる説明
解決したい課題と遊び方
画面のスクリーンショットまたは短いデモ
友人10人のテストで分かったこと
改善前と改善後
技術構成
主要ファイルと責務
起動方法
セキュリティ上の注意
今後の改善点

そのまま使えるREADME冒頭例

# territory_game_web

スマートフォンの位置情報を使い、地図上の3地点から三角形の陣地を作る歩行促進Webアプリです。
プレイヤーは、現在保持している陣地の重複を除いた総面積で順位を競います。

## 主な改善
- 友人10人のテストを実施
- 陣地数ランキングを総陣地面積ランキングへ変更
- Shapelyで同一ユーザーの重複面積を除外
- localStorageで計測セッションを復元
- 復帰直後のGPS点を移動距離へ加算しない

数値を盛らず、実際に行った改善だけを並べています。満足度や継続率を測っていない場合は書かず、次の検証項目として残します。

技術課題は「困った」で終わらせない

territory_game_webで難しかったのは、乗り物を使うプレイを避けるための歩行判定です。WebのGPSにはずれがあり、精度や位置ジャンプをフィルタリングしても、地図上の見え方に違和感が残る場面がありました。

そこで判定精度を追うだけでなく、描画システムと地図表示の大きさも工夫しました。READMEでは「GPS精度が悪かった」で止めず、制約に対して判定と表示の両方を変えたと書きます。

友人の意見を改善前後で見せる

スマホを閉じたときの計測

改善前：画面を切り替えたりブラウザを閉じたりすると、計測中の状態が消えてしまいました。

改善後：計測セッションをlocalStorageへ保存し、同じユーザーが開いた場合に拠点、チェックポイント、GPS点などを復元できるようにしました。

復帰直後のGPS飛び

追加で見つけた課題：復帰前の地点と復帰後の地点を直線でつなぐと、ブラウザを閉じていた間の移動まで距離へ入ってしまいます。

対応：resumePendingを使い、復帰直後のGPS点は前回地点とつながず、閉じていた区間を距離へ加算しないようにしました。ユーザーの要望を実装したあとに生まれる例外ケースまで考えた部分です。

コミットメッセージにも判断を残す

ランキングを重複除外後の総陣地面積へ変更
Shapelyでユーザー別ポリゴンを統合
計測セッションをlocalStorageへ保存
同一ユーザーの進行中セッションを復元
復帰直後のGPS点を距離計算から除外
GPS誤差が目立ちにくい地図表示へ調整

fixやupdateだけより、何を変えたかが読めるコミットは面接前の振り返りにも使えます。過去の履歴を無理に作り直さず、今後の変更から整えれば十分です。

スクリーンショットで見せたい画面

計測開始前の地図
3地点と三角形の陣地が表示された状態
総陣地面積ランキング
計測セッション復帰後の通知
スマホで実際に操作している画面

位置情報を扱うアプリなので、画像には自宅、友人の位置、ユーザー名などを映さないようにします。公開して問題のない地点やテスト用データで撮影します。

Google Maps APIキーの扱い

Maps JavaScript APIのキーはブラウザから読み込むため、ページのソース上で見える構成になります。だからこそ、Google Cloud側でHTTPリファラーを公開ドメインへ制限し、使用できるAPIも必要なものだけに絞ることが重要です。サーバー用の秘密鍵や他サービスのトークンと同じ扱いで無制限に置かないようにします。

制限を変更する前は利用状況も確認してください。具体的な設定と注意点は、Google Maps PlatformのAPIセキュリティガイドにまとまっています。

公開前に確認する情報

Google Maps APIキーへドメインとAPIの制限が設定されている
データベース接続情報や秘密鍵が入っていない
本番ユーザーの位置情報がSQLiteや画像に残っていない
territories.dbを公開リポジトリへ含める必要があるか見直した
環境別の接続先を設定ファイルへ分離した
READMEの起動手順を別の環境で確認した

提出前チェックリスト

READMEの最初だけでアプリの目的と遊び方が分かる
Google MapsとGeolocation APIの役割を分けて説明した
Turf.jsとShapelyをどこで使うか書いた
友人10人の意見と改善結果を事実の範囲で載せた
総面積ランキングと重複除外の意味が分かる
セッション復帰とGPS例外処理を説明した
主要ファイルへのリンクがある
位置情報とAPIキーの公開範囲を確認した
スマホからREADMEとデモを確認した

まとめ：GitHubで見せるのは技術名より判断のつながり

territory_game_webには、Vanilla JavaScript、Google Maps、Geolocation API、Turf.js、Flask、Shapely、SQLiteなど複数の技術があります。ただ並べるだけではなく、GPSを取得し、地図へ描き、図形を計算し、サーバーで重複を除き、ランキングへ返す流れで説明すると設計が伝わります。

さらに、友人の意見からランキングと計測復帰を変え、復帰直後のGPS飛びまで処理した経験があります。GitHubをコードの倉庫ではなく、ユーザーの声をどう実装へ変えたかが追える資料にすると、面接で話を広げやすくなります。

IT就活で見られるGitHubの整え方｜大学生向けチェックリスト