RFQとは（RFPやRFIとの関係など）

RFQは正式名称「Request For Quotation」の略語で、日本語では「見積依頼書」と呼ばれており、後述するRFI（情報提供依頼書）やRFP（提案依頼書）とセットで用いられるのが一般的です。RFIやRFQを提示した後にシステム要件が明確になると、システム化に要する費用の情報が必要となります。その費用を把握するための文書がRFQ、すなわち「見積依頼書」です。

発出される際は、RFI「情報提供依頼書」→RFP「提案依頼書」→RFQ「見積依頼書」の順番が一般的ですが、「RFQ」が「RFP」と一体で発出される場合もあります。

RFIは正式名称「Request For Information」の略語です。RFIは「情報提供依頼書」と訳されているように、ITベンダーに対して会社情報・事業内容・技術情報・サービス情報などの提供を依頼する文書です。

求める情報はホームページに載っているような公知の情報というよりは、ベンダー選定に当たって必要となるより詳しい情報であり、求めるのは製品やサービスなどの導入先・導入事例・得意分野・製品スペックなどです。RFIには取引検討の意思を示す意味もあり、RFPの前に位置する依頼書と言えます。

RFPとは正式名称「Request For Proposal」の略語で、日本語では「提案要請書」や「提案依頼書」と訳されています。RFPは、システム導入や業務委託を進める際、発注先の候補となるSIerやベンダーに提案を依頼するためのもので、システム化の狙い・目標・システムの要件などが記された文書のことです。

RFPの作成はシステム開発や導入の実質的なスタートです。RFPの出来栄えがシステムの成否を左右します。ITエンジニアとしてはシステム概要書や要件定義書と同様に重要なドキュメントだと認識しましょう。

混同されやすい「要求仕様書」との違いは、RFPにはプロジェクトの要件や見積もり条件を含みますが、要求仕様書にはそれらを含みません。要求仕様書は機能要件や非機能要件が記載されます。

RFQ・RFI・RFPの3つをまとめて「RFx」と称します。RFxは元々、自動車業界を中心に調達・購買業務において用いられた手法で、IT分野でも用いられるようになりました。従来の経験や勘に頼らない、合理的・科学的な調達や購買を実現するために利用されています。

RFQの発出について

では、RFQはどのタイミングでどのような内容で発出するのでしょうか？これから、その流れ・文書の内容・注意点などを『Webサイトの構築』を例にして解説します。クライアント企業でコーポレートサイトの再構築が決まったという前提からスタートします。

1.社内でコーポレートサイトの再構築が決まる 2.ベンダーの選定条件を決定する 3.選定条件に合致すると思われる数社のベンダーにRFIを送付 4.数社からRFIの回答を貰い、候補ベンダーを3社に絞り込む 5.候補ベンダー3社にRFPを発出 6.候補ベンダー3社から提案書を受け取る 7.提案内容を検討し、提案内容が経営陣から高い評価を得たA社に内定、B社を次点とする 8.詳細見積もりの提示を求めるため、A社とB社にRFQを発出（あいみつ） 9.A社、B社から見積もり提示。A社の提示額がややB社を上回ったため、A社と価格交渉を行う。 10.交渉の結果、A社の提示額がB社を下回ったため、A社に正式決定。

以上ベンダー選定の一例として紹介しました。

RFQに記載するフォーマットについて、特に決まりはありません。業種・求める製品・サービスなどによって多少異なりますが、取引条件・支払い条件・支払い方法・納期・納品方法・明細・単価・数量・金額などは明記してもらう必要があります。

例えば、請負契約であれば成果物が納品され検収が済んだ後に費用を支払うのが一般的ですが、プロジェクトが長期の場合は前金を支払うこともありますので、支払いが一括なのか・分割なのかといった点も確認しておく必要があります。

▪RFQを発出する側 　RFQを用いてベンダーに見積もりを依頼する場合、RFIやRFPに対する回答をベンダーから受け取っていることが前提です。基本的にはベンダーからの提案を検討し、納品物に関する価格見積もりを受けるという流れになるので、RFIやRFPを抜かしていきなりRFQを発出するというケースは稀です。

▪RFQを受取って回答する側 　RFQを受け取ったベンダーは、RFPに対して回答した提案内容に基づいて見積もりを行い、RFQを発行したクライアントに見積回答書（見積書）を提出します。

RFQは損？メリットについて

RFPやRFQを依頼されて発行しても必ずしもクライアントに選ばれる訳ではありません。

他のベンダーが選ばれてしまうのはそう珍しいことではないため、「せっかく時間をかけて作成したのに選ばれない」「損ではないか？」とマイナスな感情になってしまうこともあります。RFPやRFQにはどのようなメリットがあるのでしょうか。

RFI・RFP・RFQをきちんと丁寧に作成することで、自社がどのようなベンダーなのかをクライアントへアピールすることができます。反対に、クライアント側が丁寧に作成してくれなかったと感じてしまうと信頼されにくく、受注に繋げることが難しくなります。

