スクラッチ開発とは パッケージとの違いと費用・期間の目安、選ぶ判断基準を解説

「パッケージでは自社の業務に合わない」「スクラッチだと高いと言われたが、実際どのくらいかかるのか」。システムの導入方式を検討する段階で、必ず出てくる論点です。

スクラッチ開発は、パッケージ製品やテンプレートを使わず、自社の要件に合わせてシステムを新規に設計・開発する方式です。業務に合わせて自由に作れる反面、費用と期間がかかります。

ただし、よく使われる「ゼロから作る」という表現には誤解があります。実際にはフレームワークやライブラリといった既存の部品を活用しており、すべてを自作するわけではありません。

この記事では、他の開発方式との違いを整理したうえで、メリットとデメリット、実績データにもとづく期間と規模の目安、そして選ぶべきかどうかの判断基準までを順に扱います。

確認したいポイント	結論	詳細
スクラッチ開発とは？	要件に合わせて新規に開発する方式	パッケージやテンプレートを使わず、自社の業務に合わせて設計・開発する方法です。
本当にゼロから作る？	フレームワークは活用する	すべてを自作するわけではありません。既存の部品を使いながら独自に組み上げます。
期間の目安は？	実績では中央値10.1か月	IPAの調査では、プロジェクト全体の工期の中央値が10.1か月となっています。
判断の軸は？	パッケージで7割満たせるか	標準機能で大半が足りるならパッケージ、業務が競争力の源泉ならスクラッチです。

この記事でわかること

• スクラッチ開発の定義と、フルスクラッチという言葉との違い
• パッケージ、SaaS、ローコードを含めた4方式の比較
• メリットとデメリットを、実務での影響の大きさとあわせて整理
• IPAの実績データにもとづく、工期・工数・体制規模の目安
• どちらを選ぶかの4つの判断基準と、よくある失敗パターン

システム開発とAI活用の進め方をまとめた資料を無料で配布しています 要件整理の進め方、開発の依頼範囲や体制の決め方、費用と期間の目安を1冊にまとめました。 稟議の検討材料としてご活用いただけます。 ＞ 資料請求はこちら ※オンライン完結／しつこい営業は一切いたしません

スクラッチ開発とは

スクラッチ開発は、既存の製品やテンプレートに依存せず、要件に合わせてシステムを新規に設計・開発する方式です。英語のfrom scratch（最初から）に由来します。

住宅に例えると分かりやすくなります。スクラッチ開発は間取りから自由に決めるフルオーダー住宅、パッケージ開発は大枠が決まっていて細部を選ぶセミオーダー住宅という関係です。

「ゼロから作る」という表現の誤解

最初に押さえておきたい点です。スクラッチ開発が「何も使わずすべてを作る」という意味ではありません。

実際の開発では、プログラミング言語の標準機能、フレームワーク、公開されているライブラリ、クラウドのサービスを組み合わせて使います。認証やログ出力といった汎用的な処理を一から書くことはありません。

つまり、業務ロジックと画面を自社の要件に合わせて作るのがスクラッチ開発です。土台となる部品は既存のものを使います。この理解があると、費用感の見通しも現実的になります。

フルスクラッチとの違い

似た言葉として、フルスクラッチという表現があります。厳密な定義の差はなく、実務ではほぼ同じ意味で使われます。

強調したい文脈で「フル」が付くという程度の違いです。「既存のシステムを一部流用せず、完全に新規で作る」という意味合いで使われることもあります。

呼び方より、何をどこまで新規に作るのかを具体的に確認するほうが重要です。ベンダーとの打ち合わせでは、流用する部分と新規に作る部分を明確にしておきます。

どういう場面で選ばれるのか

スクラッチ開発が選ばれるのは、既存の製品では要件を満たせない場合です。業務の進め方そのものが他社と異なり、それが競争力になっているケースが典型です。

独自の料金計算ロジック、特殊な生産工程の管理、業界特有の商流への対応。こうした要件は、汎用のパッケージには含まれていません。

逆に、会計や給与計算のように法令で処理方法が決まっている業務では、スクラッチ開発を選ぶ理由がほとんどありません。パッケージのほうが確実で安価です。

