リファクタリングとリライト（作り直し）の違い：分岐条件と、リライトが失敗しやすい理由

リファクタリングとは、外部から見た振る舞いを変えずに、ソフトウェアの内部構造を改善する作業です（refactoring.com における Martin Fowler の定義）。 リライトには、リファクタリングほど統一された定義がありません。 この記事では、既存の実装を変更して使い続けるのではなく、対象範囲の実装を新たに作って置き換えることをリライトと呼びます。 古くなったシステムに手を入れる場面では、この2つが「直すか、作り直すか」という並列の選択肢として語られがちです。 しかし両者は、リスクの形も、成立するための前提条件も違います。 とくに、全体を一度に置き換える全面リライトは、成果とリスクが切り替え時点に集中します。

定義の対比

リファクタリングの定義には「観察可能な振る舞いを変えない」が含まれています。 Martin Fowler は、小さな変換のたびに動く状態を保ち、機能追加の前後にリファクタリングを置く進め方を説明しています。 構造変更と仕様変更を検証可能な単位に分ければ、不具合が出たときに原因を絞りやすくなります。

一方のリライトでは、再実装する範囲と再現する振る舞いを決める必要があります。 「せっかく作り直すなら」と要件が膨らみ、旧システムの再現に加えて新機能の開発まで抱え込む、という失敗はここから始まります。

なお、クラウド移行の7Rにある Refactor / Re-architect は、クラウドの機能を活用するためにアプリケーションのアーキテクチャを変更する戦略です。 既存コードの改修、部分的な再実装、全面リライトのどれを採るかまでは、この名称だけでは決まりません。 観察可能な振る舞いを保つ Fowler のリファクタリングとも定義が異なるため、移行計画では変更範囲を確認してください（7Rの全体像はモダナイゼーションの解説で整理しています）。

リライトが失敗しやすい理由

この論点の古典としてよく参照されるのが、Joel Spolsky が2000年に書いた Things You Should Never Do, Part I です。 Netscape がブラウザのコードをゼロから書き直した判断を戦略的な過ちだったと論じています。 これは失敗率を測った統計ではなく、事例に基づく論考です。 ただし、そこで挙げられた2つのリスクは、全面リライトの計画を点検するうえで現在も使えます。

失敗しやすさの理由は、大きく2つに整理できます。

1つ目は「動いているコードに暗黙の仕様が残っている」というリスクです。 古いコードの分岐には、実運用で見つかった不具合や例外的な入力への対応が含まれています。 コードを捨てると、その経緯を知らないまま、旧システムが処理していた境界条件まで失う可能性があります。 ただし、現在の挙動がすべて正しい仕様とは限りません。 不具合や不要になった制約まで再現しないよう、コードから見つけた挙動を業務ルールや利用実態と照合し、残すものを受け入れ基準にします。

2つ目は「書き直している間も本番は変化し続ける」というリスクです。 制度改正、取引先の要求、障害対応などで、旧システムには変更が入り続けます。 新システムはその変更を取り込みながら追いかけることになり、開発期間が長いほど差は開きます。 追いつく前に差が広がる状態に入ると、切り替え判断そのものができなくなります。

分岐条件

まず、リファクタリングを第一候補にしやすい条件から確認します。

• 目的が機能変更ではなく、理解しやすさや変更コストの改善である
• 対象を小さく分け、各変更後もビルドしてリリースできる
• 自動テスト、監視、代表的な操作の確認など、振る舞いの後退を検出する手段を整備できる（テスト基盤の解説も参照）
• 言語、ランタイム、主要ライブラリを、サポート対象の版へ段階的に更新できる

リライトを候補にしやすいのは、次のような条件です。

• 言語やランタイムがEOLを迎え、現行実装を保ったままサポート対象の環境へ移す経路がない
• 必要な品質特性を段階改修では満たせない（例：シングルテナント前提の設計から、テナント分離を保証するSaaSへ移行する）
• ソースコードが失われている、あるいはビルドできる環境を復元できない
• 段階改修の累積コストが、再実装と移行の総コストを上回るという試算がある

「この設計は限界だ」という現場の実感は出発点にはなりますが、それだけで事業計画に載る規模の投資判断はできません。 比較には開発費だけでなく、仕様調査、データ移行、新旧の並行運用、連携先の変更、利用者教育、切り替え、旧システムの廃止まで含めます。

どちらかを選ぶ必要がない場合もあります。 利用実態のないシステムなら廃止し、標準化された業務に適合する製品があるならSaaSへの置き換えも候補になります。 リファクタリングとリライトを比較する前に、システムを残す理由そのものを確認してください。

中間の道：境界を切って段階的に置き換える

