個人開発の進捗を、平日30分で前に進めるためのルール
個人開発の進捗を、平日30分で前に進めるためのルール
個人開発が4ヶ月続いている。これは自分にとって最長記録だ。
過去3年で5回くらい同じことを始めて、毎回1〜2週間で止まっていた。理由はだいたい同じで、本業のあとに PC を開いても、何をやるか決まっていなくて、結局 X を見て寝る、というやつだ。
今回続いているのは、気合いが入っているからではない。むしろ気合いの量は過去最低だと思う。続いている理由は、平日夜の30分でやることを「迷う時間ゼロ」にするルールを5つ運用しているからだ。整理しておく。
4ヶ月続いている事実
数字で出しておく。
| 月 | 平日コミット日数 | 週末コミット日数 | 累計コミット数 |
|---|---|---|---|
| 1月 | 14日 / 22営業日 | 6日 / 9日 | 78 |
| 2月 | 16日 / 20営業日 | 7日 / 8日 | 92 |
| 3月 | 17日 / 22営業日 | 8日 / 9日 | 104 |
| 4月 | 15日 / 22営業日 | 7日 / 8日 | 88 |
平日コミット率は約7割。これは自分にとっては異常値だ。過去の個人開発で平日コミット率がここまで出たことはなかった。
書き出す内容は CRUD の小さな Web アプリで、Next.js 15 と PostgreSQL 16 で組んでいる。週末に2〜3時間のまとまった時間を取って大きい変更を入れ、平日30分は週末の続きの「小さい一歩」を進める、という構成だ。
平日30分は短い、と最初は思っていた。実際にやってみたら、ルール次第で十分だった。
ルール1: 翌日のタスクを前夜に1個だけ決める
夜の個人開発で何をやるか、その夜になってから決めない。前の夜の終了時に、必ず Linear に「明日の自分宛のタスク」を1個だけ立てる。
タスクは1個だけ。3個書くと結局1個もやらないことを過去に何度もやった。1個に絞る。
タスクの粒度は「30分で終わる」サイズ。たとえば「ユーザー一覧画面に検索フォームを置く(UIのみ、APIは別タスク)」のように、1コミットで終わる粒度まで分解する。
これだけで夜21時に PC を開いたあとの「今日何やる?」を考える時間がゼロになる。タスクを Linear で開くと、すでに自分が昨夜書いた指示が入っている。ありがたい。
ルール2: 30分タイマーをスタートしてから開発を始める
PC を開いて Linear を開いたあと、何より先に iPhone でタイマーを30分セットする。タイマーを開始してから、エディタを開く。
30分が経ったら、コミットしてプッシュして、その日は終わる。途中でも終わる。
「あと10分で終わるから続けよう」は禁止。これをやると、その10分が結局60分になり、翌日疲れて休む、というのが見えている。30分で止めて、続きは翌日のタスクとして Linear に積む。
30分は短いように見えるが、毎日30分やると週で2.5時間、月で10時間になる。週末の3時間を加えると月で22時間。年で264時間だ。これくらいあれば、個人プロダクトの形は普通に作れる。
ルール3: PR は分割せず、平日は main に直接コミットする
会社の業務では PR レビューを必ず通すが、個人開発で平日30分の作業に PR を立てると、PR を立てる時間と説明文を書く時間で15分が消える。
平日は main に直接コミットする。これは個人開発だから許される運用だ。
代わりに、週末のまとまった作業のときだけ feature ブランチを切って自分で自分にレビューを入れる。週末のレビューは「先週1週間の自分の平日コミットを読み返す」工程と兼ねている。
平日コミットを後で読み返すと、たまにひどいやつがある。週末にリファクタする。
ルール4: テストは「壊れる前提」で書き、平日は書かない
これは賛否ある運用だが、自分の場合これでうまくいっている。
テストは週末にまとめて書く。平日のコミットでロジックを足したら、その日はテストを書かない。翌週末にまとめて、その週のロジックに対するテストをまとめて足す。
平日30分でロジックとテストを両方書こうとすると、テスト中の細かい挙動の調整で30分が溶ける。テストはまとめて書いたほうが、テスト全体の構造も整理できる。
ただしこれは「テスト書かない」ではなく「曜日を分ける」ということだ。週末に書かなかったテストは、月曜の朝に確実に思い出して足す。GitHub Actions で coverage が一定以下なら CI が落ちる設定にしてあるので、忘れたら本人より先に CI が怒る。
ルール5: 進捗の体感ではなく、コミット数の事実で判断する
これがいちばん効いている。
「今週は進んだ気がする」「今週はあんまりやれてない気がする」という体感は、自分の場合ほぼあてにならない。火曜に集中して書いて水〜金が薄い週でも「今週はやった」と感じる。逆に毎日少しずつ書いた週でも「あんまり進んでない気がする」と感じる。
体感と事実がずれているから、毎週金曜の夜にコミット数を眺める時間を作っている。GitHub Insights を開いて、今週の累計と先週の累計を見る。それだけ。
これをやると「今週は実は少なかった」「今週は思ったよりやれていた」が見える。来週の自分への期待値の調整ができる。期待値が現実から離れている状態が、個人開発が止まる一番の原因だと思っている。
5つのルールを並べて気づくこと
並べてみると、5つのルールは全部「迷う時間を減らす」「事実で判断する」ことに収束している。
| ルール | 削っているもの |
|---|---|
| 1: 前夜にタスクを1個決める | 「何やるか」の迷い |
| 2: 30分タイマー | 「いつまでやるか」の迷い |
| 3: 平日 main 直コミット | PR運用の手続きコスト |
| 4: テストは週末まとめ | 1日の中での文脈切替コスト |
| 5: コミット数で判断 | 体感の不正確さ |
個人開発が続かない原因は、自分の場合「時間が足りないこと」ではなかった。平日に使える30分はあった。ただ、その30分で「何をやるか」「いつまでやるか」「どう判断するか」を毎回考え直していたから、実装に使える時間が10分しか残らなかった、という構造だ。
迷う時間をゼロにすれば、30分はちゃんと30分のままだ。これは仕事のスプリント運用と同じ考え方だと思う。
このルールが効かなくなったら
4ヶ月続いているが、いずれ崩れるとも思っている。崩れた瞬間は記録する。
5つのルールのどれが先に壊れるかで、自分のなかの優先度が見える。たぶん、ルール5(コミット数で判断する)が最後まで残ると思う。事実ベースで自分を見るのが、自分の場合いちばん壊れにくい。