RFP（提案依頼書）とは？作成手順とメリット、注意点をわかりやすく解説

RFP（提案依頼書）は、企業が開発会社にAIやSFA（営業支援システム）といったシステム開発を依頼する上で欠かせない提案依頼書です。DX化が進む昨今、自社にとって最適なシステムを導入するためには、システム開発の委託先の企業に具体的な機能や要件、解決したい課題などを共有し、発注側と開発側で認識のズレを可能な限り少なくすることが重要になります。

ここではRFPの概要や作成するメリット・デメリットを詳しく紹介します。あわせて、RFP作成時に意識したいポイントも合わせて紹介しましょう。

 

目次

 

 

1.そもそもRFP（提案依頼書）とは？

RFPとは、システム開発を依頼する側が、SIerやベンダーといった開発会社へ提出する書類のことです。システムに搭載したい機能や要件、解決したい課題などを発注者が記入し、ドキュメント化します。よりわかりやすく言えば、「発注者側の依頼内容をまとめた書類」という認識でも良いでしょう。「Request for Proposal」という言葉の頭文字を取ってRFPと表記されます。

わかりやすくまとめたRFPを受注側であるシステム開発会社に提出することで、発注側の要望や情報を正しく開発会社に伝えられます。その結果、「自社の要望に合った提案」をシステム開発会社から引き出しやすくなるのです。以下の項では、RFPを提出するメリットとデメリットをそれぞれ紹介します。

 

2.RFPのメリット

RFPを使って開発側と情報共有を行うことには、以下に挙げられるようなさまざまなメリットがあります。

 

• 要件を適切に伝えられる

• より良い提案を受ける確率が上がる

• 複数社の提案を効率よく評価・比較できる

• 自社の現状を見直す際に役立つ

• トラブル発生の防止に繋がる

• 想定スケジュールが適切かを確認できる

• 社内調整がしやすい

• 開発会社も作業に取り組みやすくなる

それぞれについてさらに詳しく解説していきます。

 

●要件を適切に伝えられる

RFPが持つ最大のメリットは、自社が求める要望を要件定義としてまとめ、開発会社へ適切に伝えられることです。RFPがないと要件に抜け漏れが発生したり、開発会社側で伝言ゲームが始まって正しい内容が伝わりにくかったりします。開発会社側からピントの外れた提案が持ち上がり、説明や訂正に時間がかかることも珍しくありません。こうした齟齬を防止するために、要件を明記したRFPの提出は不可欠なのです。RFPを一度作成しておけば、開発会社に自社の要求を都度説明する手間を省くこともできます。

 

●より良い提案を受ける確率が上がる

要件を明確化することで、開発会社から受けられる提案のレベルを担保できます。要求の概要を文書化することで、要求に沿った最新の技術や、さらに付加価値のあるシステムを提案してもらえる可能性も高まるため、提案内容を詰めるための作業負担も軽減できます。発注側の企業がシステムに関する知識が乏しい場合こそ、RFPを作成したほうが良いとも言えるでしょう。

 

●複数社の提案を効率よく評価・比較できる

発注前の段階で、RFPを複数の開発会社へ提出することも可能です。複数の開発会社から全く同じ要件の提案書をもらえるため評価基準を統一しやすくなり、各提案の比較をスムーズに行えます。一方、RFPを提出しない場合だと、評価基準がまとまらず提案にムラが出てしまうため、要件に合った開発会社を選定するのが難しくなります。

 

●自社の現状を見直す際に役立つ

RFPの作成は、自社の現状把握や課題発見にも役立ちます。RFPに正しい要件を盛り込むには、「社内のサービスにどんな課題があるのか」「その課題をどんなシステムで解決したいのか」という点を洗い出す必要があります。この作業を通して、現状および課題を把握できるようになるのです。

 

●トラブル発生の防止に繋がる

RFPによって情報や要望を明確にドキュメント化しておくと、トラブルの発生を未然に防げます。

