「リファクタリング」ではなく「リライト」を選ぶべき場面とは？　利点と欠点

アプリケーションの抜本的な改革を目指して、ソースコードを一から書き直す「リライト」は、困難を伴うと同時に、さまざまなメリットをもたらす。細かい修正で済ませる「リファクタリング」との選択のポイントとは。

公開 2025年07月19日 05時00分

著者

Matt Heusser

[TechTarget]

印刷する連載新着通知を受け取る

　運用を続けてきたアプリケーションのソースコードは、変更を重ねるうちに複雑化し、開発速度を優先したことで発生する将来的な負荷「技術的負債」を生む。この問題に対し、開発者は既存のソースコードの挙動を変えずに部分的に手直しして改善する「リファクタリング」か、全てを作り直す「リライト」かを選択することになる。リファクタリングと比較して、リライトにはどのようなメリットとデメリットがあるのか。自社のプロジェクトに適した手法をどのように見極めればよいのか。その判断基準を解説する。

リライトのメリットとデメリット

併せて読みたいお薦め記事

連載：リファクタリングか、リライトか

前編：コードの“大掃除”「リファクタリング」とは？　主なメリットとデメリット

コーディングのヒント

　複雑で見通しが悪いソースコードを読み解いてリファクタリングする代わりに、ソースコード全体を新たに書き直すリライトを実施する選択肢もある。一から機能を再実装するため、リライトは問題を根本から解決できる単純明快な手法のように思えるが、メリットばかりではない。開発体制や費用、プロジェクトそのものに大きな影響を及ぼし得る、特有の課題も存在する。

リライトのメリット

メリット1．新機能の実装につながる

　新しい技術の導入や機能実装といった要望に応えることは、既存ソースコードの改修では対処が難しい。ソースコードを一から書き直すことで、新しい利用者や市場、技術に接触できる可能性が生まれる。リライトは一般消費者向けのアプリケーションをデスクトップアプリケーションからWebアプリケーション、モバイルアプリケーションに移行させるための手段になり得る。

メリット2．クリーンな状態で再出発できる

　リライトによって、開発者は自身が扱いやすい技術を用いて開発を始められる。この利点は、企業の合併や買収後には特に魅力的だ。クリーンな新プロジェクトは、開発者が自身の腕を奮って代表作を完成させる好機になる。同時に、積み重なった技術的負債を解消するチャンスでもある。

メリット3．最新技術への適応力を高める

　アプリケーションの土台となっている技術やプログラミング言語、設計思想などを、現代的なものに刷新する機会を創出することもリライトのメリットだ。これによって将来的に新しい技術や機能を追加しやすくなるレガシーソースコードを一掃することで、現在のアプリケーションと、将来利用可能になる最新の技術の間にあるギャップを埋めることが可能だ。

リライトのデメリット

デメリット1．時間がかかりやすい

　リライトは、厳格な要件に基づいて新しいアプリケーションを開発することに等しく、概して時間がかかる。ソースコードを再構築するための期間を確保できる場合にのみ、リライトに踏み切るのが賢明だ。

デメリット2．新たな欠陥を生む可能性がある

　古いソースコードはただでさえ質が低い上に、リライト中にもさらに悪化していく可能性がある。リライトチームが古いソースコードを調査したり、そこから必要なソースコードをコピーしたりしている間にも、保守チームは稼働中のアプリケーションのソースコードを修正し続けている。保守チームが修正の過程で意図せず欠陥を組み込んでしまうこともあり、さらにそれを修正するための場当たり的な対処が、ソースコードの品質をさらに悪化させる可能性がある。

デメリット3．さらに手に負えないソースコードになる可能性がある

　自動化ツールを使ってアプリケーションのソースコードを別のプログラミング言語で実装し直す方法は、リライトにおける有力な選択肢であり、時間を節約できる可能性がある。だが自動化ツールが生成するソースコードは、しばしば異なるプログラミング言語の概念を無理やり混ぜ合わせようとするため、人間にとって読みにくく、保守しづらいものになることがある点には注意が必要だ。

リファクタリングかリライトを選ぶ際の判断基準

　開発チームは、最終的に複数の要素を考慮してリライトかリファクタリングかを選択すべきだ。

考慮点1．時間

　リファクタリングは段階的に改善を進める手法であるため、納期が厳しいプロジェクトや継続的デリバリー（アプリケーションに加えた変更を、常に本番環境へリリース可能な状態に保つ開発手法）が求められる場合に適する。これに対してリライトは、より大掛かりで時間を要する抜本的な改善だ。チームは新しいソースコードを書き直す作業と並行して、古いコードベースの保守も続けなければならない。プロジェクトのスケジュールやチームの経験、リスク許容度を加味して、最も現実的なアプローチを選択する必要がある。

考慮点2．目標

　企業の長期的な目標は、判断における重要な考慮事項だ。単に保守性を高めたいだけならば、リファクタリングが有力な選択肢になる。現在のコードベースでは実現不可能な新技術の導入や新規市場への参入を目指しているのであれば、リライトを選択すべきだ。

考慮点3．予算

　リファクタリングは、新機能の開発と並行して段階的に実施できるため、初期投資を抑えることが可能だ。対照的に、リライトはより多くの予算を必要とすることが一般的だ。リライトでは2つのコードベースを同時に保守する必要があり、リライトが完了するまで新機能の提供が滞る可能性もある。

考慮点4．アーキテクチャ

　コードベースの設計思想も重要な判断材料だ。アーキテクチャは健全だが実装に問題がある場合、ソースコードを一から書き直さず、リファクタリングによってソースコードの品質を回復できる。アーキテクチャが時代遅れになっていたり、現代の開発手法やビジネスプロセスに順応できなくなっていたりする場合は、望ましい技術を導入するためにリライトに踏み切るべきだ。