システム刷新のRFPとは？現行情報の開示範囲・移行要件・ベンダー選定基準を解説

システム刷新のRFPは、新規開発のRFPに「移行」という章を1つ足せば済む文書ではありません。刷新案件には、止められない業務、動いている現行システム、その現行を作った既存ベンダーという3つの前提があり、この3点が要求の書き方も評価の軸も変えます。提案の金額が各社で2倍以上ばらつく原因の多くは機能要件ではなく、現行システムの情報がどこまで開示されているかという一点にある。この記事では、刷新のRFPで追加する現行情報の開示区分、データ移行と切替方式の書き方、サポート終了日や繁忙期という制約条件、移行実績を織り込んだ評価配点までを発注者目線で整理しました。そのうえで、作り込むべき案件と、RFPより先に現状調査を別発注すべき案件の線引きまで踏み込みます。

まとめ｜システム刷新のRFPは現行情報の開示と移行要件で提案の質が決まる

刷新のRFPで提案の質を分けるのは、章立ての体裁ではなく現行システムをどこまで開示したかです。構成・データ・連携・運用の4区分を、粒度を揃えて出したRFPには移行方式まで踏み込んだ提案が返ってきます。逆に「現行システムを刷新したい」という一文と機能一覧だけを配ったRFPには、各社が独自の前提を置いた見積もりが並び、金額差の理由を発注者側で説明できない状態に陥ります。

もう1点、刷新のRFPでは移行要件を提案依頼事項の末尾に置かないことです。データ移行の対象範囲と分担、切替方式、停止許容時間、切り戻し条件。この4項目を独立した章として先に示すと、各社の見積もり前提が揃い、比較できる形になります。評価配点も新規開発と同じでは機能せず、移行と現行調査の計画に2割前後を割く形へ組み替えるのが実務的な判断になる。なお、RFPという文書そのものの章立てと記載粒度の基本はRFPの書き方と章立てサンプルの解説に譲り、本記事は刷新案件でのみ増える論点だけを扱います。

新規開発のRFPとの違い｜刷新案件が抱える3つの前提条件と書き方への影響

刷新のRFPが難しくなる理由は、書く項目が多いからではなく、前提が3つ増えるからです。この3点を意識せず汎用のテンプレートを埋めると、集まった提案を比較できません。

稼働中の業務がある前提で要求を書く｜止められない制約の示し方

新規開発では、稼働開始日が多少ずれても業務そのものは今までどおり回ります。刷新は違う。現行システムが動き続けている間に新システムを作り、ある時点で切り替える必要があり、その切替の前後で業務を止められる時間には上限がある。この上限がRFPに書かれていないと、ベンダーは自社が扱いやすい前提で提案を組み立てます。ある社は週末48時間の停止を前提に一括切替を提案し、別の社は無停止を前提に並行稼働の構成を提案する。両者の金額はそろわず、比較の土台が崩れます。業務を止められる時間帯と最大時間を数値で書くところから始めてください。

現行システムという既存解がある｜現行踏襲をどこまで要求に書くか

刷新案件では「現行と同じ動きにしてほしい」という要求が必ず出てきます。ところがこの一文は、RFPに書く要求としては最も危険な書き方の1つです。現行と同じという指定は、現行の仕様書が完全に揃って初めて見積もれる要求であり、資料が不完全なまま出せばベンダーはリスク分を上乗せするしかない。実務では、現行踏襲を全体へ課すのではなく、業務上の理由がある機能を名指しで挙げ、それ以外は標準機能への寄せを許容すると明記する形が現実的です。理由まで添えれば、代替案が返ってきます。

現行ベンダーを候補に含める場合の情報格差と選定の公平性の担保

刷新のコンペでは、現行システムを保守している既存ベンダーが候補に入る場合があります。既存ベンダーは現行の内部構造を把握しているため、他社との情報格差が大きい。放置したまま同じ評価表で採点すれば、他社は調査リスク分を上乗せして価格で負け、既存ベンダーが自動的に選ばれる構図が生まれます。格差を埋める手立ては2つある。1つは、既存ベンダーが持つ現行資料を発注者の資産として提出させ、添付資料として全社へ配ること。もう1つは、現行調査を提案範囲から外し、全社共通の前提に置くことです。どちらも取れないなら、既存ベンダーへの随意契約と比較検討の記録という形に切り替えるほうが、工数の無駄を減らせます。

