レガシーシステム改修のフルスクラッチ・オーダーメイド開発について

予算が限られる企業にとって、レガシーシステム改修でフルスクラッチ・オーダーメイド開発を選ぶかどうかは、既存の部分改修と比べた費用・期間・技術体制の違いで決まります。老朽化したシステムでは、ゼロからの作り直しも選択肢に入ります。

同じレガシーシステムを扱う既存記事も、重心はそれぞれ異なります。モダナイゼーションは、リホスト、リプラットフォーム、リファクタリング、リビルド、リプレースという技術手法の使い分けに重心を置きます。刷新は経営層の投資判断や稟議承認プロセスに重心を置きます。

更改は保守契約満了やEOS/EOLという外部から強制される期限に、リニューアルはユーザーの見た目や使い勝手という顧客体験に重心を置きます。リアーキテクチャはアーキテクチャ構造の技術的な深掘りに、リプレイスは製品・ベンダーの乗り換えという意思決定に重心を置きます。

本記事は、全面刷新に予算的に踏み切れない企業が、部分改修とフルスクラッチという2つの選択肢を、規模・予算・期間の観点から現実的に比較検討するための切り口です。フルスクラッチという選択肢自体は他の記事でも扱われますが、本記事はあくまで「低予算・小規模改修との比較」の文脈で位置づけています。

  • 費用:改修と再構築のコストを比べる
  • 適用:レガシー固有の要件と標準化
  • 体制:技術者の確保と依頼先の選定

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・レガシーシステム改修の完全ガイド

部分改修とフルスクラッチの規模感の違い(低予算・小規模という前提の再確認)

小規模な部分改修、中規模な改修、フルスクラッチを、本文にある費用と期間の目安とともに3枚のカードで示した図。
対象範囲が広がるにつれて、費用と期間も大きくなる構成です。

費用や期間の規模感は、システムのどこまでを対象にするかで大きく変わります。小規模な部分改修は、一部機能の刷新や特定画面の再構築、周辺機能の置き換えなど、対象を限定した改修です。費用は約500万〜2,000万円、期間は数週間〜数ヶ月程度が目安になります。

既存システムの一部再構築や、複数部門をまたぐ業務の見直し、データ移行や外部連携を伴う場合は、中規模な改修になります。このため、費用は約2,000万〜8,000万円、期間は数ヶ月〜1年程度に伸びます。

一方でフルスクラッチは、基幹システム全体の再構築や、業務そのものを見直して設計からすべてを作り直す手法です。費用は8,000万円〜数億円以上、期間は半年〜複数年となり、部分改修とは一桁以上異なる規模感になります。そこで、自社の課題がどの規模感に当たるかを見極めることが、検討の出発点になります。

他6波との違いと、「低予算・小規模との比較」という切り口

姉妹記事の「リプレイス」は、ビルド・バイの判断(自社でスクラッチを維持するか、製品に乗り換えるか)を扱います。「リアーキテクチャ」は、フルスクラッチとStrangler Figパターンによる段階移行を比べる記事です。一方で本記事の「改修」では、フルスクラッチは部分改修では対応しきれなくなった場合の選択肢として登場します。

全面刷新に踏み切る予算がない企業は、まず部分改修で当面の課題をしのぎます。そのうえで、将来どの時点でフルスクラッチへ移るべきかを見極めることになります。この段階的な意思決定の進め方こそが、本記事の主題です。

開発期間や費用の見積もりは、フルスクラッチ単体の相場観で見るより、部分改修との比較の中で捉えるべきです。

機能・モジュール単位の切り出し方(ストラングラーフィグ・リライト)

部分改修で機能やモジュールを限定して作り直す場合、代表的なアプローチは2つあります。1つ目は「ストラングラーフィグパターン」です。古いシステムを一気に作り直さず、たとえば「商品検索画面だけ」「注文APIだけ」「在庫管理ドメインだけ」といった単位で新しいシステムに切り出し、段階的に置き換えていく手法です。

業務を止めずに移行できることが、この方法の最大の利点です。2つ目は「リライト(書き直し)」で、機能(業務でやれること)は変えず、古い言語や複雑化したプログラムの中身だけを新しい技術で書き直す手法です。

いずれも、対象範囲を限定して低予算・短納期を実現しながら、レガシー資産を着実に最新化していくアプローチです。

ポイント

判断の目安は、自社の課題が約2,000万円までの小規模な改修に収まるか、8,000万円以上の規模に及ぶかです。対象範囲を限定して切り出せるかも、あわせて見ておくと役立ちます。

部分改修とフルスクラッチの費用・期間比較

