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

答えは b です。

RFPは、システムを作ってほしい発注者（お客さん側）が、開発会社に向けて「こんなシステムを、この条件で作ってほしいです」とまとめて渡す“注文の希望書”です。家を建てるときに「3LDKで予算2000万、来年3月までに」と工務店へ伝える要望書のようなもの。これを見て開発会社が「では、こう作ります」と提案します。

👉 覚え方：RFP＝Request For Proposal＝「提案をください」と発注者がお願いする書類。

ほかの選択肢：a 開発会社からの提案文書／c 発注者と開発会社が一緒に作る設計書／d 社内の部門どうしのお願い文書——いずれも“発注者→開発会社への調達条件提示”ではありません。

なぜこれが正解か

正解は b。RFP（Request For Proposal＝提案依頼書）は、発注者側がITベンダーに対し、開発したい情報システムの目的・要件・予算・納期などの調達条件を示し、提案を依頼するために作成する文書。ベンダーはこれに基づいて提案書を返す。

各選択肢の解説

• a：ベンダーが自ら開発の必要性を提案する文書＝これは提案書（プロポーザル）側の説明。
• c：発注者とベンダーが共同で作る設計文書＝これは要件定義書や仕様書にあたる。
• d：ユーザー部門が情報システム部門に開発を要請する文書＝これはRFI（情報提供依頼書）やシステム化要求に近く、社内向けの位置づけ。

覚え方・ひっかけ注意

「RFP＝発注者がベンダーへ“提案ちょうだい”」と方向（発注者→ベンダー）を覚える。混同しやすいRFI（Request For Information＝情報提供依頼書）は、RFPの前段階でベンダーから一般情報を集める文書。RFI→RFP→提案書→契約、という調達の流れで整理する。

理論的背景

RFP（Request for Proposal：提案依頼書）は調達プロセスの中核ドキュメントで、発注者がITベンダーに対して「調達条件・業務要件・技術要件・評価基準・スケジュール・予算」を提示し、ベンダーから具体的な提案書・見積書を求める正式な招請文書である。RFPとRFI・RFQの関係を整理すると：RFI（Request for Information：情報提供依頼）はRFP作成前の市場調査として「どのようなソリューションが存在するか」を複数ベンダーに照会する文書。RFQ（Request for Quotation：見積依頼書）は仕様が固まった段階で「価格だけ」を問い合わせる文書。RFPはこの中間に位置し、「要件を示してソリューションと価格の両方を提案させる」という総合的な調達手段となる。IT調達における一般競争入札・企画競争入札（プロポーザル方式）ではRFPが法的根拠文書となる。

実務での使われ方

RFP作成は情報システム部門・調達部門・ユーザー部門の共同作業であり、RFPの品質がベンダー選定の公正性・導入プロジェクトの成否を大きく左右する。IPA（情報処理推進機構）は「RFP作成ガイドライン」を公開しており、記載すべき項目として「事業概要・現行業務概要・調達の目的・機能要件・非機能要件（性能・セキュリティ・可用性・保守性・移行性）・作業・規模感・評価基準・スケジュール・契約条件・機密保持要件」等が定義されている。ベンダー側はRFPに対してRFP説明会（Q&A）→提案書作成→ベンダープレゼンテーション→最終交渉というプロセスで対応し、受注したベンダーはRFPを要件定義書・契約書の基礎として活用する。クラウドサービス調達ではRFPに「セキュリティ・クラウド利用の責任分界点・データ所在地・監査対応可否」を明示的に盛り込む必要がある。

試験での位置づけ

RFPはITパスポートのシステム戦略・IT調達カテゴリで頻出。本問の識別ポイントは「誰が作成するか（発注者=ユーザー）」「誰に向けるか（ベンダー）」「目的（調達条件の提示・提案依頼）」の三要素を正確に押さえること。誤答パターンはaの「ITベンダーが作成する」という誤解（逆方向）と、dの「ユーザー部門→情報システム部門への要求文書」という混同（RFP類似の社内文書はRFIや業務要件定義書と呼ばれる）。近年は「RFPのDX対応」として「AI・クラウドを活用したシステム調達のRFP記述」や「SaaS調達でのRFPの簡略化（MSA：マスターサービスアグリーメント活用）」という実務発展形が出題に現れ始めている。

選択肢の発展補足

選択肢aのような「ベンダーからユーザーへの提案文書」はRFP（提案依頼書）への返答として作成される「提案書（Proposal）」に相当し、RFPの対応文書である。選択肢cの「発注者と受注者が共同作成する設計文書」は要件定義フェーズで作成される「要件定義書・基本設計書（仕様書）」に相当し、RFPとは調達フェーズ（RFP→契約→要件定義→設計）の順序で位置づけられる別文書。選択肢dの「ユーザー部門が情報システム部門に開発を依頼する文書」はITリクエスト（IT要求書・システム化要件定義依頼書）に相当し、社内調達の文脈で使われる。公共調達では「調達仕様書・競争参加資格確認申請書・入札説明書」という体系でRFPが組み込まれ、情報公開・ベンダーロックイン回避・競争性確保の観点から国・地方自治体のDX調達ガイドラインで詳細が定められている。