個人開発が止まったとき。タスクを小さくする三つの分け方と順番

手が止まるとき、やる気の問題だと考えがちです。実際には、タスクの書き方に共通する欠けがあります。終わりが書いていない。

「ログインを作る」には、どこまでできれば終わりかが入っていません。だから、開いても最初の一手が決まりません。決まらないものは着手できないので、別の作業へ逃げます。

逆に、「Appleログインのボタンを画面に表示する」なら開けます。終わりが見えているので、やることも決まります。大きさを変えたのではなく、終わりを書いただけです。

⚠️ 完了条件は、自分で判定できる形にしてください。「ちゃんと動く」では判定できません。「端末でボタンが見える」なら、見れば分かります。

終わりを書くと、やらないことも決まります。「ボタンを表示する」なら、押したあとの処理は次のタスクです。範囲が決まっているので、途中で広がりません。

この書き換えは、AIに頼むときにも同じです。終わりを渡さないと、動くけれど意図と違うものが返ってきます。渡し方はAIにコードを書かせる前に決めるべき5つと、その置き場所にまとめました。

3つに分ける理由は、必要な状態が違うからです。調べるのは頭が動く時間、変えるのは手が動く時間、確認するのは環境が要る時間。混ぜると、どれも進みません。

疲れている日は「調べる」だけ、という使い方もできます。分けていないと、疲れている日は何もできない日になります。

タスクの粒度に迷ったら、「今から30分で終わるか」を目安にしています。終わらないなら、まだ大きいか、終わりが書けていません。

分けたあと、「調べる」から始めると動きやすいです。答えが出ないまま変え始めると、途中で調べ直すことになります。順番を固定しておくと、そこで迷いません。

⚠️ 「確認する」を省かないのも大事です。変えたところで止めると、動いているかどうかが分からないまま次へ進みます。あとでまとめて確認すると、どこで壊れたかを探すことになります。

1. 01　調べる：答えを得るだけの作業に

   仕様、エラー、公式ドキュメントなど、答えを得る作業だけにします。調べながら直そうとすると、どちらも中途半端になります。

2. 02　変える：変更する範囲を限定する

   一つの画面、一つの関数、一つの設定など、変更範囲を限定します。範囲が決まっていないと、触っているうちに広がります。

3. 03　確認する：成功の判断方法を書く

   端末、テスト、生成物など、成功を判断する方法を明記します。ここが無いと、終わったかどうかを毎回考えることになります。

実装中に料金、文言、対象ユーザーまで決めようとすると、コード以外の判断で止まります。手は動かせる状態なのに、決まっていないことがあって進めない。

「月額を決める」「エラー文を決める」を別タスクにして、決まってから実装へ戻します。分けておけば、実装のほうは他の部分を進められます。

判断が必要なものは、判断できる状態のときにまとめてやるほうが早いです。実装の途中で一つずつ考えると、切り替えのたびに時間がかかります。

⚠️ 決まっていないまま進めないのも大事です。仮の値を入れて進めると、あとでどれが仮だったか分からなくなります。私は仕様書に「未定」と書いて、空欄が見える形にしています。書き方はアプリの仕様書は何を書けばいい？個人開発で使う九つの項目にまとめました。

外へ出した判断は、まとめて片付ける時間を取るほうが効率的でした。料金、文言、対象。どれも頭を使う作業なので、集中できるときに並べて決めます。

判断を外へ出す効用は、実装が止まらないことだけではありません。判断そのものも良くなります。実装の途中で急いで決めた料金や文言は、あとで見ると納得できないことが多いです。

タスクを小さくしても動かないなら、止まっている場所が実装ではない可能性があります。個人開発では、ここが原因のことが多いです。

私が経験した止まり方は3つあります。課題が決まっていない。公開の手前が重い。公開後の反応が来ない。どれもコードを書いていない時間に起きます。

課題が決まっていないときは、何を作るかの判断が毎回必要になります。機能を足すべきか削るべきかが決まらないので、手が止まります。ここはタスクの大きさの問題ではありません。

公開の手前は、作業の種類が変わるところです。審査用の情報、スクリーンショット、プライバシーポリシー、問い合わせ先。実装の勢いのまま進めないので、そこで止まります。

私はここで、法務文書と実装を1条ずつ照らし合わせて、守れていない約束が見つかったことがあります。進んでいないように見えて、実際には必要な作業でした。

