RFP（提案依頼書）は、システム開発などの業務委託を行う際に必要不可欠な書類です。

しかし、どんな内容を記載するべきなのか、作成する上での注意点など、分からないことは多いでしょう。

そこで本記事では、RFPとRFI、RFQの違い、RFPの書き方と注意点、主な記載内容を分かりやすく解説します。

正しく発注するためにも、最後までご覧ください。

RFP（提案依頼書）とは？

RFPとは、Request for Proposalを略したものであり、日本語に訳すと提案依頼書となります。

システムの開発を行うにあたって、クライアント企業がシステム開発ベンダーに発注するための要件をまとめたものです。

RFPを作成する目的・意義

システムベンダーとしては、RFPは提案時に必ず接するものです。ただ、システム等を取り扱っていない企業においては、あまり聞き馴染みが無いものとなり、RFPを利用する事でどのようなメリットがあるのかが分らないといった声もよくあります。

しかしシステムの開発等をシステムベンダーへ発注する場合は、基本的にRFPは定義したほうがよいです。

システム開発の契約を締結後にシステム要件を伝えられても、クライアント企業の想定する期間や予算内に要件を充足するシステムを提供できるかどうかがわからず、開発の失敗、予算オーバー、スケジュールの延期をもたらす可能性が高くなります。また、最もシステム要件を理解し、開発能力があり、コストを抑えて短期納入ができる最適なシステムベンダーを選ぶことができなくなってしまいます。

そのため、RFPを利用して目的を明確にし、それを書面でまとめて、ベンダー候補に提示する必要があります。

RFPの作成者は誰か

RFPの作成は、基本的にクライアント企業のシステムを担当する、情報システム部門が作成を行うのが一般的です。

クライアント企業からシステムベンダーに依頼を行う為、クライアント企業のシステムについて理解をしている人でないと、RFPを作成する事が難しいと言えるからです。
また、RFPが無いまま開発に着手する場合、システムベンダーは何を開発するのかが曖昧なまま要件定義が進み、想像していたシステムとは違うものが出来上がってしまう可能性もあります。

入札におけるRFP

自治体や省庁などの国の機関や、電力・ガスなどのインフラ事業者、メガバンクなどの大手金融機関などでは、入札というプロセスが実施されることがあります。ここでもRFPが提示され、広く提案を求めることになります。

一般企業と異なる点は、RFPでは詳細な要件を記載して応募を求めるものの、要件定義自体はプロジェクト開始後に改めて実行するのに対し、公共入札では要件定義書そのものがRFPとして提示されていることです。

このため、プロジェクト開始後に要件定義プロセスを通じて要件の調整を行うことは基本的に無く、応募企業であるシステムベンダーとしては、さらに慎重にRFPを読み込み、提案内容や提示金額、体制の検討を行ったうえで提案を行う必要があります。

一方で、作成者側の負担も大きく、要件定義書そのものであるRFPは100ページ以上になる場合も多く、RFP作成そのものが1つの大きなプロジェクトになることも珍しいことではありません。

RFPとRFI、RFQの違いとは？

RFPと呼ばれるもののほかに、RFI、RFQと呼ばれるものも存在します。

RFPは提案依頼書と呼ばれますが、RFIはRequest For Informationの略称であり、情報提供依頼書と呼ばれています。RFQはRequest For Quotationの略称であり、見積依頼書と呼ばれています。

それぞれ解説致します。

RFIとは

RFI（情報提供依頼書）とは、RFPを提示する前に行うことがあるプロセスです。詳細なシステム開発要件を定める前に、広く情報収集を行うために実施します。

RFPを作成するためには、候補となるシステムベンダーや、利用するソフトウェアをある程度絞り込んでいます。それらの候補をさらに絞り込むため、候補ベンダーに情報提供を依頼します。これから導入・刷新しようとしているシステムの技術的な情報や、利用している製品等の情報を記入し、情報提供依頼を行う為のものです。

ただし、この段階ではRFPを作成できるほどの詳細な要件は決まっていません。RFIで得られた情報を基に、クライアント企業は対象企業やソフトウェアをさらに絞り込み、要求事項をより具体的に仕上げていきます。RFIはRFPを作るための情報収集に使います。

RFQとは

RFQ（見積依頼書）とはその名の通り、システムに関する見積に関する事を記載するものとなります。