システム開発の場面では、曖昧な要望や口約束が原因で「知らされていた納期と異なる」「予算と開発規模が合わない」などのトラブルが発生するケースが少なくありません。依頼する側と開発会社側間で「言った」「言わない」の水掛け論が発生し、意見が平行線を辿るケースもあります。

RFPはこうした「納品物の納期」、「見積もりや開発規模」に関するトラブルを防ぐのに効果的です。

 

●想定スケジュールが適切かを確認できる

RFPを作成して開発会社に共有しておけば、社内で想定していた作業スケジュールや納期などがそもそも適切かどうかを確認できます。無理がある場合には、適宜スケジュールや納期を見直しましょう。また、後述するRFQも作成する場合、設定している予算の妥当性も確認することができます。

 

●社内調整がしやすい

RFPを作成した後、自社の経営層や関係部署にあらかじめ説明しておけば、社内での理解や合意を得やすいと言えます。経営層や関係部署に根回ししておくことで協力が得られ、プロジェクトをスムーズに進められます。

 

●開発会社も作業に取り組みやすくなる

RFPがあれば、案件の概要を把握できるため開発会社も提案作業に取り組みやすいと言えます。また、開発会社にとっては提案作業にもコストはかかるため、単なる情報収集目的の依頼は避けたいものです。RFPの提出を受けることは仕事の依頼が前提となっているため、開発会社側からもしっかりとした提案が行われる確率が上がります。

 

3.RFPのデメリット

RFPを作成・提出するにあたり、以下2点のようなデメリットにも注意する必要があるでしょう。

 

• 発注前の作業負担が増える

• システム開発の着手まで時間がかかる

 

●発注前の作業負担が増える

RFPは、詳細な要件を明確にまとめ、相手が正しく理解できる形で作成・提出する必要があります。RFPを初めて作成する企業や担当者にとっては、この要件の抽出が思わぬ負担になるでしょう。しかし理想のシステムを開発してもらうためには、曖昧な部分をできるだけ排除することが欠かせません。コストや時間がある程度かかっても、しっかりとしたRFPを作成する必要があるのです。

 

●システム開発の着手まで時間がかかる

RFPの作成は、システム開発に関係する部門それぞれの問題点を整理する必要があるため、工数がかかります。特に、初めてRFPを作成する場合は、分かりやすくまとめる以前に、何をまとめれば良いのかが分からずドキュメント化しきれないということもあるでしょう。

ですが、開発の着手までには時間がかかってしまうものの、RFPを作成・提出することで、開発着手後の余計な手戻りを減らすことができます。総合的に考えると、かかる工数や手間をふまえても、RFPを作成する方が無駄な時間の削減につながると言えます。

 

4.RFPとRFI、RFQとの違い

名称	詳細
RFP（提案依頼書）	システム開発会社へ向けて、発注する側の要件をまとめた書類
RFI（情報依頼書）	システム開発会社に対し、企業情報や製品情報の提示を依頼する書類
RFQ（見積依頼書）	システム開発会社に対し、見積額や内訳などの提示を依頼する書類

 

RFPの構成や作成のポイントを紹介する前に、RFPとしばしば混同される「RFI」との違いについて解説しておきましょう。繰り返しになりますが、RFPの役割は、既に目星をつけている開発会社へシステム開発の要件を伝えることです。

これに対してRFIは、開発会社の会社情報や技術・製品情報の提示を依頼する書類のことです。RFIは「Request for Information」の頭文字を取った略語で、日本語に訳すと「情報依頼書」になります。

わかりやすく言えば、システム開発を依頼するため「御社の技術や製品、基本的な会社情報を教えてほしい」と依頼する書類だと考えると良いでしょう。会社情報や技術情報を知ることで、要件に合致する企業か否かを見極める意図があります。

RFIは依頼先を決める段階で必要となるため、プロジェクトの初期段階で依頼するのが一般的です。ちなみに、「会社情報」や「実績」などの記入もしくは提出を依頼するだけの書類であるため、RFPと比べると作成の難易度が低い書類と言えます。

