SaaSとスクラッチ開発の違いは？費用・運用・連携から選ぶ

SaaSかスクラッチ開発かは、必要な業務をどこまで既存サービスで処理できるか、残る手作業はどれくらいか、導入後の運用を誰が担うかで選びます。 標準機能で業務が回るならSaaSが有力です。独自の処理や複数部門をまたぐ情報の流れが事業に欠かせず、既存機能や連携では対応が難しいなら、スクラッチ開発を検討する理由があります。

もう一つの選択肢が、SaaSを使いながら必要な部分だけを開発する方法です。顧客管理、在庫管理、受発注、請求など、業務ごとに役割を分けると、全体を作り直さずに課題を解決できる場合もあります。

SaaSとスクラッチ開発は何が違うのか

SaaSは、事業者が提供・運用するソフトウェアをインターネット経由で利用する形態です。一般に、サービス側がアプリケーションやその基盤を管理します。定義と基本的な仕組みは、AWSのSaaS解説でも説明されています。

スクラッチ開発は、自社の要件に合わせてシステムを個別に設計・開発する方法です。既存のフレームワークやクラウドサービスを組み合わせて作ることもあり、すべての部品を一から作るという意味ではありません。

厳密には、SaaSは「提供・利用の形態」、スクラッチ開発は「作り方」です。個別開発したシステムをクラウド上で動かすこともできます。この記事では、業務システムを利用する企業の立場で、市販SaaSの利用と、自社向けの個別開発を比較します。

パッケージの標準機能との適合や、将来の改修を中心に比べたい方は、もう一つの比較記事をご覧ください。コラムパッケージとスクラッチ開発の違いは？業務への適合と改修の自由度で選ぶ

費用・運用・連携で比較する

標準機能で必要な業務を処理できるなら、SaaSは個別に設計・開発する工程を抑えられ、利用開始までの期間と初期費用を抑えやすい方法です。 一方、スクラッチ開発は業務に合わせて設計できますが、要件定義・開発・テストの期間と費用が必要です。SaaSでも大規模な移行や追加連携があれば、導入の負担は大きくなります。

総費用の優劣は、利用人数・期間・連携・改修の範囲で変わります。次の表の条件を、候補サービスと開発内容ごとに確かめてください。

SaaSは「運用の担当者が一切いらない仕組み」ではありません。誰に情報を見せるか、入力ルールをどう保つか、退職者の利用をどう止めるかは、利用企業側でも決める必要があります。逆にスクラッチ開発も、保守をすべて社内で行う必要はなく、担当範囲を定めて外部に委託できます。

SaaSが合う場合と、個別開発を検討する場合

SaaSを軸に考えやすい場合

候補サービスで、日常業務と重要な例外処理が無理なく回る場合です。たとえば、顧客情報の共有、案件の進捗管理、一般的な申請・承認を標準機能で扱え、今の仕事の進め方も合理的に見直せるなら、既存サービスを活用する価値があります。

機能一覧だけで決めず、現場の担当者に一連の作業を試してもらいます。入力できても、毎月の締め処理だけExcelで組み直す、管理者にしか訂正できず仕事が止まる、といった負担がないかを確かめましょう。

スクラッチ開発を検討する理由がある場合

取引先ごとの計算、複数拠点への割り当て、部門をまたぐ承認と請求など、自社の業務に欠かせない処理があり、候補サービスの設定や連携では扱いにくい場合です。今後の事業変更に合わせて、その処理を継続的に変えていく必要があるかも判断材料になります。

ただし、「今のExcelをそのまま再現したい」だけでは、個別開発の必要性は決まりません。残すべき業務条件と、慣習で続けている手順を分けます。開発費に加えて、改修の判断をする担当者と、保守を続ける体制を用意できることも条件です。

SaaSと追加開発を組み合わせる場合

顧客管理は既存SaaSに残し、独自の見積計算や取引先向け帳票だけを別に作る、といった構成も候補です。APIはシステム同士がデータを受け渡すための仕組みで、たとえばkintoneには、レコードなどを操作するAPIが用意されています。kintone公式API資料

ただし、APIがあるだけで必要な情報をすべてやり取りできるとは限りません。契約プラン、対象項目、利用回数、更新できるタイミングを確認します。連携部分の保守も必要です。具体的な連携方法と追加開発の使い分けは、次の記事で解説しています。コラムSaaSの二重入力を減らすには？連携・追加開発の判断基準

費用は同じ業務範囲と利用期間で比べる

月額料金と開発見積もりだけでは、比較の条件がそろいません。導入から運用、将来の移行までに必要な費用を、同じ対象業務・利用人数・期間で見積もります。このように全体の費用を見る考え方を、TCO（総保有コスト）と呼びます。

支出合計の整理例：初期導入・開発費 ＋ 対象期間の利用料・基盤費・保守費 ＋ 追加改修費 ＋ 移行・終了に必要な費用。 各見積もりに含まれる項目を確認し、同じ費用を二重に足さないようにします。

社内の作業時間は、支出とは別の行に並べ、可能なら実際の件数と作業を測って見積もります。金額に換算して総費用に含める場合は、時間単価などの前提を明記し、支出に計上済みの費用と重複させません。時間が減っても、同じ額の人件費支出が直ちに減るとは限らないため、支出と社内工数は分けて示すと判断しやすくなります。

「利用人数が何人を超えたら必ずスクラッチが安い」「何年で必ず逆転する」といった共通の境界は置けません。人数が増えた場合、追加連携が必要になった場合、改修が増えた場合をそれぞれ試算し、結論が変わる条件を把握します。

開発会社から見積書を受け取った後は、各社が含めている作業の違いもそろえます。見積書の確認項目と比較手順は、次の記事で説明しています。コラムシステム開発の見積もりの見方：見積書で確かめる項目と、2社以上を比べるときのそろえ方

SaaSが現場に合わないとき、最初に確認すること

使われていない理由を整理すると、次に取るべき行動が変わります。

SaaSを導入した経験がうまくいかなかった場合も、理由を明確にしないまま開発へ進むと、同じ運用上の問題を持ち越すおそれがあります。まず「どの場面で、誰の仕事が、なぜ止まるのか」を具体化してください。

Ouverの事例に見る、既存SaaSの活用と新規開発

ここでは、各公開事例で確認できる支援内容を紹介します。製品の比較結果や採用理由を示すものとしては扱いません。

既存SaaSを使うための業務整理・運用設計

廃品回収会社の事例では、契約したSaaSの利用が進まず、Ouverが業務の可視化、標準機能との適合性確認、運用設計、導入に向けた調整を支援しました。新規開発を前提にせず、SaaSに合わせる業務と、別の方法で補う情報を整理した取り組みです。事例SaaSを導入したのに使われない。廃品回収会社の業務整理・運用設計を支援した事例

分散した案件管理と入力業務を新しいシステムに統合

産業廃棄物処理会社の事例では、担当者ごとのExcelや複数の仕組みに分かれていた案件・見積・売上の情報を、新しい業務システムで扱うようにしました。対象業務での個別ファイル管理と二重・三重入力を解消しています。事例営業担当者ごとのExcel管理と二重入力を解消｜老舗の産業廃棄物処理会社の業務システム開発事例

2件で紹介している対象業務と支援内容は異なります。自社の検討でも、解消したい作業と必要な運用を整理したうえで、対応方法を比べます。