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