RFPと要件定義の違いとは？書き分ける範囲と発注者の作業分担を解説

システム開発の発注準備を進めると、RFP（提案依頼書）と要件定義書という2つの文書名が出てきます。どちらも「作りたいシステムの中身を書いた文書」に見えるため、RFPにどこまで書けばよいのか、要件定義には何を残すのかで手が止まりがちです。この2つは、作る時期も主体も読み手も記載の粒度も別物です。この記事では、RFPと要件定義書の役割差を整理したうえで、記載範囲の線引き、要求定義や要求仕様書との関係、準委任と請負に分かれる契約形態、発注者側の工数をどちらに厚く配分すべきかまでを扱います。

まとめ｜RFPと要件定義の違いを分ける作成時期と主体と記載の粒度

違いは3点に集約できます。RFPはベンダーと契約する前に発注者が作る文書で、要件定義書は契約した後にベンダーと発注者が一緒に固める成果物です。読み手も違います。RFPの読み手は提案を検討する複数の会社、要件定義書の読み手は実際に設計と実装を担当する技術者です。

記載の粒度が最も混同されます。RFPに書くのは「解決したい業務課題と、守ってほしい制約」まで。画面のレイアウト、帳票の項目、データ項目の型といった実装に近い記述は要件定義へ送ります。この線を引かずにRFPへ画面仕様まで書き込むと、各社の提案が発注者の想定をなぞるだけになり、比較する意味が薄れてしまうでしょう。RFPそのものの定義と記載項目はRFP（提案依頼書）とは何かを整理した解説、要件定義という工程の進め方は要件定義の目的と進め方をまとめた解説で扱っているため、本記事は2文書の書き分けに絞ります。工数配分の結論を先に書くと、発注者が時間を割くべきなのはRFPの作り込みよりも要件定義への参画のほうです。

RFPと要件定義書で変わる作成時期・作成主体・記述の粒度と目的

まず、2つの文書がプロジェクトのどこに置かれるのかを揃えます。ここがずれたまま議論すると、記載範囲の話が噛み合いません。

発注先の選定前に作るRFPと契約締結後に作る要件定義書の時期差

RFPは、発注先がまだ決まっていない段階の文書です。複数のベンダーへ同じ内容を配り、返ってきた提案書と見積書を比べて1社を選ぶために使います。要件定義書は、その選定が終わって契約を交わした後、開発工程の一番手前で作られます。順番にすると、RFI（情報提供依頼）→RFP→提案・見積の受領→ベンダー選定→契約→要件定義→基本設計、という流れですね。RFP作成の時点で発注者が持っているのは、自社の業務課題と予算枠だけ。どの製品を使うか、パッケージを入れるかスクラッチで作るかは、提案を受け取ってから決まります。だからRFPには「決まっていないこと」を決まったように書けません。

発注者が主体のRFPとベンダーが主導する要件定義の作成責任の所在

RFPの作成責任は発注者にあります。社内の要望を集め、情報システム部門や経営層と調整し、優先順位をつけてまとめる作業は外部に代行できません。一方の要件定義は、契約したベンダーが主導し、発注者がヒアリングとレビューと承認で関与する共同作業になります。IPAと経済産業省が公表した「情報システム・モデル取引・契約書」第二版（2020年12月22日公表）でも、要件定義工程はベンダーが支援しながら発注者が内容を確定させる位置づけで整理されました。ここを「ベンダーが全部やってくれる工程」と誤解すると、後述する手戻りの原因になります。

提案を引き出すRFPと開発範囲を確定させる要件定義書の目的差

RFPの目的は、条件のそろった提案を集めることです。各社が同じ前提で見積もれる状態を作り、金額と実現方式を横並びで比べます。要件定義書の目的は開発範囲の確定です。何を作り何を作らないかを文書で固定し、検収の基準にします。良い文書の条件も変わります。RFPは「提案の自由度を残しつつ、外せない条件は明示されている」状態が良く、要件定義書は「解釈の余地がなく、テストで合否を判定できる」状態が良い。同じ書きぶりで両方をまかなうと、どちらかが破綻します。

RFPと要件定義書を作成時期・主体・記載粒度・契約で比べた対応表

ここまでの違いを1枚に整理します。社内で認識を合わせるときは、この対応表をそのまま共有すると話が早く進みます。

