ITパスポート|RFPとは?要件定義とシステム企画をやさしく解説
※ 本記事にはアフィリエイトリンク(PR)を含みます。
RFP(アールエフピー。Request for Proposal。提案依頼書)とは、発注先の候補に「この条件で提案してください」と正式に依頼する文書です。ITパスポートでは、RFI→RFP→提案書→見積書という調達の流れが繰り返し問われます。
この記事では、システムを手に入れるまでの段取り(システム企画)を、「注文住宅の家づくり」に例えて一本道で解説します。
「RFIとRFP、1文字違いでどっちがどっちだか…」と混乱しますよね。わかります。でも大丈夫。この分野の段取りは、家を建てるときの段取りとまったく同じ順番なんです。流れが一本につながれば、順序を問う問題はそのまま得点源になりますよ。
この記事でわかること
システム化計画で決めること(全体スケジュール・費用対効果など)
要件定義のやり方と、機能要件・非機能要件の違い
RFI→RFP→提案書→見積書という調達の流れと、それぞれの役割
この記事の要点(先に結論!)
RFP(提案依頼書)とは、発注側がベンダー企業(システムを作って売る会社)に、システムの提案書の提出を正式に依頼する文書です。
RFI(情報提供依頼)はRFPより前に出す文書で、実現手段や技術動向の情報提供をベンダー企業に依頼するものです。
調達の流れは「RFI→RFP→提案書・見積書の入手→比較評価→契約」の順で、「I(情報)が先、P(提案)が後」と覚えます。
システム化計画とは、開発スケジュールや概算コスト、費用対効果など、システム化の全体像を明らかにすることです。
要件定義では、機能要件(何ができるか)と非機能要件(性能・セキュリティなど)を決め、利害関係者(その仕事に関わる人たち)で合意します。
1. システム企画ってなに?(家づくりの一本道)
会社が新しいシステムを手に入れるまでには、決まった段取りがあります。それがシステム企画です。順番はこうです。
システム化構想・システム化計画…どんなシステムを、いつまでに、いくらで作るか
要件定義…システムに求めることを、具体的な文章にまとめる
調達…作ってくれる会社を探し、比べて、契約する
これ、注文住宅の家づくりとそっくりなんです。どんな家に住みたいか構想を練り、間取りの要望書をまとめ、工務店から見積もりを取って選ぶ。この記事は最後まで、この家づくりの例えで進みますね。

なお、この記事は本書『いちばんやさしいITパスポート』の第5章「システム戦略」に対応しています。第5章は範囲が広いので3つに分けていて、この記事はシステム企画(システム化計画・要件定義・調達)の担当です。情報システム戦略やBPR・RPAは別記事(B05a)、SaaSなどのクラウドサービスは別記事(B05b)で解説しています。この記事で、第5章は完結です!
2. システム化計画:どんな家を・いつまでに・いくらで
2.1 いきなり工事を始めない(システム化構想)
家を建てるとき、いきなり大工さんを呼ぶ人はいませんよね。まず「どんな家に住みたいか」「予算はいくらか」を家族で話し合うはずです。
システムも同じです。最初に来るのがシステム化構想。「会社の作戦(情報システム戦略)に沿って、どの業務をシステム化するか」という大きな方針を描く段階です。システムを入れること自体が目的ではなく、経営の作戦をかなえる手段、という順番がポイントですよ。
2.2 システム化計画で決めること
構想が固まったら、システム化計画に進みます。システム化計画とは、対象の業務を分析して、システム化の全体像を明らかにすることです。家づくりでいえば、「構想ノート」を1冊にまとめる段階ですね。決めるのは、たとえば次のような項目です。
全体スケジュール…いつまでに完成させるか
体制…誰が(どの部署が)進めるか
費用対効果…かかるお金に見合う効果があるか
リスク分析…途中でつまずきそうな点はないか
適用範囲…どの業務までをシステム化するか

