業務システムのリプレイスを検討しているものの、「どこから手をつければいいのかわからない」「ベンダーに出す書類の書き方がわからない」「契約でトラブルにならないか不安」という声は、IT担当者やプロジェクトマネージャーから非常に多く寄せられます。業務システムのリプレイスは数千万〜数億円規模の投資を伴うプロジェクトであり、発注プロセスを間違えると、見積もり段階から認識のズレが生まれ、最終的には「言った・言わない」のトラブルに発展するリスクがあります。

この記事では、業務システムリプレイスの発注方法について、RFP（提案依頼書）の書き方から見積もりの精査方法、請負・準委任の契約選択、下請法の注意点、そして発注後のプロジェクト管理まで、実務で使える具体的な知識を体系的に解説します。発注側がベンダーに主導権を握られず、自社が主体的にプロジェクトをコントロールするための「武器」となる情報を提供します。

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

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

業務システムのリプレイスにおける発注プロセスは、大きく「情報収集（RFI）→ 提案依頼（RFP）→ 評価・選定 → 契約」という4つのステップで構成されます。各ステップで何をすべきかを事前に把握しておくことが、プロジェクト成功の第一歩です。この全体像を正確に理解することで、準備不足による見積もり段階での手戻りや、ベンダーとの認識のズレを防ぐことができます。

発注プロセスの起点となるのがRFI（Request for Information：情報提供依頼書）です。RFIは「市場にどのようなソリューションや会社があるのか」を把握するための情報収集ツールであり、まだ具体的な要件が固まっていない段階でベンダーに送付します。複数のベンダーにRFIを送ることで、技術動向・価格感・対応可能な機能の概要を把握でき、次のRFP作成に向けた基礎情報を効率的に収集できます。

RFIを経て自社の方向性がある程度固まったら、次にRFP（Request for Proposal：提案依頼書）を作成します。RFPはベンダーに対して「具体的にどのようなシステムを、いくらで、どのような体制で作れるか」を提案してもらうための文書です。RFPの完成度が高いほど、ベンダーからの提案の質も上がり、見積もり金額の妥当性判断や複数社比較が容易になります。RFIを省略してRFPから始めるケースもありますが、市場感がまったくわからない場合はRFIを活用することを推奨します。

ベンダーから提案書と見積書が届いたら、評価シートを用いて複数社を定量的に比較します。評価軸としては、「提案の要件充足度」「プロジェクト体制とPM（プロジェクトマネージャー）の質」「同業種・同規模の支援実績」「コストの妥当性」「保守運用体制」などが代表的です。口頭でのプレゼンテーション対応力も実際のコミュニケーション能力を示す重要な指標であり、評価に含めることが有効です。

発注先が決まったら、契約書の締結に進みます。契約形態（請負か準委任か）の選択は後述しますが、この段階で著作権の帰属・SLA（サービスレベル合意）・仕様変更時の費用負担ルール・契約不適合責任の範囲などを明確に定めておくことが、後のトラブル防止に直結します。契約書はベンダー提示のひな形をそのまま使用するのではなく、自社側でもリーガルチェックを行うことを強く推奨します。

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

RFPはただ「要件を書いた文書」ではありません。ベンダーとの認識のズレを防ぎ、後から「言った・言わない」のトラブルを回避するための重要な契約前ドキュメントです。RFPの品質が発注の成否を決めると言っても過言ではなく、作り込みへの投資を惜しむべきではありません。

業務システムリプレイスのRFPに最低限含めるべき項目は以下のとおりです。

①プロジェクトの背景・目的（なぜリプレイスするのか、解決したい課題は何か）
②現行システムの概要（使用中のシステム名・稼働年数・主要機能・連携システム）
③機能要件（新システムに必要な機能の一覧と優先度）
④非機能要件（パフォーマンス・可用性・セキュリティ・拡張性などの品質要件）
⑤スケジュール（リプレイス完了の目標時期、各フェーズの期間）
⑥予算の上限または概算規模
⑦評価基準（提案をどの軸で評価するか）
⑧提案にあたっての制約事項（既存インフラとの互換性、使用禁止技術など）

