SAP導入のRFPの書き方 ─ 見積もりが割れにくくなる12項目と、先に決める評価基準

SAP導入のRFP（提案依頼書）を書こうとして、ひな形やサンプルを探す。章立ては見つかります。ところが項目を埋めて各社に送っても、返ってくる見積もりは金額も期間もそろいません。

理由は、項目の不足より、一つひとつの項目の書き方が粗いことにあると筆者は見ています。「データ移行：一式」と書けば、ある会社は残高だけを移す前提で見積もり、別の会社は過去の明細まで移す前提で見積もります。RFPの出来は、前提をどこまで細かく書いたかで決まります。 もう一つ大事なのは順番で、評価基準は提案を読む前に決めておきます。

SAP導入のRFPがほかのシステムのRFPと違う点は、機能でなく進め方と人を選ぶこと

製品は決まっていて、選ぶのは進め方と人

一からつくるシステムのRFPは、欲しい機能を並べて、つくれる会社を探します。SAP導入のRFPは事情が違います。製品はSAPで、標準の機能はどの会社が導入しても同じです。提案によって変わるのは、どこまでを標準に合わせるか、足りない部分をどう扱うか、誰が担当するか、といった進め方と人です。

そのため、現行システムの機能一覧をそのまま要求として書くと、要件がまとまりにくくなります。SAPジャパンの年次イベントでは、登壇した導入会社のコンサルタントが、発注側から届くRFPは現行を前提にした型が多いと指摘しました。現行のシステムに引っ張られてプロジェクトが長引き、追加開発（アドオン）も増えるという指摘です。SAPのRFPに書くのは、いまの機能の一覧より、新しい業務で実現したいことと、見積もりの前提です。

SAP導入のRFPで比べるのは、製品ではなく進め方と人

RFIとRFPは、聞くことが違う

RFI（情報提供依頼書）は、提案を頼む前に、広く情報を集めるための文書です。政府の情報システムのルールである「デジタル・ガバメント推進標準ガイドライン」は、民間企業に適用されるものではありませんが、RFIの位置づけを示しています。RFIを、要件の検討にあたって専門的な知見を広く得るために行うものとしています。求める内容の例に挙がっているのは、検討中の案の実現性、実現の方法、必要な経費と要員の見込みです。

RFPは、前提を示したうえで、提案と見積もりを頼む文書です。出すのが一度とは限りません。IPA（情報処理推進機構）と経済産業省が整備した「情報システム・モデル取引・契約書」の解説は、契約の進め方の例を示しています。RFIのあとにRFPを出して試算の見積もりを受け、もう一度RFPを出して概算の見積もりを受け、外部設計を経て確定の見積もりに進む流れです。

表　RFIとRFPの使い分け（出典1・2をもとに作成）。「返ってくるもの」の欄は筆者の整理。

RFPを出す前とあとに、発注側の作業がある。評価基準は、提案が届く前に決める

RFPは書いて終わりの文書ではない。前提を決める作業と、質疑と評価の作業が、前後に続く。

SAPのRFPに書く12項目は、対象、方式、量、分担、契約の順に並べる

書く項目は、SAP導入の費用の記事で挙げた、見積もりを取る前にそろえる12項目と同じです。ここでは、依頼書の章立てに並べ直します。

章立ては、先の政府のガイドラインが調達仕様書に書く事項として挙げる並び（背景と目的、要件、作業の内容、体制、前提条件など）を参考にしました。

表　RFPの章立てと書く内容。12項目は費用の記事と同じで、章への割り振りは筆者の整理。章立ての考え方は出典1を参考にした。

違いが出るのは、一行の書き方です。同じ項目でも、粗く書けば各社が別々の前提を置き、細かく書けば前提がそろいやすくなります。

同じ項目でも、前提まで書いた一行は見積もりが割れにくい

粗い一行は、各社が自分の経験で埋める。前提まで書くと、金額の差を進め方と体制の差として読みやすくなる。

評価基準は、提案を読む前に決める

提案書が届いてから基準を話し合うと、最初に読んだ提案に評価が引っ張られやすいと筆者は見ています。基準は先に決め、RFPに載せます。

観点は、理解、進め方、人、管理に分ける

先の政府のガイドラインは、提案依頼書に載せる事項の一つに評価基準を挙げています。提案を受ける前に、基準を文書にしておくという考え方です。評価する事項の例として、8つを挙げています。

• 制度、業務及び情報システムに対する理解度
• 要件定義の理解度
• 任意で提案を求める事項に対する充足度
• プロジェクトの計画能力
• プロジェクトの管理能力
• 設計・開発等に関する技術的能力
• 設計・開発等の実績
• 組織的対応力

