システムリプレイスの発注は、RFI（情報提供依頼）→ RFP（提案依頼）→ 評価・選定 → 契約締結の4段階で進みます。
数千万〜数億円規模のプロジェクトでも、発注側の準備不足による失敗は後を絶ちません。失敗を防ぐには、発注先の評価から契約、予算管理、完了判定までの各場面で、発注側が何を確認し、どこで判断するかを先に決めておく必要があります。
- RFI・RFPと発注先の評価
- 契約形態・SLA・下請法の確認
- 予算超過と損切り基準の管理
- ILUO評価を含む完了判定
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
システムリプレイスの発注プロセス全体像
発注は、RFI（情報提供依頼）→RFP（提案依頼）→評価・選定→契約締結の4段階で進み、各段階で発注側が果たす役割と必要な準備は、それぞれ明確に異なります。そのため、まず全体の流れを把握してから各段階に臨むことが大切です。この流れを省いたり順番を入れ替えたりすると、後工程で取り返しのつかない認識の齟齬が生じます。
RFI → RFP → 評価・選定 → 契約の4ステップ
最初のRFI（Request for Information）は、市場全体の情報を集めるための「問い合わせ」で、特定のベンダーへの正式な依頼にはあたりません。発注側は、複数のベンダーに自社の課題や規模感を示し、どのようなソリューションが存在するかを確認します。この段階では詳細な要件は不要で、むしろ自社が知らない選択肢を掘り起こすことに価値があります。
RFIを通じてベンダー候補が絞り込まれたら、次はRFP（Request for Proposal）を作成し、正式な提案を依頼します。RFPはベンダーが提案書を作るための設計図にあたり、その内容の質が提案の質を直接左右します。特に、曖昧なRFPには曖昧な提案しか返ってこないという原則を、忘れてはいけません。
提案書を受け取ったら、評価基準に従って各社を比べ、発注先を決定します。評価は、機能要件への適合度、費用、スケジュールに加えて、プロジェクト体制と実績の5軸で数値化し、感覚的な判断を避けます。選定後は、まずNDA（秘密保持契約）を結び、詳細な情報を交換できる環境を整えてから本契約の協議に入るのが一般的な手順です。
RFP提出前に社内で整備すべき3つのドキュメント
RFP作成に入る前に、社内で3種類のドキュメントを用意しておくと、作業が格段にスムーズになります。1つ目は「現行システム概要書」で、現在稼働しているシステムの構成図と利用ハードウェアのスペックを、連携している外部サービスやライセンス情報とあわせて一枚にまとめます。
2つ目は「業務フロー現状図（As-Is）」と「業務フロー理想図（To-Be）」です。現行の業務フローをそのまま引き継ぐ「現行踏襲」を前提にすると、不要な業務工程まで新システムに移してしまい、典型的な失敗パターンになります。
そのため、To-Beを先に描いておくと、リプレイスの機会に業務改善も同時に進められます。3つ目は「優先度付き要件リスト」です。機能要件を「必須（Must）」「重要（Should）」「あれば良い（Nice to have）」の3段階に分けておきます。この分類があると、ベンダーとの交渉で、削減できる機能と削減できない機能の議論が明確になります。
RFPの書き方――ベンダーから良い提案を引き出すコツ
RFPは発注側とベンダーの「共通言語」です。同じ要件を示したつもりでも、表現が曖昧だとベンダーごとに解釈が分かれ、提案書を比べられなくなります。「質の高いRFPには質の高い提案が集まる」というシンプルな原則を頭に置き、具体的な記述を心がけます。
RFPに記載すべき必須項目一覧
RFPに盛り込むべき項目は大きく8つのカテゴリに分けられます。①では、なぜ今リプレイスが必要か、ビジネス上の課題は何かを示し、②では、現行システムの概要として、システム構成とユーザー数、データ量、連携先を示します。③では、業務別に必要な機能を優先度付きで記載し、④では、非機能要件として可用性と性能、セキュリティ、拡張性を示します。
⑤では、移行対象データの種類、件数、品質基準を示し、⑥では、本番稼働の予定日と制約条件を示します。⑦では、上限金額か、「提案を通じて適正価格を判断したい」という方針を示し、⑧では、提案を評価する観点を示します。とくに非機能要件は、競合記事でも指摘されているように「後出しで追加されることが多い項目」です。
本番稼働後に「実は同時接続ユーザー数が500人いる」「バッチ処理は毎日深夜2時に500万件のデータを処理する必要がある」といった要件が判明すると、大規模な追加開発が発生します。建築業B社の事例では、この性能見積もりの甘さが原因となり、工期が延び、費用も当初予算を大幅に超えました。そのため、RFPの段階でピーク時の処理要件まで明記することが、後のトラブル防止に直結します。
曖昧な表現を避ける「具体化テクニック」
RFPでよくある失敗は、「〜の機能が必要です」「〜を考慮してください」といった抽象的な表現を多用することです。ベンダーはこの表現を最小限のコストで解釈しますが、発注側はより充実した対応を想定していた、というミスマッチが頻発します。具体化の基本原則は、「5W1H＋数値」で記述することです。
例えば「検索機能が必要」を、「商品マスター（約50万件）をSKU・商品名・バーコードの3軸で検索し、3秒以内に結果を返すこと。同時接続ユーザー数は最大100名を想定」と書き直すと、正確な見積もりが可能になります。「セキュリティに配慮すること」も、「ISMS認証取得済みの環境での開発、通信はTLS1.2以上を使用、個人情報は暗号化して保存すること」と明示すると、対応の範囲が確定します。
また、RFPには「提案を評価する基準と配点」を明示することを、強くおすすめします。「機能適合率30点・費用25点・スケジュール実現性20点・実績15点・サポート体制10点」のように点数化すると、ベンダーは重視する観点を把握でき、発注側も客観的な比較が可能になります。
RFP提示後の要件追加を防ぐ「スコープロック」の考え方
RFPを提示してベンダーが提案書を作成している段階で、発注側から「やっぱりこの機能も追加したい」という要望が出ることは珍しくありません。しかし、提案後・契約前の要件追加は、ベンダーの見積もり前提を崩し、「スコープクリープ（要件の際限ない拡大）」の始まりとなります。
対策として効果的なのは、「提案期間中は要件を凍結する」というルールを明文化することです。RFPに「本書を発行した日以降、提案締切日までは要件の追加・変更を行わない」と明記し、変更が生じた場合は全候補ベンダーに同時に通知するプロセスを設けます。
また、契約時には「変更管理プロセス（Change Request Procedure）」を定めておくことが重要です。要件変更は所定のフォームで申請し、双方の合意のうえでスコープと費用を調整します。
見積もりの精査と相見積もりの比較方法
複数のベンダーから提案書と見積もりを受け取ると、発注担当者が最も頭を悩ませるのが「この金額は妥当なのか」という判断です。同じ要件に対してA社が3,000万円、B社が7,000万円という差が生じることも珍しくありません。単純に安い方を選ぶのは危険ですが、高い方が必ずしも良いわけでもありません。
見積もりの妥当性を判断する5つのチェックポイント
見積もりが妥当かどうかは、次の5つの観点で確かめます。
- 工程別費用：要件定義から移行、PM管理までの費用が工程ごとに示されているかを見ます。
- 人月単価と工数：市場単価の目安との照合。
- 前提条件：自社の実態と一致しているかどうか。
- トータルコスト（TCO）：保守費を含めた5年間での比較。
- データ移行費用：別途計上されているかを確認します。
内訳のない一括見積もりは、後工程での追加費用請求の温床になります。前提条件に「弊社既存フレームワークを使用した場合」「要件が現時点の提示内容から変更されない場合」といった条件が明示されているかを確認し、自社の実態と一致しているかを精査します。ずれていると、金額の差を同じ土俵で比べられなくなります。
市場単価の目安は、新人が〜80万円/月、一般が80〜140万円/月、上級が140〜250万円/月です。
初期開発費用だけを比べて選定すると、運用フェーズで高額な保守契約を結ばざるを得ないケースが頻繁に発生します。そのため、運用保守費用が含まれているかも確認します。
一般的な内訳の目安は、要件定義10〜15%、設計10〜25%、開発・実装50〜60%、テスト5〜10%、運用保守15〜20%とされています。この比率から大きく外れる見積もりは、根拠を確認すべきです。
安価な見積もりは、新人を多数アサインして工数を見かけ上増やし、金額を低く抑えている可能性があるため、PMや上級エンジニアの単価と工数も確認します。
商社E社の事例では、20年分の顧客データが3システムに分散し、統合とクレンジングだけで4ヶ月を要したため、この費用の有無は必ず確認します。
金額差が大きい場合の「差額原因」の見極め方
相見積もりで金額差が大きい場合、まず疑うべきは「要件の解釈の差」です。同じRFPを読んでも、ベンダーによって要件の難易度や範囲の見方が異なります。安価な見積もりのベンダーが要件を狭く解釈し、高価な見積もりのベンダーが幅広く解釈している場合、実際の開発で安価なベンダーが後から「この機能は要件外です」と主張するリスクがあります。
差額の原因を解明する有効な手段は、「見積もりヒアリング（提案説明会）」です。各ベンダーに「工数の差が大きい部分はどこか」「前提条件の違いは何か」を直接聞くことで、金額差の根拠が明らかになります。また、見積もり変動は本来「構造的」に起こりうるものです。
要件定義の途中で新たな要件が判明したり、非機能要件が明確になったりすると、前提条件が変わります。そのため、「超概算（±50%）」「概算（±30%）」「確定（±10%以内）」という精度の違いを、発注側が理解しておくことが大切です。最初の見積もりと最終的な費用が異なること自体は自然で、理由を説明できるかどうかが肝心です。
契約の落とし穴と法務的注意点
システムリプレイスの契約は、民法や下請法、情報処理推進機構（IPA）のモデル契約書など、複数の法的枠組みが絡み合う複雑な領域です。
契約書はベンダーが用意するものだと考え、内容を精査せずに署名するのは非常に危険です。発注側が押さえておくべき契約上の要点は、請負と準委任の違い、下請法、SLAの3つです。
請負契約と準委任契約の使い分け
システムリプレイスの契約形態は、大きく「請負契約」と「準委任契約」の2種類に分かれます。請負契約は、ベンダーが「成果物の完成」を約束する契約で、ソフトウェアが完成しなければ報酬は発生しません。一方、準委任契約は、ベンダーが「業務の遂行」を約束する契約で、一定時間・一定工数の業務提供に対して報酬が支払われます。
一般的に推奨される使い分けは、要件定義を準委任契約、設計・開発・テストを請負契約とする組み合わせです。要件定義は「完成品」が定義しにくく、試行錯誤を伴うため、準委任が適しています。これに対して、詳細設計と開発は成果物が明確に定義できるため、請負として完成責任を持たせることが発注側にとって有利です。
2020年の民法改正で「瑕疵担保責任」は「契約不適合責任」に改められ、請負契約の大きなメリットはこの責任が適用されることです。本質は、契約で定めた仕様を満たさない場合に、ベンダーが修補・代替物引渡し・報酬減額・損害賠償に応じる義務を負う点で共通しています。この権利は「知った時から1年以内」に行使する必要があるため、検収時に仕様書との照合を徹底します。
下請法の適用条件と注意すべき支払いルール
下請法（下請代金支払遅延等防止法）は、発注側（親事業者）と受注側（下請事業者）の資本金規模に一定の差がある場合に適用される法律です。システム開発は「情報成果物作成委託」に該当します。発注側の資本金が1,000万円超でベンダーの資本金が1,000万円以下の場合、または発注側が1億円超でベンダーが1億円以下の場合に、下請法が適用されます。
下請法が適用される最も重要な義務は「60日以内の支払い」ルールです。ベンダーから納品物を受け取った日から60日以内に、代金を支払わなければなりません。月末締め翌月末払いなどの一般的な支払いサイクルでは問題ありませんが、四半期後払いや検収確認に時間をかけすぎると違反になります。
また、下請法では発注内容の書面交付義務も定められており、口頭での発注は禁止されています。中規模・大企業がスタートアップや中小のSIerにリプレイスを外注する際は、特に意識が必要です。
SLA（サービスレベル合意）の設計とペナルティ条項の作り方
SLA（Service Level Agreement）は、稼働率や応答時間、障害対応時間などの品質水準をベンダーと数値で合意した文書です。「品質は別途協議する」と曖昧にせず、SLAを契約に組み込むと、サービス品質の「見える化」と「責任の明確化」が実現します。SLAに定める主な項目は4つで、「保証する」と書くことで未達が努力目標に終わらず、SLO（目標値）との混同も避けられます。
①可用性（稼働率）は「システムの月次稼働率99.5%以上を保証する」、②性能は「ピーク時の画面遷移は3秒以内」です。③障害対応は「P1（業務全体停止）は発生から2時間以内に対応開始、8時間以内に復旧」「P2（一部機能停止）は翌営業日中に復旧」です。④定期メンテナンスの事前通知は「計画メンテナンスは2週間前までにメール通知」と定めます。
ペナルティ条項の設計では、「段階的な減額方式」が実務上のスタンダードです。例えば、月次稼働率が99.5%を下回ると月額費用の10%、99.0%を下回ると20%、98.0%を下回ると30%を減額する設計が一般的です。ただし、ペナルティは損害賠償の代替と見なされることもあるため、損害賠償請求権を別途留保するかも明記が必要です。
発注後のプロジェクト管理――発注側の主体的な関与
発注が完了したら「あとはベンダーに任せればいい」と考えるのは非常に危険です。プロジェクトが失敗する最大の原因の一つは、「発注側の関与不足」です。ガートナーの調査では、プロジェクトの75%が進行中に何らかの失敗を経験するとされていますが、その多くはベンダー主導・発注側任せの管理体制に起因しています。
そのため、発注後こそ発注側が積極的に関与し、プロジェクトをコントロールする姿勢が求められます。
ILUO評価によるフェーズ完了判定の導入
フェーズゲートレビュー（フェーズ移行の承認判定）では、多くのプロジェクトが「機能のテスト完了」や「バグ件数ゼロ」といった技術的基準だけで判断します。しかし実務では、システムが技術的に完成していても「使いこなせる人間がいない」ために、本番稼働後の混乱を招くことがあります。
この問題に対処する独自のアプローチが、「ILUOフレームワーク」によるフェーズ完了判定です。ILUOは製造業由来のスキル評価手法で、I（教わりながらできる）→L（一人でできる）→U（理解して人に教えられる）→O（改善提案できる）の4段階で習熟度を評価します。
システムリプレイスでは、ユーザー受入テスト（UAT）の完了基準として、「主要業務を担当するユーザーがU（理解・実行可能）レベルに達していること」を設定します。これにより、機能テストの合格に加えて「人間の習熟度」が本番稼働の判断基準に組み込まれ、カットオーバー後の現場混乱を大幅に軽減できます。
予算超過時の経営陣への説明と追加予算獲得の進め方
プロジェクトが進む中で予算超過が見込まれる事態は、決して珍しくありません。製造業D社は、標準パッケージに70%のカスタマイズを加えた結果、費用が当初予算の2.5倍に膨らみました（最終的には業務完全適合により生産性が30%向上し、投資は正当化されましたが）。問題は、予算超過そのものより「いつ、どのように経営陣に報告するか」です。
追加予算の稟議で最も重要なのは、「なぜ予算が不足しているのか」という原因説明と、「追加投資でどのような成果が得られるか」というROI再計算です。経営陣に伝える構成は、①現状の進捗と予算消化状況、②当初想定からの変更要因（要件の追加・難易度変更）、③追加費用の内訳と根拠の順で示すのが効果的です。
そのうえで、④このまま継続した場合と追加投資をした場合のシナリオを比べ、⑤投資対効果を再試算します（人件費削減は基本給の2倍で算出）。特に、「このまま止めた場合に発生するサンクコスト（埋没費用）」を明確に提示することで、追加投資の合理性が伝わりやすくなります。
損切り（サンクコスト放棄）の判断基準
プロジェクトの途中で「このまま続けるべきか、止めるべきか」という判断を迫られることがあります。すでに投じた費用（サンクコスト）は意思決定に影響させてはいけませんが、「ここまで払ったのだから続けよう」という心理バイアスは非常に強く働きます。そこで、損切りの判断基準を事前に設定しておくことが重要です。
損切りを検討すべき具体的なシグナルは4つあります。①スケジュールが3ヶ月以上遅延し、かつ挽回計画が実現困難と判断される場合、②追加費用の見込みが当初予算の50%を超え、ROIがマイナスに転じる場合です。③ベンダーのPMや主要エンジニアが交代し、継続に支障をきたす場合、④要件定義の根本的な欠陥が発覚し、開発のやり直しが必要になった場合です。
プロジェクトを中止した場合に回収できるもの（部分的に完成した機能の活用、取得した知見）を資産として整理し、継続コストと比べたうえで判断することが、経営的に正しいアプローチです。
システムリプレイスの発注・外注に関するripla（リプラ）への相談
riplaは、コンサルティングから開発まで一気通貫で支援できる企業です。IT事業会社として社内DXを推進してきた経験を活かし、ビジネスへの成果創出とシステムの定着支援に強みがあります。
営業・顧客・生産・販売管理など、幅広い基幹システムの構築・導入実績があります。さらに、企業の業務要件に合わせて柔軟に対応できる体制を整えています。
RFP作成の支援から発注先の選定支援、契約条件の精査、プロジェクト管理の伴走支援まで、発注側が主体的にプロジェクトをコントロールできる環境づくりをトータルでサポートします。
「RFPをどう書けばいいかわからない」「相見積もりの判断が難しい」「契約書の内容を精査したい」といったご相談は、お気軽にお問い合わせください。
まとめ
システムリプレイスの発注を成功させるために、この記事で解説した主なポイントを振り返ります。発注プロセスは「RFI → RFP → 評価・選定 → 契約締結」の4段階で進めます。RFP作成の前に、現行システム概要書・業務フロー図・優先度付き要件リストの3つを社内で整えておくことが、良い提案を引き出す前提です。
RFPには「5W1H＋数値」の原則で要件を具体的に記述し、非機能要件（性能・可用性・セキュリティ）も詳細に明示することが重要です。さらに、見積もりの精査は工程別内訳・人月単価・前提条件・運用保守費・データ移行費の5点で行い、金額差が大きい場合は提案説明会を通じて差額原因を確認します。
契約では、要件定義は準委任契約、開発は請負契約という使い分けが基本です。また、下請法が適用される場合は60日以内の支払い義務を守り、SLAには稼働率・障害対応時間・ペナルティ条項を数値で明記することで、品質水準を法的に担保できます。
発注後は、ILUO評価によるフェーズ完了判定を導入して人間の習熟度も考慮した本番稼働判断を行い、予算超過や損切り判断に備えて事前に基準を設けておきます。これが、プロジェクトを安全にゴールへ導くための最大の準備です。
全体ガイドの記事として、システムリプレイスの完全ガイドをご覧ください。
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を創業。