実務で選ばれることが多いのは、全面同時リライトを避け、置き換えを分割する道です。 機能やドメインの境界でモジュールを切り出し、新しい実装へ少しずつ移していく進め方は、Strangler Fig Application として知られています。

この方式では、リライトの投資と検証を小さく分割できます。 新旧を振り分ける境界と切り戻し手段を用意できれば、問題の影響を置き換えた範囲に限定し、途中の段階から新しい機能を使えます。 一方で、新旧を共存させる一時的な構成やデータ同期が必要になり、その複雑さは追加コストです。 分割できる境界が見つからない場合は、境界を作るための改修から始めます。 並走の仕組み、データ整合、完了条件はストラングラーフィグパターンの解説で、移行方式全体の類型はモダナイゼーションの解説で扱っています。

判断の実務

どちらを選ぶ場合でも、現行システムの振る舞い、データ、外部連携、非機能要件、運用手順の棚卸しが先に必要です。 そのうち自動化できる振る舞いはテストにし、リファクタリングでは変更の検証に、リライトでは受け入れ判定に使います。 テストだけでは性能、監査、手作業を含む運用まで表せないため、計測値と業務手順も受け入れ基準に含めます。

AI駆動開発では、既存コードの要約、依存関係の候補抽出、テストのたたき台作成にAIを使えます。 しかし、コードから推定した説明も生成されたテストも、現行仕様の証拠にはなりません。 AIの出力を調査の仮説として扱い、実際の入出力、ログ、業務資料、利用部門への確認で検証します。 調査が速くなっても、EOLやアーキテクチャの不適合が解消するわけではなく、分岐条件そのものは変わりません。

関連して読める記事

このサイトでは、レガシーシステムへの対応を1テーマ1記事で解説しています。 判断の前提となる負債の考え方から押さえたい方は、技術的負債の解説からどうぞ。

技術的負債とは？「借金」の比喩の本来の意味と、返済の優先順位の付け方

技術的負債とは、短期には便益がある、または当時の理解では妥当だった設計や実装が、将来の変更や保守に追加コストを生む状態を捉える比喩です。Ward Cunninghamによる比喩の初出とFowlerの4象限を原典に沿って整理し、利子が変更リードタイムや障害という形で現れる構造、経営への翻訳のしかた、変更頻度×変更コストで返す場所を選ぶ優先順位の付け方、AI時代に増えやすい理解負債までを解説します。

2026年7月29日

レガシーシステムとは？「古い」だけでは決まらない判定基準と放置のリスク

レガシーシステムの本質は古さではなく、許容できるコストとリスクで保守や変更を続けられなくなったことです。経産省のレガシーシステムモダン化委員会総括レポートの定義を起点に、EOL・自動テスト・属人化・ドキュメントなど8観点の判定チェックリスト、セキュリティ・事業・人材の3面から見た放置のリスク、「2025年の崖」その後の政策動向、資産棚卸しから始める対応の入口までを整理します。

2026年7月29日

モダナイゼーションとは？クラウド移行の7Rと選び方の基準

モダナイゼーションとは、既存のアプリケーション、インフラ、開発運用プロセスを更新し、事業や運用上の成果を改善していく取り組みです。クラウド移行との違いを整理したうえで、AWSが定義する7つの移行戦略（7R）を原典に沿って表で解説し、事業価値や変更頻度だけでは決まらない選び方の判断材料、ストラングラーフィグによる段階移行、成果指標から始める進め方と注意点までをまとめます。

2026年7月29日

ストラングラーフィグパターンとは？システム全体を一括停止せずに置き換える段階移行の設計

ストラングラーフィグパターンとは、既存システムを稼働させながら、業務機能やデータを小さな単位で段階的に新実装へ移し、旧システムの廃止を目指すアプローチです。Martin Fowlerによる比喩の由来と2004年の原文、ファサードで受けるMicrosoftの4段階とAWSの3ステップ、継ぎ目（seam）と移行期アーキテクチャの考え方、並走期間のデータ整合と切り戻し条件、適さない場面の判定、最初の移行単位の決め方までを原典に沿って整理します。

2026年7月29日

「動けばいい」運用は、AI 駆動開発で半年もたない

AI 駆動開発で生産性が出るかどうかは、ツールでもエンジニアのスキルでもなく、自動テストが回せているかで決まります。「動けばいい」運用が AI 時代に半年でボトルネック化する構造と、CXO・VPoE が今打つべき手を整理します。

2026年6月7日

AI駆動開発では、コード品質が事業競争力になる

AI駆動開発で競争力を出すには、ツール選定よりも既存コードベースの品質・設計・自動テストが重要です。コード品質が事業スピードに直結する理由と、経営層が90日で着手すべき基盤整備を整理します。

2026年6月18日