また、RFQは「Request For Quotation」の頭文字を取った略語で、日本語では「見積依頼書」と訳されます。予算の参考にするため、システム開発会社に対して価格や内訳を記載した見積書の提出を依頼するための文書です。場合によっては納期や納品方法、支払い方法などの記載も併せて依頼することがあります。複数のシステム開発会社に見積書を依頼しておけば、比較検討を行いやすくなります。

なお、RFPとRFI、RFQの3つを総称して「RFx」と呼ぶことがあります。いずれも価格決定に重要な書類です。書類の作成順は「RFI」→「RFP」→「RFQ」ですが、RFPの中にRFQを含む場合もあります。

 

5.RFPの作成からシステム開発までの流れ

RFPの作成からシステム開発に着手するまでは、主に上記のような流れで行います。

ここからは、それぞれの段階の中でどのようなことを行うのかさらに詳しく解説していきます。

 

●STEP1：プロジェクトチームの編成

RFPを作成する際は、いきなりプロジェクト担当者1人だけで手早く進めず、RFPが必要となるプロジェクトを進めるためのチームを編成しましょう。

1人ではなく複数メンバーで進めるべき理由は、わかりやすく明確なRFPの作成には、社内情報の積極的な洗い出しや共有が求められるためです。システムの開発・導入にあたって関係各所から意見を募るなどの連携や、導入するシステムがどの部署にどのような影響を与えるのかといったヒアリング、ミーティングなども必要になるでしょう。開発着手後やシステム導入後の社内トラブルを回避できるメリットもあるため、複数メンバーでプロジェクトを進めるのが望ましいと言えます。

また、チームを編成する際は、プロジェクト全体のマネジメントを担うプロジェクトマネージャーと、経営的視点で意思決定を行うプロジェクトオーナーを優先的に決めておくのもポイントです。

 

●STEP2：開発目的の確認

チームを編成した後、プロジェクトで開発するシステムの目的を確認しましょう。導入するシステムの目的が曖昧なまま開発が進行してしまうと、社内に導入した後に有効に扱えなくなってしまいます。「なぜそのシステムを導入するのか」「どのような課題を解決したいのか」などの軸がぶれないよう、チーム内で明確にしておきましょう。

システム開発の目的を確認した後は、現状の社内における課題の把握が必要です。プロジェクトチーム内外を含めたさまざまなレイヤーから多角的な情報を集め、それぞれがどのような課題を抱えているのか認識をすり合わせましょう。

この時、どのレイヤーが抱える課題から率先して取り組むべきか、優先順位を設定することで、より目的に沿ったシステムを開発・導入しやすくなります。

 

●STEP3：解決策の立案

課題の把握と解決すべき優先順位を設定したら、次は具体的な解決策を立案しましょう。

解決策を立案する際は、「システムを導入して課題を解決できるのか」を軸にするのではなく、少し先を見据えて「システムで課題を解決すれば本来の目的を達成できるのか」を軸に考えるのがポイントです。システムを導入するかどうかだけに論点を設定せず、必要に応じて社内の体制変更を考案するなど、さまざまな幅広い視点から解決策を模索していくのが良いでしょう。

 

●STEP4：情報収集・評価基準の設定

候補となるシステム開発会社を探し出すため、情報収集を行います。候補となりそうなシステム開発会社に対してヒアリングやRFIの提出などを通して、情報提供を依頼します。こうした情報収集はRFPの提出先を絞り込むために行います。

次に、RFPの提出先を選定するための評価基準を設定します。発注側である自社がどういう観点で開発会社を選定するかを明らかにすることで、受注側の提案レベルの向上も見込めます。なお、この作業は後述するRFPの作成と同時期に行うと良いでしょう。

 

●STEP5：RFPの作成・提出

候補となるシステム開発会社を絞り込んだら、本格的にRFPの作成に移ります。ここまでの内容をふまえ、社外の人間にも明確な意思伝達ができるようドキュメント化し、候補となる開発会社へ提出しましょう。場合によっては、見積額の提示を依頼するRFQも提出します。