購入を検討している機器やソフトウェアの価格を見積もってもらいたい際、RFQでおおよその価格感がわかります。このため、プロジェクト予算を現実に即したものに設定できるようになり、プロジェクト予算とベンダーの提示額の開きが押さえられる効果があります。

RFPの書き方と主な記載内容

ここでは、RFPの書き方と記載内容についてご紹介します。大きなカテゴリとしては以下の内容を書くことになります。

プロジェクトの概要

RFPにおけるプロジェクトの概要には、全体像と詳細を記載します。プロジェクトの背景、目的、完了条件、現状の問題点を明記しましょう。

また、プロジェクトのスコープを明確に定義し、読み手が誤解しないよう記載します。

実施する事項と実施しない事項を明確にし、スコープ内の範囲を具体的に示すことが大切です。

提案依頼内容

RFPの核心部分で、ベンダーへの具体的な提案依頼を記載します。主な内容は以下の通りです。

• 機能要件：実装する機能と業務プロセス
• 非機能要件：UI、セキュリティ、耐障害性など
• プロジェクトスケジュール案：背景、工程、マイルストーン
• 契約フェーズ（該当する場合）
• 運用・保守要件
• プロジェクト運営要件
• 成果物・納品物

評価基準

提案書の評価方法を示し、ベンダーに期待する提案内容を明確にします。必須項目や足切り要件も明示しましょう。

公共入札の場合、評価項目と配点を公開することもあります。技術点と価格点の比率も、プロジェクトの性質に応じて設定することが必要です。

評価基準を明確にすることで、ベンダーからより適切な提案を得ることができます。

スケジュール

RFP提示後の調達プロセスのスケジュールを記載します。ここでのスケジュールとは、調達プロセス、すなわちRFPをベンダーに渡した後、どのようなプロセスと期間で業者決定を行い、契約に至るかを書いています。

主な項目は以下の通りです。

• ベンダー向け説明会
• 提案書の提出期限と方法
• 評価期間
• 質問会の予定
• 業者確定日
• 契約期限

公共入札の場合、再調達の可能性とそのスケジュールも明記します。これにより、ベンダーは提案準備のための時間を適切に確保できます。

【コピペOK】RFP（提案依頼書）のサンプル

ここでは、RFPのサンプルを例示します。適宜コピペしてRFP作成に活用してください。

表紙

表紙はあまり考える必要はなく、いわゆる定型文を記載します。見る人に一目でわかるように、出来るだけ簡潔に記載するようにします。

本プロジェクトの目的

こちらも表紙と同様に、定型文を記載していきます。なぜプロジェクトを計画する事になったのか、その目的について記載していきます。

プロジェクトの背景

こちらは目的に対しての背景を記載していきます。先ほどはプロジェクト実施によって実現したいことを記載しましたが、その理由を記載していきます。

現在の課題

こちらはプロジェクトの目的の為になにが問題になっているのかを記載していきます。長文になってしまう場合は、箇条書きにするとよいかもしれません。

システム導入の目的

こちらは、プロジェクトの目的ではなく、プロジェクト目的の達成のためにどのようなシステムを導入することにしたのかについて記載します。

プロジェクトのゴール

プロジェクトのゴールは、ベンダーに求めるプロジェクトの成果物です。また、その成果物の合格水準を明確にします。ただし、その水準はベンダーが自身で達成できるものでなければなりません。たとえば、経営判断のスピードアップに資するためのシステムを完成させることは要求できても、実際の経営判断のスピードアップを達成することは、ベンダーに求めることができません。

プロジェクトの範囲

こちらに関しては、ベンダーに提案を依頼する為の、プロジェクトの範囲を記載していきます。

特に、作業範囲については詳細に記述し、誤認識による作業範囲の漏れが起きないよう注意します。特に、クライアント企業とベンダーとの間で役割分担が不明確になりがちな箇所には留意し、明記します。たとえば、以下のようなものに注意が必要です。

• ソフトウェアの導入に関し、サーバーの納入も求めるのかどうか
• ソフトウェアの導入に関し、インストールサービスだけか、それとも導入支援作業を求めるか
• システム導入後の保守を求めるか
• システム導入後の運用を求めるか、あるいは求めないが、運用設計を行い運用担当への引継ぎを求めるか
• 受入テスト（UAT）について、計画策定やテストデータの準備等、ベンダーにも一定の支援を求めるか
• 旧システムからのデータ移行に関し、旧システムからの抜き出しも担当させるか　など

