スクラッチ開発とは｜基幹システムをフルスクラッチで作る条件と費用・期間

スクラッチ開発とは、既製のパッケージを使わず、自社の業務に合わせてシステムを一から設計・開発する作り方です。中小企業の基幹システムでフルスクラッチが合理的になるのは、「他社と違うやり方そのものが利益の源泉」で、かつ「作った後も直し続ける体制がある」場合に限られます。この記事では、パッケージとの違い、フルスクラッチを選んでよい条件の判定表、費用と期間の見積もり方を、大手コンサルティングファーム出身の専門家の知見をもとに整理します。

スクラッチ開発とは：パッケージとの違いは「業務とシステムのどちらを合わせるか」

スクラッチ開発は、画面・帳票・計算ロジック・データベースまで、自社専用に設計して作る方法です。既存の部品やフレームワークは使いますが、業務の仕組みそのものは自社の要件から組み立てます。土台となる製品を持たない作り方を、特にフルスクラッチと呼びます。

パッケージ（ERPや販売管理ソフト）との違いは、出発点です。パッケージは「製品が想定する標準の業務」が先にあり、自社の業務をそこに寄せていきます。スクラッチは「自社の業務」が先にあり、システムをそれに合わせて作ります。

• パッケージ：業務をシステムに合わせる。合わない部分はアドオン（追加開発）か運用で吸収する
• スクラッチ：システムを業務に合わせる。合わない部分は原則として出ない代わりに、すべてを自分で作り、自分で直し続ける

この「直し続ける」が見落とされがちです。パッケージなら製品側が担う税制改正や法令対応、OS・ミドルウェアの更新への追従も、スクラッチでは自社（と委託先）の仕事になります。パッケージ側の考え方はERPパッケージとはで詳しく解説しています。

経済産業省が2025年5月に公表した「レガシーシステムモダン化委員会総括レポート」は、標準化の方針として「経営資源の制約の大きい中堅・中小企業は、オーダーメイドのスクラッチ開発は避け、パッケージやSaaSを原則とすべき」と書いています。同レポートは、仕様のブラックボックス化や現行踏襲へのこだわりが刷新の足かせになっている状況を、アンケート結果とともに示しています。ただし「原則」であって禁止ではありません。例外にあたるかどうかを、次の節以降の表で判定します。

スクラッチ・パッケージ・SaaS・ローコードの違い

基幹システムの作り方は、実務上は4つに分かれます。「スクラッチかパッケージか」の二択で考えると、中間の選択肢を見落とします。

ローコードで基幹業務をどこまで担えるかはローコード・kintoneで基幹システムは作れるか、パッケージの追加開発の判断はERPのアドオンとはを参照してください。

表を見ると、スクラッチの利点は「業務に合わせられる」一点に集約され、ほかの行はすべて負担側に並ぶことがわかります。だからこそ、その一点が本当に利益につながるのかを、感覚ではなく条件で確かめる必要があります。

なお、「セミスクラッチ」という言葉もよく使われます。開発会社が持つ雛形や自社製の部品を土台に、残りを個別に作る方法です。一から作るより早く安くなる一方、土台の部分はその会社の持ち物であることが多く、委託先を替えにくくなります。見積書に「セミスクラッチ」とあったら、土台部分の権利と、他社が保守を引き継げるかを確認してください。

フルスクラッチを選んでよい5つの条件（判定表）

次の5条件のうち、1と2の両方に当てはまり、さらに3〜5のうち2つ以上を満たすなら、スクラッチを本格的に検討する価値があります。1か2が欠けるなら、パッケージやSaaSを軸にして、独自部分だけを周辺に作る形を先に検討します。

※判定の目安です。条件2の確認では、候補製品の標準機能を実際の業務データで試す（デモでなく自社の取引で確認する）ことを前提にしてください。

条件1の判定で多い誤りは、「今のやり方に慣れている」を「独自性」と取り違えることです。たとえば「当社は取引先ごとに請求書の形式が違う」は独自性ではありません。多くの会社が抱える事情で、パッケージの帳票設定や運用ルールの見直しで解決できることがほとんどです。一方、「受注時に過去の加工実績から原価を自動で見積もり、即日回答する仕組みで受注を取っている」なら、利益の源泉に直結しています。