具体的にどのような項目をまとめれば良いのかは、RFPに記載する主な項目で後述します。なお、評価基準についてもRFPに記載することがあります。

 

●STEP6：開発会社から提案書・見積書を受領

RFPを開発会社に提出後、開発会社側はRFPの内容を確認し、それを基にプロジェクトの提案書と見積書を作成します。開発会社から提案書と見積書が送付され次第、受領と確認を行いましょう。

 

●STEP7：開発会社の決定・合意・開発開始

候補となる開発会社からの提案書と見積書を確認した後は、必要であればさらに各社からプレゼンテーションしてもらうコンペティションを実施します。提案内容を評価基準に照らして総合的に判断し、委託先となる開発会社を決定しましょう。

開発会社を決定したら契約を締結して合意を得ます。必要に応じて関係各所との調整を行います。十分な意思伝達と要件定義の共有が済んだら、本格的なシステム開発に着手してもらいましょう。

認識の更なるすり合わせが必要な場合やシステム開発に関する質問がある場合は、開発に着手する前に開発会社に問い合わせたり、ミーティングの時間を確保したりするのも良いでしょう。

 

6.RFPに記載する主な項目

RFPに記載する主な項目は、「概要」と「提案依頼内容」「選考の進め方」の3つに分かれます。

●概要

「概要」は、発注側である自社の現状や、今回のプロジェクトの概要など、システム開発会社が提案書を作成する際に参考にできるような情報を記載します。

 

▼「概要」枠における記載項目

本書の目的	システム開発を依頼する目的
プロジェクトの背景	システムを導入することになった背景
現状の課題	現在自社が抱えていて、解決したい課題
プロジェクトの目的	このプロジェクトを実施する理由・目的
ゴール	プロジェクト自体のゴール（求める品質や納期、費用）
プロジェクトの範囲	提案を依頼したいプロジェクトの範囲
発注側の会社情報	自社の取扱商品や業種、販売形態などの情報
現行のシステム構成	現在自社で使用しているシステムの構成図やシステムパッケージ
現行の機器情報	現在自社で使用しているPCやサーバ情報

 

●本書の目的

このRFP自体の目的や位置づけについて簡潔に説明するページです。システム開発会社が提案書を作成する際に参考になる自社の情報やプロジェクトの要件を示すことが目的であることや、提案書を基にプロジェクトの発注先を選定することなどを記載します。

 

●プロジェクトの背景

経営面や業務量の課題など、システムを導入することになった背景を説明するページです。同時に、システム構築・導入で解決したい現状の課題を説明する場合もあります。

 

●現状の課題

現在自社が抱えている課題について記載します。業務別・機能別などに分類して箇条書きにしたり、図表を用いたりして、情報を整理してわかりやすく伝わるようにしましょう。

 

●プロジェクトの目的

「何のためにこのプロジェクトを行うのか」という目的について明確に記載します。もし、達成に必要な手段がわかっている場合は明記しておくと良いでしょう。「現状の課題」と同様に、箇条書きにして補足説明を入れるように記載すると伝わりやすくなります。

 

●ゴール

RFPには、求める品質や納期、費用などできるだけ可視化できる項目をプロジェクトのゴールに据えます。たとえば品質の項目であれば、「現状の課題がすべて解決すること」、「すべての画面処理が5秒未満で完了すること」などの条件をつけましょう。費用の項目であれば「見積額以内でプロジェクトが完了する」などの予算に関する条件を、納期項目なら「○○年○○月○○日までに、新システムが問題なく稼働する」などの具体的なスケジュールに関する条件をつけると、さらにゴールが明確になり、プロジェクトの評価もしやすくなります。

 

●プロジェクトの範囲

開発会社に対し、提案を依頼したいプロジェクトの範囲を説明するページです。「機器の購入から開発まで依頼したい」「システム開発だけを依頼したい」など、プロジェクトの範囲を明確に説明しましょう。範囲を箇条書きでまとめると、簡潔でわかりやすくなります。

 

