レガシーシステムのリプレイスは、数千万円から数億円規模の投資を伴う経営プロジェクトです。しかし多くの企業では「どのベンダーに何を伝えればよいのか」「契約はどの形式を選ぶべきか」「発注後にどうコントロールするか」という発注プロセスそのものに対する知識が不足しており、ベンダーに主導権を握られたまま失敗するケースが後を絶ちません。ガートナーの調査では、ERPを含む大規模システムプロジェクトの75%が進行中に何らかの形で失敗を経験するという衝撃的なデータがあります。その背景には、技術的な問題よりも発注プロセスの設計ミスや契約上の落とし穴が大きく影響しています。

本記事では、レガシーシステムリプレイスにおける発注プロセスの全体像から、RFP（提案依頼書）の書き方、見積もりの精査方法、そして競合記事がほとんど触れていない契約の法務的注意点（請負 vs 準委任の責任分解、下請法の適用、SLAのペナルティ設計）まで、発注側が主体的にプロジェクトをコントロールするための実践的な知識を体系的に解説します。単なる手順の紹介ではなく、現場で実際に起きるトラブルを防ぐための「武器」となる情報をお伝えします。

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

レガシーシステムリプレイスの発注プロセス全体像

レガシーシステムのリプレイスを外注する際には、「RFI（情報提供依頼）→ RFP（提案依頼）→ 提案評価・ベンダー選定 → 契約締結」という4つのフェーズを経るのが標準的なプロセスです。このプロセスを正しく設計することが、適切なベンダーを選び、プロジェクトを成功に導く第一歩となります。多くの企業がいきなりRFPを送付してしまいますが、まずRFIで市場調査を行い、発注要件を固める段階を踏むことが重要です。

RFI（Request for Information）は、RFPを作成する前にベンダーから技術動向や概算費用、対応可能範囲などの情報を収集するためのドキュメントです。レガシーシステムのリプレイスでは、発注側が自社システムの全容を正確に把握していないケースが多く（いわゆるブラックボックス化の問題）、最初から精密なRFPを書くことは現実的に困難です。そのためRFIを通じて、まず「このような要件で進めることは技術的に可能か」「概算費用はどの程度か」「どのような移行方式が考えられるか」といった情報をベンダー数社から集め、RFP作成の前提知識を固めることが得策です。

RFIで確認すべき主な項目としては、自社の現行システム環境への対応実績、採用を検討している技術スタックやクラウドプラットフォームの知見、データ移行支援の体制、同業種・同規模プロジェクトの導入事例、そして概算の費用レンジがあります。複数のベンダーからRFIの回答を得ることで、市場全体のケイパビリティを把握し、自社のRFPに盛り込む内容の精度を高めることができます。

RFPを複数社に送付し、提案書と見積もりを受領したら、評価基準に基づいてベンダーを選定します。評価は「技術力・実績（40%）」「プロジェクト管理体制・PM力（30%）」「費用（20%）」「サポート・保守体制（10%）」のような重み付けをあらかじめ設定しておくことで、感情に流されない客観的な選定が可能になります。最終候補を2〜3社に絞った後はプレゼンテーション（口頭ヒアリング）を実施し、提案書の内容について深掘りを行います。この段階でPMの人柄・経験・コミュニケーション力を直接確認することが、発注後のプロジェクト円滑化に直結します。

ベンダーを決定したら契約締結に入りますが、ここが最も重要かつリスクの高いフェーズです。「とにかく早く着手したい」という焦りから契約内容を十分に精査せずにサインしてしまうケースが多いですが、契約書の内容が後のトラブルの大半を決定します。特に請負契約と準委任契約の選択、SLA条項、下請法対応については後述する通り慎重に対処する必要があります。

RFPの書き方 ── ベンダーから良い提案を引き出すコツ

RFP（Request for Proposal）は、単なる「要望書」ではありません。ベンダーが適切な提案と見積もりを作成できるよう、プロジェクトの背景・目的・要件・制約条件を過不足なく記述した「発注仕様書」です。RFPの品質がそのままベンダーから受け取る提案の品質を決定します。曖昧なRFPからは曖昧な提案しか生まれず、結果として相見積もりの比較が不可能になります。