条件2では、検討する製品を1つに絞らないことが肝心です。1製品で合わないことは、スクラッチを選ぶ理由になりません。業務を製品に合わせる考え方はFit to Standardとはで解説しています。

判定表の記入例

判定表は、経営者と業務責任者が同じ紙に書き込むと議論が早く進みます。次は記入の例です。

スクラッチ開発の費用の考え方：初期より「作った後」が重い

スクラッチの費用は、開発会社の見積書に載る初期費用だけを見ると判断を誤ります。費用は、発生のタイミングで3つに分けて並べます。

法改正対応の負担は、具体例で考えると実感できます。2023年10月1日に始まったインボイス制度（適格請求書等保存方式）では、請求書に登録番号、税率ごとに区分した対価の額と適用税率、税率ごとの消費税額等を記載する必要が生じました（国税庁「No.6625 適格請求書等の記載事項」）。また、2024年1月からは電子取引データを電子のまま保存し、検索できる状態にしておくことが求められています（国税庁「令和6年1月からの電子取引データの保存方法」）。パッケージやSaaSなら製品の更新で対応するところを、スクラッチでは請求書発行・会計連携・保存の各機能を自社で改修します。

作り方ごとの費用の全体像はERP・基幹システムの費用で整理しています。見積書を受け取ったら、上の費目のうちどれが含まれ、どれが別見積かを1行ずつ確かめてください。

人月で考える5年総費用の試算例

スクラッチの見積もりは「人月（1人が1か月働く作業量）」で出てきます。金額ではなく人月のまま比べると、作り方の違いが見えやすくなります。

スクラッチ開発の期間の目安：工期は工数の立方根の約2.5倍

期間の見積もりには、日本情報システム・ユーザー協会（JUAS）の「ソフトウェアメトリックス調査」が示している経験則が使えます。同調査（2014年版）は、工期（月）はおおむね投入工数（人月）の立方根の約2.5倍という関係を示し、1,000人月のプロジェクトなら約25か月という例を挙げています。

※規模のイメージは説明用の例です。計算式はJUAS調査の経験則で、個別の案件の工期を保証するものではありません。なお同調査の2020年版では、係数は2.70倍（n=892）とされています。版によって係数は少し変わるため、目安として使ってください。

この表から読み取れるのは、人を増やしても工期は比例して縮まないことです。64人月の仕事を5か月で終えたいと言っても、目安の半分の期間です。無理に縮めると、設計の確認やテストが削られます。同じ資料のクロス集計では、要求仕様が「非常に明確」だった案件の83.7%が予定より早いか予定どおりに終わったのに対し、「非常にあいまい」だった案件では50.0%にとどまっています。工期を守る手段は、人を足すことより要件を早く固めることです。

注意したいのは、この計算に構想策定や製品比較の期間は入らないことです。スクラッチを選ぶ前の検討と、稼働後に運用が落ち着くまでの安定化期間を前後に足して、経営の計画に載せます。この前後の期間を省いた計画は、遅れたときの吸収余地がありません。

スクラッチ開発で起きやすい4つの失敗

スクラッチの失敗は、開発中よりも稼働して数年たってから表面化するものが多くあります。代表的なものを4つ挙げます。

1. ブラックボックス化：作った人しか直せない

設計書が更新されないまま改修が重なると、仕様を知る人が限られます。経済産業省の2018年の「DXレポート」は、既存システムの複雑化・ブラックボックス化を「2025年の崖」の原因として挙げました。2025年の総括レポートでも、システムの可視化と内製化が提言の柱になっています。スクラッチを選ぶなら、設計書を改修のたびに更新する作業を保守契約の範囲に入れておきます。

2. 現行踏襲：今の画面をそのまま作り直す

「今のシステムと同じように動けばよい」という要件は、スクラッチで特に起きやすい問題です。業務を見直さずに古い仕組みを再現すると、使われていない機能や、例外処理のための回り道まで新しく作ることになります。総括レポートも、現行踏襲にこだわらず業務を見直すことを求めています。

3. 範囲の膨張：「せっかく作るなら」が止まらない

パッケージなら「標準にない」ことが歯止めになりますが、スクラッチでは要望がそのまま開発範囲に入ります。要件ごとに「必須／あれば／後回し」の優先度をつけ、後回しの要望は稼働後の改修計画に回すルールを、要件定義の初回に決めておきます。後回しにした要望は一覧に残し、稼働半年後に改めて要否を判断します。