刷新RFPで開示する現行システム情報の区分と粒度｜構成・データ・連携・運用

ここが刷新のRFPの中心です。IPAが公開している「システム再構築を成功に導くユーザガイド 第2版」（2018年2月発行のSEC BOOKS。2026年8月時点ではIPAのアーカイブページに掲載）も、再構築の計画段階で現行システムの実態を把握し、ユーザとベンダで前提を共有する工程を出発点に置いています。開示する情報は、次の4区分で整理すると漏れが減ります。

開示する現行システム情報を4区分で整理した一覧と記載粒度の基準

次の表は、刷新のRFPに添付または記載する現行情報の区分です。すべてを詳細に書く必要はなく、工数の見積もりに効く粒度へ揃えるほうが実務的です。

粒度の基準は「ベンダーがこの情報なしでは見積もれないか」の一点で判断します。テーブル定義の全項目は不要でも、主要テーブルの件数と年間増加量は移行時間の見積もりに直結するため必要になる。障害件数も同じで、直近1年の件数と原因の傾向を出せば、非機能要件の目標値に説得力が出ます。逆に、画面のスクリーンショットを何十枚添付しても提案の精度は上がりません。刷新の手法を比較検討している段階であれば、マイグレーションとリプレイス・モダナイゼーションの違いと発注判断の解説で方式の当たりを付けてからRFPを書くほうが、開示すべき情報の範囲も定まります。

現行の設計資料が揃っていないときの書き方と現状調査の切り出し

刷新案件では、設計書が更新されていない、仕様を説明できる担当者がいない、という状況が珍しくありません。ないものをあるように書くのが最悪の対応です。RFPには「設計書は2018年時点の版までで、以降の改修分は反映されていない」「テーブル定義は取得できるが、業務ロジックの仕様書は存在しない」と事実をそのまま書いてください。そのうえで、現行調査をどちらが担うかを明記します。ベンダーに調査から任せるなら調査工程を提案範囲に含めると書き、調査結果によって後続の見積もりを見直す前提であることも添える。この一文があるかどうかで、提案の金額に含まれるリスク分が変わります。

開示範囲とNDAの扱い｜伏せる情報の線引きと質疑での追加開示

現行情報のなかには、そのまま配れない内容が混ざります。ネットワーク構成の詳細、認証方式、外部接続先の契約条件、顧客データのサンプル。これらは配布段階では伏せ、RFP本文に「秘密保持契約の締結後、二次審査の対象社にのみ開示する」と条件を書く形が扱いやすい。段階的な開示なら、一次審査は概算、二次審査で精度の高い見積もりという2段構えになり、辞退社に機微情報を渡さずに済みます。質疑での追加開示も同じ運用で、回答は質問者名を伏せて全社へ一斉に返す。個別に答えると情報量の差がそのまま提案の差になります。

移行要件と切替方式をRFPに書く方法｜データ移行の分担と停止許容時間

移行要件は提案依頼事項の一項目ではなく、独立した章として扱ってください。刷新案件で追加費用が発生する原因は、ここの曖昧さに集中しています。

データ移行の対象範囲と発注者・ベンダーの分担を明記する書き方

データ移行で最初に決めるのは、どこまでのデータを移すかです。全件を移すのか、直近何年分を移して残りは参照用に別保管するのか。この判断は業務側でしか決められないため、RFPを書く時点で結論を出しておきます。次に分担です。実務では、抽出はベンダー、名寄せや不整合データの判断は発注者、という分け方が多く採られます。判断そのものを外部へ渡せない作業だからです。RFPには、移行対象の範囲、抽出と変換の担当、検証の担当、リハーサルの回数という4点を書いてください。分担のないRFPに対して、ベンダーは自社作業を最小に見積もる。その差が追加費用として表面化します。

一括切替と段階移行を要求でなく制約と評価の軸として提示する理由

