ベンダー選定

システム開発RFPテンプレート｜必須項目と稟議を通す書き方【2026年版】

2026年7月16日22分で読める

QUICK CHECK

本文を読みながら、自社で進めるべきか、相談前に何を整理するかを確認できます。

GXO COLUMN

システム開発

結論から先に。 システム開発のRFP（提案依頼書）は「ベンダーに要件を伝える文書」であると同時に、社内稟議・予算承認を通すための説明資料でもあります。この二役を両立できていないRFPは、①各社の見積金額が数倍単位でぶれて比較できない、②経営層・財務が投資判断できず稟議が差し戻される、という二重の失敗を招きます。逆に言えば、RFPで「作るもの・作らないもの・予算・非機能水準・評価基準」を先に固定すれば、相見積もりは横並びで比較でき、稟議は「なぜこの金額でこのベンダーか」を一枚で説明できるようになります。

本記事は、RFPの必須項目テンプレート（10項目）と各項目の書き方に加え、相見積もりを比較可能にする条件揃え・予算の書き方・稟議を一発で通す4点セット・発注前チェックリスト・見積もりの読み方・よくある失敗パターンまで、発注側（買い手）の判断軸として整理します。非機能要求の標準はIPA（独立行政法人情報処理推進機構）の一次情報で裏取りしています。

この記事を読むべき人

初めてシステム開発・DX投資を外注し、RFPの書き方がわからない中小企業の経営者・事業責任者
ベンダー各社の見積が数倍違い、どれが妥当か判断できない発注担当者・情シス・兼任情シス
経営会議や稟議で「その金額の根拠は？」と問われ、予算承認が止まっている管理部門・DX責任者
過去にPoC止まり・追加費用・仕様の認識ズレで痛い目を見て、次は失敗を避けたい決裁者

いずれかに当てはまるなら、RFPを「体裁の整った依頼書」ではなく「見積比較と稟議承認を通すための設計図」として作り直す価値があります。

FREE DOWNLOAD

中小企業のDX推進「失敗を防ぐ5ステップ」ガイドを無料でお送りします

多くの企業がつまずくポイントを着手順に整理した無料ガイド。相談する前に、自社の現在地と進め方を掴めます。

5ステップガイドを無料でダウンロード

RFP・RFI・要件定義書は何が違うのか

RFPを書き始める前に、混同されやすい3文書の役割を分けておきます。ここを曖昧にしたまま作ると、要件定義書レベルの精密さを求めて手が止まるか、逆にRFIレベルの浅さで出してしまい、比較にならない提案が集まります。

横にスクロールして確認できます

文書	目的	誰が作る	いつ	記載の粒度
RFI（情報提供依頼）	ベンダーの実績・対応可否を知る	発注側	検討初期	概略・スクリーニング用
RFP（提案依頼書）	同一条件で提案・見積を出させ比較する	発注側	ベンダー選定前	目的・要件・制約・評価基準を明示
要件定義書	実装内容を確定する	発注側＋受注側	契約後の上流工程	機能を一意に確定できる精度

覚えておくべき順序は「RFIで候補を絞り→RFPで提案を競わせ→契約後に要件定義で確定する」です。**RFPは要件定義書ではありません。**RFP時点で全機能を確定させる必要はなく、むしろ「何を解決したいか（Why）」「どこまでやるか（スコープ）」「いくらまで・いつまで（制約）」を明確にすることが、良い提案を引き出す条件になります。

RFPの必須項目テンプレート（10項目）

競合各社のテンプレートと、IT系メディア・SIerの解説を横断すると、システム開発RFPの必須項目は次の10項目に収れんします。表の「稟議で効く理由」列は、その項目が単なるベンダー向け情報ではなく、社内の予算承認にどう効くかを示したものです。

横にスクロールして確認できます

