レガシーシステム更改の発注は、通常のシステム開発と大きく異なります。長年運用されてきたシステムはブラックボックス化が進み、設計書や仕様書が残っていないケースも珍しくありません。既存ベンダーとの関係整理、ドキュメントのない現行システムの棚卸し、そして新たなベンダー選定まで、複数の難題が同時に押し寄せてくるのが現実です。

この記事では、レガシーシステム更改を発注・外注・委託する際に押さえるべき準備から、RFP作成の実践テクニック、ベンダー評価の方法、契約のリスクヘッジ、発注後のプロジェクト管理まで、一気通貫で解説します。予算を提示すべきかどうかという発注側の駆け引き術や、本番障害時の対応フローといった実践的なノウハウも余すところなくお伝えします。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

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

レガシーシステム更改の発注前に準備すべきこと

レガシーシステム更改の失敗の多くは、発注前の準備不足に起因します。現行システムの実態を正確に把握しないまま外部ベンダーに丸投げすると、要件定義が曖昧になり、後から大幅なスコープ拡張や追加費用が発生してしまいます。発注者側が主体的に動き、現状を整理した上でベンダーとの対話に臨むことが、プロジェクト成功の第一歩です。

稼働から10年以上が経過したシステムでは、開発当時の担当者が退職・異動しており、仕様書や設計書が存在しないという状況が頻繁に起きます。このような「ブラックボックス」状態のまま更改プロジェクトを開始すると、新しいベンダーが現行システムの調査だけで膨大な工数を消費し、見積もりが大幅に膨らむ原因となります。

まず取り組むべきは、現行システムのドキュメント化です。完全な仕様書の作成は時間がかかりますが、少なくとも次の情報は発注前に整理しておくことを強くおすすめします。①現在稼働しているサーバー構成・ミドルウェア・データベースの種類とバージョン、②主要な業務フローと画面遷移の概要、③データの種類・件数・保管期間のルール、④連携している外部システムの一覧とAPI仕様、⑤過去に発生した重大障害の履歴と対処記録です。これらを揃えるだけで、新規ベンダーは現状調査フェーズの工数を大幅に削減でき、より精度の高い提案・見積もりが可能になります。

既存ベンダーがシステムの詳細情報の提供に非協力的なケースもあります。この場合は、契約書に「情報開示義務」や「引き継ぎ協力義務」が規定されているか確認し、必要であれば法的根拠をもとに交渉することも選択肢に入れてください。既存ベンダーとの関係が良好であれば、新ベンダーへのスムーズな引き継ぎを依頼することができますが、関係が悪化している場合は、現行システムのリバースエンジニアリング（動作からコードや仕様を逆解析する手法）に対応できるベンダーを選定することが現実的な判断です。

レガシーシステム更改プロジェクトでは、発注者側にIT人材が不在または少ない状態での推進を迫られるケースが多く見られます。特に中堅・中小企業では、情報システム部門が「ベンダーへの窓口担当者が1名いるだけ」という体制も珍しくありません。こうした状況でも、発注者側がプロジェクトの「オーナーシップ」を持って臨む姿勢が不可欠です。

発注者側の体制として最低限確保すべきは、プロジェクトオーナー（経営層の承認権者）、業務要件を語れる業務担当者（現場のキーパーソン）、そして技術的な橋渡しをするIT窓口の3役です。社内にIT知識が不足している場合は、第三者のPMO（プロジェクトマネジメントオフィス）支援会社やITコンサルタントを活用して、発注者側のサポート体制を強化する方法が効果的です。PMOは発注者の代理として要件定義を支援し、ベンダーとの交渉や進捗管理を担うため、プロジェクトの成功確率を高める投資といえます。

RFI・RFPの作成方法と実践テンプレート

ベンダー選定の質は、RFI（情報提供依頼書）とRFP（提案依頼書）の質に直結します。レガシーシステム更改では、通常のシステム開発と異なる固有の項目があります。現行システムの調査・分析能力や移行設計の経験を測るための質問を盛り込むことが、優れたベンダーと実力不足のベンダーを見分ける鍵となります。

RFIは、本格的な提案依頼の前にベンダーの基本的な能力・経験・自社との相性を確認するための情報収集ツールです。レガシーシステム更改に特化したRFIでは、次の点を重点的に確認します。まず「設計書・仕様書が存在しないレガシーシステムの調査経験」について、過去の具体的な事例と採用した調査手法を尋ねます。設計書なしでシステムを解析した経験のあるベンダーは、リバースエンジニアリングや動的解析のノウハウを持っており、初期調査フェーズの遅延リスクを大幅に下げられます。

