MAGAZINE TOP

業務システムはSaaS・パッケージ・スクラッチのどれを選ぶ?――領域別の判断軸と3年の総費用の比べ方

業務のカードを、雲・段ボール箱・工具の印が付いた3つのトレイへ仕分ける人のイラスト。業務システムの作り方を、SaaS・業種向けパッケージ・スクラッチから選ぶことを表す

業務システムを入れ替えたいものの、SaaS、業種向けパッケージ、スクラッチのどれを選べばよいか決めきれずにいる方もいらっしゃるのではないでしょうか。見積もりを取っても方式ごとに含まれる費用の範囲がそろわず、金額を並べるだけでは比べられないこともあります。SaaSをカスタマイズして使い続けるより、生成AIを使って自社向けに作り直すほうがよいのではないかと考え始めた方もいるかもしれません。

そこで本記事では、業務システム開発を提供するスパイスファクトリー株式会社が、どの業務にどの方式を選ぶかについての当社の見解と、3年の総費用の比べ方をお伝えします。当社はスクラッチ開発を請け負う立場ですが、スクラッチを選ばないほうがよい場面も含めて書きます。

業務の領域ごとに、最初に検討する方式を決める

当社は、業務システムの作り方を会社全体で一つに決める必要はないと考えています。次の表は、最初に検討する方式を業務の領域ごとに本記事で整理したものです。同じ業務でも、事業の中心にあるかどうかで扱いは変わります。

業務の領域 例 最初に検討する方式 別の方式も比べる場合
制度で型が決まり、他社と差がつかない業務 給与計算、勤怠、労務手続き、会計 SaaS 法令や取引先との契約上、標準の機能では対応できない要件があるとき
業界の商習慣が強く反映される業務 業界固有の帳票・計算・取引の管理 業種向けパッケージ 大掛かりなカスタマイズが要るとき、競争力に大きく関わるとき、製品の技術基盤や安全性に懸念があるとき
売上を左右し、進め方に自社の違いがある業務 営業支援(SFA)、顧客管理(CRM)、見積、顧客向けの受付 標準のまま使えるならSaaS カスタマイズが大きくなるとき。SaaSへの外付け開発とスクラッチを比べる
Excelやメールに分散した周辺の業務 案件管理、社内申請、部門をまたぐ集計 SaaSの組み合わせ 転記が残り続けるとき。足りない部分だけの開発を検討する

方式によって、費用のかかり方と変更の自由度が違う

比べる点 SaaS(単体・組み合わせ) 業種向けパッケージ SaaS+外付け開発 スクラッチ
業務への合い方 業務を製品に合わせる 業界の標準に業務を合わせる 中核はSaaSに合わせ、差分を開発する 業務に合わせて作る
費用のかかり方 利用料が毎月続く。組み合わせると連携の費用が増える 製品費、導入作業、保守料 利用料に加え、開発と運用保守の費用 初期の開発費に費用が集中し、運用保守が続く
制度改正への対応 標準機能はベンダーの更新で対応 保守契約の範囲で対応 開発した部分は利用企業の負担 調査・改修・テストを改正のたびに負担
変更の自由度 製品の仕様の範囲 カスタマイズの範囲。増えるほど版の更新が重くなる 開発した部分は自由だが、SaaSの連携仕様に左右される 高い。変更のたびに費用がかかる
データと権利 データの出力機能と解約条件による データの出力機能とライセンス条件による 開発した部分は契約による コードと設計資料の扱いは契約で決める
導入後の主な負担 業務の見直し、設定の管理 版の更新、カスタマイズの保守 連携の監視と保守 運用保守の担い手の確保

給与・勤怠・会計は、なぜSaaSを第一候補にするのか

給与計算や会計は、法令で計算方法や帳簿の要件が決まるため、独自に作っても他社との差になりにくい業務です。その一方で制度は頻繁に変わります。

給与計算では、2024年6月の定額減税(新しいタブで開きます)、2024年10月と2026年10月の社会保険の適用拡大(新しいタブで開きます)、2026年4月分の保険料からの子ども・子育て支援金(新しいタブで開きます)、2025年(新しいタブで開きます)と2026年(新しいタブで開きます)の年末調整に関わる基礎控除などの改正と対応が続き、社会保険の適用範囲は2027年10月以降も段階的に広がります。会計でも、2024年1月からの電子取引データの保存(新しいタブで開きます)、2026年10月のインボイス制度の経過措置の変更(新しいタブで開きます)がありました(いずれも2026年11月6日に公的資料で確認)。

