レガシーシステム更改は、現状の可視化（アセスメント）、要件定義、RFP作成の順に進めます。この順で進めると、曖昧な発注による見積りのぶれや、移行後の不具合、炎上を防げます。
更改全体の手法・費用・進め方はレガシーシステム更改の完全ガイドで扱っています。上流工程の詳細とあわせてご覧ください。
▼全体ガイドの記事
・レガシーシステム更改の完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
更改アセスメント：現状（AS-IS）の可視化
レガシーシステム更改は、現状（AS-IS）を可視化するアセスメントから始めます。現状が不明なままでは、移行対象や費用、期間を見積もれません。分析の不足は、刷新の失敗の多くに関わります。
IT資産棚卸しと依存関係の可視化
アセスメントの中核は、IT資産の棚卸しです。棚卸しでは、業務を動かしている仕組みを4つの面から洗い出します。
- プログラム：モジュールごとの利用状況と対応業務
- データベース：現役データと履歴として保持するデータ
- 外部連携：接続先とデータの受け渡し形式
- バッチジョブ：処理の順序と実行タイミング
対象ごとに、どの業務と対応しているか、現在どれくらい使われているかを明らかにします。長年改修を重ねたシステムには、廃止された業務だけを処理するデッドコードが残っていることがあります。実際に、ある製造業では、棚卸しによって移行が必要なプログラムを想定の約60%まで絞り込めました（出典：各社公開資料に基づく相場感）。
手作業での把握が難しい大規模システムでは、ツールの利用も選択肢になります。富士通の「ソフトウェア地図」は、資産の複雑度や依存関係を地図のように可視化し、全体像を客観的に把握する助けになります（出典：富士通）。
さらに、複雑度や依存関係を効率よく把握するツールも登場しています。現状を正確に映し出せるかどうかが、要件定義とRFPの精度を左右します。
仕様書がなくても、棚卸しの結果から現状を再構築できます。その結果は、見積りと移行計画の土台になります。時間をかけて整えることで、更改全体の手戻りを減らせます。
保守期限・EOLの棚卸しと優先度の判定
更改では、保守期限とEOLを棚卸しておく必要があります。ハードウェアからミドルウェアまで、層ごとに期限を分けて確かめます。
- ハードウェア：保守契約の満了日
- OS・データベース：サポート終了日
- ミドルウェア：バージョンごとのEOL
資産ごとの期限を並べると、どこから着手すべきかの優先順位を決められます。ただし、大量の機器を抱える企業では、棚卸し自体が大変になります。
ユニリタの事例では、200種・30,000台のネットワーク機器と10,000台のサーバーを対象としました。さらに、1日10億件の通信ログを集計し、保守費の高い機器や利用実態を可視化して優先度を判定しました（出典：ユニリタ）。期限と効果の両面から、予算と期間に応じた更改ロードマップを描けます。
期限を正しく棚卸ししておくと、要件定義のスコープを現実的にします。アセスメントの成果物は、現状構成図と資産一覧です。
このほかに、保守期限・EOL一覧や業務とシステムの対応表も作ります。これらは要件定義の入力になり、後工程でベンダーに渡すRFPの基礎資料にもなります。
調査を単発で終わらせず、更改全体を貫く土台として扱います。曖昧なまま進めると、要件定義や移行で現状確認の手戻りが繰り返されます。
更改の要件定義で押さえるべき観点
現状と期限が見えたら、次は要件定義に進みます。基本となるのは、現行と同じ業務を新しい基盤で確実に動かすことです。
要件定義では、移行範囲、非機能要件、移行方式を明確にします。そのうえで、現行踏襲を軸に、今回満たす範囲を定めます。
移行範囲の確定と非機能要件の明文化
移行範囲は、「残す・捨てる・載せ替える」の仕分けをもとに、今回の範囲を線引きします。期限を優先し、機能改善を次のサイクルに回す判断も書き残します。
範囲が曖昧なままだと、ベンダーとの認識がずれ、追加費用につながります。また、更改では非機能要件の明文化が特に重要で、性能からKPIまでを具体的な数値で書ける形にしておくことが欠かせません。
- 性能：バッチ処理時間やレスポンス
- 可用性：稼働率や障害時の復旧時間
- セキュリティ：サポートOS・DBとパッチ適用
- KPI：移行後に達成したい指標
移行後のKPIは、具体的な数値で目標を置いて定めます。たとえば、夜間バッチを現行の8時間以内に収める条件を定めます。同様に、現行の性能水準を下回らないことや、EOL解消を検収基準にできます。
データ移行とテスト・移行方式の要件化
レガシーシステムには独自形式のデータが多く含まれます。そのため、変換方法と移行後の検証方法を要件に定めておく必要があります。
データマッピングの複雑さやユーザー部門の参画不足は、パッケージ導入で失敗する要因になります。移行と検証を具体化して後の炎上を防ぐには、移行の進め方そのものを要件に入れておく必要があります。
- 並行稼働：新旧を動かす期間
- 出力検証：新旧の結果を突合する方法
- 切り戻し：ロールバックを行う条件
一括で切り替えるビッグバン方式はリスクが高いため、機能単位で移すストラングラーパターン（段階移行）を前提にするケースが多くなっています。
新規開発のように「やりたいこと」を広げすぎないことも大切です。期限を優先し、現行踏襲を基本に据えます。さらに、要件定義の精度はRFPの質に直結するので、十分な時間をかけて進めます。
業務改革や新機能は、別フェーズに分けて扱います。「ついで」の要望を安易に加えると、スコープが膨らみ、期限内の更改が破綻するおそれがあります。今回必須の要件と将来の改善要件を線引きしておくと、この区分によって要件定義の質を保てます。
RFPに盛り込む項目とベンダー評価基準
要件定義をまとめたら、その内容をベンダーへ伝えるRFPに落とし込みます。現状と要件を示しておけば、各社の提案を同じ条件で比べられます。
RFPは、現状の正確な情報と達成要件を過不足なく示し、各社の提案を同じ土俵で比べるための資料です。盛り込む項目と評価基準も、この前提にそろえておきます。
RFPに必ず記載すべき項目
更改のRFPには、最低限、現状、期限、移行条件、運用の引き継ぎ範囲を記載します。各社が同じ前提で提案できるよう、これらの材料を揃えておきます。
- 現行情報：構成図とハード・OS・DB・言語
- 期限：保守期限・EOL一覧と目標完了時期
- 移行範囲：「残す・捨てる・載せ替える」の仕分け
- 要件：性能・可用性・セキュリティ、移行後KPI
- 移行・運用：データ移行、テスト、並行稼働、切り戻し、方式、保守運用の引き継ぎ
現行構成図や保守期限が曖昧だと、ベンダーは安全側に見積もり、各社の前提もばらつきます。その結果、提案の比較が難しくなります。
可視化した現状を正確に反映することは、適正な見積りと公平な比較の前提になります。要件定義と業務棚卸しだけを先に依頼する場合、費用の目安は200万〜500万円程度です（出典：各社公開資料に基づく相場感）。
更改ベンダー選定の5つの評価ポイント
提案を受け取ったら、価格や見栄えだけで判断せず、同じ基準で各社を評価します。判断の軸は、実績から第三者認証まで5つの観点に分けて見ていきます。
- 実績：同業界・同規模のレガシー更改を完遂したか
- 設計力：段階移行を前提に設計できるか
- 移行計画：停止時間と切り戻しの見積りが具体的か
- 運用体制：24時間365日を含む保守体制があるか
- 第三者認証：ISO9001やISO27001などを取得しているか
段階移行の設計力と、切り戻しを含むリスク管理は、価格以上に重要です。実際に、安さを優先した結果、移行計画の甘さから業務停止を招いた事例も報告されています。
評価項目に重みを付けて点数化すると、社内で合意を取りやすくなります。止められない基幹業務では、段階移行の設計力と停止時間の見積りに、より重い比重を置きます。
コスト制約が厳しい案件では、実績と価格のバランスを重視します。関係者が同じ評価表で採点すれば、担当者の主観や営業力で判断が左右されにくくなります。
RFPに要件を明示し、5つの評価点で各社を採点するかどうかが、更改全体の成否を左右します。発注の判断も、客観的に説明できます。
まとめ
レガシーシステム更改の上流工程は、アセスメント、要件定義、RFPの順に進めます。資産と期限を可視化したうえで、移行範囲や非機能要件、データ移行の方法を定めます。
RFPには現行構成図と期限一覧を示し、5つの評価ポイントでベンダーを選びます。上流工程をこの規律で進めることが、更改成功の土台になります。
上流工程には時間がかかりますが、丁寧に進めるほど下流の移行はスムーズになります。資産棚卸しによって移行対象を想定の約60%に絞り込んだ製造業の例もあります。
現状を把握すると、不要な移行を減らしてコストを下げる効果もあります。ただし、期限に追われても、アセスメントと要件定義は省略しないことが成功の前提です。
更改が失敗する原因は、現状分析の不足や要件の曖昧さにあることがあります。そのため、時間と費用をかけて精度の高いRFPを作れば、見積りのぶれや移行後の混乱を減らせます。
riplaは、資産棚卸しから要件定義、RFP作成、ベンダー選定まで支援しています。現行システムがブラックボックス化している場合も、アセスメントからご相談ください。
▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。