LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

業務システムを作り直したいが、一から作るべきか、パッケージを入れるべきか決められない。見積もりを取ったら、パッケージのほうが安いはずなのに追加開発の費用がふくらんでいた——。システムの入れ替えを任された担当者の現場では、こうした迷いが起こりがちです。スクラッチ開発とパッケージ開発の違いは、既製品を土台にするかどうかにあります。

最近はSaaSも選択肢に加わり、比べる相手は3つになりました。ただしどれか1つが常に正しいわけではなく、業務ごとに向き不向きがあります。本記事では、システムの選定を任された情報システムの担当者に向けて、3つの選択肢の違い、選び分けが大切な理由、選び分けの進め方、そして外部に頼むときに確認したい点を整理します。

スクラッチ開発とパッケージ開発とは

スクラッチ開発は、既製品を土台にせず、業務に合わせてシステムを一から設計して作る進め方です。これに対してパッケージ開発は、すでに完成している市販のソフトウェア（パッケージ）を土台にして、設定や追加の開発で自社の業務に合わせる進め方を指します。経済産業省とIPA（情報処理推進機構）のモデル契約書は、パッケージを「特定の業種又は業務を想定し、そのなかで汎用的に使用されることを前提とした市販ソフトウェア」と説明しています。^*3

• スクラッチ開発：画面・機能・データの持ち方をすべて自社の業務に合わせて決められる
• パッケージ開発：会計・販売管理・人事など、多くの会社に共通する業務の仕組みを土台にする
• パッケージ開発で合わせる手段は、パラメータ設定（用意された設定項目の切り替え）、補完製品の組み合わせ、パッケージ本体の改修（モディファイ）、追加機能の開発（アドオン）の4つ^*3
• SaaS（インターネット経由で使うソフト）：提供会社のクラウド上で動くアプリをWebブラウザなどから使う形。利用者は基盤もアプリの機能も管理せず、触れるのは利用者ごとの限られた設定だけ^*1

SaaSはパッケージと同じく「既製品を使う」選択肢ですが、自社のサーバーに入れるのではなく、提供会社が動かしているものを借りて使う点が違います。

3つの選択肢の違い

スクラッチ開発とパッケージ開発、そしてSaaSの違いは、「どこまで自社に合わせられるか」と「導入した後の手入れを誰が受け持つか」の2点に集約できます。費用や期間は規模と業務によって大きく変わるため、ここでは考え方の違いを表にまとめます。

表のとおり、自由に作れる度合いと手入れの手間は裏表の関係にあります。スクラッチ開発は業務にぴったり合わせられる代わりに、法改正や業務の変更があるたびに自社の費用で直します。SaaSは手入れを提供会社に任せられる代わりに、機能が合わなければ業務の側を変えるしかありません。パッケージ開発はその中間にあたります。

なぜ使い分けが大切なのか

経済産業省のDXレポート2（2020年12月）は、日本企業のシステムは米国企業と比べて受託開発で作る割合が高く、パッケージを使う場合もカスタマイズ（自社向けの作り込み）が多いと指摘しています。米国ではパッケージを極力カスタマイズせずに使い、複数を組み合わせて素早く導入するのが一般的だとしています。^*2

• 競争領域（自社の強みになる業務）と協調領域（他社と共通の業務）を見分ける^*2
• 協調領域は業務を標準化し、パッケージやSaaSを使うことでIT投資を抑える
• 抑えた予算と人を、競争領域のシステムに回す

同じレポートは、業務の標準化が進まないと「パッケージを導入しても多数のカスタマイズが必要になる」ことも起こると述べています。^*2 一方で、使えるパッケージやSaaSが無い業務で、規模の大きな開発になる場合には、受託開発は合理的な選択だったとも書いています。^*2 どれか1つに決めるのではなく、業務ごとに選び分けるという考え方です。

どう選び分けるのか

スクラッチ開発かパッケージ開発かは、システム全体で1つに決める必要はありません。業務ごとに分けて、次の4つのステップで進めます。