次に「データ移行の実績」を確認します。レガシーシステムのデータは、現代のデータ形式と互換性がない旧来の形式（例：固定長テキストファイル、EOFコードが特殊なバイナリ）で保存されていることがあります。こうしたデータをクレンジング（品質を整えること）し、新システムへ移行した経験があるベンダーかどうかを問い直します。また、「稼働中のシステムを止めずに移行する（オンライン移行）の経験」についても聞くことで、現行業務を継続しながらの移行に対応できるかを確かめられます。

RFPはベンダーへの正式な提案依頼書であり、記載内容が曖昧だとベンダーごとに解釈が異なり、提案の比較が困難になります。レガシーシステム更改のRFPには次の項目を必ず盛り込みます。①プロジェクトの背景と目的（なぜ今更改するのか、更改後に実現したいビジネス上のゴール）、②現行システムの概要（サーバー構成・技術スタック・主要機能・利用部門・ユーザー数）、③現行システムの課題（保守コスト・セキュリティリスク・拡張性の限界など具体的数値で記載）、④更改後の新システムに求める要件（機能要件と非機能要件）、⑤データ移行の要件（移行対象データの種類・件数・許容停止時間）、⑥プロジェクト体制と役割分担（発注者・ベンダーそれぞれの責任範囲）です。

書き方のコツとして、「～を実現したい」という要望レベルの記述にとどめることが重要です。どのように実現するかはベンダーの提案に委ねることで、各社の技術力・アプローチの違いが提案書に反映され、比較しやすくなります。逆に技術的な詳細実装方法まで発注者側が指定すると、ベンダーの創意工夫が失われ、提案内容が横並びになってしまいます。

RFPに予算を明示すべきかどうかは、発注者が最も迷う点の一つです。予算を開示すると、ベンダーはその上限に近い金額で提案を組み立てる傾向があります。3,000万円の予算を公開すれば、2,800万円〜3,000万円の見積もりが集まりやすくなる、というのが業界の実態です。一方で、予算の下限もない状態ではベンダーが過大な提案を出してくるリスクもあります。

現実的な戦術として「予算は非公開とし、代わりに優先度付きの要件リストを渡す」方法が有効です。具体的には、RFPの要件を「Must Have（必須機能）」「Should Have（できれば欲しい機能）」「Nice to Have（あると良い機能）」の3段階で記載し、「まずMust Haveだけで見積もりを提示し、予算に余裕があればShould Haveを加えた見積もりも合わせて提示してほしい」と依頼します。こうすることで、ベンダーは現実的なスコープで複数のパターンを提示するため、発注者は予算枠を明かさずに複数の見積もりを比較できます。また、最終的な発注交渉で「Should HaveのXX機能を外せば、どこまで費用を下げられますか」と問い直す余地も生まれます。

ベンダー提案の評価・比較手法

複数のベンダーから提案を受け取ったら、公平かつ多角的な視点で評価することが重要です。価格だけで判断すると、安価でも技術力が不足していたり、プロジェクト管理が杜撰なベンダーを選んでしまうリスクがあります。定量評価と定性評価を組み合わせることで、より精度の高い意思決定が可能になります。

スコアリングシートは、評価軸と配点を事前に決めておくことで、評価者の主観を排除し、客観的な比較を可能にするツールです。レガシーシステム更改では、次の評価軸と配点比率が参考になります。技術力・開発実績（30点）、価格の適切さ（25点）、プロジェクト管理体制（20点）、移行計画の具体性（15点）、保守・サポート体制（10点）という5軸合計100点満点の構成が典型例です。

技術力の評価では、レガシーシステムに類似した更改実績の件数や規模を重視します。「過去3年以内に同規模のレガシー更改を3件以上経験している」「使用技術スタックが重複している」といった具体的な根拠で加点することで、恣意的な評価を防げます。価格評価では、単純に安い順に点数を付けるのではなく、「見積もりの根拠が明確であるか（工数や単価の内訳が記載されているか）」も評価基準に加えることをおすすめします。根拠なく他社より30%安い見積もりは、後から追加費用を請求される「安値受注→変更費用回収」の典型的なパターンです。

スコアリングでは測れない定性的な評価も、実プロジェクトの成否に大きく影響します。特にレガシー更改のような長期プロジェクトでは、プロジェクトマネージャー（PM）の対応力が最重要因子の一つです。提案時のプレゼンテーションや質疑応答を通じて、次の点を確認します。まず「想定外の課題が発生した場合にどう対処するか」という質問に対する回答の質です。具体的な経験を交えて説明できるPMは、問題解決への実績と自信を持っている証拠です。逆に「その場合はお客様と協議します」という型通りの回答しかできないPMは、実務経験が浅い可能性があります。

