会社情報
採用情報
お問い合わせ
Article

RFP（提案依頼書）の書き方：システム導入プロジェクトを成功させる第一歩

高田晃太郎
RFP（提案依頼書）の書き方：システム導入プロジェクトを成功させる第一歩

統計や研究データを見ると、失敗の芽は実装前から生まれています。McKinseyの大規模ITプロジェクト分析では平均で予算超過45%、期待価値の未達が56%と報告されています¹。PMIの調査でも要件の不備は主要な失敗要因の一つに挙げられます²。共通点は明確です。何を達成したいのか、成功をどう測るのか、どの制約下で進めるのかが曖昧なままスタートしていること。RFP（提案依頼書）は、この曖昧さを構造化し、ベンダーの提案を比較可能にするための技術的・経営的インターフェースです。単なる書類ではなく、意思決定と実装を滑らかにつなぐ設計図として機能させましょう。ここで扱うSLO（サービス水準目標）やSLA（サービス水準合意）は、ユーザー体験と契約の双方を数値化するための基礎となります。

RFPの役割と成功条件

RFPはベンダーに発注内容を伝える文書ですが、実体は調達戦略とアーキテクチャ方針の具現化です。RFIは市場理解と仮説検証のために幅広く情報を集める段階、RFQは仕様が固まった後に価格見積を求める段階、RFPはこの中間に位置し、目的・スコープ・制約・評価基準を提示して創造的な解法を募ります³⁴⁵。重要なのは、解くべき問題を厳密に定義しながら、解き方はベンダーの専門性に委ねるバランスです。

成功するRFPは、ビジネスのゴールと技術の現実を同時に捉えます。短期のKPIと中長期のKGIを接続し、スコープの境界を明確に引き、非機能要件を数値で示し、リスクと仮定を明記します。さらに、提案の比較軸を事前に固定することで、価格・機能・運用コスト・セキュリティを同一平面で評価できるようにします。これにより、最安値ではなく総所有コストと成果の観点での合理的な選定が可能になります。SLO/SLI（サービス指標）で運用の基準値を固め、契約時にはSLAに落とす、という流れを意識して設計しましょう。

RFI/RFP/RFQの使い分けを戦略化する

未知が大きい領域では、最初にRFIで技術選択肢と概算のレンジを把握し、続けてフォーカスを絞ったRFPで具体的な実現方針を募るのが合理的です³⁴⁵。逆に、既に要件が確定している定型調達はRFQで十分です。RFPが解の一意性を前提にし始めたら黄色信号です。仕様の書き込み過ぎは比較可能性を下げ、イノベーションを抑制します。RFPは「何を、なぜ」を定量で示し、SLOの目安を提示する。SLAに関わる違約やクレジット条件の詳細は契約段階で詰める、という分業が現実的です。

問題を提示し、解法を縛らない

RFPに求められるのは「何を、なぜ、どこまで」を明確にすることです。たとえばUIフレームワークを名指しするのではなく、アクセシビリティの達成基準やパフォーマンスSLO（たとえばp95レイテンシ）を明示して判断を提案者に委ねる方が健全です。特定ベンダーの専有技術に依存する指定は、ロックインと将来の移行コストを増大させます。

「必須セクション」をどう書くか

RFPにはお作法のように見える章立てが並びますが、鍵は各セクションで意思決定に必要な情報を過不足なく定量で残すことです。まずビジネスゴールでは、単なる売上拡大やコスト削減といった抽象語を避け、現実の指標に落とします。例えば「コンタクトセンターの平均応答時間を6か月で20%短縮し、CSATを72から78へ引き上げる」といった表現です。これが後段の優先順位と受入基準の基礎になります。

スコープは包含と除外を対にして書くと境界が鮮明になります。たとえば「新規Webチャネルの構築を対象とするが、既存基幹の改修は対象外。ただしAPI公開のためのアダプタ開発は対象に含む」のように、グレーゾーンを先回りで潰しておくと、後の合意コストが減ります。

