個人開発では、コードを書き始める前と、完成したと思った後にも多くの作業があります。時間を取られるのは、たいてい実装以外でした。全体を課題、仕様、試作、実装、確認、公開、改善の七段階に分けると、今やることを選びやすくなります。この記事では、七段階の中身、技術より先に決めること、完成条件の書き方、一人だと止まりやすい場所、そして記録を頭の外へ置く理由を、3つのアプリを作りながら分かったことから書きます。
アプリ開発の七段階。実装はそのうちの一つだけ
七つのうち、実装は一つです。作り始める前に3つ、作ったあとに3つあります。ここを見落とすと、コードが書けた時点で終わりだと思ってしまいます。
実際には、5番と6番でいちばん時間を使いました。権限、課金、ストアの情報、法務のページ。どれも作る作業とは種類が違うので、実装の感覚で見積もると足りません。
順番どおりに一度で進むわけでもありません。却下されて1番に戻ることもあります。私はそれを実際に経験しました（後述）。
段階を分けておく効用は、戻る先がはっきりすることです。うまくいかないときに「最初からやり直す」ではなく、「2番へ戻る」と言えます。戻る距離が短いほど、やり直しが軽くなります。
01 課題を決める。対象と場面を一つに
対象ユーザーと、今困っている場面を一つ選びます。
02 仕様へ落とす。画面と例外を書く
画面、操作、保存するデータ、エラー時の動きを書きます。
03 小さく試作する。価値の流れだけ
価値を確かめる最小の流れだけを作ります。
04 実装する。完了条件と一緒に進める
機能を一つずつ、完了条件と一緒に進めます。
05 完成品を確認する。コード以外も見る
コードだけでなく、ビルド、権限、課金、ストア情報を見ます。
06 公開する。審査用の情報を揃える
審査用情報とサポート、法務ページを揃えて提出します。
07 改善する。次の仮説を一つ決める
利用状況、問い合わせ、レビューから次の仮説を決めます。
最初に決めるのは技術より課題。一文で書けるか
FlutterかSwiftかを先に決めても、作る価値が曖昧だと機能が増え続けます。「誰が、どんな場面で、今より何を楽にするか」を一文にします。技術は、その条件を満たすために選びます。
一文で書けないときは、まだ決まっていません。⚠️ 書けないまま進むと、実装の途中で毎回そこに戻ることになります。判断の基準が無いので、機能を足すか削るかが決まりません。
私の場合、ここを曖昧にしたまま進めて、審査で「似たアプリはもう十分ある」と言われたことがあります。機能を削ったり説明を書き換えたりしても通らず、最終的にアプリの主語そのものを変えました。人を探すのではなく、近所の予定を探す形にした。経緯はApp Storeに「似たアプリはもう十分ある」と言われて、アプリの主語を変えたに書いています。
このとき分かったのは、一文が書けていないことは、外から見ても分かるということでした。審査する側からは、何が新しいのか判断できなかったわけです。
どちらの端末から出すかという判断は、iOSとAndroidどちらから作る？個人開発で見る六つの判断材料に分けて書きました。これも、課題が決まってから読むほうが判断しやすいと思います。技術の選択は、満たしたい条件が決まってからのほうが比べやすくなります。
一文を書くときのコツは、「誰が」を狭くすることでした。広く書くほど当たりそうに見えますが、判断の基準としては弱くなります。最初の対象を一人に絞っても、作るものは変わりません。
完成条件を先に書く。五つ通れば出せる状態
「完成」の定義を後回しにすると、いつまでも終わりません。先に書いておくと、そこへ向かって削れます。
五つとも、機械で確かめられるか、画面を開けば分かるものにしてあります。「品質が高い」のような書き方だと、判断できません。
この五つに入れていないものもあります。デザインの完成度、機能の数、速さ。どれも大事ですが、無いと出せないものではありません。出せない条件と、良くする条件は分けて持っています。
- 主要な操作が最初から最後まで通る。
- 通信失敗・権限拒否・空データでも止まらない。
- プライバシーポリシーと問い合わせ先がある。
- ストア説明と実際の機能が一致する。
- 公開後に最低限の不具合を把握できる。
一人だと止まりやすい場所。実装の外に三つある
一人でやっていると、止まる場所が偏ります。実装で止まることは意外と少なく、その前後で止まります。3つ挙げます。
1つ目は、課題が決まらないまま作り始めたときです。前述のとおり、一文が書けていないと判断の基準がありません。機能を足すべきか削るべきかが毎回決まらず、そのうち手が止まります。
2つ目は、公開の直前です。ここが一番重いと思います。審査用の情報、スクリーンショット、プライバシーポリシー、問い合わせ先、法務のページ。どれも作る作業ではないので、実装の勢いのまま進めません。
私の場合、公開の手前で法務文書と実装を1条ずつ照らし合わせて、守れていない約束が見つかったことがあります。文面にあるのに実装に無いもの、実装にあるのに文面に無いもの。ここは作り直しになりました。
3つ目は、公開したあとです。出した時点で終わった気になりますが、実際には反応が来ます。私は返信アプリを出して、9日間で利用者が0人でした。そこで同じ領域のアプリを118本調べて、何を中心に置くかから見直しています。経緯は公開9日で利用者0人。118本を調べて、返信AIが選ばれにくい理由を見直したに書きました。
止まったときに効いたのは、段階のどこにいるかを確かめることでした。実装が進まないと感じても、原因が1番にあることは珍しくありません。止まる場所の分け方は個人開発が止まったとき。タスクを小さくする三つの分け方と順番にまとめています。
3つに共通しているのは、コードを書いていない時間だということです。一人だと、この時間を「進んでいない」と感じやすい。実際には七段階のうちの6つがここに入ります。
止まっているときに増やしがちなのが、調べる時間です。技術の記事を読む、他のアプリを触る。どれも無駄ではありませんが、止まっている場所が企画なら、技術を調べても動きません。
一人だからこそ、記録を頭の外へ置いておく
頭の中だけで仕様を持つと、数週間後の自分が別の判断をします。一人だと誰も指摘しないので、食い違ったまま進みます。
ClearDropでは仕様書、実装メモ、公開チェックを分けて管理しています。詳しくはひとりで3つのアプリを作る。仕様を「頭の中」に置かないためにやっていることにまとめました。
分けて置く理由は、読むタイミングが違うからです。仕様は実装の前、公開チェックは出す前。全部を1つにすると、必要なときに必要な部分だけを読めません。
もう一段強いのが、機械に守らせるやり方です。文章の注意書きは読み飛ばせますが、ビルドが落ちれば止まります。私は審査で使えなくなった語を、紹介ページに入るとビルドが失敗する形にしました。うっかり書いても本番には出ません。
失敗をそのつど手順へ変える考え方は個人開発で失敗を記録する六項目。却下と障害から残した形式に、機能を絞る段階はMVPとは？最初のアプリで機能を絞る方法と、外れたときの扱いにまとめています。
記録の置き方で一つ決めているのが、同じ内容を2か所に書かないことです。片方だけ古くなると、どちらが正しいか分からなくなります。写したくなったら、写す代わりに出どころを指すようにしています。
よくある疑問と、この記事が扱っていないこと
個人でアプリを作るには何から始めますか？
技術ではなく課題からです。「誰が、どんな場面で、今より何を楽にするか」を一文にしてください。書けないまま進むと、実装の途中で毎回そこに戻ることになります。判断の基準が無いので、機能を足すか削るかが決まりません。
一人でアプリを公開できますか？
できます。私は3つ公開しています。ただ、⚠️ 実装以外の作業が想像より多いです。審査用の情報、スクリーンショット、プライバシーポリシー、問い合わせ先、法務のページ。ここを実装の感覚で見積もると足りません。
どこで挫折しやすいですか？
課題が決まらないまま作り始めたとき、公開の直前、公開したあとの3つです。実装で止まることは意外と少ないと思います。進まないと感じても、原因が企画の段階にあることは珍しくありません。
審査に落ちたらどうしますか？
内容によります。私は「似たアプリはもう十分ある」という理由で落ちたことがありますが、機能を削っても説明を書き換えても通りませんでした。最終的にアプリの主語そのものを変えています。表面を直して通る種類と、そうでない種類があります。
公開したら終わりですか？
そこから反応が来ます。私は返信アプリを出して9日間で利用者が0人でした。そこで同じ領域を118本調べて、何を中心に置くかから見直しています。公開は七段階の6番目で、最後ではありません。
仕様書は作ったほうがいいですか？
頭の中だけで持つと、数週間後の自分が別の判断をします。一人だと誰も指摘しないので、食い違ったまま進みます。形式は問いませんが、あとから読める場所に置いてください。
完成の基準はどこに置けばいいですか？
機械で確かめられるか、画面を開けば分かる形にしてください。「品質が高い」では判断できません。主要な操作が通る、失敗しても止まらない、ストア説明と機能が一致する。この種の書き方なら、通ったかどうかが決まります。
何本くらい作れば慣れますか？
本数では書けません。ただ、2本目からは前後の段階が見えているぶん、見積もりが変わりました。1本目で重かった公開の手前の作業は、2本目では準備できます。
⚠️ この記事は、特定の技術や開発手法を推奨するものではありません。七段階という分け方も、私が3つのアプリを作りながら整理したものです。合わない部分は変えてください。
また、収益や利用者数についても書いていません。私自身がまだ確かめられていないためです。
覚えておくと使えるのは、実装は七段階のうちの一つという1点です。作る作業だけを見積もると、前後の3つずつが丸ごと抜けます。そこが一人でやるときの一番の落とし穴でした。
段階を分ける目的は、進み方を管理することではありません。いま何で止まっているかを特定するためです。分けていないと、全部まとめて「進んでいない」になります。
段階の分け方そのものは変えてかまいません。数が七つである必要もありません。