●発注側の会社情報

発注側である自社の取扱商品や業種、販売形態などの情報を説明するページです。こちらも箇条書きで記載して問題ありません。自社の紹介パンフレットがあれば、RFPに添付してみるのも手です。

 

●現行のシステム構成

現在使用しているシステムの構成図や、システムパッケージ（既存の製品版システム）の名前を説明します。構成図が複雑で作成が難しい場合は、システムパッケージ名を洗い出して記載しましょう。

 

●現行の機器情報

自社で現在運用しているPCやサーバ情報を説明します。導入するシステムによって推奨環境や必要なスペックが異なるため、PCの入替作業が発生するケースも考えられます。「思わぬ入替作業が必要になって慌てた」という事態にならないよう、使用中のPCの台数と基本スペックはしっかり説明しましょう。

 

●提案依頼内容

「提案依頼内容」には、システム開発会社に対して提案書に盛り込んでほしい情報について具体的に記載します。記載してほしい内容に関する条件なども細かく掲載すると良いでしょう。

 

▼「提案依頼内容」枠における記載項目

受注側の会社情報	受注側となるシステム開発会社の組織に関する情報
提案システム概要・構成	開発会社に提案してもらうシステムの概要や構成
機能要件	システムに実装してほしい機能
スケジュール	発注決定から開発、納品までの全体スケジュール
体制図	プロジェクトに参加する全メンバーと役割、プロジェクトマネージャーの経歴など
プロジェクトマネジメント方法	プロジェクトマネジメント方法についての明示
会議体一覧	プロジェクトを進める会議体の概要
サポート体制	サポート体制や窓口の対応フロー、緊急時窓口などの明示
納品物一覧	納品物の内容と納品時期、納品形態
ドキュメントサンプル	納品物の品質がわかるようなドキュメントサンプル
概算費用	初期費用や月額費用の概算
制約事項	現時点で明らかな制約事項やリスク
導入事例	発注側の会社と業種・規模に近い導入事例
契約内容	契約内容および支払方法の明示

 

●受注側の会社情報

システム開発会社の企業情報や製品情報などを記載する項目です。自社と同じような業種・業界でのシステム開発実績があれば、ミスマッチの可能性は低くなります。なお、RFIにより会社情報の開示を得られている場合は不要です。

 

●提案システム概要・構成

ここでは、開発会社に提案してもらうシステムの情報について、どのような形式で提示してもらうかを記載します。例えばシステムの機能一覧や主要機能の画面キャプチャ、ネットワーク構成図、ハードウェアに必要なスペックなど、欲しい情報を明確にしましょう。

 

●機能要件

どのような機能を実装してほしいかについて記載します。発注時に作成する「要件定義書」で別途詳細に記載しますが、RFPにも具体的に記載しておけば認識の齟齬を防ぎやすく、求める提案を受けられる可能性が高くなります。

 

●スケジュール

プロジェクトのスケジュールについて、週単位（もしくは月単位）で明示してもらうよう記載します。また、開発会社側だけでなく、発注側の自社が担うべきタスクについても明示してもらうようにしましょう。

 

●体制図

プロジェクトに参加する全メンバーとその役割を明示してもらうよう記載します。また、プロジェクトの成否にかかわるプロジェクトマネージャーについては、併せて経歴などの資料も提示してもらうようにしましょう。

 

●プロジェクトマネジメント方法

プロジェクトにおける品質やスケジュール、リスクなどのマネジメントのために行う具体的施策について明示するよう記載します。体制がしっかりしている開発会社であればプロジェクトマネジメント方法を定めている傾向にあります。

 

●会議体一覧

プロジェクトを進める際に発生する会議体について、名称や実施内容、メンバー、開催日、所要時間を明示するよう記載します。自社の工数を把握できます。

 

●サポート体制

システム障害発生時の対応を確認するための項目です。システム稼働後のサポート体制、窓口の受付時間・対応フロー、緊急時窓口、SLAなどについて明示するよう記載します。対応に時間を要する場合に、なるべく支障を与えないような運用方法についても確認しておくと良いでしょう。

 