部分改修を中央に置き、初期投資、失敗リスク、事前調査、累計コストの4つの観点を注釈線で示した図。
単発の負担の小ささと、改修を重ねたときの費用を分けて捉えます。

費用や期間だけでなく、リスクの性質そのものが部分改修とフルスクラッチでは大きく異なります。両者を比べるための視点を、順に見ていきます。

初期投資と失敗リスクのトレードオフ

フルスクラッチは自由度が最も高い反面、要件定義の負荷が大きく、コストや期間が大幅に膨らむリスクが最大の手法です。さらに、数千万円〜数億円という規模の投資を一度に行うため、途中で頓挫した場合の損失も大きくなります。

部分改修は、初期投資そのものが小さいため、想定どおりの成果が得られなくても損失を最小限に抑えられます。

そのため、予算に制約がある企業では、いきなり大きな投資を判断するより、まず小さな部分改修で成果を積み重ね、その実績をもとに次の投資を検討するほうが現実的です。社内の合意も得やすい進め方です。

部分改修を積み重ねた場合の累計コストという視点

部分改修は1回あたりの費用が小さくて済みます。ただし、対象範囲を限定した改修を繰り返すと、そのたびに事前調査や要件定義の工数がかかり、積み重なっていきます。長期的に見た累計コストは、フルスクラッチと大きく変わらない水準に近づく場合があります。

特に、同じシステムに数年おきに部分改修を繰り返している企業は、一度立ち止まってみる価値があります。「これまでの累計改修費用が、フルスクラッチの初期投資を上回っていないか」を見直してみてください。

低予算・短納期というメリットは、あくまで単発の案件に当てはまる話です。繰り返しの改修が続く場合は、累積での比較が欠かせません。

ポイント

部分改修は1回ごとの損失を抑えやすい一方で、改修を繰り返すなら、累計の費用がフルスクラッチの初期投資を上回らないかで比べます。

法改正対応・特定帳票改修といった典型案件での使い分け

実際にレガシーシステム改修の現場で頻繁に発生する典型案件について、部分改修とフルスクラッチのどちらが適しているかを具体的に見ていきます。

法改正対応は数十万円規模の部分改修が原則

インボイス制度対応や消費税率変更といった法改正対応は、税務上「20万円未満」「60万円未満(取得価額の10%以下)」であれば修繕費として処理できる基準が示されています。こうした基準を踏まえると、軽微な法改正対応は、数十万円規模の低予算な部分改修で実施されるケースが多いとうかがえます。

法改正対応だけを理由にフルスクラッチを検討する企業はほとんどなく、こうした案件は、フォーマット変更や税額計算の仕様変更等の部分改修で、原則として対応すべき典型例です。

ただし、法改正への対応が繰り返し発生し、そのたびに既存システムの構造上の制約で対応コストが膨らんでいる場合は、システム自体の限界を示すサインといえます。フルスクラッチへの移行を検討すべき局面が近づいている可能性があります。

特定帳票・軽微な画面修正の保守契約内での対応

帳票フォーマットの変更や、画面の表示項目順序の変更といった案件は、保守契約の対象外となることが多いです。実作業は30分〜1時間程度でも、1件あたり10万〜12万円程度の追加費用(最低作業料金)が請求されるケースがあります。

この規模の改修にフルスクラッチはまったく見合いません。保守契約の枠内か、チケット制のような軽量な契約形態で完結させるべき、典型的な部分改修案件です。

逆に、複数の帳票にまたがる仕様変更が同時多発している場合や、帳票出力の基盤が老朽化して、どの帳票も改修のたびに苦労する場合は、話が変わります。こうした状態では、個別対応を積み重ねるよりも、帳票出力機能をモジュール単位でリライトするほうが、長期的な費用対効果は高くなります。

ポイント

法改正対応や特定帳票の軽微な改修は、原則として部分改修で対応します。改修が繰り返し重なって対応費用が膨らむ場合に限り、フルスクラッチやリライトを検討します。

部分改修からフルスクラッチへの移行を見極める判断基準

部分改修とフルスクラッチの選択に使う将来の業務要件、現行システムの品質、予算と期間の制約、ブラックボックス度を4枚のカードで示した図。
4つの観点をそろえて確認すると、選択の抜けを減らせます。

どちらの手法を選ぶべきかは、以下の4つの軸で判断することが推奨されています。これらは、部分改修を続けるか、フルスクラッチへ切り替えるかを見極める実務的な指標になります。

将来の業務要件・現行品質・予算制約・ブラックボックス度の4軸

