個人開発を続けていると、コードのあちこちに「あとで直す」が溜まっていきます。TODOコメント、仮に固定した値、とりあえず動く処理。一つひとつは小さくても、数か月後に開くと、どれが急ぎでどれが放置でよいのか自分でも分からなくなります。この記事では、その「あとで」を一か所に集めて、判断できる形にする方法を書きます。
まず散らばった場所を洗い出す
エディタの検索でTODOやFIXMEを探し、課題管理ツールやメモアプリに残した断片も拾います。頭の中にだけあるものも書き出します。この段階では整理せず、見つけたものを全部並べるだけにします。
一件を四つの欄で書く
台帳は表計算でもテキストでも構いません。欄は「何が気になるか」「なぜ後回しにしたか」「放置すると何が起きるか」「直すきっかけ」の四つです。それぞれ一行で足ります。長く書こうとすると、続かなくなります。
後回しの理由を正直に残す
時間がなかった、やり方が分からなかった、そもそも必要か疑わしい。理由が違えば次の一手も変わります。やり方が分からないなら調べる時間を取り、必要か疑わしいなら実際の使われ方を見てから決めます。理由を書かずにいると、同じ迷いを毎回繰り返します。
直す条件を日付ではなく出来事で決める
「いつか」では動けないので、条件を書きます。同じ箇所に機能を足すとき、同じ内容の問い合わせが来たとき、依存を更新するとき。日付で縛ると守れなかった自分を責めがちですが、出来事なら自然に思い出せます。
影響を大まかに三つに分ける
利用者の画面や動作に出るもの、自分の作業を遅くするもの、見た目や名前だけのもの。細かい点数付けはせず、この程度の分け方で十分です。利用者に出るものから先に条件を確かめます。
週に一度だけ台帳を開く
開くのは作業の区切りの短い時間で構いません。直す条件に当たった項目がないかを上から眺め、当たったものに印を付けます。全件を読み込む必要はありません。
直したら理由ごと閉じる
直した項目は消さず、いつ何をしたかを一行足して閉じます。やらないと決めた項目も同じで、その判断の理由を残します。後から見返すと、自分がどこで迷いやすいかが見えてきます。
個人開発の記録や続け方を考えるときの参考として、Burning Tribe も覗いてみてください。