他の開発方式との違い

比較対象は3つあります。それぞれ自由度とコストが逆の関係にあります。

パッケージ開発

既製のソフトウェア製品を導入し、必要な範囲をカスタマイズする方式です。業種や業務に特化した製品が多数あり、標準機能で大半の要件を満たせる場合に有利です。

利点は、期間が短く費用を抑えられること、多くの企業で使われているため品質が安定していること、法改正への対応がベンダー側で行われることです。

難点は、カスタマイズを重ねると費用が膨らみ、バージョンアップが困難になることです。改造した部分が、製品の更新時に作り直しになります。「カスタマイズは3割まで」という目安が語られるのはこのためです。

SaaSの利用

クラウド上で提供されるサービスを月額で利用する方式です。初期費用が最も低く、導入も最短です。

サーバーの管理が不要で、機能も継続的に改善されます。利用者数に応じた課金が一般的なため、小規模から始められます。

一方で、カスタマイズの自由度は最も低くなります。提供される機能の範囲で業務を組む必要があり、サービス側の仕様変更や値上げの影響も受けます。

ローコード・ノーコード

画面上の操作を中心にアプリケーションを作る方式です。スクラッチとパッケージの中間に位置づけられます。

業務に合わせた画面や処理を、コードをほとんど書かずに作れます。開発期間が短く、現場の担当者が自分で作ることも可能です。

制約は、プラットフォームの機能の範囲を超えられないことと、規模が大きくなると性能や保守性の問題が出ることです。小規模な業務アプリには有効ですが、基幹システムには向きません。

4方式の比較

自由度と、費用・期間はほぼ反比例します。何を優先するかで選択が決まります。

　　　　　　　　自由度　費用　期間　保守の負担

スクラッチ　　　　高　　 高　　長　　　高

パッケージ　　　　中　　 中　　中　　　中

ローコード　　　　中　　 低　　短　　　中

SaaS　　　　　　 低　　 低　　最短　 低

表の見方として注意したいのは、保守の負担です。スクラッチ開発は作った後も自社で面倒を見る必要があります。この負担を計算に入れずに判断すると、稼働後に苦しくなります。

スクラッチ開発のメリット

自由度の高さが、すべての利点の源になっています。

業務に合わせて設計できる

最大の利点です。既存製品の制約を受けず、自社の業務フローに合わせて画面と処理を設計できます。

パッケージを導入すると、製品の想定する業務の流れに自社を合わせることになります。標準に合わせるのが望ましい場面も多いものの、その業務が競争力の源泉であれば、変えるべきではありません。

既存システムとの連携も柔軟に組めます。データの受け渡し方式を自社の環境に合わせて設計できるため、無理な変換処理を挟む必要がなくなります。

拡張と改修の自由度が高い

事業の変化に応じて、必要な機能を追加できます。製品のバージョンアップを待つ必要がありません。

パッケージでは、要望した機能が次のバージョンに入るかどうかはベンダーの判断です。自社にとって重要な機能でも、他社の需要が少なければ実装されません。

製品のサポート終了に振り回されないという点も利点です。パッケージは製品の提供終了とともに移行を強いられますが、スクラッチであれば使い続ける判断ができます。

ベンダーロックインを避けやすい

特定の製品に依存しないため、理論上は開発を担う会社を変えられます。ソースコードと設計書を自社で保有していれば、別の会社に引き継げます。

ただし、これは条件付きの利点です。ソースコードの著作権が自社に帰属しているか、設計書が納品されているかによって、実際に移行できるかが変わります。

契約時にこの点を確認する必要があります。IPAが公開する情報システム・モデル取引・契約書（第二版）は、ユーザ企業とITベンダのいずれにもメリットが偏らない中立的な契約書を目指して作成されたもので、成果物の範囲や権利の扱いを整理する際の参考になります。

ライセンス費用が発生しない

パッケージ製品にはライセンス料が必要です。買い切り型と月額型がありますが、いずれもスクラッチ開発では発生しません。

