システムリプレイスの発注は、ベンダーに声をかけて見積もりを取れば終わり、というほど単純ではありません。RFPの書き方ひとつで提案の質が大きく変わり、契約形態の選択ミスが後々の責任争いに発展し、下請法への無知が支払い遅延として法的リスクに化けることもあります。数千万円から数億円規模の投資を伴うプロジェクトで「発注側の準備不足」が原因となった失敗は、業界全体を通じて後を絶ちません。

この記事では、システムリプレイスの発注から契約締結、そしてプロジェクト完了まで、発注側が主体的にコントロールするための具体的な手順と知識をまとめています。RFPに記載すべき項目と「曖昧な表現を避ける」テクニック、請負と準委任の使い分け、SLA違反時のペナルティ設計、下請法の実務的な注意点、さらには予算超過時の対処法や損切り判断基準まで、現場の実務に即した情報をお届けします。

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

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

システムリプレイスの発注プロセスは、「RFI（情報提供依頼）→ RFP（提案依頼）→ 評価・選定 → 契約締結」という4段階で進みます。それぞれの段階で発注側が果たすべき役割と準備が明確に異なるため、全体の流れを把握した上で各フェーズに臨むことが重要です。この流れを省略したり順番を入れ替えたりすると、後工程で取り返しのつかない認識齟齬が発生します。

最初のRFI（Request for Information）は、特定のベンダーへの正式な依頼ではなく、市場全体の情報収集を目的とした「問い合わせ」です。複数のベンダーに対して「自社の課題や規模感を示し、どのようなソリューションが存在するか」を確認します。この段階では詳細な要件は不要で、むしろ自社が知らない選択肢を掘り起こすことに価値があります。

RFIを通じてベンダー候補が絞り込まれたら、次にRFP（Request for Proposal）を作成して正式な提案を依頼します。RFPはベンダーが提案書を作成するための設計図であり、ここに書かれた内容の質が提案の質を直接左右します。曖昧なRFPに対しては曖昧な提案しか返ってこないという原則を忘れてはいけません。

提案書を受け取ったら、あらかじめ設定した評価基準に従って各社を比較し、最終的な発注先を決定します。評価は機能要件への適合度・費用・スケジュール・プロジェクト体制・実績の5軸で数値化し、感覚的な判断を排除することが重要です。選定後はNDA（秘密保持契約）を先に締結し、詳細な情報交換ができる環境を整えてから本契約の協議に入るのが一般的な手順です。

RFP作成に入る前に、社内で3種類のドキュメントを用意しておくと作業が格段にスムーズになります。1つ目は「現行システム概要書」です。現在稼働しているシステムの構成図、利用ハードウェアのスペック、連携している外部サービス、ライセンス情報を一枚に整理します。

2つ目は「業務フロー現状図（As-Is）」と「業務フロー理想図（To-Be）」です。現行の業務フローをそのまま引き継ぐ「現行踏襲」を前提としたシステムリプレイスは、不要な業務工程まで新システムに移植してしまう典型的な失敗パターンです。To-Beを先に描くことで、リプレイスを機会として業務改善も同時に行う設計が可能になります。3つ目は「優先度付き要件リスト」で、「必須（Must）」「重要（Should）」「あれば良い（Nice to have）」の3段階で機能要件を分類しておきます。この整理があるだけで、ベンダーとの交渉において削減可能な機能と削減できない機能の議論が明確になります。

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に「本書を発行した日以降、提案締切日までは要件の追加・変更を行わない」と明記し、変更が生じた場合は全候補ベンダーに同時に通知するプロセスを設けます。また、契約時に「変更管理プロセス（Change Request Procedure）」を規定し、要件変更は所定のフォームで申請し、双方合意のうえでスコープと費用を調整する仕組みを組み込むことが重要です。

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

