技術的負債は改修とフルリプレイスどちらを選ぶべきか
「もう限界だから作り直したほうが早いのでは」。既存システムの改修を重ねるうち、こう感じたことがある事業責任者は少なくないはずです。コードは複雑に絡み合い、ちょっとした修正にも時間がかかる。だったらいっそゼロから作り直したい——その気持ちは分かりますが、実際にはその判断で年単位の期間と予算を溶かし、結局同じ負債を再生産してしまったプロジェクトを何度も見てきました。改修とフルリプレイスをどう判断すべきか、私たちが現場で使っている基準を整理します。
フルリプレイスの誘惑と、その罠
「新しく作り直せば全部きれいになる」という発想は魅力的です。過去の妥協から解放され、理想の設計で作り直せる——理屈としては正しく見えます。しかし実際に走らせると、多くのプロジェクトで次のような事態が起きます。
- 完成まで1〜2年かかり、その間ビジネス側の要望は止まらない。競合は機能を出し続け、現行システムへの追加要望も途切れない。リプレイス対象の仕様が完成前にズレていく
- 予算が当初見積もりの1.5〜2倍に膨らむ。既存システムに埋め込まれた「なぜこうなっているか分からない仕様」を1つずつ掘り起こす作業が想定以上に重い
- 旧システムと新システムを並行運用する期間が発生し、二重の保守コストがかかる
- 同じ開発体制・同じプロセスで作れば、数年後には同じ負債が積み上がる
フルリプレイスが失敗する最大の理由は技術的な難易度ではなく、「ビジネスを止めずに理想を追う」という前提が成立しないことにあります。負債の原因が技術選定ではなく開発プロセスや体制にある場合、作り直しても根本原因は解決しません。
段階的改善(ストラングラーパターン)が有効なケース
多くの現場で現実解になるのは、システム全体を一気に置き換えるのではなく、負債が深刻な部分から少しずつ新しい実装に置き換えていく段階的改善です。よく使われるのが「ストラングラーパターン」で、旧システムを稼働させたまま機能単位で少しずつ移行していく考え方です。
段階的改善が向いているのは、次のような状態です。
- ビジネスは動いており、止めるコストが大きい。売上や顧客対応が既存システムに依存している
- 負債が全体ではなく一部に偏っている。特定の機能・モジュールだけが複雑化・老朽化している
- 技術スタック自体は現役(EOLしていない言語・フレームワーク)で、設計や運用の積み重ねが問題の中心
- チームや発注者が「動くものを維持しながら」改善するプロセスに慣れられる
段階的改善のメリットは、常に動くものが手元にあることです。1つの機能を改善するたびに効果を検証でき、方針が間違っていれば早期に軌道修正できます。フルリプレイスのように「完成するまで成果が見えない」というリスクを避けられます。
具体的には、既存プロダクトの改善で最初に確認すべき観点にあるように、まず「動かせるか」「デプロイが再現可能か」「テストがあるか」という土台を整えたうえで、影響範囲の大きい箇所から優先順位をつけて手を入れるアプローチが、多くの場合もっとも予算対効果が高くなります。
本当にフルリプレイスすべきケース
とはいえ、段階的改善が常に正解というわけではありません。次のような状況では、フルリプレイスを検討する価値があります。
- 技術スタックそのものがEOL(サポート終了)を迎え、セキュリティリスクが放置できない水準にある。ただしまず検討すべきは「同じ言語・フレームワークのバージョンアップ」です。いきなり別言語・別フレームワークへの全面書き直しではありません。Rubyバージョンのアップグレードだけで解決するケースは想像以上に多くあります
- ビジネスモデル自体が根本的に変わり、既存のデータモデルやアーキテクチャの前提が成立しなくなった。単一テナント前提のシステムをマルチテナントSaaSに転換する、といったケース
- 改修コストの見積もりが、フルリプレイスの見積もりを恒常的に上回る。負債が広範囲に及び、どこを触っても影響範囲の特定に多大な調査コストがかかり続けている
重要なのは、これらの条件は単独では決め手にならないということです。「古いから」「読みにくいから」だけでリプレイスに踏み切ると、前段で挙げた罠にはまります。技術面の限界とビジネス面の転換、両方が揃って初めて合理性が生まれます。
判断基準の整理
改修とフルリプレイスのどちらを選ぶか迷ったときは、次の問いに順番に答えることをお勧めします。
- 今のビジネスを止めずに改善を進められるか — 止められないなら、まず段階的改善から検討する
- 負債は一部に偏っているか、全体に及んでいるか — 一部なら段階的改善、全体かつ深刻なら再検討の余地あり
- 技術スタックはEOLか、まだ現役か — EOLならまずバージョンアップを検討。それでも無理なら初めてリプレイスを検討
- ビジネスモデル自体が変わったか — 変わっていないなら、既存のアーキテクチャを活かせる余地が大きい
- 改修とリプレイス、両方の見積もりを実際に出して比較したか — 「なんとなく作り直したほうが早そう」という感覚だけで判断していないか
この5つに丁寧に答えると、多くのケースで「まず段階的改善から着手し、必要な箇所だけを絞ってリプレイスする」という中間的な結論に落ち着きます。全か無かの二択で考えないことが、予算とスケジュールを守る近道です。
torcheees では、この判断自体を発注者と一緒に行うところから支援しています。モダナイゼーションのサービスでは、既存コードの診断結果をもとに改修とリプレイスのどちらが現実的かを費用感つきで提示し、技術顧問・要件整理の相談を通じて「作り直す前に本当に必要な選択肢は何か」を検討します。
まとめ
- フルリプレイスは理想的に見えるが、完成までの期間中にビジネスの要望が止まらず、予算超過・同じ負債の再生産に陥りやすい
- ビジネスが動いている限り、負債が深刻な部分から少しずつ置き換える段階的改善(ストラングラーパターン)が現実的な解になることが多い
- フルリプレイスが合理的なのは、技術スタックのEOLとビジネスモデルの転換など複数の条件が揃ったときに限られる。単独の理由だけで踏み切らない
「改修すべきかリプレイスすべきか」の判断そのものに迷っている段階でも、torcheees はご相談を受け付けています。まずは「開発診断」で現状のコードとアーキテクチャを確認し、改修とリプレイスそれぞれの費用感・リスクを比較した上で、現実的な進め方をご提示します。お問い合わせフォームからお気軽にご連絡ください。