失敗学・アンチパターン：RFPでやりがちなNGが「比較不能な見積もり」を生む理由

なぜRFPから「比較不能な見積もり」が生まれてしまうのか

AIやDXのプロジェクトでRFP（提案依頼書）を出したところ、ベンダーから返ってきた見積もりが3倍以上バラバラだった──DX推進責任者や情報システム部門の方から、そんな相談を受けることは少なくありません。RFPを作成した側は「同じ条件で依頼したつもり」なのに、見積もりの金額も内訳も噛み合わない。その裏側には、RFPと要件定義の設計の仕方に共通するアンチパターンが潜んでいます。

本来、RFPは「プロジェクトの目的・スコープ・制約・非機能要件を整理し、ベンダーが比較可能な見積もりを出せるようにするための設計図」です。しかし実務では、DXやAIというキーワードだけが先行し、RFPに書かれている要件定義が「AIで業務を自動化したい」「DXで効率化したい」といった抽象的な一文に留まっているケースが目立ちます。このようなRFPでは、ベンダーごとに想像するゴールが異なり、見積もりの前提条件もまったく揃いません。

さらに、「詳細はベンダーとの要件定義で決めていきたい」と書き添えられているだけのRFPもよく見かけます。発注側としては柔軟さを意識したつもりでも、受け取る側からすると「どこまでを見積もりに含めるべきか」「要件定義フェーズの工数をどこまで見込むべきか」が分からず、結果としてそれぞれが自社の都合で解釈した見積もりを出すことになります。要件定義の範囲が曖昧なRFPほど、工数の読みやリスクの見積もりがベンダーごとにばらつき、見積もり金額の差として表面化してしまうのです。

加えて、RFPが「情報提供のための資料」としか認識されていないことも問題です。RFPと要件定義は、単に背景や要望を共有するだけでなく、「同じ土俵で見積もりを比較するためのルールブック」として設計されている必要があります。つまり、RFPが曖昧であればあるほど、見積もりは「価格」ではなく「各社の解釈とリスクの置き方」を比べるものになってしまう。この記事では、この構造を失敗学として分解し、実務で使えるRFPと要件定義の考え方、そして比較可能な見積もりを引き出すための具体的な工夫を整理していきます。

RFPに潜むアンチパターン：見積もりをバラバラにしてしまう書き方

まず押さえておきたいのは、「RFPにありがちな一文」が、そのまま見積もりのバラつきに直結しているという事実です。典型的なのは、目的やスコープが曖昧なRFPです。「本RFPの目的はDXを推進することであり、詳細な仕様・要件定義は選定後に協議する」といった表現は、一見すると柔軟で合理的に見えます。しかし、要件定義フェーズをどの程度のボリュームで行うか、見積もりに含めるか別途とするかは、ベンダーの解釈に委ねられてしまいます。その結果、あるベンダーは要件定義コンサルを含めた高めの見積もりを作り、別のベンダーは開発部分だけに絞った安い見積もりを提示することになるのです。

次に、RFPの文章の中に登場する「よしなに」「柔軟に対応」「高度なAI活用」などの抽象的な表現も危険です。こうした表現は、要件定義の段階で議論すべき論点をRFP側に十分に落とし込めていないサインです。機能要件の粒度が粗いままRFPを出すと、各社の要件定義プロセスの進め方や前提条件に応じて見積もりの範囲が大きく変わります。「高度な分析」と書かれていても、あるベンダーはダッシュボード作成のみを想定し、別のベンダーは機械学習モデルの構築やデータ基盤の整備まで見込んだ見積もりを作るかもしれません。

また、非機能要件が空欄に近いRFPもアンチパターンです。性能要件やセキュリティ、可用性、ログ・監査といった非機能要件は、見積もりの工数に大きく影響します。RFPで非機能の要件定義がほとんど触れられていないと、あるベンダーは「業務システムとして実運用できるレベル」を前提にインフラやテストを厚めに見積もり、別のベンダーは「PoCレベルの最小構成」を想定してコストを抑えます。結果として、見積もり金額だけを見ても、その裏にある品質レベルやリスクの置き方が見えず、合理的な比較ができません。