システム構成

こちらはベンダーへ提案してほしいシステム構成の要件を記載していきます。かなり重要な箇所な為、要件が上手く伝わるように細かく記載していきます。必ず図を挿入するようにしましょう。

現行システムの構成

現行システムがあり、追加開発や移行元システムとしての利用など、本プロジェクトに関係がある場合は、現行システムの構成についても記載します。また、そうでなくても導入するシステムの連携先システムがある場合は、連携先システムの接続方法などを中心に記載する必要があります。

会社情報

こちらは提案を依頼してもらう際、ベンダーが参考にする会社情報を詳しく記載します。

どのような業種でどれくらいの人数なのかによって、ベンダーは得意な分野や事例を参考にして、提案を行います。また、グループ企業がある場合、それらは導入対象となるのか明示が必要です。

提案システム概要

提案をしてもらう際に、どういった形で提案内容を記載してもらうかを記載していきます。提案において、記載に含めてもらいたい内容を明示します。

プロジェクトスケジュール

必ず用意すべきはマスタスケジュールです。月単位程度の粒度で、何をいつ行う想定なのかを明示します。具体的な遂行スケジュールを提案させるため、適宜マイルストーンを設置することを要求しましょう。

提案受領時には、要件定義フェーズが完了していないため、詳細なWBSを作成することができないことも多いです。この場合、調達するフェーズを分解し、まずは要件定義フェーズだけの発注を行うことにすることも検討しましょう。

プロジェクト体制図

こちらについては、プロジェクトにおける体制図と、ベンダーのプロジェクトマネージャーについての経歴について記載してもらうようにしましょう。

プロジェクトマネジメント手法

こちらはプロジェクトにおけるシステム開発側の担当者が行うマネジメント方法について、提案してもらえるように記載しましょう。

 

サポート体制・運用体制

運用・保守を継続して委託する場合はサポート体制や運用体制についても提案を受領する必要があります。

システムにおける重大な障害が発生した場合、どのようなトラブルシューティング等を対応してもらえるかを提案して頂けるかを記載していきます。

SLA

SLA（Service Level Agreement）は、サービスの水準に関する両者間の合意文書です。主に非機能要件・保守要件に対して、どのレベルのサービスが担保されるかを示してもらい、両者間の合意を行います。特にシステムの稼働率（どれくらいシステムが止まらないか）、問合せの際の一次回答の時間など、システム障害に関する対応内容に設定する合意事項です。

納品物一覧

こちらはプロジェクト発足時及びプロジェクト完了時に納品される品を提案してもらえるように、しっかり定めて記載するようにしましょう。

マニュアル等は必ず納品してもらえるよう、忘れず記載していきましょう。

ドキュメントサンプル

納品物の中に、ドキュメントファイルが多数納品されると思います。サンプルを提案してもらい、内容の確認をし、どのようなレベルなのかでシステム開発側を選ぶ事に必要な箇所になっております。

納品物のレベルによって、設計・構築及び運用レベルも変わってくると思いますので、必ず記載しましょう。

概算費用

こちらに関しては、プロジェクト全体に関しての初期費用とランニング費用（月額に対する運用費用）についてそれぞれの内訳を明確にしてもらいます。

重要なのが内訳を記載してもらう事です。

内訳を記載してもらう事で、どの工程でいくらかかるのかを理解できますので、内訳を記載してもらえるように記載していきましょう。

制約事項

プロジェクトにはさまざまな制約事項があります。制約事項は、所与の条件としてプロジェクト計画に反映させなくてはなりません。コスト上昇や、プロジェクト難易度にかかわってくるため、すべて示す必要があります。

これらをベンダーに提示しておかないと、プロジェクト進行時にトラブルが発生する可能性がありますので、必ず記載しましょう。

導入事例

こちらに関しては、ベンダーに要求する導入事例で、選定時に参考にすることを目的としています。

自社と近い導入事例及び成功例を確認すれば、ベンダーを選定し、依頼しやすくなります。

契約内容

契約条件について記載します。特に、業務委託契約（準委任）なのか、請負契約なのかは重要な論点です。また、請負契約とする場合、要件定義や受入テスト（UAT）の部分だけ準委任契約にするなど、工程ごとに契約形態が異なることもあります。

