レガシーシステム改修の選定ポイント/選び方/種類

レガシーシステムの改修を検討し始めると、単純なバグ修正を得意とするベンダー、法改正対応のスピードに強いベンダー、COBOLなど特定言語の保守に精通したベンダーなど、幅広い選択肢が見つかります。金額の安さや対応の速さだけで選ぶと、肝心の調査工程が省略され、改修後に想定していなかった箇所で不具合が発生することも少なくありません。選定の出発点は、自社がどの業務でどの程度の困りごとを抱えているかを具体的に言語化することです。

本記事では、レガシーシステム改修を検討する前に整理すべき自社の課題、対応内容による3つの分類、改修パートナーを比較する評価軸、リホスト・リライト・ストラングラーフィグパターンといった改修手法の選び分け、見積り依頼やPoCの進め方を解説します。これから改修の相談先を探す担当者の方が、比較条件をそろえて2〜3社まで具体的に絞り込める内容です。

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

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

レガシーシステム改修を検討する前に整理すべき自社の課題

改修を検討する際にまず行うべきは、ベンダーを探すことではなく、どの業務で・どの程度の困りごとが起きているかを特定することです。困りごとを一文で説明できれば、必要な対応範囲と依頼すべき相手が見えやすくなります。

日常的に発生する不具合修正は、保守契約のSLA（対応開始までの合意時間）に基づいて進めることが一般的です。一方、インボイス制度や消費税率の変更のような法改正対応は、制度の発表段階からできるだけ早く動き出す必要があり、対応が遅れるほど法的なリスクが高まります。両者を同じ優先度で扱うのではなく、緊急度と影響範囲を分けて整理することが選定の出発点になります。一般的なシステム保守費用は、初期開発費用の年間15〜20%程度が目安とされ、月額換算では小規模なシステムで数万円〜10万円前後、中規模なシステムで10万〜50万円程度が一つの相場観になります。自社が支払っている保守費用がこの目安から大きく外れている場合、対応範囲や契約条件を見直す余地があるかもしれません。

改修対象のシステムについて、設計書や仕様書がどこまで残っているか、開発当時の担当者が社内に在籍しているかを確認します。ドキュメントが不足し、担当者も不在という状態では、事前調査に想定より多くの工数がかかる可能性が高くなります。前任不在・ドキュメントなしの状態から改修に着手したアパレル業界の品質管理システムの事例では、インフラ改善と機能改善を合わせて10か月ほどの期間を要しています。自社の状況がこれに近いのか、比較的整理されているのかによって、依頼すべきパートナーの調査力の重要度も変わります。レガシーシステムに特有のコスト増要因として、ドキュメント不足や担当者の属人化により、調査や原因切り分けの工数が想定より膨らみやすい点も挙げられます。見積もり比較の際は、金額の水準だけでなく、こうした不確実性をどのように前提条件へ織り込んでいるかも確認しておくと、着手後の想定外を減らせます。

対応内容による改修の3つのタイプ

レガシーシステム改修は、対応内容によって大きく3つのタイプに分けられます。実際の依頼内容は複数のタイプにまたがることもあるため、分類名よりも自社が最優先する対応を確実に実施できるかを確認します。

既存の保守契約の範囲内、またはその延長として、日常的な不具合の修正や、インボイス制度・電子帳簿保存法・税率変更といった法改正への対応を行うタイプです。対応開始までの時間や優先順位づけの基準があらかじめ合意されているかどうかが重要になります。急を要する法改正対応では、通常の保守窓口とは別に、優先的に対応してもらえる体制があるかも確認しておくと安心です。また、帳票フォーマットの変更や画面の軽微な修正のように保守契約の対象外になりやすい依頼まで、同じ窓口で柔軟に受け付けてもらえるかどうかも、日常的な運用のしやすさを左右します。

帳票フォーマットの変更や画面の軽微な修正、新しい業務に合わせた機能追加を行うタイプは、既存の保守契約の対象外になっていることが多く、都度見積もりで進むのが一般的です。もう一つは、機能・モジュール単位で新しいシステムへ段階的に切り出すストラングラーフィグパターンや、機能は変えずに中身だけを新しい技術で書き直すリライトのように、部分的な作り直しを行うタイプです。対象範囲が広がるほど、影響調査やテストの比重も大きくなるため、見積もり時にどこまでの範囲を含むかを明確にする必要があります。中規模の部分的な作り直しになると、費用の目安は2,000万〜8,000万円、期間は数か月〜1年程度に広がることもあるため、対象範囲が広がった時点で見積もりの前提条件を改めて擦り合わせることが欠かせません。

