業務システムリプレイスの発注は、情報収集（RFI）、提案依頼（RFP）、評価・選定、契約の4つのステップで進みます。
数千万〜数億円規模の投資になるため、発注の進め方を誤ると、見積もり段階から認識のズレが生まれ、「言った・言わない」のトラブルに発展しかねません。
▼全体ガイドの記事
・業務システムリプレイスの完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
業務システムリプレイスの発注プロセス全体像
各ステップで何をすべきかを事前に把握しておくことが、プロジェクト成功の第一歩です。全体像を正確に理解すると、準備不足による見積もり段階での手戻りや、ベンダーとの認識のズレを防げます。
- ステップ1：RFIによる市場情報の収集
- ステップ2：RFPによる提案の依頼
- ステップ3：提案の評価とベンダーの選定
- ステップ4：契約内容の確認と締結
RFIとRFPの役割分担
発注プロセスの起点となるのがRFI（Request for Information：情報提供依頼書）です。RFIは「市場にどのようなソリューションや会社があるのか」を把握するための情報収集ツールで、まだ具体的な要件が固まっていない段階でベンダーに送付します。
複数のベンダーにRFIを送ると、技術動向・価格感・対応可能な機能の概要を把握でき、次のRFP作成に向けた基礎情報を効率的に集められます。RFIを省略してRFPから始めるケースもありますが、市場感がまったくわからない場合はRFIの活用を推奨します。
RFIを経て自社の方向性がある程度固まったら、次にRFP（Request for Proposal：提案依頼書）を作成します。RFPは、ベンダーに「具体的にどのようなシステムを、いくらで、どのような体制で作れるか」を提案してもらうための文書です。RFPの完成度が高いほど、ベンダーからの提案の質も上がり、見積もり金額の妥当性判断や複数社の比較がしやすくなります。
評価・選定から契約締結までの流れ
ベンダーから提案書と見積書が届いたら、評価シートを用いて複数社を定量的に比較します。評価軸としては、提案の要件充足度、プロジェクト体制とPM（プロジェクトマネージャー）の質、コストの妥当性などが代表的です。このほかに、同業種・同規模の支援実績や保守運用体制も挙げられます。
口頭でのプレゼンテーション対応力も、実際のコミュニケーション能力を示す重要な指標なので、評価に含めることが有効です。発注先が決まったら、次は契約書の締結に進みます。
契約形態（請負か準委任か）の選択は後述しますが、この段階で著作権の帰属や仕様変更時の費用負担ルールなどを明確に定めておくことが、後のトラブル防止に直結します。契約書は、ベンダー提示のひな形をそのまま使うのではなく、自社側でもリーガルチェックを行うことを強く推奨します。
RFPの書き方 ─ ベンダーから良い提案を引き出すコツ
RFPは、要件を書き並べるだけでなく、ベンダーとの認識のズレを防ぎ、後から「言った・言わない」のトラブルを避けるための重要な契約前のドキュメントです。RFPの品質が発注の成否を決めるといっても過言ではないため、作り込みへの投資は惜しまないほうがよいです。
RFPに記載すべき項目一覧
ベンダーが提案の範囲と費用を見積もれるよう、RFPには最低限、背景から制約事項まで5つの区分を書き込んでおきます。項目の記述が曖昧なままだと、後で「仕様の範囲外です」と言われる根拠を与えてしまいます。
- ①背景・目的（リプレイスの理由、解決したい課題）と、現行システムの概要（使用中のシステム名・稼働年数・主要機能・連携システム）。
- ②機能要件（新システムに必要な機能の一覧と優先度）と、非機能要件（パフォーマンス・可用性・セキュリティ・拡張性などの品質要件）。
- ③スケジュール（リプレイス完了の目標時期、各フェーズの期間）と、予算の上限または概算規模。
- ④評価基準（提案をどの軸で評価するか）。
- ⑤提案にあたっての制約事項（既存インフラとの互換性、使用禁止技術など）を明記します。
特に重要なのが「非機能要件」と「評価基準」です。非機能要件は「同時接続ユーザー数は最大500名」「夜間バッチ処理は3時間以内に完了」といった具体的な数値で記述することが求められます。評価基準を明示すると、ベンダー側も何に注力した提案をすべきかが明確になり、提案の質が上がります。
曖昧な表現を避けて具体化するテクニック
RFPでよく見られる失敗は、「現行と同等の機能」「使いやすい画面」といった曖昧な表現を使うことです。こうした表現は、後で「仕様の範囲外です」と言われる根拠を与えてしまいます。特に「現行と同等」は、現行システムの仕様書が存在しない場合にベンダーごとの解釈が分かれ、後で大規模な追加開発費用が発生する温床になります。
具体化のコツは、「誰が・何を・どのような条件で・どのくらいの時間で行う」という観点で業務フローを記述することです。たとえば「月次の売上集計レポートを、経理担当者が基幹システムのデータを参照しながら、30分以内に出力できること」のように書くと、ベンダーが開発スコープを正確に把握できます。
RFP提出後に要件の追加が発生するケースも多いため、「本RFP記載外の要件については、追加見積もりを別途協議する」という一文を入れておくと、費用増加のルールを事前に合意できます。
RFP提出後のオリエンテーションと質疑対応
RFPを提出した後は、各ベンダーに対して内容説明の場を設けるオリエンテーション（説明会）を実施するのが一般的です。この場でRFPの背景・意図を口頭で補うことで、ベンダーの理解度が上がり、提案の精度も高まります。
質疑応答は「QA期間」を設け、すべてのベンダーに同一の質問と回答を共有します。こうすると、公平性を保ちながら情報格差を防げます。
見積もりの精査と相見積もりの比較方法
ベンダーから提出された見積もりの金額が妥当かを判断することは、発注側にとって最も難しい作業の一つです。見積もりを正しく精査するには、金額の合計だけでなく、内訳の構成と前提条件を詳細に確認することが欠かせません。さらに、相見積もりを取得したとしても、前提条件が異なれば単純な金額比較は意味をなしません。
見積もりの妥当性を判断する5つのチェックポイント
見積もりの金額が妥当かは、前提条件から見積もりの精度まで5つの観点で確かめます。
- ①前提条件の確認：RFPの要件のうち、どこまでをスコープとして計上しているかが明示されているか。
- ②工程別の費用内訳：要件定義・設計・開発・テスト・移行・PMOなど、工程別に費用が明示されているか。
- ③人月単価の妥当性：エンジニアの人月単価が、相場と比べて妥当か。
- ④保守・運用費用の有無：初期開発費用だけでなく、稼働後の保守・運用費用（月次）が見積もりに含まれているかどうか。含まれていなければ、別途見積もりを取得します。
- ⑤見積もりの種類（超概算か・概算か・確定か）：提出された見積もりがどの段階のものかを必ず確かめる。
スコープ外の項目が多いと、実質的な総額は見積もりより大きくなります。業界標準としては、開発・実装が50〜60%、要件定義が10〜15%、設計が10〜25%、テストが5〜10%の配分が目安です。
エンジニアの人月単価は、新人クラスで〜80万円、一般クラスで80〜140万円、上級クラスで140〜250万円が相場です。極端に安い場合は、体制の質に疑問を持つべきです。
見積もりは要件定義の進捗に応じて「超概算（精度±50%）」→「概算（±30%）」→「確定（±10%）」と精度が高まる構造的なものです。
金額差が大きい場合の見極め方
複数社から見積もりを取得すると、金額に大きな差が出ることがあります。2倍以上の差が出た場合は、安い方に決める前に、その差の原因を追究することが大切です。差の主な原因は、「スコープの解釈の差」「体制の規模・質の差」「リスク見積もりの差」の3つです。
スコープの解釈の差は、RFPの要件の読み取り方がベンダーによって異なることで生じます。たとえば、安い方のベンダーが「RFPの要件だけを実装すれば良い」と解釈し、高い方が「実際の業務を動かすために必要な追加機能も含めた」と見積もっている場合は、本来は高い方の見積もりが正確です。
相見積もりを比べるときは、必ず「同じ前提条件・同じスコープで計上しているか」を揃えることが大前提です。見積もりの変動は「見積もり手法に起因する構造的なもの」であり、精度が確定するのは要件定義が完了した後だと、発注側が正確に認識しておく必要があります。
契約の落とし穴と法務的注意点
業務システムリプレイスにおける発注の失敗は、多くの場合「契約段階での詰めの甘さ」に起因します。競合記事の大半は契約の法務的な側面を表面的にしか解説していませんが、この領域こそ発注後の大きなトラブルを防ぐための核心です。請負と準委任の違い、下請法の適用、SLAの設計は、発注担当者が必ず押さえておくべき知識です。
請負契約 vs 準委任契約 ─ 業務システムリプレイスでの選び分け
システム開発の契約形態には「請負契約」と「準委任契約」の2種類があり、リプレイスプロジェクトではフェーズごとに使い分けるのが実務上のベストプラクティスです。請負契約は「成果物の完成」を約束する契約で、ベンダーは仕様書に定めたシステムを完成させる義務を負います。完成物に契約不適合があれば、修補や損害賠償を請求できます。
一方、準委任契約は「作業の遂行」に対して報酬が発生する契約で、完成の保証はありません。ベンダーには「善良な管理者の注意義務（善管注意義務）」をもって作業を行うことが求められますが、結果の保証はしません。そのため、発注側は「時間（工数）を買う」意識を持ち、進捗管理を自ら行う必要があります。
業務システムリプレイス特有のリスクは、要件定義の段階で何を作るかが不明確で、請負では正確な価格設定ができない点です。このため、要件定義は準委任、設計・開発は要件確定後に請負とするハイブリッドが主流です。ただし、仕様変更が頻発しそうな大規模リプレイスや、アジャイル開発の場合は、全フェーズを準委任契約とすることも合理的です。
契約不適合責任の実務的な押さえ方
2020年の民法改正により、「瑕疵担保責任」は「契約不適合責任」へと名称・制度が変わりました。請負契約では、引き渡されたシステムが契約の内容（仕様書・RFP等）に適合しない場合、発注側は追完（修補）や代金減額を請求できます。さらに、損害賠償請求や契約解除も可能です。
実務上の重要なポイントは、契約不適合責任の範囲が「契約書と仕様書に明記されたものに限定される」ということです。そのため、口頭で合意した内容や、RFPに曖昧に記載した内容については、責任の追及が困難になります。発注側が責任を問うためには、要件を仕様書として文書化し、契約書に添付することが絶対条件です。
また、責任の追及期限（不適合を知った時から1年以内の通知が必要）にも注意が必要です。稼働後の検収期間を適切に設定しておくことが大切です。
下請法の適用条件と注意すべき支払いルール
プログラム開発などの「情報成果物作成委託」は下請法（下請代金支払遅延等防止法）の対象になり、見落としやすい点です。下請法が適用される条件は「資本金の規模の差」によって決まります。親事業者の資本金が1000万円超3億円以下で、委託先（下請事業者）の資本金が1000万円以下の場合、または親事業者の資本金が3億円超で委託先の資本金が3億円以下の場合に下請法が適用されます。
下請法が適用される場合の最重要ルールが「60日以内の支払い」です。発注者は、下請事業者が成果物を納品した日から起算して60日以内に代金を支払わなければなりません。なお、このルールは強行法規であり、当事者間で「90日後に支払う」と合意しても法的に無効です。
さらに、60日を超えると年率14.6%の遅延利息の支払い義務が生じます。規模の小さいシステム会社に委託する際は、両社の資本金規模を確認し、下請法の適用有無を事前に判断しておく必要があります。また、発注書面の交付義務や書類の保存義務なども下請法で定められ、コンプライアンス上の注意が必要です。
SLA（サービスレベル合意）の設計とペナルティ条項
SLA（Service Level Agreement）とは、システムの稼働率・応答時間・障害対応時間・バックアップ頻度などについてベンダーと合意する文書です。特に業務システムは会社の基幹業務を支えるため、SLAの設計は稼働後のトラブル対応で重要な役割を果たします。
SLAの具体的な記載例としては、「月次稼働率99.5%以上」「重大障害発生から4時間以内の復旧を目指す」「問い合わせ対応は翌営業日中に初回回答」などがあります。ペナルティ条項では、SLA未達時に月額保守料の一定割合（10〜20%程度）を減額する形式が一般的です。
ただし、ペナルティ条項を設けると「ベンダーが保守的な提案しかしなくなる」という副作用もあるため、過度に厳しい条件ではなく、バランスの取れた設定が重要です。一方で、ペナルティより「改善計画の提出と実行」を義務付けるほうが、継続的な品質向上を促すうえで実務的な効果が高い場合があります。
発注後のプロジェクト管理 ─ 発注側が持つべき実践ノウハウ
発注が完了すれば発注側の仕事は終わる、という考えは危険な誤解です。業務システムリプレイスでベンダーに丸投げするプロジェクトは、高確率で失敗します。ガートナーの調査によると、ERPを含むシステム開発プロジェクトの75%が、プロジェクト進行中に何らかの失敗を経験しているというデータがあります。
発注側は、発注後も「オーナーシップを持った発注者」として積極的に関与することが、成功の条件です。
ILUO評価によるフェーズ完了判定の導入
フェーズの完了を判断する基準として、スケジュールや成果物の提出だけでなく「人間の習熟度」を使うというアプローチがあります。これがILUO（イルオ）フレームワークです。ILUOは製造業のトレーニング評価手法で、I（できない）→L（補助があればできる）→U（一人でできる）→O（他者を指導できる）の4段階で習熟度を評価するものです。
業務システムリプレイスのフェーズ管理に応用すると、たとえば「主要業務担当者の全員がILUOのU（一人でできる）以上に達すること」を、ユーザー受け入れテスト（UAT）の完了判定の基準にできます。一方、「テストの消化率100%」という成果物ベースの判定だけでは、実際には現場が使いこなせないまま本番稼働を迎えるリスクがあります。
人の習熟度を基準に加えると、システムの定着化と稼働後トラブルの防止に直結するフェーズ管理が実現します。
予算超過時の経営陣への説明と追加予算獲得の進め方
業務システムリプレイスでは、プロジェクト進行中に当初予算を超える費用が発生するケースは珍しくありません。ある製造業D社の事例では、パッケージへの70%カスタマイズにより、費用が当初予算の2.5倍に膨張しました。こうした予算超過が起きると、プロジェクト担当者は経営陣に対して追加予算の申請という難題に直面します。
経営陣を説得する説明の型としては、「状況・原因・選択肢・推奨案」の4段構成が有効です。まず、当初予算に対してどの程度超過しているかを数値で示し、次に、要件追加・仕様変更・見積もり精度の問題などの原因を説明します。そして、現時点で取り得る選択肢（追加予算承認・スコープ削減・プロジェクト中断）を、それぞれのメリット・デメリットとともに示します。
最後に、「推奨案とその理由（ROIを含む投資対効果の再計算）」を示すという構成です。この構成により、経営陣は感情的ではなく、事実と論理に基づいた意思決定ができるようになります。特にROIの再計算では、製造業A社の事例（月次決算が3週間から1週間に短縮）のような具体的な業務改善効果を数値化すると、追加投資の妥当性を示せます。
損切り（サンクコスト放棄）の判断基準
追加予算を投じても、プロジェクトの成功が見通せない場合は、「損切り（プロジェクト中断）」を真剣に検討する必要があります。「すでに投じた費用がもったいない」というサンクコスト（埋没費用）への執着は、合理的な意思決定の最大の障害です。経済学でいうサンクコストの誤謬であり、意思決定者は「これまでに使ったお金」ではなく、「これからかかるお金と得られる効果」だけを比べることが求められます。
損切りを検討する目安は、次のいずれかに当たるときです。
①プロジェクト完了までの追加費用が、完成後に得られる業務改善効果のROIを下回る場合。
②ベンダーとの関係が破綻しており、技術的な問題解決の見通しが立たない場合。
③プロジェクトの遅延が業務運用に重大な影響を与えており、リスク許容限度を超えた場合に当たります。
③の例として、食品メーカーA社は、切り戻し基準を未合意のままカットオーバーした結果、受発注・在庫不整合が連鎖して出荷・製造が長期停止する事態に陥りました。このような状況では、継続よりも一時撤退・再設計の判断が合理的です。損切りの判断は、「失敗」ではなく、より大きな損失を防ぐための経営判断として位置づけることが大切です。
ベンダーコントロールの実践 ─ 発注後の手綱の握り方
発注後のベンダーコントロールは、業務システムリプレイスの成否を左右する重要な要素であり、多くの競合記事では十分に解説されていない領域です。ベンダーとの関係で発注側が受け身になると、スケジュールや品質の管理権をベンダーに握られ、後手に回ることになります。
定例会議の仕切り方と遅延の早期発見
プロジェクトの定例会議は、「ベンダーが報告する場」ではなく「発注側が状況をコントロールする場」として設計することが大切です。定例会議のアジェンダに必ず含めるべき項目は、次のとおりです。
前回からの進捗（計画比・実績比）。
現在判明しているリスクと対応状況。
次フェーズへの影響が懸念される課題の確認。
次回までのアクションを決めます（誰が・何を・いつまでに）。
遅延の早期発見には、EVM（アーンド・バリュー・マネジメント）の考え方が有効です。計画上の進捗率と実際の完了タスクを比べ、0.1の差異でも発生した段階で、ベンダーに要因を確認する習慣を持ちます。「少し遅れているが後で取り返せる」という報告を鵜呑みにせず、回復計画（誰が・何を・いつまでに追加対応するか）を文書で提出させることが、遅延拡大の防止になります。
「仕様外です」と言われた際の交渉ノウハウ
「その機能は仕様書に記載がないため追加費用が発生します」というベンダーからの申告は、ほぼすべてのシステムリプレイスプロジェクトで起こります。この「追加費用請求」への対応を誤ると、当初予算から大幅に膨れ上がる原因になります。まず確認すべきは、「本当に仕様書に記載がないのか、それとも記載があるが解釈が異なるのか」です。
仕様書の当該箇所を引用し、「この記述でカバーされないのか」と具体的に問いかけることが、交渉の出発点になります。次に、その機能が仕様書になくても、RFPの業務要件を実現するために必然的に必要な機能ではないかを検討します。RFPの要件と開発スコープの関係から、「業務要件実現のために必要不可欠な機能である」と主張できれば、追加費用を認めない根拠になります。
すべての議論の基盤になるのは文書記録です。そのため、認識が異なる事項は、議事録への記録と双方の署名・確認を徹底することが、最終的な交渉力の源泉になります。
まとめ
業務システムリプレイスの発注は、RFI・RFPの作成から始まり、見積もりの精査、契約形態の選択、発注後のプロジェクト管理まで、発注側が主体的に関わるべき多くのステップで構成されます。RFPには、非機能要件や評価基準などを具体的な数値で書くことが、良質な提案を引き出す鍵です。
見積もりは「超概算・概算・確定」という精度の違いがあり、要件定義の完了前の見積もりは構造的に変動する点を、発注側が正確に理解しておく必要があります。契約では、要件定義フェーズを準委任契約、設計・開発フェーズを請負契約とするハイブリッドアプローチが業務システムリプレイスに適しています。
規模の小さい委託先との契約では、下請法の適用有無を確認し、60日以内の支払いルールを守ることが法令遵守上の義務です。SLAは稼働率・障害対応時間などを数値で定め、ペナルティより改善義務を中心に据えた設計が実務的に有効です。
発注後は、ILUOフレームワークを活用したフェーズ完了判定、定例会議での遅延の早期発見、追加費用請求への文書ベースの対応などを、発注側がオーナーシップを持って進めることが成功の条件です。予算超過時は、「状況・原因・選択肢・推奨案」の4段構成で経営陣に説明します。必要であれば、サンクコストにとらわれず損切りの判断を下す勇気も求められます。
▼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を創業。