SIer向けRFP｜提案を比較する7項目

3社へRFPを送り、3通りの提案が返ってきた。A社はパッケージ導入、B社はフルスクラッチ、C社は要件定義からの準委任。金額も納期も違い、結局どれが妥当なのか比べられない。

これは提案力だけの差ではない。RFPに「何をそろえて回答してほしいか」が書かれていないと、SIerはそれぞれの前提で見積もる。発注側は、異なる物差しで出された数字を比べることになる。

SIerへ渡すRFPの役割は、欲しい機能を漏れなく並べることではない。提案の前提をそろえ、選定後に要件定義を始められる状態を作ることだ。

最低限、次の七つを同じ順番で示したい。

1. 背景、目的、成功指標
2. 現行業務と利用者
3. 対象範囲、対象外、優先順位
4. 非機能要件とリスク条件
5. 成果物と受け入れ条件
6. 見積前提と変更ルール
7. 選定基準と役割分担

SIer向けRFPを機能一覧から書くと比較できない

SIer向けRFPのテンプレートを開くと、機能要件の表が目につく。「顧客管理」「検索」「CSV出力」と埋めれば、資料が進んだように見える。ところが、同じ機能名でも実装範囲は大きく変わる。

たとえば「検索」には、完全一致だけでよいのか、表記揺れを吸収するのか、権限のないデータを候補にも出さないのか、応答時間は何秒か、という条件が隠れている。機能名だけでは、SIerが安全側に余裕を持つか、最小構成で見積もるかが分かれる。

デジタル庁のデジタル社会推進標準ガイドラインは、要件定義書と調達仕様書の標準テンプレートを公開している。政府調達向けの文書だが、要件定義と調達を別工程として扱い、共通ルールの下で関係者が協働する考え方は民間のRFPにも使える。

IPAのユーザのための要件定義ガイド 第2版も、ビジネス要求定義と要件定義マネジメントを分けている。発注前に全部を詳細設計する必要はない。ただし、なぜ作るのか、どこまで頼むのか、何を合格とするのかは発注側で決める。

提案を比較できるRFPの7項目

ここからは、候補各社へ同じ前提を渡すための7項目を整理する。機能一覧だけでなく、背景から選定基準までを一本につなげる。

1. 背景、目的、成功指標を一つの線でつなぐ

冒頭には「業務効率化のため」とだけ書かない。現状の困りごと、変えたい業務、測る数字を一つの線でつなぐ。

営業案件管理を例にすると、次のように書ける。

成功指標は、システムの納品条件と業務成果を分ける。画面が開く、データを登録できる、応答時間を満たす。これはシステムの合格条件である。一方、会議準備時間や更新漏れは導入後に測る業務成果だ。二つを混ぜると、SIerが責任を持てる範囲が曖昧になる。

2. 現行業務と利用者を「例外」まで示す

業務フローは、きれいな通常系だけでは足りない。誰が、何を見て、どこで判断し、失敗時に誰へ戻すかを書く。

営業案件なら、通常の登録に加えて次を示したい。

• 同じ企業が別名で登録されたときの確認方法
• 担当者が異動・退職したときの引き継ぎ
• 複数部署が同じ案件へ関わる場合の閲覧範囲
• 外部サービスとの同期が失敗した場合の再実行
• 誤登録を削除せず履歴として残す条件

利用者は「営業部50名」のような人数だけで終わらせない。管理者、入力者、閲覧者、承認者、監査担当に分ける。同じ画面を使っても、見られる項目と実行できる操作が違うからだ。

現行業務がまだ文章になっていない場合は、AIワークフローは業務フローから設計するで扱ったように、入力、判断、出力、例外、責任者の順で棚卸しするとよい。画面案より先に業務の境界を出すと、提案方式の違いを読みやすくなる。

3. 対象範囲、対象外、優先順位を明記する

RFPで抜けやすいのが対象外だ。対象機能を20個書いても、「データ移行は誰がするか」「既存契約の整理は含むか」「運用マニュアルは誰が作るか」が空欄なら、見積もりはそろわない。

範囲は次の単位で分ける。

• 業務：今回変える業務と、現行のまま残す業務
• システム：新規開発、既存改修、外部サービス連携
• データ：移行対象、移行元、品質確認、保管期間
• 導入：教育、マニュアル、初期登録、並行稼働
• 運用：問い合わせ、監視、障害対応、改善受付

各項目には「必須」「提案歓迎」「将来候補」を付ける。全部を必須にすると、予算内での工夫が消える。逆に優先順位がなければ、各社が別々の機能を削り、金額だけを並べても意味がなくなる。

4. 非機能要件とリスク条件を業務の言葉で書く

非機能要件は「高いセキュリティ」「十分な性能」で済ませない。利用場面と数値、または判断条件へ落とす。

IPAの非機能要求グレードは、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの観点を整理する材料になる。すべてを最高水準にするのではなく、業務影響から必要なレベルを選ぶ。

生成AIを含む場合は、入力できない情報、参照可能なデータ、出力確認、外部送信の承認、モデルやプロンプト変更時の再評価も加える。デジタル庁が2026年6月に公開した生成AIの調達・利活用ガイドライン2.0版の資料には、高リスク判定、利活用ルール、調達・契約の各チェックシートが含まれる。これは政府機関向けのガイドラインであり、民間案件へそのまま適用する規則ではない。民間のRFPでは、リスク観点と確認項目を選ぶための参考資料として使える。

