こんにちは、阿久梨絵です！
技術的負債が積み重なったコード、
バグが多くて触るのが怖いモジュール、
仕様が不明瞭で誰も手を出せないレガシーシステム。
そんな“ 品質の悪いプログラム ”に直面したとき、
私たちは「直すべきか」「作り直すべきか」で悩みます。
この記事では、 品質の悪いプログラム にどう向き合うべきか？
その判断軸と、現実的な改善アプローチを整理します。
1. まずは「現状の可視化」から始める
品質が悪いとはいえ、何が悪いのかが分からなければ改善できません。
以下のような観点で、現状を“見える化”しましょう。
・バグの頻度・傾向（ログ、チケット、ユーザー報告）
・テストカバレッジ（ユニットテスト、E2Eテストの有無）
・コードの複雑度（循環的複雑度、依存関係）
・ドキュメントの有無（仕様書、設計書、README）
この時点で「そもそもテストがない」「誰も仕様を知らない」なら、作り直しの検討ラインに入ります。
2. テストを繰り返す：壊さずに直すための“安全網”
品質改善の第一歩は、テストの整備です。
・ユニットテスト：関数単位での正しさを担保
・統合テスト：モジュール間の連携を確認
・回帰テスト：修正による“副作用”を検出
テストが整っていれば、安心してリファクタリングや修正ができるようになります。
逆に、テストがない状態での修正は“地雷原を裸足で歩く”ようなものです。
3. 作り直すべきか？判断の3つの軸
以下の3つの観点から、「リファクタリング」か「再構築」かを判断します。
| 判断軸 | リファクタリング向き | 作り直し向き |
|---|---|---|
| 仕様の明確さ | 仕様が残っている／理解できる | 仕様が不明・属人化している |
| テストの有無 | テストがある／追加できる | テストがない／追加が困難 |
| 構造の健全性 | 層構造・責務分離がある程度ある | スパゲッティ構造・密結合 |
3つすべてが“作り直し向き”なら、再構築を検討する価値ありです。
4. 第三者の視点を入れる：バイアスを排除する
品質が悪いコードに長く関わっていると、“慣れ”や“諦め”が判断を鈍らせます。
そこで有効なのが、第三者レビューや外部の技術顧問の導入です。
・コードレビュー：構造・命名・責務の観点で指摘をもらう
・アーキテクチャレビュー：設計レベルでの改善提案を受ける
・QAチームによるテスト観点レビュー：見落としやすいケースを補完
第三者の視点は、“自分たちでは気づけなかった問題”を浮き彫りにしてくれます。
まとめ
・ 品質が悪いプログラム は、まず“見える化”から始める
・テストを整備すれば、壊さずに直せる“安全網”ができる
・仕様・テスト・構造の3軸で“作り直すべきか”を判断する
・第三者の視点を入れることで、改善の精度と納得感が高まる
品質の悪さは、放置すれば“負債”になりますが、
正しく向き合えば“改善の起点”にもなります。
阿久梨絵でした！