公開後も止まりやすい場所です。出せば終わりのつもりが、反応が来ないと次に何をすればいいか分かりません。私は返信アプリを出して9日間で利用者が0人でした。そこで118本調べて、何を中心に置くかから見直しています。全体の流れは個人でアプリを作るには？企画から公開までの七段階と止まる場所にまとめました。

止まっている場所を特定できると、「進んでいない」という感覚が減ります。企画で止まっているなら、コードが書けていないのは当然です。場所が分かれば、そこを進めればよいだけになります。

特定するには、最後に手が止まった瞬間を思い出すのが早いです。何を開こうとして止まったのか。コードを開こうとしたのか、それとも開く前に何を作るか考えていたのか。

作業を終えるとき、次に開くファイル、確認するURL、残ったエラーを一行で残します。翌日、状況を思い出すところから始めずに済みます。

一人でやっていると、次に触るのが数日後ということがあります。そのとき、前回どこまでやったかを思い出す時間がいちばん重い。ここを消せると、再開が軽くなります。

残すのは、次にやることではなく次に触るものにしています。「認証を直す」より「auth.ts の 42 行目のエラーから」のほうが、開いた瞬間に動けます。

⚠️ うまくいったことより、途中で止まったことを書くほうが役に立ちます。動いているものは開けば分かりますが、止まった理由は記憶にしかありません。

仕様の置き場所が散らばっている場合はアプリの仕様書は何を書けばいい？個人開発で使う九つの項目も使って整理してください。失敗や却下の記録は個人開発で失敗を記録する六項目。却下と障害から残した形式に分けています。

残す先は、次に開く場所の近くがよいです。コードの中のコメント、タスク管理の一行、メモアプリ。探しに行く必要がある場所だと、読まれません。

一行を残す習慣は、長い中断のあとでも効きます。数週間空いても、その一行から再開できます。

個人開発が進みません。やる気の問題ですか？

タスクの書き方を先に疑ってください。止まるタスクには終わりが書いていないことが多いです。「ログインを作る」は開けませんが、「Appleログインのボタンを表示する」なら開けます。大きさではなく、終わりの有無です。

タスクはどのくらいの大きさにしますか？

「今から30分で終わるか」を目安にしています。終わらないなら、まだ大きいか、終わりが書けていません。調べる・変える・確認するに分けると、自然にその大きさになります。

なぜ三種類に分けるのですか？

必要な状態が違うからです。調べるのは頭が動く時間、変えるのは手が動く時間、確認するのは環境が要る時間。混ぜるとどれも進みません。疲れている日は「調べる」だけ、という使い方もできます。

タスクを小さくしても動きません。

⚠️ 止まっている場所が実装ではない可能性があります。課題が決まっていない、公開の手前が重い、公開後の反応が来ない。どれもコードを書いていない時間に起きるので、タスクの大きさでは解決しません。

実装中に仕様が決まっていないと気づいたら？

別タスクへ出してください。仮の値を入れて進めると、あとでどれが仮だったか分からなくなります。「未定」と書いて空欄が見える形にしておくほうが、実装の他の部分を進められます。

数日空くと前回の続きが分かりません。

次に触るものを一行で残してください。「認証を直す」より「auth.ts の 42 行目のエラーから」のほうが、開いた瞬間に動けます。うまくいったことより、止まった理由のほうが役に立ちます。

完了条件をどう書けば判定できますか？

見れば分かる形か、コマンドで確かめられる形にしてください。「ちゃんと動く」は判定できませんが、「端末でボタンが見える」「このコマンドが通る」なら決まります。あとから確認の手順としても使えます。

まとまった時間が取れません。

「調べる」だけの日があってかまいません。三種類に分けておくと、状態に合わせて選べます。分けていないと、まとまった時間が無い日は何もできない日になります。

作りかけのアプリが複数あって、どれを進めるか決まりません。

どれが一番公開に近いかで選んでいます。面白さや将来性で選ぶと、比べる軸が人によって変わるので決まりません。公開までに残っている作業を数えれば、比べる軸は一つになります。選んだあと、残りは進めないと決めて閉じます。

⚠️ この記事は、作業時間を増やす方法を扱っていません。扱っているのは、止まっている時間を減らす部分だけです。使える時間そのものは、生活の都合で決まります。

また、特定の管理ツールも推奨していません。形式より、終わりが書いてあるかのほうが効きました。

覚えておくと使えるのは、終わりを書けば開けるという1点です。タスクを小さくする作業は、実は終わりを書く作業でした。大きさは、その結果として決まります。