個人開発の進捗を、平日30分で前に進めるためのルール

2 months ago
1

個人開発の進捗を、平日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(コミット数で判断する)が最後まで残ると思う。事実ベースで自分を見るのが、自分の場合いちばん壊れにくい。

0
0
0