基幹システムやERPのリプレイスは、数千万円から数億円規模の投資を伴う大型プロジェクトです。それだけに「どこに・どうやって発注するか」という発注プロセスそのものの巧拙が、プロジェクト全体の成否を大きく左右します。ベンダーに主導権を握られたまま進めてしまうと、要件の曖昧さが引き金となって追加費用が膨らんだり、納品後に「言った・言わない」の対立が生じたりするケースが後を絶ちません。

この記事では、RFI・RFPの作成から評価・選定、契約交渉、そして発注後のプロジェクトコントロールまで、基幹システム／ERPリプレイスにおける発注の全プロセスを体系的に解説します。請負契約と準委任契約の責任分解、下請法の適用条件、SLAとペナルティ条項の設計など、競合記事では触れられることの少ない法務・契約面の実務知識も詳しく取り上げます。発注側が主体的にプロジェクトをコントロールするための「武器」として、ぜひ最後までお読みください。

▼全体ガイドの記事
・基幹システム/ERPリプレイスの完全ガイド

基幹システム/ERPリプレイスの発注プロセス全体像

基幹システム／ERPリプレイスの発注プロセスは、大きく「RFI（情報提供依頼）」「RFP（提案依頼）」「評価・選定」「契約」という4つのフェーズに分けられます。各フェーズを丁寧に踏むことで、ベンダーとの認識齟齬を最小化し、契約後のトラブルを未然に防ぐことができます。

最初のステップは「RFI（Request for Information）」です。これはベンダーの製品概要・導入実績・対応可能な技術スタックなどの基礎情報を収集するための文書で、RFP作成前の市場調査として機能します。RFIを複数のベンダーに送付し、回答内容を比較することで、自社の要件に近いベンダーを効率よく絞り込むことができます。RFIの段階では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は質の低い提案しか生まず、後の追加費用やスコープ争いの原因となります。ここでは、ERPリプレイス特有のポイントを中心に、実務で使えるRFP作成の要点を解説します。

ERPリプレイスのRFPには、以下の項目を必ず盛り込む必要があります。①プロジェクト背景・目的（なぜリプレイスするのか、経営課題との関連）、②現状システムの概要と課題（現行ERP名、稼働年数、利用ユーザー数、主要課題）、③機能要件一覧（業務モジュール別の必須・任意機能を一覧化）、④非機能要件（性能・可用性・セキュリティ・拡張性の数値基準）、⑤データ移行の範囲と方針（移行対象データ種別、マスタデータ量、移行先ER図）、⑥連携システム一覧（会計・人事・倉庫管理など連携が必要な周辺システム）、⑦プロジェクト体制と役割分担（発注側が担うタスクの明記）、⑧スケジュール概要（カットオーバー目標日・マイルストーン）、⑨予算規模の目安、⑩提案書フォーマットと評価基準です。

特に重要なのが「⑦プロジェクト体制と役割分担」です。発注側の担当者が要件定義の主体となるのか、それともベンダー主導で進めるのかを明記することで、準委任契約か請負契約かの選択にも直結します。また、「⑩評価基準」を事前に明示することで、ベンダーが評価軸に合わせた提案を作成しやすくなり、提案書の比較精度が上がります。

RFP作成で最も犯しやすいミスが「現行踏襲」という表現です。「現行と同等の機能を提供すること」と書いてしまうと、ベンダーは現行システムを詳細に分析しない限り正確な見積もりができず、後から「現行にはこんな機能があった」「それは聞いていなかった」という対立が生まれます。要件は「○○画面で△△の操作ができること」という具体的な行動ベースで記述する必要があります。

また、「高速に処理できること」「使いやすいこと」といった定性的な表現も厳禁です。パフォーマンス要件であれば「受注入力画面の画面表示は3秒以内」「月次バッチ処理は4時間以内に完了」のように数値化します。セキュリティ要件であれば「ISO/IEC 27001準拠」「多要素認証の実装」と具体的な規格・仕様を示します。この数値化こそが、建築業B社のような性能問題による予算超過を防ぐ最大の防御策です。

