RFP（提案依頼書）と要件定義書の違いは何？ 記載内容も詳しく解説

こんにちは、ジーピーオンラインのキタです！
発注元企業がシステム開発などを外注し、システムの導入を進める最初の工程で作成される文書に、RFP（提案依頼書）、要件定義書、要求定義書などがあります。システム開発を経験したことがある人にとっても、これらの違いがよくわからない、という人はいるのではないでしょうか。
Web制作の現場でも使われることがある書類のため、今回はこれら3つの仕様書の違いについて解説し、RFPおよび要件定義書の作成方法をご紹介します。
最後に要件定義に対する当社の捉え方もご紹介していますのでぜひお読みください。

ジーピーオンラインにWebサイト制作・システム開発の相談をする

RFP、要件定義書、要求定義書の違いとは

それでは、RFPと要件定義書、要求定義書の違いを詳しく説明していきます。

RFP（提案依頼書）とは

RFP（提案依頼書）は、システム開発やWebサイト構築などを企画する際に、発注側企業の担当者が作成する、開発・制作側に対して具体的な提案を依頼するための文書です。プロジェクトの目的や概要、要件や制約などを記載し、これからどういうWebサイト制作・システム構築を依頼したいのか、全体がイメージできるような内容を記載します。

RFPを作成することで、発注側企業は自社システムやWebサイトの現状および課題を把握することができ、要件を明確にした上で開発側に正しく伝えられます。RFPを作成せず、要件や課題が曖昧なまま開発・制作側に対して説明を始めてしまうと、開発・制作側へ要件が正しく伝わりません。
特に複数社へのコンペ依頼や相見積もりをする場合に必要となってくる書類です。

要件定義書とは

要件定義とは、開発・制作側がおこなう作業で、発注側がどういうシステム構築またはWebサイト制作をしたいか要件や要望、現状の課題を明確にし、目的達成するためにおこなうべき内容を明らかにすることです。この作業の成果物として作成する文書が要件定義書です。

要件定義の主な目的は、発注側と開発・制作側の間で明確な認識合わせをおこなうことです。要件定義書をきちんと作成することにより、発注側の要求を関連部署間で共有しやすくなるばかりでなく、開発側でも開発担当間で認識齟齬が生まれにくくなります。要件定義が正しくおこなわれず、あいまいな部分を残してしまうと、開発・制作側で主観的な判断による作業がおこなわれてしまうケースもあります。これにより発注側との認識齟齬が生まれ、要件や要望にあったシステム開発やWebサイト制作を実現できなくなる場合があります。

要求定義書とは

要求定義とは、発注側が現状の問題や課題に対してシステム開発によってそれらをどう解決していくかを明確にする作業のことです。この作業の結果、これから開発するシステムに求める仕様、およびシステム開発の中で開発・制作側に対して依頼する内容が明確になります。この成果物が要求定義書であり、システム開発における指示書的な役割の位置づけとなります。

要求定義書の内容は、具体的には、システムにおける細かな仕様や機能、費用面や開発スケジュールなどが含まれます。Webサイト制作の現場ではWebシステムを開発する場合に作成されることが多い書類で、要求定義書を元に機能一覧や詳細設計、テスト設計書などを作成していきます。

まとめると、RFP、要件定義書、要求定義書の違いは以下の通りです。
RFP（提案依頼書）は、発注側が作成し、開発・制作側に対して具体的な提案を依頼するための文書です。システムやWebサイトの背景や目的・目標および制約など、これから構築するシステムやWebサイトの全体がイメージできるような内容を記載します。

要件定義書は、開発・制作側が作成し、発注側からの要件や要望、目的達成するためにおこなうべき内容をまとめた文書です。この内容をもとに具体的なシステムやWebサイトの設計・開発がおこなわれます。

要求定義書は、発注側が作成し、システムに求める細かな仕様や機能について開発側に伝える文書です。システムに対するオーダーを記載したものです。

RFPの書き方

まずはRFPの書き方を下記の3つに分けて解説していきます。

