ITパスポート 令和4年度 問8：システム企画・調達に関する問題

答えは d「適用可能な技術とその動向」 です。

RFIは「情報をください」とベンダー（IT業者）に聞く段階。家を建てる前に、まず工務店に「今どんな建て方や素材がありますか？」と情報集めするのと同じです。だから業者側に出してほしいのは『どんな技術が使えるか』という情報。

👉 覚え方：RFI＝Request For Information＝『情報ください』。だから答えも“技術情報”。

ほかの選択肢：a 現行システムの概要／b 再構築の狙い／c 新システムに求める要件 → これらは“自社が業者に伝える側”の情報なので、業者に求めるものではない。

なぜこれが正解か

正解は d。RFI（Request For Information、情報提供依頼書）は、調達の初期段階で発注者がベンダに「実現できる技術や製品の情報を提供してほしい」と求める文書。よってベンダ側から提出を求める情報は d 適用可能な技術とその動向。

各選択肢の解説

• a 現行システムの概要、b システム再構築の狙い、c 新システムに求める要件：いずれも発注者がベンダに提示・提供する情報であり、ベンダから求めるものではない。

覚え方・ひっかけ注意

「誰が誰に出すか」を取り違えさせる問題。RFI＝情報ください（初期の情報収集）、その後のRFP＝Request For Proposal＝提案ください（具体的な提案・見積を求める）の順番をセットで覚える。a〜cは発注者が出す側、dだけベンダが出す側、と整理すれば即答できる。

理論的背景

ITシステム調達における書類体系は、プロジェクトの成熟度段階に対応して「RFI → RFP → RFQ → 契約」という流れで構成される。各文書の役割と発行の主体・方向性を正確に理解することが本問の核心である。

RFI（Request For Information：情報提供依頼書）：調達の最上流工程で、発注者が市場にある技術・製品・ソリューションの動向を収集する目的で発行する。複数ベンダへ同時発行し、各ベンダが「自社の技術や実績」を提供する。この段階では具体的な要件定義は未完成であり、むしろ市場の技術動向（選択肢d）を把握して後続のRFP要件の現実性を検証するのがRFIの本来目的。発注者は現行システム・再構築の狙い・要件（選択肢a/b/c）をベンダに提示する情報として整理するが、これらはベンダが「提出を求められる」情報ではなく、発注者が「提示する」情報という方向性の違いが本問のポイント。

RFP（Request For Proposal：提案依頼書）：RFI後に要件が固まった段階で、具体的なシステム要件・スコープ・納期・予算範囲を提示し、ベンダから実現方法・体制・概算見積の提案を求める。提案評価基準（技術点・価格点・体制点）を明示して公平な評価を可能にする。共通フレーム2013（IPA策定）でも調達プロセスの標準手順として定義されている。

RFQ（Request For Quotation：見積依頼書）：仕様が確定した後、ベンダに対して価格見積のみを求める文書。仕様の比較ではなく価格の比較が目的。

実務での使われ方

公共調達（国・自治体）では会計法・地方自治法に基づく競争入札が原則で、RFIに相当する「情報提供依頼」の手続きが調達規程に明記されている。民間企業でもITガバナンスの観点からRFI→RFP→評価→契約の標準調達フローを整備する企業が増えており、特に大規模基幹系更改（ERP導入・基幹クラウド移行）では数億〜数十億円規模の案件をベンダ中立に評価するため、RFIによる技術動向調査が必須のプロセスとなっている。

RFIへの回答を踏まえて「この技術は現時点では成熟していない・コストが見合わない」と判断し、調達仕様を修正したり、場合によって調達自体を延期するという意思決定支援機能もRFIは持っている。ゼロからRFPを書くよりも、RFI段階でベンダから最新動向情報を得ることで、実態に即した調達仕様が作れる点が実務上の最大のメリット。

試験での位置づけ

ITパスポートのシステム企画・調達分野で頻出。「誰が誰に何を提出するのか」という情報の流れ方向を問う問題パターンが定番。RFI・RFP・RFQの区別、発注者とベンダそれぞれの提出物の違いを整理することが正答への最短ルートとなる。

上位資格では、RFP評価の重み付け方法（AHP：階層分析法）、システム開発の請負契約と準委任契約の区別、ベンダ選定後の「SoW（Statement of Work：作業範囲記述書）」作成プロセス、公共調達での競争的対話（competitive dialogue）制度まで踏み込んだ問題が出る。

選択肢の発展補足

選択肢a（現行システムの概要）：現行システムの構成・処理量・連携先・課題点などは発注者が保有・整理する情報で、RFP段階でベンダへの参考情報として提供する「現状調査報告書」に相当する。現行システムを把握していないベンダは提案の精度が下がるため、発注者がRFP添付資料として提示するのが一般的。ベンダに「これを出してください」と求める性格の情報ではない。

選択肢b（システム再構築の狙い）：プロジェクトの目的・背景・課題認識は、発注者の内部で整理して経営層の承認を得た「基本計画書・システム化計画書」に記載される情報。これもRFPで発注者がベンダに提示する側の情報であり、ベンダが提出を求められる情報ではない。ただし狙い・ビジョンを明確に提示することで、ベンダが本質的な課題解決の提案をしやすくなる効果がある。

選択肢c（新システムに求める要件）：機能要件（業務機能・帳票・連携）・非機能要件（性能・可用性・セキュリティ・スケーラビリティ）を文書化した「要件定義書」に相当。これはRFPの核心文書であり、発注者がRFP段階でベンダに提示する情報。RFI段階ではまだ要件が固まっていないことも多く、RFI結果を踏まえて要件を精緻化するという関係性がある。要件定義の品質がプロジェクト成否を左右する最重要成果物とされる。