さらに、現行システムや業務プロセスの情報が不足しているRFPも多く見られます。現場の運用フローや既存ツールとの連携有無、データの整備状況などがRFPに十分書かれていなければ、要件定義に必要なヒアリング量も、見積もりに含めるべき移行や運用設計の工数も、ベンダーごとに大きく変わります。情報システム部門としては「口頭で説明すれば分かる」と思っていても、RFPに書かれていない前提条件は見積もりに反映されません。RFPと要件定義の両方で、「ベンダーの解釈をバラバラにしそうな曖昧な表現」を意識的に減らすことが、見積もりを揃える第一歩になります。

ズレの構造と要件定義の押さえどころ：見積もり差を生む6つのギャップ

見積もりが比較不能になる背景には、RFPと要件定義に共通して現れる「ズレ」がいくつかあります。第一は目的・成果のズレです。「DX推進」「AI活用」などの抽象的な表現だけでは、ベンダーごとに想定するゴールが異なります。あるベンダーは「社内の意思決定を支える分析基盤」をイメージし、別のベンダーは「特定業務の負荷を下げる自動化ツール」を想像するかもしれません。目的の要件定義が曖昧であれば、その後に続くスコープも非機能も、すべてがズレたまま見積もりに落ちていきます。

第二はスコープのズレです。対象業務・対象システム・対象外をきちんと線引きできていないRFPでは、要件定義の打ち合わせの中でどんどん範囲が広がり、その広がり方もベンダーごとに違ってきます。営業部門だけを対象とするのか、バックオフィスや経営層のレポートまで含むのか、既存システムの改修を前提とするのか。こうしたスコープの違いは、見積もりの工数や体制に直結します。RFPの段階でスコープの要件定義が甘いと、見積もりの「含まれているもの／含まれていないもの」が揃いません。

第三は品質・非機能のズレです。性能要件、可用性、セキュリティ、ログ、監査、拡張性などの非機能要件は、RFPと要件定義のどちらでも軽く扱われがちです。しかし、実運用を見据えたシステム開発では、非機能要件の見積もりが全体工数の大きな割合を占めます。RFPで非機能の要件定義が十分でないと、「24時間365日稼働を想定した構成」と「平日日中のみ想定した構成」が同じ土俵で比較されてしまい、見積もり差の理由が分からなくなります。

第四は制約条件のズレで、納期や予算、利用が必須なクラウドや製品、契約条件、社内リソースの稼働上限などがRFPに書かれていないケースです。これらの制約は、要件定義の進め方やプロジェクト体制の組み方に直結し、見積もりの前提になります。第五は前提のズレで、既存データの品質や現行仕様の確からしさ、関係部署の協力度合いなどが不明瞭なまま話を進めてしまうパターンです。最後に、第六の運用・移行のズレがあります。運用ルールやサポート範囲、教育、データ移行、切替方式、障害発生時の対応フローなどの要件定義が抜けていると、「そこまで含めた見積もり」と「そこを切り離した見積もり」が並び、金額差が出て当然の状態になります。

重要なのは、これらのズレが個別に起きるのではなく、複合して見積もり差を増幅しているという点です。目的の要件定義が曖昧だからスコープが広がり、非機能要件が抜けているから品質レベルが揃わず、制約や前提が不明瞭なために各社のリスク見積もりもばらつく。結果として、RFPから生まれる見積もりは、数字の上では並んでいても、実質的にはまったく違うプロジェクト案の比較になってしまうのです。

比較可能な見積もりを引き出すRFPと要件定義の設計

では、どうすればRFPと要件定義を通じて、比較可能な見積もりを引き出せるのでしょうか。まず大切なのは、RFPの冒頭に記載する目的・背景・成功条件の書き方です。「DX推進」という抽象的な言葉に留めず、「どの業務の何をどれくらい改善したいのか」「AIによってどのような意思決定やオペレーションを変えたいのか」を具体的に書き出します。たとえば「問い合わせ対応工数を1年以内に30％削減」「需要予測の誤差を現状より○％改善」といった形で、要件定義のゴールをできる限り定量的に記述することで、見積もりの前提が揃いやすくなります。

次に、RFP内のスコープ定義を丁寧に行います。対象業務、対象部門、対象システム、対象外事項、利用者、拠点などを「境界線」として整理し、要件定義で議論すべき範囲を明確にします。ここでは、「ここまでは今回のスコープ」「ここから先は別プロジェクト」といった線引きを、業務フローやシステム構成図を添えて説明すると、ベンダーごとの解釈の差を小さくできます。見積もりの段階で迷いがちな「これはスコープに含まれますか？」という質問を、RFPと要件定義の設計で先回りして潰しておくイメージです。

