ITパスポート 令和5年度 問32：system_strategyに関する問題

答えは d です。

RFPとは「こういうシステムが欲しいんです、作ってくれる会社さん、提案書を出してください」とお願いする書類のこと。

つまり、システムを買う側（企業や役所）が、作る会社（ベンダー）に向けて『目的や必要な機能を伝えて、提案をください』と募集するための文書です。

👉 覚え方：RFP＝Request For Proposal＝『提案（Proposal）をください（Request）』！

ほかの選択肢：a は情報を集める段階のお願い（RFIの話）／b は性能の細かい取り決め（要件定義）／c はサービスの品質約束（SLAの話）。dだけが『提案を募る』内容です。

なぜこれが正解か

正解は d。RFP（Request For Proposal＝提案依頼書）は、発注者がベンダーに対しシステムの導入目的・機能概要・予算・スケジュールなどを示し、具体的な提案書の提出を求める文書。選択肢dの説明がそのまま定義に一致する。

各選択肢の解説

• a：ベンダーから技術情報を収集し実現性を把握する文書 → これはRFI（Request For Information＝情報提供依頼書）の説明。
• b：発注者とベンダーで性能要件などを定義 → これは要件定義の説明。
• c：サービス品質レベルの合意事項を列挙 → これはSLA（Service Level Agreement）の説明。

覚え方・ひっかけ注意

調達の流れは『RFI（情報収集）→ RFP（提案依頼）→ 提案・選定 → 契約』。Pは Proposal（提案）と覚える。RFIと混同しやすいので、I＝Information（情報）、P＝Proposal（提案）で区別する。

理論的背景

RFP（Request For Proposal＝提案依頼書）は、情報システムの調達プロセスにおける核心的な文書であり、発注者（ユーザー企業・官公庁）がシステム化の目的・背景・現行課題・要求機能・非機能要件・制約条件（予算・スケジュール・技術制約）・提案書の様式や評価基準を体系的に記述し、複数のベンダーから同一条件での提案を引き出すためのものである。

RFPの品質は後工程の成否を大きく左右する。要件の曖昧な低品質のRFPは、ベンダーの提案がばらつき客観的な比較が困難になるだけでなく、契約後の仕様変更・追加費用・認識齟齬によるプロジェクト失敗の温床となる。システム開発プロジェクトの失敗事例の多くが「上流工程（要件定義・RFP作成）の不備」に起因するという調査結果（IPA「情報システムの信頼性向上に関するガイドライン」等）は繰り返し報告されており、発注者側のIT調達能力が重要な経営課題とされている。

標準的な調達フローは「RFI（情報提供依頼）→ RFP（提案依頼）→ 提案書受領・評価→ ベンダー選定 → 契約締結 → 要件定義 → 開発」という順序をたどる。RFIで市場の技術動向・ベンダーの実績・実現可能性の情報を収集した後、RFPでより具体的な要求を示して提案を競わせる二段階アプローチが、特に大規模調達では標準的手順となっている。

実務での使われ方

政府・官公庁の調達では、RFPを公示して入札を実施する「競争入札」が原則であり、RFPの内容は行政文書として公開される場合も多い。内閣府デジタル庁・経済産業省はITシステム調達のためのRFPテンプレートを公表しており、機能要件・非機能要件（信頼性・性能・セキュリティ・運用・拡張性）の記述粒度に関するガイドラインも整備されている。

民間では、評価基準として「機能適合度・技術力・実績・提案価格・サポート体制・セキュリティ対応」などを重み付けしたスコアリング表（RFP評価マトリクス）でベンダーを比較する手法が一般的である。特に近年はクラウドサービス・SaaSの調達でも、要件整理とRFP作成の重要性が認識されており、ベンダー評価にセキュリティ認証（ISO 27001・SOC2）・SLA・データ主権（サーバ所在地）の確認が必須項目となっている。

試験での位置づけ

ITパスポートのシステム戦略・システム企画分野では、IT調達プロセスの文書名と役割の対応が頻出テーマである。RFI・RFP・SLA・SLM・提案書・要件定義書・契約書という調達から開発・運用にわたる一連の文書の位置づけを、プロセスの時系列順に整理しておくことが重要である。特に「RFI vs RFP」（情報収集か提案要請か）、「RFP vs SLA」（調達前の要求か契約後の品質合意か）という対比は毎回のように出題される。

上位資格の基本情報技術者試験では、共通フレーム（SLCP）における「システム化計画→要件定義→システム要件定義」のフェーズ関係や、システム監査における調達プロセスの監査視点まで問われる。また経産省「DX推進ガイドライン」においてもユーザー企業のIT調達能力向上が課題とされており、RFPを適切に作成できる人材の重要性が増している。

選択肢の発展補足

RFI（Request For Information・選択肢aの説明）：RFPの前段階として、特定のシステム・技術について「どのようなソリューションが市場に存在するか」「自社要件に対して技術的実現可能性はどうか」を幅広く収集するための文書。特定の提案を求めるのではなく、情報収集・市場調査が目的。回答したベンダーが必ずRFPを受け取れるとは限らず、情報提供義務もない。

要件定義（選択肢bの説明）：ベンダー選定・契約後に、発注者とベンダーが協働で「何を作るか」を詳細に確定する工程。RFP段階の「何を実現したいか（要求）」をより詳細化した「何をどのように作るか（要件）」に落とし込む。RFPは調達前・要件定義は契約後という時系列の違いが重要。

SLA（Service Level Agreement・選択肢cの説明）：システム導入・契約後の運用フェーズで、サービス提供者と利用者の間でサービス品質水準（稼働率・応答時間・インシデント対応時間など）を数値で合意する文書。RFPが「何を求めるか」の調達前文書であるのに対し、SLAは「どの品質を保証するか」の契約後文書であり、フェーズが根本的に異なる。