公開したあとが怖かった僕が先に書いた保守フェーズ

個人開発の運用を雨の季節に整える

「また CHANGELOG 書くの忘れた。」

リリースタグを打ったあと、そう気づいたことはありませんか？

コードは動いている。
テストも通っている。
CHANGELOG は空のまま。
README の機能一覧は先月のまま——。

個人開発の公開したあとが、僕はずっと怖かったのです。

公開したあとに手が止まる本当の理由

「リリース後に何をすればいいか、分からなくなる。」

tsurilog（釣果記録アプリ）と flowtask（GTD × PDCA の Todo アプリ）。
この 2 つの個人開発を抱えて気づいたのは、問題は意志でも時間でもなかったということです。

保守フェーズをリリース前に設計していなかった。

それだけでした。

コードを書く前に仕様を決めるように。
テストを書く前にどこをカバーするか優先順位を決めるように。
デプロイ前にどのサービスを使うか役割を決めるように。

公開後に何をするかも、リリース前に決めておく必要がある——。

そのことを学んだのは、何度か痛い目を見た後でした。

みなさんは、個人開発を公開したあとの次の一手を先に決めていますか？

僕が経験した公開後に止まる 3 つのパターン

【パターン ①】 深夜 2 時のバグ発見

テストを省いた結果がどうなるか、身をもって知っています。

深夜 2 時、個人開発していた決済機能に二重課金のバグが見つかった夜がありました。
直しても直しても、別のどこかが壊れる恐怖。

「次に何を直せばいいか」の優先順位が決まっていなかった。
バグ対応の手順が頭の中にしかなかった。

そのとき初めて、保守の手順を事前に書いておくべきだったと気づきました。

【パターン ②】 CHANGELOG が空のまま積み上がる

tsurilog のリリースタグを打ったあと、CHANGELOG が空のまま 3 週間が経つことがありました。

コードは育っていた。
「何が変わったか」を記録する場所が設計されていなかった。

「後で書こう」は、たいてい来ない。
それが個人開発の現実でした。

【パターン ③】 次に何をするかで開くたびに迷う

flowtask は仕様が複雑で、週末にリポジトリを開くたびにどこから手をつけるかを考えるだけで 30 分が消えることがありました。

GitHub Issues を開けば積み上がった未整理のタスク。
Obsidian を開けば週次ノートに 0% が続く記録。

開くたびに止まる。
それは保守の設計がなかったサインだったのです。

先に決める設計が公開後の恐怖を消した

止まるパターンを何度か経験したあと、ある考え方に行き着きました。

テスト戦略を立てるとき、「何を・どの順番で書くか」を先に決めることが時間のない個人開発者の生命線だと気づいていた。
デプロイ先（Vercel か Cloudflare か）の判断を、リリース直前ではなく設計の段階で先に決めることで、迷いが消えていた。

同じことが保守フェーズにも当てはまる。

リリース後にどう動くかをリリース前に先に書いておく。

これが、僕が保守フェーズ設計書と呼んでいるものの出発点です。

難しくありません。
最小で 4 項目、A4 一枚にも満たない文章で済みます。

最小の保守フェーズ設計書を先に書く

保守フェーズ設計書は、リリース前に書く公開後の運用メモです。
僕は Obsidian に 1 ノートで管理し、GitHub の README にも要点だけ転記しています。

以下が、実際に使っている雛形です。