非機能要件は、パフォーマンス・可用性・セキュリティ・運用性の四象限で捉えると漏れにくくなります。パフォーマンスではピークトラフィック時の遅延とスループットをパーセンタイルで指定し、例えば「平常時p95=200ms、ピーク時p95=350ms、p99=500ms」という表し方にします。可用性は月間や四半期のSLOで指定し、99.9%なら月間許容停止は約43.2分、99.99%なら約4.32分です⁶。こうした値と併せてRTO（目標復旧時間）とRPO（目標復旧時点）を記載すると、設計・運用の最適化に直結します⁷。SLAに反映する前提として、監視・測定方法（SLIの定義）と報告頻度、違約時の取り扱い方針も概説しておくと、提案の精度が上がります。

データと統合の章では、データモデルの重要エンティティ、トラフィック特性、データ鮮度要件を言語化します。たとえば「会員テーブルは約1,200万件、日次増加2万件、同期は5分以内、整合性は最終的整合性で許容。ただし決済系は強整合性を要求」のように、領域ごとの差を明確にしておくと、提案のアーキテクチャ判断を比較しやすくなります。

セキュリティは標準に依拠して簡潔に。具体的にはISO 27001に準拠した運用、OWASP ASVSレベル2相当の対策、個人情報は暗号化保存（AES-256）と転送時TLS1.2以上、監査ログの保持12か月、脆弱性診断の頻度と責任分界など、検証可能な文言で記述します⁸⁹¹⁰。曖昧な「万全の対策」は技術的に意味を持ちません。運用時のセキュリティSLA（重大度ごとの修正期限の目安など）は、契約設計の論点として先に触れておくと齟齬が減ります。

スケジュールと成果物は、ステージゲートと受入条件を対で示します。例えば「アーキテクチャレビューの合格基準は、容量計画と障害時シナリオの整合が取れていること」「結合テストの合格基準は、主要ユースケース20本の自動化シナリオがp95遅延基準を満たすこと」と書くと、プロジェクトの進捗が測定可能になります。

評価基準は採点可能にすることが重要です。価格・技術実現性・運用適合性・セキュリティ・体制のように観点を分け、重みを設定します。例えば価格40%、技術実現性30%、運用適合性20%、セキュリティ10%とした上で、各観点のスコアリング根拠を記述します。ベンダーには「どの仮定の下でスコアが上がるのか」が見え、提案の質が上がります。

具体的な文例で粒度を合わせる

曖昧語を避けるには、良い例と悪い例のコントラストで自分たちの粒度感をチーム内でそろえるのが有効です。例えばパフォーマンス要件で「高速」と書く代わりに「会員検索APIは平常時p95で200ms以下、ピーク時でも350ms以下。タイムアウトは3秒、リトライ最大2回」と記すと、実装や容量計画の前提が揃います。障害対応では「重大度1のインシデントは15分以内に初動、60分以内に回復の見込みを顧客に通知、事後48時間以内にRCAを提出」のように、運用フローに落ちた表現にします。これらは後のSLA条項（一次対応時間や回復目標の合意）の雛形にもなります。

提案依頼のフォーマットを固定化する

比較可能性を担保するために、提案書の構成を指定します。例えば「アーキテクチャ概要、主要技術の選定理由、SLO達成の根拠、移行計画、体制とスキル、WBSの主要マイルストーン、リスク一覧と対応、概算見積（初期費用・月額・ライセンス・サードパーティ費用の内訳）」を必須項目として求めると、重要論点が漏れにくくなります。章立てを合わせること自体が品質管理の第一歩です。提案には、SLAを見据えた監視・測定方法（SLIの定義と収集方法）も明記させると、運用フェーズの透明性が上がります。

定量化と受入基準：失敗しないための数字

