【IT業界初心者必見】RFP(提案依頼書)の基本|RFPの目的とメリット・デメリット
本日は、RFPについて、簡単に説明していこうと思います。
RFPについてこのようなお悩みを抱えていませんか?
- RFPの言葉の意味がわからない
- RFPを書く目的・対象がわからない
- IT初心者で、開発の何もかもわからない
今回はこのようなお悩みを解決する記事になっておりますので、是非とも目を通していたければ嬉しいです。
この記事を読めばこれがわかる!
☑️ RFPについて、IT初心者でも言葉の意味がわかる ☑️ RFPを提出する側と受け取る側がはっきりと理解できる ☑️ ITの知識が増え、分かることが多くなる
この記事を書いている私は、、、
ソフトウェア開発会社に勤めており、実際にRFPを何度も見てきました。また、今年の3月に大学を卒業して未経験でIT業界に入ってきたので、IT初心者でもわかりやすいよう難しい言葉を使用せず説明するように心がけています。
そんな私がRFPについて詳しく解説します!
目次
RFPとは?
RFPとは、Request For Proposalの頭文字をとった略語です。日本語では、提案依頼書という意味に翻訳されます。アプリやwebシステムを作りたい会社(発注企業)が、開発会社(受託開発企業)に対して、開発を依頼する際に使用する文書です。
RFPには主に、作りたいサービスの概要が記載されています。
具体的には、アプリ・システム導入の目的や背景、解決したい課題を記述します。それを元に今回作りたいサービスの範囲や目標、納期の日程と予算まで記載するのが一般的です。既に現在使われているサービスなどがある場合は、そのサービスについても詳しく説明した方がより具体的な提案を受けることができます。
上記で述べた様に、RFPには色々な項目が含まれているため、RFPは発注担当者だけでなく、営業部門や経営層などの様々な意見を取り入れて作成する必要があります。
ソフトウェア開発は、沢山の時間とお金を費やします。
そのため、RFPを入念に作ることが自分達の作りたいサービスの開発実現の一歩となります。
また、ソフトウェア開発の成功率は、30%と言われています。
その理由は、目に見えない物を開発するため、お互いの認識のズレが生じるケースや開発会社(受注企業)が開発できるか分からないのに、受注したりすることがあるからです。成功確率を少しでも上げるためにも、RFPはとても重要な役割を担っています。
RFPを作る目的とは?
では、RFPを作る目的はなんでしょうか?
もう少し深ぼって解説します。目的は大きく2つです。
- 開発会社(受注企業)から適切な提案を受けるため
- 開発会社(受託企業)を選定するため
それぞれを詳しく見ていきましょう。
✔️ 1つ目:開発会社(受注企業)から適切な提案を受けるため
発注企業が、RFPを作成することで、開発会社(受託企業)はそれを元に開発を行う予定を立てることが可能です。RFPを作成しない場合、発注企業の要望を開発会社(受注企業)が、正しく理解できず、的外れな提案を持ってきてしまうケースも多々あります。
「一見、発注企業側なのに、なぜ手間をかけてRFPを作成しなかればならないんだ。」と思う方もいますが、その考え方は、間違いです。
RFPがない場合、発注企業と開発会社(受託企業)でお互いの認識確認のコミュニケーションフローが多くなります。そのため、何か開発を依頼する場合は、必ずRFPを作成することを、強くオススメします。
✔️ 2つ目:開発会社(受託企業)を選定するため
RFPを作成すれば、RFPを開発会社(受託企業)に送るだけで、開発会社からの提案を得ることができます。そのため、容易に開発会社(受注企業)から、提案をもらうことができます。それに対してRFPを作成しない場合、既存の開発会社に継続して依頼したり、少数の開発会社を頼ることしかできません。数多くの開発会社から開発の提案をもらうことで、より良い開発会社(受託企業)を選定することが可能になります。また、ある程度RFPで概要を伝えているため、各開発会社(受託企業)からの提案に基準が設けられるため、選定しやすくなることも大きなポイントです。
RFPを作成する企業と受け取る企業
RFPを調べる際に一番理解に苦しんだのが、作成側と受け取る側の違いです。
そこで改めて、作成する企業と受け取る企業の対象をはっきりさせていこうと思います。
✔️ RFPを作成する企業
RFPを作成しなければならない企業は、発注企業です。発注企業とはアプリやWebシステムを作りたい会社です。
✔️ RFPを受け取る企業
RFPを受け取る企業はシステム・アプリ開発する開発会社です。開発会社は、RFPを受け取り、それを元に提案書を作成いたします。
まとめると、RFP(提案依頼書)を作成するのは発注企業、RFPを受け取りそれを元に提案書を作るのが開発会社(受託企業)です。
提案依頼書と提案書が、ごちゃごちゃにならないように気をつけましょう。
RFPのメリット・デメリット
次にRFPを書くメリット・デメリットについて説明していきます。
メリット・デメリットは、発注企業と開発企業によって異なるため、それぞれで解説していきます。
発注企業
まずは発注企業から記載します。上記で記載した通り、発注企業は制作したいアプリやサービスがあり、そのアイデアに基づくRFPを作成しなければならない企業です。
彼らにとってのRFP作成のメリット・デメリットはなんでしょうか?
メリット
1: 開発会社(受託企業)に対して、自社の要求を説明する手間を省くことができる。
2: 要求を文章に残すことで、「伝えた・伝えていない」のような認識齟齬のリスクを減らすことができる。
3:開発会社(受託企業)から良い提案を得た上で受託企業の選定コンペが平等にできる
デメリット
1:RFPの作成に工数&時間がかかる。
2:依頼の目的や背景・課題・製作したい機能などを洗い出して言語化する必要がある
上記が発注企業がRFPを作成するメリット・デメリットになります。デメリットのRFPの作成に時間がかかるとありますが、最終的に見ると、圧倒的にRFPを作成した方が、スムーズに開発を進めることができます。
なぜなら、RFPにシステムを作りたい背景から搭載したい機能を記載しているため、ヒアリングや確認するコミュニケーションロスが少なくなるからです。
なので、開発会社からすると、本音では、
開発業者選定の際はRFPを作成していただきたいと思っています、、、汗
しかしながら、Enlytの場合、RFPはなくても問題はありません。
ヒアリングのプロですので、「こんなこと考えているんですが、、、」の段階でもご相談ください!
開発会社(受託企業)
一方で、開発会社(受託企業)から見たメリットとデメリットをお伝えしていきます。再掲にはなりますが、開発会社(受託企業)はRFPを受け取る企業です。RFPを元に、システムの提案書(工数・時間の見積りを記載)している書類を発注企業に見せます。RFPがある場合のメリット、デメリットを見てみましょう。
メリット
1:提案依頼書を元に、粒度の高い提案書を作成できる。
2:ヒアリング&要求を確認する時間を短縮できる。
再掲にはなりますが、開発会社(受託企業)からすると、可能であればRFPを受け取りたいと思っております。
というのも、発注企業がRFPを作るためには、ある程度の調査が必要で、その調査中にIT業界の知見や、ある程度の前提条件を知っていただけるからです。そのため、開発会社と一歩先の段階から話を進めることができます。
発注企業の中には開発の知見が少ない会社も多く、「アプリやWebシステムは簡単に開発できる」と思っている方も多くいらっしゃいます。
そのため、開発会社は、アプリ・Webシステムを開発するにあたって必要な知識や平均的な金額・期間を正直にお伝えしなければなりません。
このようなことを避けるためにもRFPはあったほうが良いでしょう。
デメリット
1:認識齟齬が起きた際に、発注企業からの信頼を失う。(受注できない)
2:RFPの粒度がわからないため読み解くのに時間を要する場合がある。
開発会社(受託企業)がRFPを受け取るデメリットは、お互いの認識齟齬で問題になった際に不利になってしまう点です。RFPは、徹底的な証拠になるので、「ここに記載されているじゃないですか!!」と言われてしまえば、もう開発会社(受託企業)は、どうすることもできません。そのため、開発会社(受託企業)の方でRFPを受け取った際は、入念にチェックしましょう。
チェック項目は主に下記3点です。
☑️ どんな機能が欲しいのか? ☑️ どういった経緯でその機能が欲しいのか? ☑️ どんな悩みや問題があるのか?
まとめ
最後までお読みいただきありがとうございます。これで皆様も今日からRFPマスターです!
私は、新卒IT未経験でソフトウェア開発会社(株式会社Enlyt)に入社し、RFPについて一番理解に苦しんだポイントはRFPを作成する企業と受け取る企業でした。IT初心者の皆様もそこは注意して読んでいただきたいと思います。
RFP作成する企業と受け取る企業を正しく理解できれば、大丈夫です。
また色々なIT用語について深掘りできたらなと思います。
それではごきげんよう!
ありがとうございました。
Enlytについて
株式会社Enlytはベトナムに開発拠点SupremeTechを持ち、これまで50以上の開発プロジェクトを行ってきました。ベトナムと日本のグローバルなチームで、数多くのプロジェクトを成功に導いてきました。
Enlytのオフショア開発は、アジャイル・スクラム開発を採用しています。コミュニケーションの透明化を意識してそれぞれの役割で責任の範囲を明確化しています。クライアントも含めたワンチームとして、フラットな関係で開発を進めることができます。
お客様の納得のいくまで、共に開発させていただき、アイデアを最高のかたちにサービス化いたします。
オフショア開発についてのお悩みやご相談がございましたら、下記ボタンより気軽にお問合せください!