STOP Inc.

RFP作成支援と要件整理

2026.02.16
#RFP作成 #プロジェクト管理 #ベンダー選定 #受託開発 #提案依頼書 #要件定義 #要件整理
RFP作成支援と要件整理

RFP作成支援と要件整理

刺さるRFPの構成と、最初に決めるべきこと

RFPは「調達書類」ではなく「意思決定の設計図」です。読み手（ベンダー）が同じ前提で見積・提案できる粒度まで、曖昧さを削ることが肝心です。最低限そろえる章立てと、数値で縛るポイントを押さえます。

  • 目的・KPI：何を達成すると成功か。例）受注処理リードタイムを平均2日→半日に、誤出荷率0.4％→0.1％。
  • スコープ/スコープ外：対象業務、対象チャネル、対象拠点、レガシー連携、運用引き継ぎ範囲。スコープ外も必ず列挙。
  • 要件一覧（機能/NFR）：ユーザーストーリーや業務イベント単位で列挙し、優先度MoSCoW付与。非機能は数値で固定（例：P95応答500ms、同時接続1,000、SLA99.9％、RPO1時間/RTO4時間）。
  • データと移行：主要テーブル、件数、保持年数、クレンジング責任分担、カットオーバー方式（ビッグバン/段階）。
  • セキュリティ・コンプライアンス：アクセス制御、監査証跡、脆弱性対応SLO、ログ保管年数、外部審査要否。
  • 体制・コミュニケーション：意思決定者、プロダクトオーナー、レビュー頻度、成果物受け入れ基準。
  • 契約と予算枠：請負/準委任/ハイブリッドの希望、成果物定義、支払マイルストーン、変更多発時の単価ルール。
  • 評価基準（重み付け）：例）価格35％、技術適合30％、体制・継続性15％、リスク対応10％、提案価値10％。スコアシートをRFPに同梱。

質問対応の運用

質疑は締切日と公開日を固定し、回答は全社に一斉配布。Excelやスプレッドシートで質問ID管理。生成AI（ChatGPT, Claude, Gemini）で重複検出や要約をかけると事務負荷が半減します。

要件整理を進める現場手順

要件は「会議で決まる」より「現場で観察して固まる」ものです。2〜3週間で一気に叩き台を作る進め方を紹介します。

  1. ステークホルダー抽出：営業、倉庫、カスタマーサポート、経理、情報システムなど役割ごとに代表者を確定。RACIで責務分担を可視化。
  2. As-Is/To-Beの業務イベント整理：受注→引当→出荷→請求のようにイベント時系列で付箋出し。例外系も併記。
  3. ユーザーストーリー作成：役割/目的/成果で短文化（例：倉庫担当として、入荷検品をモバイルで一括登録したい、誤登録を防ぐため）。優先順位と受け入れ条件をセット。
  4. データと連携IF：主要項目のソース・粒度・発生頻度、API/ファイル連携仕様、バッチ窓口時間、再送制御。
  5. 非機能の数値化：性能、可用性、運用監視、バックアップ、監査対応をSLOで定義。曖昧語（サクサク、柔軟）は禁止。
  6. リスクと前提の明文化：依存システムの更新、ベンダーロック条件、法改正の影響域、インフラ制約。

ドキュメント粒度

成果物は「業務イベント図」「要件バックログ」「非機能SLO表」「インターフェース一覧」「リスク台帳」の5点セットが最短距離。テンプレ雛形はCopilotやChatGPTでドラフト生成し、実データを当て込んで精度を上げます。

ベンダー評価と見積比較のコツ

比較不能な見積が集まるのは、前提と粒度がバラつくからです。評価の土俵を先に作ります。

  • 内訳の粒度指定：サブシステム/工程/ロール別（例：要件定義、設計、実装、テスト、移行、PM、QA）。人日単価と工数を分けて提示。
  • デモ・シナリオ配布：3〜5本の業務シナリオをRFPに添付し、同じ流れでデモしてもらう。カスタム/標準/ワークアラウンドを区別して提示。
  • PoCの設計：高リスク領域（在庫引当ロジック、オフライン端末、夜間バッチ）だけ小規模検証。成功/失敗判定基準をスコア化。
  • 赤信号の見抜き方：保守費の逓増カーブ不明、テスト想定の薄さ、属人スキル依存、スコープ外すり替え。質疑で突く質問を標準化。
  • スケジュールの型：RFP公開→質疑1→回答→質疑2→回答→提案会→最終回答、で最短6〜8週間。内部稟議の期日も逆算で明示。

失敗からの学び：身近な企業活用例

従業員200名規模の製造業が、受発注と在庫を統合する基幹刷新を進めた際、最初のRFPは「使い勝手向上」「柔軟な連携」といった抽象表現が多く、非機能は未定義。結果として各社の提案が噛み合わず、見積の差は最大で2.5倍、移行とテストの範囲も不明確でした。

立て直しでは、2週間のワークショップで業務イベントを洗い出し、ユーザーストーリー120本を優先度付きで整理。非機能はP95応答700ms、RPO1時間/RTO4時間、夜間バッチ2時間以内、監査ログ7年保管と数値で確定。RFPには評価基準とデモ・シナリオ、内訳テンプレを同梱し、質疑はスプレッドシートで公開運用しました。

ドキュメントの初稿作成や表の体裁はChatGPTとClaudeで素早くドラフト化し、要件の抜けはGeminiの一貫性チェックで洗出し。工数見積の妥当性検証にはCopilotでWBSの穴を指摘させ、人手で最終確認。再公募の結果、3社の見積差は30％以内に収束し、移行リハーサル2回を計画に組み込めたことで、カットオーバー時の停止は4時間で収まりました。稟議も、KPIとSLOが明確になったことで一次審査を一度で通過しています。

RFPと要件整理は、受託開発ソリューション事業の現場で最も再現性の効くリスク低減策です。発注側・開発側が同じ設計図を持てば、提案の創造性はむしろ高まり、実装フェーズの迷いが減ります。丁寧な要件の言語化と評価土俵づくりこそが、スケジュールと品質、そして関係者の納得感を同時に守る近道です。

関連記事