SaaSのRFP/要件定義書/提案依頼書について

SaaS（Software as a Service）の開発プロジェクトで、その成否をもっとも大きく左右するのが要件定義です。SaaSは自社で使う業務システムや個別受託のアプリとは違い、不特定多数の顧客に継続的に提供し、解約されずに使い続けてもらうことで収益を積み上げるビジネスモデルです。そのため、要件定義の段階で「誰のどんな課題を、どの機能で、どこまで解決するか」を見誤ると、いくら作り込んでも売れない、あるいは作りすぎて資金が尽きる、という事態に陥ります。SaaSの要件定義は、機能の網羅ではなく事業戦略そのものを設計する工程だと言えます。

本記事は、SaaSのRFP（提案依頼書）・要件定義書・提案依頼書を、発注企業（SaaS事業者）の視点から具体的に解説する「要件定義特化」の記事です。PMF（プロダクトマーケットフィット）前提のMVPスコープ設計、Must/Wantの仕分けと社内合意の作り方、マルチテナント設計や課金モデルの要件化、SLAやセキュリティといった非機能要件、ロードマップ志向の段階的リリース要件、そしてRFPに盛り込むべき項目と見積りの妥当性判断まで、SaaS事業の実務に即して掘り下げます。読み終えるころには、ベンダーに渡すRFPの骨子が描けるはずです。全体像をまだ把握していない方は、まずSaaS開発の完全ガイドから読むことをおすすめします。

PMF前提のMVPスコープ設計から始める進め方

SaaSの要件定義は、「どんな機能を載せたいか」のリストアップから始めてはいけません。出発点は、「どの顧客の、どの課題を、最小限のどの機能で解決すればお金を払ってもらえるか」を見極めることです。SaaSはPMF（プロダクトマーケットフィット＝市場に受け入れられる状態）に到達して初めて事業として成立します。PMF前のフェーズで機能を作り込みすぎると、検証前に資金と時間を浪費し、方向転換すらできなくなります。

MVPのスコープ設計では、「この機能がなければ顧客が解約する」というコア機能だけを残し、それ以外を後回しにします。SaaSの初期リリースで重要なのは機能の数ではなく、解決したい課題に対して一本筋の通った価値を提供できているかどうかです。たとえば勤怠管理SaaSなら、まず打刻と集計という中核だけを完成度高く作り、給与連携や多拠点対応は後続のフェーズに回す、という判断が求められます。

スコープを絞るときは、ターゲット顧客（ペルソナ）を具体的に一社・一人まで絞り込むことが効果的です。「あらゆる業種のあらゆる規模に使ってほしい」という要件は、結局誰にも刺さらないプロダクトを生みます。最初の数十社が熱狂的に使ってくれる状態を作ることが、SaaSのPMF獲得の近道です。要件定義書には、このターゲットとコア価値を冒頭に明記し、すべての機能要件がそこから逆算されているかを常に確認します。

SaaSは一度作って終わりではなく、リリース後に継続的に機能を追加し、改善し続けるプロダクトです。だからこそ要件定義の段階で、「初期リリースで何を出し、その後どの順序で機能を拡張していくか」というロードマップを描いておく必要があります。MVPで検証し、PMFの兆しが見えたら次のフェーズの機能を追加する、という段階的リリースを前提に要件を組み立てます。

段階的リリースを要件に落とすときは、フェーズごとに区切りを設け、各フェーズの目的（検証したい仮説やKGI）を明記します。これにより、開発ベンダーも全体像を理解したうえでMVPを設計でき、後続フェーズを見据えた拡張性のある作りにしてくれます。逆に、最初から完成形をすべて要件に詰め込むと、検証前に巨額の投資が必要になり、方向転換の余地を失います。ロードマップ志向で要件を分割することが、SaaSの資金効率を守る要諦です。

Must/Wantの仕分けと社内合意の作り方

