レガシーシステム刷新のアセスメント/要件定義/RFPについて

「仕様書が一切残っていない」「担当者が退職してブラックボックス化している」──レガシーシステム刷新を検討する企業の多くが、こうした状況から出発します。COBOL・メインフレーム・オフコンといった古い技術基盤は、数十年にわたって業務の中核を担ってきた一方で、現行の動作仕様を誰も把握していないケースが珍しくありません。経済産業省のDXレポートが警鐘を鳴らした「2025年の崖」以降、刷新の必要性は認識されても、最初の一歩であるアセスメントで行き詰まる企業が後を絶ちません。

本記事では、仕様書がない前提でのアセスメント（現状分析・AS-IS可視化）から要件定義、そしてRFP作成・ベンダー選定までの一連の流れを、レガシー特有の論点を中心に解説します。プロジェクト全体の進め方についてはレガシーシステム刷新の完全ガイドも合わせてご参照ください。本記事は「各フェーズで何を成果物として作るか」「RFPに何を書くか」「ベンダーをどう評価するか」という観点に絞って詳述します。

▼全体ガイドの記事
・レガシーシステム刷新の完全ガイド

レガシー刷新のアセスメント（現状分析・AS-IS可視化）の進め方

レガシーシステムのアセスメントが通常のシステム刷新と大きく異なるのは、「現行仕様書が存在しない、あるいは実態と乖離している」という前提からスタートしなければならない点です。一般的なシステム再構築であれば設計書を参照しながら要件を整理できますが、COBOL資産やメインフレーム上のシステムは、稼働開始から30年以上が経過して改修が積み重なり、ドキュメントの追随が途絶えているケースがほとんどです。このため、アセスメントの最初のステップは「ソースコードそのものを読む」ことから始まります。

仕様書がない場合、アセスメントチームはソースコードを静的解析し、業務ロジックを逆引きする「リバースエンジニアリング」を行います。COBOLの場合、プログラム数が数千本に及ぶことも珍しくなく、手作業での全数レビューは現実的ではありません。そこで活用されるのが、アプリ資産の複雑度・依存関係を自動で可視化するツールです。富士通が提供する「ソフトウェア地図」は、COBOLプログラム間のCALL関係やデータ項目の使われ方をグラフ化し、改修コストが高い複雑度の高いモジュールや、他のプログラムから多数呼び出されている中核モジュールを一目で把握できます。

この複雑度・依存関係の可視化は、後の要件定義フェーズで「現行踏襲か業務見直しか」を判断する際の客観的根拠にもなります。依存が多く複雑度が高いモジュールほど、業務見直しのリスクが高く、現行踏襲でまず安定稼働を確保してから段階的に改善するという意思決定を支えるデータになります。

コード解析と並行して行うのが、システム資産全体の棚卸しです。レガシー環境特有の棚卸し対象として、以下の3つが挙げられます。

まず「COBOLプログラム資産」の棚卸しです。プログラム名・ステップ数・最終改修日・担当部門の一覧を整備し、現在も実際に使用されているか（デッドコードでないか）を確認します。長年の改修で使われなくなったプログラムが残存しているケースも多く、それらをスコープから除外することで後続工程の工数を大幅に削減できます。
次に「データ資産」の棚卸しです。メインフレームやオフコンのデータは、文字コードとしてEBCDIC（Extended Binary Coded Decimal Interchange Code）を使用しているため、オープン系のUTF-8環境に移行する際に文字化けや変換ロジックの実装が必要になります。マスタデータのレコードレイアウト、各フィールドの意味・桁数・使用ルールを棚卸し、データ品質（欠損・重複・形式不統一）も同時に評価します。
最後に「バッチジョブ」の棚卸しです。JCL（Job Control Language）で定義された夜間バッチ・月次バッチ・年次バッチのジョブスケジュール、処理順序（前後関係）、所要時間、エラー時の対応手順を一覧化します。バッチの依存関係が複雑に絡み合っている場合、移行後の並行稼働設計やデータ同期方式の検討に直結するため、アセスメント段階での可視化が不可欠です。

アセスメントフェーズの成果物として、最低限以下を揃えることを推奨します。「現行システム構成図」（ハードウェア・ミドルウェア・ネットワーク構成）、「プログラム資産一覧」（複雑度・依存関係含む）、「データモデル概要」（主要マスタ・トランザクション・文字コード情報）、「バッチジョブ一覧」（ジョブスケジュール・依存関係・所要時間）、「リスク評価書」（担当者依存・文書化不足・技術的負債の度合い）の5点です。これらはそのまま要件定義・RFP作成の入力情報になります。アセスメントの期間は、対象システムの規模にもよりますが、中規模（プログラム数500〜2,000本）で3〜4ヶ月が目安です。

アセスメントを踏まえた要件定義のポイント（現行踏襲か業務見直しか・移行KPI）

