SaaS開発の見積もりを依頼すると、想定していた金額や期間を大きく上回ることがよくあります。その理由の多くは、顧客が直接使う「本体の機能」ではなく、組織とユーザーの管理、権限、課金、運営側の管理画面、セキュリティ対応といった、SaaSとして提供するために必要な土台の部分にあります。本体の機能が単純でも、この土台を一通り作ると開発の範囲は数倍に広がります。
費用と期間を抑える基本方針は、①土台のうち外部サービスで代替できるものは作らない、②最初の版では土台の作り込みを最小限にして、顧客が増えてから厚くする、③見積もりの前に「最初の版で何を検証するか」を決めて範囲を絞る、の3つです。
この記事では、SaaS開発の費用と期間が何で決まるのか、見積もりが膨らむ要因、外部サービスを活用して抑える方法、見積もりを比較するときの観点を、具体的な金額相場に頼らず、判断の枠組みとして整理します。自社SaaSの立ち上げを検討している事業責任者や、開発会社の見積もりを比較している担当者に向けた内容です。
SaaS開発の費用は何で決まるか
受託でのシステム開発費用は、基本的に「必要な作業量（工数）×作業する人の単価」で決まります。工数は、画面や機能の数、業務ルールの複雑さ、外部との連携、品質の要求水準によって変わります。この考え方自体はSaaSでも同じで、詳しくはシステム開発の費用はどう決まるかで解説しています。
SaaSが一般的な社内システムや受託のWebアプリと違うのは、「不特定多数の企業が、それぞれ独立した環境として使う」ことが前提になる点です。この前提から、次のような要素が必ず発生します。
- 複数の顧客企業のデータを安全に分ける仕組み（マルチテナント）
- 顧客企業ごとの組織・ユーザー・ロールの管理と、メンバーの招待
- 料金プランに応じた課金と機能制限
- 運営会社が顧客の契約や利用状況を確認・操作する管理画面
- 顧客企業から求められるセキュリティ対応（ログ、パスワードポリシー、シングルサインオンなど）
- 申し込みから利用開始までを人手を介さず進めるオンボーディング
社内システムであれば、利用者は自社の従業員だけなので、これらの多くは不要か、ごく簡単なもので済みます。SaaSの見積もりが想定より大きくなるのは、この差を見落としていることが主な原因です。
工程ごとに見た費用のかかり方
費用は機能だけでなく、工程ごとにも発生します。見積書で工程の内訳が分かれていない場合は、次のどこに工数が積まれているかを確認すると、金額の妥当性を判断しやすくなります。
- 要件整理・設計：誰の、どの業務を、どう変えるのかを決め、画面とデータの構造に落とし込む工程です。SaaSでは料金体系や権限の仕様もここで固めるため、社内システムより比重が大きくなります
- 実装：画面、処理、外部サービスとの連携を作る工程です。土台の機能が多いほど、ここが膨らみます
- テスト：機能が正しく動くかに加え、テナント間でデータが見えてしまわないか、権限のない操作ができないかといった、SaaS特有の確認が必要です
- インフラ構築・リリース：本番環境、監視、バックアップ、ドメインやメール送信の設定などです
- プロジェクト管理：進捗管理、定例会、仕様の調整にかかる工数です。関係者が多いほど増えます
テストの工数は見落とされやすい項目です。特にテナント間のデータ分離は、一度でも漏れると事業の信頼に関わるため、自動テストを含めて丁寧に確認する前提で見積もるべき部分です。
見積もりが膨らむ要因を分解する
SaaS開発の範囲を、本体の機能と土台の機能に分けて整理すると、どこに費用がかかっているかが見えやすくなります。
| 区分 | 主な機能 | 費用が膨らむ要因 |
|---|---|---|
| 本体機能 | 顧客の業務を解決する画面とロジック | 業務ルールの複雑さ、画面数、帳票、外部連携 |
| テナント・組織管理 | 組織の作成、ユーザー招待、ロール、データ分離 | 権限の細かさ、部署や階層の表現、組織をまたぐ共有 |
| 認証 | ログイン、パスワード再設定、二要素認証、SSO | 自前実装か外部認証サービスか、SSOの対応範囲 |
| 課金 | プラン、決済、請求書、機能制限 | 請求書払いの有無、日割り、従量課金 |
| 運営管理画面 | 顧客一覧、契約管理、問い合わせ対応、代理ログイン | 運営業務の多さ、操作ログの要否 |
| 非機能 | 性能、可用性、監視、バックアップ、セキュリティ | 顧客企業の要求水準、監査やチェックシート対応 |
| 周辺 | ランディングページ、ヘルプ、通知メール、利用規約 | 内製か外注か、どこまでシステムに組み込むか |
特に費用が膨らみやすいのは、権限の細かさと課金の複雑さです。「部署ごとに閲覧範囲を変えたい」「プロジェクト単位で権限を付けたい」「ユーザー数と利用量の両方で課金したい」といった要望は、それぞれは小さく見えても、データ構造と画面のあらゆる部分に影響します。
期間が延びる要因
期間は工数だけでなく、意思決定の速さに大きく左右されます。SaaSの開発でよく期間が延びるのは、次のような場面です。
- 料金体系やプラン構成が開発中に何度も変わる
- 想定顧客が定まらず、機能の優先順位が決まらない
- 大口の見込み顧客の個別要望を、開発途中で取り込む
- セキュリティ要件やインフラ構成が後から追加される
- 社内の承認者が多く、仕様の確認に時間がかかる
開発会社の作業時間は契約で確保できても、発注側の判断待ちが積み重なると全体の期間は延びていきます。
期間を短縮するために発注側ができること
期間の短縮は、開発会社の努力だけでは限界があります。発注側で準備しておくと効果が大きいのは次の点です。
- 仕様の最終判断をする人を1人決め、定例会に必ず出席してもらう
- 料金体系とプラン構成を、開発開始前に「最初の版ではこれで行く」と決め切る
- 見込み顧客の要望は、開発中に取り込むのではなく、次の版の候補リストに積む
- 画面の確認は完成後ではなく、途中段階のものを週単位で見て早めに指摘する
- テスト用のデータや業務の具体例を、開発側が必要になる前に用意しておく
AIを活用した開発や既存の部品の活用で実装の速度は上がっていますが、判断待ちの時間は短くなりません。意思決定の流れを整えることが、結果的に最も確実な期間短縮になります。
外部サービスを活用して費用を抑える
SaaSの土台部分には、専用の外部サービスが数多くあります。自前で作るか外部サービスを使うかを機能ごとに判断するだけで、開発範囲は大きく変わります。
| 機能 | 外部サービスの例 | 自前で作る方がよい場合 |
|---|---|---|
| 認証・ユーザー管理 | 認証サービス（IDaaS）、クラウドの認証機能 | 認証方式自体が差別化要素、外部サービスの料金体系が事業モデルに合わない |
| 決済・請求 | 決済代行、サブスク請求管理サービス | 業界特有の請求ルールがある |
| メール・通知 | メール配信サービス、プッシュ通知サービス | ほぼない |
| 問い合わせ・ヘルプ | ヘルプデスクツール、FAQツール | 問い合わせ内容を本体データと深く連携させたい |
| 分析・計測 | アクセス解析、プロダクト分析ツール | 顧客向けに分析結果を見せる機能自体が商品 |
| ファイル保存・検索 | クラウドストレージ、検索サービス | 大量データの独自処理が中核 |
外部サービスを使う際の注意点は、月額の利用料が顧客数や利用量に応じて増えることと、サービスの仕様変更や終了の影響を受けることです。開発費を抑えた分、運用費がどう増えるかを試算しておきましょう。運用時の費用の見積もり方はサーバー・クラウド費用の見積もり方で詳しく解説しています。
また、外部サービスの名称や料金、機能は頻繁に変わります。候補を挙げたら、公式情報で最新の条件を確認し、小さく試してから採用を決めるのが安全です。
リリース後にかかり続ける費用
SaaSは作って終わりではなく、提供を続ける限り費用が発生します。開発費と同じくらい、次のような継続費用を事前に見積もっておくことが大切です。
- インフラ費用：サーバー、データベース、ストレージ、通信の費用です。顧客数やデータ量に応じて増えます
- 外部サービスの利用料：認証、決済、メール配信、監視などの月額料金や従量料金です
- 保守：ライブラリやOSの更新、セキュリティの修正、障害対応にかかる工数です
- 改善開発：顧客の要望や解約理由をもとにした機能追加・改修です。SaaSでは最も継続的に発生する費用です
- サポート運用：問い合わせ対応、導入支援、ヘルプページの整備にかかる人手です
これらを顧客1社あたりの費用に割り戻し、料金設計と照らし合わせると、どの程度の顧客数で収支が合うかの見通しが立ちます。開発費を抑えるための判断が、継続費用を押し上げていないかも、この段階で確認しておきましょう。
最初の版の範囲を絞る手順
費用と期間に最も大きく効くのは、最初の版に何を入れるかの判断です。次の手順で範囲を絞り込みます。
- 検証したい仮説を書き出す：「この業界の担当者は、この作業にお金を払ってでも効率化したいか」など、最初の版で確かめたいことを2〜3個に絞る
- 仮説の検証に必要な本体機能を選ぶ：顧客が価値を感じる中心の流れを1本決め、それ以外は後回しにする
- 土台の機能を「手作業で代替できるか」で仕分ける：初期の顧客数が少ないうちは、契約管理や請求書発行を運営側の手作業で回すことも選択肢になる
- 外部サービスで代替できる機能を決める：認証、決済、メール、ヘルプは原則として外部サービスを検討する
- 後から変えにくい設計だけは先に決める：データの分け方（テナントの分離方式）、ユーザーと組織の関係、IDの体系は後から変えると影響が大きい
- 機能一覧に優先度を付けて見積もりを依頼する：必須・できれば・後回しの3段階で、それぞれの見積もりを分けてもらう
5番目の「後から変えにくい設計」は、範囲を絞る際にも削らないことが重要です。テナントの分離方式についてはSaaSのマルチテナント設計で比較しています。また、最初の版に入れる機能の具体的な考え方はBtoB SaaSの最初の版に入れる機能も参考になります。
具体的な場面で考える：見積もりが想定の倍になったケース
架空の例で考えます。ある企業が、自社の業務で使っていたスケジュール調整の仕組みを、同業他社向けのSaaSとして提供しようと考えました。社内では表計算ソフトとちょっとしたスクリプトで回っていたため、「画面にすれば数か月でできる」と考えて開発会社に見積もりを依頼しました。
ところが、届いた見積もりは想定を大きく上回っていました。内訳を確認すると、本体のスケジュール調整機能は全体の一部にすぎず、顧客企業ごとのデータ分離、組織とメンバーの招待、管理者と一般ユーザーの権限、カード決済と請求書払い、運営会社向けの管理画面、パスワード再設定や二要素認証、利用状況の分析といった項目が並んでいました。
この企業は、見積もりの各項目について「最初の数社に提供する段階で本当に必要か」「手作業で代替できないか」を開発会社と一つずつ確認しました。そのうえで、見積もりの内訳をもとに、次のように範囲を見直しました。
- 認証は外部の認証サービスを使い、ログインまわりの開発をほぼなくす
- 最初の数社は個別に契約し、請求は請求書を手作業で発行する。決済機能は顧客が一定数を超えてから導入する
- 権限は「管理者」と「メンバー」の2種類だけにする
- 運営向け管理画面は、顧客企業の一覧と契約状態の変更だけに絞り、それ以外はデータベースの閲覧ツールで代替する
- テナントの分離とユーザー・組織のデータ構造は、将来の拡張を見越して最初からきちんと設計する
この見直しで、最初の版の範囲は大きく縮まり、早期に数社へ提供を始められる計画になりました。重要なのは、削ったのは「後から足せる機能」であり、「後から変えにくい設計」は削らなかったことです。
見積もりを比較するときの観点
複数の開発会社から見積もりを取ると、金額にも期間にも大きな差が出ることがあります。金額だけで比較せず、次の観点で中身をそろえて比べましょう。
| 観点 | 確認すること |
|---|---|
| 範囲 | 土台の機能（組織管理・権限・課金・管理画面）がどこまで含まれているか |
| 外部サービス | どの機能に外部サービスを使う前提か、その月額費用は誰がどう負担するか |
| 非機能 | 性能、監視、バックアップ、セキュリティ対応の水準が書かれているか |
| 工程 | 要件整理・設計・テスト・リリース支援が含まれているか |
| 体制 | 誰が何人、どの期間関わるか。発注側の役割は何か |
| 前提条件 | 仕様変更の扱い、見積もりの前提となる画面数や機能数 |
| 運用 | リリース後の保守・改善の費用と体制 |
見積もりが安く見えても、土台の機能が含まれていなかったり、外部サービスの費用が別だったりすることがあります。比較する際は、各社に同じ機能一覧と前提条件を渡し、項目ごとに差が出ている理由を質問すると、金額差の背景が見えてきます。
よくある失敗と避け方
全部入りの最初の版を作ろうとする
競合のSaaSと同じ機能を一通りそろえないと売れないと考え、最初の版から多機能にしてしまうケースです。開発に時間がかかる間に市場の状況が変わったり、実際の顧客が求めるものと違ったりするリスクが高まります。検証したい仮説に必要な機能に絞り、残りは顧客の声を聞きながら追加します。
土台を削りすぎて作り直しになる
逆に、とにかく早く出すためにテナントの分離や組織の構造を簡略化しすぎると、顧客が増えた段階で大規模な作り直しが必要になります。後から変えにくい部分を見極めて、そこだけは最初から丁寧に設計します。
運用費を見落とす
開発費だけを比較して、サーバー費用や外部サービスの利用料、保守の費用を見落とすと、リリース後に収支が合わなくなります。顧客数が増えたときに運用費がどう増えるかを、料金設計とあわせて試算しておきます。
大口顧客の個別要望をそのまま取り込む
最初の大口顧客の要望に合わせて作り込むと、他の顧客には使いにくいSaaSになりがちです。個別要望は「他の顧客にも必要か」で判断し、必要なら標準機能として汎用化し、そうでなければ設定や運用で吸収します。
チェックリスト：見積もり依頼の前に確認すること
- 最初の版で検証したい仮説が2〜3個に絞れている
- 想定顧客（業種・規模・利用者数）が決まっている
- 料金体系の方針（ユーザー課金・定額・従量など）が決まっている
- 本体機能の中心となる業務の流れが説明できる
- 土台の機能を「最初の版で必要・手作業で代替・後回し」に仕分けた
- 外部サービスを使う機能の候補を挙げた
- 求められるセキュリティ水準（顧客企業のチェックシートの有無など）を把握した
- 開発後の運用・改善を誰が担うか決めている
よくある質問
Q. SaaS開発の期間はどのくらいを見込めばよいですか？
範囲によって大きく変わるため一概には言えません。期間は機能の数だけでなく、料金体系や想定顧客が決まっているか、発注側の判断がどれだけ早いかにも左右されます。まずは最初の版の範囲を絞り、その範囲での期間を見積もってもらうのが現実的です。
Q. ノーコードツールでSaaSを作れば安く済みますか？
最初の検証には有効な場合があります。ただし、複数企業のデータ分離や細かな権限、課金との連動は、ノーコードツールでは実現が難しいことがあります。検証が進んで顧客が増えた段階で、移行の判断が必要になる点を見込んでおきましょう。
Q. 開発費を抑えるために、海外の開発会社に頼むのはどうですか？
単価だけでなく、仕様のすり合わせにかかる時間、品質の確認、コミュニケーションの負荷を含めて判断する必要があります。SaaSは仕様が変わりやすいため、意思決定の速さを保てる体制かどうかを重視してください。
Q. 補助金を使って開発費を抑えられますか？
制度によっては対象になる場合があります。ただし、公募時期や対象経費、要件は制度ごとに異なり、変更もあります。最新の情報は公的機関の公式情報や専門家に確認したうえで検討してください。
Otsumuに相談できること
想定顧客と検証したい仮説がはっきりしていて、社内に開発経験のあるエンジニアがいる場合は、外部サービスを組み合わせて自社で最初の版を作ることも十分に可能です。本記事の手順で範囲を絞り、機能一覧を作るだけでも、見積もりの精度と比較のしやすさは大きく変わります。
一方で、見積もりの金額や期間が妥当か判断できない、何を削って何を残すべきか決めきれない、社内に開発の判断ができる人がいない、という状況では、事業と開発の両方を理解した外部の視点が役立ちます。特にSaaSは、最初の設計の判断がその後の拡張性と運用費を大きく左右します。
Otsumuは、自らも事業を手がける実践者として、検証すべき仮説の整理から、範囲の絞り込み、設計・開発・運用改善までを一気通貫で支援しています。AIを活用した開発により、少人数・短期間で最初の版を形にすることを重視しています。支援内容はSaaS開発のページで紹介しているほか、最初の版を短期間で作る場合はPoC / MVP Sprint（税別300万円〜、6週間を目安に設計）という進め方もご用意しています。
「手元の見積もりが妥当か知りたい」「どこまで削れるか一緒に考えてほしい」といった段階でもご相談いただけます。まずは30分の無料相談でお話をお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01