レガシーシステムリプレイスの発注は、RFI（情報提供依頼）、RFP（提案依頼）、提案の評価とベンダー選定、契約締結の4段階で進めるのが一般的です。各段階で何を決め、何を確認するかを押さえておくと、ベンダーに主導権を握られにくくなります。
▼全体ガイドの記事
・レガシーシステムリプレイスの完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
レガシーシステムリプレイスの発注プロセス全体像
レガシーシステムのリプレイスは、数千万円から数億円規模の投資を伴う経営プロジェクトです。しかし多くの企業では、どのベンダーに何を伝えればよいか、契約はどの形式を選ぶべきか、発注後にどうコントロールするかといった発注プロセスの知識が不足しています。その結果、ベンダーに主導権を握られたまま失敗するケースが後を絶ちません。
ガートナーの調査では、ERPを含む大規模システムプロジェクトの75%が進行中に何らかの形で失敗を経験するという結果があります。その背景には、技術的な問題よりも発注プロセスの設計ミスや契約上の落とし穴が大きく影響しています。そのため、現場で起きやすいトラブルを防ぐには、発注の流れを段階ごとに押さえることが欠かせません。
発注は、市場調査から契約までを次の4つのフェーズに分けて進みます。
- フェーズ1：RFIによる市場調査
- フェーズ2：RFPによる発注要件の提示
- フェーズ3：提案の評価とベンダーの選定
- フェーズ4：契約内容の精査と締結
このプロセスを正しく設計することが、適切なベンダーを選び、プロジェクトを成功に導く第一歩となります。一方で多くの企業は、いきなりRFPを送付してしまいます。まずRFIで市場調査を行い、発注要件を固める段階を踏むことが欠かせません。
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に記載すべき項目一覧
レガシーシステムリプレイスのRFPには、最低限8つの項目を盛り込む必要があります。
- 背景と目的：なぜ今リプレイスするのか、現行システムの何が問題なのか
- 現行システムの概要：技術スタック、稼働年数、連携システム、ユーザー数、データ量
- 実現したいこと：リプレイス後の機能要件と非機能要件
- 移行方式の方針：一括移行か段階移行かなど
- スケジュールの制約：本番稼働の希望時期と中間マイルストーン
- 予算：上限額、または参考レンジ
- 評価基準：提案の評価基準と、提案書のフォーマット
- 締切と連絡先：提案の締切日と、担当者の連絡先
特にレガシーシステムでは、老朽化して仕様書が存在しなかったり、属人化して全容を把握している担当者がいなかったりするケースが多く、現行システムの概要の記述が欠かせません。それでも「わかる範囲で」システム構成図・業務フロー・データ項目一覧・連携先システムを整理して添付すれば、ベンダーは現実的な移行リスクを踏まえた提案ができます。
「詳細は着手後に調査する」という逃げの姿勢は、後になって多額の追加費用要求を招く温床となります。
曖昧な表現を排除して要件を具体化するテクニック
RFPでよく使われる「高速に処理できること」「使いやすいUI」「セキュリティに配慮すること」といった表現は、ベンダーによって解釈が180度異なる危険な曖昧表現です。非機能要件は、特に数値で記述するのが鉄則です。
「1万件のデータを5秒以内に検索できること」「稼働率99.9%以上を保証すること」「パスワードはSHA-256以上でハッシュ化すること」のように、測定可能な指標（メトリクス）で表現します。また、「現行踏襲」という表現も危険です。
この表現は、現行システムの機能を全て引き継ぐという意味で使われがちですが、20年前に作られた業務フローを無批判に引き継ぐことは、技術的負債の再生産につながります。そのため、RFPには「現行の○○機能については業務を見直した上で再設計すること」という方針を明記し、ベンダーに業務改善視点での提案を求めることが賢明です。
RFP提示後の要件追加を防ぐためのスコープ管理
RFPを提示した後に「やはりこの機能も必要だった」という要件追加が発生すると、ベンダーからの追加見積もりにより費用が膨らみます。これを防ぐには、RFP作成の段階で営業・製造・経理・物流など社内の関係部署から幅広くヒアリングし、要件を出し切ることが欠かせません。
特にレガシーシステムには、「誰も使っていないと思っていたが実は月次締めで使っていた」という隠れ機能が潜んでいることが多く、現場担当者への丁寧なヒアリングが不可欠です。さらに、RFPには「スコープ外事項」を明記することも有効です。
「本プロジェクトには○○機能の開発は含まない」と明示することで、ベンダーとの認識齟齬を防ぎ、後から「それは含まれていると思っていた」という水掛け論を回避できます。一方で、見積もりの変動は構造的に起こるものです（超概算・概算・確定見積もりのそれぞれで精度が異なるという性質があります）。そのため、スコープを明確にして変動幅を最小化することが大切です。
見積もりの精査と相見積もりの比較方法
複数社から見積もりを受け取ると、金額に2〜3倍の差が出ることは珍しくありません。この差を「安い方を選べばいい」と判断するのは危険です。
見積もりの差異は、前提としている作業スコープ・品質水準・リスク想定の違いを反映しています。そのため、適切に精査するには、工数内訳の比較と論拠の確認が欠かせません。
見積もりの妥当性を判断する5つのチェックポイント
見積もりを精査する際には、5つの点を必ず確認してください。1つ目は、フェーズ別の費用内訳が明示されているか（要件定義・設計・開発・テスト・移行・保守）です。2つ目は、エンジニアの人月単価と人数構成が記載されているか（目安として新人〜80万円、一般80〜140万円、上級140〜250万円）です。
3つ目は、データ移行費用が含まれているか（これが別途扱いになっていると後から追加費用が発生しやすい）です。4つ目は、テスト工程の工数が開発工数に対して適切か（テストが全体の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（サービスレベル合意）の設計とペナルティ条項
SLA（Service Level Agreement）は、システムの稼働率・応答速度・障害対応時間などのサービス品質基準を数値で定め、未達時の対応を取り決めた合意文書です。SLAは、必ず契約書に組み込んで法的拘束力を持たせる必要があります。具体的には、契約書の別紙として添付し、「本SLAを本契約の一部とする」と明記します。
契約から切り離された参考資料のままでは、法的には義務として機能しません。ペナルティ条項は、SLA違反の重大度に応じて段階的に設定するのが、実務上効果的です。
例えば「月間稼働率99.9%未満・99.5%以上：月額利用料の10%減額」「99.5%未満・99.0%以上：25%減額」「99.0%未満：50%減額」のように、稼働率の水準ごとに減額率を定めます。さらに「障害発生から4時間以内に応急対処がなされない場合：1時間毎に月額の1%減額」のように、障害対応にも数値と措置を対応させます。ペナルティの目的は、制裁ではなく品質維持のインセンティブ設計にあります。
発注後のプロジェクト管理
発注が完了しても、プロジェクトの責任は続きます。むしろここからが、発注側の本当の仕事の始まりです。
発注側が主体的にプロジェクトをコントロールできるかどうかが、成功と失敗を分ける最大の要因です。「何かあればベンダーから報告が上がってくる」という受け身の姿勢は、問題が顕在化するまで何も気づけない状況を生み出します。
ILUO評価によるフェーズ完了判定の導入
プロジェクトのフェーズ移行（例：要件定義から設計へ、開発からテストへ）の判断基準として、ILUOフレームワークの活用をお勧めします。ILUOとは、製造業の多能工教育で用いられる習熟度評価指標で、I（指導の下でできる）・L（1人でできる）・U（理解し教えられる）・O（改善提案できる）の4段階で個人の習熟度を評価するものです。
これをシステム開発のフェーズゲートに適用することで、「書類上は完成しているが、担当者が実際に理解・操作できていない」という状態でのフェーズ移行を防げます。具体的には、各フェーズ完了の条件として「検証チームの主要メンバーがILUOの『U（理解・実行可能）』に到達していること」を設定します。
要件定義の完了判定では、業務担当者が新システムの業務フローを「自分で説明できる（U評価）」状態に達していることを条件とします。テストフェーズの完了判定では、受け入れテストを担当するユーザーが「独立して操作・検証できる（L評価）」以上かを確認します。この基準があれば、ベンダー側の「完成した」という宣言と、発注側の「本当に使えるか」という実態のギャップを客観的に測れます。
予算超過時の経営陣への説明と追加予算獲得の進め方
プロジェクト途中での予算超過は、レガシーシステムリプレイスでは珍しくありません。現行システムのブラックボックス化による調査の追加作業、非機能要件の後出し変更、データクレンジングの想定以上の工数など、複合的な要因が費用を押し上げます。
ある製造業での事例では、標準パッケージへの70%カスタマイズが原因で費用が当初予算の2.5倍に膨張したケースがありますが、同社ではその代わりに業務完全適合による生産性30%向上という成果も得ています。経営陣に追加予算を説明する際は、「なぜ予算が超過したか（原因の説明）」だけでなく「追加投資によって何が達成されるか（費用対効果）」を中心に据えることが説得の鍵です。
予算超過分の費用と、それを投じて得られるROI（業務効率化による人件費削減・売上拡大・リスク回避）を定量的に示します。人件費削減の試算では、削減できる業務時間に、各役職の平均給与の2倍（社会保険料・福利厚生費等の管理コストを含む）を乗じた金額を使うと、より現実的な数値が得られます。
損切り（サンクコスト放棄）の判断基準
最も難しい意思決定の一つが、「プロジェクトを中断するかどうか」の判断です。すでに1億円を投じたプロジェクトが行き詰まると、「1億円を無駄にしたくない」という心理（サンクコスト効果）が追加投資の判断を歪めます。損切りは、経営資源を守るための合理的な意思決定です。
しかし、過去の投資額は回収できない埋没費用であり、これからの意思決定には関係しません。問題になるのは、今後の追加投資で完成させた場合に得られる価値が、追加コストを上回るかどうかです。損切りを検討すべきサインは、次の4つです。
- スコープの膨張：要件定義の大幅な変更が3回以上発生し、スコープが当初比1.5倍以上に膨らんでいる
- 体制の断絶：コアメンバーがベンダー・発注側の双方で入れ替わり、経緯を知る人間がいなくなっている
- 構造的な問題：品質問題の根本原因が技術ではなく、コミュニケーション不全や責任の所在の曖昧さといったプロジェクトマネジメントにある
- 完成時期の見通し：残工数の見積もりが3回以上修正され、完成時期がまったく読めない
ベンダーコントロールの実践ノウハウ
ベンダーを選定した後も、発注側が主導権を握り続けるためには「ベンダーコントロール」の技術が必要です。
ベンダーに任せきりにすると、プロジェクトの進捗・品質・コストがベンダーの都合で動き、発注側が気づいた時には手遅れというケースが多発します。
特にレガシーシステムのリプレイスでは、ブラックボックス情報を持つのが、旧システムを開発したベンダーであるケースもあります。情報の非対称性が発注側を不利な立場に追い込みます。
定例会議の仕切り方と遅延の早期発見
週次の定例会議は、「報告を聞く場」ではなく「問題を早期発見して対処を決める場」として設計するのが大切です。ベンダーの進捗報告スライドをただ聞く会議は、意味がありません。
発注側が主導して、「今週完了予定だった○○の作業が完了しているか」「懸案事項リストの件はどう対処したか」を具体的に確認するアジェンダを設定します。遅延の早期発見には、マイルストーンごとの進捗率を視覚化する「バーンダウンチャート（残作業の推移グラフ）」の共有が効果的です。
また、「本来今週完了すべきタスクで未完了のものは何か」を毎週確認します。未完了の累積が3週間分を超えた段階でエスカレーション（経営陣への報告と対策会議の招集）を行う基準を、プロジェクト開始時に取り決めておくと、遅延対応の迅速化につながります。
「仕様外です」と言われた際の交渉ノウハウ
プロジェクト途中で、ベンダーから「これは仕様外なので追加費用が発生します」と言われるケースは非常に多く、発注側にとって最も厄介な場面の一つです。対処の鍵は、「RFPと契約書の内容に立ち返ること」です。
ベンダーが「仕様外」と主張する場合は、「ではどの文書のどの記述に基づいて仕様外と判断しているか」を、文書で提示させます。RFPに「含まない」と記載されていない限り、一般的に必要と想定される機能の追加費用請求には、交渉の余地があります。
一方で、発注側にも自省が必要です。プロジェクト途中の要件変更（追加・削除・修正）は、正式な変更管理プロセスを通じて行い、口頭での「少し変えてほしい」が積み重なると正当な追加費用の請求根拠になります。変更管理票に変更内容・理由・影響範囲・費用見込みを記録し、双方が合意して正式な変更として処理すれば、後のトラブルを防げます。
まとめ
レガシーシステムリプレイスの発注は、ベンダーを選んで契約した後も続きます。
RFIによる市場調査から、RFPの作成、見積もりの精査、契約締結、発注後のベンダーコントロールまで、発注側が主体的に動き続けることがプロジェクト成功の条件です。注意したいのは、契約、法務、SLA、発注後の4点です。
- 契約：フェーズに応じた請負と準委任の使い分け、要件定義の請負化への慎重な判断
- 法務：下請法の適用条件と、60日以内の支払い義務の確認
- SLA：契約書への組み込みと、段階的なペナルティ条項の設計
- 発注後：ILUO評価、ROI、サンクコストを軸にした継続判断
レガシーシステムのリプレイスはリスクが高いプロジェクトですが、正しい発注プロセスと知識を持って臨めば、成功の確率を高められます。まずはRFIの準備から、一歩を踏み出してみてください。
▼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を創業。