BtoBシステムの開発を外部ベンダーに依頼するとき、プロジェクトの成否を最初に決めるのが、RFP（提案依頼書）と要件定義書の質です。一次データによれば、要件定義が曖昧なまま進むと工数が1.3〜1.5倍に膨張し、Gartnerの調査ではERP導入・刷新プロジェクトの70%以上が失敗評価とされています。つまり「何を作るか」を発注側が正しく定義できるかどうかが、数百万から数千万円の投資が活きるか無駄になるかを分けるのです。
本記事は、BtoBシステムのRFP・要件定義書・提案依頼書を、発注企業の視点から「文書作成特化」で解説するものです。RFPに盛り込むべき記載項目、見落としがちな非機能要件の固め方、見積もりの妥当性をチェックする観点、そしてAI生成コードが普及した時代ならではの検収基準まで、一次データとあわせて具体的に解説します。なお、BtoBシステム全体の費用相場や進め方をまだ把握していない方は、まずBtoBシステムの完全ガイドから読むことをおすすめします。読み終えるころには、自社でRFPと要件定義書を書き始めるための骨格が手に入るはずです。
▼全体ガイドの記事
・BtoBシステムの完全ガイド
RFP（提案依頼書）に盛り込むべき記載項目
RFP（提案依頼書）は、複数のベンダーに同じ条件で提案を求め、各社を公平に比較するための文書です。RFPが曖昧だと、ベンダーごとに前提がバラバラの見積もりが返ってきて比較ができず、結果として「安さ」だけで選んでしまう失敗につながります。逆にRFPの解像度が高ければ、各社が同じ土俵で具体的な提案をしてくれるため、選定の精度が大きく上がります。まずは何を書くべきかを押さえましょう。
背景・目的・現状課題（AsIs）の記載
RFPの冒頭でもっとも重要なのが、プロジェクトの背景・目的・現状課題（AsIs）です。なぜこのシステムを作るのか、現状の業務で何に困っているのか、システム化で何を達成したいのかを言語化します。たとえば「FAX受注の手入力で月160時間を費やしており、これを削減したい」「在庫の二重管理で売り越しが発生している」といった具体的な課題を書くことで、ベンダーは本質的な提案ができます。
この背景・目的が曖昧だと、ベンダーは「言われた機能をそのまま作る」だけの受け身の提案になりがちです。一次データでも、競合は「ITベンダー視点の教科書的正論」に寄りがちで、発注企業のリアルな業務課題に寄り添う視点が手薄だと指摘されています。だからこそ発注側が、自社の業務の痛みを具体的な数字とともにRFPに書き込むことが、良い提案を引き出す前提になります。現状課題を定量的に示せれば、後の費用対効果の議論もスムーズに進みます。
予算・納期・提案依頼範囲・選定基準の明示
RFPには、予算感・希望納期・提案を依頼する範囲・選定基準を明示します。予算を書くことをためらう発注者もいますが、おおよその予算レンジを示した方が、ベンダーは現実的な提案に集中できます。たとえば「小規模なら300万〜800万円、中規模なら800万〜2,500万円」といった相場感を踏まえ、自社の想定予算を伝えることで、身の丈に合った提案が集まります。納期についても、いつまでに何が必要かを書くことで、フェーズ分けの提案が引き出せます。
選定基準を明示することも重要です。価格だけでなく、同業界・同規模の実績、要件定義から保守までの一貫対応、技術力や品質保証体制といった軸で評価することを事前に伝えれば、ベンダーはそれらをアピールした提案をしてくれます。一次データでも「安さ単独で選ぶのは危険」とされ、同業界・同規模の実績を持つベンダーを選ぶことが推奨されています。提案依頼範囲では、要件定義から依頼するのか、設計済みの実装だけを依頼するのかを明確にすることで、見積もりの前提が揃います。
非機能要件の解像度を上げる
要件定義でもっとも見落とされやすく、かつトラブルの原因になりやすいのが非機能要件です。機能要件（何ができるか）に比べ、非機能要件（どれくらいの速さ・安全さ・止まりにくさで動くか）は目に見えにくいため、後回しにされがちです。しかし非機能要件の曖昧さは、リリース後の「遅い」「落ちる」「漏れた」という致命的なトラブルに直結します。RFPと要件定義書では、ここの解像度を意識的に上げる必要があります。
性能・データ量・同時アクセスの数値化
非機能要件で最初に数値化すべきが、性能（レスポンス）・データ量・同時アクセスです。「商品検索は何秒以内に結果を返すか」「想定する商品数や得意先数はどれくらいか」「ピーク時に何ユーザーが同時にアクセスするか」を具体的な数値で示すことが重要です。BtoBシステムでは大量の品目や取引データを扱うため、データ量が増えても性能が落ちない設計が求められます。これを要件として明示しないと、リリース後にデータが増えてシステムが遅くなる、という事態が起きます。
数値の根拠は、自社の実績データから導きます。現在の年間取引件数、得意先数、商品点数、繁忙期のアクセス集中度などを洗い出し、さらに「3年後にどれくらい成長する想定か」を加味して、将来の規模も見込んだ要件にします。一次データでも、非機能要件はセキュリティ・レスポンス・データ量の解像度が成否を分けるとされています。漠然と「速く」「大量に」ではなく、「検索3秒以内、商品10万点、同時100ユーザー」のように数値化することが、ベンダーが正しく設計し、適正な見積もりを出すための前提になります。
セキュリティ・可用性・SLAの必須条項
セキュリティと可用性も、要件定義で必ず固めるべき非機能要件です。BtoBシステムは得意先別価格や取引履歴といった機密データを扱うため、通信の暗号化、認証の強化、アクセスログの記録といったセキュリティ要件を明記します。特に得意先別価格を他社に見せないという情報の出し分けは、機能であると同時にセキュリティ要件でもあるため、要件定義で漏れなく押さえる必要があります。
可用性については、稼働後のSLA（サービス品質保証）を具体的に定めることが重要です。一次データでも、「システムが止まったとき何分で初動するか」「法改正やOSアップデート、脆弱性対応は保守範囲内か別料金か」を契約前に明確にすべきだと指摘されています。稼働率の目標、障害時の復旧時間、バックアップの頻度と保管期間、保守の対応時間帯といった項目を、要件定義の段階で洗い出しておきましょう。これらを曖昧にすると、リリース後に「止まったのに何時間も連絡がつかない」「脆弱性対応に追加費用を請求された」というトラブルになります。SLAの必須条項を要件定義に組み込むことが、安心して長く使うための保険になります。
見積もりの妥当性をチェックする観点
RFPに対してベンダーから見積もりが返ってきたら、その妥当性をチェックする番です。BtoBシステムの費用は「人月単価×工数」で決まるのが基本で、この構造を理解していれば、見積もりが適正か、安すぎて危険ではないかを判断できます。一次データの相場感を手元に置きながら、見積書を読み解く観点を押さえましょう。
人月単価と工数内訳の確認
見積もりを読むうえで知っておきたいのが、人月単価の相場です。一次データによれば、PMは110万〜150万円、SE（設計）は中堅で65万〜90万円、PG（実装）は50万〜90万円が職種別の目安です。体制別では、フリーランスが50万〜80万円、中小開発会社が80万〜120万円、大手SIerが150万〜200万円/人月とされています。見積書に職種別の単価と工数（人月）が明示されているか、その単価が相場の範囲内かを確認しましょう。
工数の内訳も重要なチェックポイントです。一次データでは、工数比は要件定義が約20%、設計からテストが約80%とされ（IPAソフトウェア開発データ白書）、人件費が全体の40〜60%を占めるのが一般的です。請負契約では人月計算に1.3〜1.5倍の係数がかかり、リスクバッファとして全体の10〜20%を見込むのが標準です。見積もりがこうした構造から大きく外れて安い場合は、要件の見落としや、後からの追加請求、品質低下のリスクを疑うべきです。安さの裏に何が隠れているかを見抜くことが、発注側の役割です。
保守費・隠れコストを含めた総額試算
見積もりの妥当性を判断するには、初期開発費だけでなく、リリース後の保守費や隠れコストまで含めた総額を見る必要があります。一次データによれば、保守費は年で開発費の15〜25%、月額では初期開発費の5〜15%が目安です。たとえば1,000万円で開発したシステムなら、年150万〜250万円の保守費が継続的にかかる計算になります。この維持費を見落として初期費用だけで判断すると、運用フェーズで予算が破綻します。
隠れコストには、保守費のほかにクラウドのインフラ費用、外部API（決済・地図・配送など）の利用料、機能追加や法改正対応の費用などがあります。一次データでも、競合は人月ベースのざっくり相場に留まりがちで、リリース後の維持費が毎月いくらのしかかるかの試算が手薄だと指摘されています。RFPの段階で「初期費用と月額ランニングコストを分けて見積もってほしい」と明記し、5年程度のトータルコスト（TCO）で比較することが、本当に安いベンダーを見極める鍵です。発注検討企業の約4〜5割が「費用対効果が分からない」を課題視しているという統計もあり、総額での試算は意思決定の土台になります。
AI時代の検収基準を要件に組み込む
近年、AIによるコード生成が普及し、開発の現場も変わりつつあります。これに伴い、要件定義と検収の段階で、従来にはなかった新しい観点を組み込む必要が出てきました。AI生成コードを使った開発には独自のリスクがあり、それを見越した検収基準を要件に盛り込むことが、AI時代の発注側に求められる新しいリテラシーです。
AI生成コードの品質・著作権・責任の確認
AIが生成したコードを丸ごと採用する、いわゆる「Vibe Coding」には、見えにくい脆弱性が潜むリスクがあります。一次データでも、AI生成コードの丸投げによる脆弱性や、生成コードの著作権・バグ責任の所在が、AI時代特有の開発リスクとして指摘されています。要件定義では、「AI生成コードを使う場合、品質保証やセキュリティレビューをどう行うか」「成果物の著作権は誰に帰属し、第三者の権利を侵害していないことをどう保証するか」を確認すべきです。
著作権については、システム開発の成果物は原則として受託者（ベンダー）に帰属するため、発注側が自由に改修・転用したい場合は、契約で著作権の譲渡を明記する必要があります（著作権法27条・28条の権利を含めて譲渡する旨を契約に書く）。AI生成コードが絡む場合は、その学習データに由来する権利関係も含めて、責任の所在を契約で明確にしておくことが安全です。検収基準として、「セキュリティ診断に合格すること」「ソースコードのレビュー記録を提出すること」などを要件に盛り込めば、AI由来の品質リスクをある程度コントロールできます。
検収基準とテスト項目の明文化
検収基準とは、「どの状態になれば、システムを完成として受け入れるか」を定めた合格ラインです。これを要件定義の段階で明文化しておくことが、納品時の「言った・言わない」のトラブルを防ぎます。具体的には、要件定義書に記載した機能がすべて動くこと、定めた性能（レスポンスやデータ量）の基準を満たすこと、想定したテストケースをすべて通過することを、検収基準として書き出します。
特にBtoBシステムでは、得意先別価格が正しく出し分けられるか、与信枠を超えた発注が正しく制御されるか、基幹連携でデータが欠落しないか、といった業務ロジックの正確性を検証するテスト項目が重要です。AIや外部システムを利用する部分では、想定外の入力に対する挙動（ハルシネーションの許容範囲など）も検収基準に含めると安心です。検収基準を曖昧にしたまま開発を進めると、「動くけれど業務に使えない」システムを受け入れてしまうことになります。要件定義の最後に検収基準とテスト項目を明文化し、発注側とベンダーで合意しておくことが、プロジェクトを正しく着地させる最後の砦です。
まとめ
BtoBシステムのRFP・要件定義書を整理すると、背景・目的・現状課題を起点に予算・納期・選定基準を明示するRFP、性能やセキュリティ・SLAの数値を固める非機能要件、人月単価と工数内訳・保守費を含めた見積もりの妥当性チェック、そしてAI時代特有の品質・著作権・検収基準という四つの観点で構成されます。要件定義の曖昧さが工数を1.3〜1.5倍に膨張させ、ERP刷新の70%以上が失敗評価とされる以上、この上流文書の質こそが投資の成否を決めます。
RFPと要件定義書を書くうえで大切なのは、ベンダーに丸投げせず、発注側が自社の業務課題と求める品質を具体的な数字で語ることです。背景を定量化し、非機能要件を数値化し、見積もりを総額で比較し、検収基準を明文化する。この四つを押さえれば、失敗の多くは未然に防げます。riplaはフルスクラッチ受託と国内開発の立場から、発注企業のRFP作成から要件定義、適正な見積もりの提示までを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。