このユニットの結論
良いRFP（提案依頼書）は、細かく書いてあるRFPではありません。
「何を実現したいか」と「守ってほしい条件」をはっきり伝え、「どう実現するか」は提案者に考えてもらい、しかも提案どうしを同じ物差しで比べられるRFPです。
1. 何の話か
このユニットは、RFPの質の話です。
02-02 RFIとRFPとは何か では、RFIとRFPの違いと、比べられるように条件をそろえることを学びました。このユニットでは、同じRFPでも、良い提案が集まるRFPと、集まらないRFPの違いを考えます。
2. なぜ必要か
RFPの質が低いと、
- 提案者が前提を想像で補い、提案ごとに範囲がばらばらになる
- 発注する側が方法まで細かく決めすぎ、提案者の工夫や経験が生かされない
- 大事な条件（非機能・移行・運用など）が書かれておらず、契約のあとで追加の費用になる
- 評価の方法が示されず、提案者が何に力を入れればよいか分からない
ということが起きます。RFPの質は、そのまま提案の質と、その後の契約・プロジェクトの進めやすさにつながります。
3. このユニットで分かること
- 良いRFPの5つの条件
- 「何を」と「どうやって」を分けて書く考え方
- RFPの見直しで、AIに任せてよいことと人間が決めること
4. 良いRFPの5つの条件
- 目的が書かれている：なぜこのシステムが必要か、何を実現したいか。提案者が、目的に照らして提案を工夫できる
- 範囲と境目が書かれている：対象の業務・システムと、対象にしないもの。ほかの会社やほかのシステムとの境目
- 要求に優先度がある：必ず満たしてほしいもの（必須）と、できれば満たしてほしいもの（希望）を分ける
- 条件と前提がそろっている：非機能（性能・止めてよい時間など）、移行、運用、使ってほしい仕組み、発注する側が用意するもの
- 答え方と評価の方法が示されている：回答の様式、見積もりの内訳の出し方、評価の観点
どれか1つが欠けると、提案を比べることも、あとで約束を確かめることも難しくなります。
5. 「何を」と「どうやって」を分ける
| 書き方 | 例（教材上の例） | 起きやすいこと |
|---|---|---|
| 方法まで決めて書く | 「画面は○○の部品を使い、夜間にファイルで連携すること」 | 提案者の工夫がなくなる。より良い方法があっても提案されない |
| 何を実現したいかで書く | 「営業の担当が、契約を登録した翌朝には、その内容を案件の管理で使えること」 | 提案者が方法を考える。方法ごとの長所・短所を比べられる |
ただし、会社として決まっている条件（使うべき認証の仕組み、守るべき安全の方針など）は、条件としてはっきり書きます。「何でも自由に」ではなく、決めていることは条件、決めていないことは提案を求める、と分けます。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件に関係する記載
- 大規模基幹システム刷新。約1,500件の要件、約36本のシステム連携、10年分のデータ移行
- マルチベンダー（Vendor A〜D の4社）
- 成果物に BUS-005 提案依頼書（RFP）、BUS-006 ベンダー評価表がある
- 実在の製品名を、案件の正式な名称として使わない（正本の方針）
アステリア案件のRFPの内容、出した時期、提案した会社の数、評価の結果は、正本に記載がありません。未確定
6. THINK — 要件を1,000行並べたRFP
（教材上の例）RFPの下書きができました。要件の一覧が1,000行以上並んでいますが、目的の説明は1段落だけで、必須と希望の区別はありません。担当者は次のように言っています。
「要件を全部書いたので、これ以上なく詳しいRFPです。」
問題
このRFPを、このまま出してよいでしょうか。
判断例を開く
判断
このままでは出さない方がよいでしょう。
確認すること:
- 提案者は、1,000行のうち何が大事かを判断できるか（必須と希望の区別）
- 目的が分からないまま、要件を満たすことだけが提案の中心にならないか
- 非機能・移行・運用・ほかの会社との境目は書かれているか
- 回答の様式と評価の観点は示されているか
量が多いことと、提案者に必要なことが伝わることは、別の話です。
7. よくある失敗
- 目的を書かず、機能の一覧だけを渡す
- 必須と希望を区別せず、すべてを必須にする
- 非機能・データ移行・稼働後の運用を書き忘れる
- ほかの会社やシステムとの境目を書かず、つなぎ目の作業がどの提案にも入らない
- 評価の方法を示さず、提案が出そろってから評価の方法を考える
- 提案者からの質問への回答を、全社に同じように共有しない
8. 成果物との接続
- BUS-005 提案依頼書（RFP）：RFPの構成と、比べられる提案を求める書き方
- BUS-006 ベンダー評価表：RFPで示した評価の観点で、提案を比べる
- REQ-002 要件一覧：RFPに載せる要件の出どころ
- REQ-003 非機能要件一覧：RFPで条件として示す非機能の要求
安さだけで選ばないための考え方は 02-04 一番安い会社を選べばよいのか で学びます。
9. AI WORKFLOW — RFPの抜けとあいまいさを探させる
AIは、RFPの下書きを、良いRFPの条件に照らして点検する下書きに役立ちます。
指示例:
「次のRFPの下書きを、①目的、②範囲と境目、③要求の優先度、④非機能・移行・運用の条件、⑤回答の様式と評価の観点、の5つに照らし、書かれていないもの・あいまいなものを挙げてください。要求や条件を補って書き足さないでください。」
10. REVIEW — AIの指摘を確認する
- AIが、書かれていない要求や数値を補っていないか
- 「一般的に必要」とされたものを、そのまま「今回必須」にしていないか
- 特定の会社・製品に有利な書き方になっていないか
- RFPを AI に渡してよいか（秘密の扱い）を、事前に確かめたか
ADVANCED深掘り — 実務者向けに一段深く
深掘り — 要求への適合表と、あいまいさの検査
要求ごとに答えさせる
RFP の要求に対して、提案者が「対応する・一部対応する・対応しない」を要求ごとに答える表を、回答の様式として付けます。世界で共有されている考え方では「適合表（コンプライアンス・マトリクス）」と呼ばれます。提案書の本文は各社で形が違いますが、適合表は同じ形になるため、要求ごとの比較がそのままできます。「一部対応」には、何が対応で何が対応でないかを書かせます。
「対応する」の意味を決めておく
適合表は便利ですが、「対応する」の意味がそろっていないと、全社が「対応する」と答えて差が出ません。標準の機能で対応するのか、追加の開発で対応するのか、業務の側が手順を変えて対応するのかを分けて答えさせます。追加の開発で対応する要求の数は、費用と期間の見積もりの根拠になります。
あいまいな言葉を出す前に検査する
RFP の要求に「速やかに」「柔軟に」「十分な」「適切に」のような言葉があると、提案者はそれぞれの解釈で答えます。出す前に、こうした言葉を機械的に探し、数値か条件に置き換えるか、置き換えられないなら「提案者に案を求める」と明記します。置き換えられない要求が多いなら、RFP を出す時期が早すぎる印です。
測り方の例
- 要求の数と、そのうち必須の数
- あいまいな言葉を含む要求の数（出す前と直したあと）
- 各社の適合表で「追加の開発で対応」とされた要求の数
現場で確かめる問い
- 回答の様式に、要求ごとの適合表があるか。「対応する」の意味は分けて答えさせているか
- 要求の文に、あいまいな言葉がどれだけ残っているか。数えたことがあるか
- 必須の要求のうち「追加の開発で対応」が多い会社と少ない会社で、費用の差を説明できるか
- 置き換えられないあいまいな要求を、「提案者に案を求める」と明記したか
アステリア案件の RFP の要求の数、適合表の有無、あいまいな要求の扱いは、正本に記録がありません。記録なし
11. 人間が判断すること
- 目的と範囲、対象にしないもの
- 必須と希望の区別
- 会社として決めている条件と、提案に任せること
- 評価の観点と重み
12. 判断演習
あなたは、RFPの下書きを見直す担当です。
「在庫の状況を確認できる画面を作ること」という要求を、「何を実現したいか」が伝わる書き方に直してください。直すために、業務の担当に確かめたいことも2つ挙げてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
良いRFPは、目的・範囲と境目・優先度・条件・評価の方法が書かれたRFPです。
決めていることは条件としてはっきり書き、決めていないことは提案を求めます。