5. 成果物と受け入れ条件を結び付ける

「設計書一式」「テスト結果一式」では、納品時に認識がずれる。成果物ごとに、使う人、確認する内容、承認者を決める。

受け入れ条件は「正常に動作すること」と書かない。入力、事前状態、操作、期待結果を代表シナリオで示す。AIテスト自動化は受け入れ条件からでも整理した通り、機能名ではなく条件で合意すると、実装とテストの解釈差を減らせる。

開発会社が変わっても改善を続けたいなら、業務判断、仕様、評価条件、運用記録を発注側へ残す。AI内製化で残したい4つの社内資産の観点を成果物へ含めると、「コードは納品されたが、変更の判断根拠がない」という状態を避けやすい。

6. 見積前提と変更ルールをそろえる

金額比較の前に、見積もりへ含むものをそろえる。最低限、税、ライセンス、クラウド利用料、外部サービス、データ移行、教育、保守、発注側作業を分ける。

見積書には次の回答を求める。

• 工程別の費用と期間
• 前提とした利用者数、データ量、連携本数
• 発注側が用意する情報と担当工数
• 未確定事項と、金額が変わる条件
• 任意提案の費用と期待効果
• 運用開始後の固定費、従量費、保守範囲

変更ルールも発注前に置く。要件が変わったとき、誰が影響を調べ、費用と納期を提示し、誰が承認するか。経済産業省の情報システム・モデル取引・契約書は、ユーザ企業とベンダ企業の取引可視化、役割分担、トラブル低減を目的としている。契約書の条文をRFPへ写す必要はないが、未確定事項を隠さず、合意の手順を示す考え方は早い段階から使いたい。

7. 選定基準と役割分担を回答前に知らせる

選定基準を伏せると、SIerは何を厚く提案すべきか分からない。価格だけで決めないなら、評価軸とおおよその配点をRFPに示す。

例として、次のように置ける。

配点は案件に合わせて変える。大切なのは、提案を受けた後で都合よく物差しを変えないことだ。

AIを使う開発では、生成速度だけを評価軸にしない。SIerがバイブコーディングを導入しにくい理由で触れたように、責任分界、レビュー、品質保証、既存資産との接続まで含めて提案を読む必要がある。

発注側の役割も書く。業務判断、資料提供、レビュー、データ照合、受け入れは、SIerだけでは完結しない。「要件定義から任せる」場合でも、発注側が目的と業務ルールの決定責任まで手放すことはできない。

SIer側はRFPを受領したら、空欄を推測で埋めず、不足事項を質問票へ戻す。とくに対象外、データ移行、例外、非機能要件、受け入れ条件、発注側作業が曖昧なら、見積前提として明示する。そのうえで、RFPの項目に要件IDを付け、要件一覧、設計、テスト、運用手順まで同じIDで追えるようにする。提案時の約束が、開発開始後に別の資料へ埋もれにくくなる。

3社の提案を同じ表に置く

提案を受け取ったら、各社の資料をページ順に読むだけでは比較しにくい。RFPの要件IDを軸に、回答を同じ表へ転記する。

「対応可」だけでは比較しない。方式、前提、初期費用、運用費、発注側作業、残るリスクまで並べる。同じ要件でも、標準機能、個別開発、運用回避では将来の変更費用が違う。

質問票も会社別に閉じず、回答可能な範囲は全候補へ同じ内容を返す。ある1社だけが重要な曖昧さを見つけた場合、その前提を他社の見積もりにも反映しなければ、数字の比較条件がまたずれる。

RFP公開前に確認する10問

最後に、次の10問を発注側で確認する。

• 解決したい業務課題を数字で説明できるか
• 成功指標と納品時の合格条件を分けたか
• 通常系だけでなく例外と責任者を書いたか
• 対象外と将来候補を明記したか
• 非機能要件を業務影響から選んだか
• データ移行と外部連携の責任範囲を分けたか
• 成果物ごとの確認者を決めたか
• 各社に同じ見積内訳を求めたか
• 未確定事項と変更手順を隠していないか
• 選定基準と発注側の役割を示したか

十問すべてに完成した答えがなくてもよい。「未定」「提案を求める」と明示されていれば、SIerは不確実性を前提として回答できる。危ないのは、決まっていないことが決まっているように読めるRFPだ。

RFPは、長いほど良い資料ではない。提案の前提、見積もりの境界、選定の物差しがそろっていればよい。機能一覧を増やす前に、目的、業務、範囲、非機能、受け入れ、見積、役割を一本につなぐ。そうすれば、SIerの違いを価格差ではなく提案の質として比べられる。

会議メモや既存資料からRFPの前提を整理し、AIが読める要件・設計ドキュメントへ変えたい場合は、株式会社Atsumellへご相談ください。発注側と開発側が同じ条件を読める状態づくりから支援します。

関連記事

• AI要件定義ツールの選び方：導入前に見る5つの軸
• AIエージェントの開発見積もりで確認したい6仕様
• SIerが仕様駆動開発を導入すべき3つの理由