RFPを提示した後に要件が追加・変更されると、ベンダーから追加見積もりが提示され、当初予算を大幅に超過するリスクがあります。これを防ぐために、RFP提示前に必ず「要件凍結日」を社内で設定し、経営層・現場部門の承認を取得しておくことが重要です。要件変更が生じた場合は「変更管理プロセス」として正式な変更申請・影響評価・承認のフローを契約書に明記し、口頭での要件追加を組織ルールとして禁止します。

また、見積もりの精度という観点では、「超概算・概算・確定」の違いを発注側が正しく理解することも不可欠です。RFP段階の見積もりは要件定義前の「概算」であり、要件定義が完了して初めて「確定見積もり」が得られます。見積もりが変動すること自体は構造的に避けられないものですが、「どの段階の見積もりか」を双方が明確に認識した上で契約を進めることで、後のトラブルを回避できます。

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

複数のベンダーから見積もりを取得した際、金額に大きな差が生じることは珍しくありません。ERPリプレイスでは数千万円から数億円規模の見積もりが並ぶケースもあり、単純に安い方を選ぶのは危険です。ここでは、見積もりを正しく精査するための考え方を解説します。

見積もりの妥当性を判断する際に確認すべきポイントは以下の5つです。第一に「工程別費用内訳の有無」です。要件定義・設計・開発・テスト・移行・PM・運用保守の各工程に費用が分解されているかを確認します。一般的に、開発・実装が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年の民法改正により、旧「瑕疵担保責任」は「契約不適合責任」へと名称・内容ともに変更されました。請負契約において、ベンダーが納品した成果物が契約内容に適合しない場合、発注側は「追完請求（修補・追完）」「代金減額請求」「損害賠償請求」「契約解除」を求めることができます。ERPリプレイスの実務では、「何が契約に適合した状態か」を明確に定義することがポイントです。

具体的には、要件定義書・設計書・テスト仕様書を契約の附属文書として正式に組み込み、「これらの仕様書に記載された機能が正常に動作すること」を契約適合の基準とすることが重要です。また、契約不適合責任の請求期間（民法上の原則は「知った時から1年」）をどう設定するかも契約書で明記します。カットオーバー後に業務運用の中で初めて不具合が発覚するケースもあるため、「本番稼働後○ヶ月以内に発見された不具合については無償対応」といった保証期間を明確に定めておくことを推奨します。

基幹システム開発を外注する場合、発注側の資本金が規模の小さいベンダーより大きい場合、下請法（下請代金支払遅延等防止法）が適用される可能性があります。具体的には、情報成果物委託（ソフトウェア開発など）において、資本金5千万円超の発注事業者が資本金5千万円以下の受託事業者に委託する場合に適用されます。

下請法の最も重要なルールが「60日以内支払い」です。発注者は、成果物・役務を受領した日（検収日ではなく受領日が原則）から60日以内に下請代金を支払わなければなりません。自社の経理ルールで「翌々月末払い」を慣例としている場合でも、これが受領日から60日を超えると下請法違反となります。違反した場合、公正取引委員会による勧告・公表や、年率14.6%の遅延利息の支払い義務が発生します。中堅規模の発注企業でも下請法の適用対象となるケースは多く、支払い条件の設定には細心の注意が必要です。

ERPをクラウド型で導入する場合、保守・運用フェーズにおけるSLA（Service Level Agreement）の設計が重要です。SLAとは、ベンダーが提供するサービスの品質水準（稼働率・障害対応時間・復旧目標時間など）を数値化して合意した文書です。SLAが未整備のまま運用を開始すると、障害発生時の責任の所在が曖昧になり、損害賠償請求が困難になります。