ポイントは、この段階で決めるのは「全体像と概算」までだということ。細かい機能を決めたり、実際に作り始めたりするのは、まだ先です。試験では「システム化計画で行うことはどれか」という形で、次の要件定義や開発との区別が問われますよ。
3. 要件定義:間取りの「要望書」を作る
3.1 要件定義とは
全体像が固まったら、次は要件定義です。要件定義とは、利用者のニーズを調べて、システムに求める機能や条件をはっきり定義することです。
家づくりでいえば、間取りの要望書を作る段階です。「部屋は3つ」「駐車場は2台分」のような要望をあいまいにしたまま工事に入ると、完成後に必ずもめます。だから工事の前に、紙に固めておくわけです。
3.2 機能要件と非機能要件の違い
要件定義で決める要件は、大きく2種類に分かれます。ここが試験の頻出ポイントです。
機能要件…システムが「何をできるか」の要件。処理の内容や、扱うデータなど
非機能要件…機能以外の要件。性能・信頼性・セキュリティ・使いやすさなど
家の要望書で例えてみましょう。「部屋が3つほしい」「対面キッチンにしたい」は間取りの要望、つまり機能要件。「地震に強く」「冬あたたかく」は住み心地と安心の要望、つまり非機能要件です。目に見える「できること」か、それを支える「品質」か、で区別しましょう。

3.3 利害関係者との「合意」が必須
もう1つ大事なのが、要件の合意です。要件は、システムの担当部署だけで勝手に決めてはいけません。実際に使う現場の利用者や、発注側・開発側といった利害関係者(その仕事に関わる人たち)みんなで確認し、合意します。
家づくりでも、間取りを1人で決めてしまったら、家族から不満が出ますよね。「使う人を置き去りにしない」。これが要件定義の鉄則です。
4. 調達:RFI→RFP→提案書・見積書の一本道
いよいよ、この記事の主役の調達です。調達とは、システムを作ってくれる会社を探し、比べて、契約するまでの活動のこと。相手となる、システムを作って売る会社をベンダー企業と呼びます。
家づくりでいえば、工務店選びです。いきなり1社に決めず、資料請求→見積もり依頼→比較、と進みますよね。調達の流れも、同じ一本道です。

4.1 RFI:まずはカタログ請求(情報提供依頼)
RFI(アールエフアイ。Request for Information。情報提供依頼)とは、RFPを作る前に、ベンダー企業へ情報提供を依頼する文書です。システム化の目的や業務の概要を示して、「実現できそうな手段や、最新の技術動向を教えてください」とお願いします。
家づくりでいえば、工務店へのカタログ請求・資料請求です。そもそもどんな工法や設備があるのか知らないと、要望も具体化できません。だから、まずは情報集めから始めるわけです。
4.2 RFP:正式な「提案依頼書」
情報が集まり、条件が固まったら、RFP(アールエフピー。Request for Proposal。提案依頼書)の出番です。RFPとは、ベンダー企業に対して、導入するシステムの概要や調達条件を示し、「提案書を出してください」と正式に依頼する文書です。
家づくりでいえば、「この予算・この要望で、御社のプランと見積もりをください」という正式な依頼状です。複数の工務店に同じ条件を渡すからこそ、あとで公平に比べられるんですね。
ここで覚え方をひとつ。RFIのIはInformation(情報)、RFPのPはProposal(提案)。つまり「I(情報)が先、P(提案)が後」です。試験では、この順序と役割の違いが穴埋め形式でよく問われます。