分量の欄に幅があるのは案件規模で振れるためです。基幹系の刷新ほど要件定義書は厚くなりますが、RFPは厚くすればよい文書ではありません。

システム開発で混同されやすい要求定義・要求仕様書とRFPの関係整理

RFPと要件定義の間には、要求定義と要求仕様書という用語がさらに挟まります。実務で会話が噛み合わない原因の多くは、この4語の使い分けにあります。

発注者の要望を整理する要求定義とRFPに転記される項目の範囲

要求定義は、発注者側が「何を実現したいか」を整理する作業を指します。要件定義が「要望をシステムが満たすべき条件へ翻訳する」作業なのに対し、要求定義は翻訳前の材料づくりです。実務では、要求＝発注者の言葉、要件＝合意された仕様という使い分けが定着しています。RFPは、この要求定義の結果を外向けに編集した文書だと考えると位置づけが定まります。社内で集めた200件の要望をそのまま貼らず、優先度の高いものを業務課題の形にまとめ直し、提案してほしい事項として並べ替える。この編集作業がRFP作成の実体で、要望リストの生データは要件定義に入ってから改めて棚卸しします。

要求仕様書と要件定義書が指す文書の違いとJIS規格上の位置づけ

要求仕様書は、規格の上では明確な定義を持つ文書です。JIS X 0166:2021（システム及びソフトウェア技術－ライフサイクルプロセス－要求エンジニアリング。ISO/IEC/IEEE 29148:2018に対応するJIS）は、要求に関するプロセスを、要求の獲得・要求の分析・要求の仕様化・要求の妥当性確認という区分で規定しています。この「仕様化」の成果物がソフトウェア要求仕様書にあたります。日本の商習慣で言う要件定義書は、この要求仕様書とほぼ同じ範囲を扱う文書で、呼び名が2系統あるだけです。会話の場では、規格の用語か商習慣の用語かを先に確認しておくと議論のずれを防げます。なお要件定義書のさらに後工程にあたる設計書や仕様書との関係は、仕様書と設計書と要件定義書の違いを整理した解説で扱っています。

RFI・RFP・RFQと要件定義書を発行順に並べた調達文書の全体像

調達側の文書は目的ごとに3つに分かれます。RFIは情報提供依頼で、市場にどんな解決策があるかを調べる段階の文書。RFPは提案依頼で、解決策と体制と概算費用を提案してもらう段階の文書。RFQは見積依頼で、仕様が固まった前提で金額だけを比べる段階の文書です。要件定義書はこの3つの後ろに位置し、調達文書ではなく開発工程の成果物になります。前例が社内にない基幹系の刷新なら、RFIを挟んでから2〜3カ月かけてRFPを作る進め方が現実的でしょう。3書類の使い分けと発行の流れはRFI・RFP・RFQの違いと発行の流れを整理した解説にまとめています。

RFPに書く範囲と要件定義に残す範囲を分ける記載レベルの線引き

ここからが本題の線引きです。判断の基準は1つ、「提案の余地を消すかどうか」に置きます。

RFPには目的と制約を書き画面や項目定義は要件定義に残す基準

RFPに書くのは、達成したい業務の状態と、外せない制約です。「受注入力から出荷指示までの手作業を減らし、1日あたり2時間かかっている転記をなくしたい」は書く。「受注一覧画面に検索条件を7項目つけて、CSVの出力ボタンを右上に置く」は書かない。前者は目的で、後者は解決手段だからです。手段を指定した瞬間、ベンダーは「もっと良い方法がありますが」と言いにくくなります。線を引くときは、その記述を消しても提案を比較できるかを確かめてください。比較できるなら要件定義で詰める内容です。RFPの章立てや各項目の書きぶりそのものはRFPの書き方と章立てサンプルの解説で扱っています。

非機能要件をRFP段階で示す粒度と要件定義で詰める数値の範囲

非機能要件は、RFP段階でも数値を出したほうがよい領域です。同時アクセス数、扱うデータ量、稼働時間帯、許容できる停止時間。この4つは見積金額を左右するため、書かないと各社の前提がばらつきます。「利用者は全国12拠点で計450名、うち同時利用は最大80名」「受注データは月間3万件、5年分を保持」といった水準までは示してください。一方で、応答時間を1秒以内と秒単位で確定させたり、バックアップの世代数を指定したりするのは要件定義の作業です。RFP段階で細かい数値を確定させると、実現方式が決まる前に制約だけが固定され、割高な構成の提案しか集まらなくなります。