利用者数に応じた課金もないため、社員が増えても費用は変わりません。長期間かつ大人数で使うシステムでは、この差が積み上がります。

ただしサーバーやクラウドの利用料、保守費用は発生します。ライセンス料がないことと、運用費用がゼロであることは別です。

スクラッチ開発のデメリット

自由であることの代償が、そのまま難点になります。

費用と期間がかかる

最も分かりやすい難点です。設計から実装、テストまでをすべて行うため、パッケージの導入と比べて数倍の工数がかかります。

パッケージであれば数か月で稼働できるものが、スクラッチでは1年以上かかることもあります。事業のスピードが求められる場面では、この差が決定的になります。

「早く安く」を求めるならスクラッチは向きません。これは技術や交渉の問題ではなく、方式そのものの性質です。

要件定義の負荷が大きい

見落とされやすい点です。パッケージには「標準の業務の流れ」が用意されていますが、スクラッチには何もありません。すべてを自社で決める必要があります。

画面の項目、入力のルール、権限の範囲、帳票の様式、例外時の処理。これらを漏れなく決めるのは、想像以上に負荷の高い作業です。

この作業を担うのは発注側です。ベンダーは支援できますが、業務を知っているのは自社だけです。担当者の時間を確保できなければ進みません。要件の書き方は要件定義の例｜システム種類別の要件例と、機能要件・非機能要件の書き換え集も参考になります。

品質が発注側の関与に左右される

パッケージは多くの企業で使われているため、基本機能の品質が実績で担保されています。スクラッチで作ったものは、そのシステムが初めての利用者になります。

潜在的な不具合が残っている可能性があり、受入テストの重要性が高くなります。ここを丁寧に行わないと、稼働後に問題が発覚します。

発注側がテストに割ける時間が、品質に直結します。この体制が確保できないなら、実績のあるパッケージを選ぶほうが安全という判断もあります。

保守の体制が必要になる

稼働後も自社で面倒を見続ける必要があります。不具合の修正、法改正への対応、利用しているライブラリの更新、セキュリティ対策。

パッケージであれば、これらの多くがベンダー側で行われ、保守費用に含まれます。スクラッチでは、対応のたびに個別の見積りと作業が発生します。

開発したベンダーとの関係が長期にわたるという前提になります。その会社が事業を続けられるか、担当者が変わっても対応できるかも、判断の材料になります。

開発方式の選定からご相談いただけます 違いは分かっても、自社にどちらが合うかの判断は別の問題です。 要件の整理からご一緒する30分の無料相談をご用意しています。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎

費用と期間の目安

「高い」「長い」と言われても、具体的な水準が分からないと判断できません。実際のプロジェクトデータから、規模感を確認します。

実績データから見る規模

IPA（情報処理推進機構）は、ソフトウェア開発分析データ集として、ソフトウェア開発プロジェクトの定量データを収集・公開しています。累計5,546プロジェクトのデータにもとづく統計値です。

この資料の2022年版では、プロジェクトの実績として次の数値が示されています。直近6年間のデータが対象です。

【プロジェクトの実績（中央値）】

プロジェクト全体の工期　　10.1か月

プロジェクト全体の工数　　7,395人時

月あたりの要員数　　　　　6.3人（新規開発は7.7人）

開発規模　　　　　　　　　31.8KSLOC

外部委託の工数比率　　　　63.4%

中央値で10か月、7,000人時強という水準です。1年以内のプロジェクトが約6割を占めています。5,000人時以下のプロジェクトも約4割あり、小規模な案件も相当数含まれています。

注意点として、このデータの母集団を押さえておきます。提供元はソフトウェア開発ベンダー35社で、開発ライフサイクルはウォーターフォール型が97.2%、受託開発が約9割を占めています。

期間の目安

上記のデータを踏まえると、一般的な業務システムの新規開発では、要件定義から稼働まで半年から1年程度を見込むのが現実的です。

小規模な単機能のシステムであれば3か月程度、基幹システムの全面刷新であれば2年以上というのが幅になります。自社の案件がどの規模に近いかで判断します。