#	項目	主な記載内容	稟議で効く理由
1	プロジェクト概要・目的	背景・解決したい課題・期待効果	「なぜ投資するか」を経営に説明できる
2	現状（As-Is）	業務フロー・既存システム・データ	投資対象の妥当性を裏付ける
3	要件（機能・非機能）	機能一覧＋非機能水準	スコープの大きさ＝金額の根拠
4	スコープ（対象外の明記）	やること／やらないこと	追加費用の予防、金額の締まり
5	制約条件	予算上限・期間・技術・体制	予算枠との整合を示せる
6	提案依頼事項	工程別工数・体制・リスク・保守	各社を横並びで比較できる
7	評価基準	採用の判断軸と配点	「なぜこのベンダーか」を説明できる
8	スケジュール	提案期限・選定・着手・稼働	予算計上時期・期の判断に効く
9	契約・ベンダー要件	契約形態・実績・体制要件	発注先リスクの説明材料
10	提出方法・機密保持	フォーマット・NDA・情報取扱	比較作業の効率とガバナンス

分量の目安は全体で20〜30ページ程度ですが、**ページ数を満たすことが目的ではありません。**薄くても第3章（要件）・第4章（スコープ）・第6章（提案依頼事項）・第7章（評価基準）の4つが具体的であれば、比較可能なRFPになります。逆に、ここが抽象的だと何ページ書いても見積はぶれます。

各項目の書き方で外してはいけない点

第1章目的は「AIで営業を効率化する」ではなく、「営業一人あたり月◯時間かかっている見積作成・案件管理を削減し、商談時間に振り向ける」まで具体化します。目的が曖昧なプロジェクトは実装段階で必ず迷走します。

第3章要件は、機能をMust／Want／不要の3段階で仕分けます。全部Mustにすると全社の見積が跳ね上がり、Wantを混ぜたままだと各社が勝手に解釈して金額が割れます。非機能要件（速度・可用性・セキュリティ・運用・拡張性・移行性）は、後述するIPAの枠組みで漏れなく水準を指定します。

第4章スコープ外は、多くのRFPで最も軽視されている一方、金額を最も締める項目です。「既存の◯◯システムは改修しない」「データ移行は直近1年分のみ」「他部門展開は本プロジェクト対象外」と書くだけで、各社の見積前提が揃います。

第7章評価基準は、価格・実績・体制・技術・保守などの配点を先に決めておきます。これがないと、選定が「なんとなく安いところ」か「なんとなく大手」に流れ、稟議で根拠を問われて詰まります。

FREE DOWNLOAD

中小企業のDX推進 5ステップガイド

多様な企業の導入実績から抽出した、失敗を防ぐDX推進の5つのステップを継続解説。

30分で相談するガイドをDL

なぜ各社の見積が数倍ぶれるのか──相見積もりを比較可能にする条件揃え

「A社1,000万円、B社4,000万円」のような開きは、ベンダーの良し悪しより前提条件が揃っていないことが主因です。同じRFPを渡しても、以下の前提が書かれていなければ各社が独自に補完し、金額は簡単に数倍ぶれます。

横にスクロールして確認できます

揃えるべき前提	揃っていないと起きること	RFPでの明示例
機能スコープ	Mustのみ社とWant込み社が混在	「今回はMust機能のみ。Wantは別見積」
データ移行範囲	全期間移行と一部移行で工数が段違い	「移行は直近12か月分、形式はCSV」
ユーザー研修	管理者向けと全社研修で差が出る	「研修は管理者10名対象、教材込み」
保守・SLA	保守6か月と24か月で総額が変わる	「稼働後12か月保守、可用性99.5%」
体制・関与度	常駐前提と定例のみで単価が変わる	「週次定例＋オンライン、常駐なし」

相見積もりは2〜3社、多くても3〜5社が現実的です。1〜2社では相場感が掴めず、6社以上は比較工数が膨らみ選定が長期化します。そして重要なのは、同じRFP・同じ質問票・同じ提出フォーマットで出させること。提案書の様式がバラバラだと、優劣ではなく「読みやすさ」で選んでしまいます。

なお「安いから」で選ぶのは最も危険な判断です。極端に安い見積は、スコープを狭く解釈しているか、要件の抜けを後から追加費用で回収する前提のことが少なくありません。金額の低さではなく、前提の明快さと工数の内訳で選ぶのが鉄則です。システム開発の費用感が読めない段階なら、システム開発の費用感を第三者と整理する相談を挟むと、各社の見積を同じ物差しに載せ替えやすくなります。

予算はRFPに書くべきか──「松竹梅」で上限とROIを両立する