業務フローと現行システムの情報をRFPに載せる場合の分量目安

現行の情報は、RFPに載せる価値が高い部類です。現行システムの製品名とバージョン、稼働年数、他システムとの連携本数、データ移行の対象件数。これらは提案側が作業量を見積もる材料になり、書かなければ各社が安全側に余裕を積みます。ただし業務フロー図を全業務ぶん添付する必要はありません。対象範囲の主要な流れを2〜3枚に絞り、詳細は要件定義で共有すると伝えてください。50枚の現行フロー図を付けたRFPは、提出期限まで読み込まれないまま提案が返る形で無駄になりがちです。

RFPに書かず要件定義へ送ってよい項目と送ってはいけない項目

送ってよい項目と、送ると事故になる項目を分けておきます。判断に迷ったときの参照リストとして使ってください。

• 要件定義へ送ってよい：画面レイアウト、帳票の項目定義、データ項目の型と桁、権限マトリクスの詳細、テストケースの設計
• 要件定義へ送ってよい：他システムとの連携の詳細な電文仕様、マスタ整備の手順、移行データのクレンジング方針
• RFPに必ず書く：予算の枠、稼働希望時期、対象業務の範囲、現行システムの構成、発注者側の体制と意思決定者
• RFPに必ず書く：譲れない制約（既存の会計システムを残す、特定の業界規制に準拠する、など）と選定の評価軸

下の2つを要件定義まで持ち越すと、契約後に前提が崩れます。予算枠を示さずに進めた案件で、要件定義の終盤に出た概算が想定の2倍だった、という事態はこのパターンです。

RFP記載事項が要件定義工程へ引き継がれる流れと成果物の対応

2つの文書は断絶しているわけではなく、RFPの記述が形を変えて要件定義書へ流れ込みます。対応関係を押さえると、RFPに書く分量の見当がつきます。

RFPの提案要求事項がベンダー提案書を経て要件へ変換される順序

RFPに「提案してほしい事項」として並べた項目は、提案書で解決方式として返ってきます。その提案書の内容が契約の前提となり、要件定義で1つずつ具体化されます。たとえばRFPに「拠点間で在庫を融通できる仕組みを提案してください」と書けば、提案書には「A社のパッケージの在庫引当機能で対応し、拠点マスタを追加する」といった方式が返る。要件定義では、その引当のルールを「どの拠点を優先し、何件まで自動で融通するか」まで詰めます。この連鎖があるため、RFPの提案要求事項を曖昧に書くと、要件定義で詰める土台がないまま議論が始まります。要件定義書に何を書くかという記載項目の側は要件定義書の記載項目と章立てサンプルの解説を参照してください。

RFPの発行から要件定義書の合意までに発注者側が踏む5つの工程

発注者が実際に手を動かす順序を並べます。ここに自社の担当者名と期日を入れれば、そのままプロジェクト計画の骨格になります。

1. 社内の要望を集めて優先順位をつけ、業務課題と予算枠の形にまとめる
2. RFPを作成し、3〜5社へ配布して質疑応答の期間を設ける
3. 提案書と見積書を評価軸に沿って採点し、1社を選定して契約を交わす
4. 要件定義のヒアリングに業務部門を出し、決めきれない論点を社内で確定させる
5. 要件定義書をレビューして承認し、開発範囲と検収の基準として固定する

4番目で止まるプロジェクトが多くあります。ベンダーからの質問に社内で答えが出ず、要件定義が延びるパターンですね。短縮したいなら、1番目の段階で「誰が最終決定するか」を決めておくしかありません。

RFPの記述が曖昧なまま要件定義に入った案件で膨らむ追加費用

費用が膨らむ典型は、対象業務の範囲をRFPで区切らなかった場合です。「販売管理を刷新したい」とだけ書いたRFPに対し、ベンダーは受注・出荷・請求までを想定して見積もる。ところが要件定義で「仕入と在庫も同時に直したい」という要望が出ると、当初の前提が変わり追加見積もりになります。追加分の交渉は、契約後で選択肢が狭まった状態で行うことになります。要件定義の途中で他社へ乗り換えるのは現実的ではありません。範囲の記述にかける労力は、後の交渉力に直結します。