SLAで定めるべき主な指標としては、システム稼働率（例：月次99.9%以上）、障害発生時の初動応答時間（例：P1障害は1時間以内に応答）、復旧目標時間（RTO：例：4時間以内）、復旧目標時点（RPO：例：直前のバックアップポイントまでのデータ損失許容）などがあります。また、SLA未達時のペナルティ条項として、「稼働率が月次99.5%を下回った場合は月額料金の10%を減額する」といった具体的な補償内容を契約書に明記することで、ベンダーのサービス品質維持に対するインセンティブが働きます。ただし、ペナルティが過大すぎるとベンダーの提案辞退・撤退リスクが高まるため、バランスのとれた設計が求められます。

発注後のプロジェクト管理——ベンダーコントロールの実践

発注して契約が完了したからといって、発注側がプロジェクトから手を引いてしまうのは危険です。ベンダーへの丸投げはプロジェクト失敗の最大原因のひとつであることが、複数の実務事例から明らかになっています。ここでは、発注後に発注側が主体的に取り組むべきプロジェクト管理の実践知識を解説します。

プロジェクトのフェーズ移行（ゲートレビュー）において、ドキュメントの完成度だけを判定基準にするのは不十分です。機能要件書が「完成した」としても、発注側担当者がその内容を本当に理解し、運用できるレベルに到達しているかが重要です。ここで有効なのが「ILUOフレームワーク」を活用したフェーズ完了判定です。

ILUOは、「I（Introduce：知識として紹介済み）」「L（Learn：学習中・補助が必要）」「U（Understand：理解・自力実行可能）」「O（Others：他者への指導が可能）」の4段階で習熟度を評価するフレームワークです。要件定義フェーズの完了判定基準として、「発注側の業務担当者が新システムの操作をUレベル（自力実行可能）で遂行できること」を設定することで、ドキュメントの有無ではなく「人間の理解と実行能力」を基準にした厳格なフェーズ管理が可能になります。これにより、「要件定義書は作ったが現場担当者が内容を理解していなかった」という典型的な失敗パターンを防ぐことができます。

ERP リプレイスプロジェクトでは、要件定義の深化や非機能要件の後出しによって、プロジェクト途中で追加費用が発生することは珍しくありません。ガートナーの調査によれば、ERPプロジェクトの75%が何らかの形で当初計画から逸脱することが報告されています。問題はコスト増加そのものではなく、経営陣に適切に説明できないことです。

追加予算申請の際は、「なぜ追加費用が発生したか（原因の明確化）」「追加費用を投じた場合と投じない場合のリスク比較」「完了した場合に得られるROI（投資対効果）」を3点セットで提示します。ROI算出の際、業務効率化による人件費削減額は管理コスト（福利厚生費等）を踏まえ、各役職の平均給与を2倍にした金額で計算する方法が実務では用いられます。製造業A社では、ERPリプレイス後に月次決算が3週間から1週間に短縮されており、CFOの工数削減だけでも年間換算で数百万円規模のコスト削減効果として試算できます。

追加予算を投じても完成が見通せない、あるいはベンダーとの信頼関係が完全に破綻してしまったケースでは、プロジェクトの損切り（中断・撤退）を検討する必要があります。しかし、サンクコスト（すでに投じた費用）への執着から、ずるずるとプロジェクトを継続してしまう「コンコルドの誤謬」に陥りやすいのが現実です。

損切りの判断基準としては、「完成まで追加で必要な費用が当初予算総額を超えている」「ベンダーのPMが交代し引き継ぎ能力に重大な疑義がある」「業務要件の根本的な変更（経営戦略の転換）が生じた」「ベンダーの財務状況が悪化し継続リスクが高い」などが挙げられます。損切りの決断は経営判断であるため、PJTオーナーである経営層が責任を持って下すべきものです。プロジェクト開始時点で「どのような状態になったら損切りを検討するか」という判断基準を文書化しておくことで、感情的な判断を排除した冷静な意思決定が可能になります。

ベンダーとの日常的なコミュニケーションと発注側の役割

