SaaSアプリのRFPと要件定義書は、事業設計から作り始めます。曖昧なまま進むと予算超過や納期遅延を招くため、テナント方式や課金、非機能要件を要件として詰め、RFPにまとめます。
全体像をまだ把握していない方は、SaaSアプリ開発の完全ガイドから読むことをおすすめします。
スマホアプリ開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スマホアプリ開発の完全ガイドブック」で詳しく解説しています。
▼RFP作成前に読みたい無料ホワイトペーパー
・スマホアプリ開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
事業設計からテナント方式を要件化する進め方
要件定義は事業設計から始めます。「どんな機能が欲しいか」を並べる前に、誰に・どんな価値を・どの課金モデルで・どの規模まで提供するのかを決めておく必要があります。
この事業設計が、マルチテナント方式、課金の仕組み、スケーラビリティの目標値といったSaaS特有の要件をすべて規定します。そのため、事業の輪郭が曖昧なまま機能を決めると、後から土台を作り直す羽目になります。
ターゲット顧客からの要件の逆算
最初に明確にすべきは、ターゲット顧客の像です。誰を相手にするかで、要件は大きく変わります。
Web（ブラウザ）アプリとして提供するか、モバイルアプリも作るかは、ターゲットの利用シーンから考えます。デスクワーク中心の業務SaaSならWeb優先で、現場やフィールドで使うなら早期からモバイルが必要になる、という具合です。
なお、最初からすべてを作る必要はありません。riplaが整理する「ネイティブ化の移行シグナル3条件」は、デイリーアクティブの増加、プッシュ通知によるリエンゲージメントの重要性、ブラウザ制約機能への要望です。
そして、この3条件が揃った段階でモバイル化する、という前提を要件に織り込むのも現実的です。そのため、要件定義の段階で「今作るもの」と「将来作るもの」を分けて明示しておくと、過剰投資を防げます。
- 想定する利用企業：薄く広く提供するか、少数の大企業に深く提供するか
- 提供する形：Webアプリのみか、モバイルアプリも作るか
中小企業向けに数多くのテナントを抱える場合は、自動でサインアップから利用開始まで完結するセルフサーブの仕組みと、コストの軽いテナント分離が要件になります。
一方で、大企業を相手にする場合は、SSO（シングルサインオン）連携、厳格なデータ分離、個別の契約・SLA対応が要件の中心になります。「誰に売るか」を決めずに機能を並べると、相反する要件が混在して破綻します。
マルチテナント方式の要件化
ターゲットが決まったら、マルチテナント方式を要件に落とします。
この選択は、初期コスト・運用負荷・セキュリティ・拡張性のすべてに影響する根本的な決定です。特に、要件定義で曖昧にしたまま開発に進むと、後から分離方式を変えるのは大規模な作り直しになり、致命的な手戻りを生みます。
あわせて、テナントごとにどこまでカスタマイズを許すかも要件に含めます。ロゴや項目名の変更といった設定で吸収する範囲と、個別開発で対応する範囲の線引きを明確にしておかないと、共通基盤であるはずのSaaSが個別開発の寄せ集めになり、保守コストも膨らみます。
「設定で吸収できる範囲」を要件として定義すると、SaaSのスケールメリットを守る重要な防衛策になります。テナント方式やカスタマイズの範囲は、機能の具体的な内容と一体で検討すべきです。
機能の詳細は、『SaaSアプリの必要機能や標準機能の一覧について』もあわせてご覧ください。
- 分離方式の方針：基本の方式と、例外を適用する顧客層
- カスタマイズの線引き：設定で吸収する範囲と、個別開発で対応する範囲
方式の候補は、データベース共有方式（識別子で分離）、スキーマ分離方式、専用データベース方式です。
課金・プラン・解約ルールの要件化
SaaSアプリの要件定義で、もっとも見落とされがちで、トラブルの温床にもなりやすいのが課金まわりの要件化です。料金体系という事業判断を機能要件に翻訳する作業であり、ここが曖昧だとリリース後に課金トラブルや売上の取りこぼしが頻発します。そのため、プランと課金のルールは、例外まで含めて漏れなく言語化する必要があります。
プラン体系と課金ルールの言語化
課金を要件化するには、まず自社の料金体系をすべて洗い出します。
仕様に抜けがあると、そのままお金のトラブルにつながるため、例外パターンまで詰めておく必要があります。
課金機能は、開発コストもかさみやすい領域です。決済機能単体で80〜200万円が目安とされ、サブスク特有のプラン変更や請求処理を加えると、さらに工数が必要になります。
だからこそ要件定義では、「自社で作り込むべき独自の課金ロジック」と「実績ある仕組みに任せられる標準処理」を切り分けます。RFPでその方針を示しておくと、見積りの精度が上がります。
課金は事業の根幹であり、仕様化にもっとも手間がかかる領域です。そのため、時間をかけて要件を固めるべきです。
- 料金の境界：無料と有料のどこから課金するか、月額と年額の差
- 例外の処理：日割り計算、決済失敗時のリトライ、プラン変更時の差額
課金の方式は、席数課金、従量課金、固定のどれにするかを決めます。上位プランへ変えたときの差額の計算方法も定めます。
ダウングレード時の扱いと、無料トライアルの期間および終了後の挙動も決めます。これらを一つずつ言語化して、「どのプランで、何が、いくらで使えるか」を明確に定義します。
解約導線と利用計測の要件化
課金の要件には、解約処理も必ず含めます。契約期間の残りの扱いを決め、解約前の引き止め提案（一時停止やダウングレード）をどう設計するかも要件にします。
解約をわざと分かりにくくすると、短期的には解約を抑えられても、評判を損ない、長期的には逆効果になります。そのため、誠実な解約導線を要件として定義することが、健全なSaaSアプリの条件になります。
席数課金や従量課金を採用するなら、利用計測が課金の前提になります。「誰が・どの機能を・どれだけ使ったか」を正確に記録する仕組みを要件に明記しておかないと、後から計測を組み込むのは困難です。
この計測データは、課金の根拠になるだけでなく、チャーン分析の基盤にもなります。要件定義の段階で、課金・利用計測・チャーン分析を一体のデータ設計として捉えておくと、SaaSアプリの拡張性を保ちやすくなります。料金体系は事業戦略であり、同時に要件定義におけるデータ設計そのものです。
- 解約の導線：自分で解約を完結できる画面と、解約理由の取得
- 計測の項目：利用者、機能、利用量の記録
SLA・可用性・スケーラビリティの非機能要件
SaaSアプリでは、機能要件と同じくらいの熱量で非機能要件を詰める必要があります。非機能要件とは「どれだけの品質で動くか」を定めるもので、SLA（サービス品質保証）・可用性・スケーラビリティ・セキュリティが中心です。
24時間多数の企業が使うSaaSでは、これらを曖昧にしたままだとリリース後に「遅い」「止まる」「漏れる」といったトラブルが起き、信頼を一気に失います。
SLA・稼働率・スケーラビリティの目標値
SLAの要件化では、計画停止の扱いやサポートの応答時間も、SLAの定義に含めます。
これらは顧客との契約条件にも直結するため、現実的な水準を設定します。
稼働率を高く約束するほど、冗長構成などのコストは上がります。そこで、ターゲット顧客が求める水準と、それを満たすコストのバランスを要件で見極めます。
「とにかく止まらないように」という要望のままでは、見積りが精緻になりません。具体的な数値目標として明記することが、見積りの精度を左右します。
スケーラビリティの要件では、利用が増えたときの拡張方針（サーバーを増やすスケールアウトなど）も示します。
SaaSは成長すると負荷が桁違いに増えるため、初期の小さな構成だけを想定すると、成長期に性能が破綻します。一方で、最初から過大な構成を要求すると、コストが無駄になります。
「現時点の規模」と「成長後に拡張する前提」を分けて要件化すると、過不足のない設計につながります。加えて、一テナントの負荷が他に影響する問題への備えも、非機能要件として記述します。
- 稼働率と復旧時間：顧客に約束する稼働率、障害時の目標復旧時間
- 想定規模：テナント数、同時接続ユーザー数、データ量
稼働率の目標は、たとえば99.9%のように具体的な数値で決めます。
セキュリティ要件とMust/Wantの社内合意
セキュリティは、複数企業のデータを預かるSaaSアプリでは極めて重要な非機能要件です。テナント間のデータ分離、通信の暗号化、アクセス制御を要件に含めます。
脆弱性対策やログの保全も同様に、IPA（情報処理推進機構）のガイドラインなども参照しながら要件化します。
特に大企業を顧客にする場合は、セキュリティチェックシートへの回答や第三者認証が導入の条件になることが多いため、これを満たせる設計を最初から要件に織り込んでおく必要があります。後から付け足すと、大規模な改修になりがちです。
要件を固める過程で避けて通れないのが、Must（必須）とWant（あれば良い）の仕分けと社内合意です。現場は多機能を望み、経営層はコストと短期リリースを求めるという板挟みは、SaaS開発でよく起きます。
これを解消するには、各機能をMust/Wantに分類し、関係者で合意することです。
すべてをMustにすると予算が破綻し、優先順位が曖昧だと開発が迷走します。そこで、要件定義の段階でMust/Wantを社内で合意しておくと、後の予算超過と仕様変更の混乱を防げます。
失敗を未然に防ぐ観点は、後述の『SaaSアプリ開発／導入の失敗／課題／注意点／リスクについて』もあわせてご覧ください。
- Must（必須）：これがないと事業が成立しない機能
- Want（あれば良い）：事業が成立するには必須でない機能
RFPに盛り込む項目と見積り妥当性の判断
要件定義書がまとまったら、それをベースにRFP（提案依頼書）を作成し、複数の開発パートナーに提案を依頼します。RFPの質が、集まる提案と見積りの質を決めます。
曖昧なRFPには曖昧な見積りしか返ってこず、横並びで比べられません。SaaSアプリは費用の幅が大きいため、RFPで条件を揃えることが、見積りの妥当性を判断する前提になります。
RFPに必ず盛り込むべき項目
SaaSアプリのRFPには、最低限、事業の目的とKGI（契約数・継続率・売上など）を書きます。マルチテナント方式の方針も盛り込みます。
課金・プラン・解約のルールも、欠かせない項目です。非機能要件（SLA・可用性・スケーラビリティ・セキュリティ）を書き、外部連携やAPIの要件、予算とスケジュールも、RFPに含めます。
SaaS特有の課金やテナント方式は、RFPの中核として具体的に書きます。特に、契約形態の希望（成果物を定義する請負か、継続改善に向く準委任・ラボ型か）を明記すると、提案の方向性がそろいます。
見落とされがちなのが、リリース後の運用・改善の体制要求です。SaaSは育て続けていくものです。そのため、保守・改善まで伴走できる体制かどうかを、RFPで問うべきです。
契約解除時のソースコードの帰属、検収基準、SLAといった法務面の条件も、RFPの段階で明記しておくと、後の揉め事を防げます。
プレゼンの上手さよりも、SaaSを継続的に支えられる体制の実態を確認できる項目をRFPに盛り込むと、パートナー選定の防衛策になります。
- 事業と機能の情報：KGI、ターゲット顧客像、Must/Wantを分けた機能要件
- 運用と契約の条件：保守・改善の体制、ソースコードの帰属、検収基準
見積りの妥当性を判断する観点
集まった見積りの妥当性を判断するには、まず相場観を持っておく必要があります。
次に、見積りの内訳を精査します。「開発一式」「テスト・デバッグ費」が一式でまとめられている場合は、内訳の開示を求めます。機能ごと・工程ごとに工数と単価が示されていれば、どこにコストがかかっているかが見え、追加要件が発生したときの単価ルールも事前に取り決めておけます。
運用・保守費（一般に初期開発費の年間15〜20%が目安：出典ripla）まで含めた総額で比べることが、長く運用するSaaSでは欠かせません。
要件定義書とRFPが詳細であるほど、開発パートナーは精緻な見積りを出す必要があり、見積りの中身を確かめやすくなります。riplaは、フルスクラッチ受託と国内開発の立場から、要件を透明に整理し、見積りの内訳を明示する進め方を重視しています。
- 相場との比較：MVPの規模感と、発注先別の人月単価
- 内訳の確認：一式でまとめられた費用と、機能・工程ごとの工数と単価
SaaSアプリのMVPは、市場相場で700〜1,500万円（13〜18人月）規模が一つの目安ですが、AI駆動開発と分割発注で実質8人月・約500万円に圧縮した事例もあります。
1人月あたりの目安は、フリーランスが60〜80万円、中小開発会社が80〜120万円、大手SIerが150〜300万円です。この価格差の多くは、中間マージンや組織維持費に由来します。見積りがこの相場から外れる場合は、その理由を確認します。
まとめ
SaaSアプリのRFP・要件定義書・提案依頼書は、「誰に・どの課金モデルで・どの規模まで」という事業設計から始めるのが鉄則です。そのうえで、マルチテナント方式を要件に落とし、課金・プラン・解約・利用計測のルールを漏れなく言語化します。また、SLA・スケーラビリティ・セキュリティといった非機能要件を、具体的な数値目標として詰めます。
Must/Wantを社内で合意し、目的・体制・契約形態・運用まで含めてRFPに明記すれば、開発パートナーの提案を横並びで比べられます。さらに、相場（MVPで市場相場700〜1,500万円規模、AI駆動なら約500万円の事例あり：出典ripla）に照らして、見積りの妥当性も判断できます。
要件定義の質は、そのままSaaSアプリの成否に直結します。事業の輪郭がはっきりした要件こそが、伸びるSaaSを生みます。riplaは、フルスクラッチ受託と国内開発、元事業会社出身の知見を組み合わせて、事業設計からテナント方式・課金・非機能要件の整理、RFP作成までを発注企業と協働で支援します。
全体像の確認には、あらためて完全ガイドをご活用ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。