RFPと要件定義で変わる契約形態と発注者側が負う実務作業の分担

文書の違いは契約の形にも表れます。ここを知らずに一括請負で契約すると、要件定義の進め方でもめる原因になります。

要件定義工程を準委任で契約し開発工程を請負で分ける実務上の理由

要件定義は、始める時点で成果物の中身が確定していない工程です。何をどこまで決めるかは議論の結果で変わるため、仕事の完成を約束する請負契約とは相性が悪く、IPAと経済産業省の「情報システム・モデル取引・契約書」第二版では、要件定義工程を準委任型で契約し、設計以降を請負で結ぶ多段階契約の整理が示されています。2020年4月1日に施行された改正民法では、準委任に「成果完成型」が明文化され、成果物の引き渡しに対して報酬を支払う形も選べるようになりました。同じ改正で、旧来の瑕疵担保責任は契約不適合責任へ整理されています。要件定義だけを先に契約し、その結果を見て開発の契約を結ぶ進め方は、要件が固まらないうちに総額を確定させるより発注者側の損失が小さくなります。

RFP段階で契約形態と検収条件を明示しておく場合の記載の仕方

契約の話は、RFPに書いておいて構いません。むしろ書いたほうが提案の精度が上がります。「要件定義工程は準委任契約を想定し、その完了後に開発工程の契約を別途締結する」と方針を示せば、各社は要件定義の工数と金額を分けて提示するはずです。検収についても「要件定義書に記載した機能要件と非機能要件の充足をもって判定する」と一文入れておくと、後の解釈のずれを減らせます。契約形態を書かないまま一括の総額だけを求めると、見えない部分のリスクを織り込んだ金額が返ってきます。

要件定義に発注者が出す人員と意思決定者の関与時間の見積もり方

要件定義は、発注者側にも実務の負荷がかかる工程です。業務部門の担当者はヒアリングとレビューに出席し、現行の運用を説明し、例外処理の扱いを判断します。3カ月の要件定義であれば、対象業務ごとに担当者1名が週に半日から1日を割く前提で計画を立てると現実に近くなります。意思決定者の時間も確保してください。部門間で要望が競合したときに裁定する人が不在だと、要件定義書の該当箇所が「継続検討」のまま設計工程へ持ち越され、後工程になるほど変更の費用が上がります。人を出せない時期にプロジェクトを始めない、という判断も選択肢に入れるべきです。

RFPを詳細に書き込みすぎた案件で要件定義が手戻りする条件と対処

ここからは、対比表では見えない実務上の判断を書きます。結論から言うと、RFPの作り込みには「効きすぎて逆効果になる水準」があります。

RFPに画面仕様まで書き込むと提案の幅が消える具体的な失敗例

RFPに画面イメージと項目一覧を添付した案件では、返ってくる提案が3社ともほぼ同じ構成になります。各社が添付資料をなぞって見積もるためです。比較できるのは金額だけになり、提案を求めた意味が失われます。まずいのは、その画面設計が既存の業務のやり方を前提にしている場合。パッケージの標準機能で代替できる部分まで作り込む前提の見積もりが返り、追加開発の費用が乗ります。要件定義に入ってから「この画面は標準機能で足ります」と指摘されて設計をやり直すなら、RFPに書いた工数はそのまま無駄になるでしょう。この失敗は、業務部門が「今の帳票と同じものを」と要望した案件で繰り返し起きます。書くべきは帳票の見た目ではなく、それで誰が何を判断しているかです。

RFPを簡易にして要件定義で詰める進め方を採用してよい3条件