ビジネスは人対人なので、細かい部分で誠実さやベンダーとしての質が問われるため、RFI・RFP・RFQをきちんと作成することで信頼されやすくなります。

RFQを要求するのはシステム開発や大規模なサイト開設に活用するイメージですが、実は小規模のサイト作りでもベンダーにRFPやRFQを依頼した方がメリットがあります。どういったサイト作りがしたいのか具体的に明示することで、より精度の高いサイト作りが可能です。

また、RFQを依頼することでより多くのベンダーと関わり、積極的にコミュニケーションを取っていくことで自社に合う優秀なベンダーと出会えることが可能です。さらに、プロジェクトマネジメントが容易になったり、ナレッジの共有ができたりなど、さまざまなメリットがあります。

見積（回答）書の注意点

見積書は契約書ではありませんが、正式契約に至るための重要な書類です。RFQを受けて見積（回答）書を策作成・提出する上で注意すべきことがあります。

1.契約内容の確認 見積書の目的の1つは、契約内容の事前確認です。見積書作成によって契約内容が具体化され、金額や納品物、納品期日などが示され、契約の前工程として重要な位置を占めます。

2.価格や内容の比較 商品やサービスなどの購入検討の際、納品内容や価格を比較する上で見積書は重要です。特に複数社に対して同一条件で見積書作成を依頼し、価格や内容を比較することを「相見積もり」（略語：あいみつ）と呼びますが、実質的な購入や取引決定の要素となる見積書は大変重要な文書です。

続いて、見積書の書き方について簡単に紹介します。ITエンジニアの方が直接見積書を作成するケースは稀だと思いますが、営業SEやフリーランスになれば見積書の作成は仕事の1つになります。また、見積書作成をSEが手伝うケースもありますので、ここで覚えておきましょう。

1.タイトル 見積書用紙の最上部中央に「見積書」「御見積書」「お見積書」と表記します。

2.発注者側情報 誰に対する見積書なのかが分かるよう、見積依頼をした側の企業名・部署・役職・個人名（様）を記入します。

3.見積書発行日 右上に発行日を記入します。

4.見積書番号 社内に規定があれば、規定に従って番号を記入します。

5.受注側情報 右側の発注側の宛名より下の位置に、受注側の「企業名」「住所」「電話番号」「氏名」の4点を記入します。

6.社印 受注者側情報の会社名と住所に重なる位置の右寄りに押印します。社印は会社として正式に提示した見積書だということを示すためのものです。

7.見積書有効期限 クライアント側に発注を促す意味と、原価変動に備える意味で期限を明示します。

8.納期 発注から〇週以内、〇ヶ月以内というような書き方で記入します。

9.見積金額 見積提示額を記入します。小計・消費税額・合計金額を明確に記入します。出精値引きなどがあれば、値引き額を差し引いた額が合計金額になります。金額の記入ミスはトラブルの元になるので十分に注意しましょう。

10.商品やサービスなどの詳細 商品名・サービス名・項目名・数量・単価に間違えがないよう、またクライアントにも分かりやすく記入します。補足説明が必要な場合は備考欄に記入しましょう。

11.備考欄 全体に関する注意書き、個別の項目について補足説明が必要であれば備考欄に記入します。

以上、見積書に必要な項目を説明しましたが、頻繁に見積書を作成するのであればテンプレート化も検討しましょう。さらに、見積書作成システムをWebで構築し、プロジェクト管理や売掛管理システムなどと連動させるようにしておくとさらに効率的な管理が行えます。

ベンダー側が見積書をクライアントに提示した後、クライアントが注文書（発注書）を作成しますが、この手間を省くためにベンダー側が予め注文書を作成しているケースがあります。注文書があらかじめ用意されていると、発注者側は社印・役職印の押印・発注日の記入だけで済み、手間が省けるので大変効率的です。

注文書には法的拘束力はなく、法的拘束力を得るには双方で契約書を交わすか、ベンダー側が発注に対する注文請書を発行する必要があります。この一連の手続きを簡略化するために、見積書・注文書・注文請書をセットで用意しておくのも手です。

RFxを活用できるエンジニアに

見積依頼書の意味を持つRFQについて解説しました。また、RFQを含めた「RFx」の3点セットであるRFIやRFPについても、概要・違い・活用場面などについて述べてきました。

RFxは最適な調達や購買を進める上で必須のツールであり、ITの開発などにおいても大変有効な手法です。ITのプロジェクトは実質的にシステム化構想や検討の段階からスタートしますが、最初からRFxを活用することでシステム開発が円滑に進むでしょう。

効率的なシステム開発を阻害する主な要因として、クライアント側とベンダー側の理解や認識の食い違いがあります。この事で仕様変更が頻繁に起きたり、手戻りが発生したりします。RFQを含めたRFxは、こうした齟齬や頻繁な使用変更を最小限にするために極めて有効です。

ITエンジニアの皆さんは最適なシステム開発を進められるよう、まずはRFQをうまく活用しましょう。