ERPリプレイスの成否は、ベンダーの技術力だけでなく、発注側とベンダーの日常的なコミュニケーションの質によって大きく左右されます。問題が大きくなってから表面化するのではなく、早期に検知して対処できる体制を整えることが重要です。

週次または隔週で実施するプロジェクト定例会議は、発注側が主体的に仕切ることが原則です。アジェンダを事前に発注側が設定し、「前回アクションアイテムの確認→進捗状況の報告→課題・リスクの共有→次週のアクションアイテムの確認」という流れを固定化します。ベンダー任せにしてアジェンダを先方に委ねると、都合の悪い遅延情報が共有されないまま問題が先送りされるリスクがあります。

遅延を早期発見するために有効なのが「EVM（アーンドバリューマネジメント）」の活用です。計画上完了すべきタスク量（PV）と実際に完了したタスク量（EV）を毎週比較し、乖離が生じた時点で即座に原因を追究します。また、「仕様外（追加費用）」とベンダーが主張した際の交渉については、契約書のスコープ定義文書を参照しながら対応します。口頭での要件変更や追加依頼を行った形跡がある場合はその記録も確認し、双方の認識齟齬を客観的に整理した上で交渉するという姿勢が重要です。

建築業B社のERPリプレイスプロジェクトでは、大容量データや連携バッチの性能見積もりを机上の比較だけで行い、実際のPoC（Proof of Concept）を省略したことが致命的な失敗につながりました。選定段階ではカタログスペックと人月見積もりだけで評価を行ったため、本格的な開発フェーズに入ってから性能不足が発覚し、アーキテクチャの再設計・追加開発が必要となりました。結果として、工期は計画の1.5倍に延伸し、予算も当初比30%超の超過となりました。

この失敗が示す教訓は明確です。ERPリプレイスにおいて、以下の条件に該当するプロジェクトでは必ずPoCを実施してください。①大量トランザクション処理が必要なケース（例：1日100万件超の受発注処理）、②複数の周辺システムとリアルタイム連携が必要なケース、③既存データ量が1,000万件を超えるケース、④月次バッチ・年次処理などの大規模一括処理があるケースです。PoCに費やすコストと時間は、本番稼働後の手戻り費用と比較すれば遥かに小さいと考えるべきです。

まとめ

基幹システム／ERPリプレイスの発注は、単なる「外注手続き」ではなく、プロジェクト全体の成否を左右する戦略的なプロセスです。この記事で解説した発注の全体像を改めて整理します。

まず発注プロセスは「RFI→RFP→評価・選定→契約」の4フェーズで構成されます。RFPの質が提案の質を決定するため、機能要件・非機能要件を数値化し、曖昧な表現を排除することが最重要です。見積もりの精査では、工程別内訳・人月単価・カスタマイズ比率・データ移行費用・ランニングコストの5点を確認します。契約面では、請負と準委任をフェーズごとに使い分け、契約不適合責任の範囲、下請法の60日支払いルール、SLAとペナルティ条項を適切に設計することで法的リスクを最小化できます。

発注後は丸投げにせず、ILUOフレームワークを活用したフェーズ完了判定、定例会議での進捗管理、PoCによる性能検証を発注側主導で推進することが求められます。予算超過が発生した場合は原因・リスク比較・ROIの3点セットで経営陣に説明し、状況によっては損切りの決断も視野に入れます。ベンダーに主導権を握られずに発注側が主体的にプロジェクトをコントロールし続けること——それが基幹システム／ERPリプレイスを成功に導く最大の条件です。

riplaでは、コンサルティングから開発まで一気通貫でERPリプレイスを支援しています。RFP作成の支援、ベンダー選定の伴走、契約交渉のアドバイス、発注後のプロジェクト管理まで、発注側に立ったサポートを提供しています。ご不明な点やご相談があれば、お気軽にお問い合わせください。

▼全体ガイドの記事
・基幹システム/ERPリプレイスの完全ガイド

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