アセスメントが完了したら、次のフェーズは要件定義です。レガシーシステム刷新における要件定義の最大の論点は「現行踏襲（As-Is）か業務見直し（To-Be）か」の線引きです。この判断を曖昧にしたまま進めると、スコープが際限なく膨らみ、プロジェクトが長期化・高コスト化する原因になります。JUASの調査によれば、約7割の企業がレガシーシステムのブラックボックス化を課題と認識しており（出典：JUAS）、要件定義の不十分さが刷新失敗の大きな要因として挙げられています。

「現行踏襲」とは、現在のシステムが行っている業務ロジックをそのまま新システムに再現することです。一方「業務見直し（To-Be）」とは、非効率な業務フロー・不要な例外処理・時代遅れのルールをこの機に整理し、業務プロセス自体を改善することです。両者は対立するものではなく、モジュールや機能単位で組み合わせて判断するのが現実的なアプローチです。

判断の基準として、アセスメントで取得した複雑度・依存関係データが活きます。依存関係が少なくビジネスルールが単純なモジュールは業務見直しのチャンスです。一方、COBOLコードに膨大な例外処理が埋め込まれており、その背景にある業務ルールを誰も説明できないようなモジュールは、まず現行踏襲で移行してから、安定稼働後に段階的に見直すという判断が安全です。この判断をプロジェクト開始前に業務部門と合意しておくことが、後工程でのスコープ変更を防ぐ鍵になります。

要件定義のもう一つの重要な成果物は「移行後のKPI定義」です。刷新の成否を測る定量的な指標を事前に合意しておかなければ、プロジェクト完了の判断基準が主観的になり、ベンダーとのSLA交渉でも根拠を示せなくなります。レガシー刷新における主要KPIとして、以下の観点が挙げられます。

「システム応答性能」はページ表示・バッチ処理の所要時間で測ります。特に夜間バッチについては、現行の処理時間をアセスメントで計測し、移行後に同じ処理量を何時間以内に完了させるかを明確にします。「可用性」は年間のサービス停止時間（ダウンタイム）で定義します。メインフレームは99.999%（ファイブナイン）の可用性を誇るケースもあり、オープン系への移行後に可用性が低下することへの懸念は業務部門から必ず出ます。SLA・DR（災害復旧）の方針も要件定義段階で確定させます。「保守性・拡張性」はソースコードの複雑度指標（サイクロマティック複雑度など）や将来の機能追加にかかる工数見積もりで測定します。「運用コスト削減率」は、現行のハードウェア・ソフトウェア・保守要員コストと比較した削減目標を設定します。これらのKPIは後工程のRFPに記載し、提案ベンダーに対してどのように達成するかの具体的な計画提示を求めます。

要件定義・業務棚卸しのみをコンサルティング会社や独立したSIerに依頼する場合、費用相場は200万〜500万円が目安です。この段階でRFPを作成する支援まで含めると、さらに上乗せになるケースがあります。注意すべきは、要件定義を依頼したベンダーがそのままシステム開発も受注する「作りやすい要件定義」を作るリスクです。要件定義フェーズと開発フェーズのベンダーを分離するか、要件定義の成果物を第三者がレビューする体制を設けることが、後工程でのベンダーロックインを防ぐために重要です。

RFPに盛り込むべき項目とベンダー選定の評価基準

アセスメントと要件定義が完了したら、次はRFP（Request For Proposal：提案依頼書）の作成です。RFPはベンダーへの提案依頼の根拠文書であると同時に、自社の要件を明確化するための内部整理ツールでもあります。レガシーシステム刷新のRFPは、一般的なシステム開発のRFPとは異なる観点が必要です。「データ移行」「並行稼働」「移行時ダウンタイム」といったレガシー固有のリスク項目を明示することが、質の高い提案を引き出す鍵になります。

レガシーシステム刷新のRFPには、以下の項目を盛り込むことを推奨します。

「現行システム概要」では、アセスメントで作成した現行システム構成図（ハードウェア・ミドルウェア・ネットワーク）、プログラム資産一覧（プログラム数・言語・総ステップ数）、主要データ（マスタ・トランザクション件数・文字コード種別）、バッチジョブ一覧（ジョブ数・最長処理時間）を添付します。ベンダーが現状を正確に把握できるほど、提案の精度が上がります。
「機能要件」では、現行踏襲する機能の一覧と、業務見直しを行う機能の一覧を明示します。To-Beの業務フローが完成している場合はその資料も添付します。
「非機能要件」では、性能要件（応答時間・バッチ処理時間・同時接続数）、可用性（SLAの目標値・DR対応方針）、セキュリティ要件（認証方式・暗号化基準・アクセスログ保管期間）を記載します。
「データ移行要件」はレガシー刷新のRFPで特に重要な項目です。移行対象データの件数・形式（EBCDICからUTF-8への変換対応）、データクレンジングの方針（欠損データ・異常値の扱い）、移行手順（いつ・どの順序で・どの単位で移行するか）、移行リハーサルの実施計画を明記します。
「移行・並行稼働計画」では、ビッグバン移行（一括切り替え）かストラングラーパターン（段階移行）かの方針を示した上で、並行稼働期間中のデータ同期方式と、本番切り替え時の許容ダウンタイムを明示します。ダウンタイムの許容範囲（例：最大4時間以内）を明記することで、ベンダーが現実的な移行計画を提案できます。
「移行後KPI」では、要件定義で定義したKPI（応答性能・可用性・運用コスト削減率など）の目標値を記載し、提案ベンダーがそれをどのように達成するかの計画提示を求めます。
「サポート体制」では、本番稼働後の保守体制（障害対応の窓口・対応時間・SLA）を明示します。