機能要件の書き方もポイントです。単に「受注管理を行う画面」「ダッシュボードを提供」といった表現ではなく、「誰が（ユーザー）」「どのタイミングで（トリガー）」「どのデータを入力し」「どのようなアウトプットを得るのか」を、ユーザーストーリー形式で記載します。例外パターンや承認フローが重要な場合は、それらも簡潔に添えておきます。これにより、ベンダー側の要件定義作業も進めやすくなり、見積もりに含めるべき工数のイメージが揃ってきます。

非機能要件の最低ラインも、RFPの段階である程度は要件定義しておきましょう。性能（レスポンスや同時接続数）、可用性（稼働時間・復旧目標）、セキュリティ（認証方式・権限管理・ログ）、監査（操作履歴の保存）、拡張性（将来の利用拡大の見込み）などの観点ごとに、「最低限ここまでは欲しい」というレベル感をRFPに記載します。もちろん詳細は要件定義フェーズで詰めていきますが、見積もりの前提としての非機能要件がないと、品質レベルの異なるシステムの見積もりを同列で比較することになってしまいます。

最後に、RFPと一緒に配布する補足資料も重要です。現行システムの構成図、業務フロー、画面サンプル、帳票サンプル、用語集、代表的なデータサンプルなどを提供しておくと、要件定義に必要な前提情報が揃い、見積もりの精度が大きく向上します。情報システム部門・DX推進チームとしては、RFPを「あとで説明するための予告編」ではなく、「これだけで要件定義の骨子と前提が伝わる説明書」として設計する意識が大切です。

見積もりを同じ土俵に乗せる：RFP後の比較設計と評価プロセス

良いRFPと要件定義を行っても、見積もりの「作られ方」がバラバラでは比較が難しいままです。そこで重要になるのが、RFPに紐づく見積もりフォーマットの設計です。発注側で標準フォーマットを用意し、要件定義、基本設計、詳細設計、実装、テスト、移行、教育、保守・運用といった工程ごとに工数と単価、成果物を記載してもらうよう依頼します。これにより、「あるベンダーは要件定義を厚めに見積もっている」「別のベンダーは運用設計をオプション扱いにしている」といった違いが可視化され、見積もりの差の理由を説明しやすくなります。

フォーマットの中には、必ず前提条件・除外事項・リスクを記載する欄を設けましょう。RFP側で書ききれなかった前提や、要件定義で追加確認が必要なポイントは、この欄に現れます。前提条件が一切書かれていない見積もりは、一見スッキリして見えますが、実務では「どの前提でこの見積もりが成り立っているのか」が分からず、プロジェクト開始後に認識ズレが顕在化しがちです。逆に、前提条件やリスクが丁寧に書かれている見積もりは、RFPと要件定義をしっかり読み解いた結果としての提案である可能性が高く、検討の価値が高いといえます。

RFPを出した後のQ&A運用も、見積もりを比較可能にする重要なプロセスです。ベンダーごとに届いた質問に個別に回答するのではなく、共通の質問集として整理し、RFPの改訂版やFAQとして全社に共有します。その際、「どの質問がどの要件定義の不足から来ているのか」を整理しながら、必要に応じてRFP本文を補強していきます。これにより、各社の見積もりは同じ前提条件を踏まえたものに近づき、比較の精度が上がります。

また、見積もりの評価軸もあらかじめ設計しておきましょう。価格だけを軸にすると、「最安値のベンダー」が選ばれがちですが、それが必ずしも「最適なベンダー」ではありません。RFPと要件定義に照らして、「スコープ整合度」「非機能要件への対応」「体制・コミュニケーション設計」「変更管理の考え方」「リスクに対するスタンス」などの観点で評価軸を作成し、複数人でレビューすることで、見積もりの差を立体的に捉えられるようになります。

このように、RFPの作り込みと要件定義の設計に加え、「見積もりをどう集め、どう比較するか」というプロセスまで含めて設計することが、DXやAIプロジェクトの成功率を高める現実的な打ち手です。見積もりは単なる数字の比較ではなく、「RFPと要件定義をどう解釈し、どんなプロジェクトとして定義し直したか」の提案書でもあると捉え直すと、評価の視点も自然と変わってきます。

