RFP 要件の抽出と整理

数十ページの提案依頼書から要件を漏れなく拾い、対応可否の検討にそのまま使える一覧表にする。要件の読み落としは失注か、受注後の赤字に直結する。

入力として受け取るもの

• RFP / 提案依頼書 / 入札仕様書（PDF / Word / Excel）
• 添付資料（現行システム構成、業務フロー、様式集、質問回答書）
• 自社の対応可否を判断する材料があれば、あわせて受け取る

質問回答書（Q&A）が公開されている場合は必ず読む。本文の要件が Q&A で変更されていることがある。

手順

1. 全ページを通読する。 目次から要件らしい章だけを拾わない。要件は前提条件、留意事項、様式の注記、スケジュールの中にも紛れている。
2. 要件を1文単位で切り出す。 「AおよびBを行うこと」は2つの要件に分ける。1要件1行にしないと、対応可否の判断ができない。
3. 要件ごとに該当箇所を記録する。 ページ番号と章番号を必ず紐づける。後から原文を確認できることが、この表の価値を決める。
4. 区分と強制力を判定する。 下記の分類に従う。
5. 提案側が判断すべき点を分離する。 対応可否、工数、リスクの列は空欄で出す。埋めるのは人。
6. 確認事項を洗い出す。 読み取れない要件、解釈が分かれる要件を質問案として出す。質問期限がある場合は先頭で伝える。
7. サマリを報告する。 全要件数、必須・任意の内訳、確認事項の件数、提出期限。

要件の区分

強制力の判定

原文の語尾で判定する。ここを取り違えると、必須要件を落とすか、不要な機能を見積もることになる。

判定できない場合は 要確認 とし、質問案に含める。

出力フォーマット

# RFP 要件一覧: <案件名>

- 発注者: <組織名>
- 提案書提出期限: YYYY-MM-DD
- 質問期限: YYYY-MM-DD
- 要件数: <全件> / 必須 <n> / 推奨 <n> / 任意 <n>
- 確認事項: <n> 件

## 要件一覧

| 要件ID | 区分 | 強制力 | 要件 | 該当箇所 | 対応可否 | 工数 | リスク・備考 |
|---|---|---|---|---|---|---|---|
| R-001 | 機能 | 必須 | 申請データを CSV で一括登録できること | p.12 3.2.1 | | | |
| R-002 | 非機能 | 必須 | 同時接続 500 ユーザーで応答 3 秒以内 | p.18 4.1 | | | |
| R-003 | 体制 | 推奨 | PMP 保有者を配置することが望ましい | p.24 5.3 | | | |

対応可否・工数・リスクの列は提案側が記入する。

## 確認事項（質問案）

| # | 該当箇所 | 読み取れない点 | 質問案 |
|---|---|---|---|

## 提出要件

| 項目 | 内容 |
|---|---|
| 提案書の様式 | |
| 提出部数・媒体 | |
| 提出方法・場所 | |
| 参加資格 | |

## 評価基準

| 評価項目 | 配点 | 該当箇所 |
|---|---|---|

Excel での出力を求められた場合は、要件一覧をそのまま1シートに、確認事項を別シートに書き出す。

守るべきルール

• 要件を要約しない。 原文の意味を変えずに1文へ切り出す。要約すると、後で原文と突き合わせたときに条件が抜けていることがある。
• 該当箇所のないの要件を書かない。 ページ・章番号を特定できない行は表に載せず、確認事項に回す。
• 強制力を勝手に緩めない。 「〜すること」を「推奨」と判定しない。迷ったら必須側に倒し、質問案に含める。
• 対応可否を埋めない。 自社が対応できるかどうかは提案側の判断。空欄で出す。
• 評価基準を見落とさない。 加点項目は要件と別に扱う。ここが提案の書き分けに直結する。
• 質問回答書で変更された要件は、変更後の内容で書く。 変更前の内容は備考に残す。

自社用にカスタマイズする

• references/capability.md に自社の対応実績・保有資格・認証を置くと、対応可否の一次判定の材料になる
• 業界特有の要件区分（自治体案件の様式、医療系の規制要件など）を区分に追加する
• 過去に失注した案件の「落としていた要件」を追加する。同じ見落としを防げる
• 提案書の章立てテンプレートを templates/ に置き、要件IDと提案書の章を対応づける