複数のベンダーから提案書と見積もりを受け取った段階で、発注担当者が最も頭を悩ませるのが「この金額は妥当なのか」という判断です。同じ要件に対してA社が3,000万円、B社が7,000万円という差が生じることは珍しくなく、単純に安い方を選ぶのは危険ですが、高い方が必ずしも良いわけでもありません。

見積もりを精査する際は5つの観点で確認します。第1に「工程別の費用内訳が開示されているか」です。要件定義・設計・開発・テスト・移行・PM管理といった工程ごとの費用が明示されていない一括見積もりは、後工程での追加費用請求の温床になります。一般的に費用内訳の目安は要件定義10〜15%、設計10〜25%、開発・実装50〜60%、テスト5〜10%、運用保守15〜20%とされており、この比率から大きく外れる見積もりは根拠を確認すべきです。

第2に「エンジニアの人月単価と工数が妥当か」です。エンジニアの市場単価は新人〜80万円/月、一般80〜140万円/月、上級140〜250万円/月が目安です。安価な見積もりの場合、新人エンジニアを多数アサインすることで工数を見かけ上増やしながら金額を低く抑えている可能性があります。プロジェクトマネージャーや上級エンジニアの単価と工数が適切か確認することが重要です。

第3に「前提条件が明記されているか」です。見積もりは前提条件が変われば金額が変わります。「弊社既存フレームワークを使用した場合」「要件が現時点の提示内容から変更されない場合」といった条件が明示されているかを確認し、前提条件が自社の実態と一致しているかを精査します。第4に「運用保守費用が含まれているか」で、初期開発費用だけを比較して選定した後、運用フェーズで高額な保守契約を結ばざるを得ないケースは頻繁に発生します。5年間のトータルコスト（TCO）で比較することが合理的です。第5に「データ移行費用が別途計上されているか」です。商社E社の事例では、20年分の顧客データが3システムに分散しており、データ統合・クレンジングだけで4ヶ月を要しました。この費用が見積もりに含まれているかは必ず確認が必要です。

相見積もりで大きな金額差が生じた場合、まず疑うべきは「要件の解釈の差」です。同じRFPを読んでも、ベンダーによって要件の難易度や範囲の見方が異なります。安価な見積もりのベンダーが要件を狭く解釈し、高価な見積もりのベンダーが要件を幅広く解釈している場合、実際の開発で安価なベンダーが後から「この機能は要件外です」と主張するリスクがあります。

差額の原因を解明するために有効な手段が「見積もりヒアリング（提案説明会）」です。各ベンダーに対して「工数の差が大きい部分はどこか」「前提条件の違いは何か」を直接聞くことで、金額差の根拠が明らかになります。また、見積もり変動は本来「構造的」に起こりうるものです。要件定義を進める中で新たな要件が判明したり、非機能要件が明確になったりすることで前提条件が変化するため、「超概算（±50%）」「概算（±30%）」「確定（±10%以内）」という精度の違いを発注側が理解しておくことが重要です。最初の見積もりと最終的な費用が異なること自体は問題ではなく、理由が説明できるかどうかが重要なのです。

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

システムリプレイスの契約は、民法・下請法・情報処理推進機構（IPA）のモデル契約書といった複数の法的枠組みが絡み合う複雑な領域です。「契約書はベンダーが用意してくれるもの」という意識で内容を精査せずに署名するのは非常に危険です。この章では、発注側が押さえておくべき契約上の重要ポイントを解説します。

システムリプレイスの契約形態は大きく「請負契約」と「準委任契約」の2種類に分かれます。請負契約はベンダーが「成果物の完成」を約束する契約で、ソフトウェアが完成しなければ報酬は発生しません。一方、準委任契約はベンダーが「業務の遂行」を約束する契約で、一定時間・一定工数の業務提供に対して報酬が支払われます。

一般的に推奨される使い分けは、要件定義フェーズは準委任契約、設計・開発・テストフェーズは請負契約という組み合わせです。要件定義は「完成品」が定義しにくく、試行錯誤しながら進める性質があるため準委任が適しています。一方、詳細設計と開発は成果物（ソフトウェア）が明確に定義できるため、請負として完成責任を持たせることが発注側にとって有利です。