切替方式を「段階移行で実施すること」と要求の形で書くと、一括切替のほうが安く速い場合でもその提案は出てきません。方式は実現方法にあたり、ベンダーの提案に委ねる領域です。発注者が書くべきなのは、方式そのものではなく方式を縛る制約のほう。業務を止められる時間、並行稼働を許容できる期間と体制、切替を実施できない時期。これらを制約として示し、「提案する切替方式とその根拠、想定リスクを記載すること」と提案依頼事項に書けば、各社の方式が比較できる形で返ってきます。制約なしに方式だけ指定すると、指定どおりの見積もりが並び、判断力の差が見えません。

停止許容時間・移行リハーサル・切り戻し条件を数値で示す書き方

切替当日の条件は数値で書きます。停止許容時間は「土曜0時から日曜18時まで、最大42時間」のように時間帯と上限で示す。移行リハーサルは本番同等データで何回実施するか、その環境をどちらが用意するかを書く。切り戻し条件は、いつまでに何が確認できなければ現行へ戻すのかという判断基準と、判断の期限時刻まで決めておきます。前提が書かれていないRFPは、当日に問題が出たときの意思決定を現場任せにする構造になり、そのまま停止時間の超過につながる。工程ごとにどこで破綻が起きたかは基幹システム刷新の失敗事例を工程別に分解した解説で整理しているため、切り戻し条件を書く前に目を通しておくと数値の見当が付きます。

刷新案件の期限と凍結期間の書き方｜EOSLと繁忙期から逆算する制約条件

刷新には、新規開発にはない外部由来の期限が付きものです。この期限をRFPに書かないまま提案を募ると、スケジュールが成立しない提案が混ざります。

保守サポート終了日から逆算する稼働期限と遅延時の代替案の求め方

OSやミドルウェア、パッケージ製品のサポート終了日（EOSL）が刷新の引き金になっている案件では、その日付をRFPに明記します。「2027年3月末に現行基盤のサポートが終了するため、同年1月末までの稼働を必須とする」という書き方です。あわせて、期限に間に合わない場合の代替案を提案書に書かせてください。延長サポートの費用負担、対象範囲を絞った先行リリース、暫定的な基盤更改による期限の後ろ倒し。これらを提案の段階で出させておくと、遅延が起きたときの意思決定が早くなる。期限だけを書いて代替案を求めないRFPは、各社が期限に合う体裁の線表を出し、実現性の差が見えないまま選定に進む結果を招きます。

決算期・繁忙期という凍結期間を先に書いて提案の前提条件を揃える

切替を実施できない時期も先に書きます。決算期、月次の締め処理期間、業種ごとの繁忙期、棚卸しの週。これらを凍結期間として列挙すると、線表の引き方が各社でそろいます。凍結期間を書かずに提案を受け取り、後から「その週は締め処理で切替できない」と伝える展開は、線表の引き直しと再見積もりで数週間を失う原因です。発注者側の要員が業務繁忙で参画できない時期も書いてください。刷新は業務部門の関与量が新規開発より多く、受入テストと移行データの確認に人手が要る。この負荷を見込まない線表は、テスト工程で必ず遅延します。

ベンダー選定基準を刷新向けに組み替える｜評価配点と現行調査の体制

評価基準はRFPに開示する前提ですが、刷新案件では配点そのものを組み替える必要があります。新規開発と同じ配点では、移行の巧拙が採点に反映されません。

移行の実績と現行調査の体制を評価配点へ組み込む考え方と配分例

刷新案件で差が出るのは、機能提案の華やかさではなく移行計画の現実味です。評価軸に「移行・現行調査の計画」を独立して立て、2割前後の配点を割り当てます。採点する中身は、現行調査の進め方、移行リハーサルの回数と検証方法、切り戻しの判断基準、移行専任の要員が体制図に載っているかという4点。実績の評価も、開発言語や業種の一致より、同規模のデータ移行を伴う刷新を完了させた件数のほうが予測力があります。発注先の選び方の全体像は基幹システムの構成領域と刷新の進め方を整理した解説で確認してください。

新規開発の案件と刷新の案件で評価配点をどう変えるかの対比一覧

次の表は、100点満点の配点例を新規開発と刷新で対比したものです。合計を変えずに移行の枠を作っています。