制度改正に伴う標準機能の更新をベンダーが担う点が、SaaSを第一候補にする理由です。スクラッチでは、改正の内容を調べ、改修し、テストする費用を改正のたびに負担するため、この領域に開発費をかける理由は小さくなります。McKinseyの2026年の分析(新しいタブで開きます)も、標準化が進んだ業務では、企業は追跡性を欠くおそれのあるAI製の個別の仕組みより、監査できる基幹のシステムを選ぶだろうとみています。

ただし、ベンダーが引き受けるのは標準機能の範囲です。独自の手当や帳票をカスタマイズで足している場合、その部分の修正は利用企業の負担になることがあり、設定の変更や結果の確認も社内に残ります。契約前に、制度改正への対応が標準の料金に含まれるか、カスタマイズや連携の部分は誰が直すか、過去の改正で施行日のどれくらい前に反映されたかを確かめてください。

SFA・CRMはSaaSか、自社開発か――標準のまま使えるかで分かれる

SFAやCRMは売上に関わる業務を支えますが、どの会社にも独自のシステムが要るわけではありません。商談の進め方が製品の標準に収まる業態であれば、SaaSをそのまま使うほうが早く導入でき、製品の機能追加も受け取れます。

判断が分かれるのは、SaaSに手を入れないと業務が回らない場合です。項目や承認の追加が設定で済むうちは問題になりませんが、画面や業務の流れを作り込む開発が増えると、カスタマイズ費と保守費が積み上がり、標準のまま使うというSaaSの利点が薄れます。

この場面で比べる案は3つあります。業務を標準に合わせる案、SaaSを残して足りない部分だけを外付けで作る案、スクラッチで作る案です。当社は、AI駆動開発(生成AIを前提に、設計・実装・テストなどの工程を組み直す開発)が実用になった今、SaaSのカスタマイズが大きくなる業務では、スクラッチも費用の比較に含めることを勧めます。

買わずに作る判断は、調査にも表れ始めています。McKinseyの2026年の調査(新しいタブで開きます)(回答者1,719人・97か国、年間売上10億ドル超の組織に属する回答者が36%)では、回答者の32%が、所属する組織がエージェント型のコーディングツールで内製できたためにソフトウェア製品または機能の購入を1つ以上見送ったと答えました。国内では、エイトレッドが従業員100人以上の企業で業務にAIを使う担当者107人に行った2026年の調査(新しいタブで開きます)で、AIの進化を受けてSaaSの見直しを実施した人は15.0%、検討中の人は48.6%で、見直しの必要性を感じる86人が挙げた対象はプロジェクト管理(45.3%)に次いでSFA(44.2%)でした。いずれもスクラッチが安く済むことを示すものではなく、国内の調査は小規模で、見直しの中身もスクラッチへの置き換えに限りません。

中核の業務アプリの扱いには慎重な見方もあります。先のMcKinseyの分析は、営業のように差別化につながる業務では自作が優位につながり得る一方、標準化が目的のERPでは大規模には続かないとしています。Gartner(新しいタブで開きます)は、ERPやCRMのような主要システムを見直している組織は22%で、個別の機能を担う製品の51%を下回るとし、中核の業務アプリを急いで置き換える計画を最大の誤りに挙げています。当社も置き換えを急ぐことは勧めません。標準のSaaSでカスタマイズ費が大きくなる業務に限って、見積もりを取り、総費用で比べることを勧めます。

比較には、実装とテストだけでなく、業務の整理、関係者の合意、データの移行、リリース後の運用保守も含めます。AIの利用料も費用で、McKinseyの同じ調査では、回答者の約2割が、トークン費用を含む運用費のために所属する組織がAIの利用を制限していると答えました。

業種向けパッケージは最初に検討し、3つの場合に見直す

業種向けパッケージには、特定の業界で使われるなかで積み重ねられた帳票、計算、取引の例外への対応が入っています。一から整理すると時間のかかる業務知識を製品として受け取れるため、業界の商習慣が強い業務では最初に検討します。

見直すのは3つの場合です。1つ目は、SaaSと同じように大掛かりなカスタマイズが必要な場合で、カスタマイズが増えるほど、版の更新のたびに検証と改修の費用がかかります。2つ目は、その業務が競争力に大きく関わる場合で、AI駆動開発によるスクラッチも比較します。3つ目は、製品の技術基盤や安全性に懸念がある場合です。

長く続く製品は実績がある一方で、改修を重ねるうちに古い設計や基盤が残り、更新やセキュリティ対応の制約になることがあります。次の表の質問で確かめます。自社のサーバーに置いたパッケージを社外からVPNでつないで使う場合は、VPN機器の更新も評価に含めます。警察庁の報告(新しいタブで開きます)では、2026年上半期のランサムウェアの被害組織へのアンケートで、侵入経路の約5割がVPN機器でした。