契約形態に誤認識があると、大きなトラブルにつながり、時には訴訟に至ることもあります。条件を細かく提示し、事前交渉でコンフリクトを解消できるよう、契約書のひな型を提示するようにもしてください。

RFP（提案依頼書）作成の流れ

RFPを作成するまでには、まずシステムの開発の定義、及び導入すべき機能を社内で検討します。

検討してある程度内容が確定できたら、RFIを提示して情報提供を依頼したい企業を選びます。RFIと共に、自社の現状・背景等を伝え、有用な情報を提供してもらえるように認識を合わせます。

RFIへの回答を経て、自社で整理した要件をブラッシュアップし、RFPの作成に入るとよいでしょう。

中にはRFIを出さず、いきなりRFPを作成する場合もあります。RFIを作成する理由は、プロフェッショナルであるシステムベンダーの知見を参考に、解決策をある程度絞り込むことです。たとえば、似たようなソリューションがあるが、専門家ではないのでどれが良いのかわからない時（例：生成AIのソリューションとしてOpenAI/Google/Amazonどれにすべきか？）や、課題の解決策としてのアプローチが複数ある場合（例：物流トラックの配送効率化として、自動運転/ルート効率化どちらがよいか？）などに使います。これらが整っていない時は、RFPに書く要件が具体的にならないので、提案内容も各社バラバラのアプローチになり比較が難しくなります。

システム開発の定義を検討

まず、システム開発することを定義します。たとえば、今回のシステム開発は既存システムが無い分野に新規で開発するのか、現行システムを刷新するのかによって大きく方針が異なります。現行システムを刷新する場合、ほぼ確実に現行システムからのデータ移行が必要であり、求める業務要件も現行システム同様になるためです。

その他、既存システムに追加開発を行う場合、既存システムの保守ベンダーが保守することから、開発部分の引継ぎがプロジェクトタスクに入ります。ソースコードの著作権放棄も必要でしょう。

このように、システム開発のハイレベルのアプローチについては、検討を進めるべきです。

依頼先の選定

RFPを渡し、提案を依頼するシステムベンダーを選定します。これまでの実績、各所からの情報提供、検討しているシステムに強いベンダーなど、様々な観点を基に絞り込みを行います。

絞り込み対象は何社にすべきかですが、これは都度さまざまです。たとえば、選定するソリューションが事実上決まっているなどの随意契約の場合は1社になります。一般競争入札では送付ではなく公表という形を採るので、絞り込み自体を行っていません。一般的なシステム調達においては、できる限り2社以上を選定し、提案内容を比較検討できるようにします。ただし、10社20社と増やし過ぎると、調達プロセスにかかる対応が増大し、提案書の評価も大変になります。対象のシステムにもよりけりですが、一般的には3~4社程度までに抑えることが多いでしょう。

ヒアリング結果を具体化

自社のユーザー部門や、RFIで得たプロフェッショナルからの知見などを基に、RFPに記載すべき事項を具体化していきます。この時、ある質問に対し、真逆の回答が得られる場合も多くあります。その場合は、どちらの意見を採用するべきかを決定しなければなりません。時にはこの調整で苦労することもあるでしょう。

大きなシステムの調達を行う場合は、手分けして作業することが必要になります。この時は、後々作成するRFPの記載粒度がまちまちになることが無いよう、結果のまとめ方、具体化の仕方を標準化する基準（クライテリア）をあらかじめ作成しておくことも重要です。さらに、各人の担当箇所が重複したり、ポッカリと抜けがあったりしないよう、それぞれの役割と担当範囲をしっかり決める必要もあります。

RFPの作成・提出

いよいよRFPを作成します。RFPは最後に全体を通して読み込んで、統一感があるか、記載事項にコンフリクトが無いか、書くべきことが抜けていないかなどをチェックします。ここで前項のクライテリアや役割分担が出来ていたかどうかによって、RFPの出来が大きく異なります。

RFPの作成段階では、評価項目や配点の方法も決めておくべきです。少なくとも、足切り要件は明確にします。評価項目が決まっていれば、提案書に記載しなければ評価ができない項目も明確になります。したがって、RFPの記載の仕方にも影響があります。これがしっかりできていないと、提案してほしいアプローチとはまるで異なる”斜め上からの提案”が相次ぎ、再提案を求めることにもなりかねません。