特に重要なのが「非機能要件」と「評価基準」です。非機能要件は「同時接続ユーザー数は最大500名」「夜間バッチ処理は3時間以内に完了」といった具体的な数値で記述することが求められます。曖昧な表現は後で「仕様の範囲外です」と言われる根拠を与えてしまいます。評価基準を明示することで、ベンダー側も何に注力した提案をすべきかが明確になり、提案の質が格段に向上します。

RFPでよく見られる失敗パターンが、「現行と同等の機能」「使いやすい画面」といった曖昧な表現です。「現行と同等」という表現は、現行システムの仕様書が存在しない場合、ベンダーによって解釈が異なり、後で大規模な追加開発費用が発生する温床になります。

具体化のコツは「誰が・何を・どのような条件で・どのくらいの時間で行う」という観点で業務フローを記述することです。たとえば「月次の売上集計レポートを、経理担当者が基幹システムのデータを参照しながら、30分以内に出力できること」のように記述すると、ベンダーが開発スコープを正確に把握できます。また、RFP提出後に要件追加が発生するケースも多いため、「本RFP記載外の要件については、追加見積もりを別途協議する」という一文を入れておくことで、費用増加のルールを事前に合意できます。

RFPを提出した後、各ベンダーに対して内容説明の場を設けるオリエンテーション（説明会）を実施することが一般的です。この場でRFPの背景・意図を口頭で補足することで、ベンダーの理解度が上がり、提案の精度が向上します。質疑応答は「QA期間」として期間を設け、すべてのベンダーに同一の質問と回答を共有することで、公平性を保ちながら情報格差を防ぐことができます。

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

ベンダーから提出された見積もりの金額が妥当かどうかを判断することは、発注側にとって最も難しいタスクの一つです。見積もりを正しく精査するためには、金額の合計だけを見るのではなく、内訳の構成と前提条件を詳細に確認することが不可欠です。相見積もりを取得したとしても、前提条件が異なれば単純な金額比較は意味をなしません。

見積もりを精査する際に確認すべき5つのポイントがあります。

①前提条件の確認：見積もりはRFPに記載した要件のうち、どこまでをスコープとして計上しているかを明確にする。スコープ外の項目が多ければ、実質的な総額は見積もりより大きくなる。
②工程別の費用内訳：要件定義・設計・開発・テスト・移行・PMOなどの工程別に費用が明示されているかを確認する。業界標準としては、開発・実装が50〜60%、要件定義が10〜15%、設計が10〜25%、テストが5〜10%の配分が目安です。
③人月単価の妥当性：エンジニアの人月単価は、新人クラスで〜80万円、一般クラスで80〜140万円、上級クラスで140〜250万円が相場です。極端に安い場合は体制の質に疑問を持つべきです。
④保守・運用費用の有無：初期開発費用だけでなく、稼働後の保守・運用費用（月次）が見積もりに含まれているかを確認する。含まれていない場合は別途見積もりを取得する。
⑤見積もりの種類（超概算か・概算か・確定か）：見積もりは要件定義の進捗に応じて「超概算（精度±50%）」→「概算（±30%）」→「確定（±10%）」と精度が高まる構造的なものです。提出された見積もりがどの段階のものかを必ず確認してください。

複数社から見積もりを取得した場合、金額に大きな差が生じることがあります。2倍以上の差が出た場合は単純に安い方を選ぶのではなく、その差の原因を追究することが重要です。差の主な原因は「スコープの解釈の差」「体制の規模・質の差」「リスク見積もりの差」の3つです。

スコープの解釈の差は、RFPの要件の読み取り方がベンダーによって異なることで発生します。安い方のベンダーが「RFPの要件だけを実装すれば良い」と解釈し、高い方が「実際の業務を動かすために必要な追加機能も含めた」という場合、本来は高い方の見積もりが正確です。相見積もりの比較では、必ず「同じ前提条件・同じスコープで計上しているか」を揃えることが比較の大前提です。また、見積もりの変動は「見積もり手法に起因する構造的なもの」であることを理解し、見積もりの精度が確定するのは要件定義が完了した後であることを発注側が正確に認識しておく必要があります。

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

