「業務システムを入れたいが、スクラッチ・パッケージ・SaaSのどれが自社に合うか分からない」「ベンダーごとに薦めるものが違って判断できない」——システム選定の最初の岐路がこの3択です。判断を誤ると、過剰投資・業務不適合・将来の改修地獄、いずれかに必ず嵌ります。これを正しく判断するための基準と費用比較を本記事でまとめます。
本記事では、3つの形態の違い・費用相場・メリット/デメリット・選定マトリクス・判断基準・失敗回避策を発注者目線で徹底解説します。
3つの形態の違い
| 形態 | 定義 | 代表例 |
|---|---|---|
| スクラッチ開発 | ゼロから設計・開発 | 独自業務基幹システム・カスタムWebサービス |
| パッケージ | 既製ソフトを買い切り or ライセンス | 奉行シリーズ・SAP・Oracle |
| SaaS | クラウド型サブスクリプション | freee・Salesforce・kintone・Workday |
費用比較【3年TCO】
| 形態 | 初期費用 | 月額／年額 | 3年TCO目安 |
|---|---|---|---|
| スクラッチ | 500万〜数千万円 | 保守 年10〜15% | 2,000万円〜億超 |
| パッケージ | 100〜1,500万円 | 保守 年15〜20% | 500万円〜3,000万円 |
| SaaS | 0〜100万円 | 1人月数百〜数千円 | 数十万〜1,000万円 |
「初期だけ」「月額だけ」で比べると判断を誤る
SaaSは初期が安く見えても、3年・100人で計算すると数千万円になることがあります。逆にスクラッチは初期が高くても、長期では追加開発費が抑えられるケースも。必ず3年TCO（初期＋月額×36ヶ月＋追加開発＋運用工数）で並べてください。詳細は費用対効果の計算方法を参考に。
メリット／デメリット
スクラッチ開発
| メリット | デメリット |
|---|---|
| 自社業務に100%適合 | 費用・期間が最大 |
| 競合優位性のある独自機能を作れる | 仕様変更時のコストも自社負担 |
| 機能と運用を完全コントロール | ベンダー依存・属人化リスク |
パッケージ
| メリット | デメリット |
|---|---|
| 業界標準業務に最適化済み | カスタマイズが高額 |
| 導入実績・ノウハウが豊富 | バージョンアップで影響 |
| 大規模・複雑要件にも対応 | 業務を製品に合わせる必要 |
SaaS
| メリット | デメリット |
|---|---|
| 初期費用低・短期間で導入 | 独自業務はカバーしきれない |
| 法改正・機能追加が自動反映 | 長期では人数比例で高額化 |
| ベンダー側で保守・運用 | サービス終了リスク |
判断軸：独自性 × 規模 × スピード
- 独自性：競合差別化の業務か、業界標準業務か
- 規模：利用人数・取引量・拠点数
- スピード：今すぐ欲しいか、1〜2年待てるか
- 変更頻度：頻繁に変える業務か、安定運用か
- 予算：初期に出せる額、ランニングで許容できる額
業務領域別の最適解
| 業務領域 | 標準的な最適解 |
|---|---|
| 勤怠・給与・経費・会計 | SaaS（freee／MF／弥生／勘定奉行） |
| 営業・CRM | SaaS（Salesforce／HubSpot／kintone） |
| 業界特化基幹（製造・物流） | パッケージ（業界別ERP） |
| 独自競合優位の業務 | スクラッチ |
| 多店舗POS・予約 | SaaS＋一部カスタム |
具体例：勤怠は勤怠管理SaaS、経費は経費精算SaaS、契約は契約管理SaaS、独自業務はスクラッチで、というハイブリッド戦略が中小〜中堅の標準パターンです。
選定マトリクス
| 条件 | 推奨形態 | 理由 |
|---|---|---|
| 独自性低・標準業務・小規模 | SaaS | 初期費用低・即導入 |
| 独自性低・標準業務・大規模 | パッケージ | 規模に対する固定費の効率 |
| 独自性高・小〜中規模 | SaaS＋カスタム or 軽量スクラッチ | 差別化と低リスクの両立 |
| 独自性高・大規模・長期 | スクラッチ | 競合優位を作る投資 |
| レガシー刷新 | SaaS or 段階的スクラッチ | リスク分散（リプレイス参照） |
ハイブリッド戦略
現代の現実解は「コアはSaaS、独自部分のみカスタム/スクラッチ」のハイブリッド戦略です。会計・勤怠・経費はSaaS、独自業務は自社開発、両者をAPIで連携する構成が、コストとスピードと差別化のバランスで最も合理的になります。
よくある失敗と回避策
- SaaSの安さで決めて独自業務に合わずカスタム費用が膨張→ 要件と適合度を事前に検証
- スクラッチで全部作って維持できない→ コアと標準業務を切り分ける
- パッケージを大幅カスタマイズしてバージョンアップ不能→ 標準機能を尊重
- ベンダー1社の提案だけで決める→ 必ず複数形態で比較
- 3年TCOを計算していない→ 必須
選定プロセス
よくある質問（FAQ）
業務システムは全部SaaSに置き換えるべき？
標準業務はSaaSが現実解ですが、独自業務はカスタム/スクラッチを残すハイブリッドが最も合理的。「全部SaaS」「全部スクラッチ」のどちらも極端で、業務の特性で使い分けるのが王道です。
SaaSは将来も値上がりしませんか？
主要SaaSは過去10年で値上げ傾向ですが、改修コスト・運用工数を含めると依然合理的なケースが多いです。値上げリスクを含めた3年TCOで判断してください。
スクラッチは古いやり方ですか？
競合差別化の必要な領域では今でも有効です。ただし全部スクラッチは過剰投資。コアだけスクラッチで「差別化エンジン」を作り、それ以外はSaaSで揃える戦略が現代的です。
パッケージは中堅以下では使われない？
業界特化ERP（建設・製造・小売）は中堅以下でも有力選択肢です。SaaS化が進んでいない業界では引き続きパッケージが主流です。
まとめ
- 形態の判断は「独自性 × 規模 × スピード」で決める
- 3年TCOで並べないと判断を誤る
- 標準業務SaaS＋独自業務カスタムのハイブリッドが現代の本命
- 必ず複数形態で比較し、PoCで検証
- ベンダー1社提案で決めない、自社軸の選定プロセスを持つ
システム選定の無料相談
業務要件の整理から最適な形態判断・PoC設計・
ベンダー選定までトータルでご支援します。
