システム開発やERP導入を成功させるためには、ベンダーへ自社の要望を正確に伝える提案依頼書(RFP)の作成が不可欠です。しかし、「何から書き始めればよいかわからない」「要件定義の項目が漏れていないか不安」と悩む方も多いのではないでしょうか。本記事では、初心者の方でも迷わず作成できるよう、RFPの基礎知識から具体的な書き方、そしてすぐに実務で使える無料のRFPテンプレートまでをわかりやすく解説します。RFPを正しく作成することで、自社の経営課題を解決に導く最適なシステムとベンダーを選定できるようになります。
【この記事でわかること】
・RFP(提案依頼書)の基本的な役割と作成する目的
・すぐに使える実用的な無料RFPテンプレートの入手方法
・失敗しないRFPの書き方とベンダー選定を成功に導くポイント
RFPとは?基礎知識と作成する目的
システム開発やITツールの導入を検討する際、必ず耳にする言葉がRFPです。RFPは、プロジェクトを成功に導くための羅針盤とも言える重要なドキュメントです。本章では、RFPの基本的な意味や、RFIとの違い、そして作成する本来の目的について詳しく解説します。
RFPの役割と重要性
RFP(Request for Proposal)とは、日本語で「提案依頼書」と呼ばれます。企業がシステム開発やソフトウェア導入を行う際、自社の抱える課題や要件を整理し、ITベンダーに対して具体的な提案を依頼するための公式な文書を指します。
RFPを作成する最大の目的は、発注側と受注側であるベンダー間の認識のズレをなくすことです。口頭での説明や簡単なメモ書きだけでは、システムの仕様や期待する効果が正確に伝わらず、プロジェクトの後半になってから「想定していた機能がない」「追加費用が発生する」といったトラブルを招きかねません。要件や制約条件をRFPとして明文化することで、複数ベンダーから質の高い提案を引き出し、公平かつ客観的な比較検討が可能になります。
また、RFPと混同されやすい文書にRFI(Request for Information)があります。RFIは「情報提供依頼書」と呼ばれ、RFPを作成する前の段階で、ベンダーの企業情報や製品の一般的な機能、導入実績などを収集するために用いられます。両者の違いを以下の表にまとめました。
| 項目 | RFI(情報提供依頼書) | RFP(提案依頼書) |
|---|---|---|
| 目的 | ベンダーや製品に関する基礎情報の収集 | 具体的なシステム提案と見積もりの取得 |
| 発行時期 | プロジェクトの初期段階(要件定義前) | 要件が固まった段階(ベンダー選定時) |
| 記載内容 | 自社の概要、情報提供の依頼事項 | システム要件、業務課題、予算、スケジュール |
| ベンダーの回答 | カタログ情報、会社案内、一般的な事例 | 課題解決のための個別提案書、詳細な見積書 |
このように、まずはRFIで広く情報を集め、自社の要件を整理したうえでRFPを発行するというステップを踏むことが、システム調達における標準的なプロセスとなっています。適切なプロセスを経ることは、独立行政法人情報処理推進機構(IPA)などが提唱するシステム開発のガイドラインにおいても推奨されており、確実なプロジェクト推進の土台となります。
ERP導入におけるRFPの必要性
近年、企業のDX(Digital Transformation)を推進する基盤として、ERP(Enterprise Resource Planning)の導入やリプレイスが活発に行われています。会計、人事、販売、生産などの基幹業務を統合管理するERPの導入においては、一般的なシステム開発以上にRFPの存在が不可欠です。
ERP導入プロジェクトは、企業の業務プロセス全体に多大な影響を与えます。そのため、単なる機能の比較ではなく、自社のビジネスモデルや将来の経営戦略にいかにフィットするかがベンダー選定の鍵を握ります。もしRFPを作成せずにベンダーの標準的なデモンストレーションだけで製品を決定してしまうと、導入後に「自社の特殊な商習慣に対応できない」「現場の業務負荷が逆に増えてしまった」という事態に陥るリスクが高まります。
ERP導入に向けたRFPでは、現状の業務フローと目指すべき理想の業務フローを明確に定義し、標準機能で対応する範囲と、カスタマイズやアドオン開発が必要な範囲をベンダーに見極めてもらう必要があります。さらに、他システムとの連携要件や、データ移行の計画、稼働後の保守サポート体制など、基幹システムならではの複雑な要件を網羅的に記載しなければなりません。
緻密に作り込まれたRFPは、ERP導入という全社的な一大プロジェクトにおいて、経営層の期待と現場の要件をすり合わせ、最適なパートナー企業を見つけ出すための強力な武器となります。
rfp テンプレートの無料ダウンロード
導入するシステムやプロジェクトの規模にかかわらず、RFP(Request for Proposal)をゼロから作成することは、担当者にとって非常に労力がかかり、かつ専門的な知識が求められる作業です。そこで積極的に活用したいのが、各機関やITベンダーが無料で提供しているRFPのテンプレートです。本章では、汎用的に利用できる標準的なテンプレートと、より高度なシステム導入に特化したテンプレートの2つに大別し、それぞれの特徴やダウンロードした後の活用方法について詳しく解説します。
すぐに使える標準rfp テンプレート
初めてRFPを作成する方や、比較的小規模な業務改善プロジェクトを計画している企業にとって、複雑すぎるフォーマットはかえって作業の妨げになることがあります。ここでは、必要最低限の項目が網羅され、どのような業種やプロジェクトにも適用しやすい標準的なRFPテンプレートについて解説します。
標準テンプレートを利用する最大のメリットは、プロジェクトの目的や現状の課題、求める要件といった基本事項を漏れなく、かつ論理的に整理できる点にあります。多くのITコンサルティング会社や公的機関が、WordやExcel、PowerPointといった一般的なオフィスソフトで扱いやすいフォーマットを無料で公開しています。文書の構成を考える時間を大幅に削減し、自社の要件を深く掘り下げるという本来の重要な作業に集中できるようになります。
特に信頼性が高く、ベースとしておすすめなのが、公的機関が提供している資料を参照する方法です。例えば、IPA(独立行政法人情報処理推進機構)では、システム構築を成功に導くための要件定義のポイントや、提案依頼に関する様々なガイドラインを公開しています。これらを参考に自社用の標準テンプレートを作成することで、ベンダーに対して的確に要件を伝えることが可能になります。
標準的なRFPテンプレートに含まれる主な項目と、その作成時のポイントは以下の通りです。
| 大項目 | 記載内容の概要 | 作成時のポイント |
|---|---|---|
| プロジェクトの概要と背景 | システム導入に至った背景、目的、解決したい経営課題、目標とする定量的・定性的な効果 | ベンダーが提案の方向性を定めるための羅針盤となります。自社の経営戦略と紐づけて、なぜ今このプロジェクトが必要なのかを明確に記載します。 |
| 提案依頼の対象範囲 | システム化の対象となる業務範囲、対象となる部署や拠点、想定される利用予定人数 | どこまでをベンダーに委託するのか、自社で対応する範囲はどこかを明確に切り分けます。対象外とする業務(アウトオブスコープ)も明記するとトラブルを防げます。 |
| スケジュール要件 | 提案書の提出締切、選考・プレゼンテーション期間、システム開発からテスト、本番稼働までの希望日程 | 無理のない現実的なマイルストーンを設定します。また、ベンダーからの専門的な視点に基づく代替スケジュールの提案も受け入れる余地を残しておくことが重要です。 |
| 予算要件 | 初期導入費用(ライセンス費用や開発費)、ランニングコスト(保守・運用費用)の上限や目安 | 予算の枠組みを示すことで、ベンダーは実現可能な範囲での最適なソリューションを提案しやすくなります。費用対効果を測るための重要な基準となります。 |
これらの項目を順番に埋めていくだけで、自社の要望が体系的に整理され、社内関係者間での認識のズレを防ぐことができます。また、Word形式のテンプレートは文章での詳細な説明に向いており、Excel形式は機能一覧や要件の○×判定など、定量的な比較を行う際に適しています。用途に合わせて適切なフォーマットを選択し、自社の状況に合わせてカスタマイズすることから始めてみてください。
システム導入向けrfp テンプレート
ERP(Enterprise Resource Planning)や大規模な基幹システムの刷新、あるいは全社的なSaaS(Software as a Service)型のクラウドサービスの導入など、より専門的で複雑なITプロジェクトにおいては、標準テンプレートだけでは要件を正確に伝えきれない場合があります。そのようなケースでは、システム導入に特化した詳細なRFPテンプレートを利用することが不可欠です。
システム導入向けのテンプレートでは、現行の業務プロセス(As-Is)と目指すべき理想の業務プロセス(To-Be)の詳細な記述をはじめ、既存システムとのデータ連携、移行計画、さらには非機能要件など、技術的かつ専門的な項目が深く掘り下げられています。特に近年主流となっているクラウドERPの導入においては、自社の業務をシステムに合わせる「Fit to Standard」の考え方が重要となるため、標準機能でどこまで対応できるかをベンダーに見極めてもらうための詳細な業務要件の提示が求められます。
システム導入において特に重要かつ専門知識が求められるのが「非機能要件」の定義です。これについては、IPAが定義する「非機能要求グレード」を参考に項目を網羅することが一般的です。以下の表は、システム導入向けRFPで必ず押さえておくべき技術的な要件項目を整理したものです。
| 要件区分 | 具体的な記載項目例 | システム導入における重要性 |
|---|---|---|
| 機能要件 | 画面レイアウト要件、帳票出力要件、外部システム連携(API連携など)、権限管理・承認ワークフロー機能 | ユーザーが直接触れる部分であり、日々の業務効率化に直結します。必須機能(Must)とあったら便利な機能(Want)を明確に分けて記載することがコスト最適化の鍵です。 |
| 非機能要件(性能・拡張性) | 同時アクセス数、トランザクション処理量、レスポンスタイムの許容範囲、将来的なデータ増加やユーザー増への対応 | システムの快適性や、将来の事業拡大にシステムが耐えうるかを決定づける重要な指標です。ピーク時の負荷を想定した数値を提示します。 |
| 非機能要件(セキュリティ) | アクセス制御、データの暗号化、監査ログの取得期間、脆弱性対策、バックアップ方針と復旧目標時間(RTO/RPO) | 企業の大切な情報資産を守るため、決して妥協できない項目です。自社のセキュリティポリシーと整合性を取り、具体的な基準を示します。 |
| 移行・運用保守要件 | 旧システムからのデータ移行手法とスケジュール、稼働後のサポート体制、障害発生時の対応フローとサービスレベル(SLA) | 導入後の安定稼働を担保するために不可欠です。ベンダーのサポート範囲、対応可能時間帯、エスカレーションの仕組みを明確にします。 |
このような高度なテンプレートは、システム開発会社やITコンサルティングファームのウェブサイトからダウンロードできるほか、中小機構(独立行政法人中小企業基盤整備機構)が提供するIT導入支援のガイドラインやツール類の中にも、RFP作成に役立つ実践的なフォーマットが含まれています。これらを活用することで、専門的な知見が不足している企業であっても、ベンダーから質の高い提案を引き出すための強固な土台を構築することができます。
システム導入向けのRFPを作成する際は、単にダウンロードしたテンプレートの空欄を埋めるのではなく、自社の経営課題の解決や業務フローの抜本的な改善という根本的な目的に立ち返りながら記述することがプロジェクト成功の鍵となります。テンプレートはあくまで要件を整理するためのツールであり、そこに魂を吹き込み、実効性のある内容にするのはプロジェクトメンバーの深い議論と社内での合意形成に他なりません。
失敗しないRFPの書き方と必須項目
RFP(Request for Proposal)を作成する際、単に欲しい機能の羅列になってしまったり、提案内容をベンダーに丸投げしてしまったりすることは、システム導入が失敗に終わる典型的なパターンです。自社の目的や要件を正確かつ論理的にベンダーへ伝えることが、失敗しないRFP作成の最大の鍵となります。本章では、RFPに必ず盛り込むべき必須項目と、プロジェクトを成功に導くための具体的な書き方の手順について詳しく解説します。
経営課題を明確にする
RFPの冒頭で最も重要になるのが、システム導入の背景にある「経営課題」をベンダーに正しく理解してもらうことです。ベンダーは、提示された課題を解決するための手段としてシステムを提案します。そのため、課題の定義が曖昧なままでは、自社のビジネスに真に貢献する提案を引き出すことはできません。
まずは、売上の低迷、コストの増大、属人的な業務プロセスの限界など、現在企業が直面している根本的な問題を明文化します。単なる現場の不満にとどまらず、経営層がどのような危機感を抱き、システム導入によってどのような事業目標を達成したいのかを言語化することが重要です。たとえば、「業務効率化」という言葉一つをとっても、それによって残業時間を削減したいのか、空いたリソースを新規事業に振り向けたいのかによって、ベンダーからの提案内容は大きく変わってきます。
現状のシステム課題と目指すべき姿
経営課題を提示した後は、現状の業務プロセスやシステムが抱えている具体的な課題(As-Is)と、システム導入後に実現したい理想の姿(To-Be)を対比させて記載します。このギャップを明確にすることで、ベンダーは「何を解決すべきか」を正確に把握できるようになります。
現状(As-Is)の可視化
現在利用しているシステムの構成、データの流れ、他システムとの連携状況、そして現場のユーザーが感じている不便な点などを詳細に洗い出します。ここでは、業務フロー図やシステム構成図を添付すると、ベンダーの理解がより一層深まります。また、ハードウェアの老朽化や、保守サポートの期限切れといったインフラ面の課題も忘れずに記載してください。
目指すべき姿(To-Be)の定義
新しいシステムが稼働した後に、業務プロセスがどのように改善され、どのような状態になっているべきかを具体的に描きます。目指すべき姿を明確にすることで、プロジェクトのゴールが共有され、導入後の効果測定も容易になります。定性的な目標だけでなく、「月次の決算業務を5営業日から3営業日に短縮する」といった定量的な目標を添えることで、提案の精度はさらに向上します。
業務要件とシステム要件の整理
RFPの中核をなすのが、業務要件とシステム要件の提示です。ここが曖昧だと、導入後に「欲しかった機能がない」「現場の運用に合わない」といったトラブルの原因となります。要件は可能な限り具体的に、かつ優先順位をつけて記載することが求められます。
業務要件の定義
業務要件とは、新しいシステムを使って「どのような業務を行いたいのか」をまとめたものです。各部門の担当者へのヒアリングを通じて、必要な機能や業務ルールを洗い出します。この際、既存の業務フローをそのままシステム化するのではなく、システム導入を機に業務プロセス自体を見直し、標準化・効率化を図る視点が不可欠です。購入品/内製品の管理フローなど、自社特有の商習慣がある場合は、その詳細も漏れなく記載します。
システム要件と非機能要件の定義
システム要件では、業務要件を実現するために必要なITシステムとしての仕様を定義します。対応すべきデータ容量、連携が必要な周辺システム(例:既存のPLM/ERPなど)、対応デバイスなどを明記します。
さらに見落としがちなのが「非機能要件」です。非機能要件とは、システムの性能、可用性、セキュリティ、保守性など、目に見える機能以外の裏側を支える要件のことです。非機能要件の定義が不十分だと、稼働後にシステムのレスポンスが極端に遅くなったり、障害時の復旧に多大な時間がかかったりする致命的なリスクが生じます。
RFPの必須項目一覧
ここまで解説した内容を踏まえ、RFPに最低限含めるべき必須項目を以下の表に整理しました。テンプレートを作成・活用する際のチェックリストとしてご活用ください。
| 大項目 | 中項目 | 記載すべき内容のポイント |
|---|---|---|
| 1. プロジェクトの概要 | 導入の背景と目的 | 解決すべき経営課題、システム導入によって達成したい目標(定量的・定性的) |
| プロジェクトの範囲(スコープ) | 対象となる業務部門、対象外とする範囲、関連する拠点や子会社 | |
| スケジュールと予算 | システム稼働の希望時期、マイルストーン、概算予算の枠組み | |
| 2. 現状と目指すべき姿 | 現状の課題(As-Is) | 現行システムの構成、業務フローの課題、インフラの制約 |
| 新システム導入後の姿(To-Be) | 業務プロセスの改善案、システム化による期待効果 | |
| 3. 提案依頼事項(要件) | 業務要件 | 各業務プロセスで実現したい機能、必要な帳票や画面のイメージ |
| システム要件・非機能要件 | システム基盤(クラウド/オンプレミス)、セキュリティ基準、可用性、性能要件 | |
| 4. ベンダーへの依頼事項 | プロジェクト体制と役割分担 | ベンダー側に求めるプロジェクト管理体制、自社との役割分担 |
| 保守・運用要件 | 稼働後のサポート体制、障害時の対応フロー、SLA(Service Level Agreement) | |
| 5. 提案手続きに関する事項 | 提出物の指定 | 提案書のフォーマット、見積書の明細粒度、提出期限 |
| 評価基準 | ベンダー選定において重視するポイント(機能適合率、コスト、実績など) |
これらの必須項目を網羅し、論理的な構成でRFPを作成することで、ベンダーとの認識のズレを防ぐことができます。また、要件定義の段階で自社のリソースだけでまとめるのが難しい場合は、外部のコンサルタントを活用したり、公的なガイドラインを参考にしたりすることも有効な手段です。
ERP導入を成功に導くRFP作成のポイント
ERP(エンタープライズ・リソース・プランニング)の導入は、企業の根幹を支える重要なプロジェクトです。そのため、RFP(提案依頼書)を作成する段階で、単なるシステムのリプレイスにとどまらない視点を持つことが求められます。ここでは、ERP導入を成功に導くためのRFP作成のポイントについて詳しく解説します。
単なるデジタル化ではなく経営管理の型を作る
ERPの導入を検討する際、既存業務の効率化やペーパーレス化といった、表面的なデジタル化に終始してしまうケースが少なくありません。しかし、ERP導入の本質は、企業全体の経営管理の型を再構築することにあります。
RFPを作成する際には、現在の業務プロセスをそのままシステムに当てはめるのではなく、ベストプラクティスをベースにした標準業務プロセスへどのように移行するかを明記することが重要です。これにより、ベンダー側も単なるシステム要件だけでなく、業務改革を見据えた提案が可能になります。
| 視点 | 従来のシステム導入(デジタル化) | ERP導入(経営管理の型作り) |
|---|---|---|
| 導入の目的 | 現行業務の効率化・自動化 | 経営情報の可視化・全体最適化 |
| 業務プロセス | 現行プロセスを維持しシステムをカスタマイズ | 標準機能に合わせて業務プロセスを変更 |
| RFPでの記述内容 | 詳細な機能要件の羅列 | 実現したい経営課題と目指すべき業務モデル |
このように、RFPには「どのような経営指標をリアルタイムで把握したいのか」「どの業務プロセスを標準化したいのか」といった、経営層の視点を盛り込むことが不可欠です。購入品/内製品の原価管理や、部門間のデータ連携など、具体的な経営管理の要件を明確に伝えることで、より精度の高い提案を引き出すことができます。
MXを支えるプラットフォームとしてのERP
近年、デジタルトランスフォーメーション(DX)の先にある概念として、マネジメントトランスフォーメーション(MX)が注目されています。MXとは、経営そのものを変革し、変化の激しい市場環境に迅速に対応できる組織能力を構築することを指します。ERPは、このMXを支える重要なデータプラットフォームとして機能しなければなりません。
経済産業省の「DXレポート」などでも指摘されている通り、レガシーシステムからの脱却とデータの一元管理は、企業の競争力維持において急務となっています。RFPを作成する際には、ERPを単独のシステムとして捉えるのではなく、周辺システムとのデータ連携を前提としたアーキテクチャを要求することが求められます。
たとえば、設計部門と製造部門の連携を強化するためのPLM/ERPのシームレスな統合や、顧客管理システム(CRM)との連携による需要予測の高度化など、企業全体のデータを繋ぐ要件を記載します。部門間で分断されていたデータを統合し、経営判断に必要な情報を一元管理できる仕組みを構築することが、ERP導入の真の価値です。
また、クラウド型ERPの普及により、常に最新の機能やセキュリティ環境を利用できるようになりました。RFPには、将来的な事業拡大や組織再編など、ビジネス環境の変化に柔軟に対応できる拡張性やスケーラビリティについての要件もしっかりと記載しておくことが重要です。
RFP作成後の進め方とベンダー選定
RFP(Request for Proposal)を完成させ、複数のシステム開発会社やベンダーに配布した後は、いよいよ具体的な選定プロセスへと移行します。このフェーズでは、各社から提出される提案書や見積もりを客観的に比較し、自社の経営課題を解決できる最適なパートナーを見極めることが求められます。ここでは、RFP提示後から契約に至るまでの具体的な進め方と、ベンダーを選定する際の重要なポイントについて詳しく解説します。
提案書の評価基準
ベンダーから提出された提案書を評価する際は、あらかじめ明確な評価基準(評価シート)を設けておくことが重要です。担当者の主観や印象だけで決めてしまうと、システム導入後に「期待していた機能が足りない」「サポート体制が不十分だった」といったトラブルに発展するリスクが高まります。評価プロセスにおいては、複数の評価者による多角的な視点を取り入れ、定量的に採点する仕組みを構築することが不可欠です。
具体的な評価項目としては、大きく分けて「提案内容の妥当性」「プロジェクト管理能力」「ベンダーの信頼性」「コスト」の4つが挙げられます。以下の表は、提案書を比較検討する際に用いる一般的な評価基準の例です。
| 評価カテゴリ | 主な評価項目 | 評価のポイント |
|---|---|---|
| 提案内容の妥当性 | 機能要件/非機能要件の網羅性 | RFPで提示した要件をどの程度満たしているか。代替案や追加提案の有用性は高いか。 |
| プロジェクト管理能力 | 体制図/スケジュール/移行計画 | 導入に向けたスケジュールに無理がないか。プロジェクトマネージャーの経験やスキルは十分か。 |
| ベンダーの信頼性 | 実績/サポート体制/セキュリティ | 同業他社や同規模の企業での導入実績があるか。保守サポートの範囲やSLA(Service Level Agreement)は明確か。 |
| コスト | 初期費用/ランニングコスト | 見積もりの前提条件が明確であり、ライセンス費用やカスタマイズ費用が妥当であるか。5年間のTCO(Total Cost of Ownership)で比較できているか。 |
これらの基準をもとに各ベンダーの提案を採点し、上位数社に絞り込んだ上で、プレゼンテーションやシステムデモンストレーションを実施します。実際の画面操作やレスポンス速度を確認することで、書面だけでは伝わらないユーザビリティや操作性を評価することができます。また、デモンストレーションの場では、現場の業務担当者にも参加してもらい、実務に即した視点からの意見を取り入れることが推奨されます。
経営を可視化するシステム選び
ベンダー選定において最も重視すべきは、単にRFPの要件を満たしているかだけでなく、そのシステムが自社の経営をどのように可視化し、成長に貢献できるかという視点です。特にERP(Enterprise Resource Planning)や基幹システムの導入においては、部門間のデータ連携をスムーズにし、経営層がリアルタイムで意思決定を行える環境を構築することが最終的な目的となります。
システムを選定する際は、現場の業務効率化にとどまらず、経営指標であるKPI(Key Performance Indicator)をタイムリーに把握できるダッシュボード機能や、将来的な事業拡大に耐えうる拡張性を備えているかを厳しくチェックする必要があります。例えば、売上データと在庫データを連携させて利益率を瞬時に算出できるか、あるいは法改正や市場の変化に柔軟に対応できるクラウドベースのアーキテクチャを採用しているかといった点が重要な判断材料となります。
また、ベンダーとのコミュニケーションを通じて、自社のビジネスモデルや業界特有の商習慣を深く理解しようとする姿勢があるかどうかも確認してください。システム導入は数年単位の長期的なプロジェクトとなるため、単なる発注先と受注先という関係ではなく、ともに経営課題の解決に取り組むビジネスパートナーとして信頼できる企業を選ぶことが、プロジェクトを成功に導く最大の鍵となります。
よくある質問(FAQ)
RFPとは何ですか?
システム開発などを外部委託する際、ベンダーに具体的な提案を依頼するための文書です。
テンプレートは無料で使えますか?
はい、本記事で紹介しているテンプレートはすべて無料でダウンロード可能です。
RFP作成で最も重要なことは何ですか?
自社の経営課題とシステム導入の目的を明確にすることです。
ERP導入にRFPは必須ですか?
自社に最適なシステムとベンダーを選定するために不可欠なプロセスです。
作成期間の目安はどのくらいですか?
プロジェクトの規模にもよりますが、一般的には1〜3ヶ月程度かかります。
まとめ
RFPは単なる要望書ではなく、経営課題を解決しERP導入を成功に導くための重要な羅針盤です。本記事で提供している無料テンプレートを活用し、現状の課題と目指すべき姿を論理的に整理しましょう。また、事前に明確な評価基準を設けることで、自社の成長を支える最適なベンダーを選定することがプロジェクト成功の鍵となります。
- カテゴリ:
- RFP
- キーワード:
- RFP







