「うちの業務は特殊だから、既製品では合わない気がする」。
基幹システムを検討する経営者から、よく聞く言葉です。一方で「わざわざ作るより、出来合いのものを使うほうが早いのでは」という声もあります。
どちらも正しく、どちらも間違っています。判断を分けるのは、業務の性質と会社の規模だからです。
この記事では、ERP導入支援を手がけるベンチャーネットが、パッケージとスクラッチ開発の選び方を整理します。読み終えると、次の3つが分かります。
- パッケージとスクラッチ開発、それぞれ何が違うのか
- 自社はどちらに向いているのか、どう判断すればよいか
- 「どちらか」ではない第三の考え方
まず、2つの考え方の違いを整理する
パッケージERPとは
すでに作られている製品を導入し、業務をその製品に合わせていく考え方です。
SAP、NetSuite、Odooなどが該当します。会計、販売、在庫といった標準的な業務の機能が、最初からそろっています。
スクラッチ開発とは
自社の業務に合わせて、必要な機能をゼロから作る考え方です。
既製品にない業務でも実現できます。近年は生成AIの活用により、開発の期間と費用が以前より抑えられるようになりました。
根本的な違いは「どちらを合わせるか」
パッケージは、業務をシステムに合わせます。スクラッチは、システムを業務に合わせます。
この違いが、費用の構造にも、変更のしやすさにも、そのまま影響します。
パッケージERPの利点と制約
利点
すぐに使い始められる
機能が最初からそろっているため、設定と業務設計が中心になります。ゼロから作るより早く動き出せます。
世界標準の業務プロセスが手に入る
多くの企業で使われている製品には、業務の型が組み込まれています。自社の非効率を見直すきっかけになります。
継続的に改善される
ベンダーが機能を更新し続けます。自社で開発しなくても、新しい機能が使えるようになります。
扱える人が多い
広く使われている製品なら、経験のある技術者や支援先を見つけやすくなります。
制約
業務を変える必要がある
現行のやり方をそのまま再現しようとすると、カスタマイズが膨らみ、費用も期間も増えます。
使わない機能にも費用がかかる
必要な機能だけを選んで買うことは、多くの場合できません。
固有の業務には合わないことがある
標準から大きく外れた業務は、無理に合わせると使いにくくなります。
スクラッチ開発の利点と制約
利点
必要な機能だけを作れる
使わない機能に費用をかける必要がありません。
固有の業務をそのまま実現できる
競争力の源泉になっている独自のやり方を、無理に変えずに済みます。
継続的なライセンス費用がない
自社の資産として持つ形になります。
制約
開発費用と期間がかかる
ゼロから作るため、初期の投資が必要です。ただし生成AIの活用で、以前より負担は下がっています。
保守の責任が自社に残る
作った後、誰が面倒を見るのか。ここを決めずに進めると、数年後に動かせないシステムになります。
属人化しやすい
作った人しか分からない状態になると、事業の引き継ぎやすさに影響します。ドキュメントの整備が欠かせません。
「ライセンス不要＝安い」ではない
継続的なライセンス費用がない代わりに、開発費と保守費が発生します。ここを見落とすと、数年後の計算が合わなくなります。
「どちらか」ではなく、4つの選択肢で考える
実務では、二択で考えると判断を誤ります。規模と要件によって、適した位置が変わるためです。
ベンチャーネットは、基幹システムを4つの選択肢で捉えています。
| 選択肢 | 対象のイメージ |
|---|---|
| SAP | 大企業・グローバルで複雑な要件 |
| NetSuite | 中堅企業・グローバル展開を目指す成長企業 |
| Odoo | 中小〜中堅企業 |
| AIスクラッチ開発 | より小規模、またはパッケージに乗らない固有業務 |
上の3つがパッケージ、いちばん下がスクラッチ開発です。
中堅規模以上のクラウドERPの比較は ERPの比較と選び方（NetSuiteの教科書） にまとめています。
この4段は、3つの方向で使えます。
現在地でのマッチング：いまの規模と要件に合う段を選ぶ
段を下る：上位ERPの負担が重い場合に、規模に合った段へ移る
段を上る：成長に備えて、先回りして上の段から始める
判断の軸：4つの質問
自社がどこに当てはまるかは、次の4つで整理できます。
質問1：業務は標準から、どれだけ離れているか
近い（受注・在庫・請求が一般的な流れ）→ パッケージが有利
遠い（業界特有・独自の商流）→ スクラッチ開発が候補
ただし「うちは特殊」という認識の多くは、実際には標準で対応できます。本当に特殊なのはどの部分か、具体的に洗い出すことが先決です。
質問2：必要な業務範囲は広いか
広い（会計・販売・在庫・製造など複数）→ パッケージが有利
狭い（特定の業務だけ）→ スクラッチ開発が候補
範囲が広いほど、ゼロから作る負担は大きくなります。
質問3：会社の規模と、これからの成長は
成長が見込まれる→ パッケージのほうが拡張しやすい
規模が小さく安定→ スクラッチ開発でも十分に回る
質問4：システムを維持する体制はあるか
社内に技術者がいない→ パッケージのほうが安全
開発と保守を任せられる先がある→ スクラッチ開発も選択肢
作った後に誰が面倒を見るのか。ここが決まらないまま作ると、動かせないシステムが残ります。
第三の考え方：組み合わせる
実務では、どちらか一方に決める必要はありません。
標準業務はパッケージ、固有業務はスクラッチ
会計・販売・在庫といった標準的な業務はパッケージで回し、競争力に直結する独自の業務だけを別に作る。この組み合わせが現実的な場面は多くあります。
まずスクラッチで始めて、後からパッケージへ
小さく始めたい会社が、必要な機能だけをスクラッチで作る。事業が成長したら、パッケージへ移行する。
ただし、乗り換えにはデータ移行と再教育の負担が伴います。急成長が見えているなら、最初からパッケージを選ぶ判断もあり得ます。
判断の基準は「3〜5年後」
いまの規模ではなく、将来から逆算してください。
成長の途中でシステムを乗り換えると、二度の負担になります。どこから始めるかは、3〜5年後の姿から決めるのが本質です。
どちらでも共通する成功条件
目的を測れる形にする
「DXのため」ではなく、「受注から請求までの転記をなくす」のように具体化します。目的が曖昧なままだと、どちらを選んでも評価できません。
業務を見直す機会にする
システムの導入は、業務を棚卸しする数少ない機会です。
パッケージなら「標準に合わせる」、スクラッチなら「本当に必要な機能だけ作る」。どちらも、業務の仕分けが前提になります。
稼働をゴールにしない
現場に定着し、業務が回り始めて、はじめて投資が回収されます。稼働後の教育と運用を、最初から計画に入れてください。
よくある質問
「うちは特殊だから既製品は無理」と言われました
その認識が正しいかを、具体的に確認してみてください。
「特殊」とされる業務の多くは、実際には標準機能で対応できます。本当に特殊なのは一部だけ、というケースがほとんどです。まず、どの部分がどう特殊なのかを項目に落とし込む作業から始めてください。
スクラッチ開発のほうが安く済みますか？
一概には言えません。
継続的なライセンス費用はありませんが、開発費用と保守費用が発生します。業務範囲が広いほど、開発の負担は大きくなります。総額で比較する必要があります。
生成AIで開発が安くなったと聞きました
開発の期間と費用は、以前より抑えられるようになりました。
ただし、AIが肩代わりするのは実装の一部です。「どんな業務をどう回すか」を決める作業や、保守を担う体制は、依然として必要です。ここを見落とさないでください。
途中で方針を変えられますか？
変えられますが、負担が発生します。
データ移行、業務の再設計、現場の再教育。だからこそ、最初の判断で3〜5年後まで見通しておくことをおすすめします。
まとめ：業務の性質と規模で選び分ける
この記事の要点です。
- パッケージは業務を製品に合わせ、スクラッチは製品を業務に合わせる
- 判断の軸は4つ。標準からの距離・業務範囲の広さ・規模と成長・維持する体制
- 「うちは特殊」の多くは、標準で対応できる。具体的に洗い出すことが先決
- スクラッチは「ライセンス不要＝安い」ではない。開発費と保守費が発生する
- どちらか一方に決めず、組み合わせる考え方もある
- 判断の基準は、いまの規模ではなく3〜5年後の姿
システムの選択は、突き詰めると「何を自社の独自性とし、何を標準に委ねるか」という問いです。これは技術の問題ではなく、経営の問題です。
ベンチャーネットは、SAP、NetSuite、Odoo、AIスクラッチ開発の4つをすべて扱っています。だからこそ、特定の方向に誘導する必要がありません。
パッケージが合うと判断すればそうお伝えし、スクラッチ開発が現実的ならそちらをご提案します。組み合わせが最適なら、その設計もご一緒します。
「うちの業務は、どちらに向いているのだろう」と迷ったら、業務の洗い出しからご一緒します。
もう少し詳しく知りたい方へ
関連記事