レガシーシステムリプレイスのRFPには、最低限以下の項目を盛り込む必要があります。「①プロジェクトの背景と目的（なぜ今リプレイスするのか、現行システムの何が問題なのか）」「②現行システムの概要（技術スタック・稼働年数・連携システム・ユーザー数・データ量）」「③リプレイス後に実現したいこと（機能要件・非機能要件）」「④移行方式の方針（一括移行か段階移行かなど）」「⑤スケジュールの制約（本番稼働希望時期・中間マイルストーン）」「⑥予算の上限または参考レンジ」「⑦評価基準と提案書のフォーマット」「⑧提案締切日と連絡先」の8項目です。

特にレガシーシステムのリプレイスで重要なのは「②現行システムの概要」の記述です。老朽化したシステムは仕様書が存在しなかったり、属人化が進んで全容を把握している担当者がいないケースが多くあります。それでも「わかる範囲で」システム構成図・業務フロー・データ項目一覧・連携先システムを整理して添付することで、ベンダーは現実的な移行リスクを踏まえた提案が可能になります。「詳細は着手後に調査する」という逃げの姿勢は、後になって多額の追加費用要求につながる温床となります。

RFPでよく使われる「高速に処理できること」「使いやすいUI」「セキュリティに配慮すること」といった表現は、ベンダーによって解釈が180度異なる危険な曖昧表現です。非機能要件は特に数値で記述することが鉄則です。「1万件のデータを5秒以内に検索できること」「稼働率99.9%以上を保証すること」「パスワードはSHA-256以上でハッシュ化すること」のように、測定可能な指標（メトリクス）で表現します。

また、「現行踏襲」という表現も危険です。現行システムの機能を全て引き継ぐという意味で使われがちですが、20年前に作られた業務フローを無批判に引き継ぐことは、技術的負債の再生産につながります。RFPには「現行の○○機能については業務を見直した上で再設計すること」という方針を明記し、ベンダーに業務改善視点での提案を求めることが賢明です。

RFPを提示した後に「やはりこの機能も必要だった」という要件追加が発生すると、ベンダーからの追加見積もりにより費用が膨らみます。これを防ぐためには、RFP作成段階で社内の関係部署（営業・製造・経理・物流など）から幅広くヒアリングを実施し、要件を出し切ることが重要です。特にレガシーシステムには「誰も使っていないと思っていたが実は月次締めで使っていた」という隠れ機能が潜んでいることが多く、現場担当者への丁寧なヒアリングが不可欠です。

さらに、RFPには「スコープ外事項」を明記することも有効です。「本プロジェクトには○○機能の開発は含まない」と明示することで、ベンダーとの認識齟齬を防ぎ、後から「それは含まれていると思っていた」という水掛け論を回避できます。見積もり変動は構造的に起こるものですが（超概算・概算・確定見積もりのそれぞれで精度が異なるという性質があります）、スコープを明確にすることで変動幅を最小化できます。

見積もりの精査と相見積もりの比較方法

複数社から見積もりを受け取ると、金額が2〜3倍の差異があることは珍しくありません。この差異を「安い方を選べばいい」と判断するのは危険です。見積もりの差異は、前提としている作業スコープ・品質水準・リスク想定の違いを反映しています。適切な見積もり精査には、工数内訳の比較と論拠の確認が不可欠です。

見積もりを精査する際には、以下の5点を必ず確認してください。「①フェーズ別の費用内訳が明示されているか（要件定義・設計・開発・テスト・移行・保守）」「②エンジニアの人月単価と人数構成が記載されているか（目安として新人〜80万円、一般80〜140万円、上級140〜250万円）」「③データ移行費用が含まれているか（これが別途扱いになっていると後から追加費用が発生しやすい）」「④テスト工程の工数が開発工数に対して適切か（テストが全体の5%未満は過少評価の可能性）」「⑤保守運用費用（ランニングコスト）が明示されているか」の5点です。

一般的な開発工程別費用比率は、開発・実装が全体の50〜60%、要件定義が10〜15%、設計が10〜25%、テストが5〜10%、運用保守が15〜20%とされています。この比率から大きく逸脱している場合は、見積もり根拠の詳細な説明を求める必要があります。特にテスト工程が著しく低い場合は、品質に問題が出るリスクが高まります。