業務システムリプレイスにおける発注の失敗は、多くの場合「契約段階での詰めの甘さ」に起因します。競合記事の大半は契約の法務的側面を表面的にしか解説していませんが、この領域こそが発注後の大きなトラブルを防ぐための核心です。請負と準委任の違い、下請法の適用、SLAの設計は、発注担当者が必ず押さえておくべき知識です。

システム開発の契約形態には「請負契約」と「準委任契約」の2種類があり、リプレイスプロジェクトではフェーズごとに使い分けることが実務上のベストプラクティスです。

請負契約は「成果物の完成」を約束する契約であり、ベンダーは仕様書に定めたシステムを完成させる義務を負います。完成物に契約不適合があれば、修補や損害賠償を請求できます。一方、準委任契約は「作業の遂行」に対して報酬が発生する契約であり、完成保証はありません。ベンダーは「善良な管理者の注意義務（善管注意義務）」をもって作業を行うことが求められますが、結果の保証はしません。

業務システムリプレイスに特有のリスクとして、「要件定義段階では何を作るかが不明確なため、請負契約では正確な価格設定ができない」という問題があります。このため、要件定義フェーズは準委任契約、設計・開発フェーズは要件が確定した後に請負契約へ切り替えるというハイブリッドアプローチが主流です。ただし、リプレイスの規模が大きく仕様変更が頻発することが見込まれる場合や、アジャイル開発で進める場合は、全フェーズを準委任契約とすることも合理的な選択です。発注側としては、準委任では「時間（工数）を買う」意識を持ち、進捗管理を自ら行う体制が求められます。

2020年の民法改正により、「瑕疵担保責任」は「契約不適合責任」へと名称・制度が変更されました。請負契約における契約不適合責任とは、引き渡されたシステムが契約の内容（仕様書・RFP等）に適合しない場合、発注側は追完（修補）の請求・代金減額請求・損害賠償請求・契約解除を行うことができるというものです。

実務上の重要なポイントは、契約不適合責任の範囲が「契約書と仕様書に明記されたものに限定される」ということです。つまり、口頭で合意した内容や、RFPに曖昧に記載した内容については責任追及が困難になります。発注側が責任を問うためには、要件を仕様書として文書化し、契約書に添付することが絶対条件です。また、責任の追及期限（不適合を知った時から1年以内の通知が必要）にも注意が必要であり、稼働後の検収期間を適切に設定することが重要です。

プログラム開発などの「情報成果物作成委託」は下請法（下請代金支払遅延等防止法）の適用対象になります。これは多くの発注担当者が見落としがちなポイントです。下請法が適用される条件は「資本金の規模の差」によって決まります。親事業者の資本金が1000万円超3億円以下で、委託先（下請事業者）の資本金が1000万円以下の場合、または親事業者の資本金が3億円超で委託先の資本金が3億円以下の場合に下請法が適用されます。

下請法が適用される場合の最重要ルールが「60日以内の支払い」です。発注者は、下請事業者が成果物を納品した日から起算して60日以内に代金を支払わなければなりません。このルールは強行法規であり、当事者間で「90日後に支払う」と合意しても法的に無効です。60日を超えた場合は年率14.6%の遅延利息の支払い義務が生じます。規模の小さいシステム会社に委託する際は、自社の資本金規模と委託先の資本金規模を確認し、下請法の適用有無を事前に判断しておく必要があります。また、発注書面の交付義務・書類の保存義務なども下請法には定められており、コンプライアンス上の注意が必要です。

SLA（Service Level Agreement）とは、システムの稼働率・応答時間・障害対応時間・バックアップ頻度などについてベンダーと合意する文書です。特に業務システムは会社の基幹業務を支えるため、SLAの設計は稼働後のトラブル対応において非常に重要な役割を果たします。