改修パートナーを比較する評価軸

改修パートナーは、調査力、対応言語・技術への精通度、テスト体制、契約形態の柔軟性、セキュリティという軸で比較します。同じ質問を各社へ投げかけ、回答の根拠までそろえることで、印象ではなく実務能力で判断できます。

第一に、事前調査・変更箇所調査・影響調査という3段階の調査プロセスを実際に踏んでいるか、成果物としてどのような資料を残してもらえるかを確認します。第二に、COBOLや汎用機など、対象システムで使われている言語や技術に精通しているかどうかです。実績のある言語であっても、自社が使用しているバージョンや独自の拡張仕様まで対応できるとは限らないため、類似案件の経験を具体的に確認します。あわせて、調査の成果物として構造図や仕様書をどのような形式で残してもらえるかも確認しておくと、次回以降の改修や他ベンダーへの引き継ぎがしやすくなります。

第三に、デグレードテストをどこまでの範囲で実施するか、テスト工程にどの程度のバッファを見込んでいるかを確認します。第四に、月額固定型、従量課金・時間課金型、チケット制・ポイント制のうち、自社の改修頻度に合う契約形態を用意しているかを確認します。第五に、改修対象のデータや仕様書を預ける以上、アクセス権限の管理、作業ログ、機密保持契約の内容も比較対象に含めます。これらを「デモで確認」「提案書で確認」「契約条項で確認」のように証拠を残しながら評価すると、営業説明の分かりやすさだけに評価が引っ張られにくくなります。チケット制・ポイント制を採用しているパートナーの場合は、1チケットで対応できる作業範囲の目安や、有効期限、余ったチケットの扱いまで確認しておくと、不定期な改修依頼にも無駄なく対応しやすくなります。

リホスト・リライト・ストラングラーフィグの選び分け

改修の実務では、リホスト、リライト、ストラングラーフィグパターンなど、複数の手法から自社に合うものを選びます。将来の業務要件、現行システムの品質、予算と期間、仕様のブラックボックス度という4つの軸で判断すると絞り込みやすくなります。

業務要件を大きく変える予定がなく、現行システムが安定して稼働している場合は、動作環境だけを新しい基盤に移すリホストや、機能は変えずに中身だけを新しい技術で書き直すリライトが現実的です。特にリライトは、既存の業務ロジックをそのまま踏襲できるため、全面刷新よりも検証範囲を狭められる利点があります。ただし、リライト自体もコードの読み解きに時間がかかるため、事前調査を省略できるわけではありません。リホストを選ぶ場合は、動作環境を変えることで生じる細かな挙動差が業務に影響しないか、リライトを選ぶ場合は、既存の計算ロジックや例外処理を漏れなく引き継げるかを、それぞれ個別に確認しておく必要があります。

現行システムの品質に不安があり、将来的にはより大きな作り直しを見据えている場合は、機能・ドメイン単位で新システムへ段階的に切り出すストラングラーフィグパターンが選択肢になります。業務を止めずに段階的な移行を進められる一方、新旧システムを一時的に併存させる仕組みが必要になるため、予算と期間に一定の余裕がある場合に向いています。仕様がブラックボックス化していて誰も説明できない状態であれば、いきなりこうした作り直しに着手するのではなく、まず現状を「読める化」する調査から始めることが安全です。新旧システムを併存させる期間は、データの二重管理や連携不具合が発生しやすいタイミングでもあるため、切り出す機能の優先順位と、旧システム側をいつまで維持するかの終了条件をあらかじめ合意しておくことが重要です。

見積り依頼とモックアップ・プロトタイプ・PoCの進め方

比較対象を絞り込んだ後は、見積り依頼の内容をそろえ、必要に応じてモックアップやプロトタイプ、PoCで実現性を確認します。デモや資料だけで判断せず、実際の対象業務を使って検証することが重要です。

見積り依頼には、対象業務、現状のドキュメントの有無、想定される不具合や変更内容、希望する納期、デグレードテストを含めるかどうかを明記します。同じ内容を複数社へ同条件で提示することで、金額だけでなく、調査工数の見積もり方や前提条件の違いを比較できます。値引きの大きさではなく、調査や影響範囲の洗い出しをどこまで含めているかを確認することが、着手後のトラブルを避けるうえで重要です。あわせて、法改正対応のように納期の融通が利きにくい依頼と、帳票改修のように比較的スケジュールに余裕を持たせやすい依頼を分けて提示すると、各社の対応力の違いも比較しやすくなります。