確認する点 ベンダーへの質問 注意したい答え
技術基盤 動作するOS・データベース・実行環境と、それぞれのサポート期限は サポートが終わった環境でしか動かない。更新の予定が示されない
脆弱性への対応 脆弱性が見つかったときの修正の提供手順と、利用企業への通知方法は 修正の提供条件や適用の担当が決まっていない
認証と記録 多要素認証、シングルサインオン、操作ログに対応しているか 対応の予定がない
データと連携 データを標準の形式で出力できるか。APIはあるか。解約時の扱いは 出力が都度の有償作業になる。解約時の扱いが契約にない
制度改正 改正への対応は保守料に含まれるか 改正のたびに個別の見積もりになる
カスタマイズと更新 カスタマイズした状態で版を更新するときの費用と検証の担当は 更新のたびに費用が読めない

自社の業務を4つに当てはめて、候補を絞る

候補の製品が見えたら、業務を入力・判断・出力の単位で書き出し、製品ごとに次の4つに当てはめます。4つの分類は本記事の整理です。

分類 意味 総費用に入れるもの
標準で済む 製品の標準機能のままで回る ライセンス
設定で済む 項目・権限・承認の流れなどの設定で回る 設定の作業と管理
追加の開発が要る カスタマイズ、連携、外付けの開発が要る 開発費、保守費、版の更新の検証
手作業で残る 人が転記や確認を続ける 社内の手間(時間×人件費)

見るのは件数より場所です。業務の中心が「標準で済む」と「設定で済む」に収まるならSaaSやパッケージを選びます。開発が周辺の連携や帳票にとどまるなら外付けの開発を検討し、中心の業務に開発が集まるならスクラッチを比較に加えます。「手作業で残る」は転記の回数を週単位で数えます。転記が残ると、利用料を払いながら同じ手間を続けることになるためです。

契約の更新やサポート終了の期限がある場合は、期限までに動く範囲も重ねて確認します。全体が間に合わなくても、中心の業務から順に移す案なら成り立つことがあります。

3年の総費用は8つの費目で比べる

次の8つの費目を方式ごとに埋め、それぞれを初期にかかる費用と年ごとの費用に分けて、3年分を合計します。

費目 SaaS(組み合わせを含む) 業種向けパッケージ スクラッチ
開発 製品の外に作る追加機能(外付け開発) 製品の外に作る追加機能 連携と移行を除く要件定義・設計・実装・テスト
ライセンス 年ごとの利用料(単価×利用者数)。AI機能の追加料金も含める 製品費と年間の保守料 使う外部サービスの利用料
カスタマイズ 設定作業、導入支援 製品本体の改修 開発に含む
連携 SaaS間の連携ツール、API連携の開発 既存システムとの接続部分の開発 接続先ごとの接続部分の開発
移行 データの移行、並行稼働、利用者の教育
運用保守 外付け・連携部分の保守 サーバー、版の更新と検証 クラウド費、監視、障害対応、基盤の更新、改修
制度改正への対応 標準機能は料金に含まれるかを確認。カスタマイズ部分は別 保守契約の範囲を確認 改正ごとの調査・改修・テスト
社内の手間 手作業の残り、設定の管理、問い合わせ対応 手作業の残り、版の更新の確認、問い合わせ対応 要件の検討、受け入れの確認、問い合わせ対応

比べるときは、次の5つに気をつけます。

  • 業務の範囲をそろえる。利用者数と単価は年ごとの見込みを使う
  • 社内の手間は、時間×人件費で金額にする
  • SaaSの利用料は、更新時の料金改定とAI機能の課金の変更を見込む。Gartner(新しいタブで開きます)は、企業向けSaaSの費用が更新時に10〜20%以上上がることが多いとしている
  • 3年後に別の方式へ移るときの費用(データの出力、解約、移管)も書き添える
  • 比較の期間は結果を見る前に決める。初期費用の大きい案があるときは、3年に加えて5年でも計算する

金額は業務の範囲、連携先、品質要件で大きく変わるため、本記事では金額の目安を示しません。運用保守と追加開発は、対応範囲を分けて見積もりを取り、総費用に含めます。日本情報システム・ユーザー協会(JUAS)のソフトウェアメトリックス調査2020(新しいタブで開きます)(2019年度、平均の開発費は数億円規模)では、スクラッチの保守と追加開発に5年でほぼ開発費と同じ費用がかかり、パッケージでは稼働後の追加と保守の年間の費用が、初期費用に対する比率でカスタマイズ部分は本体の約3倍でした。

補助金と会計処理も結果を動かします。中小企業向けのデジタル化・AI導入補助金2026(新しいタブで開きます)の通常枠では、対象は事務局に登録されたITツールで、スクラッチ開発を伴うソフトウェアは登録の対象外です(2026年11月6日に公募要領と登録要領で確認)。年度ごとの損益の見え方は会計処理で変わるため、総費用とは別に税理士や経理に確認してください。