MVPのスコープを設計するうえで避けて通れないのが、社内の意見の対立です。SaaS開発では、現場やプロダクトチームは「競合に勝つために多機能を」と求め、経営層は「コストを抑え短期で回収を」と求めます。この板挟みを放置すると要件が肥大化し、予算とスケジュールが破綻します。要件定義の本質的な仕事は、この対立をMust/Wantの仕分けと社内合意によって解消することにあります。

機能要件は、ただ列挙するのではなく優先度を付けて分類します。「これがないと顧客が契約しない・解約する」Must（必須）機能、「効果は大きいが初期になくても運用できる」Want（優先）機能、「将来追加でよい」Future機能の三段階に分けるのが基本です。SaaSは機能を盛り込むほど開発費が膨らむため、この優先度付けが予算管理の生命線になります。MVPに含めるのはMustのみとし、WantとFutureはロードマップ上の後続フェーズに割り当てます。

優先度を付けておくと、見積りが予算を超えた場合に、どの機能を初期リリースから外すかを冷静に判断できます。すべてをMustにしてしまうと、予算オーバー時に削るものがなくなり、プロジェクトが頓挫します。逆に優先度が明確なら、まずMust機能でリリースし、顧客の反応を見ながらWant機能を追加する段階的なリリース計画が立てられます。機能要件の分類は、要件定義書の中でも特に投資判断に直結する部分です。具体的にどんな機能が必要かは、関連記事『SaaSの必要機能や標準機能の一覧について』もあわせてご覧ください。

Must/Wantの仕分けは、技術的な作業である以上に社内政治の調整作業です。現場が「これも必要、あれも必要」と主張する機能を、感覚ではなく基準で仕分けるために、判断の物差しを共有することが重要です。たとえば「このターゲット顧客が契約を決める理由に直結するか」「なければ解約に至るか」という問いに照らし、Yesと言えるものだけをMustとします。基準が共有されていれば、機能を外す判断も感情論ではなく合理的な合意になります。

経営層を巻き込む際は、要件の取捨選択をMRRやチャーンといった事業指標と結びつけて説明すると合意が得やすくなります。「この機能はチャーン率の低下に寄与する」「この機能は初期の獲得には不要」というように、機能を事業インパクトの言葉で語ることが鍵です。要件定義の社内合意は、ドキュメント化して関係者の承認を得るところまでやり切ります。口頭の合意は後で蒸し返され、開発途中の要件追加（スコープクリープ）の温床になるためです。

SaaS固有の機能要件（マルチテナント・課金モデル）

SaaSの要件定義が個別受託アプリと決定的に違うのは、不特定多数の顧客に同一のプロダクトを提供し、課金で収益化するという前提から生じる固有要件です。マルチテナント設計と課金モデルは、後から作り直すのが極めて困難なため、要件定義の段階で慎重に設計する必要があります。ここを曖昧にしたままMVPを作ると、顧客が増えた途端にスケールできず、作り直しに巨額の費用がかかります。

マルチテナントとは、一つのシステム基盤を複数の契約企業（テナント）が共有して使う方式です。SaaSはこの方式が一般的ですが、要件定義では「テナント間のデータをどう分離するか」を明確に定める必要があります。データベースをテナントごとに分けるのか、共有データベース内で論理的に分けるのか、その方式によってコスト・性能・セキュリティのバランスが大きく変わります。これは技術選定であると同時に、事業の成長想定に基づく要件判断です。

拡張性も非機能要件として早期に要件化します。「契約企業が10社のときと1,000社のとき、システムが破綻なく動くか」という観点です。想定する成長カーブ（1年後・3年後の契約社数やユーザー数）を要件に書き込むことで、ベンダーはスケールに耐えるアーキテクチャを設計できます。マルチテナントと拡張性は、後から手を入れると基盤の作り直しになりかねないため、MVPの段階でも将来の成長を見据えた設計方針を要件に含めることが欠かせません。

