レガシーシステム更改は、現行環境と契約条件を整理してから発注するのが基本です。長年運用されたシステムは設計書が残っていないことも多く、ブラックボックス化が進んでいます。
準備からRFP作成、ベンダー評価、契約、発注後の管理と障害対応まで順に解説します。本テーマの全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・レガシーシステム更改の完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
レガシーシステム更改の発注前の準備
レガシーシステム更改で失敗するケースの多くは、発注前の準備が足りないことに原因があります。現行システムの実態を正確に把握しないまま外部ベンダーに丸投げすると、要件定義があいまいになります。その結果、後から大幅なスコープ拡張や追加費用が発生します。
だからこそ、発注者側が主体的に動いて現状を整理し、そのうえでベンダーとの対話に臨むことが、プロジェクト成功の第一歩です。
現行システムの現状把握とドキュメント化（ブラックボックス対策）
稼働から10年以上が経つシステムでは、開発当時の担当者が退職・異動し、仕様書や設計書がない状況が頻繁に起きます。ブラックボックスのまま更改を始めると、新ベンダーは現行の調査だけで膨大な工数を使い、見積もりが大きく膨らみます。まず取り組むべきは現行システムのドキュメント化で、完全な仕様書は時間がかかるものの、少なくとも次の情報は発注前に揃えることをおすすめします。
具体的には、①サーバー構成・ミドルウェア・データベースの種類とバージョン、②主要な業務フローと画面遷移の概要、③データの種類・件数・保管期間のルールです。さらに、④連携している外部システムの一覧とAPI仕様、⑤過去に発生した重大障害の履歴と対処記録も含めます。これらを揃えるだけで、新規ベンダーは現状調査の工数を大幅に減らし、精度の高い提案・見積もりが可能になります。
既存ベンダーが詳細情報の提供に非協力的なら、契約書の「情報開示義務」「引き継ぎ協力義務」を確かめ、必要なら法的根拠をもとに交渉することも選択肢です。関係が良好なら新ベンダーへの引き継ぎを頼めますが、悪化していれば、リバースエンジニアリング（動作からコードや仕様を逆解析する手法）に対応できるベンダーを選ぶのが現実的です。
IT人材不在時の体制構築
発注者側にIT人材が不在か少ない状態で更改を進めるケースが、多く見られます。特に中堅・中小企業では、情報システム部門が「ベンダーへの窓口担当者が1名いるだけ」という体制も珍しくありません。
こうした状況でも、発注者側がプロジェクトのオーナーシップを持って臨む姿勢が欠かせません。発注者側の体制として最低限確保したいのは、プロジェクトオーナー（経営層の承認権者）、業務要件を語れる業務担当者（現場のキーパーソン）、技術面の橋渡しを担うIT窓口の3役です。
社内にIT知識が不足している場合は、第三者のPMO（プロジェクトマネジメントオフィス）支援会社やITコンサルタントを活用して、発注者側のサポート体制を強化する方法が効果的です。PMOは発注者の代理として要件定義を支援し、ベンダーとの交渉や進捗管理を担います。そのため、プロジェクトの成功確率を高める投資といえます。
RFI・RFPの作成方法と実践テンプレート
ベンダー選定の質は、RFI（情報提供依頼書）とRFP（提案依頼書）の質に直結します。レガシーシステム更改では、通常のシステム開発とは異なる固有の項目があります。
現行システムの調査力や移行設計の経験を測る質問を盛り込むことが、優れたベンダーと実力不足のベンダーを見分ける手がかりになります。
レガシー特有のRFI項目（現行システムの調査・移行設計の能力確認）
RFIは、本格的な提案依頼の前にベンダーの基本的な能力・経験・自社との相性を確認するための情報収集ツールです。レガシーシステム更改に特化したRFIでは、現行システムの調査力と移行の経験を重点的に確かめます。まず「設計書・仕様書が存在しないレガシーシステムの調査経験」を尋ね、過去の導入事例と採用した調査手法を聞きます。
設計書なしでシステムを解析した経験があるベンダーは、リバースエンジニアリングや動的解析のノウハウを持っており、初期調査フェーズの遅延リスクを大幅に下げられます。次に「データ移行の実績」を確かめます。レガシーシステムのデータは、現在の形式と互換性のない旧来の形式（例：固定長テキストファイル、EOFコードが特殊なバイナリ）で保存されていることがあります。
こうしたデータを、クレンジング（品質を整えること）したうえで新システムへ移行した経験があるかを問います。また、「稼働中のシステムを止めずに移行する（オンライン移行）の経験」も聞くと、現行業務を続けながらの移行に対応できるかを確かめられます。
RFPに盛り込むべき必須項目と書き方のコツ
RFPはベンダーへの正式な提案依頼書で、記載が曖昧だとベンダーごとに解釈が分かれ、提案の比較が困難になります。そのため、レガシーシステム更改のRFPでは、次の6項目を必ず盛り込みます。①プロジェクトの背景と目的（なぜ今更改するのか、更改後に実現したいビジネス上のゴール）と、②現行システムの概要（サーバー構成・技術スタック・主要機能・利用部門・ユーザー数）を書きます。
③現行システムの課題（保守コスト・セキュリティリスク・拡張性の限界など、具体的な数値で記載）と、④更改後の新システムに求める要件（機能要件と非機能要件）も欠かせません。⑤データ移行の要件（移行対象データの種類・件数・許容停止時間）と、⑥プロジェクト体制と役割分担（発注者・ベンダーそれぞれの責任範囲）も入れます。
書き方のコツは、「～を実現したい」という要望レベルの記述にとどめ、実現方法はベンダーの提案に委ねることです。そうすると、各社の技術力やアプローチの違いが提案書に表れ、比較しやすくなります。逆に、技術的な詳細の実装方法まで発注者が指定すると、ベンダーの創意工夫が失われ、提案内容が横並びになってしまいます。
予算の記載と発注側の駆け引き
RFPに予算を明示すべきかどうかは、発注者が最も迷う点の一つです。予算を開示すると、ベンダーはその上限近くの金額で提案を組み立てる傾向があります。3,000万円の予算を公開すれば、2,800万円〜3,000万円の見積もりが集まりやすくなる、というのが業界の実態です。
一方で、予算の下限が示されない状態では、ベンダーが過大な提案を出してくるリスクもあります。現実的な戦術としては、「予算は非公開とし、代わりに優先度付きの要件リストを渡す」方法が有効です。具体的には、RFPの要件を「Must Have（必須機能）」「Should Have（できれば欲しい機能）」「Nice to Have（あると良い機能）」の3段階で記載します。
そのうえで、「まずMust Haveだけで見積もりを提示し、予算に余裕があればShould Haveを加えた見積もりも合わせて提示してほしい」と依頼します。こうすると、ベンダーは現実的な複数のパターンを示すため、予算枠を明かさずに見積もりを比べられます。また、最終の発注交渉で「Should HaveのXX機能を外せば、どこまで費用を下げられますか」と問い直す余地も生まれます。
ベンダー提案の評価・比較手法
複数のベンダーから提案を受け取ったら、公平で多角的な視点から評価します。価格だけで判断すると、安くても技術力が不足していたり、プロジェクト管理が杜撰だったりするベンダーを選んでしまうおそれがあります。定量評価と定性評価を組み合わせると、より精度の高い意思決定が可能になります。
定量評価（スコアリングシート）の設計方法
スコアリングシートは、評価項目と配点を事前に決めておくことで、評価者の主観を排除し、客観的な比較を可能にするツールです。Gartnerなどの公開調査も参考に、自社の要件と照合して決めます。レガシーシステム更改の典型例は、5つの評価項目を合計100点満点にする構成で、技術力・開発実績に30点、価格の適切さに25点、プロジェクト管理体制に20点を配分します。
さらに、移行計画の具体性に15点、保守・サポート体制に10点を充てます。技術力の評価では、レガシーシステムに類似した更改実績の件数や規模を重視します。具体的には、「過去3年以内に同規模のレガシー更改を3件以上経験している」「使用技術スタックが重複している」といった根拠で加点すると、恣意的な評価を防げます。
価格評価では、安い順に点数を付けるよりも、見積もりの根拠（工数や単価の内訳が記載されているか）を基準に加えることをおすすめします。根拠を示さずに他社より30%安い見積もりは、後から追加費用を請求される「安値受注→変更費用回収」の典型的なパターンです。
定性評価（PMの対応力・企業文化との相性）の見極め方
スコアリングでは測れない定性的な評価も、実プロジェクトの成否に大きく影響します。特にレガシー更改のような長期プロジェクトでは、プロジェクトマネージャー（PM）の対応力が最も重要な要因の一つです。提案時のプレゼンテーションや質疑応答では、PMの対応力を確かめます。
まずは、「想定外の課題が発生した場合にどう対処するか」への回答の質を見ます。具体的な経験を交えて説明できるPMは、問題解決への実績と自信を持っている証拠です。逆に「その場合はお客様と協議します」という型どおりの回答しかできないPMは、実務経験が浅い可能性があります。
企業文化との相性も見逃せません。スピード重視で、アジャイルな進め方を好む発注者が、重厚なドキュメント管理と慎重な工程管理を旨とする大手SIerと組むと、意思決定のスピードのズレが停滞を招くことがあります。提案プレゼンの後に非公式な質問時間を設け、「貴社チームの通常のコミュニケーション頻度や進捗報告の方法は？」と尋ねると、実務上の相性を事前につかめます。
同点時の最終判断基準
スコアリング結果が同点もしくは僅差のときは、「どちらのベンダーと長期的な関係を築きたいか」という視点を最終判断に使います。稼働後の運用・保守まで含めると、レガシー更改は5年〜10年の関係になることも多いです。
そのため、プロジェクト終了後のサポート体制や継続的な改善への意欲が、差別化の要因になります。過去の顧客への稼働後フォローの事例を確認し、顧客満足度向上への取り組みを聞くことが効果的です。また、担当者の離職率やPMの途中交代時の対応方針も確認しておくと、長期安定運用のリスクを把握できます。
契約締結時のリスクヘッジ
発注先が決まったら、次は契約交渉です。レガシーシステム更改では、契約書の内容が後のトラブルの広がりを抑える最後の手段になります。どの契約形態を選ぶか、どのような免責・責任範囲を設けるかで、プロジェクトが難航したときに損害をどこまで抑えられるかが大きく変わります。
請負契約と準委任契約の使い分け
システム開発の契約形態には、大きく「請負契約」と「準委任契約」の2種類があります。請負契約は、ベンダーが成果物（完成したシステム）の完成を約束する形態で、仕様が明確に固まっている場合に適しています。一方、準委任契約は、ベンダーが善管注意義務をもって作業することを約束する形態で、要件が流動的なフェーズや調査・コンサルティング業務に向いています。
レガシーシステム更改では、フェーズによって使い分けるのが賢明で、二段構えが一般的です。現行システムの調査・要件定義フェーズは仕様が確定していないため準委任契約が適切で、基本設計が固まった後の開発・テスト・移行フェーズは請負契約でスコープと納期を明確にします。
ただし、請負契約でも「変更管理手続き（Change Request手続き）」の条項は欠かせません。調査を進める中で仕様の追加・変更が必要になったとき、追加費用や工期の変更をどう扱うかを明文化しておかないと、後から「それは契約範囲内か外か」と水掛け論になります。
ベンダーロックイン防止条項（データ所有権・脱依存ステップ）
レガシーシステム更改では、最も軽視されがちな一方で、最も重大な契約事項の一つが「ベンダーロックイン防止」です。現行のレガシーシステムから脱却しにくい理由をたどると、多くは当初の契約でデータ構造や移行手順の情報開示義務を明記しなかったことに行き着きます。同じ過ちを避けるため、契約書にはデータ所有権、ソースコード、引き継ぎ協力の3条項を盛り込みます。
まず「データ所有権」として、発注者が生成・蓄積したデータは発注者の財産だと明記し、契約終了後のベンダーによる保持・利用を認めないと規定します。次に「ソースコードの開示・エスクロー」として、ベンダーが開発したシステムのソースコードは契約終了時に発注者へ引き渡すことを義務づけ、困難な場合は第三者機関（エスクロー）に預ける仕組みを設けます。
さらに「引き継ぎ協力義務」として、ベンダーが変わる際はX週間以上の移行支援期間を設け、後任への技術情報の開示と引き継ぎを誠実に行うことを規定します。この3点を契約書に明記しておけば、数年後のベンダー変更も格段に進めやすくなります。
契約不適合責任・遅延損害金の取り決め
2020年の民法改正により「瑕疵担保責任」という概念は廃止され、「契約不適合責任」に統一されました。これは、納品されたシステムが契約で定めた仕様・品質・機能に適合しない場合に、発注者がベンダーに対して追完請求（修正・追加納品）、代金減額請求、損害賠償請求などを行えるという規定です。
契約書では、契約不適合責任の期間（通常は引き渡しから1年が多いが、複雑なシステムでは2年以上を交渉）と、通知義務（不適合を発見したら何日以内にベンダーへ通知するか）を明確にしておきます。遅延損害金も、交渉で詰めておきたい項目です。ベンダーが納期を超えた場合、1日あたり請負代金の0.1〜0.3%を損害金として請求できる条項を設けるのが一般的です。
ただし、遅延の原因が発注者側（仕様変更・確認待ち・承認遅延）にある場合は免責されるという但し書きも、合わせて設ける必要があります。数字の高さより大切なのは、「遅延が生じたときに双方がどう対処するか」というプロセスを事前に合意しておくことです。それ自体が、ベンダーにスケジュールを守らせる動機づけになります。
発注後のプロジェクト管理と障害対応
契約を結んでプロジェクトが始まったら、発注者は任せきりにせず、主体的に関わり続けます。
レガシーシステム更改は長期プロジェクトになることが多く、途中でスコープの拡大や仕様変更、予期せぬ課題が生じます。そのため、これらを早期に把握し、適切に判断するための管理体制が必要です。
暫定対応（業務継続優先）と根本対応（バグ修正）の2段階フロー
新システムの稼働後に起きる本番障害への対応フローは、プロジェクト開始前から設計しておくことが欠かせません。特に移行直後は、想定外のデータ不整合やシステム間連携のエラーが起きやすく、迅速な判断が求められます。障害対応の基本は「暫定対応（業務継続優先）」と「根本対応（バグ修正）」の2段階で、第一の優先は業務を止めないことです。
暫定対応では、影響を最小化する代替処理（例：エラーの出る機能の一時停止と手動対応への切り替え、バッチ処理の強制スキップなど）を即座に実施します。この判断は業務担当者も含む合同チームで行い、「この機能を止めたら、どの業務が影響を受けるか」を確認します。暫定対応で業務継続の目途が立ったら、根本原因の特定と恒久対応（バグ修正・プログラム改修）に進みます。
根本対応の優先度と期限は、サービスレベルアグリーメント（SLA）で事前に定めると、判断基準が明確になります。たとえば、「業務停止を引き起こす重大障害は4時間以内に暫定対応、24時間以内に修正版リリース」といった基準を設けると、期待値を揃えられます。業務影響が軽微な軽度障害は次回定期リリースに含める、という基準も設けられます。
初期流動管理による稼働直後の混乱の抑制
初期流動管理とは、新システムの本番稼働直後に起きやすいトラブルに備えて、ベンダーの支援体制を通常より手厚くする期間のことです。期間の目安は、一般的に稼働後1〜3ヶ月間です。
この期間は、ベンダーのエンジニアがオンサイト（発注者のオフィス）か常時待機で対応し、問題が起きた際の初動を素早く行えるよう体制を整えます。稼働直後の混乱を抑えるには、施策を事前に決めておくと対応が安定します。
具体的な施策は、次の4つが効果的です。
- 常駐・即時対応：稼働後2〜4週間は、現地に詰めるか、リモートで素早く応じる体制を保証します。
- 日次報告：障害と課題を、発注者とベンダーが毎日突き合わせる場です。
- 既知課題の管理：Known Issue Listを共有し、優先度順に追える一覧にします。
- 専用窓口：現場ユーザーの声を一か所に集める役割です。
こうした体制を契約書の「保守・サポート条項」に盛り込んでおけば、稼働直後の混乱期も被害を最小限に抑えて乗り切れます。初期流動管理期間を経て問題が落ち着いたら、通常の保守・運用フェーズへ移る流れが理想的です。
まとめ
レガシーシステム更改の発注・外注・委託は、通常のシステム開発より格段に複雑です。
考慮すべき事項は多岐にわたり、現行システムの把握と既存ベンダーとの関係整理から始まります。予算を提示しない戦術的なRFP設計、スコアリングと定性評価を組み合わせたベンダー選定、ベンダーロックイン防止条項の契約への盛り込みと続きます。そして、本番障害に備えた2段階フローと初期流動管理体制の構築まで、一連の流れを押さえる必要があります。
しかし、一つひとつ丁寧に進めれば、「更改しても結局また同じ問題を抱えた」という失敗を避けられ、新しいシステムは組織の成長を支える基盤になります。
最初の準備（現行システムのドキュメント化・体制構築）に手間をかけることが、プロジェクト全体の成功率を高める最大の投資です。発注前の段階から専門家に相談しながら進めることで、より確実なプロジェクト推進が実現できます。
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を創業。