コメントアウトはなぜ増える？バージョン管理不足でコードが腐った実例と対策
Contents
はじめに：不要なコード、どうしていますか？
不要になったコードを見つけたとき、選択肢はだいたい2つです。
- 削除する
- 「後で使うかも」とコメントアウトして残す
結論から言うと、不要なコメントアウトは削除するのがおすすめです。
理由は単純で、コメントアウトは“安全な保管”ではなく、可読性と生産性を確実に下げるノイズになるからです。
本記事では、コメントアウトを残さない理由と、Gitが導入できない現場でも履歴を残すための運用ルールをまとめます。
コメントアウトが増える理由：現場では修正が日常だから
現場では、完成したコードが修正されるのは当たり前です。
- 仕様変更
- 不具合対応
- リファクタリング
修正が入れば、当然「不要になったコード」も発生します。
すると人間はこう思いがちです。
- せっかく書いたのに消すのはもったいない
- また使うかもしれないから残しておこう
ここでコメントアウトを残し始めると、後から確実に効いてきます。
なぜコメントアウトを残すのはダメなのか（結論：ノイズが増殖する）
コメントアウトは短期的には安心感があります。
しかし長期的には、確実に次の損失を生みます。
1) 読む効率が落ちる（＝調査・改修・レビューが遅くなる）
本当に理解したいのは「今動いているコード」です。
そこに動かないコードが混ざると、読解コストが跳ね上がります。
特に不具合調査では致命的です。
「動いている処理」を追いたいのに、コメントアウトが視界に入り、判断が鈍ります。
2) grepが汚れる（コメントアウトが検索に引っかかる）
検索結果にコメントアウトが混ざると、見なくていい情報が増えます。
これは地味ですが、毎日の作業で積み上がるタイプの損失です。
3) スクロール量が増える（＝地味に疲れる）
不要なコードが残るほど、視線移動とスクロールが増えます。
結果として集中が切れやすくなり、生産性が落ちます。
正解は「履歴に残す」こと（本来はGit）
不要コードを残したい理由の多くは、結局これです。
消したら戻せないのが怖い
だから本来は、コメントアウトではなく、バージョン管理（Git）の履歴に残すのが正解です。
ただ、現実にはこういう状況もあります。
- Gitを導入していない
- 事情があって導入できない
この場合、「仕方ないからコメントアウトで残す」に流れがちです。
しかしそれは、“仕方ない”のコストが高すぎる運用です。
Gitがなくてもできる：コメントアウトを増やさない代替運用
Gitが導入できないなら、次善策として 疑似的に履歴を残す仕組みを作ります。
私の現場では、以下のルールで運用しました。
ルール①：開発前に資源全量のバックアップを取る
- 改修前の状態を丸ごと退避する
- 「戻せる」安心感を先に確保する
これで「消すのが怖い」という心理を先に潰せます。
ルール②：案件ごとに「改修前後のソース差分」を成果物として残す
- 改修前のソース（Before）
- 改修後のソース（After）
- できれば差分（diff）も保存する
この運用にすると、コメントアウトで残す必要がなくなります。
どこがどう変わったかを後から追えるためです。
関連記事
「頑張ったのに差し戻し」を減らす：Apexレビュー観点チェックリスト（設計／UT）
バッチ処理とガバナ制限の仕組みを理解しよう
【Salesforce】Apexテストクラス開発で使うアノテーション「＠IsTest」とは何かまとめてみた
まとめ：リーダーは“コメントアウト増殖”を許さない
コメントアウトを許すと、コードは増殖します。
そして増殖したノイズは、未来の自分（とチーム）に刺さります。
- リーダーは、不要なコメントアウトを許さない
- エンジニアは、まずコメント以外で表現できないか考える
- 履歴は「仕組み」で残す（理想はGit／無理なら代替運用）
コメントアウトは「保険」ではなく、将来の負債です。
消して、履歴は別で残す。 この運用がいちばん強いです。
