App Store掲載用のスクリーンショット準備を終えて一区切りついたところで、ふと振り返ると「やろうと思って忘れていたこと」がいくつも出てきました。今回は、そんな自分の反省もこめて、個人開発でのバグ・タスク管理について記録しておきます。
1. 最初は「頭の中で覚えておく」で失敗した
開発を始めたばかりの頃は、修正したいバグも実装したい機能も、全部頭の中で覚えておけばいいと思っていました。せいぜい数個しかないだろう、と。
しかし実際にコードを書き進めると、「このボタンの余白がちょっとおかしい」「このエラーメッセージが分かりにくい」といった小さな気づきが、1日作業しただけで10個近く出てきます。当然、次に開発を再開したときには半分近く忘れていて、「あれ、直したいことあった気がするけど何だっけ」と探し回る羽目になりました。
2. Notionで管理を始めたが、続かなかった理由
さすがにまずいと思い、Notionでタスク管理用のデータベースを作りました。ステータス（未着手・作業中・完了）、優先度、カテゴリ（バグ／機能追加／UI改善）まで細かく項目を用意した、それなりに立派な管理表です。
最初の数日は快適でした。ただ、コードを書いている最中に「あ、ここもついでに直したい」と気づいたとき、Notionを開いて項目を1つずつ入力するのがだんだん面倒になっていきました。エディタとブラウザを行き来する手間がストレスになり、結局「あとで書こう」と先延ばしにしているうちに、また記録せずに忘れる、という元の木阿弥な状態に戻ってしまいました。
3. GitHub Issuesに乗り換えて分かったメリットと注意点
次に試したのが、コードを管理しているのと同じGitHubの「Issues」機能です。ターミナルでコードを触っている流れのまま、GitHub CLIからgh issue createで1行タイトルを打つだけで登録できるので、Notionのときのような「別のツールに切り替える面倒さ」がなくなりました。
もう一つ良かったのが、コミットメッセージにfixes #12のように書くと、そのIssueが自動でクローズされる仕組みです。バグを直したら記録し忘れることがほぼなくなりました。
注意点としては、Issueのタイトルだけ書いて満足してしまい、詳細をほとんど書かないまま放置しがちだったことです。1週間後に見返すと「エラー直す」とだけ書かれていて、どのエラーだったか思い出せない、ということが何度かありました。今は最低限「どの画面で」「何をしたときに」起きた問題かだけは一言添えるようにしています。
4. 結局たどり着いたシンプルな運用ルール
試行錯誤の末、今は次のシンプルなルールに落ち着いています。
- 気づいたことは、その場ですぐにGitHub Issuesへ1行だけでも登録する（あとで詳しく書く前提でOK）
- ラベルは「bug」「feature」「ui」の3種類だけに絞る（細かく分類しすぎない）
- 週に1回、たまったIssueをまとめて見返して優先度を決める
道具の高機能さよりも「今取り組んでいる作業の邪魔をしない記録のしやすさ」の方が、自分には大事だったと感じています。
まとめ
- 頭の中だけで管理しようとすると、必ずと言っていいほど忘れる
- 高機能なツールでも、記録の手間がかかると結局続かない
- 今の作業から離れずに記録できる仕組み（自分の場合はGitHub Issues）が続けやすい
- タイトルだけでもいいので、気づいた瞬間にすぐ書く習慣が一番効いた
道具選びに正解はないと思いますが、「続けやすさ」を軸に選び直したことで、ようやく自分に合った管理方法にたどり着けた気がしています。
次は、Swiftのoptional型（nil）で何度も詰まった話をまとめます。
本記事は生成AI（Claude）を活用して執筆・編集しています。内容は実体験に基づき、執筆者本人が確認・監修しています。
コメント