A社が5,000万円、B社が1億円という大きな差が出た場合、単純にA社を選ぶことは危険です。まず両社に「同一の前提条件で見積もっているか」を確認します。A社の見積もりにデータ移行・テスト自動化・非機能要件対応が含まれていない可能性があります。「追加発注が必要になった場合の単価と想定件数」を各社に回答させることで、トータルコストの比較が可能になります。

また「なぜその金額になるのか」をベンダーに口頭でも説明させることが重要です。根拠を明確に説明できないベンダーは、プロジェクト進行中に追加費用を請求してくるリスクが高い傾向があります。逆に高い見積もりでも、データ移行リスクや非機能要件を丁寧に考慮した上での金額であれば、それはむしろ誠実な見積もりと評価できます。

契約の落とし穴と法務的注意点

システム開発の発注で最も多くのトラブルを生むのが「契約」です。技術や要件の問題ではなく、契約書の曖昧さや法的知識の不足が原因で、訴訟や大幅な追加費用請求に至るケースは少なくありません。特にレガシーシステムのリプレイスでは、現行システムのブラックボックス化による仕様の不確かさがあるため、契約形態の選択がより重要になります。

システム開発の契約形態には大きく「請負契約」と「準委任契約」の2種類があります。請負契約はベンダーが「成果物の完成」を義務として負う契約であり、契約不適合責任（旧称：瑕疵担保責任）が発生します。成果物に問題があればベンダーは無償修正や損害賠償の責任を負います。一方、準委任契約はベンダーが「善管注意義務をもって業務を遂行すること」を義務とする契約であり、成果物の完成義務そのものはなく、原則として契約不適合責任は発生しません。

重要なのは、レガシーシステムのリプレイスでは「フェーズによって適切な契約形態が異なる」という点です。要件定義フェーズは「何を作るか」がまだ確定していないため準委任契約が適切であり、詳細設計・開発フェーズは成果物が明確になっているため請負契約が可能になります。この多段階契約の考え方を理解せず、プロジェクト全体を一括して請負契約にしてしまうと、ブラックボックス化した現行システムの調査・分析フェーズでの手戻りや仕様変更が、全て契約不適合の議論に発展するリスクがあります。逆に全フェーズを準委任にすると、ベンダーへの成果物完成義務がなくなり、発注側のリスクが高まります。

2020年の民法改正により「瑕疵担保責任」は「契約不適合責任」に改称され、ユーザー側に有利な改正が行われました。発注側として押さえておくべきポイントは3点です。第一に、契約不適合責任の請求期間は民法上「不適合を知った時から1年以内」となっていますが、システム開発契約では「検収完了後1年以内」とする特約が多く見られます。この期間はできるだけ長く設定することが発注側に有利です。第二に、不適合の内容（どの機能がどう動かないか）を具体的に記録・保存しておくことが、後の責任追及に重要です。第三に、損害賠償の上限額（免責条項）がベンダーの提示する契約書にあらかじめ設定されているケースが多く、この上限が著しく低い場合は交渉で引き上げることを検討してください。

下請法（下請代金支払遅延等防止法）は、発注側の優越的地位の濫用を防ぐための法律で、一定規模以上の企業が中小企業（下請事業者）に業務委託する場合に適用されます。具体的には、資本金3億円超の企業が資本金1,000万円超3億円以下の企業に発注する場合、または資本金1,000万円超の企業が資本金1,000万円以下の企業に発注する場合が対象です。

下請法が適用される場合、発注側には「60日以内の支払い義務」が課されます。これは発注者が定める支払日の上限であり、これを超えると遅延損害金（年14.6%）が発生します。また「発注内容を書面で交付する義務」もあり、口頭のみの発注は認められません。中堅企業がスタートアップや個人事業主のエンジニアにシステム開発を委託する場合、知らずに下請法違反を犯しているケースがあるため注意が必要です。公正取引委員会への申告を受けた場合、社名公表などのペナルティが課される可能性があります。