SaaSの収益はプライシング設計で決まります。料金体系には、機能差で段階を分けるプラン課金、利用量に応じて課金する従量課金、利用人数に応じて課金するシート課金などがあり、多くのSaaSはこれらを組み合わせます。要件定義では、自社が採用するプライシングを具体的に定め、それをシステムの課金機能としてどう実装するかを要件に落とします。プラン間のアップグレード・ダウングレード、無料トライアルからの転換、日割り計算などのルールも漏れなく定義します。

課金は誤ると顧客の信頼を一瞬で失うため、要件の精度が特に重要な領域です。プラン変更時の請求金額の計算、決済の失敗時のリトライや督促、解約時の返金や利用停止のタイミングなど、運用で必ず起きるケースを要件に書き切ります。なお、課金そのものを自前で実装するか、決済・サブスクリプション管理のサービスを利用するかも要件定義の判断事項です。自前実装は柔軟ですが工数が増え、外部サービス利用は早いものの制約があります。プライシングをシステム要件に正確に落とすことが、SaaSの収益基盤を支えます。

非機能要件（SLA・可用性・セキュリティ）の要件化

SaaSは顧客の業務を預かるサービスであるため、非機能要件の重みが個別アプリよりはるかに大きくなります。機能要件が「何ができるか」を定めるのに対し、非機能要件は「どれだけの品質・安全性で動くか」を定めます。SaaSでは、サービスが止まる・遅い・漏れるといった事態が、そのまま大量の顧客の解約に直結します。非機能要件を機能要件と同じ熱量で詰めることが、SaaSの信頼を支えます。

SLA（サービス品質保証）は、SaaS事業者が顧客に対して約束するサービス品質の水準です。要件定義では、目標とする稼働率（たとえば99.9%）、障害時の復旧目標時間、計画停止の扱いなどを定め、これを実現できるシステム構成をベンダーに求めます。可用性を高めるには冗長構成やバックアップ体制が必要になり、その分コストもかかるため、事業として約束すべき水準とコストのバランスを要件段階で判断します。

性能要件も明記します。想定する同時アクセス数や、ピーク時のレスポンス目標を要件に書くことで、ベンダーは適切なインフラ構成を見積もれます。SaaSは契約社数が増えるほど負荷が高まるため、現在ではなく成長後の負荷を見据えた性能要件が必要です。これらSLA・可用性・性能の要件は、運用保守の費用にも直結します。なお、SaaSの運用保守費は初期開発費の年間15〜20%が目安です。この継続コストを要件段階から見込んでおくことが、SaaSの総保有コストの管理につながります。

SaaSは複数企業のデータを一つの基盤で預かるため、セキュリティ要件は事業の生命線です。とくにテナント間のデータ分離は、他社のデータが見えてしまう事故が起きれば信頼を一瞬で失うため、要件として明確に定義します。アクセス制御、通信や保存データの暗号化、権限管理、監査ログの取得などを、IPA（情報処理推進機構）のガイドラインなども参照しつつ要件化します。

大企業や官公庁を顧客に想定する場合は、SOC2やISMS（ISO27001）といった第三者認証の取得が契約の前提条件になることがあります。これらの認証は、要件定義の段階で取得方針を決めておかないと、後からシステムの作り直しが必要になります。「将来どの顧客層を狙うか」という事業戦略と、必要なセキュリティ水準・認証要件を紐づけて要件に書き込むことが重要です。セキュリティを後付けにすると、巨額の手戻りと信頼の失墜を招きます。データ分離と認証要件は、SaaSの要件定義で最優先に詰めるべき非機能要件です。

RFPに盛り込む項目と見積り妥当性の判断

要件定義書がまとまったら、それをベースにRFP（提案依頼書）を作成し、複数のベンダーに提案を依頼します。RFPの質が、集まる提案と見積りの質を決めます。曖昧なRFPには曖昧な見積りしか返ってこず、横並びの比較ができません。SaaS開発は費用幅が大きいため、RFPで土俵を揃えることが、見積りの妥当性を判断する大前提になります。