RFPへの提案を受け取ったら、次はベンダーの評価です。価格だけで判断することは非常に危険で、技術力・体制・実績を客観的に評価する基準が必要です。特にレガシーシステムの移行においては、価格が最安値でも実績・技術力が不足したベンダーを選ぶと、移行失敗のリスクが格段に高まります。以下の5つのチェックポイントで評価することを推奨します。

チェックポイント1は「同業界・同規模での実績」です。COBOLからのマイグレーション、メインフレームからオープン系への移行、あるいは同規模（プログラム数・データ量）のレガシー刷新実績があるかを確認します。参照先の顧客企業に直接ヒアリングできると理想的です。単なる実績件数ではなく、「どのような課題がありどう解決したか」という具体的なケーススタディの提示を求めてください。
チェックポイント2は「段階移行の設計力」です。ビッグバン移行は高リスクであるため、ストラングラーパターンによる段階移行を設計できるかどうかを確認します。どの機能を先行して移行し、どのタイミングでデータを統合するか、並行稼働期間中のデータ整合性をどう確保するかの具体的な設計案を提案段階で求めます。
チェックポイント3は「ダウンタイムの見積もり」です。本番切り替え時に業務が停止する時間を最小化する設計が提案されているかを確認します。データ移行のリハーサルを事前に何回実施するか、万が一のリカバリ手順は何かを具体的に説明できるベンダーを選びます。
チェックポイント4は「24時間365日の保守体制」です。本番稼働後の障害対応体制を確認します。特にレガシーシステムを刷新した直後は、想定外の業務例外が発生しやすいため、迅速な一次対応が可能な専任の保守チームがいるかどうかを確認します。SLA違反時のペナルティ条項が明示されているかも重要です。
チェックポイント5は「品質・セキュリティ認証」です。ISO9001（品質マネジメント）やISO27001（情報セキュリティマネジメント）の認証取得状況を確認します。これらの認証は、プロジェクト管理の成熟度やセキュリティ対策の水準を客観的に示す指標になります。特に個人情報や機密性の高い業務データを扱うシステムの場合、セキュリティ認証の取得は必須条件として設定することを推奨します。

複数ベンダーの提案を公平に比較するために、評価項目と重み付けを事前に設定したスコアリングシートを用意します。評価項目の例として「技術的実現性（30点）」「移行計画の具体性（25点）」「価格の妥当性（20点）」「保守・サポート体制（15点）」「企業の信頼性・財務安定性（10点）」のような配分が一般的です。価格の重み付けを20%程度に抑え、技術力・計画の具体性を重視する配分にすることで、最安値ベンダーへの安易な選定を防ぎます。

また、提案書の評価だけでなく「プレゼンテーション・デモ」の場を設け、担当エンジニアのレベルを直接確認することも重要です。提案書を書いたマネージャーではなく、実際に開発を担当するエンジニアが技術的な質問に答えられるかを確認することで、提案と実態のギャップを早期に発見できます。

まとめ

本記事では、仕様書が存在しないレガシーシステム（COBOL・メインフレーム・オフコン）の刷新において、アセスメント・要件定義・RFP・ベンダー選定の各フェーズで何を成果物として作るか、どのような判断基準で進めるかを解説しました。アセスメントではリバースエンジニアリング・コード解析・複雑度可視化ツール（富士通「ソフトウェア地図」等）を活用してブラックボックスを解消し、COBOL資産・EBCDICデータ・バッチジョブの棚卸しを徹底することが出発点です。要件定義では「現行踏襲か業務見直しか」の線引きをアセスメントデータに基づいて行い、移行後KPIを定量的に定義します。RFPではレガシー固有の「データ移行要件」「並行稼働計画」「許容ダウンタイム」を明示し、ベンダー評価では実績・段階移行設計力・保守体制・品質認証の5つのポイントで客観的に評価します。

経済産業省のDXレポートが指摘するように、レガシーシステムの放置は「2025年の崖」に象徴される経営リスクを高め続けます。刷新の失敗は多くの場合、初期フェーズのアセスメント・要件定義の不十分さに起因します。現行仕様書がない前提での体系的なアセスメントと、レガシー固有のリスクを組み込んだRFP・ベンダー評価の枠組みを整えることが、刷新プロジェクトを成功に導く最重要ファクターです。各フェーズの成果物を着実に積み上げ、業務部門・IT部門・ベンダーの三者が同じ認識を持った状態で次のフェーズに進む進め方が、大規模レガシー刷新を成功させる王道です。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。