企業文化との相性も見逃せません。スピード重視でアジャイルな進め方を好む発注者企業が、重厚なドキュメント管理と慎重な工程管理を旨とする大手SIerと組むと、意思決定のスピードのズレがプロジェクト全体の停滞を招くことがあります。提案プレゼン後に非公式な質問時間を設け、「貴社チームの通常のコミュニケーション頻度や進捗報告の方法は？」と尋ねることで、実務上の相性を事前に把握できます。

スコアリング結果が同点もしくは僅差だった場合の最終判断には、「どちらのベンダーと長期的な関係を築きたいか」という視点を活用します。レガシー更改は稼働後の運用・保守フェーズも含めると5年〜10年の関係になることも多く、プロジェクト終了後のサポート体制や継続的な改善への意欲が差別化要因となります。過去の顧客に対する稼働後フォロー事例を確認し、顧客満足度向上への取り組みをヒアリングすることが効果的です。また、ベンダー担当者の離職率や、担当PMが途中交代した場合の対応方針も確認しておくと、長期安定運用のリスクを把握できます。

契約締結時に押さえるべきリスクヘッジ

発注先が決まったら、次は契約交渉です。レガシーシステム更改では、契約書の内容が後のトラブルを防ぐ最後の砦となります。どの契約形態を選ぶか、どのような免責・責任範囲を設けるかによって、プロジェクトが難航したときのダメージコントロールが大きく変わります。

システム開発の契約形態には大きく「請負契約」と「準委任契約」の2種類があります。請負契約はベンダーが成果物（完成したシステム）の完成を約束する形態で、仕様が明確に固まっている場合に適しています。一方、準委任契約はベンダーが善管注意義務をもって作業することを約束する形態で、要件が流動的なフェーズや、調査・コンサルティング業務に向いています。

レガシーシステム更改では、フェーズによって使い分けることが賢明です。現行システム調査・要件定義フェーズは仕様が確定していないため準委任契約が適切で、基本設計が固まった後の開発・テスト・移行フェーズは請負契約でスコープと納期を明確にする、という二段構えが一般的です。ただし、請負契約においても「変更管理手続き（Change Request手続き）」の条項を入れることが重要です。現行システムの調査を進める中で仕様の追加・変更が必要になった際に、追加費用や工期の変更をどう取り扱うかのプロセスを明文化しておかないと、後から「それは契約範囲内か外か」という水掛け論が発生します。

レガシーシステム更改において最も軽視されがちで、しかし最も重大な契約事項の一つが「ベンダーロックイン防止」です。現行のレガシーシステムがなぜ脱却困難だったのかを振り返れば、多くの場合「当初の契約でデータ構造や移行手順の情報開示義務を明記しなかった」という点に行き着きます。同じ過ちを新しいシステムで繰り返さないために、契約書に次の条項を盛り込みます。

まず「データ所有権の明確化」です。発注者が生成・蓄積したデータはすべて発注者の財産であることを明記し、ベンダーが契約終了後もデータを保持・利用できないことを規定します。次に「ソースコードの開示・エスクロー」です。ベンダーが開発したシステムのソースコードは契約終了時に発注者へ引き渡すことを義務づけ、それが困難な場合は第三者機関（エスクロー）にソースコードを預ける仕組みを設けます。さらに「引き継ぎ協力義務」として、ベンダーが変更される際にはX週間以上の移行支援期間を設け、後任ベンダーへの技術情報開示・引き継ぎ作業を誠実に実施することを規定します。この3点を契約書に明記するだけで、数年後のベンダー変更を格段にスムーズに進められるようになります。

2020年の民法改正により「瑕疵担保責任」という概念は廃止され、「契約不適合責任」に統一されました。これは、納品されたシステムが契約で定めた仕様・品質・機能に適合しない場合、発注者はベンダーに対して追完請求（修正・追加納品）、代金減額請求、損害賠償請求などができるという規定です。契約書では「契約不適合責任の期間（通常は引き渡しから1年が多いが、複雑なシステムでは2年以上を交渉）」と「通知義務（不適合を発見したら何日以内にベンダーへ通知するか）」を明確にしておきます。

