レガシーシステムの刷新は、現状分析と要件定義、RFP作成、ベンダー評価の順に進めると、要件の漏れや移行後の追加費用を抑えやすくなります。
発注前の準備文書に絞り、RFPに書く項目とベンダー評価の観点を取り上げます。全体像はレガシーシステムのモダナイゼーションの完全ガイドもご覧ください。
▼全体ガイドの記事
・レガシーシステムのモダナイゼーションの完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
刷新の成否を分けるアセスメントと要件定義
レガシーシステムの刷新は、ゼロからの新規開発とは性質が異なります。稼働中の業務を止めずに置き換える必要があるうえ、現行仕様が分からない状態から始まることも少なくありません。
そのため、「現状が見えない」まま発注すると、要件の抜け漏れが移行後に一気に表面化します。アセスメントと要件定義の精度が、後工程の手戻りや刷新全体の成否を左右します。
刷新失敗の大きな原因である要件定義の不十分さ
刷新計画が止まる最大の要因は、技術的な難しさよりも要件定義の不十分さです。
- 設計書の陳腐化：改修を重ねるうちに、設計書と実際の挙動が食い違っていることがあります
- 仕様知識の喪失：開発や保守の担当者が退職し、社内に仕様を説明できる人がいない場合があります
要件が固まらないまま発注すると、ベンダーは把握できた範囲だけで見積もりや設計を進めます。移行後に隠れた業務ルールや例外処理が見つかると、追加開発や費用が膨らみやすくなります。現行システムの実態をどこまで要件定義に明文化できるかで、後工程の手戻りの大きさが決まります。
「2025年の崖」という背景と準備の重要性
準備の重要性を裏づける、国のレポートと企業調査には次の指摘があります。
- 対象システム：老朽化・複雑化・ブラックボックス化したシステム
- 経済産業省の指摘：未刷新のまま2025年を迎えると、その後、年間最大12兆円の経済損失が生じる可能性があります（出典：経済産業省）
- JUASの調査：約7割の企業が、既存システムのレガシー化を経営課題と認識しています
崖が迫っていても、準備を省いて急いで発注すると、失敗のリスクが高まります。限られた予算と時間を生かすには、まず現状を洗い出し、優先する範囲を見極める必要があります。アセスメントと要件定義に手間をかけることは、刷新を成功させるための準備にほかなりません。
アセスメント段階での現状（AS-IS）可視化の進め方
要件定義の前に、アセスメントで現状（AS-IS）を見える形にしておきます。システムの構成や連携先、支えている業務を、客観的な事実として洗い出す作業です。
AS-ISが曖昧なまま「こうあるべき（TO-BE）」を描くと、現実とのギャップが見えません。そのため、移行計画が机上の空論になりかねません。アセスメントの精度は、その後に作る文書の土台になります。
資産棚卸しで把握すべき項目
刷新対象の規模と複雑さをつかむため、資産棚卸しでは、システムを構成する要素と業務での利用実態を確認します。
- ハードウェア・ミドルウェア：構成の確認
- アプリケーション：プログラムの本数と言語
- データベース：テーブル構造とデータ量
- 連携先：他システムとのインターフェースの洗い出し
- 業務プロセス：各機能が支えている業務の把握
一覧にまとめると、刷新対象の全体規模と複雑度を数値で把握できます。あわせて、各機能が今も使われているか、廃止できる機能はどれかも調べます。
使われない機能を刷新対象に含めると、その分の工数とコストが無駄になります。利用実態まで調べておけば、刷新範囲を決める判断材料が揃います。
依存関係を可視化するツールの活用
大規模なレガシーシステムでは、プログラムの呼び出し関係やデータの流れが複雑で、人手だけでは全容を把握しにくいことがあります。可視化ツールは、次のように現状把握を支援します。
- 資産の解析：アプリ資産の複雑度や依存関係を可視化
- ソフトウェア地図：富士通が提供する可視化ツール
- ソースコード分析：勘や記憶に頼らず現状を把握
- 依存関係マップ：ベンダーへ現状を伝える共通言語
富士通の「ソフトウェア地図」は、膨大なプログラム群の構造や依存関係を俯瞰できるツールです。刷新の難所を早い段階で特定する助けになります（出典：富士通）。アセスメントの精度を高めたいときは、可視化ツールの導入に加えて、それを活用できるパートナーの起用も検討できます。
アセスメント費用の目安
費用を見積もる際は、金額の目安と発注方法、準備を省いた場合のリスクをあわせて確認します。
- 切り出し費用：要件定義や業務棚卸しだけなら、200万〜500万円程度に収まることが多い
- 独立発注：この段階だけを切り出し、現状を把握する方法も有効
- 省略時のリスク：後から数千万円規模の追加費用が発生する場合がある
なお、費用はシステムの規模や複雑度、業務範囲の広さによって変わります。アセスメントと要件定義は、刷新本体への投資を守る保険です。
これを余分なコストと見るか、失敗を防ぐための必要な投資と見るかで、成否は変わります。さらに、この先行投資は刷新全体の予算精度を高めます。
RFP（提案依頼書）に含めるべき項目
アセスメントと要件定義で固めた内容を、ベンダーに伝える文書がRFP（提案依頼書）です。RFPの質が低いと、各社は前提を自分で補って見積もるため、提案がばらつき、比較できなくなります。
必要な情報をそろえて示せば、各社を同じ条件で比べられ、自社に合うパートナーを選べます。そこで、レガシー刷新のRFPに含める項目を順に見ていきます。
現行構成図・性能要件・移行後KPI
RFPでは、現状と目標をベンダーが把握できるよう、次の情報をそろえます。
- 現行構成図：アセスメントで把握したハードウェア、ソフトウェア、連携先を図示
- 性能要件：処理件数、応答時間、夜間バッチの完了時間などの定量基準
- 移行後のKPI：保守費削減率や処理時間短縮率など、刷新後の目標値
この情報があれば、ベンダーは出発点と目標を共有したうえで提案できます。特にKPIを数値で示しておくと、目標の達成にどれだけ寄与するかを基準に、提案を評価できます。RFP作成の要点は、要望を曖昧にせず、測定できるゴールを設定することです。
前提要件として盛り込む移行方式（段階移行）
RFPには移行方式の前提条件も書き込み、方式ごとの切り替え方とリスクをベンダーに伝えます。
- ビッグバン方式：一度にすべてを切り替えるため、当日に問題が起きたときの影響が大きく、レガシー刷新ではリスクを伴います
- 段階移行：機能や業務ごとに切り替え、RFPに明記して現実的なリスク管理の提案を促す
ストラングラーパターンは、既存システムを稼働させたまま、その周囲に新しい機能を段階的に作り、最終的に旧システムを置き換える方法です。段階移行は一括移行より切り替えリスクを分散でき、各段階で効果を検証できます。さらに、RFPで方式を示しておけば、ダウンタイムや移行リスクへの対応力も確認できます。
ベンダー評価の5つのチェックポイント
RFPを各社に提示して提案を受け取ったら、ベンダーを評価して選定します。価格だけで判断すると、安さに隠れたリスクを見落とすおそれがあります。
難度の高いレガシー刷新では、技術力と実績に加えて、体制や信頼性も多面的に評価します。提案書を読む評価軸として、5つのチェックポイントを順に見ていきます。
実績と段階移行の設計力
実績と設計力では、次の2点を確認します。判断材料になるのは、自社に近い経験と、移行計画の具体性です。
- 同業界・同規模の実績：近い業界や規模のレガシー刷新経験
- 段階移行の設計力：ストラングラーパターンなどを具体化できるか
同業界・同規模の実績からは、業務特有の要件や落とし穴への理解度が分かります。移行設計では、提案書に機能を移す順番や並行稼働期間まで具体的に示されているかを確認します。「段階的に移行する」といった抽象的な説明にとどまらず、手順まで具体化しているかが、実行力を見極める手掛かりになります。
ダウンタイム見積り・保守体制・認証
移行の品質と運用後の安心を判断するには、次の3点を確認します。
- ダウンタイム見積り：業務停止時間を具体的かつ現実的に算出しているか
- 24時間365日の保守体制：障害やトラブル時の運用を支えられるか
- 品質・セキュリティ認証：ISO9001やISO/IEC27001などを取得しているか
ダウンタイムの数字があまりに楽観的な場合は、注意が必要です。現実的なリスクを見積もりに含めているかどうかは、ベンダーの誠実さや実力の表れといえます。
保守体制は刷新後の事業継続を左右します。また、ISO9001（品質マネジメント）やISO/IEC27001（情報セキュリティ）は、品質やセキュリティを支える仕組みを示す第三者認証です。5つの観点を合わせて見れば、価格の安さだけに頼らない選定につながります。
まとめ：アセスメントから始める刷新準備のポイント
レガシー刷新は、アセスメントと要件定義、RFP作成、ベンダー評価の順で準備を進めます。なかでも、失敗の大きな原因は要件定義の不足です。
仕様書がない場合や、ブラックボックス化している場合は、資産棚卸しと現状（AS-IS）の可視化で実態を把握します。
富士通の「ソフトウェア地図」のようなツールも、現状把握に使えます。要件定義と業務棚卸しだけなら200万〜500万円程度を見込み、アセスメントに先行投資すると、後の追加費用を防ぐ助けになります。
RFPには、現行構成図、性能要件、移行後KPIを含めます。ビッグバン方式を避け、段階移行（ストラングラーパターン）を前提要件として明示します。
ベンダーは5つの観点で総合評価します。同業界・同規模の実績と、段階移行の設計力を確認します。
ダウンタイム見積りや24時間365日の保守体制も評価します。ISO9001やISO/IEC27001などの認証も含め、価格だけで決めないことが大切です。
「2025年の崖」では、レガシーシステムを放置した場合に年間最大12兆円の経済損失が生じる可能性が指摘されています。急いで発注するより、現状分析を起点に丁寧に準備するほうが、刷新を成功させる近道です。
自社に合ったアセスメントや要件定義、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を創業。