発注担当が最も迷うのが「予算をRFPに明示すべきか」です。結論は原則明示、ただし内訳を要求するです。予算を書かないと各社の提案規模がバラつき比較にならず、書くと「上限に張り付いた見積」が返ってくる——このジレンマは実務でよく語られます（この論点は日経クロステックなど二次情報でも整理されています）。

上限に張り付くのを避けるには、「松竹梅」方式が有効です。予算レンジを示したうえで、松（気づいていない課題まで含めた理想案）・竹（現実解）・梅（最小限）の3案を各社に求めます。これにより、上限内で何を諦め何を取るかの判断材料が揃い、稟議でも「梅から始めて段階投資する」といった説明ができます。

そして予算欄は総額一本ではなく、イニシャル（初期）とランニング（保守・運用）を分けて要求します。システム投資は初期費用より運用フェーズの累計が効いてくることが多く、初期だけで比較すると「安く導入して高く保守する」構造を見抜けません。人月単価と投入工数、ハード・ソフト・保守を費目ごとに明細化させ、費目の抜けを潰します。

非機能要求はIPA「非機能要求グレード」で揃える（一次ソース）

多くのRFP解説が機能要件に紙幅を割く一方、見積のブレと後々のトラブルは非機能要件の抜けから生まれます。「速い」「安全」「落ちない」を感覚で書くと、各社が勝手な水準で見積り、稼働後に「思っていた性能と違う」が起きます。

ここで頼れる一次情報が、IPA（独立行政法人情報処理推進機構）の**「非機能要求グレード」**です。IPAの公開資料によれば、非機能要求グレードは発注者と受注者の間で非機能要求の認識齟齬を防ぐために体系化されたもので、次の6大項目でシステム基盤要件を整理します（出典：IPA、後掲）。

横にスクロールして確認できます

IPA 非機能要求の6大項目	RFPで指定すべき例
可用性	稼働率、計画停止の許容、障害時の復旧目標時間
性能・拡張性	応答時間、同時接続数、将来の拡張倍率
運用・保守性	監視・バックアップ・保守窓口・対応時間帯
移行性	移行対象データ量・方式・移行期間
セキュリティ	認証・権限・ログ・暗号化・脆弱性対応
システム環境・エコロジー	設置環境、電力・スペース等の制約

IPAは、このグレード表をRFPに添付し、各項目で希望水準と具体値を明記すれば、全提案社を同じ土俵に乗せられコスト比較が公平になるとしています。自社でゼロから非機能要件を書き起こすより、この6項目をチェックリスト代わりに使うほうが、抜けが減り見積も締まります。中小規模の案件なら全項目を厳密に埋める必要はありませんが、少なくとも「可用性・性能・セキュリティ・運用・移行」の5つは水準を言語化しておくべきです。

なお非機能要求グレードのプロジェクト自体は公開後にアーカイブ化されていますが、資料は引き続きIPA公式サイトで参照でき、非機能要件を漏れなく指定するための実務的な枠組みとして有効です。

抽象表現を定量表現へ書き換える（見積が締まる言い換え表）

RFPの言葉が抽象的だと、ベンダーは安全側に大きく見積るか、逆に都合よく小さく解釈します。どちらも発注側に不利です。次のように定量化するだけで、見積の前提が揃い、稟議での説明もしやすくなります。

横にスクロールして確認できます

抽象表現（NG）	定量表現（OK）
最新技術を活用したい	運用実績5年以上の枯れた技術スタックを優先
業務を効率化したい	対象業務で月◯時間の工数を削減したい
拡張性の高い設計	3年後に同時接続を3倍まで拡張できる設計
高品質・安定稼働	稼働率99.5%以上、応答2秒以内
柔軟に対応してほしい	仕様変更時の対応工数・費用の見積基準を明記
セキュアなシステム	認証方式・権限設計・ログ保持期間を指定

「最新技術」を安易に求めないのは、買い手にとって重要な自衛策です。話題性のある新しさは、実績が浅く運用ノウハウが乏しいことの裏返しでもあります。避けたいのは技術的新規性より運用の失敗——この優先順位を言葉にしておくと、提案の方向性が現実的になります。