• ステップ1：業務を、自社の強みになる業務と他社と共通の業務に分ける
• ステップ2：共通の業務について、SaaSやパッケージの候補が業務に合うかを確かめる
• ステップ3：合わない部分の扱いを決める
• ステップ4：導入後の保守を、どの会社がどこまで受け持つかを決める

ステップ3で迷いやすいのが、パッケージが業務に合わない部分の扱いです。モデル契約書は、適合性が低いときの選択肢として、改修や追加機能の開発に切り替える、外部のプログラムを作る、業務をパッケージに合わせる、優先度を下げてシステム化しない、の4つを挙げています。^*3 改修や追加開発で要件を満たせば満足度は上がりますが、同じ資料は「システムの保守性、信頼性は低くなる」とも述べています。^*3 作り込みが増えるほどパッケージの利点が薄れるため、改修の量が多くなる業務はスクラッチ開発と比べ直します。

外部に頼むときに確認しておきたい点

スクラッチ開発もパッケージ開発も、多くの会社では開発会社に委託して進めます。パッケージを使う場合、本体はパッケージの製造会社、追加部分は開発した会社が保守を受け持つ形になり、障害が起きたときに原因の切り分けが難しくなると、モデル契約書は注意を促しています。^*3 見積もりを取る前に、次の点を確かめておきます。

• 候補の評価の幅：機能が業務に合うかだけでなく、使用許諾契約の制限、SaaSならSLA（サービス品質の取り決め）、版上げの方針まで見ているか^*3
• 合わない部分の扱い：改修・追加開発・業務の変更のどれを選ぶかを、理由と合わせて示してくれるか
• 保守の分担：障害が起きたとき、どの会社が最初に受け付けて切り分けるかが決まっているか
• 版上げへの備え：パッケージやSaaSが新しい版になったとき、追加した機能の動作を誰が確かめるか
• パッケージを使わない提案：合う製品が無いときに、スクラッチ開発を含めた別の案を出してくれるか

費用の見方は業務システム開発の費用相場で、ノーコードやローコードと比べたい場合はノーコード・ローコードとスクラッチ開発の比較で扱っています。

まとめ：選び分けで確かめておきたい3つの点

スクラッチ開発とパッケージ開発、そしてSaaSから選ぶうえで、確かめておきたい点は3つに整理できます。第一に、システム全体ではなく業務ごとに、自社の強みになる業務か他社と共通の業務かを分けること。第二に、パッケージが合わない部分を改修で埋めるのか、業務の側を変えるのかを、保守の手間まで含めて決めること。第三に、導入後の保守をどの会社がどこまで受け持つかを、契約の前に決めておくことです。この3点を踏まえておけば、「安く済むと思って入れたパッケージが、追加開発だらけで手に負えなくなった」という事態を避けやすくなります。選び分けや見積もりの比べ方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：NIST SP 800-145「The NIST Definition of Cloud Computing」（https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf）。出典：Service Models のうち Software as a Service (SaaS) の定義（提供会社のアプリをクラウド上で使う・利用者は基盤やアプリの機能を管理しない・利用者ごとの限られた設定のみ）を参照（2026年10月確認）
2. *2　参考：経済産業省「DXレポート2（中間取りまとめ）」（2020年12月28日）（https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation_kasoku/pdf/20201228_3.pdf）。出典：競争領域と協調領域の識別、協調領域でのパッケージソフトウェア・SaaSの活用、日米のシステム構築の違い、受託開発が合理的だった場面についての記述を参照（2026年10月確認）
3. *3　参考：経済産業省・独立行政法人情報処理推進機構（IPA）「情報システム・モデル取引・契約書（パッケージ、SaaS/ASP活用、保守・運用）＜第二版追補版＞」（https://www.ipa.go.jp/digital/model/model20201222.html）。出典：パッケージソフトウェアの説明、パラメータ設定・補完製品・モディファイ・アドオン、適合性が低い場合の4つの選択肢、パッケージ候補の評価項目、保守の分担についての記述を参照（2026年10月確認）

Tweet