SLA（Service Level Agreement）は、システムの稼働率・応答速度・障害対応時間などのサービス品質基準を数値で定め、未達時の対応を取り決めた合意文書です。SLAはそれ単体で存在するのではなく、必ず契約書に組み込む形（契約書の別紙として添付し、「本SLAを本契約の一部とする」と明記する）で法的拘束力を持たせる必要があります。SLAが契約から切り離された参考資料として存在するだけでは、法的には義務として機能しません。

ペナルティ条項の設計においては、SLA違反の重大度に応じて段階的に設定することが実務上効果的です。例えば「月間稼働率99.9%未満・99.5%以上：月額利用料の10%減額」「99.5%未満・99.0%以上：25%減額」「99.0%未満：50%減額」「障害発生から4時間以内に応急対処がなされない場合：1時間毎に月額の1%減額」といった形で、具体的な数値と措置を対応させます。ペナルティを設定する目的は「制裁」ではなく「品質維持のインセンティブ設計」であり、ベンダーが真剣に品質を守るための仕組みとして機能させることが目標です。

発注後のプロジェクト管理

発注が完了してもプロジェクトの責任は終わりではありません。むしろここからが発注側の本当の仕事の始まりです。ベンダーに丸投げせず、発注側が主体的にプロジェクトをコントロールすることが、成功と失敗を分ける最大の要因です。「何かあればベンダーから報告が上がってくる」という受け身の姿勢は、問題が顕在化するまで何も気づけない状況を生み出します。

プロジェクトのフェーズ移行（例：要件定義から設計へ、開発からテストへ）の判断基準として、ILUOフレームワークの活用をお勧めします。ILUOとは、製造業の多能工教育で用いられる習熟度評価指標で、I（指導の下でできる）・L（1人でできる）・U（理解し教えられる）・O（改善提案できる）の4段階で個人の習熟度を評価するものです。これをシステム開発のフェーズゲートに適用することで、「書類上は完成しているが、担当者が実際に理解・操作できていない」という状態でのフェーズ移行を防ぐことができます。

具体的には、各フェーズ完了の条件として「検証チームの主要メンバーがILUOの『U（理解・実行可能）』に到達していること」を設定します。要件定義の完了判定では、業務担当者が新システムの業務フローを「自分で説明できる（U評価）」状態に達していることを条件とします。テストフェーズ完了の判定では、受け入れテストを担当するユーザーが「独立して操作・検証できる（L評価）」以上に達していることを確認します。この基準を設けることで、ベンダー側の「完成した」という宣言と、発注側の「本当に使えるか」という実態のギャップを客観的に測定できます。

プロジェクト途中での予算超過はレガシーシステムリプレイスでは珍しくありません。前述の通り、現行システムのブラックボックス化による調査の追加作業、非機能要件の後出し変更、データクレンジングの想定以上の工数など、複合的な要因が費用を押し上げます。ある製造業での事例では、標準パッケージへの70%カスタマイズが原因で費用が当初予算の2.5倍に膨張したケースがありますが、同社ではその代わりに業務完全適合による生産性30%向上という成果も得ています。

追加予算を経営陣に説明する際には「なぜ予算が超過したか（原因の説明）」だけでなく「追加投資によって何が達成されるか（費用対効果）」を中心に据えることが説得の鍵です。予算超過分の費用と、その費用を投じることで得られるROI（業務効率化による人件費削減・売上拡大・リスク回避）を定量的に示します。人件費削減の試算では、削減できる業務時間に、各役職の平均給与の2倍（社会保険料・福利厚生費等の管理コストを含む）を乗じた金額を用いることで、より現実的な数値が得られます。

最も難しい意思決定の一つが「プロジェクトを中断するかどうか」の判断です。すでに1億円を投じたプロジェクトが行き詰まった時、「1億円を無駄にしたくない」という心理（サンクコスト効果）が追加投資の判断を歪めます。しかし、過去の投資額はすでに回収できない埋没費用であり、これからの意思決定には関係ありません。問題となるのは「今後追加投資をして完成させた場合に得られる価値が、追加コストを上回るか否か」だけです。

