「個人開発って、ガクチカにしていいの？」
もちろん使えます。むしろ、自分で課題を決め、技術の限界にぶつかり、ユーザーの意見から仕様を変えた経験は、IT就活で話しやすい題材です。完成した機能の数より、「なぜその判断をしたか」が伝わると強くなります。
私が開発したterritory_game_webは、スマートフォンの位置情報を使う歩行促進Webアプリです。地図上の3地点で三角形の陣地を作り、他プレイヤーと陣地面積を競います。友人10人にテストを頼み、意見を受けてランキングや計測復帰の仕様を変更しました。
この記事は本人の実体験と実装コードを確認して作成しています。歩行判定、GPS誤差への対応、localStorageによる計測復帰、Shapelyによる重複面積の除外をコード上でも確認しました。未計測の満足度や継続率は成果として足していません。
territory_game_webはどんなアプリか
ルールはシンプルです。スマホを持って移動し、地図上で3地点を取ると三角形の陣地ができます。獲得した陣地の面積をランキングで競うことで、「もう少し歩いてみよう」という動機をゲームへ変えました。
- 目的：歩くきっかけを作る
- 操作：位置情報を使って地図上の3地点を取る
- ゲーム性：3点からできる三角形を陣地にする
- 競争：現在保持する陣地の総面積で順位を決める
- テスト：友人10人にスマートフォンで試してもらう
使用した技術
- フロントエンド：HTML / CSS / Vanilla JavaScript
- 地図・位置情報：Google Maps JavaScript API / Geolocation API
- 図形処理：Turf.js / Shapely
- バックエンド：Python Flask / REST API / JSON
- データ：SQLite / SQLAlchemy
- サーバー連携：CGI経由でFlask APIを実行
- 端末内保存：localStorage
地図の表示やマーカー、ポリゴンの描画にはGoogle Maps JavaScript APIを使っています。一方、GPSの取得はGoogle Mapsではなく、ブラウザ標準のnavigator.geolocationです。ここを分けて説明すると、面接でも技術構成が伝わりやすくなります。
一番難しかったのは歩行判定の精度
このアプリでは、乗り物で移動して陣地だけを広げてほしくありませんでした。歩いて遊ぶことが前提なので、移動が本当に歩行なのかをどう判定するかが重要でした。
GPSの精度、位置の急なジャンプ、速度などを見ながら判定を調整しました。ただ、WebのGeolocation APIで得られる位置にはずれがあり、判定ロジックだけを追っても、地図上の移動が不自然に見える場面が残りました。
GPSを完璧にするのではなく、体験全体で吸収した
そこで、描画システムと地図表示の大きさも工夫しました。GPS誤差そのものをゼロにするのではなく、誤差が目立ちすぎない描画と縮尺を考え、ゲームとして状況を理解しやすい見せ方へ寄せました。
これは精度を諦めた話ではありません。位置精度のフィルタリングやジャンプ判定を行いながら、利用環境の限界をUI側でも受け止めた判断です。実装だけで解決しきれない制約に対して、プロダクト全体で解決策を考えた経験として話せます。
友人の意見から変えた4つの仕様
1. 陣地数ではなく、実際の支配面積で競う
友人から「ランキングが何を基準にしているのか分かりにくい。陣地の数より、実際にどれくらいの範囲を取っているかで競いたい」という意見が出ました。そこでランキングを総陣地面積ランキングへ変更しました。
さらに、同じプレイヤーの陣地が重なっている場合、その重なりを二重に数えないようにしました。サーバー側でShapelyのunary_unionを使ってポリゴンを統合し、実際に保持している範囲の面積を計算してから順位を決めています。
2. スマホを閉じても計測へ戻れるようにする
「スマホを閉じたり、画面を切り替えたりすると計測が消えるのが不便」という意見を受け、進行中の計測セッションをlocalStorageへ保存する機能を追加しました。同じユーザーが再度アプリを開いた場合は、拠点、チェックポイント、移動データなどを復元して途中から再開できます。
3. 閉じていた間のGPSを距離へ足さない
復帰だけを実装すると、別の問題が起きます。ブラウザを閉じている間はGPSを継続取得できないため、最後の地点と復帰後の地点を直線で結ぶと、実際には計測していない距離まで加算されます。
そこで復帰直後はresumePendingという状態を持たせ、最初のGPS点を前回地点と結ばないようにしました。閉じていた区間の移動距離は加算せず、復帰後の点から計測を再開する仕様です。
4. ランキング表示とサーバー計算をそろえる
ランキング画面で重なり込みの累計を表示すると、見た目の支配範囲と数値がずれます。そこで、フロント側の表示だけを変えるのではなく、Flask API側で重複を除いた面積を返すようにしました。UIとランキングの意味が同じになるよう、計算の責任をサーバー側へ置いています。
ユーザーの一言を、そのまま小さなUI修正で終わらせず、ランキングの定義、図形計算、セッション保存、GPS復帰時の例外処理まで設計し直した。この部分がterritory_game_webのガクチカで最も強いポイントです。
ガクチカは6つの順番で組み立てる
- 結論：歩行促進Webアプリを個人開発した
- 仕組み：3地点で三角形の陣地を作り、面積を競う
- 課題：歩行判定、GPS誤差、画面を閉じたときの計測
- 行動：友人10人に試してもらい、意見を整理した
- 改善：重複除外ランキングとセッション復帰を実装した
- 学び：技術の限界と利用者の感覚を両方見て仕様を決める
面接で使える回答例
学生時代に力を入れたのは、territory_game_webという歩行促進Webアプリの個人開発です。スマートフォンの位置情報を使って3地点を取り、三角形の陣地面積を競う仕組みにしました。乗り物での移動を避けるため歩行判定を調整しましたが、WebのGPS誤差が目立つ課題があり、判定だけでなく描画と地図表示も工夫しました。友人10人にテストを頼んだところ、陣地数より実際の支配面積で競いたいという意見があり、Shapelyで重複を除いた総面積ランキングへ変更しました。また、画面を閉じると計測が消える問題にはlocalStorageで復帰機能を追加し、閉じていた間の距離は加算しないようにしました。この経験から、機能を作るだけでなく、利用者の意見と技術的な制約を一緒に考えて仕様へ落とす大切さを学びました。
丸暗記は不要です。「歩行促進」「GPS」「10人テスト」「総面積ランキング」「計測復帰」の5語だけ覚えると、自分の言葉で話しやすくなります。
この内容を実際の新卒面接でどう伝え、どこを深掘りされたかは、ソフトウェア系の新卒面接で伝えた3つにまとめています。地図ゲームの説明から、面接官の「面白い」「やってみたい」という反応へ会話が広がった流れも紹介しています。
深掘りされたときの短い答え
- どんなアプリ？ 位置情報で三角形の陣地を作り、面積を競う歩行促進Webアプリです。
- 一番難しかったことは？ 乗り物を除外したい一方で、WebのGPSには誤差があることです。
- ユーザーの声で何を変えた？ 総面積ランキングと計測セッションの復帰機能です。
- 重複面積はどう処理した？ Flask側でShapelyを使い、同じ人のポリゴンを統合してから面積を計算しました。
- 復帰後のGPS飛びは？ 最初の点を前回地点とつながず、閉じていた間の距離を加算しない仕様にしました。
- 何が楽しかった？ 自分のアイデアを動かし、人の意見でさらに良くしていく過程です。
「楽しかった」は消さなくていい
歩行判定やGPSのずれに苦戦し、友人の意見からサーバー計算まで変えています。それでも楽しかったと言えるなら、「課題があっても作り続けられる」という説得力があります。感想だけで終わらせず、苦戦と改善を一緒に話すのがコツです。
GitHubとREADMEにも同じ流れを載せる
READMEでは、アプリの目的、遊び方、技術構成、歩行判定の課題、友人の意見、改善した実装の順で載せます。詳しい構成は、IT就活で見られるGitHubの整え方でまとめています。
まとめ：ユーザーの声を仕様へ変えた経験を話す
territory_game_webの強みは、GPSを使うアプリを完成させたことだけではありません。友人10人に使ってもらい、ランキングの意味やスマホでの使いにくさを受け取り、Shapelyの面積統合、localStorageの復帰、復帰直後のGPS例外処理まで実装したことです。
ガクチカでは「すごいアプリを作った」と盛る必要はありません。何を目指し、誰の意見を受け、どのコードをどう変えたかを話すほうが、エンジニアとしての信頼につながります。
この記事のガクチカで使ったアプリの技術面を詳しく知りたい人は、2週間で作った歩行促進Webアプリの技術構成も確認してください。Google Maps JavaScript API、Geolocation API、Flask、SQLiteをどう選び、GPS精度の悪さへどう対応したかをまとめています。
コメント