稟議・予算承認を一発で通すには──RFP＋4点セット

RFPが良くても、稟議は別の資料で決まります。決裁者が見るのは「作るもの」ではなく「投資対効果とリスク」だからです。RFPと合わせて、次の4点セットを標準装備にします。

横にスクロールして確認できます

資料	役割	決裁者が確認すること
ROI試算書	投資回収の見通し	何年で回収し、どの指標が改善するか
リスク評価書	想定リスクと対策	失敗した場合の損失と歯止め
ベンダー比較表	選定の客観根拠	評価基準に沿って選んだか
契約書ドラフト	責任分界と条件	追加費用・瑕疵・解約の条件

さらに、稟議は決裁者ごとに見る所が違うことを踏まえて資料を作ると通りやすくなります。

経営層：売上・粗利・リスク低減のどれに効くか。単なる効率化に見えると後回しにされる。
財務・経理：初期と運用の総額、投資回収年数、費用計上の期。予算枠との整合。
情シス・DX責任者：既存システムとの接続、認証・権限・ログ、保守体制、責任分界。
業務部門：例外処理や承認フローが現場で回るか、定着するか。

RFPは、この4者の関心にそれぞれ材料を供給する「元データ」です。目的（1章）は経営、制約と予算（4・5章）は財務、非機能（3章）は情シス、現状と要件（2・3章）は業務部門——というように、RFPの各章が稟議のどのパートを支えるかを意識して書くと、承認プロセス全体が一本の線でつながります。DX・システム開発全体の進め方から整理したい場合は、DX・システム開発の進め方を相談するところから始めると、RFPと稟議資料を同時に設計しやすくなります。

GXO流・発注前チェックリスト（RFP提出前）

RFPを配る前に、次の項目を自己点検してください。1つでも「いいえ」があるなら、その項目が見積のブレか稟議の差し戻しの原因になります。

見積もりの読み方──RFPを出した「後」の勝負

RFPで前提を揃えても、返ってきた見積を読めなければ意味がありません。発注側が特に見るべきは次の3点です。

**1. 工数（人月）の内訳。**総額ではなく、要件定義・設計・実装・テスト・移行・保守の工程別に、誰（役割・単価）が何人月投入されるかを見ます。工程配分が実装偏重で上流（要件定義・テスト）が薄い見積は、後工程での手戻りリスクが高いサインです。

**2. 費目の抜け。**データ移行・ユーザー研修・本番リリース作業・稼働後の初期保守は、見積から漏れやすく、後から追加請求になりがちです。RFPで要求したのに見積に無い項目は、必ず理由を確認します。

3. 追加費用の条件。「仕様変更が発生した場合の単価と算定方法」が契約に明記されているか。ここが空欄のまま契約すると、変更のたびに言い値の追加費用が積み上がります。安い初期見積ほど、この条項が甘いことがあります。

見積の妥当性を自社だけで判断しきれないときは、第三者の目を一度入れる価値があります。特にAI開発案件は工数の相場観が定まりにくく、AI開発の見積もりを第三者の目で診断することで、過大・過小や前提の抜けを発注前に洗い出せます。

よくある失敗パターンと回避策

横にスクロールして確認できます

失敗パターン	何が起きるか	回避策
目的が抽象的	実装段階で迷走・スコープ膨張	目的を定量で書く
スコープ外を書かない	追加費用・見積の水増し	やらないことを明記
非機能要件の抜け	稼働後に性能・保守で不満	IPA 6項目で水準指定
予算非提示	提案規模がバラつく	レンジ＋松竹梅で要求
全機能をMust化	総額が跳ね上がる	Must／Wantを仕分け
提案様式がバラバラ	優劣でなく体裁で選ぶ	共通フォーマット指定
稟議資料が後付け	予算承認が差し戻し	RFPと4点セットを同時整備
最安値で選定	追加費用で結局高くつく	内訳と前提で選ぶ

これらは個別のミスに見えて、根っこは共通しています。RFPを「ベンダー向けの依頼書」としか捉えず、稟議・比較の設計図として作っていない——ここに尽きます。

第三者検証の観点──RFPと見積を客観視する

