SaaSのRFPや要件定義書で中心になるのは、機能の一覧ではなく、誰のどんな課題を、どこまで解決するかという事業戦略です。
この見極めを誤ると、作り込んでも売れない、あるいは作りすぎて資金が尽きかねません。全体像をまだ把握していない方は、まずSaaS開発の完全ガイドから読むことをおすすめします。
Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
PMF前提のMVPスコープ設計から始める進め方
SaaSの要件定義は、「どんな機能を載せたいか」を洗い出すより先に、「どの顧客の、どの課題を、最小限のどの機能で解決すればお金を払ってもらえるか」を見極めることから始めます。
SaaSは、PMF（プロダクトマーケットフィット＝市場に受け入れられる状態）に到達して初めて事業として成立します。そのため、PMF前の段階で機能を作り込みすぎると、検証前に資金と時間を浪費し、方向転換すらできなくなります。
MVPのスコープを絞る考え方
MVPのスコープ設計では、「この機能がなければ顧客が解約する」というコア機能だけを残し、それ以外は後回しにします。SaaSの初期リリースで問われるのは、機能の数よりも、解決したい課題に対して一本筋の通った価値を提供できているかどうかです。
たとえば勤怠管理SaaSなら、まず打刻と集計という中核を完成度を高めて作り、給与連携や多拠点対応は後続のフェーズに回す、という判断になります。
スコープを絞るときは、ターゲット顧客（ペルソナ）を一社・一人まで具体的に絞り込むと効果的です。「あらゆる業種のあらゆる規模に使ってほしい」という要件は、結局、誰にも刺さらないプロダクトを生みます。
最初の数十社が熱狂的に使ってくれる状態をつくることが、SaaSのPMF獲得の近道です。要件定義書には、このターゲットとコア価値を冒頭に明記し、すべての機能要件がそこから逆算されているかを、常に確かめます。
MVPに含めるかは、解約への影響と、絞り込んだ顧客の課題との結びつきで判断します。
- 解約との関係：その機能が無いと、顧客が使い続けないかどうか
- ターゲットとの一致：絞り込んだ顧客の課題を直接解決している機能か
ロードマップ志向の段階的リリース要件
SaaSは一度作って終わりではなく、リリース後も機能を追加し、改善し続けるプロダクトです。そのため要件定義の段階で、「初期リリースで何を出し、その後どの順序で機能を拡張していくか」というロードマップを描いておく必要があります。
MVPで検証し、PMFの兆しが見えたら次のフェーズの機能を追加する段階的リリースを前提に、要件を組み立てます。
段階的リリースを要件に落とすには、フェーズごとに区切りを設け、各フェーズの目的（検証したい仮説やKGI）を書き添えます。フェーズの目的まで書いておけば、開発ベンダーは全体像をつかんだうえでMVPを設計でき、後続フェーズを見据えた拡張性のある作りにしてくれます。
反対に、完成形をすべて最初の要件に詰め込むと、検証前に巨額の投資が必要になり、方向転換の余地も失われます。要件をロードマップに沿って分けることは、SaaSの資金効率を守るうえで欠かせません。
初期リリースの範囲と後続フェーズの位置づけは、要件定義書のなかで別々に書き分けておきます。
- 次フェーズへ進む判断：PMFの兆しが見えた時点で、何を追加するか
- 後続フェーズの拡張性：後から機能を足しても、基盤の作り直しにならない設計
Must/Wantの仕分けと社内合意の作り方
MVPのスコープを設計するとき、社内の意見の対立は避けて通れません。SaaS開発では、現場やプロダクトチームが「競合に勝つために多機能を」と求める一方で、経営層は「コストを抑え、短期で回収を」と求めます。
この板挟みを放置すると、要件が肥大化して予算とスケジュールが破綻します。だからこそ要件定義では、Must/Wantの仕分けと社内合意によってこの対立を解消することが、中心の仕事になります。
Must/Want/Futureの三段階による機能分類
機能要件は、ただ列挙するのではなく優先度を付けて分類します。「これがないと顧客が契約しない・解約する」Must（必須）機能、「効果は大きいが初期になくても運用できる」Want（優先）機能、「将来追加でよい」Future機能の三段階に分けるのが基本です。
SaaSは機能を盛り込むほど開発費が膨らむため、この優先度付けが予算管理の生命線になります。MVPに含めるのはMustのみとし、WantとFutureはロードマップ上の後続フェーズに割り当てます。
優先度を付けておけば、見積りが予算を超えたとき、どの機能を初期リリースから外すかを冷静に判断できます。反対に、すべてをMustにしてしまうと、予算オーバー時に削るものがなくなり、プロジェクトが頓挫します。
優先度が明確であれば、まずMust機能でリリースし、顧客の反応を見ながらWant機能を追加していく計画が立てられます。機能要件の分類は、要件定義書のなかでも特に投資判断に直結する部分です。
具体的にどんな機能が必要かは、関連記事『SaaSの必要機能や標準機能の一覧について』もあわせてご覧ください。
分類した結果は、MVPの範囲と予算との照らし合わせで確かめます。
- MVPの範囲：Mustの機能だけで、初期リリースが成り立つか
- 外せる機能：予算を超えたとき、初期リリースから外せる機能が残っているか
社内合意による現場と経営層の板挟みの解消
Must/Wantの仕分けは、技術的な作業である以上に社内の利害を調整する作業です。現場が「これも必要、あれも必要」と主張する機能を感覚ではなく基準で仕分けるには、判断の物差しを社内で共有することが欠かせません。
たとえば「このターゲット顧客が契約を決める理由に直結するか」「なければ解約に至るか」という問いに照らし、Yesと言えるものだけをMustとします。基準が共有されていれば、機能を外す判断も感情論ではなく、合理的な合意になります。
経営層を巻き込む際は、要件の取捨選択をMRRやチャーンといった事業指標と結びつけて説明すると、合意を得やすくなります。具体的には、「この機能はチャーン率の低下に寄与する」「この機能は初期の獲得には不要」のように、機能を事業インパクトの言葉で語ります。
要件定義の社内合意は、ドキュメントにして関係者の承認を得るところまでやり切ります。口頭の合意は後で蒸し返され、開発の途中で要件が増えていく状態（スコープクリープ）の温床になるためです。
社内合意の場では、現場と経営層それぞれの要望を並べて扱います。
- 現場側の要望：「これも必要、あれも必要」と挙がった機能の一覧
- 経営側の要望：コストを抑えて、短期で回収するという条件
SaaS固有の機能要件（マルチテナント・課金モデル）
SaaSの要件定義が個別受託のアプリと大きく違うのは、不特定多数の顧客に同じプロダクトを提供し、課金で収益を得るという前提から、固有の要件が生じる点です。
マルチテナント設計と課金モデルは、後から作り直すのが極めて難しいため、要件定義の段階で慎重に設計する必要があります。ここを曖昧にしたままMVPを作ると、顧客が増えた途端にスケールできず、作り直しに巨額の費用がかかります。
マルチテナント設計と拡張性の要件化
マルチテナントとは、一つのシステム基盤を複数の契約企業（テナント）が共有して使う方式です。SaaSではこの方式が一般的ですが、テナント同士のデータが混ざらないことが前提になります。
拡張性も、非機能要件として早い段階で要件にしておきます。確かめる観点は、「契約企業が10社のときと1,000社のとき、システムが破綻なく動くか」です。
想定する成長カーブを要件に書き込めば、ベンダーはスケールに耐えるアーキテクチャを設計できます。マルチテナントと拡張性は、後から手を入れると基盤の作り直しになりかねません。そのため、MVPの段階でも、将来の成長を見据えた設計方針を要件に含めておく必要があります。
要件に書く際は、分け方と見込みを押さえます。
- 分離方式：テナント間のデータを、どの単位で分けるか
- 成長の見込み：1年後・3年後の契約社数とユーザー数
データベースをテナントごとに分けるのか、共有のデータベース内で論理的に分けるのかによって、コスト・性能・セキュリティのバランスが変わります。この選択は、技術の選定であると同時に、事業の成長想定に基づく要件の判断でもあります。
プライシング・課金モデルの要件化
SaaSの収益は、プライシング設計で決まります。だからこそ要件定義では、自社が採用するプライシングを具体的に定め、それをシステムの課金機能としてどう実装するかを要件に落とします。
プラン間のアップグレードやダウングレード、無料トライアルからの転換、日割り計算などのルールも、漏れなく定義しておきます。課金は、誤ると顧客の信頼を一瞬で失うため、要件の精度がとくに求められる領域です。プラン変更時の請求金額の計算、決済の失敗時のリトライや督促、解約時の返金や利用停止のタイミングなど、運用で必ず起きるケースを要件に書き切ります。
課金を自前で実装するか、決済やサブスクリプション管理のサービスを使うかも、要件定義で判断する事項です。自前で実装すれば柔軟性は高まりますが、工数は増えます。一方で、外部サービスは導入が早いものの、制約を受けます。
プライシングをシステム要件に正確に落とすことが、SaaSの収益基盤を支えます。
料金の要件は、組み合わせ方と例外の扱いを具体的に書きます。
- 料金体系：プラン、従量、シートのどれを、どう組み合わせるか
- 例外のルール：トライアルからの転換や、日割り計算の扱い
料金の方式には、機能差で段階を分けるもの、利用量に応じて課金するもの、利用人数に応じて課金するものがあります。
非機能要件（SLA・可用性・セキュリティ）の要件化
SaaSは顧客の業務を預かるサービスであるため、非機能要件の重みが個別アプリよりはるかに大きくなります。機能要件が「何ができるか」を定めるのに対し、非機能要件は「どれだけの品質・安全性で動くか」を定めます。
SaaSでは、サービスが止まる、遅い、情報が漏れるといった事態が、そのまま大量の顧客の解約に直結します。そのため、非機能要件も機能要件と同じ熱量で詰める必要があります。
SLA・可用性・性能の要件化
SLA（サービス品質保証）は、SaaS事業者が顧客に対して約束するサービス品質の水準です。
要件定義では、目標とする稼働率を、たとえば99.9%のように数値で定め、これを実現できるシステム構成をベンダーに求めます。
可用性を高めるには、冗長構成やバックアップ体制が必要になります。その分コストもかかるため、事業として約束する水準とコストのバランスを、要件の段階で判断します。
性能の要件も明記します。想定する同時アクセス数やピーク時のレスポンス目標を書いておけば、ベンダーは適切なインフラ構成を見積もれます。SaaSは契約社数が増えるほど負荷が高まるため、現在ではなく成長後の負荷を見据えた性能要件が必要です。
SLA・可用性・性能の要件は、運用保守の費用にも直結します。なお、SaaSの運用保守費は初期開発費の年間15〜20%が目安です。この継続コストを要件段階から見込んでおくことは、SaaSの総保有コストの管理につながります。
SLAと性能の要件は、目標値と想定する負荷を具体的に書いて定めます。
- 稼働率と復旧時間：目標値と、計画停止の扱い
- 想定する負荷：成長後の規模で見た、ピーク時の同時アクセス数
セキュリティ（SOC2/ISMS・データ分離）の要件化
SaaSは複数企業のデータを一つの基盤で預かるため、セキュリティ要件は事業の生命線です。
とくにテナント間のデータ分離は、他社のデータが見えてしまう事故が起これば信頼を一瞬で失うため、要件として明確に定義します。アクセス制御、通信や保存データの暗号化、権限管理、監査ログの取得などは、IPA（情報処理推進機構）のガイドラインなども参照しながら要件にします。
大企業や官公庁を顧客に想定する場合は、SOC2やISMS（ISO27001）といった第三者認証の取得が、契約の前提条件になることがあります。これらの認証は、取得方針を要件定義の段階で決めておかないと、後からシステムの作り直しが必要になります。
「将来どの顧客層を狙うか」という事業戦略と、必要なセキュリティ水準・認証要件を紐づけて要件に書き込むことが重要です。セキュリティを後付けにすると、巨額の手戻りと信頼の失墜を招きます。
データ分離と認証要件は、SaaSの要件定義で最優先に詰めるべき非機能要件です。
セキュリティの要件は、分離の仕組みと認証の取得時期を先に決めて書きます。
- データ分離：テナント間で、他社のデータが見えない設計になっているか
- 第三者認証：SOC2やISMSを、いつ取得するかの方針
RFPに盛り込む項目と見積り妥当性の判断
要件定義書がまとまったら、それをもとにRFP（提案依頼書）を作成し、複数のベンダーに提案を依頼します。RFPの質が、集まる提案と見積りの質を決めます。
曖昧なRFPには、曖昧な見積りしか返ってきません。SaaS開発は費用の幅が大きいため、RFPで条件を揃えておくことが、見積りの妥当性を判断する大前提になります。
RFPに必ず盛り込むべき項目
SaaSのRFPには、最低限、目的とKGI、ターゲットや機能の要件を盛り込みます。連携や予算、体制の要求も、あわせて書いておきます。
まず、プロジェクトの目的とKGIを書きます。SaaSでは売上ではなく、MRR＝月次経常収益、ARR＝年次経常収益、チャーン率＝解約率の目標が中心になります。
ターゲット顧客とコア価値、Must・Want・Futureの分類付きの機能要件、SLA・可用性・性能・セキュリティ・認証を含む非機能要件を書きます。さらに、外部サービスとの連携要件（決済・認証・各種API連携）、予算とスケジュールの目安、開発・運用の体制要求を加えます。SaaS固有のマルチテナント、課金モデル、拡張性は、RFPの中核として具体的に記述します。
とくにSaaSで重要なのは、KGIを経常収益や解約率で語ることと、体制要求です。事業の成功指標を示しておけば、ベンダーも事業ゴールを理解したうえで提案できます。
また、体制要求では、コンペにエース級の担当者が出てきても、実際の開発は技術力の低い下請けが行う、という事態が起こり得ます。そこで、体制図の提出を求め、誰が実際に開発し、PMは誰かを明記させることが有効です。
ベンダー選定の防衛策になるのは、プレゼンの上手さより、実際の開発体制を確認できる項目をRFPに盛り込むことです。
RFPでは、KGIの指標と、実際の開発体制を書き分けておきます。
- KGIの指標：売上ではなく、経常収益と解約率で示す目標
- 実開発体制：実際に開発する担当者と、PMの名前
見積りの妥当性を判断する軸と契約形態
集まった見積りの妥当性は、まず単価の水準で見ると判断しやすくなります。目安は、人月単価でフリーランスが60〜80万円、中小開発会社が80〜120万円、大手SIerが150〜300万円です。
この価格差は、中間マージンや組織の維持費、多重下請けの保険料によるものです。そこで、見積りの総額だけでなく、何人月で、どんな体制で開発するのかを確認すると、価格の妥当性が見えてきます。
一式でまとめられた費用は、機能ごと・工程ごとの内訳を開示してもらい、精査します。
近年は、AI駆動開発によって相場が動いています。riplaの事例では、市場相場700〜1,500万円（13〜18人月）の案件を、AIによるコードの自動生成と分割発注の組み合わせで、実質8人月・約500万円に圧縮しています。
見積りを判断する際は、こうしたAI活用による効率化を織り込んだ提案かどうかも、比べる観点になります。
契約形態は、要件が固まったMVP開発なら請負契約（成果物に責任を持つ）が、継続的に機能を追加するSaaSの運用フェーズなら準委任（ラボ型）契約が向いています。両者を使い分けることで、段階的な開発や改善に柔軟に対応できます。要件定義の精度が、見積りの妥当性の判断と契約設計の精度を決めるといえます。
見積りを比べるときは、人月単価と契約形態を見ておきます。
- 人月単価：発注先の種類ごとの相場と、見積りの単価帯
- 契約形態：MVP開発の請負と、運用フェーズの準委任
まとめ
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事業者と協働で支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。