発注前のセルフチェックと、現場で回る運用のコツ

最後に、RFPと要件定義をベンダーに共有する前に、発注側で行いたいセルフチェックと運用のコツをまとめます。おすすめしたいのは、事業側・現場・情報システム部門の三者レビューです。事業側は「このRFPや要件定義で、ビジネスとしての目的とKPIが伝わるか」、現場は「自分たちの業務の実態や運用負荷が正しく表現されているか」、情シスは「システム要件や制約、セキュリティやガバナンスの観点が抜けていないか」をそれぞれ確認します。三者がそれぞれの言葉でレビューすることで、見積もりの前提となる情報の抜け漏れを減らせます。

また、RFPや要件定義の中で「まだ決め切れていない要素」がある場合は、曖昧なまま隠さず、未確定事項として明示しましょう。そのうえで、ベンダーにはA案/B案など複数パターンでの見積もりを依頼します。例えば、「クラウドAを利用する場合」と「クラウドBを利用する場合」、「既存システム改修を含める場合」と「含めない場合」のように、要件定義上の分岐を意図的に分けて見積もりを出してもらうことで、曖昧さを放置せずに比較材料に変えられます。

さらに、発注前には1枚もののチェックリストを使うと便利です。スコープの境界線、主要な非機能要件、データ移行と運用設計、前提と除外事項、成果物と検収条件、変更管理ルールなどの項目を並べ、RFPと要件定義のどこに書かれているかを確認します。どの項目もどこにも記載がない場合は、「見積もりの前提として危険な穴がある」サインと考え、追記や別添資料の整備を検討します。

ベンダーから返ってきた質問や見積もりの内容も、セルフチェックの材料になります。質問が極端に少ない、見積もり内訳が「一式」の羅列で粗い、前提条件やリスクがほとんど書かれていないといったケースは、RFPや要件定義の読み込みが浅い可能性があります。一方で、「この要件定義の前提だとこのリスクがある」「このRFPの範囲では非機能要件が不足している」といった指摘をしてくるベンダーは、長期的に伴走してくれるパートナー候補かもしれません。見積もりの数値だけでなく、RFPや要件定義の読み解き方にも目を向けることで、選定の質を高められます。

こうしたセルフチェックと運用の工夫を積み重ねることで、「RFPを出したら見積もりがバラバラで選べない」という状態から、「RFPと要件定義を通じて、比較可能な見積もりを集め、納得感のある意思決定ができる」状態へと変えていくことができます。DXやAIの導入は一度きりではなく、今後も何度も繰り返されるテーマだからこそ、RFPと要件定義の作り方、そして見積もり比較のプロセスを組織の資産として磨き込んでいく意識が重要です。

まとめ：RFPと要件定義は「見積もり比較の設計図」

この記事では、RFPの書き方ひとつで見積もりが比較不能になってしまう失敗の構造を、失敗学・アンチパターンの視点から整理しました。ポイントは、RFPと要件定義を「情報共有のための資料」ではなく、「比較可能な見積もりを集めるための設計図」として捉え直すことです。目的やスコープ、非機能要件、制約条件、前提、運用・移行といった要素を、RFPの中でどこまで具体的に要件定義できるかが、そのまま見積もりのバラつきに影響します。

また、RFPを出した後のプロセスも同じくらい重要です。標準化された見積もりフォーマットの用意、前提条件やリスクの明示を促す設計、Q&Aの全社共有とRFPのアップデート、価格だけに依存しない評価軸の設定など、発注側でできる工夫は多くあります。DX推進責任者や情報システム部門、現場マネージャーが連携してRFPと要件定義を作り込み、見積もり比較のプロセスを設計していくことで、「高いか安いか分からない」「どのベンダーを選べばいいか見えない」といったストレスを減らすことができます。

DXやAIのプロジェクトは、技術選定やツール導入そのもの以上に、「どんな目的で、どんな体験や業務プロセスを作りたいのか」を言語化することが成功の鍵になります。その入り口にあるRFPと要件定義は、単なる紙の形式ではなく、組織の意思決定の質を左右する重要なアセットです。自社なりのRFPと要件定義の型、見積もり比較の型を少しずつ整えながら、「この会社なら相談できそうだ」と思えるパートナーと出会っていただければと思います。