• RFPに記載すべき項目
• RFP作成の工程
• RFPを作成する際に押さえるべきポイント5つ

RFPに記載すべき項目

RFPは、発注側が開発・制作側に対してシステムの目的や概要、要件や制約条件などを記載し、これからどういうシステム構築またはWebサイト制作を依頼したいのか、全体がイメージできるように記載することが大切です。ここでは、具体的なRFPの作成方法をご紹介します。

• 全体像
  今回提案するプロジェクト全体がシンプルに理解できる内容を記載する。背景や開発の目的、目標、提案依頼に関する手続き（予算規模、スケジュール）を記載する。
• 提案の要件
  具体的な提案の要件を記載する。提案を依頼したい範囲や内容、システム開発手法、必須な機能、運用・保守、納品成果物を記載する。
• その他
  全体像や提案の要件以外で伝えた方がよいと思われる情報や、RFP記載の段階ではわからない点などを補足として記載する。

 

RFPの構成については、こちらでテンプレートを無料で配布していますので、ぜひ活用してみてください。
【関連記事】RFPとは？ホームページ制作を成功に導く提案依頼書の書き方とサンプル

RFP作成の工程

RFP作成の工程は、以下の流れで実施します。

1. 全社システムにおいてのプロジェクトの位置づけを確認

これから導入するシステムや制作するWebサイトの位置づけを確認します。Webシステムと基幹システムとの連携がある場合など、他のシステムにも影響が大きいものか、他のシステムに影響しない独立したシステムかによって、今後のビジネスや経営戦略において考慮すべき点が変わってきます。

全社的に大きな影響を与えるものである場合、RFP作成にIT担当者や情報システム部門担当者だけでなく、経営層も関わり、システム計画を考える必要があります。他のシステムに影響しない独立したシステムであれば、特定の課題に着目するだけでよく、システム計画に関わる範囲も限定されるでしょう。

2. 今後目指していく方向性を踏まえてRFPを策定

システムの位置づけを確認したら、今後会社が目指す方向性を踏まえた上でRFPを策定します。先ほどご紹介した構成例を参考に、内容を記載していきます。

RFPを作成する際に押さえるべきポイント5つ

RFP作成の際のポイントは大きく5点あります。

• 曖昧さが排除されているか
• 必要な項目がすべて記載されているか
• プロジェクト名を共有できているか
• 発注側と開発・制作側で担当する役割を明確にしているか
• 補足事項や別途検討が必要な事項は記載しているか

曖昧さが排除されているか

RFPに限らず文書を作成する上で最も大切なポイントは、曖昧さをなくすことです。人によって解釈が変わる記載の仕方は、認識齟齬が発生する要因となります。発注側、開発・制作側どちらが見ても同じ理解になるよう、曖昧さは徹底的に排除するよう心がけましょう。

必要な項目がすべて記載されているか

最低限、プロジェクト全体のイメージができるための項目は記載しましょう。「背景」「目的・目標」「予算」「スケジュール」「納品成果物」が該当します。またこれらを含め、プロジェクトのゴールを明確にしておきます。

プロジェクト名を共有できているか

プロジェクト名は必ず記載しましょう。「○○プロジェクト」といった簡単なものでかまいません。大切なのは、発注側・開発・制作側含め、認識齟齬をなくし情報共有をしやすくすることです。

発注側と開発・制作側で担当する役割を明確にしているか

プロジェクトの中で、発注側、開発・制作側どちらで実施するかが曖昧な場合、双方が相手側で作業をすることを期待し、結果作業が実施されずトラブルの原因となります。提案時には、開発・制作側から提案してほしい役割、作業内容を明確に記載しましょう。

補足事項や別途検討が必要な事項は記載しているか

RFP作成時に不明点や悩んでいることがあれば、その内容を記載しておきましょう。開発・制作側からそれらを考慮された提案を受けることができます。また、参考情報などもあわせて伝えておくとよいでしょう。

要件定義書の書き方

ここからは、要件定義書の書き方について解説していきます。要件定義書はRFPと異なり、開発・制作側が発注側からヒアリングした内容をもとに、作成する文書です。

