BtoCシステムのRFP（提案依頼書）と要件定義書は、性能・セキュリティなどの非機能要件を数値で書き、作る範囲を線引きし、検収基準と見積もりの内訳まで押さえて作ります。本記事は、この2つの作り方を発注企業の視点から実務的に解説する、「要件定義特化」の記事です。
成否の8割を決めるのは、要件定義とRFPの質です。実際、要件が曖昧なまま進めると工数が1.3〜1.5倍に膨らむとされ、これは数百万円単位の差に直結します。全体像はBtoCシステムの完全ガイドでご確認ください。
▼全体ガイドの記事
・BtoCシステムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
BtoC特有の非機能要件の定量化
BtoCシステムの要件定義で、機能要件以上に差がつくのが非機能要件です。非機能要件とは「どんな機能か」ではなく、「どれくらいの性能・安全性・可用性で動くか」を定める要件です。
BtoCは不特定多数のユーザーが一斉にアクセスし、大量の個人情報を扱います。そのため、非機能要件を曖昧にしたままだと、リリース後にシステムが落ちたり、情報が漏れたりするといった致命的な事態を招きます。ここを定量的に書けるかどうかが、発注側の力量の見せどころです。
想定アクセス数とピーク負荷の数値化
BtoC非機能要件の筆頭は、性能と負荷の定量化です。「サクサク動くこと」のような曖昧な表現では、ベンダーは何を作ればよいか判断できません。この数値が曖昧だと、「平常時しか想定していなかった」とリリース後に弁明する事態になります。
とくにBtoCはピークと平常時の差が極端なため、ピーク時の想定を数値で示すことが、オートスケール構成の設計を引き出す鍵になります。負荷の数値は、自社の事業計画から逆算します。たとえば、テレビCMやSNSキャンペーンで一気に流入が見込まれるなら、その想定流入を要件に明記します。
ただ、サービス開始時点では実績がないため、想定が当てずっぽうになりがちです。そこで現実的なのは、まずMVPで一定のアクセス実績を取り、その実データをもとに本格構築の負荷要件を固める進め方です。過大な想定で過剰投資するのも、過小に見積もって落ちるのも避けたいところです。そのため、実データで要件を段階的に精緻化していくのが賢明です。
- 同時アクセス数：平常時の人数と、セール時のピークの倍率
- 応答時間：ページ表示と決済処理にそれぞれ求める秒数
個人情報とセキュリティ要件の明文化
BtoCで非機能要件として絶対に外せないのが、セキュリティと個人情報保護です。RFPには、扱う個人情報の種類を明記し、それぞれにどのレベルの保護を求めるかを書きます。
とくにクレジットカードを扱う場合は、カード情報を自社で保持しない非保持化を要件に含めるのが定石です。これを曖昧にすると、ベンダーによってセキュリティ水準がばらつき、安価な提案ほど対策が薄いという危険な比較になりかねません。
加えて、セキュリティ要件も具体的に明記します。これらは「当然やってくれるだろう」と省略されがちですが、書かなければ対応しないベンダーもいます。
要件定義書に「何を、どこまで守るか」を文章で残しておくと、後のトラブルや責任の所在がはっきりします。セキュリティは機能と違って目に見えにくいものです。そのため、要件として明文化しておくことが、発注側を守る備えになります。
- 個人情報の種類：氏名、住所、連絡先、購買履歴、カード情報など
- セキュリティ対策：不正ログイン対策、通信やデータの暗号化、ログの取得と保管、脆弱性が見つかったときの対応方針
RFPに盛り込むべき項目とスコープの定め方
RFPは、ベンダーから精度の高い提案と相見積もりを引き出すための設計図です。何を書くかが整理されていないと、各社の提案がバラバラの前提で出てきて、比較ができなくなります。
逆に、骨格となる項目を押さえておけば、複数社の見積もりを同じ土俵で比べられ、適正価格と信頼できるパートナーを見極められます。BtoCならではの押さえどころを、順に見ていきます。
目的・背景・ターゲットユーザーの冒頭記載
RFPの冒頭には、機能の羅列ではなく、「なぜこのシステムを作るのか」という目的と背景を書きます。どんな課題を解決したいのか、ターゲットの消費者は誰か、そのユーザーにどんな体験を届けたいのかを、ここで伝えます。
これが共有されていると、ベンダーは発注どおりの実装ではなく、目的に沿った提案をしてくれます。BtoCは「誰のための、どんな価値か」が曖昧だと、機能は揃っていても刺さらないシステムになりがちです。
目的とターゲット像を最初に言語化することが、良い提案を引き出す出発点です。あわせて、想定する事業規模を共有すると、ベンダーは適切な規模感で設計を考えられます。小さく始めて伸ばすのか、最初から大規模を狙うのかで、技術選定もインフラ構成も変わるためです。
費用には幅があり、この幅のどこを狙うかは目的と事業規模次第です。目的・背景・ターゲット・規模感を冒頭で示すことが、的外れな提案を防ぎます。
- 事業規模とKPI：会員数、月間アクセス、売上目標など
- 規模別の相場（ripla受託）：小規模MVPは300万〜800万円、中規模は800万〜2,500万円、大規模は2,500万〜5,000万円以上
「作るもの」と「作らないもの」の線引き
RFPで意外と見落とされがちなのが、「今回作らないもの（スコープ外）」を明記することです。BtoCシステムは、やろうと思えばいくらでも機能を足せるためです。
また、スコープの線引きが曖昧だと、「あれも入っていると思っていた」「これは別料金です」といった認識のズレが生じます。要件が曖昧だと工数が1.3〜1.5倍に膨らむという数字は、まさにこのスコープの曖昧さから生まれます。
初期リリースで作る機能と、次フェーズに回す機能を分けて文書に残すことが、追加請求のトラブルを防ぎます。
BtoCは公開後にユーザーの反応を見て仕様を変えたくなることが多いため、契約前に仕様変更への備えを決めておく必要があります。あわせて、仕様変更が発生したときの追加費用のルールも、あらかじめ取り決めておきます。スコープを明確にすることが、BtoC要件定義の肝です。
機能には優先度を付け、4段階で仕分けておくと、予算に応じてどこまで作るかの判断がスムーズになります。
- 優先度の4段階：必須・できれば・あれば良い・今回は不要
- 変更時の取り決め：軽微な変更はどこまで含むか、大きな変更はどう見積もり直すか
AI時代の検収基準とテスト要件
要件定義で見落とされがちなのが、「完成をどう判定するか」という検収基準です。検収基準が曖昧だと、ベンダーは「仕様どおりに作った」と主張し、発注側は「思っていたものと違う」と感じてしまいます。
とくに近年は、AIが生成したコードの品質をどう検証するかという新しい論点も加わりました。そのため、検収の設計はこれまで以上に重要になっています。
測定可能な検収基準の要件への組み込み
検収基準は、可能な限り測定できる形で要件定義に書き込みます。「動くこと」ではなく、テストで合否を判定できる基準にします。
BtoCは不特定多数の環境からアクセスされるため、対応する端末やブラウザの範囲を要件で定め、動作確認を検収条件にすることが欠かせません。
負荷テストを検収項目に含めておけば、リリース後にピークで落ちる事態を未然に防げます。
検収基準を最初に合意しておくと、発注側とベンダーが「何をもって完成とするか」の共通認識を持てます。これがないと、検収段階で主観的な押し問答になり、関係が悪化します。測定可能な基準を要件に織り込むことが、円滑な検収と良好な関係の前提です。
- 決済の完了時間：指定の秒数以内での完了
- 表示環境と脆弱性：主要なブラウザとスマートフォンでの正しい表示、第三者による脆弱性診断での重大な脆弱性の有無
AI生成コードの品質と責任の要件化
近年は、開発の現場でAIによるコード生成が広く使われるようになりました。
生産性が上がる一方で、AIが生成したコードには、見た目は動くが脆弱性を含む、保守しづらい構造になっている、といったリスクが潜みます。BtoCは大量の個人情報を扱うため、AI生成コードの脆弱性が漏えいにつながるリスクは軽視できません。
要件定義の段階で、AIをどこまで使うか、品質と責任をどう定めるかを、ベンダーと確認しておくことが重要です。
AIの活用は、コスト削減にもつながります。ただ、「AIに丸投げした結果、誰も中身を理解していないコードが納品される」事態は避けねばなりません。
AI時代のBtoC要件定義では、品質と責任の所在を曖昧にしないことが、新たな必須項目になっています。riplaはフルスクラッチ受託の立場から、AIを活用しつつ人の目で品質を担保する開発を重視しています。
- 納品物への責任：AI生成かどうかにかかわらず、納品コードの品質と脆弱性をベンダーが負う範囲
- 品質保証の検収条件：人によるレビューとテストの実施
見積もりの妥当性チェックとベンダー比較
RFPを各社に提示して見積もりが揃ったら、次はその妥当性を見極める段階です。BtoCシステムの見積もりは、その内訳を理解せずに金額だけを比べると判断を誤ります。
安すぎる見積もりには、後からの追加請求や品質低下のリスクが潜むことがあります。一方で、高すぎる見積もりには、過剰なスペックが含まれている場合もあります。
人月単価と工数の内訳による妥当性の見極め
システム開発の見積もりは、人月単価×工数で決まります。人月単価は職種や体制で変わるため、単価の目安を押さえておくと見積もりを読み解けます。
見積もりを見るときは、総額だけでなく、どの職種が何人月で、単価はいくらかという内訳を確認します。そのうえで、自社の規模に合った体制かを判断します。
工数の妥当性を見るには、工程ごとの配分も参考になります。一般に、要件定義が全体の約20〜25%、設計からテストまでが約75〜80%を占めるとされます（IPAのソフトウェア開発データを参照）。
要件定義の工数が極端に薄い見積もりは、後で手戻りが多発する危険があります。また、請負契約では、人月計算に1.3〜1.5倍の係数をかけ、全体の10〜20%のリスクバッファを乗せるのが一般的です。
相場観を持っておくと、見積もりが妥当か、不自然に安い・高いかを判断しやすくなります。PMはプロジェクトマネージャーのことです。
- 職種別の月単価：PM 110万〜150万円、設計を担うSE 65万〜110万円、プログラマー 50万〜90万円、テスター 45万〜80万円
- 体制別の月単価：フリーランス 50万〜80万円、中小開発会社 80万〜120万円、大手SIer 150万〜200万円
運用・保守の隠れコストの確認
BtoC要件定義で必ず確認すべきなのが、リリース後の運用・保守費用です。初期構築費だけに目を奪われがちですが、BtoCは公開してからが本番です。
サーバー代、外部サービスの利用料、保守費用が毎月かかります。さらに、BtoCはアクセスが増えるほどサーバー代が上がるため、ユーザー数の増加に伴うランニングコストの増え方も、見積もりで確認しておく必要があります。
あわせて、SLA（サービス品質保証）の内容も、要件で確認しておきます。
運用・保守の条件が曖昧なまま契約すると、トラブル時に「それは契約外です」と追加費用を請求される事態に陥ります。条件を契約前に明確にしておくことが、リリース後の安心につながります。
初期費・運用費・保守条件を一体で評価することが、BtoCシステムの賢い発注です。要件定義は、作る前だけでなく、作った後の運用まで見据えて設計してください。
- 保守費用の相場：年額で初期開発費の15〜25%（月額では初期費の5〜15%程度）
- SLAと保守範囲：障害時の初動対応の時限、OSやセキュリティ対応が保守範囲内か別料金か、バックアップの取り方
まとめ
BtoCシステムの要件定義とRFPは、4つの点に集約されます。まず、ピーク負荷・セキュリティ・個人情報というBtoC特有の非機能要件を、数値で定量化することです。次に、目的・ターゲット・スコープ（作るもの、作らないもの）をRFPに明記することです。
さらに、測定可能な検収基準と、AI生成コードの品質・責任を押さえることが必要です。最後に、人月単価と工数の内訳、運用・保守の隠れコストまで含めて、見積もりの妥当性を評価することが大切です。
とくに、要件が曖昧だと工数が1.3〜1.5倍に膨らみます。この現実が、要件定義に時間をかける価値を物語っています。
要件定義は地味で骨の折れる工程ですが、ここに注いだ労力が、後の手戻り・追加請求・トラブルを構造的に減らします。完璧な要件を最初から書くのは難しいため、MVPで実データを取りながら段階的に要件を精緻化するのが現実的です。
riplaはフルスクラッチ受託と国内開発の立場から、BtoC特有の非機能要件の定量化、スコープの線引き、AI時代の品質保証までを伴走し、発注側が損をしない要件定義を支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
▼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を創業。