基幹システム／ERPリプレイスは、数千万円から数億円規模の投資を伴う大型プロジェクトです。そのため、発注の進め方そのものがプロジェクト全体の成否を左右します。発注は情報収集から契約まで段階を踏んで進み、各段階で発注側が主導権を持つことが大切です。
▼全体ガイドの記事
・基幹システム/ERPリプレイスの完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
基幹システム/ERPリプレイスの発注プロセス全体像
発注プロセスは、RFI（情報提供依頼）、RFP（提案依頼）、評価・選定、契約の4つのフェーズで進みます。各フェーズを一つずつ丁寧に踏むことで、ベンダーとの認識齟齬を小さくし、契約後のトラブルを未然に防げます。
- フェーズ1：RFIによる市場調査（ベンダーの製品概要や導入実績の把握）
- フェーズ2：RFPによる発注要件の提示
- フェーズ3：提案の評価と選定
- フェーズ4：契約内容の精査と締結
RFI（情報提供依頼）→RFP（提案依頼）→評価・選定→契約の流れ
最初のステップはRFI（Request for Information）で、ベンダーの製品概要・導入実績・対応可能な技術スタックなどの基礎情報を集めます。RFIはRFP作成前の市場調査として機能し、一般的には5〜10社程度に声をかけて、回答内容をもとに3〜5社まで候補を減らします。RFIで候補を絞ったら、次はRFP（Request for Proposal）を作成します。
RFPは、要件を並べた一覧にとどめず、「この提案書によって正しい提案を引き出す」という目的意識をもって作ることが大切です。発注側は、機能要件・非機能要件・スケジュール・予算上限・評価基準をすべて明記し、ベンダーが回答しやすい形にまとめます。RFPの質が提案の質を直接決めるといっても過言ではありません。
RFPへの回答（提案書）が集まれば、機能適合率・TCO（総所有コスト）・導入実績・サポート体制・PM体制などを評価軸に、重み付けスコアリングで客観的に比べます。その際、口頭説明だけでなくPoC（Proof of Concept）で実測データを取ることが、建築業B社のような「性能見積もりの甘さ」による工期延伸・予算超過を防ぐうえで不可欠です。最終的に1〜2社に絞り込み、契約交渉へ進みます。
発注前に整備すべき社内ドキュメント
RFIやRFPを作る前に、社内で整えておくべきドキュメントがあります。まず「現状業務フロー図」が必要です。現行システムの業務の流れを図にして整理しておかないと、ベンダーへの要件説明が担当者の口頭伝達頼みになり、後から「そんなことは聞いていなかった」という対立を招きます。
次に「課題一覧と優先順位付き要件リスト」が必要です。解決したい課題を業務ごとに整理し、「必須要件（Must）」「あれば望ましい要件（Want）」「将来対応でよい要件（Nice to have）」の3段階に分類して整備します。非機能要件は、あとで決めるのではなく、発注前に数値化しておくことを強く推奨します。
さらに「非機能要件定義書」では、同時接続数やバッチ処理時間などのパフォーマンス、稼働率や計画停止時間などの可用性、認証方式やアクセス権限管理などのセキュリティ要件を数値で定義します。建築業B社は、大容量データや連携バッチの性能要件を曖昧なまま発注したため、PoCの段階で初めて性能不足が発覚し、工期が大幅に延伸しました。
RFPの書き方——ベンダーから良い提案を引き出すコツ
RFPは、ベンダーに「何を作ってほしいか」を伝えるための最重要文書です。質の低いRFPからは質の低い提案しか生まれず、後の追加費用やスコープ争いの原因になります。
RFPに記載すべき項目一覧とサンプル
ERPリプレイスのRFPには、①プロジェクトの背景・目的（なぜリプレイスするのか、経営課題との関連）と、②現状システムの概要と課題（現行ERP名、稼働年数、利用ユーザー数、主要課題）を必ず盛り込みます。さらに、③機能要件一覧（業務モジュール別の必須・任意機能を一覧化）と、④非機能要件（性能・可用性・セキュリティ・拡張性の数値基準）を入れます。
また、⑤データ移行の範囲と方針（移行対象データ種別、マスタデータ量、移行先ER図）と、⑥連携システム一覧（会計・人事・倉庫管理など連携が必要な周辺システム）を含めます。⑦プロジェクト体制と役割分担（発注側が担うタスクの明記）、⑧スケジュール概要（カットオーバー目標日・マイルストーン）、⑨予算規模の目安、⑩提案書フォーマットと評価基準も欠かせません。
特に重要なのは⑦プロジェクト体制と役割分担です。発注側の担当者が要件定義の主体となるのか、ベンダー主導で進めるのかを明記すると、準委任契約か請負契約かの選択にも直結します。また、⑩の評価基準を事前に示すと、ベンダーが評価軸に合わせた提案を作りやすくなり、提案書の比較精度も上がります。
曖昧な表現を避ける具体化テクニック
RFP作成で最も犯しやすいミスは「現行踏襲」という表現です。「現行と同等の機能を提供すること」と書くと、ベンダーは現行システムを詳細に分析しない限り正確な見積もりができず、後から「現行にはこんな機能があった」「それは聞いていなかった」という対立が生まれます。
要件は、「○○画面で△△の操作ができること」のように、具体的な行動を基準に書く必要があります。「高速に処理できること」「使いやすいこと」といった定性的な表現も厳禁です。パフォーマンス要件であれば、「受注入力画面の画面表示は3秒以内」「月次バッチ処理は4時間以内に完了」のように数値化します。
セキュリティ要件であれば、「ISO/IEC 27001準拠」「多要素認証の実装」のように、具体的な規格・仕様を示します。この数値化こそが、建築業B社のような性能問題による予算超過を防ぐ最大の防御策です。
RFP提示後の要件追加の防ぎ方
RFPを提示した後に要件が追加・変更されると、ベンダーから追加見積もりが出て、当初予算を大幅に超えるおそれがあります。これを防ぐために、RFP提示前に「要件凍結日」を社内で設定し、経営層と現場部門の承認を取っておくことが重要です。
要件変更が生じた場合は、「変更管理プロセス」として正式な変更申請・影響評価・承認の流れを契約書に明記します。口頭での要件追加は、組織ルールとして禁止しておきます。
見積もりの精度については、「超概算・概算・確定」の違いを発注側が正しく理解することも欠かせません。RFP段階の見積もりは要件定義前の「概算」で、要件定義が完了して初めて「確定見積もり」が得られます。見積もりの変動は避けられませんが、「どの段階の見積もりか」を双方が認識したうえで契約すれば、後のトラブルを減らせます。
見積もりの精査と相見積もりの比較方法
複数のベンダーから見積もりを取ると、金額に大きな差が出ることは珍しくありません。ERPリプレイスでは数千万円から数億円規模の見積もりが並ぶこともあるため、単純に安い方を選ぶのは危険です。
見積もりの妥当性を判断する5つのチェックポイント
見積もりの妥当性は、工程別の費用内訳、人月単価、カスタマイズ費用の割合、データ移行費用、保守・運用費用の5点で確かめます。工程別の内訳は、開発・実装50〜60%、要件定義10〜15%、設計10〜25%、テスト5〜10%、運用保守15〜20%が業界標準で、大きく外れる場合は理由を確認します。人月単価は、新人〜中堅が80〜140万円、上級エンジニアが140〜250万円が相場です。
単価が著しく低い場合は、経験不足のエンジニアが充当されるリスクがあります。ERPパッケージへのカスタマイズが多いほど費用は膨らみ、将来の保守コストも増大します。製造業D社は70%カスタマイズで費用が当初予算の2.5倍に膨張したため、標準機能に業務を合わせる（Fit to Standard）を基本とし、カスタマイズは最小限に抑える姿勢が重要です。
データ移行・クレンジングの費用は見積もりから抜けやすく、後から追加で請求されるケースがあるため、工数は事前に含めるよう発注側から求めます。商社E社は、従業員200名規模にもかかわらず、20年分の顧客データ統合・クレンジングだけで4ヶ月を要しました。カットオーバー後の保守運用費用（月額・年額）も明確にしておかないと、TCO（総所有コスト）で比べられません。
金額差が大きい場合の見極め方
複数の見積もりに大きな差がある場合は、まず原因を特定します。主な原因は、「スコープの解釈の違い」「工数の見積もり手法の違い」「標準機能対応とカスタマイズ対応の違い」の3つです。
安価な見積もりがスコープを意図的に絞り込んでいる場合、カットオーバー後に追加費用が発生し、最終的に高くつくことがあります。見積もりの比較は、同一の要件定義書（RFP）に基づくことが大前提です。そのうえで、内訳が不明瞭な見積もりには必ず質問状を送り、工数・単価・スコープの根拠を明示してもらいます。
また、過去の類似プロジェクトの実績データを参考にする「類推見積もり」や、機能ポイント数から算出する「FP法」を使えば、ベンダー提示の見積もりと独自試算を照合し、妥当性を検証できます。
契約の落とし穴と法務的注意点
基幹システム／ERPリプレイスの契約段階は、プロジェクト全体で最もリスクが潜む局面のひとつです。契約形態の選択ミスや法律上の注意事項の見落としから、後で取り返しのつかないトラブルに発展するケースがあります。
請負契約と準委任契約の選び方
基幹システム開発の契約形態は、大きく「請負契約」と「準委任契約」の2種類に分かれます。請負契約は「成果物の完成」を目的とし、ベンダーは完成した成果物を納品して初めて報酬を受け取る権利が生じるため、成果物への責任が明確なことが最大の特徴です。一方、準委任契約は「業務の遂行」を目的とし、成果物の完成保証はありません。
準委任契約では、ベンダーは善管注意義務をもって業務を遂行すれば報酬を受け取れます。ERPリプレイスの実務では、フェーズごとに契約形態を使い分けることが一般的です。要件定義フェーズは、発注側とベンダーが協働して要件を探索するため、成果物が事前に確定しない準委任契約が適しています。
設計・開発・テストは、要件が確定していれば請負契約で、設計書やプログラムの完成責任をベンダーに持たせられます。保守・運用フェーズは継続的なサービス提供が目的のため、準委任契約が標準的です。フェーズの性質に応じてハイブリッドに組み合わせると、責任の所在を明確にしながら柔軟にプロジェクトを運営できます。
契約不適合責任（旧：瑕疵担保）の実務的な押さえ方
2020年の民法改正により、旧「瑕疵担保責任」は「契約不適合責任」へと名称・内容ともに変わりました。請負契約では、納品された成果物が契約内容に適合しない場合、発注側は「追完請求（修補・追完）」「代金減額請求」「損害賠償請求」「契約解除」を求められます。
実務では、「何が契約に適合した状態か」を明確に定義することが大切です。具体的には、要件定義書・設計書・テスト仕様書を契約の附属文書として組み込み、「これらの仕様書に記載された機能が正常に動作すること」を契約適合の基準にします。また、契約不適合責任の請求期間（民法上の原則は「知った時から1年」）も契約書で明記します。
カットオーバー後に業務運用の中で初めて不具合が発覚するケースもあるため、「本番稼働後○ヶ月以内に発見された不具合については無償対応」といった保証期間を明確に定めておくことを推奨します。
下請法の適用条件と注意すべき支払いルール
基幹システム開発を外注する場合、発注側の資本金が規模の小さいベンダーより大きいと、下請法（下請代金支払遅延等防止法）が適用される可能性があります。具体的には、情報成果物委託（ソフトウェア開発など）で、資本金5千万円超の発注事業者が資本金5千万円以下の受託事業者に委託する場合が対象です。
下請法でもっとも重要なルールが「60日以内支払い」です。発注者は、成果物・役務を受領した日（検収日ではなく受領日が原則）から60日以内に下請代金を支払わなければなりません。自社の経理ルールで「翌々月末払い」を慣例としている場合でも、受領日から60日を超えれば下請法違反となります。
違反した場合は、公正取引委員会による勧告・公表や、年率14.6%の遅延利息の支払い義務が発生します。中堅規模の発注企業でも下請法の適用対象となるケースは多く、支払い条件の設定には細心の注意が必要です。
SLA（サービスレベル合意）の設計とペナルティ条項
ERPをクラウド型で導入する場合は、保守・運用フェーズにおけるSLA（Service Level Agreement）の設計が重要です。SLAとは、ベンダーが提供するサービスの品質水準（稼働率・障害対応時間・復旧目標時間など）を数値化して合意した文書です。SLAが未整備のまま運用を始めると、障害発生時の責任の所在が曖昧になり、損害賠償請求が困難になります。
SLAで定めるべき主な指標は、システム稼働率（例：月次99.9%以上）、障害発生時の初動応答時間（例：P1障害は1時間以内に応答）などです。復旧目標時間（RTO：例：4時間以内）や、復旧目標時点（RPO：例：直前のバックアップポイントまでのデータ損失許容）も指標に含まれます。
また、SLA未達時のペナルティ条項として、「稼働率が月次99.5%を下回った場合は月額料金の10%を減額する」といった補償内容を契約書に明記します。これにより、ベンダーがサービス品質を保つインセンティブが働きます。ただし、ペナルティが過大すぎるとベンダーの提案辞退・撤退リスクが高まるため、バランスのとれた設計が求められます。
発注後のプロジェクト管理——ベンダーコントロールの実践
発注して契約が完了したからといって、発注側がプロジェクトから手を引いてしまうのは危険です。ベンダーへの丸投げはプロジェクト失敗の最大原因のひとつであることが、複数の実務事例から明らかになっています。
ILUO評価によるフェーズ完了判定の導入
フェーズ移行（ゲートレビュー）では、ドキュメントの完成度だけを判定基準にするのは不十分です。機能要件書が完成したとしても、発注側の担当者がその内容を本当に理解し、運用できるレベルに達しているかが問われます。
そこで有効なのが、「ILUOフレームワーク」を使ったフェーズ完了判定です。ILUOは、習熟度を4段階で評価するフレームワークです。4段階は、I（Introduce：知識として紹介済み）、L（Learn：学習中・補助が必要）、U（Understand：理解・自力実行可能）、O（Others：他者への指導が可能）の順です。
要件定義フェーズの完了判定基準は、「発注側の業務担当者が新システムの操作をUレベル（自力実行可能）で遂行できること」とします。ドキュメントの有無ではなく人間の理解と実行能力を基準にすることで、厳格なフェーズ管理が可能になります。これにより、「要件定義書は作ったが現場担当者が内容を理解していなかった」という典型的な失敗を防げます。
予算超過時の経営陣への説明と追加予算獲得の進め方
ERPリプレイスでは、要件定義の深化や非機能要件の後出しによって、プロジェクト途中で追加費用が発生することは珍しくありません。ガートナーの調査によれば、ERPプロジェクトの75%が何らかの形で当初計画から逸脱することが報告されています。問題はコスト増加そのものではなく、経営陣に適切に説明できないことです。
追加予算の申請では、なぜ追加費用が発生したか（原因の明確化）、追加費用を投じた場合と投じない場合のリスク比較、完了した場合に得られるROI（投資対効果）の3点セットで示します。ROIの算出では、業務効率化による人件費削減額を、管理コスト（福利厚生費等）を踏まえ、各役職の平均給与を2倍にした金額で計算する方法が実務では用いられます。
製造業A社では、ERPリプレイス後に月次決算が3週間から1週間に短縮され、CFOの工数削減だけでも年間換算で数百万円規模のコスト削減効果として試算できます。
損切り（サンクコスト放棄）の判断基準
追加予算を投じても完成が見通せない場合や、ベンダーとの信頼関係が完全に破綻した場合は、プロジェクトの損切り（中断・撤退）を検討する必要があります。しかし、サンクコスト（すでに投じた費用）への執着から、ずるずると継続してしまう「コンコルドの誤謬」に陥りやすいのが現実です。
損切りの判断基準には、「完成まで追加で必要な費用が当初予算総額を超えている」「ベンダーのPMが交代し引き継ぎ能力に重大な疑義がある」といったものがあります。また、「業務要件の根本的な変更（経営戦略の転換）が生じた」「ベンダーの財務状況が悪化し継続リスクが高い」場合も、判断基準になります。
損切りの決断は経営判断であるため、PJTオーナーである経営層が責任を持って下すべきものです。プロジェクト開始時点で「どのような状態になったら損切りを検討するか」という基準を文書化しておけば、感情的な判断を排除した冷静な意思決定が可能になります。
ベンダーとの日常的なコミュニケーションと発注側の役割
ERPリプレイスの成否は、ベンダーの技術力だけでなく、発注側とベンダーの日常的なコミュニケーションの質によって大きく左右されます。問題が大きくなってから表面化させるのではなく、早期に検知して対処できる体制を整えておくことが大切です。
定例会議の仕切り方と遅延の早期発見
週次または隔週で実施するプロジェクト定例会議は、発注側が主体的に仕切ることが原則です。アジェンダも発注側が事前に設定し、「前回アクションアイテムの確認→進捗状況の報告→課題・リスクの共有→次週のアクションアイテムの確認」の流れを固定します。ベンダー任せにすると、都合の悪い遅延情報が共有されないまま問題が先送りされるリスクがあります。
遅延を早期に見つけるには、「EVM（アーンドバリューマネジメント）」の活用が有効です。計画上完了すべきタスク量（PV）と実際に完了したタスク量（EV）を毎週比較し、乖離が生じた時点で即座に原因を追究します。また、「仕様外（追加費用）」とベンダーが主張した際は、契約書のスコープ定義文書を参照しながら対応します。
口頭での要件変更や追加依頼の形跡がある場合は、その記録も確認します。そのうえで、双方の認識齟齬を客観的に整理して交渉するよう心がけます。
PoCによる性能検証と建築業B社の失敗の教訓
建築業B社のERPリプレイスでは、大容量データや連携バッチの性能見積もりを机上の比較だけで行い、PoC（Proof of Concept）を省略したことが致命的な失敗につながりました。選定段階でカタログスペックと人月見積もりだけで評価したため、本格的な開発に入ってから性能不足が発覚し、アーキテクチャの再設計・追加開発が必要になりました。
結果として、工期は計画の1.5倍に延伸し、予算も当初比30%超の超過となりました。この失敗が示す教訓は明確です。
PoCを必ず行うべきなのは、①大量トランザクション処理が必要なケース（例：1日100万件超の受発注処理）、②複数の周辺システムとのリアルタイム連携が必要なケースです。③既存データ量が1,000万件を超えるケース、④月次バッチ・年次処理などの大規模一括処理があるケースも同様です。PoCに費やすコストと時間は、本番稼働後の手戻り費用と比べれば遥かに小さいと考えるべきです。
まとめ
基幹システム／ERPリプレイスの発注は、単なる外注手続きではなく、プロジェクト全体の成否を左右する戦略的なプロセスです。発注の流れは、RFI、RFP、評価・選定、契約の4フェーズです。
RFPの質が提案の質を決めるため、機能要件と非機能要件を数値化し、曖昧な表現を排除することが最重要です。
見積もりは、工程別内訳、人月単価、カスタマイズ比率、データ移行費用、ランニングコストの5点で確認します。契約では、請負と準委任をフェーズごとに使い分け、契約不適合責任の範囲、下請法の60日支払いルール、SLAとペナルティ条項を適切に設計することで、法的リスクを最小化できます。
発注後は丸投げにせず、ILUOフレームワークによるフェーズ完了判定、定例会議での進捗管理、PoCによる性能検証を発注側主導で進めることが求められます。予算超過が起きた場合は、原因・リスク比較・ROIの3点セットで経営陣に説明し、状況によっては損切りも視野に入れます。
ベンダーに主導権を握られず、発注側が主体的にプロジェクトをコントロールし続けることが、基幹システム／ERPリプレイスを成功に導く最大の条件です。
riplaでは、コンサルティングから開発まで一気通貫でERPリプレイスを支援しています。RFP作成の支援、ベンダー選定の伴走、契約交渉のアドバイス、発注後のプロジェクト管理まで、発注側に立ったサポートを提供しています。ご不明な点やご相談があれば、お気軽にお問い合わせください。
▼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を創業。