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