発注側だけでRFPと見積を完結させると、どうしても自社の思い込みや、付き合いの長いベンダーへの偏りが入ります。次の観点で一度外から検証すると、発注前の判断ミスを減らせます。

要件の抜け漏れ：非機能・移行・研修・保守といった見落とされやすい領域が入っているか。
スコープの妥当性：本当に今回作るべき範囲か、過剰・過小になっていないか。
見積の相場観：工程別の工数配分が、規模に対して現実的か。
ベンダー依存の偏り：特定技術・特定ベンダー前提になっていないか。
稟議の説得力：ROIとリスクが、経営・財務の言葉で説明できているか。

この「第三者の物差し」を持つことが、初めての発注や社内にIT判断力が乏しい状況では特に効きます。

GXOに相談すべきタイミング

次のいずれかに当てはまるなら、RFPを配る前・稟議を上げる前に、外部の整理を挟む価値があります。

RFPの書き方がわからず、最初の一枚が書き出せない
ベンダー各社の見積が数倍違い、どれが妥当か判断できない
経営会議で金額の根拠を問われ、稟議が止まっている
過去にPoC止まり・追加費用・仕様ズレで痛い目を見た
社内にIT判断力が乏しく、発注そのものに不安がある

GXOでは、記事テーマをそのまま提案に変換するのではなく、現場の制約と経営上の目的に分解したうえで、構想整理・RFP作成・ベンダー比較・稟議資料づくり・導入後の運用改善までを段階的に支援します。大切なのは、この記事を読んだ直後に「相談するかどうか」ではなく、「自社では何を、どの順で確認すべきか」「どの段階から外部支援を入れるべきか」が明確になることです。

よくある質問（FAQ）

Q1. RFP作成にどれくらい時間をかけるべきですか？

中規模（数千万円規模）で2〜4週間が目安です。これを短縮すると要件の抜けが増え、見積精度とプロジェクト全体のリスクが上がります。逆に完璧を目指して数か月かけるより、要点（目的・要件・スコープ・評価基準）を固めて出し、質疑で補完するほうが現実的です。

Q2. RFPは何社に送るのが適切ですか？

2〜3社を基本に、多くても3〜5社です。1〜2社では相場感が掴めず、6社以上は比較工数が膨らみ選定が長期化します。同じRFP・同じ質問票・同じ提出様式で出させることが、比較の前提です。

Q3. 予算はRFPに書くべきですか？

原則は明示です。書かないと提案規模がバラつき比較になりません。上限に張り付くのを避けたい場合は、予算レンジを示したうえで松竹梅の3案を求め、イニシャルとランニングを分けた内訳を要求します。

Q4. ベンダーに「RFPが不明確で提案できない」と言われたら？

まず該当箇所を特定し、目的・スコープ・非機能水準のどれが曖昧かを補足します。ただし、補足しても提案できないベンダーは、自社案件とのフィットが低い可能性があります。質疑で各社の理解度を見ること自体が、選定の材料になります。

Q5. 稟議を通すにはRFPのほかに何が必要ですか？

ROI試算書・リスク評価書・ベンダー比較表・契約書ドラフトの4点セットが標準です。RFPが「作るもの」を説明し、この4点が「投資対効果とリスク」を説明します。決裁者ごとに見る所が違うため、経営・財務・情シス・業務それぞれの関心に材料を割り当てるとスムーズです。

Q6. RFPは社内で作るべきか、外部に頼むべきか？

小規模なら社内でも書けますが、中規模以上や初めての発注では、外部の視点を一度入れることを推奨します。特定ベンダーへの偏りや要件の抜けを、発注前に客観視できるためです。

まとめ

システム開発のRFPは、テンプレートの体裁を整えることがゴールではありません。「相見積もりを横並びで比較でき」「稟議・予算承認を一枚で説明できる」状態を作ることが本質です。目的の定量化、スコープ外の明記、IPAの6項目に沿った非機能要件、松竹梅の予算提示、そしてRFPと4点セットの同時整備——この5つを押さえれば、見積のブレと稟議の差し戻しは大きく減らせます。発注前の判断軸を自社で整理しきれない、あるいは見積を第三者の目で検証したいときは、早い段階での相談が失敗回避の近道になります。