SaaS開発を外注する費用は、初期リリースで500万〜1,500万円、標準的なBtoB SaaSで1,500万〜3,000万円、期間は4〜10か月が一般的な目安です。費用を抑える鍵は、顧客価値に直結する機能を優先し、課金・権限・運用設計を後回しにしないことです。
SaaS(Software as a Service=インターネット経由で継続提供するソフトウェア)は、一般的なWebサイトと異なり、契約企業ごとのデータ管理、料金プラン、請求、権限、アップデートなどを継続的に運用する必要があります。そのため、画面数だけで見積もると、リリース直前や運用開始後に費用が膨らみやすくなります。
本記事では、SaaS開発を外注する発注者に向けて、費用相場、期間、必要機能、依頼前の準備、見積もりの比較方法、開発会社の選び方を解説します。金額はすべて一般的な目安であり、機能数、品質要件、外部サービスとの連携、開発体制によって変動します。
SaaS開発の費用相場と期間
SaaS開発の費用は、検証用プロトタイプなら100万〜300万円程度、顧客が実際に利用できる初期版なら500万〜1,500万円程度、標準的なBtoB SaaSなら1,500万〜3,000万円程度が目安です。複雑な業務処理や大企業向けのセキュリティ要件がある場合は、3,000万〜6,000万円以上になることもあります。
開発規模別の費用・期間
| 開発規模 | 想定する状態 | 初期費用の目安 | 期間の目安 |
|---|---|---|---|
| 検証用プロトタイプ | 主要画面や操作の流れを確認できる | 100万〜300万円 | 1〜2か月 |
| 小規模な初期版 | 限定顧客に有料提供できる | 500万〜1,500万円 | 3〜6か月 |
| 標準的なBtoB SaaS | 課金、権限、管理画面、通知などを備える | 1,500万〜3,000万円 | 6〜10か月 |
| 大規模・高要件SaaS | 複雑な業務、外部連携、高度な監査・セキュリティに対応する | 3,000万〜6,000万円以上 | 9〜18か月以上 |
事業仮説の検証が主目的なら、最初から標準的なSaaSを完成させる必要はありません。一方で、顧客データを預かって有料提供する段階では、ログインできるだけの簡易システムでは不十分です。データ分離、障害対応、バックアップ、利用規約に沿ったデータ管理などを含めて予算化する必要があります。
検証版の開発範囲を決めたい場合は、MVP開発の費用相場|外注範囲・進め方・選び方も参考にしてください。MVP(Minimum Viable Product=顧客価値を検証できる最小限の製品)と、安定運用を前提とする商用版では、必要な品質と予算が異なります。
工程別の費用目安
| 工程・項目 | 費用の目安 | 主な内容 |
|---|---|---|
| 企画整理・要件定義 | 80万〜300万円 | 対象顧客、業務フロー、機能、品質条件の整理 |
| UI・UX設計 | 80万〜250万円 | 画面構成、操作導線、デザイン |
| アプリケーション開発 | 300万〜1,500万円 | 顧客向け機能、管理機能、データ処理 |
| 認証・権限・課金 | 150万〜700万円 | ログイン、組織管理、プラン、決済連携 |
| インフラ・テスト・公開準備 | 100万〜500万円 | クラウド環境、監視、テスト、リリース作業 |
各項目の範囲は開発会社によって異なるため、この金額を単純に合計するものではありません。例えば、アプリケーション開発費に管理画面やテストが含まれる見積もりもあれば、別項目になっている見積もりもあります。総額だけでなく、どこまで含むかを確認してください。
リリース後に必要な費用
SaaSは公開して終わりではありません。初期費用とは別に、次の継続費用を見込む必要があります。
- クラウド利用料:初期は月数万円〜30万円程度が目安
- 監視、メール配信、認証などの外部サービス料:月1万〜20万円程度が目安
- 保守・障害対応:月30万〜150万円程度が目安
- 機能改善:月50万〜300万円以上が目安
- 決済手数料:売上に応じて発生
- 問い合わせ対応、利用支援、コンテンツ作成などの運営費
利用者数、データ量、動画・画像の配信量、外部API(=他社サービスとデータを連携する仕組み)の利用回数が増えると、運用費も上がります。開発費だけで事業計画を作らず、少なくともリリース後6〜12か月分の運用・改善予算を確保しておくと判断しやすくなります。
見積もり前に決める機能と依頼準備
見積もりの精度を上げるには、画面一覧より先に「誰の、どの課題を、どの業務フローで解決するか」を決めることが重要です。SaaSでは同じ機能名でも、対象顧客や契約形態によって実装範囲が大きく変わります。
例えば「ユーザー管理」という機能でも、個人が自分で登録するだけの場合と、企業の管理者が社員を招待し、部署や役職ごとに閲覧範囲を設定する場合では、必要な設計も費用も異なります。
SaaSで整理すべき基本機能
| 項目 | 発注前に決めること | 費用に影響する例 |
|---|---|---|
| 顧客・組織管理 | 個人利用か法人利用か | 企業、部署、拠点の階層管理 |
| 認証 | 登録、ログインの方法 | 多要素認証、シングルサインオン |
| 権限 | 誰が何を閲覧・操作できるか | 管理者、担当者、閲覧者などの細分化 |
| データ管理 | 顧客ごとのデータ分離方法 | 保存期間、削除、出力、監査履歴 |
| 料金プラン | 定額、従量、人数課金など | 無料期間、プラン変更、日割り計算 |
| 決済・請求 | カード決済か請求書か | 決済失敗時の再請求、請求書発行 |
| 通知 | メール、画面内、チャット連携など | 条件別の通知、配信停止、履歴管理 |
| 運営管理画面 | 自社担当者が行う操作 | 契約変更、利用停止、問い合わせ調査 |
| 外部連携 | 連携する他社システム | 会計、CRM、ストレージ、基幹システム |
特に重要なのが、テナント管理です。テナントとは、SaaSを契約する企業や組織の単位を指します。複数企業が同じシステムを使うマルチテナント方式では、他社のデータが表示されないように分離しなければなりません。この設計は後から変更しにくいため、初期段階で開発会社と合意する必要があります。
非機能要件も先に伝える
非機能要件とは、機能一覧には表れにくい性能、安全性、可用性などの品質条件です。発注者が「一般的なセキュリティで」と伝えるだけでは、見積もりの前提がそろいません。
最低限、次の項目を整理してください。
- 想定する契約企業数、ユーザー数、同時利用者数
- 扱う情報の種類と機密性
- 画面表示や処理速度の希望
- 利用可能な時間帯とメンテナンス可否
- バックアップの頻度と復旧目標
- 操作履歴や監査ログを残す期間
- 個人情報の削除・出力への対応
- 障害時の連絡方法と対応時間
- 将来想定する海外展開や多言語対応
大企業への販売を予定している場合は、セキュリティチェックシートへの回答、アクセス制限、操作ログ、データ保存場所などを求められることがあります。最初の顧客が決まってから追加すると設計変更になりやすいため、想定顧客の調達基準を早めに確認しましょう。
外部サービスを使う範囲を決める
認証、決済、メール配信、チャット、分析などは、既存の外部サービスを利用することで初期開発を短縮できます。ただし、外部サービスを使えば必ず安くなるとは限りません。
| 選択肢 | メリット | 注意点 |
|---|---|---|
| 外部サービスを利用 | 初期開発を短縮しやすい、実績ある機能を使える | 月額・従量料金、仕様変更、提供停止の影響を受ける |
| 独自開発 | 自社の料金体系や業務に合わせやすい | 初期費用と保守責任が大きくなる |
| 段階的に切り替える | 初期投資を抑えながら将来の選択肢を残せる | データ移行や切り替え方法の設計が必要 |
依頼前には、必須機能、できれば欲しい機能、将来機能の3段階に分けてください。すべてを必須にすると予算超過だけでなく、リリースが遅れて顧客検証の機会を失う可能性があります。
SaaS開発を外注する進め方
SaaS開発は、企画から一括で丸投げするのではなく、事業条件の整理、要件定義、開発、限定公開、改善の順に進めるのが基本です。発注側にも、事業上の優先順位を判断する責任者が必要です。
1. 顧客と収益モデルを整理する
最初に、対象顧客、解決する課題、利用者、契約者、料金の支払者を区別します。BtoB SaaSでは、実際に操作する担当者と、契約を承認する責任者が異なることが少なくありません。
次の内容を1〜2枚にまとめるだけでも、開発会社との会話が具体的になります。
- 対象業界と企業規模
- 現在の業務と困りごと
- SaaS導入後の業務の変化
- 利用者、管理者、契約決裁者
- 料金プランと課金単位の仮説
- 初年度に獲得したい顧客数
- 検証したい事業上の仮説
2. 初期リリースの範囲を決める
初期顧客が価値を感じる中心機能を一つ決め、それを利用するために必要な機能を追加します。「競合サービスにあるから」という理由だけで機能を増やさないことが重要です。
優先順位は、次の4分類で整理すると判断しやすくなります。
- 必須:なければ顧客が主要業務を完了できない
- 重要:継続利用や販売に大きく影響する
- 保留:手作業で代替でき、利用状況を見て判断できる
- 対象外:初期版では作らない
課金処理や顧客登録を一部手作業にする選択肢もあります。ただし、手作業にするなら「誰が、どの管理画面や台帳で、何件まで処理するか」を決めてください。開発対象から外した業務が、運営担当者の過大な負担になるケースがあります。
3. 提案依頼と開発会社選定を行う
候補会社には、同じ資料と条件を渡します。予算を隠したまま最大構成の提案を求めるより、予算上限と優先順位を共有したほうが現実的な提案を比較できます。
依頼資料には、少なくとも以下を記載してください。
- 事業の目的と対象顧客
- 現在想定している業務フロー
- 必須機能と将来機能
- 想定ユーザー数とデータ量
- 希望予算と公開時期
- 外部サービスや既存データの有無
- 発注側の担当者と意思決定方法
- 見積もりに含めてほしい成果物
正式な提案依頼書を作る場合は、RFPの作り方|システム開発の依頼準備で必要項目を確認できます。
4. 要件定義と画面プロトタイプを作る
要件定義(=作るものと条件を決める工程)では、機能だけでなく、例外時の処理も決めます。例えば、決済に失敗した場合、契約人数を減らした場合、退会した場合、管理者が退職した場合などです。
画面プロトタイプ(=操作の流れを確認する試作品)を使い、営業、運営、顧客候補にも確認してもらうと、開発後の認識違いを減らせます。見た目の好みだけでなく、利用者が目的の操作を完了できるかを確認してください。
5. 開発・テスト・限定公開を行う
開発中は、2週間程度の単位で動作確認の機会を設けると、方向のずれを早期に発見できます。完成直前まで確認しない進め方は避けましょう。
公開前には、通常の機能テストに加えて、次の確認が必要です。
- 権限の異なる利用者が他人の情報を見られないか
- 顧客企業間でデータが混ざらないか
- 決済失敗や通信エラー時に不整合が起きないか
- 退会後のデータが規約どおりに扱われるか
- バックアップから復旧できるか
- 問い合わせ時に運営側が状況を調査できるか
- 利用規約、プライバシーポリシー、問い合わせ窓口が整っているか
最初は限定顧客へ公開し、操作ログ、問い合わせ、継続利用状況を確認してから対象を広げる方法が現実的です。
6. 改善の判断基準を決める
SaaSでは、リリース後に要望が継続的に集まります。要望の件数だけで開発順を決めず、解約防止、利用頻度、契約単価、運営工数などへの影響で優先順位を付けます。
「顧客から言われた機能をすべて追加する」状態になると、特定顧客向けの個別開発が増え、共通サービスとして保守しにくくなります。標準機能にするのか、有料オプションにするのか、個別対応を断るのかを判断するルールも必要です。
見積もりの見方・開発会社の選び方・失敗回避
SaaS開発の見積もりは総額だけで比較せず、前提、対象範囲、リリース後の責任分界まで確認してください。安い見積もりでも、管理画面、セキュリティ対応、テスト、公開作業が別料金なら、最終総額が高くなる可能性があります。
見積もりで確認する項目
| 確認項目 | 確認する質問 |
|---|---|
| 対象範囲 | 認証、課金、管理画面、通知は含まれるか |
| 前提条件 | 何社・何人の利用を想定しているか |
| 成果物 | 設計書、ソースコード、テスト結果は納品されるか |
| テスト | 対象端末、ブラウザ、権限、負荷の確認範囲はどこまでか |
| インフラ | 環境構築、監視、バックアップ、公開作業を含むか |
| 外部費用 | クラウドや外部サービスの料金を含むか |
| 仕様変更 | 追加費用の判断方法と承認手順は何か |
| 保守 | 障害対応時間、問い合わせ窓口、改善開発の扱いはどうなるか |
| 権利 | ソースコードやデザインの知的財産権はどうなるか |
契約方式も確認しましょう。請負契約(=決めた成果物の完成を約束する契約)は、仕様が固まった開発に向きます。準委任契約(=一定期間、専門業務を遂行する契約)は、仮説検証をしながら仕様を調整する開発に向きます。
| 契約方式 | 向いている状況 | 発注者の注意点 |
|---|---|---|
| 請負契約 | 要件と納期が明確 | 途中変更は追加見積もりになりやすい |
| 準委任契約 | 優先順位を変えながら進めたい | 予算上限、作業報告、成果確認のルールが必要 |
| 段階契約 | 要件定義後に開発費を確定したい | 各段階の終了条件と次工程の判断基準を決める |
新規SaaSでは、要件定義までを準委任契約、範囲が固まった開発を請負契約にするなど、工程で契約を分ける方法もあります。どの契約が常に正しいということではなく、不確実性の高さに合わせて選びます。
開発会社を見極めるチェックリスト
- SaaSの課金、権限、テナント管理を設計した経験がある
- 機能の実装だけでなく、運営側の業務を質問してくる
- 予算内に収めるための優先順位や代替案を提案できる
- セキュリティ、監視、バックアップを具体的に説明できる
- 外部サービスを使う理由と将来の制約を説明できる
- 見積もりの前提と対象外が明記されている
- 進捗、課題、予算消化を定期的に共有する方法がある
- リリース後の保守・改善体制を提示できる
- 特定の担当者だけに知識が集中しない体制を考えている
- 事業責任者と技術責任者が直接会話できる
発注のご相談を受ける開発会社の立場から見ると、「作りたい機能は決まっているが、契約者と利用者、料金プラン、退会時の処理が決まっていない」という相談は少なくありません。これらは後で決める付随事項ではなく、データ構造や権限設計に影響する事業要件です。見積もり前にすべて確定できなくても、未決事項として明示し、いつ誰が決めるかを設定してください。
具体的な開発範囲や段階的な予算配分を整理したい場合は、開発のご相談はこちらからご相談ください。
よくある失敗と回避策
失敗1:競合と同じ機能を最初からそろえる
機能数が増えてリリースが遅れ、実際の顧客ニーズを確認できなくなります。中心機能と販売に必要な機能へ絞り、利用データを見て追加してください。
失敗2:料金プランを開発後に決める
人数課金、従量課金、無料期間、プラン変更などはデータと決済の設計に影響します。確定できなくても、想定する課金方式を要件定義で共有しましょう。
失敗3:顧客向け画面だけを作る
運営管理画面が不足すると、契約変更や問い合わせ調査のたびに開発会社へ依頼することになります。初期版でも、顧客検索、契約確認、利用停止、操作履歴などを検討してください。
失敗4:セキュリティを公開直前に確認する
テナント間のデータ分離や権限構造は、後からの修正が大きくなりやすい項目です。要件定義時にリスクを洗い出し、設計とテストの対象に含めます。
失敗5:発注側に意思決定者がいない
開発会社は技術的な提案はできますが、対象顧客、料金、優先順位を最終決定できません。週次で判断できる事業責任者を置き、回答期限を決めてください。
失敗6:初期開発費だけで予算を使い切る
公開後には、顧客要望への対応、障害修正、運用改善が必要です。初期予算とは別に、6〜12か月分の運用・改善費を確保しましょう。
まとめ
- SaaS開発の費用は、初期版で500万〜1,500万円、標準的なBtoB SaaSで1,500万〜3,000万円が一般的な目安です
- 開発期間は初期版で3〜6か月、標準的なSaaSで6〜10か月程度を見込みます
- 課金、権限、テナント管理、運営管理画面は、SaaS特有の重要項目です
- 見積もり前に、対象顧客、料金モデル、必須機能、想定利用規模、品質条件を整理します
- 見積もりは総額だけでなく、対象範囲、前提、成果物、外部費用、保守条件を比較します
- 初期機能を絞る場合も、セキュリティやデータ分離まで安易に省略してはいけません
- 開発会社には、SaaSの実績だけでなく、事業と運営業務を踏まえた提案力が求められます
- 初期開発費とは別に、リリース後6〜12か月分の保守・改善予算を確保することが大切です
よくある質問
SaaS開発を外注すると、費用はいくらかかりますか?
初期リリースで500万〜1,500万円、標準的なBtoB SaaSで1,500万〜3,000万円が一般的な目安です。複雑な業務処理、高度な権限、外部システム連携、大企業向けのセキュリティ対応が必要な場合は、3,000万〜6,000万円以上になることもあります。
SaaSの開発期間はどのくらいですか?
限定顧客向けの初期版で3〜6か月、標準的なBtoB SaaSで6〜10か月が目安です。要件定義に1〜2か月、設計・開発に3〜6か月、テスト・公開準備に1〜2か月程度を見込みます。複雑な外部連携や審査がある場合は、1年以上かかることもあります。
開発会社へ相談する前に何を準備すればよいですか?
対象顧客、解決したい課題、現在の業務フロー、必須機能、料金モデル、想定ユーザー数、希望予算、公開時期を整理してください。すべてを確定する必要はありませんが、決定済み・仮説・未決定を区別すると、開発会社が前提を置きやすくなり、見積もりの精度が上がります。
ノーコードや既存サービスでもSaaSを立ち上げられますか?
機能が比較的単純で、利用者数や外部連携が限定的なら、ノーコード(=プログラムをほとんど書かずに構築する方法)や既存サービスで検証できる場合があります。ただし、複雑な権限、独自課金、大量データ、高度なセキュリティが必要な場合は制約が出やすいため、将来の移行方法も含めて選定することが重要です。