要件定義書に記載すべき項目

要件定義書は、RFPに記載された発注側の要件に対して、その答えとなるシステムやWebサイトの機能を記載します。「RFPに記載されている○○という要件に対し、△△機能を開発して解決します」というイメージです。

• 概要や背景・目標
  発注側のニーズを開発・制作側が正しく理解できているか再確認するため、RFPに記載されている背景・および目標をもとに、開発・制作することにより達成できる目標や、メリットを記載します。
• システムの具体的な機能
  発注側から求められている機能要件について記載します。機能要件には、利用者から見える外装の「画面要件」「外部インターフェース要件」や、バッチ要件などが含まれます。他にも、システム全体の稼働環境を整理したハードウェアやソフトウェア、ネットワークなどの構成図なども記載します。Webシステムの場合は利用者の閲覧環境やデバイスについての要件なども記載します。
• システム導入後のフォロー、非機能要件
  発注側から求められているシステムの非機能要件や教育などのシステム導入後のフォローに関する要件について記載します。具体的には「拡張性」「セキュリティ」「システム移行」「運用・保守」「教育・研修」などについて記載します。

要件定義の工程

要件定義は大まかに下記の3工程でおこなわれます。

• 発注側から要求を引き出す
• 要求定義に基づいて分析と検討を実施
• 複数回の打ち合わせを経て、要件定義書を作成

1. 発注側から要求を引き出す

発注側からのRFPをもとに、さらに細かい部分の要求についてヒアリングし、要件をより具体的なものに落とし込んでいきます。

2. 要求定義に基づいて分析と検討を実施

発注側から出された要求を分析し、システムで解決する部分を検討します。要件によっては、システムでは解決できないものが含まれている可能性もあります。すべての要求を満たすことが重要ではなく、システムで解決できる部分とそうでない部分を精査し、発注側の目的に最も沿うよう要求を整理していきます。

3. 複数回の打ち合わせを経て、要件定義書を作成

発注側と開発・制作側で認識のすり合わせを何度もおこない、要件定義書としてまとめます。まとめた結果が、RFPの内容に沿ったものであることも確認が必要です。

要件定義書を作成する際に押さえるべきポイント3つ

要件定義書を作成する際は以下の3つのポイントを押さえると進行がスムーズになります。

• 開発・制作側がやるべきことを具体的に定義する
• 発注側と開発・制作側で認識の統一をおこなう
• RFPを確認し、目的に沿った要件を記載する

開発・制作側がやるべきことを具体的に定義する

要件定義書の内容をもとに、具体的にシステムの設計・開発がおこなわれます。そのため、要件定義書に曖昧な記載があった場合、どのようにシステムやプログラムの設計・開発をおこなえばいいかわからず、最悪意図しない機能ができあがる場合もあります。
そのようなことにならないよう、要件定義書を作成する段階で、開発・制作側がやるべき内容を具体的に定義しておくことが大切です。

発注側と開発・制作側で認識の統一をおこなう

要件定義を成功させるためには、発注側と開発・制作側で認識を統一することが重要です。曖昧な定義により認識がずれてしまうと、できあがったものと期待したものがずれてしまい、プロジェクトそのものが失敗してしまう場合があります。そうならないためにも、発注側と開発・制作側での認識は必ず統一させましょう。

RFPを確認し、目的に沿った要件を記載する

要件定義は発注側に対してヒアリングをおこないながら進めていきますが、ヒアリングをおこなっていくうちに目的や要件の追加や変更が発生し、当初の内容からズレてしまうことがあります。そのような状況にならないよう、適宜RFPを確認し、要件定義がRFPから離れたものにならないよう注意が必要です。

当社の要件定義における取り組み

Web制作会社である当社でも、要件定義書はプロジェクト進行においてよく使用する資料です。当社において、要件定義書はシステムだけでなく、構築するWebサイトについてまとめた包括的な資料となります。

ここまで一般的なRFPと要件定義書について解説しましたが、最後にジーピーオンラインでは要件定義書をどう捉えているかをご紹介します。

