「技術的負債」の返済タイミング、どう決めてる？

「まずは動くものを」で作ったコードと、技術的負債の向き合い方について 個人開発や少人数チームで、「まずは動くものを作る」というのは、 要件は固まっておらず、正解も分からない段階では、「最初から綺麗なコードを目指す」ことは現実的ではありません。 仮コードの役割は、正しさや見栄えの良さではなく、 ・要件を確かめるため、モックアップを作成する ・ユースケースを理解する ・今後、仮コードを捨てるか育てるかを判断する ための材料になると思います。 したがって、この段階でリファクタリングを始めるのは誤りです。 要件が揺れている間、仕様変更が頻発している間、捨てる可能性が残っている間は、改善に時間を使うべきではないと考えます。 では、いつ返済するのか。 仮コードが返済対象に変わるのは、「明確な合図が出たとき」だけです。 例として２つ記載します。 １つ目は、仮コード捨てられなくなったときです。 ユーザーが使い始めた、データが本番に溜まり始めた、 あるいは別の機能がそのコードを前提に作られた。 この時点で初めて、そのコードは「返済すべき技術的負債」に変わります。 ２つ目は、仮コードの内容で要件の合意ができたときです。 厳密に言うと仮コードは、要件合意をもって役割を終えます。 返済は、合意内容を前提にしたコードの拡張・運用が始まった時点で行います。 また返済に入る際の考え方も重要です。 ここで重要なのは「綺麗に作り直す」ことではありません。 まず行うべきは、「境界を固定すること」です。 外部インターフェース、API、DBスキーマなど、 外から見える部分だけを安定させることです。 このとき、内部の実装はまだ汚くても全く問題ありません。 そして個人・少人数開発においては、 「返済するか」「捨てて作り直すか」 この選択肢を常に残しておくことも重要です。 プロトタイプ用のブランチや明示的なコメントによって、 そのコードが仮設であることを示すのも１つの方法であると考えます。 まとめると、「まずは動くものを」で作ったコードは、 返済前提の借金ではありません。 それは「返すか、捨てるか」を判断するための借金です。 返済は急がず、 しかし仮コードを作る目的に応じて、 返済開始の合図を決めておくことが重要です。