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