レガシーシステムのモダナイゼーション（既存システムの刷新）を成功させられるかどうかは、ベンダーへ発注する前の「準備段階」でほぼ決まると言っても過言ではありません。実際に、刷新プロジェクトが頓挫する大きな原因のひとつが、要件定義の不十分さにあります。仕様書が失われていたり、長年の改修でブラックボックス化していたりする現行システムを、現状把握が曖昧なまま刷新しようとすると、移行後に「動かない機能」や「想定外の追加費用」が次々と表面化してしまうのです。経済産業省のDXレポートが警鐘を鳴らした「2025年の崖」では、レガシーシステムを放置した場合に年間最大12兆円もの経済損失が生じるリスクが指摘されており（出典：経済産業省）、刷新は待ったなしの経営課題となっています。
本記事では、レガシーシステムのモダナイゼーションを「アセスメント（現状分析・AS-IS可視化）→要件定義→RFP（提案依頼書）作成→ベンダー評価」という一連のプロセスに沿って、何を文書化し、どんな観点でベンダーを選ぶべきかに焦点を当てて解説します。全体像を体系的に整理したレガシーシステムのモダナイゼーションの完全ガイドもあわせてご覧いただくと、手法選定から費用感までの俯瞰がしやすくなります。本記事は、その中でも特に「発注前の準備文書」に絞り込み、RFPに含めるべき項目やベンダー評価のチェックポイントといった実務に直結する内容を、できるだけ具体的に掘り下げていきます。
▼全体ガイドの記事
・レガシーシステムのモダナイゼーションの完全ガイド
なぜアセスメントと要件定義が刷新成否を分けるのか
レガシーシステムの刷新は、ゼロから新規システムを開発するプロジェクトとは根本的に性質が異なります。すでに業務が回っている現行システムを止めずに置き換えなければならず、しかも現行の仕様が誰にも正確には把握できていないという状態から始まることが少なくありません。この「現状が見えない」という前提を軽視したまま発注に進むと、要件の抜け漏れが移行後に一気に噴出します。だからこそ、刷新の入口であるアセスメントと要件定義が、プロジェクト全体の成否を左右する最重要工程になるのです。
刷新失敗の大きな原因は要件定義の不十分さ
レガシー刷新プロジェクトが計画通りに進まない最大の要因は、技術的な難しさそのものよりも、要件定義の不十分さにあります。長年運用されてきたシステムは、当初の設計書が更新されないまま改修が積み重なり、実際の挙動と文書が乖離していることが珍しくありません。さらに開発・保守を担った技術者が退職し、仕様を説明できる人が社内に残っていない、いわゆるブラックボックス化が進行しているケースも多く見られます。
こうした状態で要件を固めずに発注すると、ベンダーは「見えている範囲」だけで見積もりと設計を進めてしまいます。その結果、移行後に隠れていた業務ルールや例外処理が発覚し、追加開発と追加費用が膨らむという典型的な失敗パターンに陥ります。要件定義の段階で現行システムの実態をどこまで明文化できているかが、後工程の手戻りの量を決定づけるのです。
「2025年の崖」という背景と準備の重要性
準備段階の重要性を後押しするのが、国レベルで定量化されたリスクです。経済産業省のDXレポートでは、老朽化・複雑化・ブラックボックス化したシステムを刷新しないまま2025年を迎えると、その後に年間最大12兆円の経済損失が生じる可能性があると指摘されています（出典：経済産業省）。これがいわゆる「2025年の崖」です。日本情報システム・ユーザー協会（JUAS）の調査でも、約7割の企業が既存システムのレガシー化を経営課題として認識していることが示されています。
とはいえ、崖が迫っているからといって準備を省いて拙速に発注することは、かえって失敗リスクを高めます。むしろ限られた予算と時間を有効に使うためにこそ、現状を正確に棚卸しし、優先すべき範囲を見極める準備工程が欠かせません。アセスメントと要件定義に十分な手間をかけることは、遠回りではなく、刷新を確実に成功へ導くための最短ルートだと言えます。
アセスメント段階での現状（AS-IS）可視化の進め方
要件定義の前段として必ず行うべきなのが、アセスメント、すなわち現状（AS-IS）の可視化です。これは「いま自社のシステムが何で構成され、どこと連携し、どんな業務を支えているのか」を客観的な事実として棚卸しする作業を指します。AS-ISが曖昧なまま「こうあるべき（TO-BE）」を描いても、現実とのギャップが見えず、移行計画が机上の空論になってしまいます。アセスメントは刷新の出発点であり、ここでの精度がその後のすべての文書の土台になります。
資産棚卸しで把握すべき項目
資産棚卸しでは、現行システムを構成する要素を漏れなく洗い出します。具体的には、ハードウェアやミドルウェアの構成、アプリケーションのプログラム本数とその言語、データベースのテーブル構造とデータ量、他システムとの連携インターフェース、そして各機能が支える業務プロセスといった項目が対象です。これらを一覧化することで、刷新対象の全体規模と複雑度が初めて数値として見えてきます。
棚卸しの際に重要なのは、単なる技術資産のリスト化にとどめず、「どの機能が現在も実際に使われているのか」「廃止できる機能はどれか」という利用実態まで踏み込むことです。長年の運用で誰も使わなくなった機能を、そのまま刷新対象に含めてしまうと、不要な工数とコストが発生します。資産棚卸しは、刷新範囲を適正にスコープするための判断材料を集める工程でもあるのです。
依存関係を可視化するツールの活用
大規模なレガシーシステムでは、プログラム同士の呼び出し関係やデータの流れが複雑に絡み合い、人手だけで全容を把握するのは困難です。そこで近年は、アプリケーション資産の複雑度や依存関係を機械的に解析し可視化するツールが活用されています。たとえば富士通が提供する「ソフトウェア地図」は、膨大なプログラム群の構造や依存関係を俯瞰できる形に可視化し、どこが刷新の難所になるかを早期に特定する助けとなります（出典：富士通）。
こうした可視化ツールを使う利点は、属人的な勘や記憶に頼らず、ソースコードという事実に基づいて現状を把握できる点にあります。可視化された依存関係マップは、後工程でベンダーに現状を正確に伝えるための共通言語にもなります。アセスメントの精度を高めたい場合は、こうしたツールの導入や、ツールを使いこなせるパートナーの起用を検討する価値があります。
アセスメント費用の目安
アセスメントと要件定義には当然コストがかかりますが、これは刷新本体への投資を守るための保険でもあります。一般的な目安として、要件定義や業務棚卸しのみを切り出して実施する場合、その費用感は200万円から500万円程度のレンジに収まることが多いとされています。システムの規模や複雑度、業務範囲の広さによって変動しますが、まずはこの段階だけを独立して発注し、現状を把握するという進め方も有効です。
この費用を「刷新本体とは別の余分なコスト」と捉えるか、「失敗を防ぐための必要投資」と捉えるかで、プロジェクトの成否は大きく変わります。アセスメントを省いて発注した結果、後から数千万円規模の追加費用が発生する事態に比べれば、この段階への投資は十分に回収できる範囲です。アセスメントは、刷新全体の予算精度を高めるための先行投資だと位置づけることをおすすめします。
RFP（提案依頼書）に含めるべき項目
アセスメントと要件定義で固めた内容を、ベンダーへ正確に伝えるための文書がRFP（提案依頼書）です。RFPの質が低いと、各ベンダーが前提を勝手に補完して見積もるため、提案内容がバラバラになり比較ができません。逆に、必要な情報が網羅されたRFPを用意できれば、同じ土俵で各社の提案を比較でき、自社に最適なパートナーを選びやすくなります。ここでは、レガシー刷新のRFPに最低限盛り込むべき項目を整理します。
現行構成図・性能要件・移行後KPI
RFPの核となるのが、現状と目標を具体的に示す情報群です。最低限、次の3点は盛り込みたいところです。
・現行構成図：アセスメントで把握したハードウェア・ソフトウェア・連携先を図示したもの
・性能要件：処理件数、応答時間、夜間バッチの完了時間など、満たすべき定量基準
・移行後のKPI：刷新によって達成したい目標値（保守費削減率、処理時間短縮率など）
これらを明記することで、ベンダーは「どこから出発し、どこを目指すのか」という前提を共有したうえで提案を組み立てられます。とりわけ移行後のKPIを数値で示しておくと、提案がその目標達成にどう寄与するのかという観点で各社を評価でき、提案の良し悪しを定量的に判断しやすくなります。曖昧な要望ではなく、測定可能なゴールを示すことがRFP作成の要点です。
移行方式（段階移行）を前提要件に盛り込む
RFPで見落とされがちなのが、移行方式に関する前提条件です。現行システムを一度に新システムへ切り替えるビッグバン方式は、切り替え当日に問題が発生した場合の影響が甚大で、レガシー刷新では大きなリスクを伴います。そのため、機能や業務単位で少しずつ新システムへ移していく段階移行（ストラングラーパターン）を前提要件としてRFPに明記しておくことが有効です。これにより、各ベンダーが現実的なリスク管理を織り込んだ提案を行うようになります。
ストラングラーパターンとは、既存システムを稼働させたまま、その周囲に新しい機能を段階的に構築し、最終的に旧システムを置き換えていく移行アプローチです。一括移行に比べて切り替えリスクを分散でき、各段階で効果を検証しながら進められる利点があります。RFPの段階でこの方式を前提として示しておけば、ダウンタイムや移行リスクへの対応力でベンダーを見極めやすくなります。
ベンダー評価の5つのチェックポイント
RFPを各社へ提示して提案を受け取ったあとは、いよいよベンダーの評価・選定です。価格だけで選ぶと、安さの裏に潜むリスクを見落としかねません。レガシー刷新という難度の高いプロジェクトでは、技術力・実績・体制・信頼性を多面的に評価する必要があります。ここでは、ベンダーを見極めるための5つのチェックポイントを紹介します。提案書を読む際の評価軸として活用してください。
実績と段階移行の設計力で見極める
5つのチェックポイントのうち、まず重視したいのが実績と設計力に関する2点です。
・同業界・同規模の実績：自社と近い業界・規模のレガシー刷新を手がけた経験があるか
・段階移行の設計力：ビッグバンを避け、ストラングラーパターンなどの段階移行を具体的に設計できるか
同業界・同規模の実績は、業務特有の要件や落とし穴をベンダーが理解しているかを測る指標になります。また段階移行の設計力は、提案書の中で移行ステップがどれだけ具体的かを見れば判断できます。「段階的に移行します」という抽象的な記述にとどまるのか、どの機能をどの順番で、どんな並行稼働期間を設けて移すのかまで踏み込んでいるのか。その具体性の差が、実行力の差を映し出します。
ダウンタイム見積り・保守体制・認証で見極める
残る3つのチェックポイントは、移行品質と運用後の安心に関わる観点です。
・ダウンタイム見積りの精度：移行時の業務停止時間をどこまで具体的かつ現実的に見積もれているか
・24時間365日の保守体制：刷新後の障害対応やトラブル時に、止まらない運用を支える体制があるか
・品質・セキュリティ認証：ISO9001（品質マネジメント）やISO/IEC27001（情報セキュリティ）などの第三者認証を取得しているか
ダウンタイムの見積りは、楽観的すぎる数字を提示するベンダーほど注意が必要です。現実的なリスクを織り込んでいるかどうかが、誠実さと実力の表れになります。保守体制は刷新後の事業継続を左右し、ISO9001やISO/IEC27001といった認証は、属人的ではない仕組みとして品質とセキュリティを担保している客観的な証拠になります。これら5つの観点を総合的に評価することで、価格の安さに惑わされない選定が可能になります。
まとめ：アセスメントから始める刷新準備のポイント
本記事では、レガシーシステムのモダナイゼーションを「アセスメント→要件定義→RFP作成→ベンダー評価」という準備プロセスに沿って解説しました。刷新失敗の大きな原因は要件定義の不十分さにあり、仕様書欠如やブラックボックス化した現行システムを、まず資産棚卸しと現状（AS-IS）可視化で正確に把握することが定石です。富士通の「ソフトウェア地図」のような可視化ツールを活用し、要件定義・業務棚卸しのみであれば200万〜500万円程度の費用感を見込んでアセスメントに先行投資することが、後の追加費用を防ぐ近道になります。RFPには現行構成図・性能要件・移行後KPIを盛り込み、ビッグバンを避けて段階移行（ストラングラーパターン）を前提要件として明示することが重要です。
ベンダーの選定では、(1)同業界・同規模の実績、(2)段階移行の設計力、(3)ダウンタイム見積りの精度、(4)24時間365日の保守体制、(5)ISO9001やISO/IEC27001などの品質・セキュリティ認証という5つのチェックポイントを総合的に評価し、価格の安さだけで決めないことが肝要です。「2025年の崖」が示すように、レガシーシステムの放置は年間最大12兆円という経済損失リスクを年々増幅させます。だからこそ、拙速な発注ではなく、現状分析を起点とした丁寧な準備こそが刷新成功への最短ルートとなります。自社の状況に合ったアセスメントと要件定義、RFP作成の進め方を、経験豊富なパートナーとともに具体化していくことをおすすめします。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。