●納品物一覧

納品物（成果物）について、あらかじめ内容や形態を一覧形式で明示するよう記載します。トラブル防止につながる重要な項目です。

 

●ドキュメントサンプル

納品物のドキュメントの品質を事前に確認するため、過去のサンプルを提示してもらうようにしましょう。要件定義書、設計書、ユーザーマニュアルなどを指定しておくと安心です。

 

●概算費用

初期費用（イニシャルコスト）や月額費用（ランニングコスト）の概算を明示してもらうよう記載します。金額の妥当性を判断するためにも、合計額だけでなく必ず内訳まで明示してもらいましょう。初期費用の内訳として、例えばシステム開発費、機器購入費、ミドルウェア購入費、ユーザー教育費など、月額費用にはシステム保守費、ネットワーク費、サポート費といったものが挙げられます。

 

●制約事項

プロジェクトに関して現時点で明らかな制約事項やリスクについて明示するよう記載します。データの登録数や同時アクセス人数について制限がある場合、事前に把握しておかないと、追加費用の発生やスケジュールの遅延につながるため重要です。

 

●導入事例

発注側の自社と同様な規模や業界・業種での導入事例があれば明示してもらいましょう。近い導入実績のある開発会社は、安心して依頼しやすいと言えます。

 

●契約内容

契約内容や支払方法についても明示してもらうように記載しておけば、トラブル防止につながります。小規模の開発会社の場合、支払方法に制約がある可能性があるため、事前の確認が重要です。

 

●選考の進め方

「選考の進め方」では、開発会社に対して、選考のスケジュールや評価基準などの情報を伝えるために記載します。

 

▼「選考の進め方」枠における記載項目

選考スケジュール	提案書の提出期限やプレゼン日程、選考結果の通知日など
提案書提出先	提出先となる担当者の氏名・メールアドレスなどの連絡先
評価基準・方針	評価で重視するポイントや採点方法など

 

●選考スケジュール

自社で想定している選考スケジュールを具体的に記載します。提案書の締め切り日から、提案書の内容精査、提案のプレゼンテーション、提案内容に対する質問・回答、社内合意、発注・プロジェクト開始などの想定日時を記載します。RFPの送付から提案書の締め切りまでは2週間以上は確保するようにしましょう。大規模なシステム開発の場合はさらに時間を要する場合があります。開発会社にとって不都合がある場合は希望スケジュールを確認するようにしましょう。

 

●提案書提出先

開発会社が提案書をいつ、誰に、どのような方法で提出するかを記載します。担当者名とメールアドレス、提案書の締め切り日時を明示しましょう。

 

●評価基準・方針

開発会社の選定における評価基準や方針を記載します。必須項目ではありませんが、評価ポイントを明確にしておけば、自社の意図に沿った提案をしてもらえる可能性が高くなるため記載しておきましょう。評価項目はソリューション評価、マネジメント評価、価格評価などの項目に分けて記載することが一般的です。

 

主な記載項目は以上です。これまでに挙げた構成を参考に、RFPを作成しましょう。

システム開発会社によっては、上記項目を予め記した、RFPのテンプレートを公開しているケースもあるので、「書類を作るのが難しい」という方であれば、利用を検討してみるのも良いでしょう。テンプレートごとに記載されている項目が異なるケースもありますが、1から作成するよりも少ない労力でRFPを作成することができます。

 

7.RFP策定時の注意点

最後に、RFPを作成する際、押さえておきたい書き方のポイントを紹介します。以下の6点に配慮して作成することで、より円滑にRFPを作りやすくなり、開発会社側の理解も明確になり、システム構築の流れがスムーズになります。

 

• フォーマットにこだわりすぎない

• 最初から完璧を目指さない

• 色々な人の意見をもらい抜け漏れを防ぐ

• 現場の実態に即した要求を行う

• 費用対効果に見合う要求を行う

• RFP提出後の追加要求は避ける

 