4. テスト不足：受入テストを開発会社に任せる

スクラッチでは、パッケージのように「多くの会社で使われて確かめられた部分」がありません。すべての機能が初めて動くものです。開発会社のテストは仕様どおりに動くかを確かめるもので、締め日の処理、返品・赤伝、月末の在庫評価といった業務の流れで正しく動くかは、発注側が受入テストで確かめるしかありません。月次の締めを少なくとも1回、本番と同じデータで通す計画を立てておきます。

契約と体制で決めておくこと：請負・準委任とソースコードの扱い

スクラッチ開発は、パッケージ導入よりも契約の決め方が結果を左右します。IPAが公開している「情報システム・モデル取引・契約書（第二版）」（2020年12月）は、経済産業省のモデル契約（2007年）などを見直したもので、セキュリティ、プロジェクトマネジメント義務と協力義務、複数契約の関係、再構築への対応などを見直しの柱にしています。現行システムを作り直す案件では、旧システムの仕様をどちらが調べるかで揉めやすいため、再構築の扱いは特に確認します。

• 要件定義：決める内容がまだ固まっていないため、作業の遂行に対価を払う準委任で組むことが多い工程です。成果物（要件定義書・業務フロー）と、発注側が担う判断の範囲を確認します。
• 設計・開発・テスト：完成物を定義できるため、請負で組むことが多い工程です。受入基準、検収の方法、契約不適合の扱いを確認します。
• 移行・稼働支援：作業の量が読みにくく、準委任で組むことが多い工程です。旧システムのデータ抽出をどちらが担うかを決めておきます。
• 保守：月額の準委任が一般的です。保守に含む作業と含まない作業（機能追加・法改正対応）を線引きします。

スクラッチ固有の確認事項は、ソースコードと設計書を誰が持つかです。著作権の帰属、ソースコード・設計書・テスト結果の引渡し、第三者への保守の委託を認めるかを、契約書に書いておきます。これが曖昧だと、委託先を替えたくても替えられない状態になります。原因と防ぎ方はベンダーロックインとはで詳しく解説しています。

現実的な選択肢：パッケージ＋独自部分だけをスクラッチ

判定表で条件1を満たしても、全体をスクラッチにする必要はありません。会計・給与・購買のような標準化しやすい業務はパッケージやSaaSに任せ、利益の源泉になっている業務だけを独自に作り、データ連携でつなぐ形が、中小企業では現実的です。

この形にすると、スクラッチ部分の規模が小さくなり、前節の早見表で見たように工期も短くなります。連携の設計（どのデータを、どの頻度で、どちらが正とするか）は、要件定義で最初に決めておきます。

契約前の10のチェックポイント

• スクラッチで作る範囲が「利益の源泉になる業務」に絞られている
• 候補となる製品を3つ以上、自社の取引データで試した記録がある
• 5年分の費用を「初期・毎年・数年に一度」に分けて比べている
• 工期が工数に対して短すぎない（立方根の約2.5倍が目安）
• 要件ごとに「必須／あれば／後回し」の優先度がついている
• 著作権の帰属と、ソースコード・設計書の引渡しが契約書にある
• 保守契約に、設計書の更新と法改正対応の扱いが書かれている
• 使う開発言語・データベースのサポート期間を確認している
• 稼働後に改修を判断する社内の担当者が決まっている
• 委託先が替わっても保守を引き継げる資料がそろう計画になっている

よくある質問

まとめ

スクラッチ開発は、システムを業務に合わせられる代わりに、法改正対応や基盤の更新まで自社で引き受ける作り方です。中小企業の基幹システムでフルスクラッチを選んでよいのは、独自の業務が利益を生み、標準製品では再現できず、稼働後も直し続ける体制がある場合です。多くの会社では、標準化できる業務はパッケージやSaaSに任せ、差別化している部分だけを作る組み合わせが現実的な答えになります。費用は5年分を人月で並べ、工期は工数の立方根の約2.5倍を目安に、無理のない計画を立ててください。

自社の業務のどこが「標準でよい部分」で、どこが「作る価値のある部分」かを整理したい方は、無料診断で現状の課題と作り方の方向性を確認できます。