画面レイアウトの確認だけであれば、開発コストがほぼかからないモックアップで十分です。操作フローや使い勝手を確認したい場合はプロトタイプが向いていますが、既存システムとの連携までは検証できません。既存システムへ新しい技術や外部ツールを組み込めるかどうかという技術的な実現性を確認したい場合は、PoC（概念実証）が必要です。部分改修のPoCは、対象業務を1つに絞り込み、明確なGo/No-Go基準を事前に設定したうえで、期間2〜3週間程度、費用は本開発の10〜20%程度を目安に実施すると、必要以上に予算をかけずに実現性を確認できます。

レガシーシステム改修選定の失敗を避ける方法

よくある失敗は、金額の安さや対応スピードの速さだけで比較し、調査工程の質やテスト範囲を確認しないことです。改修の目的と責任者を明確にし、現場、情報システム、経理など関係者の視点を選定に反映します。

見積金額が低いベンダーでも、事前調査や影響調査を簡略化している場合、改修後に想定外の不具合が発生し、結果的に追加費用がかさむことがあります。反対に、調査工程を丁寧に行うベンダーは、着手前の段階でやや費用が高く見えることもありますが、手戻りの少なさで総コストを抑えられる場合もあります。金額だけで判断せず、調査・テストの範囲まで含めた条件で比較してください。具体的な製品・ツールの候補を確認したい場合は、レガシーシステム改修のパッケージ・クラウド製品一覧を参照すると、ツール選定の共通軸を把握しやすくなります。

帳票改修や軽微な機能追加が保守契約の対象外であることを把握しないまま契約すると、実作業が数十分程度でも高額な最低作業料金が発生し、年間の追加費用が想定より膨らむことがあります。月額固定型、従量課金型、チケット制・ポイント制のうち、自社の改修頻度に合う契約形態を選び、追加費用が発生する条件を契約前に明文化しておくことが重要です。契約前に、月額保守費用に含まれる作業時間の上限や、上限を超えた場合の追加料金の単価まで具体的に確認しておくと、年間を通じた総コストの見通しが立てやすくなります。

レガシーシステム改修導入前に確認しておきたいポイント

候補を絞った後は、対象範囲の広さだけでなく、契約形態や検証方法、社内の受け入れ体制まで確認します。比較表の項目だけでは見えにくい条件を事前に確認することで、着手後に運用が止まるリスクを抑えられます。

対応内容が小規模であっても、調査の丁寧さやテスト範囲によって、着手後の手戻りの発生しやすさは大きく変わります。金額だけでなく、事前調査の進め方や過去の類似案件の実績を複数社で比較する価値があります。

社内に開発担当者がいて仕様も把握できている場合は、自社対応で完結できることもあります。一方、仕様がブラックボックス化し、誰も説明できない状態であれば、まず現状把握の調査から外部に依頼し、対応範囲を明確にしたうえで改修へ進む方が安全です。

部分改修のPoCは、対象業務を1つに絞り込むことで、期間・費用を抑えて実施できます。目安として、期間は2〜3週間程度、費用は本開発の10〜20%程度とされますが、検証範囲が広がるほど費用も膨らむため、事前にGo/No-Go基準を明確にしておくことが重要です。

まとめ

レガシーシステム改修の選定では、不具合対応・法改正対応・帳票改修・部分的作り直しという自社の課題を特定し、調査力、対応言語・技術、テスト体制、契約形態、セキュリティという評価軸で候補を比較します。そのうえで、リホスト・リライト・ストラングラーフィグパターンといった手法を、将来の業務要件・現行システムの品質・予算と期間・ブラックボックス度の4軸で選び分けることが重要です。

まず自社のどの業務でどの程度の困りごとが起きているかを特定し、対応内容による3つのタイプのどれに近いかを整理します。そのうえで、調査力やテスト体制、契約形態といった評価軸で複数のパートナーを比較すれば、金額だけに引っ張られない選定ができます。あわせて、リホスト・リライト・ストラングラーフィグパターンのどれが自社の状況に近いかも早い段階で仮決めしておくと、パートナーへの相談内容が具体的になり、見積もりの精度も上がります。

見積もりの比較だけで決めるのではなく、必要に応じてモックアップやプロトタイプ、PoCで実際の対象業務を使った検証を行うことが、着手後の想定外を減らします。既存のパッケージやツールでは対応しきれない独自の業務ロジックや複雑な影響範囲を持つ改修には、フルスクラッチ開発の知見が必要になる場合があります。riplaはフルスクラッチ開発の立場から、改修範囲の切り分けや事前調査、既存システムとの連携を含む改修の実装までを支援しています。

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

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。