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