業務システムを新しくしようと開発会社に相談すると、「スクラッチで作りますか、パッケージにしますか」と聞かれることがあります。最近はクラウドのサービスやノーコードの道具も増え、選べる方法が多いぶん、どれが自社に合うのか決めにくくなっています。この記事では、スクラッチ開発で作るか既製品を使うかを決めるために、パッケージ・カスタマイズ・SaaS・ノーコードとの違いを表で比べます。あわせて、スクラッチ開発が向いている場合、公的な調査をもとにした費用と期間の考え方、発注で失敗しないための進め方を整理します。
この記事の結論
- スクラッチ開発は、業務に合わせて一から作る方法です。自由に作れる代わりに、時間と費用、発注する側の手間がいちばんかかります。
- 作るほうが向くのは、業務のやり方が自社の強みそのもので、パッケージやSaaSでは必要な機能の多くが足りない場合です。会計・給与・勤怠のような業務は既製品のほうが早く使い始められます。
- 「作るか、買うか」の二択にせず、自社ならではの部分だけを作り、どの会社でも同じ部分は既製品に任せてつなぐ組み合わせも選べます。
- 費用はおおむね「人月×単価」で決まります。JUASの調査では、スクラッチ開発の外注の人月単価は加重平均96万円でした。保守や利用料まで含め、5年、10年使う前提の合計で比べます。
- 作ると決めたら、要件定義は発注する側が中心になって固めます。見積もりは段階ごとに取り直してもらい、最初は小さく作って使いながら機能を足していきます。
スクラッチ開発とは：既製品を土台にせず、一から作ること
スクラッチ開発とは、既製のソフトウェアを土台にせず、自社の業務に合わせてシステムを一から設計し、プログラムを書いて作る方法です。英語の「from scratch（ゼロから）」が語源で、「フルスクラッチ」と呼ばれることもあります。
反対の考え方が、すでにできあがっている製品を使う方法です。ソフトウェアを買って自社に入れる「パッケージ」、インターネット経由で借りて使う「SaaS（サース）」、画面の部品を組み合わせてアプリを作る「ノーコード」などがこちらに入ります。
実際の開発では、この2つがはっきり分かれないこともあります。パッケージを土台にして、足りない機能だけをスクラッチで作り足す進め方もよく使われます。IPA（情報処理推進機構）が発注者と開発会社の守るべき考え方をまとめた『実務に活かすIT化の原理原則17ヶ条』にも、パッケージを基本とし、パッケージにない機能をスクラッチ開発で作る案件の事例が載っています[1]。そのため「作るか、買うか」を二択で考えるより、どの部分を作り、どの部分を既製品に任せるかを決める、と考えるほうが実際に近くなります。
🛠 この記事のような業務システムの課題は、ご相談ください。今の業務の流れを伺い、どこをシステムにするかから一緒に決めます（相談は無料）。
Comparison
パッケージ・SaaS・ノーコードとの違いを表で比べる
5つの方法の違いを、発注する側から見た点で並べると次のようになります。費用や期間は中身によって大きく変わるため、ここでは金額ではなく「どこにお金と時間がかかるか」で比べています。
| 方法 | どう作るか | 業務に合わせられる範囲 | お金と時間がかかる所 | 気をつけること |
|---|---|---|---|---|
| スクラッチ開発 | 一から設計してプログラムを書く | 広い。決めたとおりに作れる | 要件定義から設計・テストまでの全工程。使い始めるまでがいちばん長い | 何を作るかを発注者が決めきる必要がある。保守も自社で手配する |
| パッケージ（そのまま使う） | 市販の業務ソフトを買って入れる | 製品が用意した設定の範囲 | 製品の購入と設定、業務のやり方を製品に合わせる作業 | 製品に合わせて業務を変える覚悟が要る |
| パッケージのカスタマイズ | パッケージに手を加えたり、機能を作り足したりする | パッケージより広い | 手を加えた部分の開発と、製品の版が上がるときの作り直し | 手を加えるほど、版上げのたびに費用がかさむ |
| SaaS | インターネット経由でサービスを借りる | 利用者ごとの設定の範囲 | 月額・年額の利用料。設定と移行の作業 | 機能を決めるのはサービスを出す会社。値上げや終了もありうる |
| ノーコード・ローコード | 道具が用意した部品を画面で組み合わせる | 道具の機能の範囲 | 道具の利用料と、組み立てる人の時間 | 道具でできないことは作れない。別の道具へ移りにくい |
パッケージ開発との違い：合わせるのは製品か、業務か
いちばん大きな違いは、どちらに合わせるかです。スクラッチ開発はシステムを業務に合わせ、パッケージは業務をシステムに合わせます。パッケージは多くの会社で使われてきた業務の型が入っているため、その型に乗れる業務なら早く安定して使えます。
注意したいのは、パッケージを買ったあとに自社のやり方に合わせて手を加える「カスタマイズ」です。17ヶ条は、業務パッケージを採用するならカスタマイズを前提にしないこととし、カスタマイズ費用が思いのほか増えたり、製品の版を上げるときにそのまま使えなくなったりするおそれを挙げています[1]。同じ資料の事例では、人事給与のパッケージを、パッケージ費用の50％にあたるカスタマイズで導入し、スクラッチより費用と期間を抑えられました。ところが4年後の機器の入れ替えで製品の版上げが必要になり、カスタマイズした部分を全部作り直すことになって、最初の開発と同じくらいの費用がかかっています[1]。
SaaSとの違い：機能を決めるのはだれか
SaaSは、サービスを出す会社がクラウド上で動かしているソフトウェアを、ブラウザなどから借りて使う形です。アメリカ国立標準技術研究所（NIST）の定義では、利用者はサーバーやOSだけでなく個々の機能も管理せず、触れられるのは利用者ごとの限られた設定だけ、とされています[2]。機能の追加や変更はサービスを出す会社が決めるので、自社だけのための機能は基本的に足せません。スクラッチ開発は、機能を決める権利が自社の側にある点で正反対です。
ノーコードとの違い：作れる範囲が道具で決まる
ノーコードは、プログラムを書かずに、用意された部品を画面上で組み合わせてアプリを作る方法です。少しだけプログラムを書いて補うものはローコードと呼ばれます。IPAの解説では、プログラミングができない人でも作れ、開発の速さや費用の面で利点があるとする一方、作れる範囲は道具の機能に限られ、どんなシステムでも作れるわけではないとしています。さらに、特定の道具に頼ると他へ移りにくくなること、利用料の値上げやサービス終了のおそれがあることも挙げています[3]。
ノーコードの使いどころは、ノーコード開発のメリット・デメリットの記事でくわしく取り上げています。
When to Choose
スクラッチ開発が向いている場合、向かない場合
表のとおり、スクラッチ開発は自由に作れる代わりに、時間とお金、それに発注する側の手間がいちばんかかる方法です。まず良い点と注意点を整理し、そのうえで向いている場合と向かない場合を見ていきます。
スクラッチ開発のメリットとデメリット
メリットは、業務に合わせて作れること、ほかのシステムとのつなぎ方を自社で決められること、機能の追加を他社の予定に左右されずに決められることです。デメリットは、表で見たとおり、使い始めるまでの時間・費用と発注する側の手間がかかることです。
向いている場合
- その業務のやり方が、自社の強みそのものである場合。見積もりの出し方や生産の段取りなど、他社と違うやり方で稼いでいる業務をパッケージの型に合わせると、強みを手放すことになりかねません。
- パッケージやSaaSを試したが、必要な機能の多くが足りない場合。カスタマイズで埋める量が多いなら、先の事例のように版上げのたびに費用がかかります。初めから作るほうが、長い目で見て安くなることがあります。
- 社内のほかのシステムや取引先と、決まった形でデータをやり取りする必要がある場合。つなぎ方を自社で決められるのは、作る側の強みです。
- 同じシステムを長く使い、少しずつ育てていく予定がある場合。機能の追加や変更を、自社の予定で決められるので、使いながら育てていく使い方に合います。
向かない場合
- 会計・給与・勤怠のように、法令や一般的なやり方に沿って動かす業務。多くの会社で同じ型が使えるため、既製品のほうが早く使い始められます。
- 何を作るかがまだ決まっていない段階。スクラッチ開発は決めたとおりに作る方法なので、中身が決まらないまま始めると手戻りが大きくなります。まずノーコードなどで小さく試し、使い方が固まってから作る順番も考えられます。
- 作ったあとに直したり足したりする人や予算を用意できない場合。
迷ったときは、業務を「自社ならではの部分」と「どの会社でも同じ部分」に分けて書き出すと判断しやすくなります。後者は既製品に任せ、前者だけをスクラッチで作ってつなぐ、という組み合わせも選べます。
Cost & Schedule
費用と期間の考え方：「人月」と単価で見る
スクラッチ開発の費用は、主に「どれだけの作業量がかかるか」と「作業する人の単価」で決まります。作業量は「人月（にんげつ）」で表すのが一般的で、1人が1か月働く量を1人月と数えます。
目安として、日本情報システム・ユーザー協会（JUAS）が企業へのアンケートで長年集めてきたデータをまとめた「ソフトウェア・メトリクス調査2025【ガイドブック】」（2025年4月）の数字を紹介します。データは過去の調査からの積み重ねで、2025年に行われた開発だけの数字ではありません[4]。
| 項目 | 調査での値 | 読み方 |
|---|---|---|
| スクラッチ開発の外注の人月単価 | 加重平均96万円（99件） | 1人月あたりの外注費のおよその水準 |
| パッケージを使った開発の外注の人月単価 | 加重平均144万円（39件） | パッケージに詳しい人が必要なため高めになっている、とガイドブックはみている |
| 10〜50人月未満のスクラッチ開発 | 外注コストの平均2,951万円、工数の平均31人月（23件） | 調査の中では小さい区分。平均31人月で、外注費は約3,000万円 |
| 工数から見た標準的な期間 | 期間（月）＝3.23×工数（人月）の立方根 | たとえば125人月なら約16か月 |
| 工程ごとの期間の割合 | 要件定義20：設計〜結合テスト50：総合テスト30 | 期間の5分の1は要件定義にかかる |
この表の数字は、ある程度の規模の開発が中心の集計です。スクラッチ開発99件のうち10人月未満の開発は6件しかなく、ガイドブック自身も、集めたデータはウォーターフォール開発（工程を順番に進める作り方）が中心だと断っています[4]。中小企業の小さな業務システムにそのまま当てはめるのではなく、「単価×人月で費用が決まる」「期間は作業量に比例しては伸びない」という考え方をつかむために使ってください。
期間について、もう1つ大事な数字があります。同じガイドブックでは、50人月未満の開発の56％で、実際の期間が標準の期間を超えていました。そのため、小さめの開発ほど期間に余裕を持って計画するのが望ましいとしています[4]。
費用を考えるときは、作るときのお金だけで比べないことも大切です。17ヶ条は、開発の費用と運用・保守の費用のつり合いを考え、システムの一生にかかる費用を意識するよう求めています[1]。SaaSは毎月の利用料が続き、スクラッチ開発は保守と改修の費用が続きます。5年、10年使う前提で合計を並べると、方法ごとの差が見えやすくなります。社内で作るか外に頼むかで費用がどう変わるかは、業務システム開発の費用相場と内製・外注の判断基準の記事で整理しています。
Process
スクラッチ開発で失敗しないための進め方
1. 作る前に、既製品で足りないかを確かめる
最初に、似た業務向けのパッケージやSaaSを2〜3つ試し、自社の業務とどこが合い、どこが合わないかを書き出します。合わない部分が少なければ既製品を選び、多ければスクラッチを考えます。この比べた記録は、なぜ作るのかを社内で説明するときの材料にもなります。
2. 要件定義は発注する側が中心になって決める
17ヶ条は「要件定義は発注者の責任である」とし、決めることを先送りにした要件定義では、いずれプロジェクトが破綻すると書いています[1]。開発会社は業務の中身を知らないので、今の業務の流れ、例外の扱い、困っている点は発注する側が説明します。「今と同じでよい」という伝え方も、同じ資料で避けるよう書かれています[1]。IPAの「ユーザのための要件定義ガイド 第2版」も、要件を定義する責任はシステムを使って事業に役立てるユーザの側にあるとし、開発会社やシステム部門が中心になる進め方から、業務部門の人が主体的に関わる進め方へ変える必要があるとしています[5]。業務の流れや条件を書面にまとめて開発会社に渡す方法は、提案依頼書（RFP）の書き方の記事で、現状の業務の書き方を含めて項目ごとに紹介しています。
3. 見積もりは段階ごとに出し直してもらう
中身が固まる前に全体の金額を決めると、どちらかが無理を抱えます。17ヶ条は、あいまいな段階の見積もりを、中身がはっきりした段階で見積もり直せるルールを作ることが成功の鍵だとし、多段階の見積もりは発注者と開発会社の双方のリスクを下げるとしています[1]。まず要件定義までを頼み、その結果をもとに開発の見積もりを取る進め方が、この考え方に沿っています。契約の形の違いは請負と準委任の違いの記事で取り上げています。
4. 最初は小さく作り、使いながら足す
最初からすべての機能を入れようとすると、期間も費用も膨らみます。毎日使う中心の機能から作って使い始め、使った人の声を聞きながら機能を足していくと、使われない機能を作ってしまうことを減らせます。
5. 作ったあとのことを契約の前に決める
スクラッチで作ったシステムは、自社で面倒を見る必要があります。設計書とプログラム一式を受け取れるか、作ったプログラムの権利をどちらが持つか、不具合をどこまで無償で直してもらえるか、保守をだれに頼むかを、契約の前に開発会社と確かめておきます。見積もりを頼む前に確かめておくことは、見積もり依頼前のチェックポイントの記事にまとめています。
Sources
参考にした資料
FAQ
スクラッチ開発についてよくある質問
スクラッチ開発とパッケージ開発の違いは何ですか？
スクラッチ開発は、既製品を使わずに業務に合わせて一から作る方法です。パッケージ開発は、市販の業務ソフトを土台にして、設定や作り足しで自社に合わせる方法です。スクラッチは自由に作れる代わりに時間と費用がかかり、パッケージは早く使い始められる代わりに、業務のやり方を製品に合わせる場面が出てきます。
スクラッチ開発の費用はどれくらいかかりますか？
作るものの大きさで大きく変わるため、決まった相場はありません。費用はおおむね「作業量（人月）×単価」で決まります。JUASの2025年版ガイドブックでは、スクラッチ開発の外注の人月単価は加重平均で96万円でした。正確な金額は、要件をまとめたうえで複数の開発会社に見積もりを頼んで確かめてください。
ノーコードで作ったアプリを、あとからスクラッチで作り直せますか？
作り直すことはできますが、移し替えではなく、新しく作ることになると考えておくほうが安全です。画面や処理の決まりはそのツールの中で組んだものなので、別の作り方にそのまま持っていけるとは限りません。一方で、ノーコードで使ってみて分かった業務の流れや必要な項目は、スクラッチで作るときの要件として役に立ちます。
スクラッチで作ったシステムは、作った会社以外でも保守できますか？
設計書とプログラム一式が手元にあり、使っている技術が広く使われているものであれば、別の会社に引き継げる可能性はあります。ただし、書類がそろっていないと引き継ぎは難しくなります。契約の前に、納品物に設計書とプログラムが入っているか、プログラムの権利をどちらが持つかを確かめておいてください。
スクラッチ開発は、既製品を使わずに業務に合わせて一から作る方法で、自由に作れる代わりに、時間と費用、発注する側の手間がいちばんかかります。自社ならではの業務で、既製品では足りない部分が多い場合に向いています。どの会社でも同じ型で動く業務は、パッケージやSaaSに任せたほうが早く使い始められます。選ぶときは業務を2つに分けて考えます。作ると決めたら、まず要件定義を自社で固めます。見積もりは段階ごとに取り直し、最初は小さく作って使いながら機能を足していくと、失敗の幅を小さくできます。当社では、既製品で足りるかどうかの見極めから、要件の整理、開発と導入後の保守まで、続けてご相談いただけます。