• 要件定義書は「やらないことを決める」ことでもある
• コンセプトに重きを置く
• 課題整理は経営課題から
• 要件定義を通した相互理解が成功へと導く

要件定義書は「やらないことを決める」ことでもある

要件定義の中で当社がWeb制作会社としてやるべきことは、数多くのやりたいことの中から、筋道を立てて「Webで何をやり、何をやらないかを決めること」と考えています。

企業さまにとってWebサイトのリニューアルなど何度も経験することではありません。そのため「何を決めないといけないのか分からない」とのお声を多くいただきます。やりたいことがあっても、部署や個人個人で方向性が定まっていないことはよくあることです。

ただ「何がしたいですか？」と問いかけて言われたままを実施するのでは良いものはできません。ヒアリングを重ね、時間をかけて課題を紐解き、お客さまの未来像に合ったWebサイトのあるべき姿を策定することこそが要件定義であると考えます。

コンセプトに重きを置く

要件定義書には項目がたくさんありますが、大切なのは条件ではなく「どのようなWebサイトにするのか」というコンセプトです。まずは「誰に（ターゲット）」「何を（コンテンツと体験）」「どうしてもらう（アクション）」の3点を押さえることで、次に策定する諸条件やコンセプトを明確にしていきます。

リニューアル範囲、スケジュール、予算、インフラ環境やシステムなどの条件も重要ですが、当社では「リニューアルの目的」「イメージ（世界観）」「施策」「設計方針」「運用方法」などのコンセプト設計こそがWebサイトリニューアルを意味のあるものにするのです。そのために、当社ではペルソナ設定、ユーザーシナリオやロードマップの作成をおこない、はっきりとしたイメージを掴みます。

課題整理は経営課題から

課題整理をする際は、経営理念や事業ビジョン、中期計画、CSR活動など経営課題から入ります。次にマーケティング課題を戦略と施策から整理し、最後にWeb課題へと落とし込んでいきます。そこで初めてユーザーニーズやログ分析、他社サイト分析、運用体制、インフラ環境、システム基盤などに視点が移ります。

Webサイトのリニューアルはあくまでも手段です。部分最適ではなく経営課題から一貫性をもってリニューアルで解決すべきことを決定します。

要件定義を通した相互理解が成功へと導く

要件定義の重要な側面に、関係者間の相互理解や自分ゴト化があります。

キックオフから始まり、定例会での打ち合わせを重ねて要件を定義していきます。関係者が一緒に課題や仮説を創りあげる作業は、自然と意見発散や気づき、相互理解、自分ゴト化を生み出します。その成果物として要件定義書ができあがると考えています。つまり、Webサイトリニューアルの要件定義とは、「発展していく企業像に合わせた『未来を思い描くシナリオ作り』」なのです。

要件定義とは企業の「未来を思い描くシナリオ」

本記事では、RFP、要件定義、要求定義の違いとともに、RFPおよび要件定義書の書き方、作成の際に押さえるべきポイントまで解説しました。RFP、要件定義、要求定義の違いは以下のとおりです。

・RFP（提案依頼書）
発注側が作成し、開発・制作側に対して具体的な提案を依頼するための文書

・要件定義書
開発・制作側が作成し、発注側からの要件や要望、目的達成するためにおこなうべき内容をまとめた文書

・要求定義書
発注側が作成し、システムに求める仕様や機能について開発・制作側に伝える文書

どれも「誰が」「どの目的で」定義し、文書を作成するのか、全て異なります。この違いを理解しておかないと、結果的に発注側の要件を満たせない場合もあります。満足度の高いシステム開発やWebサイト制作を実現するため、それぞれの記載内容をしっかり理解しましょう。

ジーピーオンラインではお客さまの経営課題からヒアリングをおこない、企業さまの思い描く未来像に沿った要件定義をおこないます。「一緒に考えながら進めてほしい」「本当に意味のあるWebサイト制作をしたい」という方はぜひご相談ください。

ジーピーオンラインにWebサイト制作・システム開発の相談をする

資料請求フォームへ