スクラッチを選ぶ前に決めておくこと

スクラッチの成否は、作る前に決めることで大きく変わります。第一に、仕様を決める人を社内に立てられるかです。業務の例外を判断できる人が関われなければ、AIで実装を進めても手戻りが増えます。第二に、リリース後の運用保守を誰が担うかです。基盤の更新が止まれば、古いパッケージと同じ問題を自社で抱えることになります。

第三に、コード、設計資料、データを自社に残せるかです。権利の帰属は契約で決まり、IPAのモデル取引・契約書(第二版)(新しいタブで開きます)にも、納入物の著作権を開発会社に帰属させる案を含む3つの案があります。スクラッチなら自動的に自社のものになるわけではないため、別の会社へ引き継げる状態で受け取れるかを発注前に確かめます。AI駆動開発の場合は、生成したコードを誰がレビューし、どのテストと受入基準で検証するかも確認してください。DORA(Googleのソフトウェア開発の研究チーム)(新しいタブで開きます)は、AIはスループットを高める一方、土台が固まっていなければ安定性を損なうことが多いと報告しています。

規模の大きなシステムを一度に作る必要はありません。投資判断の前に、モックアップで画面と業務の流れを確かめれば、要件の認識のずれを早い段階で見つけられます。当社では、数週間かかっていた検証用プロトタイプを数時間で形にし、投資判断の前に価値を確かめられます。AI駆動開発に適した考え方や前提条件の整備が前提となります。常にこれだけの改善が得られるわけではありません。また、プロトタイプは検証用で、本番の品質を備えたものではありません。

よくある質問(FAQ)

スクラッチ、フルスクラッチ、ハーフスクラッチの違いは何ですか?

スクラッチは既製の製品を使わず、業務に合わせて新しく作る方法で、フルスクラッチも同じ意味で使われます。線引きは会社によって異なり、フレームワークや既存の部品を使う開発も含むのが実務の使い方です。ハーフスクラッチは、パッケージやSaaSを土台に足りない部分だけを開発する方法で、本記事の「SaaS+外付け開発」に近い考え方です。発注時には、どこまでを新しく作るのかを見積もりの前提として確認してください。

中小企業でもスクラッチを選ぶ意味はありますか?

業務の中心に標準の製品では足りない部分があるなら、検討する意味はあります。全業務を作る必要はなく、給与や会計はSaaSに任せ、差がつく業務だけを作る形が現実的です。その場合も、リリース後の運用保守の担い手と年間の費用を先に決めてください。

SaaSのカスタマイズ費が高いとき、AI駆動開発のスクラッチに切り替えるべきですか?

カスタマイズ費が高いことだけでは決まりません。まず要望を設定で済むものと開発が要るものに分け、業務を標準に寄せられないかを確かめます。それでも中心の業務に開発が集まるなら、外付けの案とスクラッチの案の見積もりを取り、8費目の3年の総費用で比べます。費用は対象範囲、品質要件、既存システムとの連携、運用保守の前提で変わるため、スクラッチがSaaSより安くなるとは一律に言えませんが、総費用が下回る場合もあります。

SaaSを先に導入して、後からスクラッチに移れますか?

移れますが、データを標準の形式で出力できるか、APIで取り出せるか、解約後にいつまでデータを取得できるかで費用が変わります。後から移る可能性があるなら、導入の前に確認してください。

3年と5年のどちらで比べるべきですか?

3年を基本に、スクラッチや買い切りのパッケージのように初期費用の大きい案があるときは5年でも計算します。期間は見積もりの前に、契約更新やサポート終了の時期に合わせて決めます。

まとめ――比較の出発点は、製品ではなく業務の仕分け

業務システムの作り方は、会社全体で一つに決めるのではなく、業務の領域ごとに決めます。給与や会計のように制度で型が決まり、他社と差がつかない業務はSaaSを第一候補にします。業界の商習慣が強く反映される業務は、業種向けパッケージから検討します。営業や顧客管理のように売上を左右する業務は、標準のまま使えるならSaaSを選び、大きなカスタマイズが必要なら、AI駆動開発によるスクラッチも含めて3年の総費用で比べます。

業務を領域に分け、標準で足りる範囲を確かめ、残った差分に3年でいくら払うことになるかを比べてください。標準の業務がSaaSで足りるなら、当社はスクラッチを勧めません。

スパイスファクトリーでは、業務システム開発とAI駆動システム開発で、どの方式が合うかの整理から支援しています。SaaSで十分かどうかは導入判断チェックリストで確かめられます。作るものの形を先に見たい場合は、無料モックアップ相談をご利用ください。

堅いご挨拶も、資料の準備もいりません。
まずはお話を聞かせてください。

お問い合わせをする お問い合わせをする