--- title: "RFPと要件定義の違いとは？要件の伝え方・記載項目と発注者の準備を解説" url: "https://www.issoh.co.jp/column/details/16294/" published: 2026-08-08 updated: 2026-09-26 categories: ["Webシステム"] publisher: "株式会社一創" --- # RFPと要件定義の違いとは？要件の伝え方・記載項目と発注者の準備を解説 システム開発の発注準備を進めると、RFP（提案依頼書）と要件定義書という2つの文書名が出てきます。どちらも「作りたいシステムの中身を書いた文書」に見えるため、RFPにどこまで書けばよいのか、要件定義には何を残すのかで手が止まりがちです。この2つは、作る時期も主体も読み手も記載の粒度も別物です。この記事では、RFPと要件定義書の役割差を整理したうえで、RFPで要件をどう伝えるかという書き方の型、記載範囲の線引き、記載項目が要件定義へ引き継がれる対応関係、要求定義や要求仕様書との関係、RFP作成前に発注者が揃える準備、準委任と請負に分かれる契約形態、発注者側の工数をどちらに厚く配分すべきかまでを扱います。 ## まとめ｜RFPと要件定義の違いを分ける作成時期と主体と記載の粒度 違いは3点に集約できます。RFPはベンダーと契約する前に発注者が作る文書で、要件定義書は契約した後にベンダーと発注者が一緒に固める成果物です。読み手も違います。RFPの読み手は提案を検討する複数の会社、要件定義書の読み手は実際に設計と実装を担当する技術者です。 記載の粒度が最も混同されます。RFPに書くのは「解決したい業務課題と、守ってほしい制約」まで。画面のレイアウト、帳票の項目、データ項目の型といった実装に近い記述は要件定義へ送ります。この線を引かずにRFPへ画面仕様まで書き込むと、各社の提案が発注者の想定をなぞるだけになり、比較する意味が薄れてしまうでしょう。RFPで要件を伝えるときは、1件ごとに「現状・課題・期待する状態・制約」の4点で書くと、提案の余地を残したまま前提をそろえられます。RFPそのものの定義と記載項目は[RFP（提案依頼書）とは何かを整理した解説](https://www.issoh.co.jp/column/details/15344/)、要件定義という工程の進め方は[要件定義の目的と進め方をまとめた解説](https://www.issoh.co.jp/column/details/12848/)で扱っているため、本記事は2文書の書き分けと受け渡しに絞ります。工数配分の結論を先に書くと、発注者が時間を割くべきなのはRFPの作り込みよりも要件定義への参画のほうです。 ## RFPと要件定義書で変わる作成時期・作成主体・記述の粒度と目的 まず、2つの文書がプロジェクトのどこに置かれるのかを揃えます。ここがずれたまま議論すると、記載範囲の話が噛み合いません。 ### 発注先の選定前に作るRFPと契約締結後に作る要件定義書の時期差 RFPは、発注先がまだ決まっていない段階の文書です。複数のベンダーへ同じ内容を配り、返ってきた提案書と見積書を比べて1社を選ぶために使います。要件定義書は、その選定が終わって契約を交わした後、開発工程の一番手前で作られます。順番にすると、RFI（情報提供依頼）→RFP→提案・見積の受領→ベンダー選定→契約→要件定義→基本設計、という流れですね。RFP作成の時点で発注者が持っているのは、自社の業務課題と予算枠だけ。どの製品を使うか、パッケージを入れるかスクラッチで作るかは、提案を受け取ってから決まります。だからRFPには「決まっていないこと」を決まったように書けません。 ### 発注者が主体のRFPとベンダーが主導する要件定義の作成責任の所在 RFPの作成責任は発注者にあります。社内の要望を集め、情報システム部門や経営層と調整し、優先順位をつけてまとめる作業は外部に代行できません。一方の要件定義は、契約したベンダーが主導し、発注者がヒアリングとレビューと承認で関与する共同作業になります。IPAと経済産業省が公表した[「情報システム・モデル取引・契約書」第二版](https://www.ipa.go.jp/digital/model/model20201222.html)（2020年12月22日公表。2026年9月時点でもIPAの公開ページ上の現行版は第二版）でも、要件定義工程はベンダーが支援しながら発注者が内容を確定させる位置づけで整理されました。ここを「ベンダーが全部やってくれる工程」と誤解すると、後述する手戻りの原因になります。 ### 提案を引き出すRFPと開発範囲を確定させる要件定義書の目的差 RFPの目的は、条件のそろった提案を集めることです。各社が同じ前提で見積もれる状態を作り、金額と実現方式を横並びで比べます。要件定義書の目的は開発範囲の確定です。何を作り何を作らないかを文書で固定し、検収の基準にします。良い文書の条件も変わります。RFPは「提案の自由度を残しつつ、外せない条件は明示されている」状態が良く、要件定義書は「解釈の余地がなく、テストで合否を判定できる」状態が良い。同じ書きぶりで両方をまかなうと、どちらかが破綻します。 ### RFPと要件定義書を作成時期・主体・記載粒度・契約で比べた対応表 ここまでの違いを1枚に整理します。社内で認識を合わせるときは、この対応表をそのまま共有すると話が早く進みます。 | 比較軸 | RFP（提案依頼書） | 要件定義書 | | ------- | --------------- | -------------- | | 作成の時期 | ベンダー選定の前 | 契約締結後の最初の工程 | | 作成の主体 | 発注者 | ベンダー主導・発注者が承認 | | 主な読み手 | 提案する複数のベンダー | 設計と実装の担当者 | | 記載の粒度 | 業務課題・制約・提案依頼事項 | 画面・帳票・データ項目まで | | 分量の目安 | 20〜50ページ程度の例が多い | 100ページを超える例もある | | 契約との関係 | 契約前に配布する依頼文書 | 準委任契約の成果物 | | 確定させるもの | 提案と見積の前提条件 | 開発範囲と検収の判定基準 | 分量の欄に幅があるのは案件規模で振れるためです。基幹系の刷新ほど要件定義書は厚くなりますが、RFPは厚くすればよい文書ではありません。 ## システム開発で混同されやすい要求定義・要求仕様書とRFPの関係整理 RFPと要件定義の間には、要求定義と要求仕様書という用語がさらに挟まります。実務で会話が噛み合わない原因の多くは、この4語の使い分けにあります。 ### 発注者の要望を整理する要求定義とRFPに転記される項目の範囲 要求定義は、発注者側が「何を実現したいか」を整理する作業を指します。要件定義が「要望をシステムが満たすべき条件へ翻訳する」作業なのに対し、要求定義は翻訳前の材料づくりです。実務では、要求＝発注者の言葉、要件＝合意された仕様という使い分けが定着しています。RFPは、この要求定義の結果を外向けに編集した文書だと考えると位置づけが定まります。社内で集めた200件の要望をそのまま貼らず、優先度の高いものを業務課題の形にまとめ直し、提案してほしい事項として並べ替える。この編集作業がRFP作成の実体で、要望リストの生データは要件定義に入ってから改めて棚卸しします。 ### 要求仕様書と要件定義書が指す文書の違いとJIS規格上の位置づけ 要求仕様書は、規格の上では明確な定義を持つ文書です。JIS X 0166:2021（システム及びソフトウェア技術－ライフサイクルプロセス－要求エンジニアリング。ISO/IEC/IEEE 29148:2018に対応するJIS）は、要求に関するプロセスを、要求の獲得・要求の分析・要求の仕様化・要求の妥当性確認という区分で規定しています。この「仕様化」の成果物がソフトウェア要求仕様書にあたります。日本の商習慣で言う要件定義書は、この要求仕様書とほぼ同じ範囲を扱う文書で、呼び名が2系統あるだけです。会話の場では、規格の用語か商習慣の用語かを先に確認しておくと議論のずれを防げます。なお要件定義書のさらに後工程にあたる設計書や仕様書との関係は、[仕様書と設計書と要件定義書の違いを整理した解説](https://www.issoh.co.jp/column/details/13200/)で扱っています。 ### RFI・RFP・RFQと要件定義書を発行順に並べた調達文書の全体像 調達側の文書は目的ごとに3つに分かれます。RFIは情報提供依頼で、市場にどんな解決策があるかを調べる段階の文書。RFPは提案依頼で、解決策と体制と概算費用を提案してもらう段階の文書。RFQは見積依頼で、仕様が固まった前提で金額だけを比べる段階の文書です。要件定義書はこの3つの後ろに位置し、調達文書ではなく開発工程の成果物になります。前例が社内にない基幹系の刷新なら、RFIを挟んでから2〜3カ月かけてRFPを作る進め方が現実的でしょう。3書類の使い分けと発行の流れは[RFI・RFP・RFQの違いと発行の流れを整理した解説](https://www.issoh.co.jp/column/details/2459/)に、返ってきた見積書の読み方と相見積もりの比べ方は[システム開発の見積もりと相見積もりの比較を扱った解説](https://www.issoh.co.jp/column/details/13443/)にまとめています。 ## RFPで要件をどう伝えるか：要求を4点で書く型と記載項目の受け渡し 記載範囲の線引きに入る前に、RFPの中で要件をどういう文の形で書けば提案がそろうのかを先に固めます。書き方の型が決まっていないと、同じ要望でも担当者ごとに粒度がばらつき、線引きの議論が成り立ちません。 ### 要件を現状・課題・期待する状態・制約の4点で書くRFPの記述の型 RFPで要件を伝えるときは、1件の要求を「現状」「課題」「期待する状態」「制約」の4点に分けて書きます。現状は今どう回っているか、課題はそれで何が困っているか、期待する状態は導入後にどうなっていれば成功か、制約は提案側が動かせない条件です。この4点のうち、解決手段を書く欄はどこにもありません。手段はベンダーに提案してもらう部分なので、欄を作らないこと自体が線引きになります。受注業務を例に、4点で書いた場合の記述を並べます。 | 観点 | RFPでの記述例 | 要件定義で詰める内容 | | ------ | ----------------- | ---------- | | 現状 | FAX受注を手入力し日次で転記 | 入力画面と項目の定義 | | 課題 | 転記に1日2時間・誤入力が月20件 | 入力チェックの規則 | | 期待する状態 | 転記作業をなくし誤入力を半減 | 受入テストの合否条件 | | 制約 | 既存の会計システムは残す | 連携方式と電文の仕様 | 表の右列は、RFPには書かない内容です。4点がそろっていれば、ベンダーはOCRで取り込む案、Web受注へ切り替える案、EDIでつなぐ案などを並べて提案できます。期待する状態に「誤入力を半減」と数値を入れておくと、提案の評価軸と要件定義での合否条件が同じ物差しでつながります。数値を書けない要求は、まだ要求定義が終わっていないサインだと考えてください。業務要件と機能要件と非機能要件の区別そのものは[機能要件と非機能要件・業務要件の違いを整理した解説](https://www.issoh.co.jp/column/details/3715/)で扱っています。 ### RFPの記載項目ごとに要件定義で受け取る成果物を対応させた一覧表 RFPに並べる記載項目は、要件定義に入ると別の成果物として受け止められます。どの項目がどこへ流れるかを先に知っておくと、RFPに何を厚く書き、何を薄くしてよいかの見当がつきます。 | RFPの記載項目 | 要件定義での受け皿 | RFPで書く厚さ | | --------- | ------------ | --------- | | 背景と目的 | プロジェクト目標の定義 | 厚く書く | | 対象業務の範囲 | 業務フローと対象外の一覧 | 厚く書く | | 現行システムの構成 | 移行要件と連携要件 | 厚く書く | | 機能への要求 | 機能要件一覧と画面定義 | 4点の型で要点だけ | | 非機能への要求 | 非機能要件の目標値 | 規模と稼働条件まで | | 予算と稼働時期 | 開発計画と段階リリース | 枠を必ず書く | | 発注者側の体制 | 役割分担表と承認ルール | 意思決定者を明記 | | 契約形態と検収 | 検収基準と受入テスト計画 | 方針を1文で示す | 「厚く書く」とした3項目は、提案側が自力で調べられない情報です。逆に機能への要求は、要件定義で機能要件一覧として作り直されるため、RFPで網羅しようとしても二度手間になります。項目ごとの章立てや目次の組み方は[RFPの書き方と章立てサンプルの解説](https://www.issoh.co.jp/column/details/16290/)を参照してください。 ### RFP作成に入る前に発注者が社内で揃えておく資料と合意事項の準備 RFPの品質は、書き始める前の準備でほぼ決まります。社内で次の資料と合意がそろっていない状態で書き始めると、途中で前提が変わり、配布後の質疑応答で答えられない質問が積み上がります。 - 資料：現行システムの構成図、稼働年数、連携先の一覧、データ件数の実測値 - 資料：対象業務の主要な流れ2〜3枚と、業務部門から集めた要望リストの原本 - 合意：対象業務の範囲と対象外にする業務、予算の上限、稼働を希望する時期 - 合意：最終決定者の氏名と、部門間で要望が競合したときの裁定の手順 合意の2行は、RFPの本文に直接書き込む情報になります。予算の上限を社内で決めきれないまま配布すると、各社の提案規模がばらばらになり、比較の土台が崩れます。準備に要する期間は、部門をまたぐ案件なら1〜2カ月を見込んでおくと、RFP作成そのものの期間を圧迫しません。 ## RFPに書く範囲と要件定義に残す範囲を分ける記載レベルの線引き ここからが本題の線引きです。判断の基準は1つ、「提案の余地を消すかどうか」に置きます。 ### RFPには目的と制約を書き画面や項目定義は要件定義に残す基準 RFPに書くのは、達成したい業務の状態と、外せない制約です。「受注入力から出荷指示までの手作業を減らし、1日あたり2時間かかっている転記をなくしたい」は書く。「受注一覧画面に検索条件を7項目つけて、CSVの出力ボタンを右上に置く」は書かない。前者は目的で、後者は解決手段だからです。手段を指定した瞬間、ベンダーは「もっと良い方法がありますが」と言いにくくなります。線を引くときは、その記述を消しても提案を比較できるかを確かめてください。比較できるなら要件定義で詰める内容です。 ### 非機能要件をRFP段階で示す粒度と要件定義で詰める数値の範囲 非機能要件は、RFP段階でも数値を出したほうがよい領域です。同時アクセス数、扱うデータ量、稼働時間帯、許容できる停止時間。この4つは見積金額を左右するため、書かないと各社の前提がばらつきます。「利用者は全国12拠点で計450名、うち同時利用は最大80名」「受注データは月間3万件、5年分を保持」といった水準までは示してください。一方で、応答時間を1秒以内と秒単位で確定させたり、バックアップの世代数を指定したりするのは要件定義の作業です。RFP段階で細かい数値を確定させると、実現方式が決まる前に制約だけが固定され、割高な構成の提案しか集まらなくなります。要件定義で項目を漏れなく詰めるときは、IPAの[非機能要求グレード2018](https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/index.html)が、可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境とエコロジーの6大項目で確認項目を整理しているので、ベンダーと共通の物差しとして使えます。 ### 業務フローと現行システムの情報をRFPに載せる場合の分量目安 現行の情報は、RFPに載せる価値が高い部類です。現行システムの製品名とバージョン、稼働年数、他システムとの連携本数、データ移行の対象件数。これらは提案側が作業量を見積もる材料になり、書かなければ各社が安全側に余裕を積みます。ただし業務フロー図を全業務ぶん添付する必要はありません。対象範囲の主要な流れを2〜3枚に絞り、詳細は要件定義で共有すると伝えてください。50枚の現行フロー図を付けたRFPは、提出期限まで読み込まれないまま提案が返る形で無駄になりがちです。刷新案件で現行情報をどこまで開示するかは[システム刷新のRFPで現行情報の開示範囲と移行要件を扱った解説](https://www.issoh.co.jp/column/details/16400/)で詳しく書いています。 ### RFPに書かず要件定義へ送ってよい項目と送ってはいけない項目 送ってよい項目と、送ると事故になる項目を分けておきます。判断に迷ったときの参照リストとして使ってください。 - 要件定義へ送ってよい：画面レイアウト、帳票の項目定義、データ項目の型と桁、権限マトリクスの詳細、テストケースの設計 - 要件定義へ送ってよい：他システムとの連携の詳細な電文仕様、マスタ整備の手順、移行データのクレンジング方針 - RFPに必ず書く：予算の枠、稼働希望時期、対象業務の範囲、現行システムの構成、発注者側の体制と意思決定者 - RFPに必ず書く：譲れない制約（既存の会計システムを残す、特定の業界規制に準拠する、など）と選定の評価軸 下の2つを要件定義まで持ち越すと、契約後に前提が崩れます。予算枠を示さずに進めた案件で、要件定義の終盤に出た概算が想定の2倍だった、という事態はこのパターンです。 ## RFP記載事項が要件定義工程へ引き継がれる流れと成果物の対応 2つの文書は断絶しているわけではなく、RFPの記述が形を変えて要件定義書へ流れ込みます。対応関係を押さえると、RFPに書く分量の見当がつきます。 ### RFPの提案要求事項がベンダー提案書を経て要件へ変換される順序 RFPに「提案してほしい事項」として並べた項目は、提案書で解決方式として返ってきます。その提案書の内容が契約の前提となり、要件定義で1つずつ具体化されます。Webサイトの制作やリニューアルでの具体化の中身は[Web制作の要件定義で決める項目と進め方](https://www.issoh.co.jp/column/details/16309/)を参照してください。たとえばRFPに「拠点間で在庫を融通できる仕組みを提案してください」と書けば、提案書には「A社のパッケージの在庫引当機能で対応し、拠点マスタを追加する」といった方式が返る。要件定義では、その引当のルールを「どの拠点を優先し、何件まで自動で融通するか」まで詰めます。この連鎖があるため、RFPの提案要求事項を曖昧に書くと、要件定義で詰める土台がないまま議論が始まります。要件定義書に何を書くかという記載項目の側は[要件定義書の記載項目と章立てサンプルの解説](https://www.issoh.co.jp/column/details/12849/)を参照してください。 ### RFPの発行から要件定義書の合意までに発注者側が踏む5つの工程 発注者が実際に手を動かす順序を並べます。ここに自社の担当者名と期日を入れれば、そのままプロジェクト計画の骨格になります。 1. 社内の要望を集めて優先順位をつけ、業務課題と予算枠の形にまとめる 2. RFPを作成し、3〜5社へ配布して質疑応答の期間を設ける 3. 提案書と見積書を評価軸に沿って採点し、1社を選定して契約を交わす 4. 要件定義のヒアリングに業務部門を出し、決めきれない論点を社内で確定させる 5. 要件定義書をレビューして承認し、開発範囲と検収の基準として固定する 4番目で止まるプロジェクトが多くあります。ベンダーからの質問に社内で答えが出ず、要件定義が延びるパターンですね。短縮したいなら、1番目の段階で「誰が最終決定するか」を決めておくしかありません。 ### RFPの記述が曖昧なまま要件定義に入った案件で膨らむ追加費用 費用が膨らむ典型は、対象業務の範囲をRFPで区切らなかった場合です。「販売管理を刷新したい」とだけ書いたRFPに対し、ベンダーは受注・出荷・請求までを想定して見積もる。ところが要件定義で「仕入と在庫も同時に直したい」という要望が出ると、当初の前提が変わり追加見積もりになります。追加分の交渉は、契約後で選択肢が狭まった状態で行うことになります。要件定義の途中で他社へ乗り換えるのは現実的ではありません。範囲の記述にかける労力は、後の交渉力に直結します。 ## RFPと要件定義で変わる契約形態と発注者側が負う実務作業の分担 文書の違いは契約の形にも表れます。ここを知らずに一括請負で契約すると、要件定義の進め方でもめる原因になります。 ### 要件定義工程を準委任で契約し開発工程を請負で分ける実務上の理由 要件定義は、始める時点で成果物の中身が確定していない工程です。何をどこまで決めるかは議論の結果で変わるため、仕事の完成を約束する請負契約とは相性が悪く、IPAと経済産業省の「情報システム・モデル取引・契約書」第二版では、要件定義工程を準委任型で契約し、設計以降を請負で結ぶ多段階契約の整理が示されています。2020年4月1日に施行された改正民法では、準委任に「成果完成型」が明文化され、成果物の引き渡しに対して報酬を支払う形も選べるようになりました。同じ改正で、旧来の瑕疵担保責任は契約不適合責任へ整理されています。要件定義だけを先に契約し、その結果を見て開発の契約を結ぶ進め方は、要件が固まらないうちに総額を確定させるより発注者側の損失を小さくできる方法です。準委任と請負の違いそのものは[準委任契約と請負・派遣の違いを整理した解説](https://www.issoh.co.jp/column/details/13187/)で扱っています。 ### 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作成・PMO支援の相談窓口](https://www.issoh.co.jp/service/system/pmo/)で現行業務の整理段階から扱っています。 ### 発注者の工数をRFP作成と要件定義参画へ配分するときの優先順 限られた社内工数をどちらへ寄せるか、という判断では要件定義への参画を優先します。理由は3つ。RFPの品質不足は提案の粒度が粗くなる形で表れ、質疑応答の期間で補正できます。要件定義への参画不足は、決まらない論点が設計へ持ち越される形で表れ、後から補正できません。そして要件定義で確定した内容は検収の判定基準になるため、ここでの判断ミスは納品物そのものに残ります。配分の目安を出すなら、RFP作成に社内工数の3割、要件定義への参画に7割です。RFPを完璧に仕上げてから力尽き、要件定義のヒアリングに担当者を出せなかった案件は、ほぼ確実に設計工程で止まります。ページ数の多いRFPが良いRFPだという前提は、いったん捨ててください。 ## よくある質問 RFPと要件定義の書き分けについて、発注準備の場でよく挙がる質問に答えます。 ### RFPと要件定義書は同じ内容を書いてもよいのですか？ 重なる項目はありますが、粒度を変えてください。対象業務の範囲や非機能の水準はどちらにも登場します。RFPでは「同時利用80名、月間受注3万件」という規模の提示にとどめ、要件定義書では応答時間の目標値やピーク時の処理方式まで踏み込んでください。RFPの文章をそのまま要件定義書へ転記すると、検収の判定ができない粒度の要件が残ります。 ### 要求定義と要件定義はどう違うのですか？ 要求定義は発注者が「何を実現したいか」を整理する作業、要件定義はそれをシステムが満たすべき条件へ翻訳して合意する作業です。要求は発注者の言葉のまま、要件はテストで合否を判定できる形で書きます。JIS X 0166:2021では、要求の獲得から分析、仕様化、妥当性確認までを一連のプロセスとして規定しており、この流れの前半が要求定義、後半が要件定義に相当します。 ### RFPを作らずに要件定義から始めても問題ありませんか？ 発注先が1社に決まっており、対象業務が限定的で、予算規模が小さい案件なら成立します。複数社の比較が前提の案件では避けてください。RFPなしで相見積もりを取ると、各社が別々の前提で見積もるため、金額の比較が成立しません。判断の分かれ目は「比較する必要があるか」の1点です。 ### RFPに載せる要件はどこまで詳しく書けばよいですか？ 解決したい業務課題と、外せない制約までです。1件ごとに現状・課題・期待する状態・制約の4点で書き、解決手段は書かないのが目安になります。その記述を消しても各社の提案を比較できるなら、要件定義へ送ってよい内容だと判断してください。画面レイアウト、帳票の項目定義、データ項目の型といった実装に近い記述は、RFPに入れると提案の幅を狭めます。現行システムの構成やデータ量など、見積もりの材料になる情報は逆に厚く書いてください。 ### 要件定義書はベンダーと発注者のどちらが作成するのですか？ 文書化はベンダーが担い、内容の確定と承認は発注者が行うのが一般的な分担です。IPAと経済産業省の「情報システム・モデル取引・契約書」第二版も、ベンダーの支援を受けながら発注者が内容を確定させる整理です。丸投げすると業務の例外処理がベンダーの推測で埋められ、受け入れテストで食い違いが表面化します。 ## 関連記事 - [RFPとは？提案依頼書の意味・目的・記載項目を発注者視点で解説](https://www.issoh.co.jp/column/details/15344/)：RFPの定義と記載項目の確認に - [RFPの書き方とは？記載項目・章立てサンプルと作成手順を発注者目線で解説](https://www.issoh.co.jp/column/details/16290/)：章立てを組み立てる段階に - [要件定義とは？目的・進め方・成果物と失敗を防ぐポイントを解説](https://www.issoh.co.jp/column/details/12848/)：要件定義工程の進め方と成果物 - [要件定義書の書き方とは？記載項目・章立てサンプル・作成のコツを解説](https://www.issoh.co.jp/column/details/12849/)：要件定義書の記載項目の確認に - [ホームページ制作のRFPとは？記載項目・コンペの進め方と発注判断を解説](https://www.issoh.co.jp/column/details/16292/)：Web制作案件に固有の記載項目 --- 出典: [RFPと要件定義の違いとは？要件の伝え方・記載項目と発注者の準備を解説]()（株式会社一創）