1つ目は将来の業務要件です。今後その業務を大きく変える予定がなければ、中身だけを最新化するリライトなどの部分改修で足ります。一方で、業務プロセスそのものを抜本的に見直したい場合は、フルスクラッチの出番です。

2つ目は現行システムの品質と限界で、安定して動いているなら部分改修での延命が有効ですが、設計が破綻しかけているなら、フルスクラッチを視野に入れます。3つ目は予算と期間の制約です。限られている場合は、全面刷新を最初から狙うと失敗しやすいため、課題の大きい部分に絞って段階的に改修するのが安全です。

4つ目はブラックボックス度です。作った人が退職して誰も仕様を説明できない状態であれば、いきなりフルスクラッチやリライトに着手すべきではありません。何の手法を選ぶにせよ、現行システムの中身を解明して仕様を文書にまとめる「読める化」を最初に行うことが、失敗を防ぐうえで欠かせません。

「改修疲れ」がフルスクラッチ検討開始のサイン

部分改修を繰り返すと、改修のたびに影響範囲の調査へ膨大な時間がかかるようになり、改修要望を「今回は見送ろう」と判断する場面が増えていきます。こうした状態は「改修疲れ」と呼ぶべきもので、部分改修という選択肢そのものが限界に近づいているサインです。

そのため、こうした兆候が複数見られるようになったら、次の改修要望が発生した時点で、部分改修を続けるかフルスクラッチへ切り替えるかを一度立ち止まって検討する価値があります。低予算・短納期という部分改修のメリットを保つためにも、限界を迎える前に見極めのタイミングを逃さないことが大切です。

ポイント

部分改修の継続かフルスクラッチへの切り替えかは、将来の業務要件・現行品質・予算制約・ブラックボックス度の4点で判断します。改修疲れの兆候が複数見えたら、次の改修要望の時点で切り替えを検討します。

低予算・短納期を実現する依頼先選定

部分改修とフルスクラッチのどちらを選ぶにしても、依頼先を誤ると、低予算・短納期という前提そのものが崩れてしまいます。そのため、依頼先の見極め方を押さえておくことが欠かせません。

部分改修とフルスクラッチを中立的に助言できるパートナー

フルスクラッチの提案に一辺倒なベンダーに相談すると、本来は部分改修で足りる課題まで、大規模プロジェクトとして提案されてしまうおそれがあります。逆に、部分改修しか手掛けていないベンダーでは、システムが「改修疲れ」の限界を迎えていても、その兆候を見抜けないまま場当たり的な対応を繰り返す可能性があります。

依頼先を選ぶ際は、対象言語や基盤(COBOLや汎用機等)の解析実績に加えて、部分改修とフルスクラッチの両方の実績があるかを確認します。そのうえで、自社の状況を踏まえてどちらが適切かを、中立的な視点で助言してくれるかが大切です。

継続的な保守・改修パートナーとして長く付き合える体制

部分改修は一度きりで終わらず、法改正対応や特定帳票の改修のように、今後も繰り返し発生するものです。単発の案件を別々のベンダーに発注し続けると、システムの構造理解がベンダー間で引き継がれず、依頼のたびに調査からやり直すことになり、結果的にコストも期間も膨らみます。

低予算・短納期を実現し続けるには、最初の部分改修の段階から、長期的に付き合える保守・改修パートナーを選び、システムへの理解を蓄積してもらうことが最も効果的な投資です。

ポイント

依頼先は、部分改修とフルスクラッチの両方の実績があり、どちらが適切かを中立的に助言してくれるかで選びます。さらに、保守や改修を長く任せられる体制かどうかも、判断の材料になります。

まとめ

ここまで、レガシーシステム改修のフルスクラッチ・オーダーメイド開発を、規模感の違い、費用・期間の比較、典型案件での使い分け、移行の判断基準、依頼先の選定という順に見てきました。部分改修は費用500万〜8,000万円・期間数週間〜1年、フルスクラッチは費用8,000万〜数億円以上・期間半年〜複数年と、両者は一桁以上異なる規模感です。

法改正対応や帳票改修といった典型案件は、原則として部分改修で対応すべきです。ただし、改修のたびに調査工数がかさむ「改修疲れ」の兆候が見えてきたら、フルスクラッチへの移行を検討すべき時期です。

将来の業務要件・現行システムの品質・予算制約・ブラックボックス度という4つの軸で定期的に見極めながら、部分改修とフルスクラッチの両方を中立的に助言できるパートナーに、早い段階から相談することをお勧めします。

▼全体ガイドの記事
・レガシーシステム改修の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。