期間には、発注側の意思決定の時間も含まれます。要件の確認や承認が滞ると、その分だけ全体が押します。ベンダーの見積り期間は、発注側が遅滞なく動く前提で作られています。

費用の考え方

費用は工数に単価を掛けて算出されるのが基本です。7,395人時という中央値であれば、単価を仮に1時間8,000円とすれば約6,000万円という計算になります。

ただしこれは大手ベンダーが関わる案件も含む数値です。小規模な案件であれば、数百万円から2,000万円程度という水準が現実的な範囲になります。

単価はベンダーの規模と技術者の経験で変わります。同じ要件でも見積りが倍近く違うことは珍しくありません。複数社から取る際は、工数と単価を分けて提示してもらいます。費用相場の考え方はシステム開発の外注とは｜メリット・デメリット、費用相場、外注先の種類と選び方でも整理しています。

運用保守費用を見込む

初期費用だけで判断すると、総額を見誤ります。稼働後の保守費用は、年間で初期費用の15%前後が目安とされます。

5年間使うなら、初期費用と同程度の保守費用が累積します。あわせてサーバーやクラウドの利用料も発生します。

判断は5年間の総額で行います。初期費用がパッケージより高くても、ライセンス料がない分、長期では逆転することもあります。逆に、保守費用が重く総額で不利になることもあります。

開発の進め方

工程そのものは一般的なシステム開発と同じです。ただし、発注側の関与が必要な場面が多くなります。

工程の全体像

ウォーターフォール型で進める場合の流れです。

1. 企画・構想（目的と対象範囲の整理）

2. RFP作成・ベンダー選定

3. 要件定義

4. 基本設計（外部設計）

5. 詳細設計（内部設計）

6. 実装・単体テスト

7. 結合テスト・システムテスト

8. 受入テスト

9. データ移行・リリース

10. 運用・保守

要件定義を別契約とし、その結果をもとに開発の見積りと契約を行うという進め方もあります。要件が固まる前に総額を確定させようとすると、双方にとって不利な契約になります。

発注側の作業が集中する工程

要件定義と受入テストが、発注側の負荷が最も高い工程です。ここに自社の工数を確保できるかが、プロジェクトの成否を左右します。

要件定義では、業務の現状を説明し、あるべき姿を決め、成果物をレビューして承認します。受入テストでは、業務の流れを通して検証し、合否を判断します。

この2工程の稼働を、担当者の業務量に組み込んでおきます。「通常業務の合間に」という前提では、確実に遅れます。

開発モデルの選択

スクラッチ開発では、進め方の選択肢もあります。要件が固まっているならウォーターフォール、探りながら進める必要があるなら反復型という判断です。

前述のIPAのデータでは、ウォーターフォール型が97.2%を占めています。受託開発では、成果物と金額を先に確定する必要があるためです。

上流はウォーターフォール、実装以降は機能単位で反復という折衷案も実務では取られます。全体の枠と予算を確定しつつ、細部の調整には柔軟に対応できます。

スクラッチを選ぶかどうかの判断基準

判断は4つの問いで絞り込めます。すべてに答えられれば、選択はほぼ決まります。

その業務が競争力の源泉か

最も重要な問いです。他社と違う進め方をしていることが強みになっている業務なら、スクラッチを選ぶ価値があります。

独自の価格設定ロジック、特殊な生産管理、業界固有の商流。こうした部分をパッケージの標準に合わせると、強みそのものを失うことになります。

逆に、経理、人事、勤怠のように他社と同じことをしている業務では、スクラッチの意味がありません。標準に合わせるほうが、コストも品質も有利になります。

パッケージで7割満たせるか

実務的な基準です。候補となる製品の標準機能で要件の7割以上が満たせるなら、パッケージを選びます。

残りの3割は、カスタマイズするか、業務を製品に合わせるか、運用で回避するかを検討します。この範囲であれば、パッケージの利点が失われません。

満たせるのが半分以下なら、スクラッチを検討する段階です。カスタマイズが半分を超えると、費用はスクラッチに近づき、バージョンアップも困難になります。

体制と期間が確保できるか