具体的なSLAの記載例としては、「月次稼働率99.5%以上」「重大障害発生から4時間以内の復旧を目指す」「問い合わせ対応は翌営業日中に初回回答」などがあります。ペナルティ条項については、SLA未達時に月額保守料の一定割合（10〜20%程度）を減額するという形式が一般的です。ただし、ペナルティ条項を設けることで「ベンダーが保守的な提案しかしなくなる」という副作用もあるため、過度に厳しい条件ではなくバランスの取れた設定が重要です。ペナルティより「改善計画の提出と実行」を義務付けることで、継続的な品質向上を促す方が実務的な効果が高い場合があります。

発注後のプロジェクト管理 ─ 発注側が持つべき実践ノウハウ

発注が完了すれば発注側の仕事は終わり、という考えは危険な誤解です。業務システムリプレイスにおいてベンダーに丸投げするプロジェクトは高確率で失敗します。ガートナーの調査によると、ERPを含むシステム開発プロジェクトの75%がプロジェクト進行中に何らかの失敗を経験しているというデータがあります。発注後も「オーナーシップを持った発注者」として積極的に関与することが成功の条件です。

フェーズの完了を判断する基準として、スケジュールや成果物の提出だけでなく「人間の習熟度」を基準に使うというアプローチがあります。それがILUO（イルオ）フレームワークです。ILUOとは製造業のトレーニング評価手法で、I（できない）→L（補助があればできる）→U（一人でできる）→O（他者を指導できる）の4段階で習熟度を評価するものです。

業務システムリプレイスのフェーズ管理にこれを応用することで、たとえば「ユーザー受け入れテスト（UAT）の完了判定」として「主要業務担当者の全員がILUOのU（一人でできる）以上に達すること」という基準を設けることができます。単に「テストの消化率100%」という成果物ベースの判定だけでは、実際には現場が使いこなせないまま本番稼働を迎えるリスクがあります。人の習熟度を基準に加えることで、システムの定着化と稼働後トラブルの防止に直結するフェーズ管理が実現します。

業務システムリプレイスでは、プロジェクト進行中に当初予算を超える費用が発生するケースは珍しくありません。ある製造業D社の事例では、パッケージへの70%カスタマイズにより費用が当初予算の2.5倍に膨張しました。こうした予算超過が発生した場合、プロジェクト担当者は経営陣に対して追加予算の申請という難題に直面します。

経営陣を説得するための説明の型として有効なのが「状況・原因・選択肢・推奨案」の4段構成です。まず「現在どのような状況か（当初予算に対してどの程度超過しているか）」を数値で示し、次に「なぜ超過しているのか（要件追加・仕様変更・見積もり精度の問題等）」を原因別に説明します。そして「現時点で取り得る選択肢（追加予算承認・スコープ削減・プロジェクト中断）」をそれぞれのメリット・デメリットとともに提示し、最後に「推奨案とその理由（ROIを含む投資対効果の再計算）」を示すという構成です。この構成により、経営陣は感情的ではなく事実と論理に基づいた意思決定ができるようになります。特にROIの再計算では、製造業A社の事例（月次決算が3週間から1週間に短縮）のような具体的な業務改善効果を数値化することで、追加投資の妥当性を示すことができます。

追加予算を投じてもプロジェクトの成功が見通せない場合、「損切り（プロジェクト中断）」という選択肢を真剣に検討する必要があります。「すでに投じた費用がもったいない」というサンクコスト（埋没費用）への執着は、合理的な意思決定の最大の障害です。経済学でいうサンクコストの誤謬であり、意思決定者は「これまでに使ったお金」ではなく「これからかかるお金と得られる効果」だけを比較することが求められます。

損切りを検討すべき判断基準としては、以下のいずれかに該当する場合が目安となります。①プロジェクト完了まで追加で必要な費用が、完成後に得られる業務改善効果のROIを下回る場合。②ベンダーとの関係が破綻しており、技術的な問題解決の見通しが立たない場合。③プロジェクトの遅延が業務運用に重大な影響を与えており、リスク許容限度を超えた場合。③の例として、食品メーカーA社のケースがあります。切り戻し基準を未合意のままカットオーバーした結果、受発注・在庫不整合が連鎖して出荷・製造が長期停止するという事態に陥りました。このような状況では、プロジェクトの継続より一時撤退・再設計の判断が合理的です。損切りの判断は「失敗」ではなく、より大きな損失を防ぐための経営判断として位置づけることが重要です。