遅延損害金についても、重要な交渉ポイントです。ベンダーが約定の納期を超えた場合に1日あたり請負代金の0.1〜0.3%を損害金として請求できる条項を設けることが一般的です。ただし、遅延の原因が発注者側（仕様変更・確認待ち・承認遅延）にある場合は免責されるという但し書きも合わせて設ける必要があります。大切なのは数字の高低ではなく、「遅延が生じたときに双方がどのように対処するかのプロセスを事前に合意しておくこと」であり、それ自体がベンダーへのスケジュール遵守への動機付けになります。

発注後のプロジェクト管理と障害対応

契約を締結してプロジェクトが始まったら、発注者は「任せきり」にせず、能動的にプロジェクトに関与し続けることが重要です。レガシーシステム更改は長期プロジェクトとなることが多く、途中でスコープ拡大・仕様変更・予期せぬ課題が生じます。これらを早期に把握し、適切に判断するための管理体制が必要です。

新システム稼働後に本番障害が発生した場合の対応フローを、プロジェクト開始前から設計しておくことが欠かせません。特にレガシーシステムから移行した直後の初期稼働期間は、想定外のデータ不整合やシステム間連携のエラーが発生しやすく、迅速な判断と対処が求められます。

障害対応の基本は「暫定対応（業務継続優先）」と「根本対応（バグ修正）」の2段階フローです。障害が発生した際の第一優先は「業務を止めないこと」です。暫定対応では、障害の影響を最小化する代替処理（例：エラーが発生する機能の一時停止と手動対応への切り替え、バッチ処理の強制スキップなど）を即座に実施し、業務継続を確保します。この判断はシステム担当者だけでなく業務担当者も含めた合同チームで行い、「この機能を止めた場合にどの業務がどのように影響を受けるか」を業務観点からも確認します。

暫定対応で業務継続の目処が立ったら、次のフェーズとして根本原因の特定と恒久対応（バグ修正・プログラム改修）に着手します。根本対応の優先度と対応期限はサービスレベルアグリーメント（SLA）で事前に定義しておくと、「いつまでに修正するか」の判断基準が明確になります。例えば「業務停止を引き起こす重大障害は4時間以内に暫定対応、24時間以内に修正版リリース」「業務影響が軽微な軽度障害は次回定期リリースに含める」という基準を設けると、ベンダーと発注者の期待値をあらかじめ揃えられます。

初期流動管理とは、新システムの本番稼働直後に発生しやすいトラブルに備えて、ベンダーの支援体制を通常よりも手厚くする期間（一般的に稼働後1〜3ヶ月間）のことを指します。この期間中は、ベンダーのエンジニアがオンサイト（発注者のオフィス）または常時待機状態で対応し、問題が発生した場合の初動対応を迅速に行えるよう体制を整えます。

初期流動管理の具体的な施策として次の4点が効果的です。①本番稼働後2〜4週間のベンダーエンジニア常駐（または即時リモート対応保証）、②日次の障害・課題報告ミーティング（発注者・ベンダー合同）、③既知の課題リスト（Known Issue List）の共有と優先度管理、④現場ユーザーからのフィードバックを集める専用窓口の設置です。こうした体制を契約書の「保守・サポート条項」に盛り込んでおくことで、稼働直後の混乱期を最も被害を最小化した状態で乗り越えられます。初期流動管理期間を経て問題が落ち着いたタイミングで、通常の保守・運用フェーズへ移行する流れが理想的です。

まとめ

レガシーシステム更改の発注・外注・委託は、通常のシステム開発より格段に複雑です。ブラックボックス化した現行システムの把握、既存ベンダーとの関係整理、予算を提示しない戦術的なRFP設計、スコアリングと定性評価の組み合わせによるベンダー選定、ベンダーロックイン防止条項の契約への盛り込み、そして本番障害に備えた2段階フローと初期流動管理体制の構築と、考慮すべき事項は多岐にわたります。

しかし、これらを一つひとつ丁寧に進めることで、「更改しても結局また同じ問題を抱えた」という失敗を回避し、新しいシステムが組織の成長に貢献する基盤となります。最初の準備（現行システムのドキュメント化・体制構築）に手間をかけることが、プロジェクト全体の成功率を高める最大の投資です。発注前の段階から専門家に相談しながら進めることで、より確実なプロジェクト推進が実現できます。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

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

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

また「Boxシリーズ」による、受発注管理・在庫管理・配送管理・業務システム・生成AI・SaaS・マッチングサイト・EC・アプリ・LINEミニアプリなどの標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」を活用することで、低コスト・短期間でのスクラッチ開発を実現いたします。

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

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

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

執筆者プロフィール

張田谷凌央

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