自社側の体制が確保できないなら、スクラッチは選ばないという判断が必要です。要件を決められる人、テストできる人、稼働後に保守を依頼できる関係。

専任者を置けない、業務を知る担当者が1人しかいない、半年後には稼働させなければならない。こうした条件では、スクラッチ開発は破綻します。

自由度より確実性を取るという選択は、後ろ向きなものではありません。自社の状況に合った方式を選ぶことが、最も合理的な判断です。

5年後まで見て判断する

初期費用だけでなく、5年間の総額と、5年後の状態で比較します。

スクラッチでは、5年後も自社で保守できているかが論点になります。パッケージでは、5年後にサポートが続いているか、バージョンアップに追随できているかが論点です。

事業の変化の速さも考慮します。5年間業務が変わらないなら、パッケージで固めるほうが安定します。変化が速いなら、拡張できる自由度に価値が出ます。

よくある失敗と対策

IPAの調査では、プロジェクトの自己評価として品質・コスト・納期のすべてに成功したとするプロジェクトが7割強という結果が示されています。つまり約3割は、いずれかを達成できていないことになります。

要件が固まらないまま進む

最も多い失敗です。要件定義の工程で決めきれなかった部分を「後で決める」として先へ進み、設計や実装の段階で仕様が確定していくという状態になります。

この進め方では、後工程で必ず手戻りが発生します。しかも契約が請負のままなら、追加費用をめぐる交渉が始まります。

対策は、要件定義の完了条件を明確にすることです。決めきれない部分があるなら、その範囲を別扱いにするか、進め方そのものを見直します。

現行踏襲で作ってしまう

「今と同じ動きにしてください」という要件です。既存システムの制約に由来する無駄な手順まで、そのまま作り込むことになります。

手作業の回避策として生まれたルール、古いシステムの制約に合わせた入力順序。これらを引き継ぐと、費用が膨らむだけで業務は改善しません。

スクラッチ開発は業務を見直す機会です。「なぜこの手順があるのか」を確認し、不要なものは落とします。この作業を省くと、高い費用で古い業務を固定化することになります。

完成後に保守できない

稼働してから気づく問題です。仕様書が残っていない、ソースコードの権利が自社にない、開発を担当した会社と連絡が取りにくい。

対策は契約段階です。納品物の範囲、ソースコードの権利、保守の条件と費用、担当者が変わった場合の対応。これらを書面で確認しておきます。

設計書を納品物に含めることは必須です。生成された画面や動くプログラムだけを受け取っても、後から自社で手を入れられません。

そもそもスクラッチである必要がなかった

最後に、根本的な失敗です。検討した結果として選んだのではなく、比較せずにスクラッチを選んでしまったというケースです。

「自社の業務は特殊だから」という前提が、実は思い込みだったという場合があります。同業他社の多くが同じパッケージを使っているなら、その前提は疑う価値があります。

必ず複数の方式で見積りを取ることをおすすめします。パッケージ、SaaS、スクラッチを並べて比較すれば、判断の根拠が残ります。稟議の説明もしやすくなります。

まとめ

スクラッチ開発は、要件に合わせてシステムを新規に設計・開発する方式です。「ゼロから作る」といっても、フレームワークやライブラリは活用します。すべてを自作するわけではありません。

メリットは業務に合わせた設計と拡張の自由度、デメリットは費用と期間、そして要件定義と保守の負荷です。自由であることの代償が、そのまま難点になっています。

規模の目安として、IPAの実績データではプロジェクト全体の工期が中央値10.1か月、工数が7,395人時という水準が示されています。判断は5年間の総額で行います。

選ぶかどうかは4つの問いで絞り込めます。その業務が競争力の源泉か、パッケージで7割満たせるか、自社の体制と期間が確保できるか、5年後にどうなっているか。

まずは候補となるパッケージ製品を1つ調べ、自社の要件の何割が標準機能で満たせるかを確認してみてください。その割合が、選ぶべき方式を最も明確に示してくれます。

システム開発の進め方から、無料で相談できます パッケージかスクラッチかで迷っている、社内に開発の知見がなく不安があるといった段階のご相談も承っています。 営業色は一切ありません。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