「月額が安い」だけでは判断できない――SaaSとスクラッチ開発の本当の費用差
中小企業が見落としやすい「初期費用だけ比較」の落とし穴
「SaaSは月額数千円から使えるので安い」「スクラッチ開発は数百万円かかるので高い」。こうしたイメージを持つ経営者や情報システム担当者は少なくありません。
たしかに、導入時点の見積もりだけを比べれば、SaaSのほうが手を出しやすく見えます。しかし、システムは導入して終わりではありません。実際には、導入後のライセンス費、設定変更費、外部連携費、運用工数、保守費などが継続的に発生します。
つまり、初期費用だけで判断すると、5年後の総支出を見誤る可能性が高いのです。
- 導入時は5人利用だったSaaSが、事業拡大で30人・50人利用になった
- 標準機能では足りず、プラグインや追加契約が増えた
- 業務に合わせるために外部ベンダーへの設定依頼が常態化した
- 複数ツールをつなぎ合わせた結果、運用が複雑になった
- 5年間の累計で見ると、SaaSのほうが高くついていた
このような事態を防ぐには、単発の導入費ではなく、5年間でいくらかかるのかを「TCO(総保有コスト)」で比較する視点が欠かせません。
なぜ5年間のTCOで比較すべきなのか
TCOとは「Total Cost of Ownership(総保有コスト)」のことです。システムの導入から運用、保守、改修、移行までにかかる費用を合算して考える指標で、表面上の安さではなく、実際の負担を把握するために使われます。
特に中小企業では、業務システムの見直しやリプレイスが3〜5年単位で発生することが多く、5年という期間は比較の目安として現実的です。この期間で見ると、SaaSとスクラッチ開発はコスト構造の違いがはっきり表れます。
| 比較項目 | SaaS(パッケージ型) | スクラッチ開発 |
|---|---|---|
| 初期費用 | 低〜中 | 高い |
| 月次コスト | ユーザー数に応じて増えやすい | 比較的安定しやすい |
| カスタマイズ費 | 追加費用が積み上がりやすい | 必要な機能を個別に実装できる |
| 5年間の総コスト | 右肩上がりになりやすい | 初期投資後は安定しやすい |
| 費用予測 | 人数増・プラン変更で変動しやすい | 設計次第で見通しを立てやすい |
SaaSは導入しやすい一方で、利用人数や業務の複雑化に比例して費用が膨らみやすいのが特徴です。反対に、スクラッチ開発は初期投資こそ大きいものの、長期ではコストが安定しやすく、業務に合わせた最適化もしやすくなります。
この記事で比較する対象と前提条件
本記事では、SaaSとスクラッチ開発を以下の前提で比較します。実際の費用は業種や要件によって変わるため、自社の状況に置き換えてご覧ください。
SaaS(パッケージ型)
クラウド上で提供される既製の業務システムを指します。例として、業務アプリ構築系のkintone、CRM・SFA系のSalesforce Sales Cloudを参考にしています。
スクラッチ開発
自社の業務要件に合わせてゼロから設計・開発するシステムです。主に外部の開発会社へ委託するケースを想定し、一部で内製も補足します。
- 対象企業規模:従業員20〜100名程度の中小企業
- 対象業務:営業管理、顧客管理、受発注管理、社内業務管理など
- 比較期間:導入から5年間
- 価格表記:税抜きの概算。実際の料金は各社公式情報を確認
【SaaS編】5年間のTCO内訳を分解してみる
初期費用:SaaSでも「導入した瞬間から使える」とは限らない
SaaSは初期費用が安いと思われがちですが、実際には導入時にも一定のコストがかかります。特に業務で本格利用する場合は、設定やデータ移行、社内教育が必要です。
- 初期設定費:項目設定、権限設定、ワークフロー設定など
- データ移行費:Excelや旧システムからの移行、データ整形
- 教育・研修費:マニュアル作成、操作説明会、定着支援
- コンサルティング費:業務整理や要件整理の支援
kintoneのような比較的シンプルなSaaSでも、外部支援を入れると10万〜50万円程度の設定費がかかることがあります。Salesforceのように設定項目が多く、業務設計が複雑なSaaSでは、初期費用が30万〜100万円以上になるケースも珍しくありません。
そのため、SaaSでも初期フェーズで50万〜200万円程度かかることは十分あり得ます。小規模な試験導入と、本番運用を前提にした導入は別物と考えたほうが安全です。
月額ライセンス費:人数が増えるほど効いてくる固定負担
SaaSのTCOで最も大きな比率を占めやすいのが、毎月発生するライセンス費です。ユーザー単価課金のサービスでは、従業員数の増加がそのままコスト増につながります。
| サービス | プラン例 | 月額費用(1ユーザーあたり概算) |
|---|---|---|
| kintone | ライトコース | 約780円 |
| kintone | スタンダードコース | 約1,500円 |
| Salesforce Sales Cloud | Starter Suite | 約3,000円 |
| Salesforce Sales Cloud | Pro Suite | 約9,900円 |
| Salesforce Sales Cloud | Enterprise | 約19,800円 |
たとえばkintoneスタンダードを30人で使うと、月額4万5,000円、年間54万円、5年間で270万円です。50人なら5年間で450万円になります。単価が高いSaaSでは、この差がさらに大きくなります。
加えて見落としやすいのが、機能要件の増加によるプランアップグレードです。分析機能、API連携、権限管理、承認機能などを求めるうちに、より高額なプランへ移行するケースは少なくありません。
SaaSは「少人数・標準機能中心」なら安くても、人数増加と機能追加で一気に高コスト化しやすい点に注意が必要です。
カスタマイズ・連携費:標準機能では足りないときに発生する追加負担
SaaSの導入後によく起きるのが、「あと少しだけ業務に合わせたい」という要望です。しかし、その“少しだけ”が積み重なると、想像以上の費用になります。
- プラグイン費:月額数千円〜数万円。複数導入で月3万〜10万円になることもある
- API連携開発費:会計、EC、物流、基幹システムなどとの接続で30万〜150万円程度/件
- 認定パートナー委託費:設定変更、レポート作成、運用支援で月10万〜30万円程度
ノーコード・ローコードをうたうSaaSでも、業務が複雑になるほど専門知識が必要になります。結果として、社内では対応しきれず、外部ベンダーへの依頼が常態化することがあります。
「SaaSは簡単にカスタマイズできる」という印象は、業務がシンプルなうちに限った話です。複雑な運用になるほど、追加費用と保守負担が増えやすくなります。
運用保守費:見積書に載りにくい「社内工数」もTCOに含める
SaaSはベンダーが管理してくれるため、保守コストが不要と思われがちです。しかし実際には、社内側にも継続的な運用負担が発生します。
- ユーザー追加・削除、権限変更
- 仕様変更やUI変更への社内周知
- マニュアル更新、問い合わせ対応
- トラブル時の一次切り分け
- 各部門からの改善要望の整理
これらは請求書には載りませんが、担当者の時間を確実に消費します。月5万〜15万円相当の人件費が発生しているケースもあり、5年間では300万〜900万円規模になることもあります。
つまり、SaaSのTCOを正しく見るには、ライセンス費だけでなく「社内で使い続けるための工数」も含めて考える必要があります。
【スクラッチ開発編】5年間のTCO内訳を分解してみる
初期開発費:高いが、何にいくらかかるのかを分けて考える
スクラッチ開発の最大の特徴は、初期費用が大きいことです。ただし、その費用は単なる「開発費」ではなく、複数の工程に分かれています。
| 工程 | 主な内容 | 費用目安 |
|---|---|---|
| 要件定義・業務分析 | 現状整理、要件整理、仕様策定 | 20万〜80万円 |
| 設計 | 画面設計、DB設計、構成設計 | 30万〜100万円 |
| 実装 | フロントエンド、バックエンド、API開発 | 100万〜600万円 |
| テスト | 単体、結合、受入テスト | 20万〜100万円 |
| 導入支援 | リリース、操作説明、初期サポート | 10万〜50万円 |
シンプルな業務システムなら150万〜250万円程度、中規模の統合型システムなら300万〜800万円程度がひとつの目安です。もちろん、連携の多さや要件の複雑さによって上下します。
重要なのは、初期費用だけを見て「高い」と切り捨てないことです。スクラッチ開発は、初期に投資して、その後の運用を自社に最適化する考え方だからです。
実際に、顧客管理システムをMVP(最小構成)で導入し、低予算でスタートしながら複数拠点の情報一元化を実現した事例もあります。最初からフル機能を目指さず、必要最小限から始めることで初期負担を抑えることは十分可能です。
インフラ費:ユーザー数ではなく負荷で決まるのが大きな違い
スクラッチ開発では、AWSやGoogle Cloudなどのクラウド基盤を使うのが一般的です。ここで発生するのがサーバー、ストレージ、バックアップ、セキュリティ監視などのインフラ費です。
| インフラ項目 | 小規模 | 中規模 |
|---|---|---|
| クラウドサーバー | 1万〜3万円/月 | 3万〜10万円/月 |
| バックアップ・ストレージ | 数千〜1万円/月 | 1万〜3万円/月 |
| SSL・ドメイン | 年1万〜3万円 | 年1万〜5万円 |
| セキュリティ監視・WAF | 1万〜3万円/月 | 3万〜8万円/月 |
| 合計目安 | 2万〜7万円/月 | 7万〜21万円/月 |
ここで注目したいのは、SaaSのように「1人増えるごとに課金」ではない点です。ユーザー数が20人から50人に増えても、アクセス負荷が大きく変わらなければ、インフラ費はほぼ据え置きで済むことがあります。
規模拡大時のコスト増が緩やかになりやすいのは、スクラッチ開発の大きな強みです。
保守・機能追加費:支払い続けるコストではなく「資産を育てる投資」
スクラッチ開発では、リリース後も保守費が発生します。ただし、その意味合いはSaaSとは異なります。SaaSが「使うために払い続ける費用」だとすれば、スクラッチ開発は「自社の仕組みを維持・改善するための費用」です。
- バグ修正・軽微な改修:月3万〜10万円
- セキュリティアップデート:月2万〜5万円
- 監視・定期点検:月2万〜5万円
- 月次保守合計:5万〜20万円程度
さらに、業務の変化に応じて必要な機能を追加できます。小規模な改修なら10万〜50万円、大きな機能追加なら50万〜200万円程度が目安です。
スクラッチ開発は、必要な機能にだけ投資できるため、長期的には無駄な支出を抑えやすいという見方もできます。
保守体制の違いでTCOは大きく変わる
スクラッチ開発の保守は、誰が担うかによってコスト構造が変わります。
| 保守体制 | メリット | 注意点 | 月次コスト目安 |
|---|---|---|---|
| 内製エンジニア | 対応が速い、ノウハウが残る | 人件費が高い | 50万〜100万円 |
| 外部委託 | 固定費を抑えやすい | 対応速度は契約次第 | 5万〜20万円 |
| ハイブリッド | コストと柔軟性のバランスが良い | 役割分担が必要 | 10万〜30万円 |
20〜100名規模の中小企業では、社内に専任エンジニアを抱えるより、社内担当者と外部開発会社を組み合わせるハイブリッド型が現実的です。必要なときに専門家へ依頼できるため、費用と運用のバランスを取りやすくなります。
【比較シミュレーション】従業員規模別・5年間TCO早見表
ケース①:従業員20名以下ならSaaSが有利になりやすい
業務フローがシンプルで、標準機能でほぼ対応できる小規模企業では、5年間TCOでSaaSが有利になるケースが多くあります。
SaaS(kintoneスタンダード・15ユーザー)の5年間TCO試算
| 項目 | 金額(概算) |
|---|---|
| 初期設定・データ移行 | 30万〜60万円 |
| ライセンス費 | 135万円 |
| プラグイン・追加設定 | 50万〜100万円 |
| 社内運用工数 | 60万〜120万円 |
| 合計 | 275万〜415万円 |
スクラッチ開発(同規模・シンプルな業務管理)の5年間TCO試算
| 項目 | 金額(概算) |
|---|---|
| 初期開発費 | 150万〜250万円 |
| インフラ費 | 180万円 |
| 保守費 | 480万円 |
| 合計 | 810万〜910万円 |
この規模では、標準機能で十分ならSaaSのほうが大幅に安い可能性が高いです。まずはSaaSで始める判断は合理的といえます。
ケース②:50〜100名規模では逆転が起きやすい
従業員が増え、業務も複雑化してくると、SaaSのライセンス費と運用負担が一気に重くなります。ここがTCO逆転の分岐点です。
SaaS(Salesforce Pro Suite・60ユーザー)の5年間TCO試算
| 項目 | 金額(概算) |
|---|---|
| 初期設定・コンサル費 | 100万〜200万円 |
| ライセンス費 | 3,564万円 |
| 委託・カスタマイズ費 | 500万〜1,000万円 |
| 社内運用工数 | 200万〜400万円 |
| 合計 | 4,364万〜5,164万円 |
スクラッチ開発(同規模・統合型業務システム)の5年間TCO試算
| 項目 | 金額(概算) |
|---|---|
| 初期開発費 | 400万〜800万円 |
| インフラ費 | 600万円 |
| 保守費 | 900万円 |
| 機能追加費 | 200万〜400万円 |
| 合計 | 2,100万〜2,700万円 |
この規模になると、スクラッチ開発のほうが5年間で2,000万円以上安くなるケースも十分あり得ます。特に高単価SaaSを多人数で使う場合は、ライセンス費だけで大きな差が生まれます。
ケース③:業務特化型の企業はスクラッチが有利になりやすい
業種特有のルールや複雑な計算、独自の承認フロー、多数の外部連携が必要な企業では、SaaSがそもそも合わないことがあります。その場合、無理にSaaSへ業務を合わせるより、最初からスクラッチ開発を選んだほうが結果的に安く、使いやすくなることがあります。
実際に、外貨貨幣両替業の受発注管理システムをリプレイスした事例では、既製システムの制約を避け、業務に合ったスクラッチ開発を選んだことで、適正価格と安心感の両立につながったケースがあります。
また、アクティビティ予約システムの事例では、業務フローに合わせた設計により、日々の事務作業が1/6に短縮されました。これは単なるシステム導入ではなく、業務そのものを最適化した成果といえます。
見積書に出ない「隠れコスト」まで含めると判断は変わる
TCOを考えるうえでは、請求書に載る費用だけでなく、業務上のロスも無視できません。
- 生産性ロス:SaaSに合わせるための手作業や二重入力
- 機会損失:データ活用が遅れ、意思決定が鈍る
- 停止リスク:SaaS障害時に業務が止まる
- 移行コスト:将来の乗り換え時に発生する再設定・再教育・データ変換
たとえば、10人の社員が毎月2時間ずつ余計な手作業をしているだけでも、時給2,500円換算で5年間300万円のロスになります。こうした見えない損失まで含めると、表面上は安く見えるSaaSが、実は高くついていることもあります。
本当に比較すべきなのは「導入費」ではなく、「5年間で失うお金と時間の総額」です。
費用だけでは決められない――意思決定を左右する「柔軟性」の差
SaaSの柔軟性には上限がある
SaaSは便利ですが、自由ではありません。できることはあくまでベンダーが用意した範囲内です。
- カスタマイズ上限:複雑なロジックや特殊な画面設計には限界がある
- ベンダーロックイン:データや運用がサービス依存になり、乗り換えづらくなる
- 仕様変更への依存:UI変更や機能廃止に利用者側が合わせる必要がある
つまり、SaaSの柔軟性は「一定の範囲では高い」が、「業務に完全に合わせられるわけではない」ということです。
スクラッチ開発は業務フローにシステムを合わせられる
スクラッチ開発の最大の強みは、自社の業務に合わせてシステムを設計できることです。SaaSのように「システムに業務を寄せる」必要がありません。
- 独自の料金計算や承認フローに対応できる
- 必要な機能だけを段階的に追加できる
- 現場が使いやすいUIを設計できる
- 業務改善そのものをシステムに反映できる
特に、競争優位が業務オペレーションにある企業では、この柔軟性がそのまま事業力につながります。
連携自由度の差は、業務全体の効率に直結する
企業のシステムは単体では完結しません。会計、EC、在庫、物流、基幹システムなど、複数の仕組みがつながって初めて業務全体が回ります。
| 連携内容 | SaaS | スクラッチ開発 |
|---|---|---|
| SaaS同士の連携 | ◎ | △ |
| 独自システムとの連携 | △〜✕ | ◎ |
| EC・独自DBとの接続 | △ | ◎ |
| リアルタイム同期 | △ | ◎ |
| 独自フォーマット対応 | ✕ | ◎ |
既存の基幹システムや独自サービスとの連携が必要な企業ほど、スクラッチ開発の優位性は大きくなります。
データオーナーシップも長期運用では重要
SaaSでは、業務データはベンダーの基盤上に保存されます。通常利用では問題なくても、長期的には以下のリスクがあります。
- サービス終了や価格改定の影響を受ける
- データ移行時に変換コストがかかる
- 機密情報を第三者基盤に預けるリスクがある
スクラッチ開発なら、データの保管場所や形式を自社主導で決められます。データを自社資産として管理できる安心感は、特に長期運用や将来のシステム再編を考える企業にとって大きな価値があります。
SaaSを続けるべき企業・スクラッチを検討すべき企業の判断基準
SaaSが向いている企業の特徴
次のような企業では、引き続きSaaSが合理的な選択になりやすいです。
- 業務フローが標準的で、特殊な要件が少ない
- 従業員数が少なく、ユーザー課金の負担が軽い
- 事業フェーズが初期で、要件がまだ固まっていない
- IT管理リソースが限られており、まずは早く導入したい
このような場合は、まずSaaSでスモールスタートし、事業の成長に合わせて見直す方法が現実的です。
スクラッチへの切り替えを検討すべき5つのシグナル
一方で、次のサインが複数当てはまるなら、スクラッチ開発の検討価値が高まっています。
- 年間のSaaS関連費用が大きい:ライセンス、プラグイン、委託費が膨らんでいる
- SaaSの制約が業務を止めている:やりたい運用を妥協している
- ユーザー数が増え続けている:人数増がそのままコスト増になっている
- 複数SaaSでデータが分散している:集計や分析に手間がかかる
- システムが競争力に直結している:独自業務を仕組み化したい
「SaaSで十分」ではなく、「SaaSに合わせることで損をしていないか」を見直すことが重要です。
全移行ではなく、段階的移行という選択肢もある
SaaSからスクラッチ開発へ切り替えるといっても、すべてを一度に作り直す必要はありません。現実的なのは、課題の大きい領域から順番に置き換える方法です。
- まず最も不満の大きい業務領域だけをスクラッチ化する
- 一定期間はSaaSと並行運用する
- 安定稼働を確認しながら順次切り替える
この方法なら、リスクを抑えながら移行でき、投資負担も平準化しやすくなります。
現状を見直すためのチェックリスト
- 現在のSaaSライセンス費を月次・年次で把握しているか
- プラグインや連携ツールの費用を集計しているか
- 社内担当者の運用工数を把握しているか
- SaaSでできないことを一覧化しているか
- 5年後の従業員数や業務量の増加を想定しているか
- サービス終了や価格改定のリスクを認識しているか
- 現状の非効率が売上や生産性にどう影響しているか試算しているか
この棚卸しを行うだけでも、SaaSを続けるべきか、スクラッチを検討すべきかの判断材料がかなり明確になります。
スクラッチ開発でTCOを抑えるための進め方
MVPで始めると初期投資を抑えやすい
スクラッチ開発で失敗しやすいのは、最初から完璧なシステムを作ろうとすることです。必要以上に機能を盛り込むと、開発費も保守費も膨らみます。
そこで有効なのがMVP(最小構成)です。まずは必須機能だけでリリースし、現場のフィードバックを見ながら段階的に育てていく方法です。
- 今すぐ必要な機能だけに絞る
- 使いながら改善点を見つける
- 優先度の高いものから順に追加する
「最初から全部作る」より「小さく始めて育てる」ほうが、結果としてTCOを抑えやすい傾向があります。
要件定義の精度が、後のコストを大きく左右する
スクラッチ開発でコストが膨らむ最大の原因のひとつが、要件定義の曖昧さです。開発が進んでから仕様変更が発生すると、修正コストは一気に高くなります。
- 業務フローを図で整理する
- 例外処理まで洗い出す
- 画面イメージを事前に確認する
- 既存システムとの連携要件を早い段階で確定する
要件定義に時間をかけることは、遠回りではなく最も効率的なコスト削減策です。
技術選定とベンダー選定は「5年後」を基準に考える
スクラッチ開発は、作って終わりではありません。5年後も保守しやすい技術と、長く付き合える開発会社を選ぶことが重要です。
- 市場で人材が確保しやすい技術を使っているか
- LTSや長期サポートがあるか
- コードや設計書を納品してもらえるか
- 保守対応の体制やレスポンスが明確か
- 追加費用のルールが透明か
初期見積もりの安さだけで選ぶと、後から保守で苦労することがあります。「5年後も安心して運用できるか」を基準に選ぶことが、TCO最適化の近道です。
まとめ:5年間TCOと柔軟性で考えると、最適解は企業ごとに違う
SaaSとスクラッチ開発の比較ポイント
| 比較軸 | SaaS | スクラッチ開発 |
|---|---|---|
| 初期費用 | 低い | 高い |
| 導入スピード | 速い | 遅い |
| 5年間のランニングコスト | 増えやすい | 安定しやすい |
| 少人数・標準業務 | 有利 | 不利になりやすい |
| 多人数・複雑業務 | 不利になりやすい | 有利になりやすい |
| 柔軟性 | 制限あり | 高い |
| 外部連携 | API依存 | 自由度が高い |
| データ管理 | ベンダー依存 | 自社主導 |
「SaaSは安い」「スクラッチは高い」という単純な見方では、正しい判断はできません。重要なのは、自社の規模、業務の複雑さ、成長計画、そして5年間の総コストを踏まえて比較することです。
スクラッチ開発を検討し始める目安
- 従業員数が30〜50名を超えてきた
- SaaS関連費が月30万円を超えている
- SaaSの制約で業務が非効率になっている
- 複数のSaaSやExcelでデータが分散している
- 今後3〜5年で業務の複雑化が見込まれる
- 業種特有の要件が強い
こうした条件が重なるほど、スクラッチ開発への移行が、コスト削減と業務改善の両面で有効になる可能性が高まります。
次の一歩は「現状コストの棚卸し」から
もし「自社ではどちらが得なのか判断しにくい」と感じるなら、まずは現状のSaaS費用、運用工数、業務上の不満を整理することから始めてみてください。
5年後に後悔しないためには、今の月額費用だけでなく、将来の拡張性や業務へのフィット感まで含めて考えることが大切です。システム選定は「安く始める」ことより、「長く無理なく使える」ことが重要です。