SaaS、パッケージ、スクラッチ開発は、優劣ではなく業務との距離で選びます。標準の業務へ合わせられるならSaaS、業界固有の土台を使いながら一部を変えるならパッケージ、競争力や既存設備に直結する手順を変えられないならスクラッチが候補です。初期費用だけで決めず、変更、連携、運用、終了時のデータ取り出しまで比べます。
たとえば、一般的な経費精算はSaaSへ業務を合わせやすい一方、得意先ごとに締め日が異なり、FAX注文の品番を独自マスタへ読み替え、月末に販売奨励金を再計算する受注業務は標準機能だけで収まらないかもしれません。ただし、その独自手順を全部残すべきかは別の話です。手作業の癖までスクラッチで再現すると、古い運用を高い費用で固定します。
SaaS・パッケージ・スクラッチ開発は、何を基準に選ぶのか？
業務への適合、変更頻度、連携、運用責任、終了時のデータ取得を同じ表で比べて選びます。
最初に製品名を並べず、対象業務を「標準へ合わせる部分」と「変えられない部分」に分けます。そのうえで三つの選択肢を同じ表で比べます。
| 比較軸 | SaaS | パッケージ | スクラッチ開発 |
|---|---|---|---|
| 業務への合わせ方 | 提供された標準機能へ寄せる | 標準機能を土台に設定・追加開発する | 自社の要件から設計する |
| 導入時の主作業 | 選定、設定、移行、教育 | 選定、設定、カスタマイズ、移行 | 要件定義、設計、開発、移行 |
| 変更の自由度 | 提供範囲とAPIに依存 | 製品構造と保守条件に依存 | 設計と保守体制の範囲で決める |
| 更新の主体 | SaaS提供者 | 製品提供者と導入会社 | 自社と開発・保守会社 |
| 費用の見方 | 利用料、設定、連携、移行 | ライセンス、導入、追加開発、保守 | 開発、基盤、運用、継続改修 |
| 終了時の確認 | エクスポート形式と期限 | データ、追加開発、ライセンス | ソース、設計書、データ、運用引継ぎ |
IPAの情報システム・モデル取引・契約書は、受託開発だけでなく、パッケージやSaaS/ASPを活用する取引のモデルも分けて公開しています。選択肢が変わると、利用許諾、設定、追加開発、保守、サービス終了時の責任も変わります。
SaaSを最初に試してよいのは、どんな業務か？
標準手順へ合わせられ、連携と権限が提供範囲に収まる定型業務からまず小さく試します。
勤怠、経費精算、オンライン会議のように、多くの会社で共通する手順はSaaSの候補です。導入前にデモを見るだけでなく、自社の申請、承認、差し戻し、月次締めを試用環境で最後まで通します。
中小企業庁の中小企業のためのクラウドサービス安全利用の手引きは、利用する業務と情報の範囲、コスト、情報の重要度、社内ルールとの整合を確認するチェックシートを示しています。機能があるかだけでなく、誰が管理者になり、障害時にどこへ連絡し、解約時にデータをどう受け取るかを確認します。
SaaSへ合わせるために、不要な承認や転記をやめられるなら、それは利点です。反対に、取引条件や法令、現場設備との接続まで標準へ無理に寄せると、SaaSの外でExcelやメールが増えます。
パッケージが向くのは、どんな業務か？
業界固有の標準機能を使い、一部の設定や追加開発で業務へ合わせる場合の選択肢になります。
販売管理、生産管理、会計のように、業界や業務の共通部分が厚く、導入実績のある製品を土台にしたい場合が候補です。スクラッチより前に、標準機能、オプション、外部連携、追加開発の順で適合を見ます。
確認すべきは、導入時に動くかだけではありません。製品のバージョンアップ時に追加開発が残るか、特定の導入会社しか保守できないか、標準機能へ戻す手順があるかを聞きます。
「パッケージだから仕様が固い」と決めつけず、変えられる場所と変えるべきでない場所を製品ごとに確認します。逆に、標準から大きく外れる追加開発を積み上げるなら、そのパッケージを選ぶ理由が薄れていないか見直します。
スクラッチ開発を選ぶのは、どんな場合か？
独自業務が競争力や設備連携に直結し、標準へ寄せる損失が大きい場合に限って選びます。
得意先別の受注条件、工場設備とのリアルタイム連携、独自の配車判断など、業務そのものが会社の強みであり、既製品では重要な判断を再現できない場合があります。その部分はスクラッチの候補です。
ただし、ログイン、通知、ファイル保存まで全部独自に作る必要はありません。共通部分はSaaSやクラウドの標準機能を使い、独自性がある部分だけ作る組み合わせも検討します。
スクラッチでは、完成後の保守責任を先に決めます。誰が障害を見るか、OSやライブラリを更新するか、開発会社が変わるときにソースと設計書を渡せるか。作る自由と、持ち続ける責任は同じ側にあります。
初期費用以外は、どう比べればよいか？
導入、利用、改修、運用、終了を同じ期間へそろえ、総額と社内作業まで具体的に比べます。
3年間で比べるなら、請求書に載る金額だけでなく、社内担当者が行う設定、問い合わせ、マスタ整備、手作業の残りも並べます。期間は契約更新や設備更新に合わせて自社で決めてください。
| 費用・作業 | SaaS | パッケージ | スクラッチ開発 |
|---|---|---|---|
| 導入 | 初期設定、移行、教育 | ライセンス、導入、追加開発 | 要件定義、設計、開発、移行 |
| 継続 | 利用人数・容量に応じた料金 | 保守料、基盤、製品更新 | 基盤、監視、保守、セキュリティ更新 |
| 変更 | 設定、外部連携、プラン変更 | 追加開発、更新影響の確認 | 要件整理、設計変更、テスト |
| 社内作業 | 管理者、マスタ、問い合わせ | 製品担当、ベンダ調整 | 業務責任者、開発・保守管理 |
| 終了 | データ出力、移行、並行契約 | データ・追加開発の移管 | ソース・設計・運用の引継ぎ |
金額に幅がある見積もりを比べるときは、超概算・概算・詳細見積の違いも確認してください。SaaSの月額とスクラッチの開発費だけを横に置くと、比較期間も含む作業もそろいません。
「作らない」と判断してよいのは、どんなときか？
発生頻度が低く、損失が小さく、既存機能や手順変更で解けるなら専用開発を見送ります。
月に一度、担当者一人が確認する作業へ専用システムを作る前に、既存SaaSの設定、チェックリスト、業務手順の変更で足りないか試します。自動化後の監視や例外対応のほうが重くなるなら、手作業を残す判断もあります。
試用や小さな検証で、現場が標準手順へ移れないと分かった場合も、すぐスクラッチへ進みません。移れない理由が取引条件なのか、単なる慣れなのかを分けます。慣れを理由に古い手順を再現すると、変更の機会を失います。
デジタル庁のデジタルマーケットプレイスは行政向けの仕組みですが、SaaSをカタログから検索する前に調達仕様を整理する考え方は参考になります。製品を選ぶことと、解決したい業務を決めることは別です。
社内では、比較前に何を決めておくべきか？
変えられる手順、残す独自性、連携先、予算期間、運用責任者を社内で導入前に決めます。
現場へは「いまの画面を残したいか」ではなく、「この判断を変えると何が起きるか」を聞きます。取引先との契約、設備、法令に結びつくものは残す候補です。担当者の並べ替えや転記の癖は、変更できる候補になります。
経営側は、選定期間、比較する総額の期間、サービス終了や開発会社変更のリスクを決めます。安く始めることだけでなく、止めるときにデータと業務を取り戻せるかを判断します。
開発会社へは、選定のために何を渡せばよいか？
現行手順、例外、データ、連携先、変更頻度、標準へ寄せられる範囲を一組で渡します。
匿名化した帳票、画面、CSVを用意し、通常の一件と、差し戻しや月末締めの一件を見せます。連携先は製品名だけでなく、CSV出力、API、手入力のどれが使えるかも確認します。
相談先には、三案すべての見積もりを無理に求めません。まず既存SaaS・パッケージで満たせる範囲と不足を調べ、その不足が業務上許容できないときだけ追加開発やスクラッチを検討します。
一次情報は、どの資料を確認したか？
契約責任、クラウド利用範囲、SaaS調達を扱う三つの公的な一次資料を確認しました。
関連記事と相談先は、どこから確認できるか？
要件整理、見積段階、開発体制の記事を往復し、選択肢を具体化してから相談できます。
Heygoodは、相談を受けた時点でスクラッチ開発へ決めません。現在の業務とデータを見て、既存SaaSへ合わせられる部分、パッケージで補える部分、作る理由が残る部分を分けます。作らない判断も含めて、比較表を一緒に作るところから相談できます。