RFP（提案依頼書）提出後の流れ

RFPを作成し、RFPの提出を依頼先に対して行ったら、そのRFPの説明を行わなければなりません。

RFPの提示時点で明らかにできなかった事項、後で見直して追加説明が必要と判明した事項については、説明会までに追加の説明資料を用意するとともに、追加の配布が行えるようにしましょう。

また、システムベンダーからも質問が出てくると思いますので、それらに答えられるようにQ&Aを用意しておくとよいでしょう。

その後、提案書や見積書などが提示されたら、それぞれの企業から依頼したい企業を選定し、契約を行います。

ベンダーからの質疑応答

説明会では、基本的にRFPの内容を漏らさず説明します。ただ、RFP提示後に記載が足りないと判明した事項もあるでしょう。この場合、追加資料なども用意して、分かりやすい説明会となるように準備します。

ベンダーからの質疑応答を効率的、正確に行うため、事前にQ&Aを用意しておくことも重要です。

また、説明会には日程が合わずに参加できなかった企業もあるでしょう。説明会で行った質疑応答内容は議事録に残したうえで、RFPを送付した全ベンダーに送付するべきです。これにより、情報の粒度に公平性を期すことができます。

見積書・提案書の提示

ベンダーから、見積書・提案書が提示されます。RFQのプロセスを用意している場合、RFP段階での見積書は概算見積の依頼に留めても構いません。時には、ベンダーから追加の質問や、他社の動向についての探りが入る場合もあるでしょう。

追加の質問があった場合、回答をすることで提案の質が向上すると思われる場合は、回答をしてもかまいません。ただし、公平を期すため、他のベンダーにも同時に回答を送付すべきです。また、他社動向の探りについては、たとえその企業が意向の企業であっても、行ってはなりません。自社の調達プロセスに対するガバナンス違反となり、最悪の場合は背任罪などの刑事事件になる可能性もあります。

場合によっては、提案書の提示が遅れるケースがあるかもしれません。基本的に遅延は許可されるべきではありませんが、応札企業が少なすぎる場合などは、期間延長のプロセスが行われる場合もあります。ただし、いざ期限が訪れてから検討するべきものではなく、RFP提示の時点で、1社以下の提出だった場合は再調達とするなど、事前にルールを決めてRFPに明記しておくべきです。

ベンダー選定と契約

提案書・見積書が提出されれば、評価を行って比較検討し、ベンダーを選定します。一般的には、提案書の提出後にベンダーからの提案内容の説明を受けるプロセスを用意します。ここでは質問事項をあらかじめ用意し、ベンダーが回答を準備できるように事前送付しておくことが望ましいです。

提案内容の説明は各社合同では行いませんので、通常は説明日を設け、1社ずつ入室してもらい、時間を分けて開催します。充分な質疑応答が時間内に行えるように時間を設定しましょう。

開発ベンダーが確定すれば、契約書の締結になります。契約書の文言の調整には、両社の譲れない事項などもあるため、RFP提示時点で契約書のひな型を提示し、あらかじめ調整を行っておくべきです。なお、公共入札においてはRFPに相当する「調達仕様書」が契約書そのものの扱いになります。このため、RFPそのものが契約書としての法的拘束力を持つものになります。

RFPの書き方のコツ・注意点

RFPの書き方にはコツがあります。ポイントとしては、読み手が勘違いせず、誰もが同じ解釈をできるような記載にすることです。また、面倒でも必要な事項は漏らさず書き、阿吽の呼吸で”これはやるに決まっているだろう”というような思い込みを排除することです。

結果、同じような記載が各所に何度も登場して読みにくく冗長な文書になることもありますが、RFPとはそんなものだと諦めて、勘違いや漏れが起きないことを優先した文書にすべきです。

RFPの書き方は下記の4つのポイントが存在します。

プロジェクトの目的を明確にする

プロジェクトが何を目的に行われるのかを明確にします。実際に行うプロジェクトタスクは後段で明示していきますが、目的や目標が共有されることで、プロジェクト進行中に発生するさまざまなトラブルや新たな事実の発覚などに応じた方針変更において、双方の目線が合うことになります。

時には、調達者であるクライアント企業が考えていなかった、より良いアプローチをベンダーが提案してくることもあります。そのような提案を受けるためには、目的や目標を共有することが重要です。

関係各所と調整する