損切りを真剣に検討すべきサインとしては、「①要件定義の大幅な変更が3回以上発生し、スコープが当初比1.5倍以上に膨らんでいる」「②コアメンバーがベンダー・発注側双方で入れ替わり、プロジェクトの経緯を知る人間がいなくなっている」「③品質問題の根本原因が技術的なものでなく、プロジェクトマネジメントの構造的な問題（コミュニケーション不全・責任の所在の曖昧さ）にある」「④残工数の見積もりが3回以上修正されており、完成時期が全く読めない」という4つが挙げられます。損切りはプロジェクトの失敗ではなく、経営資源を守る合理的な意思決定です。

ベンダーコントロールの実践ノウハウ

ベンダーを選定した後、発注側が主導権を握り続けるためには「ベンダーコントロール」の技術が必要です。ベンダーに任せきりにすると、プロジェクトの進捗・品質・コストがベンダーの都合で動き、発注側が気づいた時には手遅れというケースが多発します。特にレガシーシステムのリプレイスでは、現行システムのブラックボックス情報を持っているのが一方はベンダー（旧システムを開発した会社）であるというケースもあり、情報の非対称性が発注側を不利な立場に追い込みます。

週次の定例会議は「報告を聞く場」ではなく「問題を早期発見して対処を決める場」として設計することが重要です。ベンダーが用意した進捗報告スライドをただ聞く会議は意味がありません。発注側から「今週完了予定だった○○の作業が完了しているか」「懸案事項リストの件はどう対処したか」を具体的に確認するアジェンダを発注側が主導して設定します。

遅延の早期発見には、マイルストーンごとの進捗率を視覚化する「バーンダウンチャート（残作業の推移グラフ）」の共有が効果的です。また「本来今週完了すべきタスクで未完了のものは何か」を毎週確認し、未完了の累積が3週間分を超えた段階でエスカレーション（経営陣への報告と対策会議の招集）の基準とすることを、プロジェクト開始時に取り決めておくことが遅延対応の迅速化につながります。

プロジェクト途中でベンダーから「これは仕様外なので追加費用が発生します」と言われるケースは非常に多く、発注側にとって最も厄介なシナリオの一つです。対処の鍵は「RFPと契約書の内容に立ち返ること」です。ベンダーが「仕様外」と主張する場合、「ではどの文書のどの記述に基づいて仕様外と判断しているか」をベンダーに文書で提示させます。RFPに明示的に「含まない」と記載されていない限り、一般的に必要と想定される機能の追加費用請求は、交渉の余地があります。

一方で発注側にも自省が必要です。プロジェクト途中での要件変更（追加・削除・修正）は正式な変更管理プロセスを通じて行い、口頭での「少し変えてほしい」が積み重なると正当な追加費用の請求根拠になります。変更管理票に変更内容・理由・影響範囲・費用見込みを記録し、双方が合意した上で正式な変更として処理する運用を徹底することで、後のトラブルを防ぐことができます。

まとめ

レガシーシステムリプレイスの発注は、単にベンダーを選んで契約すれば終わりではありません。本記事で解説した通り、RFIによる市場調査から始まり、精密なRFPの作成、見積もりの適切な精査、契約形態の選択と法務的リスクの管理、そして発注後のベンダーコントロールまで、発注側が主体的に動き続けることがプロジェクト成功の条件です。

特に競合記事が触れていない重要なポイントを改めて整理します。まず契約については、フェーズに応じた請負・準委任の使い分けが必須であり、特にブラックボックス化したレガシーシステムの要件定義フェーズを請負にすることは高リスクです。次に法務面では、下請法の適用条件（資本金規模による適用判断と60日以内支払い義務）を発注側として理解しておくことが、知らずしらずの法令違反を防ぎます。SLAは必ず契約書に組み込み、ペナルティ条項を段階的に設定することで、品質維持のインセンティブを設計します。そして発注後は、ILUOフレームワークを用いた客観的なフェーズ完了判定や、予算超過時のROIを軸にした経営陣への説明、必要であればサンクコストを切り捨てる損切り判断という、一般的なプロジェクト管理論では語られない実務知見が、プロジェクトを守る武器となります。

レガシーシステムのリプレイスはリスクが高いプロジェクトですが、正しい発注プロセスと知識を持って臨めば、確実に成功の確率を高めることができます。まずはRFIの準備から、一歩を踏み出してみてください。

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

株式会社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を創業。