政府の調達のための例で、民間に適用されるルールではありません。それでも観点の立て方は、民間のSAP導入でも参考になると筆者は考えています。

配点は、合否の線と、重く見る観点を分けて決める

同じガイドラインは、必須の事項のうち最低限の要求を、合否を判断する基礎点にするとしています。そのうえで、重く見る事項に加点の配分を厚くします。価格の点と技術の点の配分も、先に決めておく事項です。

SAP導入に当てはめた例を示します。観点は筆者の整理で、配点の数字は説明のための例です。

表　評価基準の例。観点は筆者の整理。配点は合計100とした場合の例で、推奨する値ではない。考え方は出典1による。

評価は2段で組む。必須に答えない提案を外してから、観点ごとの配点で比べる

面談では、その案件を担当する本人の話を聞きます。同じガイドラインも、審査の手法として、責任者になる予定の人によるプレゼンテーションと質疑応答を挙げています。面談で確かめる問いは、SAPコンサル会社の選び方の記事にまとめました。

質疑の回答は全社に返し、各社の前提を並べてから金額を読む

各社から届く質問への答えは、新しい前提です。1社にだけ答えると、その会社だけが違う前提で見積もります。政府のガイドラインも、提案に重要な影響がある応答は、関係するすべての事業者に通知するとしています。

回答で前提が変わったら、RFPの該当する項目を書き直します。届いた提案は、金額の前に、各社の前提を横に並べて読みます。並べ方はSAPベンダーの選び方の記事で図にしています。

1社の質問への答えは、全社の前提になる。回答は全社に返し、RFPに書き戻す

RFPの前に、4項目を経営会議で決める

12項目のうち、担当者だけでは書けない項目が4つあります。1の対象範囲、4の利用区分、5の標準機能で足りない要件、8の移行データです。どれも経営の判断です。

12項目のうち4つは、担当者だけでは書けない。RFPの前に経営会議で決める

RFPを書き始める前に、この4つを経営会議にかけてください。その手前の構想で決めることは、SAP導入の構想策定の記事にまとめました。導入全体の流れと、工程ごとに決めることは、SAP導入の進め方の記事に整理しています。

Never Redは、発注側に立つ選定の事務局として、RFPの作成、評価基準の設計、質疑の管理、比較評価の資料づくりをお引き受けしています。システム選定を支援した事例はプロジェクト事例に、SAPの案件で当社が入った工程はSAP導入事例に、支援の範囲はSAP導入支援に載せています。

よくある質問

SAPのRFPのサンプルやひな形はありますか。

SAP導入に限ったひな形で、公的な機関が公開しているものは見当たりません。章立ての参考になるのは、政府の「デジタル・ガバメント推進標準ガイドライン」です。ひな形は項目の漏れを防ぎますが、前提の細かさまでは埋めてくれません。

RFPの作り方で、最初にやることは何ですか。

導入の目的を測れる言葉で書くことと、対象範囲を決めることです。この2つが決まらないと、残りの項目の前提を置けません。

RFPを外部の会社に書いてもらってもよいですか。

書く作業は頼めます。前提を決めるのは発注側です。政府のガイドラインは、調達仕様書の作成に直接関与した事業者を、原則としてその調達の入札に参加させないとしています。民間に適用されるルールではありませんが、書く会社と提案する会社を分ける考え方は参考になります。

SAP導入のRFPの書き方や、評価基準の作り方についてのご相談は、お問い合わせからお寄せください。

出典

1. RFIの目的と求める内容、調達仕様書に書く事項、提案依頼書に載せる事項（RFPの内容、提案手続、評価基準、審査手法）、評価事項の例、基礎点と加点の考え方、重要な応答内容を関係するすべての事業者に通知すること、調達仕様書の作成に直接関与した事業者の入札制限：デジタル庁「デジタル・ガバメント推進標準ガイドライン」（2026年6月12日 デジタル社会推進会議幹事会決定）第3編第5章・第6章
2. 契約プロセスの例（RFI、RFP①と見積①（試算）、RFP②と見積②（概算）、見積③（確定））と、多段階契約と再見積もりの考え方：独立行政法人情報処理推進機構「システム開発の健全化に向けて ～『情報システム・モデル取引・契約書』から読み解く～」（2025年4月24日講演資料）
3. 現行システムを前提にしたRFPが多く、要件がまとまりにくくなり、プロジェクトの長期化とアドオンの増加を招くという指摘：SAPジャパン「エキスパートコンサルが明かす SAP ERP 導入の失敗と成功の法則」（SAP NOWレポート、2024年10月7日）