SaaSのRFPには、最低限以下の項目を盛り込みます。プロジェクトの目的とKGI（SaaSでは売上ではなくMRR＝月次経常収益、ARR＝年次経常収益、チャーン率＝解約率の目標が中心）、ターゲット顧客とコア価値、機能要件（Must・Want・Futureの分類付き）、非機能要件（SLA・可用性・性能・セキュリティ・認証）、外部サービスとの連携要件（決済・認証・各種API連携）、予算とスケジュールの目安、そして開発・運用の体制要求です。SaaS固有のマルチテナント・課金モデル・拡張性は、RFPの中核として具体的に記述します。

とくにSaaSで重要なのが、KGIをMRR・ARR・チャーンで語ることと、体制要求です。事業の成功指標を解約率や経常収益で示せば、ベンダーも事業ゴールを理解したうえで提案できます。また体制要求では、コンペにエース級の担当者が出てきても実際の開発は技術力の低い下請けが行う、という事態を避けるため、体制図の提出を求め、誰が実際に開発しPMは誰かを明記させることが有効です。プレゼンの上手さではなく、実開発体制の実態を確認できる項目をRFPに盛り込むことが、ベンダー選定の防衛策になります。

集まった見積りの妥当性を判断するには、まず人月単価の相場観を持つことです。発注先別の人月単価は、フリーランス60〜80万円、中小開発会社80〜120万円、大手SIer150〜300万円が目安です。この価格差は、中間マージンや組織維持費、多重下請けの保険料によるものです。見積りの総額だけでなく、何人月で、どの単価帯のベンダーが、どんな体制で開発するのかを確認すれば、価格の妥当性が見えてきます。一式でまとめられた費用は、機能ごと・工程ごとの内訳開示を求めて精査します。

近年はAI駆動開発によって相場が大きく動いています。riplaの事例では、市場相場700〜1,500万円（13〜18人月）の案件を、AIコード自動生成と分割発注の組み合わせで、実質8人月・約500万円に圧縮しています。見積りを判断する際は、こうしたAI活用による効率化を織り込んだ提案かどうかも比較軸になります。また契約形態は、要件が固まったMVP開発には請負契約（成果物に責任）が、継続的に機能を追加するSaaS運用フェーズには準委任（ラボ型）契約が向きます。両者を使い分けることで、SaaSの段階的な開発・改善に柔軟に対応できます。要件定義の精度が、見積りの妥当性判断と契約設計の精度を決めるのです。

まとめ

SaaSの要件定義・RFP・提案依頼書は、機能の全列挙からではなく、PMF前提でMVPのスコープを絞り、Must/Wantを社内合意で仕分けることから始めるのが鉄則です。そのうえで、マルチテナント設計・拡張性・課金モデルというSaaS固有の機能要件を早期に設計し、SLA・可用性・性能・セキュリティ（データ分離・SOC2/ISMS）といった非機能要件も事業戦略と紐づけて詰めます。これらをRFPに目的・KGI（MRR・ARR・チャーン）・連携要件・体制要求まで明記すれば、ベンダーの提案を横並びで比較でき、人月単価の相場（フリーランス60〜80万円／中小80〜120万円／大手SIer150〜300万円：出典ripla）に照らして見積りの妥当性も判断できます。

要件定義の質は、そのままSaaS事業の成否に直結します。多機能であることよりも、ターゲット顧客が対価を払う価値に絞り込んだ要件こそが、解約されずに使われ続けるSaaSを生みます。riplaはフルスクラッチ受託と国内開発を組み合わせ、AI駆動開発で市場相場700〜1,500万円の案件を実質約500万円に圧縮した実績も活かしながら、MVPスコープ設計から課金モデル・非機能要件の要件化、RFP作成までをSaaS事業者と協働で支援します。全体像の確認には、あらためて完全ガイドをご活用ください。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。