1人開発は、コードを書く前より「次に何をすればいいか分からない時間」で止まりやすいです。企画、画面、技術、テスト、公開まで、全部を1人で決めるからです。
私は大学生のとき、歩くことを楽しくする地図ゲームを1人で開発しました。期間は約2週間。スマートフォンのGPSを使い、地図上に3地点を置いて三角形の陣地を作り、面積で競うWebアプリです。完成後は友人10人に試してもらいました。
この記事では、そのときの経験をもとに、初心者が企画から公開まで進むための6ステップをまとめます。立派な設計書を完成させる話ではなく、まず人に触ってもらえる状態まで持っていく方法です。
先に結論：完成の基準を小さく決める
最初の完成条件は、次の3つで十分です。
- 中心となる体験が最初から最後まで動く
- 自分以外の人が説明なしで一度は使える
- 不具合や改善点を次の作業として残せる
「思いついた機能を全部入れる」ではなく、「誰かに試してもらえる最小版を出す」が最初のゴールです。私の地図ゲームなら、現在地を取得し、3地点を記録し、三角形と面積を表示できることが中心でした。
ステップ1：自分が困った場面から企画する
私はダイエットのために、歩くこと自体が楽しくなるアプリを探していました。位置情報ゲームはあったものの、立ち止まって遊ぶ時間が長くなったり、ゲーム内コンテンツが目的になったりして、歩くことが中心ではないと感じました。
そこで考えたのが、「歩いた範囲そのものに価値がつくゲーム」です。企画を考えるときは、次の1文を作ると迷いにくくなります。
誰が、どんな場面で困っていて、使った後に何が変わるか。
今回なら「楽しく歩きたい人が、歩いた範囲を陣地として残し、もう少し歩きたくなる」です。自分が本当に困った場面から始めると、途中で仕様に迷ったときも目的へ戻れます。
ステップ2：中心機能を1本に絞る
次は、企画を最小の操作へ分解します。私が最初に必要だと考えた流れは次の通りです。
- スマートフォンで現在地を取得する
- 地図上で3地点を記録する
- 3地点を結んだ三角形を描く
- 陣地の面積を計算する
- 他の利用者と面積で競う
着せ替え、通知、実績、細かなプロフィールなどは、中心の体験が成立してから考えれば大丈夫です。機能を思いついたら「これがなくても、歩いて陣地を作る体験は成立するか」と問い、成立するなら後回しへ移します。
ステップ3：技術は無料・簡単・公開できるで選ぶ
1人開発では、流行している技術より、自分が期限内に動かせる技術のほうが大切です。私は「なるべく簡単で、無料に近い形で利用できること」を条件に選びました。
地図表示にはGoogle Maps JavaScript API、現在地の取得にはブラウザのGeolocation API、画面はHTML・CSS・Vanilla JavaScript、サーバー側はPython FlaskとSQLiteを使いました。面積処理にはTurf.jsとShapelyを利用しています。
技術選定では、次の4点を確認します。
- 中心機能を実装できるか
- 自分が調べながら扱えるか
- 公開先で動かせるか
- 料金やAPIの利用制限を把握できているか
実際の構成と役割は、2週間で作った歩行促進Webアプリの技術構成で詳しく整理しています。開発環境をこれから選ぶ場合は、個人開発を始めるためのツール・サービスも参考にしてください。
ステップ4：最初から最後まで動く道を先に作る
画面を1つずつ完璧にするより、現在地取得から面積表示までを一度つなげます。見た目が仮でも、データが一時的でも構いません。全体がつながると、どこが本当に難しいかが見えてきます。
この開発で特に大変だったのは、ブラウザのGPS精度です。乗り物を使わず歩いてほしいゲームなのに、位置情報が飛ぶと、実際には歩いていない距離まで増えたように見えます。
GPSそのものを完全に正確にするのは難しかったため、取得精度だけで粘り続けず、地図の表示範囲や陣地の描画方法も調整しました。制約を消せないときは、利用者が違和感を持ちにくい見せ方まで含めて設計する必要があります。
ステップ5：自分以外の人に触ってもらう
自分だけで動作確認すると、作り手には分かる操作を「誰でも分かる」と思い込みやすいです。私は友人10人に実際に試してもらいました。テストを頼むときは、「どうだった？」だけで終わらせず、次の点を見ます。
- 説明なしで最初の操作を始められたか
- 途中で止まった場所はどこか
- 何を基準に競っていると理解したか
- スマートフォンを閉じた後も続けたいと思ったか
友人からは「陣地の数ではなく、実際にどれだけ広い範囲を取ったかで競いたい」「画面を閉じると計測が消えるのが不便」といった意見が出ました。作者の頭の中では補えていた部分が、使う側にはきちんと不便として見えていました。
ステップ6：影響の大きい意見から直して公開する
意見を全部直そうとすると、今度は公開できなくなります。私は「中心の体験が伝わるか」「計測結果を信頼できるか」「続けて使えるか」に関わる変更を優先しました。
- ランキングを陣地数ではなく総陣地面積へ変更
- 重なった自分の陣地は重複分を除いて面積を計算
- 計測中の状態をlocalStorageへ保存し、再度開いたときに復帰
- 閉じていた間のGPS点を直線で結ばず、不自然な距離を加算しない
このように、感想をそのまま機能へ変えるのではなく、「なぜ困ったのか」を一段掘ってから直します。ランキングの意見なら、問題は数字の見せ方ではなく、競争の基準と実際の支配範囲がずれていたことでした。
2週間で進めるなら作業をどう分けるか
同じ規模のWebアプリを今から2週間で作るなら、私は次のように分けます。これは実際の日ごとの記録ではなく、今回の反省を含めた進め方の例です。
| 期間 | やること | 終わりの基準 |
|---|---|---|
| 1〜2日目 | 課題と中心機能を決める | 操作の流れを1枚で説明できる |
| 3〜5日目 | 最初から最後まで仮実装する | 中心の体験が一度動く |
| 6〜8日目 | GPS・保存・面積など難所を直す | 致命的な誤動作が減る |
| 9〜10日目 | スマートフォンで使いやすくする | 説明なしで操作できる |
| 11〜12日目 | 友人に試してもらう | 困った場所を記録できる |
| 13〜14日目 | 重要な意見を直して公開する | 公開URLから使える |
1人開発で止まりやすかったポイント
一番危ないのは、解けない問題を全部「技術力不足」と考えることです。GPSのように、Webブラウザや端末側の制約が原因で完全には解消できない問題もあります。
調べてもすぐ直らない場合は、次の順番で考えます。
- 中心機能を壊す重大な問題か
- 判定条件やデータ処理で軽減できるか
- 画面表示や説明で違和感を減らせるか
- 制約として明示して公開できるか
重大な誤作動や個人情報の危険が残るなら公開を止めます。一方で、完全ではなくても利用者が理解でき、安全に試せる状態なら、小さく公開して改善を続けられます。
まとめ：公開してから見えたことが一番多かった
1人開発では、最初から正解の仕様を作る必要はありません。自分の困りごとを1文にし、中心機能を絞り、最初から最後まで動かし、自分以外の人に触ってもらう。この順番なら、次の作業を決めやすくなります。
私の場合、友人10人に使ってもらったことで、ランキングの基準やセッション復帰など、自分だけでは気づかなかった改善につながりました。開発内容を就活でどう伝えたかは、個人開発をガクチカにする書き方で具体的に紹介しています。
コメント