配点はRFP本文に開示します。移行に20点が付いていると分かれば、各社は移行計画に紙幅を割いて提案してくる。逆に伏せると価格勝負と解釈され、移行工程を薄く見積もった構成が集まり、契約後に追加費用として跳ね返ります。配点の開示は公平性のためというより、必要な提案を引き出すための手段だと考えてください。

提案書に現行調査の前提と追加費用が発生する条件を書かせる指定

刷新の提案書には、現行調査の結果しだいで金額が動く余地が必ず残ります。余地を隠して安い金額を出す提案と、条件を明示して相応の金額を出す提案が並ぶと、条件を書いた側が価格で負けます。防ぐには、提案書の様式で「見積もりの前提条件」と「追加費用が発生する条件と概算幅」を必須記載にし、前提が書かれていない提案は条件不備として評価を下げる旨も添えてください。要求をどこまでRFPに書き、どこから要件定義で詰めるかという線引きはRFPと要件定義の書き分ける範囲を整理した解説にまとめています。

刷新のRFPを作り込む案件と現状調査を先に別発注する案件の線引き

ここからは、テンプレート配布型の解説が踏み込まない判断の話です。刷新だからといって常にフル仕様のRFPを作るのが正解にはならず、条件を付けて線を引く必要があります。

フル仕様の刷新RFPを作り込むべき案件の条件と規模の見極め方

次の条件のいずれかに当てはまるなら、作成に4〜8週間を投じてもRFPを作り込む価値があります。3社以上のコンペで発注先を決める、初期費用が1,000万円を超える、複数部門の業務が対象で要求の取りまとめから必要になる、データ移行の対象が数百万件を超える、サポート終了日という動かせない期限がある。この規模では、選定を誤ったときの損失が作成工数を桁違いに上回るからです。整理した現行情報はそのまま契約後の要件定義の入力になる。刷新の対象範囲から相談したい段階であれば、システムマイグレーション・リプレイスの相談窓口で現行調査の切り出し方から整理する方法もあります。

RFPより先に現状調査を別発注すべき場面と切り分けの判断条件

一方、次の場合はRFPを書く前に現状調査だけを別発注するほうが早く進みます。設計書が10年以上更新されておらず現行仕様を説明できる担当者が社内にいない、業務ロジックがプログラム内に埋め込まれていて仕様の抽出に解析が要る、外部連携先が10系統を超えて全容が把握できていない。この状態でRFPを配ると、各社が調査リスクを見込んだ幅の広い金額を出し、比較になりません。調査を1社に先行発注し、その成果物を全社共通の前提としてRFPに添付する。調査費用は増えますが、提案の精度が上がって契約後の追加費用が減るため、総額では回収できる場合が多い。調査を担当した会社を後続の開発から外すかどうかは、RFIの段階で伝えておいてください。

刷新そのものを見送る、または時期を後ろへ倒す判断が成り立つ条件

RFPを書く前に立ち止まるべき場面もあります。刷新の目的が「システムが古いから」に留まり、業務上の課題が言語化できていない場合。現行の障害件数も運用コストも許容範囲で、サポート終了日にも猶予がある場合。業務側の主管部門が決まっておらず、要求の取りまとめを担う人が不在の場合。この3点が重なっているなら、刷新の判断そのものを先送りし、現行の課題を数値で押さえる作業を先に置くほうが結果的に安く済みます。刷新の緊急度をどう測るかはDXレポートの試算と刷新を判断する基準の解説で整理しています。期限だけを理由に走り出す判断は費用倒れになりやすい。

刷新RFPで提案の質が落ちる失敗パターンと配布前に潰す確認手順

刷新のRFPで起きる失敗は、汎用のRFPとは別の形で表れます。典型の2つと配布前の確認手順を押さえておきます。

現行機能一覧をそのまま要求にした刷新RFPで費用が膨らむ理由

もっとも多い失敗が、現行システムの機能一覧を書き出して「すべて同等の機能を実現すること」と付け加える書き方です。現行機能には、使われなくなった帳票、年に1回しか動かない処理、特定の担当者だけが使う画面が必ず混ざっています。棚卸しをせずに一覧を渡せば、ベンダーは全機能を作る前提で見積もり、金額が現行の再構築費用そのものになる。回避策は、配布前に利用実績で機能を仕分けることです。直近1年の利用回数を取得し、ゼロ件の機能は対象外の候補として明示する。判断が付かない機能は「代替手段を含めて提案を求める」と書けば、標準機能への寄せ方が提示されます。

