システム調達の流れと RFP・契約

結論：調達は「聞く→頼む→選ぶ→約束する」の4段

システム調達は RFI → RFP → 供給者の選定 → 契約の締結 の順に進みます。試験で最も多いのは、この4つを並べて空欄を埋めさせる問題です。

たとえるなら家のリフォームです。まず業者に「どんな工事ができますか」と情報をもらい（RFI）、次に「この条件で見積と提案をください」と依頼し（RFP）、出てきた提案を比べて1社選び、最後に契約書を交わします。

flowchart TD
  A["RFI：情報提供を依頼（目的・業務内容を示す）"] --> B["RFP：提案を依頼（調達対象・調達条件を示す）"]
  B --> C["供給者の選定：提案書・能力で決める"]
  C --> D["契約の締結：役割・責任分担を文書で確認"]

RFI と RFP の見分け方（ここが一番のひっかけ）

見分けるときは、問題文の動詞を見ます。「情報提供を依頼」なら RFI、「提案書の提出を依頼」なら RFP です。

キーワード対応：「情報提供」→ RFI、「提案書」「調達条件」→ RFP、「調達先を決定」→ 選定、「役割や責任分担を文書で確認」→ 契約です。

良い RFP の条件

RFP は「何を実現してほしいか」を、比較できる形で書いた依頼書です。要件定義の結果を機能要件（何ができるか）と非機能要件（性能・信頼性・セキュリティなど、どれくらいの質でできるか）に整理して載せます。

適切な対応（正解になるもの）

• 要件定義を機能要件・非機能要件にまとめて提示する
• 要求が複数あるなら、RFP を作る時点で重要度を決めておく（必須か、あれば望ましいか）
• 要求の実現性は、発注側でも事前に確認しておく
• 「何を実現したいか」を書き、製品名などの実現手段は指定しすぎない

不適切な対応（ひっかけの選択肢）

• 手間を省くため要求の記述を最小限にし、曖昧な点はベンダに都度確認させる
• 実現性の調査をベンダ任せにする
• 具体的な製品名や実現手段を細かく指定する
• 作業の完了時期をはっきりさせない
• 現行システムのプログラム仕様書をそのまま添付する（要件ではなく作り方の資料）

公正な選定：評価基準は「先に」決める

RFP を出したら、提案書が届く前に評価基準や重み付け（どの項目を何点で評価するか）を決めて、選定の手順を固めておきます。後から決めると、好きなベンダに合わせて基準を変えられてしまうからです。

ひっかけになるのは、特定のベンダを有利にする対応です。たとえば「現行システムを知っているベンダの評価を上げておく」「落ちたベンダに再提案の救済措置を用意する」「選定前に全社へ内示書を出して契約書づくりを頼む」といった選択肢は、どれも不公正なので誤りです。

総合評価落札方式：価格＋中身の合計点で選ぶ

総合評価落札方式は、価格と提案内容（技術点など）をそれぞれ点数にし、合計点が最も高い提案を選ぶ方式です。主に公共調達で使われます。

計算問題では、予定価格（発注者が上限として決めた価格）を超えた入札は、点数が高くても評価対象から外すことを忘れないでください。

契約タイプ：お金の払い方で3つに分かれる

契約タイプは「何に対してお金を払うか」で区別します。

たとえるなら、定額は「この料金で家を1軒建てます」、T&M は「職人1人1日いくら」の日当払いです。「償還」が出てきたら実費償還、「労務」が出てきたら T&M、「成果物＋決められた価格」が出てきたら一括請負と判断します。

契約が成立する書類：注文書＋請書

発注側が注文書（申込み）を出し、受注側が請書（承諾）を返すと契約が成立します。RFI・RFP・提案書は、契約前のやり取りに使う書類なので、契約書類ではありません。