請負契約を選択した場合の大きなメリットは「契約不適合責任」が適用されることです。2020年の民法改正により、旧来の「瑕疵担保責任」が「契約不適合責任」に改められましたが、本質は「契約で定めた仕様を満たしていない場合、ベンダーは修補・代替物引渡し・報酬減額・損害賠償に応じる義務を負う」という点で共通しています。この権利は「知った時から1年以内」に行使する必要があるため、納品物の検収時に仕様書との照合を徹底することが重要です。

下請法（下請代金支払遅延等防止法）は、発注側（親事業者）と受注側（下請事業者）の資本金規模に一定の差がある場合に適用される法律です。システム開発の場合、「情報成果物作成委託」に該当し、発注側の資本金が1,000万円超でベンダーの資本金が1,000万円以下の場合、または発注側の資本金が1億円超でベンダーの資本金が1億円以下の場合に下請法が適用されます。

下請法が適用される最も重要な義務が「60日以内の支払い」ルールです。ベンダーから納品物を受け取った日から60日以内に代金を支払わなければなりません。月末締め翌月末払いなどの一般的な支払いサイクルでは問題ありませんが、四半期後払いや検収確認に時間をかけすぎると違反になります。また、下請法では発注内容の書面交付義務も定められており、口頭での発注は禁止されています。中規模・大企業がスタートアップや中小のSIerにリプレイスを外注する際は、特に意識が必要です。

SLA（Service Level Agreement）は、システムの稼働率・応答時間・障害対応時間などの品質水準をベンダーと数値で合意した文書です。「品質については別途協議する」という曖昧な契約ではなく、具体的なSLAを契約に組み込むことで、サービス品質の「見える化」と「責任の明確化」が実現します。

SLAに定める主な項目は4つです。①可用性（稼働率）：「システムの月次稼働率99.5%以上を保証する」②性能：「ピーク時の画面遷移は3秒以内」③障害対応：「P1（業務全体停止）は発生から2時間以内に対応開始、8時間以内に復旧」「P2（一部機能停止）は翌営業日中に復旧」④定期メンテナンスの事前通知：「計画メンテナンスは2週間前までにメール通知」といった形で具体的な数値と期限を定めます。

ペナルティ条項の設計では「段階的な減額方式」が実務上スタンダードです。例えば、月次稼働率が99.5%を下回った場合は月額費用の10%を減額、99.0%を下回った場合は20%を減額、98.0%を下回った場合は30%を減額するといった設計が一般的です。ただし、ペナルティは損害賠償の代替として認識されることもあり、別途損害賠償請求権を留保するか否かも明記が必要です。SLAの未達が単なる「努力目標」ではなく法的な義務として機能するよう、「保証する」という表現を使い、SLO（目標値）との混同を避けることが重要です。

発注後のプロジェクト管理――主体性を持ってコントロールする

発注が完了したら「あとはベンダーに任せればいい」という考えは非常に危険です。プロジェクトが失敗する最大の原因の一つが「発注側の関与不足」です。ガートナーの調査では、プロジェクトの75%が進行中に何らかの失敗を経験するとされていますが、その多くはベンダー主導・発注側任せの管理体制に起因しています。発注後こそ、発注側が積極的に関与しプロジェクトをコントロールする姿勢が求められます。

フェーズゲートレビュー（フェーズ移行の承認判定）において、多くのプロジェクトは「機能のテスト完了」や「バグ件数ゼロ」といった技術的基準のみで判断します。しかし実務では、システムが技術的に完成していても「使いこなせる人間がいない」という状況が本番稼働後の混乱を招くことがあります。

この問題に対処する独自のアプローチが「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評価によるフェーズ完了判定を導入して人間の習熟度も考慮した本番稼働判断を行い、予算超過や損切り判断に備えて事前に基準を設けておくことが、プロジェクトを安全にゴールへ導くための最大の準備です。

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

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