RFPを薄くして先へ進む判断が成り立つ場面もあります。次の3つがそろうなら、RFPの作り込みより要件定義へ工数を寄せてください。第1に、発注先が実質的に決まっている場合。既存ベンダーへの追加開発や、過去に取引のある1社への発注では、比較のための文書は不要です。第2に、対象業務が1部門に閉じ、関係者が10名以下の場合。前提の共有コストが低く、口頭とメモで足ります。第3に、予算規模が数百万円台にとどまる場合。RFP作成に2カ月かけると、その社内工数のほうが案件規模に見合いません。逆に、部門をまたぐ基幹系の刷新で複数社の比較が要り、予算が数千万円を超えるなら、RFPを省く選択は取らないでください。前提をそろえずに始めれば、要件定義の途中で範囲が膨らみます。業務システムの発注準備そのものを外部と進めたい場合は、基幹システム開発の相談窓口で現行業務の整理段階から扱っています。

発注者の工数をRFP作成と要件定義参画へ配分するときの優先順

限られた社内工数をどちらへ寄せるか、という判断では要件定義への参画を優先します。理由は3つ。RFPの品質不足は提案の粒度が粗くなる形で表れ、質疑応答の期間で補正できます。要件定義への参画不足は、決まらない論点が設計へ持ち越される形で表れ、後から補正できません。そして要件定義で確定した内容は検収の判定基準になるため、ここでの判断ミスは納品物そのものに残ります。配分の目安を出すなら、RFP作成に社内工数の3割、要件定義への参画に7割です。RFPを完璧に仕上げてから力尽き、要件定義のヒアリングに担当者を出せなかった案件は、ほぼ確実に設計工程で止まります。ページ数の多いRFPが良いRFPだという前提は、いったん捨ててください。

よくある質問

RFPと要件定義の書き分けについて、発注準備の場でよく挙がる質問に答えます。

RFPと要件定義書は同じ内容を書いてもよいのですか？

重なる項目はありますが、粒度を変えてください。対象業務の範囲や非機能の水準はどちらにも登場します。RFPでは「同時利用80名、月間受注3万件」という規模の提示にとどめ、要件定義書では応答時間の目標値やピーク時の処理方式まで踏み込んでください。RFPの文章をそのまま要件定義書へ転記すると、検収の判定ができない粒度の要件が残ります。

要求定義と要件定義はどう違うのですか？

要求定義は発注者が「何を実現したいか」を整理する作業、要件定義はそれをシステムが満たすべき条件へ翻訳して合意する作業です。要求は発注者の言葉のまま、要件はテストで合否を判定できる形で書きます。JIS X 0166:2021では、要求の獲得から分析、仕様化、妥当性確認までを一連のプロセスとして規定しており、この流れの前半が要求定義、後半が要件定義に相当します。

RFPを作らずに要件定義から始めても問題ありませんか？

発注先が1社に決まっており、対象業務が限定的で、予算規模が小さい案件なら成立します。複数社の比較が前提の案件では避けてください。RFPなしで相見積もりを取ると、各社が別々の前提で見積もるため、金額の比較が成立しません。判断の分かれ目は「比較する必要があるか」の1点です。

RFPに載せる要件はどこまで詳しく書けばよいですか？

解決したい業務課題と、外せない制約までです。目安として、その記述を消しても各社の提案を比較できるなら、要件定義へ送ってよい内容だと判断してください。画面レイアウト、帳票の項目定義、データ項目の型といった実装に近い記述は、RFPに入れると提案の幅を狭めます。現行システムの構成やデータ量など、見積もりの材料になる情報は逆に厚く書いてください。

要件定義書はベンダーと発注者のどちらが作成するのですか？

文書化はベンダーが担い、内容の確定と承認は発注者が行うのが一般的な分担です。IPAと経済産業省の「情報システム・モデル取引・契約書」第二版も、ベンダーの支援を受けながら発注者が内容を確定させる整理です。丸投げすると業務の例外処理がベンダーの推測で埋められ、受け入れテストで食い違いが表面化します。

関連記事

• RFPとは？提案依頼書の意味・目的・記載項目を発注者視点で解説：RFPの定義と記載項目の確認に
• RFPの書き方とは？記載項目・章立てサンプルと作成手順を発注者目線で解説：章立てを組み立てる段階に
• 要件定義とは？目的・進め方・成果物と失敗を防ぐポイントを解説：要件定義工程の進め方と成果物
• 要件定義書の書き方とは？記載項目・章立てサンプル・作成のコツを解説：要件定義書の記載項目の確認に
• ホームページ制作のRFPとは？記載項目・コンペの進め方と発注判断を解説：Web制作案件に固有の記載項目