RFPは数字で語るほど強くなります。まずSLO/SLIでユーザー体験を定義します。レイテンシは平均ではなくパーセンタイルで、p90やp95、場合によってp99を使います¹¹。可用性は9の数で語るだけでなく、許容停止時間と回復戦略（アクティブ-アクティブかアクティブ-スタンバイか）までセットで指定します⁶¹²。99.9%は月間約43分、99.99%は約4分の停止を意味します⁶。これにRTO（目標復旧時間）とRPO（目標復旧時点）を添えると、バックアップ戦略やデータレプリケーション方式の選択が一貫します⁷。SLOは設計・運用のガードレール、SLAは契約上の合意水準として区別し、両者の整合を取ることが重要です。

スループットはピーク同時接続やTPSのレンジを記します。たとえば「平常時は平均200TPS、ピークはブラックフライデーに1,200TPS、バースト耐性は1,800TPS、暖機時間は5分以内」のように、時間軸の文脈を与えます。キャパシティ計画の根拠を提案側に求めるために、トラフィックの週次・月次・季節性のデータ提供もRFPの付属資料として用意します。

品質属性シナリオは、単一の数値よりも実践的です。例えば「決済中に片系AZが落ちてもユーザーの操作は継続でき、最大5秒以内にフェイルオーバー。ユーザーの再ログインを要求しない」といった振る舞いベースの記述は、設計判断の比較に有効です。

受入基準はテスト方法まで含めて定義します。「p95=200ms」を掲げるなら、どの環境で、どのツールで、どのデータ量で測るのかを合わせます。テストデータの匿名化方針、性能試験の再現手順、スモークテストの項目、合格・不合格の判定ロジックを文章で残しておくと、プロジェクトの終盤で争点になりがちな論点が前倒しで解消されます。運用監視でのSLI収集方法とSLAレポートの生成方法も、この段階で方向性を示しておくと移行が滑らかです。

移行とカットオーバーは、RFP段階でリハーサルの回数や判定基準まで決めると後戻りが減ります。例えば「ゼロダウンタイム移行は要求しない。ただし最大停止は90分まで、リハーサルは2回、リハーサル時にp95レイテンシとエラーレートを本番閾値の80%以内で達成すること」といった具体性が、現実的で安全な工程に結びつきます。

ベンダー選定と契約・運営まで見据えた設計

公平性と効率の両立が選定プロセスのテーマです。Q&Aは期限を区切って受け付け、回答は全社に同報します。個別説明の要求は原則断り、必要に応じて追加資料を一斉配布します。この運用ルールをRFPに明記すると、情報非対称による不公平感や後日のトラブルを避けられます。デモやPoCの評価観点も事前に宣言しておくと、提案の重心が合ってきます。

スコアリングモデルは、重みと判定基準をセットにして宣言します。例えば「価格40%は総所有コスト（3年）で比較し、初期費用・月額運用・ライセンス・サードパーティ費の内訳と前提を必須提出。技術実現性30%はSLO達成根拠とアーキテクチャの冗長化戦略で採点。運用適合性20%は監視・アラート設計、オンコール体制、変更管理プロセスの成熟度で評価。セキュリティ10%は脆弱性管理のサイクル、侵入テストの頻度、データ保護の実装で判断」といった具合です。数値化しておけば、選定の説明責任も果たしやすくなります。

価格の比較可能性を上げるため、見積フォーマットは固定します。初期費用と月額費用の内訳、クラウド利用料の扱い、第三者サービスのライセンス計算単位、想定トラフィックのレンジ、為替の前提、年次の単価改定ルールなど、後で増えがちな抜け道を初期から塞ぎます。これにより、入札後の「隠れコスト」発見という不毛な応酬を減らせます。

契約は不確実性に応じて設計します。要件が固い部分は固定価格、探索が必須の領域は準委任、というハイブリッドが現実的です。変更管理は小さなCR（Change Request）単位で影響分析と承認フローを定義しておきます。知財とデータの帰属、成果物の利用範囲、第三者コードのライセンス遵守、セキュリティインシデント時の通知義務と費用負担、SLA未達時のサービスクレジットなど、運用フェーズの論点もRFPで先に枠組みを作っておくと、契約交渉が滑らかになります。