ベンダーコントロールの実践 ─ 発注後の手綱の握り方

発注後のベンダーコントロールは、業務システムリプレイスの成否を左右する重要な要素であり、多くの競合記事では十分に解説されていない領域です。ベンダーとの関係において発注側が受け身になると、スケジュールや品質の管理権をベンダーに握られ、後手に回ることになります。

プロジェクトの定例会議は「ベンダーが報告する場」ではなく、「発注側が状況をコントロールする場」として設計することが重要です。定例会議のアジェンダとして必ず含めるべき項目は、「前回からの進捗（計画比・実績比）」「現在判明しているリスクと対応状況」「次フェーズへの影響が懸念される課題の確認」「次回までのアクション（誰が・何を・いつまでに）」の4点です。

遅延の早期発見には、EVM（アーンド・バリュー・マネジメント）の考え方を取り入れることが有効です。計画上の進捗率と実際の完了タスクを比較し、0.1の差異でも発生した段階でベンダーに要因確認を行う習慣を持つことが重要です。「少し遅れているが後で取り返せる」という報告を鵜呑みにするのではなく、具体的な回復計画（誰が・何を・いつまでに追加対応するか）を文書で提出させることが遅延拡大の防止になります。

プロジェクト中に「その機能は仕様書に記載がないため追加費用が発生します」というベンダーからの申告は、ほぼすべてのシステムリプレイスプロジェクトで発生します。この「追加費用請求」への対応を誤ると、当初予算から大幅に膨れ上がる原因になります。

まず確認すべきは「本当に仕様書に記載がないのか、それとも記載があるが解釈が異なるのか」です。仕様書の当該箇所を引用して「この記述でカバーされないのか」という具体的な問いかけをすることが、交渉の出発点になります。次に「その機能が仕様書に記載されていない場合でも、RFPで提示した業務要件を実現するために必然的に必要な機能ではないか」を検討します。RFPの要件と開発スコープの関係性から、「業務要件実現のために必要不可欠な機能である」と主張できれば、追加費用を認めない根拠になります。すべての議論の基盤となるのは文書記録であるため、認識が異なる事項については議事録への記録と双方の署名・確認を徹底することが、最終的な交渉力の源泉です。

まとめ

業務システムリプレイスの発注は、RFI・RFPの作成から始まり、見積もりの精査、契約形態の選択、発注後のプロジェクト管理まで、発注側が主体的に関与すべき多くのステップで構成されます。この記事で解説したポイントを以下に整理します。

発注プロセスでは、RFPに「背景・目的・機能要件・非機能要件・スケジュール・予算・評価基準」を具体的な数値で記述することが、良質な提案を引き出す鍵です。見積もりは「超概算・概算・確定」という精度の違いがあり、要件定義完了前の見積もりは構造的に変動する点を発注側が正確に理解しておく必要があります。

契約においては、要件定義フェーズは準委任契約、設計・開発フェーズは請負契約というハイブリッドアプローチが業務システムリプレイスに適しています。規模の小さい委託先との契約では下請法の適用有無を確認し、60日以内の支払いルールを守ることが法令遵守上の義務です。SLAは稼働率・障害対応時間などを数値で定め、ペナルティより改善義務を軸にした設計が実務的に有効です。

発注後はILUOフレームワークを活用したフェーズ完了判定や、定例会議での遅延早期発見、追加費用請求への文書ベースの対応など、発注側がオーナーシップを持ってプロジェクトをコントロールする姿勢が成功の条件です。予算超過時は「状況・原因・選択肢・推奨案」の4段構成で経営陣に説明し、必要であればサンクコストにとらわれず損切りの判断を下す勇気も求められます。

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

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