個人開発の企画は、「ダイエットのために楽しく歩けるアプリが欲しい」と思ったことから始まりました。歩数を増やしたいのに、歩く理由がないと続かない。そこで、歩いた結果がゲームの中で価値になるアプリを作ろうと考えました。
ポケモンGOのように外へ出るきっかけになるゲームはありましたが、私はポケモンが特別好きだったわけではなく、立ち止まってゲームに夢中になるとゲーム自体が中心になってしまう感覚がありました。だから「ゲームのために歩く」より、「歩くことが主役で、少しゲームとして楽しい」形を目指しました。
2週間・一人で作った歩行促進Webアプリ
作ったのは、スマートフォンの位置情報を使って地図上に3つのピンを置き、できた三角形の面積で陣地を競うWebアプリです。自分が歩いた場所に意味が生まれ、ただの移動が少しだけゲームになる。そんな体験を形にしたくて、2週間で一人開発しました。
公開URLはこの記事に掲載していません。試作版は、ユーザー認証、APIの更新権限、位置情報の保護、Google Maps APIキーの制限を公開運用向けに設計し直す必要があるためです。ここでは架空データの画面と、実装から学んだ技術構成だけを紹介します。
個人開発では、最初から大きなサービスを作ろうとすると止まりやすいです。今回は「位置情報を取る」「地図にピンを置く」「三角形を描く」「面積で競う」という最小の流れを先に決めました。機能を増やすより、歩く体験が成立するところまで早く作ることを優先しました。
技術選定の条件は「簡単に触れて、コストを抑えられること」
一人で短期間に作るため、技術は新しくて難しいものより、情報を探しやすく、まずは低コストで試せるものを選びました。個人開発では、技術の流行よりも、困ったときに自分で直せるか、完成まで持っていけるかのほうが大事だと感じています。
- フロントエンド：HTML / CSS / Vanilla JavaScript
- 地図表示：Google Maps JavaScript API
- 位置情報：ブラウザのGeolocation API
- 図形・面積処理：Turf.js、Shapely
- バックエンド：Python Flask、REST API / JSON
- データベース：SQLite、SQLAlchemy
- 途中状態の保存：localStorage
全体の流れは次の図の通りです。位置取得と地図表示はブラウザ側、陣地の保存と重複面積の集計はサーバー側に分けました。
WebアプリとJavaScriptを選んだ理由
歩くときに使うなら、スマートフォンで地図を見られることが必要でした。Webアプリなら、ブラウザで位置情報を扱いながら地図を表示でき、まずは小さく試せます。フロントエンドはVanilla JavaScriptにして、地図の描画や位置情報の取得がどこで動いているかを追いやすくしました。
地図の表示にはGoogle Maps JavaScript APIを使い、現在地、マーカー、陣地のポリゴンを描画しました。位置情報そのものはGoogle Maps APIではなく、ブラウザ標準のGeolocation APIで取得しています。役割を分けて考えたことで、地図表示とGPS取得の問題を切り分けやすくなりました。
一番苦労したのは、歩行とGPS精度だった
このアプリでは、乗り物を使ってほしくありませんでした。歩いたことで陣地が作られるゲームにしたかったため、歩行判定の精度にはかなりこだわりました。ただしWebのGPSは、場所や端末によって位置が飛ぶことがあります。地図上では少しのズレでも、不自然な移動や大きな三角形に見えてしまいます。
そこで、GPSが完全に正確になる前提ではなく、誤差が目立ちにくい描画と地図の見せ方を考えました。地図の表示範囲やポリゴンの描画を工夫し、位置情報のズレで体験が壊れにくい形に寄せました。精度問題を技術だけで解こうとせず、画面上の見え方も含めて対処したのが学びです。
友人10人のテストで変えたこと
完成前に友人10人へテストを頼みました。自分だけで使っていると気づかない「何を競っているか分かりにくい」「途中で閉じると困る」という意見が出たため、フィードバックを元に仕様を変えました。作ること自体も楽しかったですが、使った人の反応でアプリが少しずつ変わる感覚が特に面白かったです。
- ランキングを陣地の数ではなく、重なりを除いた総陣地面積で競う形へ変更
- 途中状態をlocalStorageへ保存し、アプリを開き直しても同じユーザーなら復帰できるように変更
- 復帰直後のGPS点は前回地点と直線でつなげず、閉じていた間の移動距離を加算しない仕様へ変更
- サーバー側でShapelyを使い、重なった陣地を統合して面積を計算するように変更
技術構成は、機能ごとに必要なものを選ぶ
このアプリでは、地図を出す、現在地を取る、三角形を作る、面積を計算する、ランキングを保存する、という機能ごとに必要な技術を選びました。フロントエンドだけで完結させず、重複しない面積の計算はサーバー側のShapelyへ任せています。全部を一つの技術で片づけようとしないことも、個人開発では大切でした。
2週間の個人開発で学んだこと
企画は「自分が少し困っていること」から始めると、機能の優先順位を決めやすくなります。ダイエットのために歩きたい、でも歩く価値が欲しい。この一文があったので、地図、位置情報、陣地、ランキングという必要な機能に絞れました。
また、技術選定は完璧な構成を探す時間ではなく、完成へ近づく構成を選ぶ時間だと思います。簡単に触れ、コストを抑えて試し、友人に使ってもらう。個人開発を続けるなら、この順番のほうが次の改善につながりやすいです。
就活で個人開発を話すときに使えたこと
この経験は、技術名を並べるよりも「なぜ作ったか」「どこで困ったか」「ユーザーの意見で何を変えたか」の順に話すと伝わりやすくなりました。ガクチカとして整理する方法は、個人開発をガクチカにする書き方で詳しくまとめています。GitHubを選考で見せる前に整えたい部分は、IT就活で見られるGitHubの整え方も参考にしてください。
面接本番で聞かれた「最も工夫したところ」「一番大変だったところ」への答え方と、地図ゲームの話から会話が広がった流れは、ソフトウェア系の新卒面接で伝えた3つで紹介しています。
このWebアプリを作ったPCはMacBook Air M2・16GBです。4年間の開発、バッテリー、ローカルAI、ゲームまで含めた使用感は、大学生エンジニアがMacBook Air M2を4年使ったレビューにまとめています。
技術構成をそのまま並べるだけでは、面接で工夫が伝わりにくいことがあります。開発経験を回答へ変える流れは、IT就活の面接で実際に聞かれた質問5選で整理しています。課題、工夫、結果の順で話せるようにすると説明しやすくなりました。
まとめ
2週間の一人開発で、歩くことを中心にした陣取りゲームを作りました。技術は簡単に触れ、コストを抑えて試せることを基準に選び、GPSのズレや友人からの意見を受けて改善しました。個人開発は、すごい技術を使うことより、自分の課題を小さな体験に変え、使った人の声で直していくことに面白さがあると思います。
技術を選ぶ前の企画、公開範囲、改善の回し方は、初心者でも挫折しにくい1人開発を続ける手順に分けて整理しています。
コメント