●フォーマットにこだわりすぎない

企業によって、導入したいシステムや必要な費用は異なるものです。したがって、必ずしもフォーマットにこだわってRFPを作成する必要はありません。RFP作成において大切なのは、必要な情報を正確にわかりやすく盛り込めているか否かという点です。フォーマットに縛られすぎると、盛り込める情報が限られてしまうので注意しましょう。

 

●最初から完璧を目指さない

手慣れた方であっても、全く抜け漏れのないRFPを作成することは難しいものです。最初から完璧なRFPを作ろうとせず、開発会社と相互の問い合わせを何度か繰り返しながら、徐々にブラッシュアップしていくものと考えましょう。そもそも、RFPの目的は開発会社に良い提案をもらってシステム開発を進めてもらうことがゴールです。RFP作成が目的になってしまえば、本末転倒になってしまいます。

 

●複数の人の意見をもらい抜け漏れを防ぐ

RFPを作成する際は、社内のさまざまな立場の人から意見を出してもらうことが大切です。1人でRFPを作成していると、思わぬ抜け漏れが発生する可能性があります。ほかに検討すべき項目はないか、要件に抜け漏れがないかを社内など他の人にもヒアリングし、話し合いながらRFPをブラッシュアップしていくのがおすすめです。

 

●現場の実態に即した要求を行う

実際にシステムを利用する部署と連携して、RFPをチェックしてもらうようにしましょう。業務効率化のために新たなシステム開発を依頼したとしても、現場の業務フローと大きく異なっていると、かえって工数が増えたり、使いこなせずに問い合わせが増えたりします。情報システム部門や担当者が独断で決めてしまうと齟齬が生じやすくなりがちなので気を付けましょう。

 

●費用対効果に見合う要求を行う

あまり現実的ではない過剰な要求を行うと、システム開発の見積額が跳ね上がる可能性があります。実現したい機能について、事前にシステム開発会社に対して問い合わせておき、費用対効果に見合うか、実現可能性があるかなどを確認しておくと良いでしょう。

 

●RFP提出後の追加要求は避ける

開発会社はRFPをもとに、アサインする人員体制やスケジュールを策定し、提案書・見積書などを作成します。RFPに記載していない要求を後から追加してしまうと、その前提が崩れてしまうため、スケジュールの再調整や、提案書・見積書の修正などが必要になって、余計な工数がかかることになり、プロジェクトが遅延する可能性が高くなります。RFPの提出前には、必要な要求はすべて記載されているか、社内で慎重に確認しておくことが望ましいです。

 

8.RFPは「良いシステム」を開発してもらうために不可欠

今回は、RFPの概要や作成するメリット・デメリット、主な記載項目などを詳しく紹介しました。

RFPはシステム導入に関する依頼会社の要望を言語化するとともに、開発会社の提案力を引き出すツールでもあります。開発会社に実力を発揮してもらうためにも、依頼会社側はできるだけ正確でわかりやすいRFPを策定する必要があるのです。ここでご紹介したポイントを参考に、案件に適したRFP作成を進めてください。

 

システム開発の最適な発注先をスムーズに見つける方法

システム開発会社選びでお困りではありませんか？
日本最大級のシステム開発会社ポータルサイト「発注ナビ」は、実績豊富なエキスパートが貴社に寄り添った最適な開発会社選びを徹底的にサポートいたします。
ご紹介実績：22,000件（2024年10月現在）

外注先探しはビジネスの今後を左右する重要な任務です。しかし、

「なにを基準に探せば良いのか分からない…。」
「自社にあった外注先ってどこだろう…？」
「費用感が不安…。」

などなど、疑問や悩みが尽きない事が多いです。
発注ナビは、貴社の悩みに寄り添い、最適な外注探し選びのベストパートナーです。
本記事に掲載するシステム会社以外にも、最適な開発会社がご紹介可能です！
ご相談からご紹介までは完全無料。
まずはお気軽に、ご相談ください。 →詳しくはこちら

 

 

■システム開発に関連した記事