運営を見据えた要求も重要です。SREの関与有無、IaCの提供範囲、監視ダッシュボードの移管、Runbookと訓練の頻度、オンコールの責任境界、プロダクトのメトリクス（SLI）を誰が維持するか。これらを明文化すると、移行後の保守コストと品質が安定します。アジャイルで進める場合は、スプリントレビューに発注側技術メンバーが必ず参加し、バーンダウンとSLOの達成状況を定点観測する運用を、要求として書いておきます。

すぐに使える短いテンプレート

以下は、重要論点の粒度を合わせるための短い雛形です。チームで自社用に調整して使ってください。

目的と成果: 6か月でCSATを72→78、平均応答時間を20%短縮。KGIは年内にチャーン率を0.8pt改善。
スコープ: Web新規チャネルの構築。基幹改修は対象外。ただしAPIアダプタ開発は含む。
非機能: 可用性99.9%（月間停止≦43分）。平常時p95=200ms/ピークp95=350ms。RTO=60分、RPO=15分。
セキュリティ: OWASP ASVS L2、PIIは保存時AES-256/転送時TLS1.2+、監査ログ12か月。
SLA: 重大度1は15分以内に一次対応・60分以内に復旧見込み通知。未達時はサービスクレジット案を提示。
評価: 価格40/技術30/運用20/セキュリティ10。3年TCOで比較。
提出物: アーキ概要、SLO/SLI達成根拠、移行計画、体制、WBS、リスク、詳細見積。
スケジュール: 提示後2週間でQ&A、4週間で提案締切、6週間で選定。

まとめ：RFPは「設計可能な未来」への投資

RFPは単なる調達書類ではなく、意思決定の質を上げるための設計ツールです。問題の定義を磨き、成果を数字で語り、比較軸を固定し、運用までの道筋を示すことで、プロジェクトの失敗確率は着実に下がります。完璧さを求めるより、仮説を明示し、検証可能な受入基準を置くことが現実的な第一歩です。

もし今日1時間確保できるなら、既存プロジェクトのSLOと受入基準を言語化し、次回のRFPテンプレートに反映してください。あなたのチームだけが知る現場の実測値と制約は、どのベンダーにも代替できない競争優位です。次のRFPでは、何を数値で語り、どこを開放して創造性を引き出しますか。

参考文献

  1. McKinsey & Company. Delivering large-scale IT projects on time, on budget, and on value. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value
  2. Project Management Institute (PMI). Causes of project failure (survey). https://www.pmi.org/learning/library/causes-project-failure-survey-engineers-4814
  3. Wikipedia. Request for information. https://en.wikipedia.org/wiki/Request_for_information
  4. SHIFT Inc. コラム: RFPとは？RFI・RFQとの違い. https://service.shiftinc.jp/column/11656/
  5. NTTデータ経営研究所. 調達におけるRFI/RFPの活用. https://www.nttdata-strategy.com/knowledge/reports/2023/230421_01/
  6. Better Stack. Uptime/availability SLA chart (downtime by nines). https://betterstack.com/community/guides/incident-management/availability-table/
  7. NIST SP 800-34 Rev.1. Contingency Planning Guide for Federal Information Systems. https://csrc.nist.gov/publications/detail/sp/800-34/rev-1/final
  8. ISO/IEC 27001: Information security management systems. https://www.iso.org/isoiec-27001-information-security.html
  9. OWASP. Application Security Verification Standard (ASVS). https://owasp.org/www-project-application-security-verification-standard/
  10. NIST SP 800-52 Rev.2. Guidelines for the Selection, Configuration, and Use of TLS Implementations. https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/final
  11. Google SRE Book. Service Level Objectives. https://sre.google/sre-book/service-level-objectives/
  12. AWS Well-Architected Framework – Reliability Pillar. https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html