期待されている要求について具体的に記載する為、社内及びシステムベンダーに向けて定期的にミーティングを行い、ヒアリングすべきです。ヒアリングする際は漏れがないように議事録を取るようにしましょう。

そこから出された案を纏めて、RFPに落とし込む必要があります。

ITベンダーを評価するシートを作成する

RFPを作成する際、ベンダーを評価するシートを作成しましょう。提案内容の評価だけでなく、委託先として実力が十分か、体制を用意できるかといった要素も重要な判断項目です。

どのような経験、実力、体制を持っているベンダーがふさわしいかを検討し、評価項目を整えておきます。RFPにもそれらを明記し、どのようなベンダーに提案をしてもらいたいか、絞り込みができるようにしておきます。

時間をかけすぎない

RFPを作成する際、過度にヒアリングを行ったり、考えを纏めていると、作成する際に見えていたゴールと離れていってしまいます。その結果、本来の要件に沿わないRFPになってしまう可能性があるでしょう。基本的にRFPを作成する場合は、ある程度ヒアリングが固まって、方向性もある程度固まったら作成するようにしてしまったほうがいいかもしれません。

開発するシステムに期待することは網羅して記載する

RFPには、開発するシステムに期待することは網羅して記載しましょう。抜けがあると、開発しなくていいことの証明になります。システム開発には、言った・言わないといったトラブルがよく生じます。RFPに書いていないということは、言っていないということであり、”このようなシステムを開発するなら、やっていて当然だろう”という考えは通用しません。

よくあるのはセキュリティ要件です。たとえば、Web系システムにおいては完成前に脆弱性診断を実施することは、業界人としては常識と思います。しかし、要件に書かれていないために計画に無いことも多々見られます。契約後に発覚すると、ベンダーが実施してくれなかったり、追加費用が発生したり、スケジュールが延期になるなどの問題も生じます。

RFPには、クライアント企業がシステムベンダーに期待しているシステム環境構築、及びそれに付随するインフラに関する事、システム及びインフラ障害発生時の対応等も全て明記するようにします。

開発するシステムに期待することは誇張しない

RFPを作成する際には上記の他にも、現実的でない機能を盛り込んだり、誇張して記載してはいけません。

現実的でない要件をRFPで定義するとなると、どこのベンダーも手を上げてくれず、プロジェクト計画が早速暗礁に乗り上げてしまうこともあります。あるいは、それを実現するために膨大な工数をかけることになり、想定を大きく超える見積金額が提示されるかもしれません。

RFPを記載する際は、本当に必要な内容なのかを吟味し、現実的な内容を記載するようにしましょう。

社内の関係部署に必ず確認をとる

RFPを作成する場合は、システム担当者が記載する事が基本となりますが、システム担当者だけでRFPを作成するのは出来るだけ避けるようにしましょう。

まず社内でどのような機能を実装してほしいのか、それについて詳しく知っている人にヒアリングし、その人が関わっている部署に連携を取り、どのような経緯でシステムを実装してほしいのかを細かくヒアリングし社内で十分検討してからシステム担当者がRFPを作成するようにしましょう。

社内で十分検討しないままRFPを作成し機能を実装すると、社内からシステム担当者へクレームが発生する可能性があります。

まとめ：RFP（提案依頼書）はビジネス課題解決のために重要

RFPは、システムを調達する際に、ベンダーに正しくビジネス課題を伝え、それを解決するシステムを確実に調達するために欠かせない書類です。

複数のベンダー候補を平等に、的確に評価し最適な契約先を決定することを助けるとともに、今後生じる可能性のあるプロジェクトのトラブルリスクを軽減することにも寄与しています。

その記載事項は、誰が読んでも同じ解釈になるように、曖昧な表現を避け、細かく記載する必要があります。また、プロジェクトに関係する社内関係者が多い場合、その関係者間の合意形成も重要になります。

これらのことから、RFP作成はとても重要で、時間がかかり骨の折れる仕事でもあります。

RFP初心者にとって、誰の助けも得ずに素人集団だけで完成させるのは、その後のプロジェクトリスクの増大にもつながります。できれば、専門家の助けを借りて確実にリスクを軽減できるRFPを作っていくべきです。

もしRFPの作成についてお困りやお悩みがある場合、Jiteraへご相談ください。RFPの作成からシステム開発会社の探索・評価など、システム調達プロセスをご支援できます。