要件定義とRFP、違いが分からない問題を整理

「まずはRFPを作ってください」と言われて、要件定義書とは何が違うのか分からないまま、見よう見まねで書類を作った経験はないでしょうか。どちらも「開発会社に自分たちの要望を伝えるための資料」という点では似ているため、現場責任者の間でもしばしば混同されます。

実はこの二つ、作る目的もタイミングも、本来はまったく別物です。「誰向けの、何のための資料か」という軸で整理すると、どちらを先に作るべきかも自然に見えてきます。

この記事を読むと、要件定義書とRFPの役割の違いと、どちらを欠いたまま発注を進めると何が起きやすいかが分かります。

要件定義書とRFP、何が違うのか

RFP（Request for Proposal＝提案依頼書）は、複数の開発会社に対して「こういう課題を解決したいので、提案をください」と呼びかけるための資料です。目的は、各社から提案と見積もりを引き出し、比較検討すること。つまり発注先を選ぶ前の段階で使う資料です。

一方、要件定義書は「システムに何をさせたいか」を具体的に書き出したもので、発注先が決まった後、実際の開発に入る前に、発注側と開発会社がすり合わせながら作り込んでいくものです。RFPが「候補を比較するための呼びかけ」だとすれば、要件定義書は「決まった相手と交わす詳細な約束事」に近い性質を持ちます。

このように整理すると分かりやすいのですが、実務ではこの順番が曖昧なまま進んでしまうケースが少なくありません。RFPの段階で「要件定義書並みの細かさ」を求められて疲弊したり、逆に「RFPがないまま」いきなり要件定義の打ち合わせに呼ばれて戸惑ったりする、という声もよく聞きます。

なぜ両者が混同されやすいのか

混同が起きる理由の一つは、どちらの資料にも「やりたいこと」「実現したい機能」といった似た項目が並ぶためです。中小企業庁がまとめている中小企業白書では、IT・デジタル化に取り組む際にまず自社の経営課題や業務課題を整理すること自体に難しさがあると触れられています。課題の言語化が難しい状態で資料を作ろうとすると、RFPなのか要件定義書なのか、作成者自身も境界があいまいなまま書き進めてしまうのです。

もう一つの理由は、社内にRFPや要件定義書を専門に扱う人材がいない場合、「とりあえず開発会社に希望を伝える資料」という1つの括りで考えてしまいがちなことです。発注経験が浅いほど、この二つを別工程と捉える発想自体が生まれにくく、結果として「RFPのつもりで書いたものが、そのまま要件定義書として扱われてしまう」という事態が起きやすくなります。ここは、次に資料を作る前に一度立ち止まって確認しておきたいところです。

混同したまま進めると何が起きるか

RFPの段階の粗い情報のまま契約が進んでしまうと、後になって「思っていたことと違う」という認識のズレが表面化しやすくなります。RFPはあくまで「大まかな方向性を伝えて比較するための資料」であり、実装に必要な細部までは決まっていません。その粗さを残したまま契約に進み、要件定義というすり合わせの工程を省略、あるいは簡略化してしまうと、開発が始まってから仕様の抜け漏れが次々と見つかるという状況を招きやすくなります。

RFPの段階の情報量で契約を決めてしまうことが、後工程での仕様の手戻りや追加費用につながりやすいという構造は、押さえておきたいところです。要件定義書が「あの人頼み」になりがちな属人化の問題についても、要件定義書が「あの人頼み」になる属人化の罠で扱っていますが、そもそもRFPと要件定義書を別工程として認識していないと、属人化以前に「誰が何を詳しく詰めるべきか」自体が宙に浮いてしまいます。

発注側として意識しておきたいこと

RFPと要件定義書を別の工程として切り分けて考えるだけでも、混乱はかなり減らせます。具体的には次のような視点を持っておくと整理しやすくなります。

• RFPの段階では「何を解決したいか」までで十分：画面の細かい仕様や項目まで詰め込もうとしなくてよい
• RFPへの回答は「比較材料」であって「確定見積もり」ではない：各社の提案を比較した後、選定した1社と要件定義を進める中で金額が変わる前提で考える
• 要件定義は契約後の共同作業と捉える：発注側が一方的に「仕様書」を用意する工程ではなく、開発会社と一緒に詰めていくものとして臨む

この整理をしておくと、開発会社から「要件定義をお願いします」と言われたときに、何を準備すればいいかが見えやすくなります。

まとめ

• RFPは発注先を選ぶための比較資料、要件定義書は決まった相手と交わす詳細な約束事という違いがある
• 両者が混同されやすいのは、課題の言語化自体が難しく、社内に二つを区別する発想が育ちにくいため
• RFPの粗さを残したまま契約を進めると、後工程での仕様の手戻りにつながりやすい