機能開発におけるバグの地産地消の大切さ

「後で直そう」の罠

機能開発していると、リリース前のテストで軽微なバグを見つけることがある。 「動作としてはまあ許容範囲だしリリース後に直せば良い」と思いそのままリリースする。 そして別の機能開発に追われて修正されないまま放置されるバグたち。 放置されたバグたちは時間経過と共にだんだん大きくなっていく…。

時間が経つと何が起こるか

リリースから数ヶ月経って、別の機能開発やユーザーからの問い合わせでその部分に触れることになると、厄介なことが起こる。 「これって仕様だっけ？バグだっけ？」 記憶は曖昧になっているし、ドキュメントにも残っていない。結局、以下のようなコストが発生する。

• 歴史的経緯の把握：当時のPRや不具合チケットを漁って、なぜこうなったのかを調査
• 修正案の検討：周辺コードも変わっているので、どう修正するか改めて考える
• コードの修正実施：該当箇所のコードを思い出すところから始める

ソフトウェア工学では、バグ修正コストは発見が遅れるほど指数関数的に増加すると言われている。
開発時なら1時間で直せたものが本番環境で問題になれば数日かかることもある。

長期的に見れば地産地消が圧倒的に楽

「挙動としてまあ許容できるレベル」のバグでも、長期的に見れば直しておいた方が工数は少なくて済む。 開発時は仕様も実装も頭に入っているから、修正も動作確認も速い。でも時間が経つと、思い出しコストが乗っかってくる。 バグを先送りにすると、未来の自分（あるいは他のメンバー）にツケを回すことになる。そして「なんでこんなのバグを残したんだ…」と過去の自分を恨むことになる。

改めてシフトレフトの大切さ

この経験から、当たり前だけど改めて「早い段階で問題を解決する」ことの重要性を実感した。 もちろん、リリース期限や優先度の兼ね合いですべてのバグをその場で直せるわけではない。しかし、「後で直す」には想像以上にコストがかかるということを意識するだけで判断が変わってくる。 可能な限りバグはその場で解消する。地産地消の精神で未来の開発を楽にしたい。