移行の要件を後回しにしたRFPで追加見積もりが発生する仕組み

もう1つが、移行を「別途協議」と書いて先送りする対応です。提案の段階で条件が定まっていない項目は、契約後に発注者とベンダーの想定が食い違う場所になり、そのまま追加見積もりの対象になります。特に、移行データのクレンジング範囲と、移行後のデータ差異をどこまで許容するかは、後から決めると必ずもめる。配布前は、要求・制約・前提の3分類でRFPを通し読みし、移行の記述がどこにも入っていない項目を洗い出してください。現行情報の記述と添付資料の矛盾も同時に確認します。本文で「連携は5系統」と書きながら添付の構成図に7系統が描かれている食い違いは、質疑の工数を増やし、提案期間を実質的に削る結果になります。

よくある質問

刷新のRFPについて、発注担当者から多く挙がる質問を5つ取り上げます。

システム刷新のRFPは新規開発のRFPと何が違いますか？

章立ての骨格は同じで、現行システム情報の開示、移行要件、切替方式、凍結期間という4つの章が加わる点が違います。加えて評価配点の組み替えも必要で、移行と現行調査の計画に2割前後を割り当てる形が実務的です。基本構成は汎用のRFPと共通のため、章立てサンプルを土台にして刷新固有の章を足す進め方が早くなります。

現行システムの資料が残っていない場合、RFPはどう書けばよいですか？

資料がないという事実をそのままRFPに書いてください。「設計書は2018年版までで以降の改修は未反映」と明記し、現行調査を提案範囲に含めるか、別工程として切り出すかを指定します。書かずに配ると各社が独自の前提でリスク分を上乗せし、金額差の理由が説明できなくなる。欠落が広範囲に及ぶ場合は、RFPより先に現状調査だけを別発注する判断も検討に値します。

現行のベンダーにもRFPを配布してよいですか？

配布して差し支えありませんが、情報格差を埋める手当てが要ります。既存ベンダーが保有する現行の設計資料を発注者の資産として提出させ、添付資料として全社へ配るのが基本の対応です。難しければ、現行調査を提案範囲から外して全社共通の前提に置きます。どちらも取れないまま同じ評価表で採点すると、コンペの体裁だけが残ります。

移行費用はRFPの予算枠に含めて書くべきですか？

含めたうえで、内訳を分けて提示させる書き方をおすすめします。「初期費用5,000万円以内（うちデータ移行費用を内訳として明示すること）」という形です。総額に溶かすと見積もり方針の差が見えず、安く見せるために移行工数を削った提案が有利になってしまう。年間保守費の上限もあわせて書いておくと、初期費用だけ抑えて保守で回収する構成を避けられます。

刷新のRFP作成にはどのくらいの期間がかかりますか？

現行情報の整理を含めて4〜8週間が目安です。新規開発のRFPより1〜2週間多く見るのは、現行の構成・データ量・連携先・利用実績を集める作業が加わるためです。時間がかかりそうなら、本文の作成と現行情報の収集を並行させ、終わった項目から添付資料に落とし込む進め方が現実的になります。RFP発行から契約締結までは全体で4〜5か月を見込んで逆算してください。

関連記事

• RFPの書き方とは？記載項目・章立てサンプルと作成手順を発注者目線で解説：RFPという文書の章立てと記載粒度の基本を扱う親記事です。
• 基幹システムとは？業務システム・ERPとの違いと構成領域・刷新の進め方を解説：刷新プロジェクト全体の進め方と外注先の選定基準を整理しています。
• マイグレーションとは？リプレイス・モダナイゼーションとの違いと発注判断を解説：RFPを書く前に決める刷新手法の選び分けです。
• 基幹システム刷新の失敗事例と回避策｜出荷停止と訴訟に至った5件を工程別に分解：移行と切替で何が起きるかを具体例で確認できます。
• 2025年の崖とは何だったのか｜DXレポートの試算と2026年に刷新を判断する基準：刷新の緊急度をどう測るかという判断材料です。