4.3 提案書と見積書:ベンダー企業からの返事
RFPを受け取ったベンダー企業は、2つの文書を返してきます。
提案書…RFPをもとに検討した、システム構成や開発手法などの提案
見積書…開発・運用・保守などにかかる費用を示した文書
工務店からの「プラン(間取り図と工法)」と「お見積もり」ですね。発注側は、あらかじめ作っておいた選定基準に沿って各社の提案を比較評価し、調達先を選びます。そのあと契約締結へ進み、完成したら注文どおりかを確認する受入れ・検収(家でいう完成検査と引き渡し)でゴールです。
4.4 調達で知っておきたい用語(グリーン調達など)
最後に、調達に関する用語を2つおさえておきましょう。試験では、名前と意味が分かれば十分です。
グリーン調達…環境への負荷が小さい製品やサービスを、優先して調達すること
AI・データの利用に関する契約ガイドライン…AI開発やデータ利用の契約の考え方を示した、経済産業省の手引き(現行は1.1版・令和元年12月。2026年7月時点)
5. まとめ:3行でふりかえり
システム企画は「構想・計画→要件定義→調達」の一本道で、注文住宅の家づくりと同じ段取りです。
要件定義では、機能要件(何ができるか)と非機能要件(性能・安心)を決め、利害関係者みんなで合意します。
調達は「RFI(情報ください)→RFP(提案ください)→提案書・見積書→比較して契約」。Iが先、Pが後です。
いかがでしたか?アルファベット3文字の文書名も、家づくりの段取りに置きかえれば怖くありません。まずは「Iが先、Pが後」から覚えてみましょう!
6. よくある質問(FAQ)
Q1. RFPとRFIの違いは何ですか?どちらが先ですか?
A. RFI(情報提供依頼)が先、RFP(提案依頼書)が後です。RFIは「どんな手段や技術動向があるか教えてください」という情報集めの文書で、RFPは条件を示して「提案書をください」と正式に依頼する文書です。RFIのI=Information(情報)、RFPのP=Proposal(提案)と覚えましょう。
Q2. 要件定義とは何ですか?
A. 要件定義とは、利用者のニーズをもとに、システムに求める機能や条件をはっきり決めて、利害関係者で合意することです。「何ができるか」を決める機能要件と、性能・信頼性・セキュリティなど機能以外を決める非機能要件があります。
Q3. 機能要件と非機能要件の違いは何ですか?
A. 機能要件は、システムが「何をできるか」という処理内容やデータの要件です。非機能要件は、性能・信頼性・セキュリティ・使いやすさなど、機能以外の品質の要件です。家の要望でいえば「部屋を3つ」が機能要件、「地震に強く冬あたたかく」が非機能要件にあたります。
Q4. システム化計画では何を決めますか?
A. システム化計画では、情報システム戦略に基づいて、全体スケジュール・体制・費用対効果・リスク分析・適用範囲など、システム化の全体像と概算を決めます。細かい機能を決めるのは次の要件定義、実際に作るのはさらに先の開発の仕事です。
おすすめ教材(PR)
システム企画は、計算のいらない「段取りと文書名」の分野です。RFI→RFPの流れをはじめ、順番と役割さえ整理すれば、そのまま得点源になります。
とはいえ、iパスの過去問は公式サイトや無料サイトでも解けます。参考書は必ずしも必須ではありません。
それでも1冊ほしいなら、この記事とそのまま並走できる、こちらがおすすめです。この記事は、次の本の第5章「システム戦略」に対応します。
『【令和8年度】いちばんやさしいITパスポート 絶対合格の教科書+出る順問題集』
章立てがこのシリーズ(B01〜B15)と対応しているので、記事と本を行き来しながら進めやすい1冊です(2026年7月時点)。くり返しますが、これがなくても合格はできます。でも、あると近道になりますよ。
次に読む
【この記事の確認問題】
【次の記事】
【前の記事】
【シリーズの目次】:ITパスポートの出題範囲 全体地図
この記事を書いた人
simic(IT資格ノート)。文系・非エンジニアの視点で、つまずきやすいIT用語を「たとえ」でかみくだきながら、資格の勉強ノートを書いています。→ くわしい自己紹介:https://note.com/simic_0531/n/n5ed7f56f1ab9
最終更新:2026年7月
Amazonのアソシエイトとして、simic(IT資格ノート)は適格販売により収入を得ています。
