レガシーシステム刷新は、現状分析（アセスメント）、要件定義、RFP作成とベンダー選定の順に進めると、各段階の判断材料をそろえやすくなります。
アセスメントの成果物は要件定義とRFP作成の入力になり、要件定義を経てRFPを作成します。全体像はレガシーシステム刷新の完全ガイドもご覧ください。
▼全体ガイドの記事
・レガシーシステム刷新の完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
レガシー刷新のアセスメント（現状分析・AS-IS可視化）の進め方
レガシー刷新のアセスメントは、現行仕様書がない、または実態と異なる前提で始まります。COBOLやメインフレームでは、稼働から30年以上たつうちに改修が重なり、文書が追いつかない場合があります。
設計書を頼りに要件を整理できないことが、レガシー刷新の特徴です。そのため、最初にソースコードを読み、現行仕様を確かめます。
リバースエンジニアリングとコード解析による現行仕様の復元
COBOLのプログラムは数千本に及ぶこともあり、そのすべてを手作業で確認するのは現実的ではありません。そのため、観点を分けて解析し、現行仕様を整理します。
- コード解析：静的解析（リバースエンジニアリング）で、業務ロジックをソースコードから逆引きします。
- 関係の可視化：プログラム同士のCALL関係とデータ項目の利用状況を、グラフで把握します。
- 要件判断：複雑度と依存関係を、現行踏襲か業務見直しかの根拠にします。
富士通の「ソフトウェア地図」では、COBOLプログラム間のCALL関係やデータ項目の使われ方がグラフになります。グラフを見ると、複雑度が高く改修コストも大きいモジュールを特定でき、多数のプログラムに呼び出される中核モジュールも把握できます。
依存が多く複雑なモジュールは、業務を見直すとリスクが高くなります。そのため、まず現行踏襲で安定稼働を確保し、その後に段階的に改善する判断を、こうした解析結果が支えます。
COBOL資産・データ・バッチジョブの棚卸し
コード解析と並行して、システム資産を洗い出します。レガシー環境で対象になるのは、プログラム、データ、バッチジョブの3つです。
- COBOLプログラム：プログラム名、ステップ数、最終改修日、担当部門を一覧にします。
- データ資産：レコード構成、各フィールドの意味、桁数、使用ルールを押さえます。
- バッチジョブ：JCL（Job Control Language）のスケジュール、処理順序、所要時間をまとめます。
まず、プログラムが今も使われているかを確かめます。長年の改修で残ったデッドコードを対象から外せば、後続工程の工数を大幅に減らせます。
EBCDICは、Extended Binary Coded Decimal Interchange Codeの略で、メインフレームやオフコンのデータに使われている場合があります。そのため、UTF-8環境へ移す際には、文字化けに対応する変換ロジックを実装します。
データ品質は、欠損、重複、形式の不統一の有無を確かめて評価します。
夜間・月次・年次のジョブも対象に含め、エラー時の対応手順を一覧にします。バッチの依存関係が複雑だと、移行後の並行稼働設計やデータ同期方式の検討に直結します。そのため、アセスメント段階で依存関係を図にまとめておくことが欠かせません。
アセスメントの成果物と品質基準
アセスメントでは、次の5点を最低限そろえることが推奨されます。いずれも要件定義とRFP作成の入力になります。
- 現行システム構成図：ハードウェア、ミドルウェア、ネットワークの構成を図にしたものです。
- プログラム資産一覧：各プログラムの複雑度と依存関係を含めます。
- データモデル概要：主要なマスタ、トランザクション、文字コードの情報を記します。
- バッチジョブ一覧：スケジュール、依存関係、所要時間をまとめます。
- リスク評価書：担当者への依存、文書化の不足、技術的負債を評価します。
期間は対象システムの規模によって変わります。プログラム数500〜2,000本の中規模システムでは、3〜4ヶ月が目安です。
アセスメントを踏まえた要件定義のポイント（現行踏襲か業務見直しか・移行KPI）
アセスメントの後は要件定義に進みます。その中で最大の論点になるのが、現行踏襲（As-Is）と業務見直し（To-Be）の線引きです。
線引きが曖昧なままだと、スコープが膨らみ、プロジェクトの長期化や高コスト化につながります。JUASの調査では、約7割の企業がレガシーシステムのブラックボックス化を課題と認識しています（出典：JUAS）。
要件定義の不十分さは、刷新失敗の大きな要因として挙げられています。だからこそ、アセスメントの結果を判断材料にして、業務部門と線引きを合意しておく必要があります。
現行踏襲と業務見直しの線引き判断基準
現行踏襲と業務見直しは、モジュールや機能ごとに分けて判断するのが現実的です。
- 現行踏襲（As-Is）：現在のシステムの業務ロジックを、新システムで再現します。
- 業務見直し（To-Be）：非効率なフロー、不要な例外処理、古いルールを整理し、業務を改善します。
両者は対立せず、組み合わせて使えます。判断には、アセスメントで得た複雑度と依存関係のデータを使います。特に、依存が少なくビジネスルールが単純なモジュールは、業務見直しの機会になります。
COBOLに例外処理が多く、その背景にある業務ルールを説明できない場合は、まず現行踏襲で移行するほうが安全です。そのうえで、安定稼働後に段階的に見直します。
プロジェクトの開始前に業務部門と判断を合意しておけば、後工程でのスコープ変更を防ぎやすくなります。
移行後KPIの定義と非機能要件
要件定義の段階で、刷新の成否を測るKPIを事前に合意しておきます。合意していないと完了の判断が主観的になり、SLA交渉の根拠も示せなくなります。
刷新後の目標は、性能、可用性、保守性、運用費用の4つの観点に分けて定めます。
- 応答性能：ページ表示とバッチ処理の所要時間で測ります。
- 可用性：年間のサービス停止時間で定義します。
- 保守性・拡張性：複雑度の指標や、将来の機能追加にかかる工数で捉えます。
- 運用コスト削減率：現行費用と比べた削減目標を設定します。
夜間バッチは、現行の所要時間を計測したうえで、移行後に同じ処理量を何時間以内で終えるかを定めます。
メインフレームは99.999%（ファイブナイン）の可用性を持つ場合があり、移行後にその水準が下がることを懸念する業務部門もあります。
SLAとDR（災害復旧）の方針も、要件定義の段階で確定させます。複雑度は、サイクロマティック複雑度などで測ります。
運用コストの基準にするのは、ハードウェア、ソフトウェア、保守要員の現行費用です。各KPIはRFPに記載し、達成計画を提案ベンダーに求めます。
要件定義単体の外部委託コスト感と注意点
要件定義や業務の洗い出しだけをコンサルティング会社や独立系SIerに依頼する場合、費用の目安は200万〜500万円です。RFP作成の支援も含めると、その分の費用が上乗せになる場合があります。
要件定義を依頼したベンダーが開発も受注すると、自社にとって作りやすい要件定義になるおそれがあります。そこで、要件定義と開発のベンダーを分ける方法があります。
ベンダーを分けない場合は、成果物を第三者がレビューする体制を設けます。この体制で、後工程のベンダーロックインを防ぎます。
RFPに盛り込むべき項目とベンダー選定の評価基準
要件定義の後は、RFP（Request For Proposal：提案依頼書）を作成します。RFPはベンダーへの依頼の根拠であり、自社の要件を整理する内部ツールでもあります。
レガシー刷新では、一般的な開発RFPとは異なる観点が必要です。データ移行、並行稼働、移行時のダウンタイムといった固有のリスクを示すと、質の高い提案につながります。
RFPに含めるべき具体項目一覧
ベンダーが提案の前提を正しく理解できるよう、RFPには次の項目を盛り込みます。
- 現行システム概要：構成図、プログラム資産、主要データ、バッチ情報を添付します。
- 機能・非機能要件：踏襲する機能と見直す機能、性能、可用性、セキュリティの要件を記載します。
- データ移行要件：対象データ、変換・クレンジングの方針、移行手順とリハーサルを示します。
- 移行計画・移行後KPI：切り替え方式、同期の方法、停止時間、目標値と達成計画を盛り込みます。
- サポート体制：本番稼働後の障害対応の窓口、対応時間、SLAを明記します。
構成図には、ハードウェア、ミドルウェア、ネットワークの情報を含めます。プログラム資産は、プログラム数、言語、総ステップ数を示します。
主要データには、マスタとトランザクションの件数と文字コードの種別を含めます。バッチジョブは、ジョブ数と最長処理時間を示します。現状を正確に伝えると、提案の精度が高まります。
機能要件では、現行踏襲する機能と業務見直しを行う機能を分けて示します。完成したTo-Be業務フローがあれば、それもあわせて添付します。
非機能要件では、応答時間、バッチ処理時間、同時接続数を定めます。また、認証方式、暗号化基準、アクセスログの保管期間も示します。
データ移行では、対象件数と形式、EBCDICからUTF-8への変換、欠損データや異常値の扱いを明記します。移行時期を示したうえで、どの順序で、どの単位で移行するか、リハーサルの計画も含めます。
切り替え方式は、ビッグバン移行（一括切り替え）かストラングラーパターン（段階移行）かを示します。並行稼働中の同期方式と、本番切り替え時の許容ダウンタイムも明らかにします。
たとえば、許容ダウンタイムを最大4時間以内と明記すると、ベンダーは現実的な計画を提案できます。
ベンダー評価の5つのチェックポイント
提案は、価格に加えて次の5つの観点で評価します。最安値でも実績や技術力が足りなければ、レガシー移行の失敗リスクが高まります。
- 同業界・同規模の実績
- 段階移行の設計力
- ダウンタイムの見積もり
- 24時間365日の保守体制
- 品質・セキュリティ認証
COBOL移行やメインフレームからオープン系への移行経験は、プログラム数やデータ量と照らして確かめます。可能であれば、参照先の顧客に直接ヒアリングします。
実績の件数だけでなく、どの課題をどう解決したかという事例を求めます。段階移行の場合は、先行させる機能、データ統合の時期、並行稼働中の整合性を確かめます。
停止時間を抑える設計になっているかを見ます。そのうえで、移行リハーサルの回数や障害時のリカバリ手順を具体的に確かめます。
刷新直後は想定外の業務例外が起きやすいため、迅速に一次対応できる専任チームがいるかを確かめます。
さらに、SLA違反時のペナルティ条項も確認します。品質とセキュリティの面では、ISO9001（品質マネジメント）やISO27001（情報セキュリティマネジメント）の取得状況を見ます。
これらの認証は、プロジェクト管理やセキュリティ対策の水準を客観的に示します。そのため、個人情報や機密データを扱う場合は、取得を必須条件にすることが推奨されます。
提案評価のスコアリングシート設計
ベンダーの提案は、技術面や移行計画などの観点に重みを付けて比べます。価格も、その観点の一つです。
- 技術的実現性：30点
- 移行計画の具体性：25点
- 価格の妥当性：20点
- 保守・サポート体制：15点
- 企業の信頼性・財務安定性：10点
価格の重みを20%程度に抑え、技術力と計画の具体性を重く見ると、最安値だけで選ぶことを防げます。
提案書の評価に加えて、プレゼンテーションやデモを行い、担当エンジニアの力量を確かめます。実際に開発するエンジニアが技術的な質問に答えられるかを見ると、提案内容とのずれを早い段階で見つけられます。
まとめ
仕様書のないレガシー刷新は、アセスメントでコードを解析し、資産を洗い出すことから始まります。複雑度や依存関係を確かめたうえで、要件定義では現行踏襲と業務見直しを判断します。
移行後KPIを定めたうえで、RFPにはデータ移行、並行稼働、許容ダウンタイムを記載します。ベンダーは、実績と移行設計を中心に、保守体制や品質認証も含めて評価します。
刷新の失敗は、初期のアセスメントや要件定義の不足が原因になる場合があります。経済産業省のDXレポートが指摘する「2025年の崖」のような経営リスクを避けるためにも、現行仕様が分からない前提で、体系的に調べます。
各フェーズの成果物を積み上げ、業務部門、IT部門、ベンダーの認識をそろえながら次へ進むことが、大規模刷新を成功させる進め方です。
▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。