スクラッチ開発とパッケージ開発の違い|案件票の「スクラッチ」「SAP導入」で変わる人材像・商流・提案先
公開日:2026年9月30日更新日:2026年9月30日
スクラッチ開発とは?意味をひとことで
スクラッチ開発とは、既製のソフトを使わず、システムを一から設計して作る開発のことです。 英語の from scratch(ゼロから)が語源です。
スクラッチ開発では、画面・機能・データの持ち方を、発注する会社に合わせて決めます。主な特徴は次の3つです。
会社独自の業務に、細かく合わせられる
作る量が多いので、期間と費用がかかりやすい
設計からテストまで、すべての工程が発生する
総務省の日本標準産業分類でも、注文を受けて作る開発は「受託開発ソフトウェア業(3911)」として区別されています。分類の全体像は情報通信業とは?5つの中分類とSES企業・取引先の業種の位置で解説しています。
「フルスクラッチ」「セミスクラッチ」との違い
案件票では「フルスクラッチ」「セミスクラッチ」という言葉も見かけます。
フルスクラッチ:土台になる製品を一切使わず、すべて自社向けに作る開発
セミスクラッチ:既存の部品やひな形を一部使い、残りを自社向けに作る開発
営業としては、どちらも「言語で人を選ぶ案件」と考えて大丈夫です。
パッケージ開発とは?意味をひとことで
パッケージ開発とは、すでに完成しているソフト(パッケージ)を土台にして、会社に合わせて設定や追加の開発をすることです。 「パッケージ導入」とも呼ばれます。
パッケージとは、多くの会社が同じものを買って使えるように作られたソフトのことです。日本標準産業分類では、パッケージソフトを作って売る会社は「パッケージソフトウェア業(3913)」に入ります。
パッケージ開発の案件では、次の2つの言葉がよく出ます。
カスタマイズ:パッケージに元からある設定を変えて、会社の業務に合わせること
アドオン:パッケージに足りない機能を、追加で開発して付け足すこと
代表的なのが、会計・人事・販売などをまとめて管理する ERP(基幹業務システム)です。中でも SAP(ドイツのSAP社が作るERP製品)は、案件票でよく見る製品名です。
「パッケージベンダー」とは
パッケージベンダーとは、パッケージソフトを作ったり、売ったりする会社のことです。 ベンダーは「売る側の会社」という意味です。→ ITベンダーとは?外部ベンダーの意味と選ばれる条件
製品を作った会社(メーカー)だけでなく、導入を手伝う会社も含めて呼ぶことがあります。導入を手伝う会社は「導入パートナー」「販売代理店」とも呼ばれます。
CMSの「スクラッチ開発」とは
Webサイトの案件では「CMSをスクラッチ開発」という書き方もあります。CMSとは、専門知識がなくてもWebページを更新できる仕組みのことです。
WordPressなど既製のCMSを使う → パッケージ(既製品)寄りの案件
CMSそのものを一から作る → スクラッチ開発の案件
同じ「CMS案件」でも、求める人材が変わります。既製のCMSならその製品の経験を、スクラッチなら言語の経験を先に確認しましょう。
スクラッチ開発とパッケージ開発の違いを表で比較
2つの一番大きな違いは、「一から作るか、既製品を土台にするか」です。 作り方の違いが、期間・費用・求められる人の違いにつながります。
| 比べる点 | スクラッチ開発 | パッケージ開発 |
|---|---|---|
| 作り方 | 一から設計して作る | 既製のソフトを土台に設定・追加 |
| 自由度 | 高い(何でも作れる) | 製品の機能の範囲に縛られる |
| 期間・費用 | かかりやすい | 抑えやすい(アドオンが多いと増える) |
| 向いている会社 | 独自の業務が強みの会社 | 業界で標準的な業務の会社 |
発注する会社(エンド)は、この違いを見て開発の方法を選びます。独自の業務が多いならスクラッチ、標準的な業務ならパッケージを選ぶことが多いです。
ただし、パッケージでもアドオンを大量に作ると、スクラッチに近い開発になります。案件票に「アドオン開発」とあれば、開発の量が多い案件と考えて確認しましょう。
案件票で見る「スクラッチ」と「パッケージ」の違い:人材像・単価・商流
案件票の書き方で、求められる人材・単価の決まり方・商流が変わります。 SES営業にとっては、案件票の読み分けが一番大事です。
| 案件票の書き方 | 求められる人材像 | 単価・商流の傾向 |
|---|---|---|
| 「スクラッチ開発」「新規開発」 | Java・C#などの言語と工程の経験 | 言語と工程で決まる。SIer経由が多い |
| 「SAP導入」「ERP導入」 | 製品の経験+会計・販売などの業務知識 | 製品経験で決まる。導入パートナー経由が多い |
| 「アドオン開発(ABAPなど)」 | 製品専用の言語の経験 | 言語が限られ、人が集めにくい |
| 「パッケージ保守」 | その製品の運用・問い合わせ対応の経験 | 長く続きやすい |
ABAP(アバップ)とは、SAP製品のアドオン開発に使う専用の言語のことです。
人材像の違い
スクラッチの案件は「何の言語で、どの工程をやったか」で人を選びます。 製品の知識はほとんど問われません。
パッケージの案件は「どの製品を、どのモジュールで触ったか」で人を選びます。 モジュールとは、製品の中の機能のまとまりです。SAPなら会計、販売、購買などに分かれています。
さらにパッケージ案件では、業務知識が重く見られます。会計の案件なら、仕訳や決算の流れがわかる人が求められます。
単価の考え方の違い
パッケージ案件は「その製品を触れる人が少ない」ほど、単価が上がりやすくなります。 言語の経験者より、特定製品の経験者のほうが見つけにくいからです。
一方、スクラッチ案件は、言語と工程の組み合わせで単価が決まります。具体的な相場の調べ方はSESの単価相場|職種別の月額目安と公的データの使い方で解説しています。
商流の違い
パッケージ案件は、メーカー・パッケージベンダー系の商流になりやすいです。 製品を売る会社と、導入を手伝う会社がつながっているためです。
スクラッチ開発の例 エンド(ユーザー企業)→ 元請けSIer → 一次請け → 自社 パッケージ導入の例 エンド(ユーザー企業)→ 導入パートナー(パッケージベンダー系のSIerなど)→ 一次請け → 自社
メーカー系のSIerは、グループの製品や取り扱い製品の導入を多く受けます。系統の違いはメーカー系SIer一覧|ユーザー系・独立系・外資系と4系統の違いにまとめています。導入パートナーの協力会社として登録する方法はSIerの協力会社登録の条件と流れ|審査で見られる7項目で紹介しています。
SES営業の現場での使い方
案件票で「スクラッチ」か「パッケージ」かを読み分けると、提案する人と提案先を間違えにくくなります。 ここでは、そのまま使える手順と例文を紹介します。
案件票を読み分ける5つの手順
製品名があるかを見る:「SAP」「Salesforce」などの製品名があれば、パッケージ寄りの案件です。
「スクラッチ」「新規開発」の言葉を探す:あれば、言語と工程で人を選ぶ案件です。
アドオンの有無を確認する:パッケージでも「アドオン開発」なら、製品専用の言語の経験者が必要です。
工程を確認する:導入の「要件定義」か、「保守」かで、合う人が変わります。
商流を確認する:パッケージ案件なら、導入パートナーがどこかを聞きます。聞き方は記事末の「次に読む・使う」の商流の記事を参考にしてください。
確認の例文(案件をくれた会社へ)
件名:Re: 【案件】基幹システム刷新のご紹介 株式会社〇〇 □□様 いつもお世話になっております。株式会社△△の◇◇です。 案件のご紹介ありがとうございます。 要員を選ぶため、次の3点を教えていただけますでしょうか。 1. 開発方式(スクラッチ/パッケージ導入。製品名もあればお願いします) 2. 担当範囲(設定・カスタマイズ/アドオン開発/保守) 3. 担当するモジュールや業務(会計・販売など) お手数ですが、よろしくお願いいたします。
社内での使い方の例
社内の会話でも、次のように使います。
「この案件、スクラッチだから言語で探そう。Javaで基本設計からできる人は?」
「SAPの会計モジュールの案件だ。製品経験者は少ないから、パートナーにも早めに流そう」
「パッケージだけどアドオン中心らしい。ABAPが書ける人がいるか確認して」
よくある勘違いと注意点
「パッケージだから簡単」と思わない:製品と業務の知識が要るので、むしろ人が探しにくいことが多いです。
製品名だけで決めない:同じSAPでも、導入・アドオン・保守で求める人が違います。
スキルシートに製品名を書く:パッケージ案件では、製品名とモジュール名がないと書類で落ちやすくなります。
SAP経験者の提案メールの例
件名:【ご提案】SAP FI(会計)導入/K.M.(SAP経験6年)
・SAP ECC 6.0のFIモジュール(会計)の保守3年、S/4HANAへの移行案件で要件定義・設定2年
・決算・仕訳の業務知識あり(前職で経理3年)
・ABAPはレポートの軽微な修正のみ
・参画可能日:2026年11月1日
製品名・モジュール・工程・業務知識を1行ずつ書くと、書類で判断されやすくなります。
パッケージ案件の提案先の選び方
パッケージ案件をねらうなら、製品のメーカーと、その導入パートナーを提案先にします。 製品ごとに、導入を手伝う会社がある程度決まっているからです。
提案先を探す手順は次のとおりです。
自社のエンジニアが触った製品を書き出す:SAP、Salesforce、会計パッケージなどを一覧にします。
製品ごとの導入パートナーを調べる:多くのメーカーは、公式サイトでパートナー企業を紹介しています。
パートナー企業の採用・協力会社募集を見る:協力会社を募集していれば、提案の入り口になります。
製品経験者をまとめて紹介する:「SAP会計の経験者が2名います」のように、製品単位で案内します。
SAP移行の案件を見かけやすい背景
SAP社は、旧製品「SAP Business Suite 7」の標準保守を2027年末までとしています。延長保守は2030年末まで選べます。
この期限に向けて、新製品「SAP S/4HANA」への移行を進める会社があります。SAP移行に関わる案件は、2027年末に向けて見かける機会が多いと考えられます。
自分で案件の「開発方式」を管理する方法
まずはExcelやスプレッドシートに、案件ごとの開発方式を1列足すことから始めましょう。 次の列を作ると、似た案件を探しやすくなります。
開発方式(スクラッチ/パッケージ)
製品名(SAP、Salesforceなど)
モジュール・業務(会計、販売など)
担当範囲(導入/アドオン/保守)
商流(エンド、元請け・導入パートナー、自社までの会社の数)
人材側にも「触った製品」の列を作っておくと、案件と人をすぐ結びつけられます。表の作り方はSESの案件・人材管理をExcelで無料で行う方法|テンプレ付きを参考にしてください。
契約の形も確認しましょう。パッケージ導入では、請負で受けて一部を準委任で頼む形もあります。→ 準委任契約と請負契約の違い|業務委託契約書を見分ける判定シート
チョータツで案件と人材の情報をまとめて管理する
案件が増えてExcelで追いきれなくなったら、SES営業向けの管理ツール「チョータツ」を使うと楽になります。 チョータツは、株式会社DrivenXが提供する、案件・人材の管理・共有ツールです。
チョータツでできることは次のとおりです。
案件・人材の情報を管理し、社内で共有できる
パートナー企業へのメール配信機能がある
他社と連携すると、他社の営業中案件・営業中人材をデータベース化できる
AIが入力を手伝う
チョータツは3,000社以上が利用しており、無料で始められます。製品経験者のような「探しにくい人」を、社内外からまとめて探す手間を減らせます。
社内やBPにSAP経験者がいないときは、フリーランスに直接声をかける方法もあります。xhoursなら、ITフリーランスに直接スカウトを送れます。
よくある質問
- Q. スクラッチ開発とパッケージ開発、どちらが多いですか?
- 案件によって違い、どちらか一方だけが多いとは言えません。SES営業としては、両方の案件票を読み分けられるようにしておくことが大切です。
- Q. パッケージ開発の案件に、スクラッチ経験だけのエンジニアは入れますか?
- アドオン開発や周りのシステムとの連携部分なら、入れる案件もあります。ただし多くは製品の経験が求められます。提案前に担当範囲を確認しましょう。
- Q. 「パッケージベンダー」と「SIer」の違いは何ですか?
- パッケージベンダーは、パッケージソフトを作ったり売ったりする会社です。SIerは、システム全体を組み立てて納める会社です。SIerがパッケージの導入パートナーを兼ねることもあります。
- Q. CMSのスクラッチ開発とは何ですか?
- WordPressなどの既製のCMSを使わず、Webページの更新の仕組みを一から作る開発です。案件票では、言語の経験で人を選ぶ案件として読みます。
- Q. SAP案件は今後も続きますか?
- SAP社は旧製品の標準保守を2027年末まで、延長保守を2030年末までとしています。新製品への移行に関わる案件は、当面見かけることが多いと考えられます。
まとめ
スクラッチ開発は一から作る開発、パッケージ開発は既製のソフトを土台に作る開発
スクラッチ案件は「言語と工程」、パッケージ案件は「製品と業務知識」で人を選ぶ
パッケージ案件は、メーカー・パッケージベンダー・導入パートナー系の商流になりやすい
案件票では、製品名・アドオンの有無・工程・商流を確認してから提案する
開発方式と製品名を案件・人材の両方に記録しておく。数が増えたらチョータツで管理すると楽になる
運営:チョータツSES研究所(株式会社DrivenX)|編集方針|公開日:2026年9月30日|更新日:2026年9月30日
参考資料(2026年9月30日確認)
総務省 政府統計の総合窓口(e-Stat)「3911 受託開発ソフトウェア業」
総務省 政府統計の総合窓口(e-Stat)「3913 パッケージソフトウェア業」
SAP Support Portal「Maintenance for SAP Business Suite 7 and SAP S/4HANA」(Business Suite 7の標準保守は2027年末まで、延長保守は2028年初めから2030年末まで)