スクラッチ開発とは—パッケージ・SaaSとの違いと、発注前に確かめる4つのこと

「スクラッチ開発」で調べる方の多くは、既製のツールを見て回ったものの自社のやり方が乗り切らず、作る選択肢が視野に入ってきた段階だと思います。あるいは、ベンダーから「スクラッチで作りましょう」という提案を受けて、それが妥当なのか判断したい段階かもしれません。

作る話は、決めた瞬間より、決めた後のほうが長く続きます。ここでは、その長い側に何が待っているのかを、公開されている実績データと制度の規定で確かめられる範囲だけ書きます。金額の相場については、一次情報で裏が取れなかったので書いていません。代わりに、提示された見積もりを自分で検算する方法を置きました。

スクラッチ開発とは何か

既製のパッケージソフトやSaaSを使わず、自社の要件に合わせてソフトウェアをゼロから設計・製作する進め方のことです。英語の「from scratch（最初から）」が語源で、「フルスクラッチ」もほぼ同じ意味で使われます。

紛らわしいのは「カスタマイズ」との境目です。既製品を土台にして設定や追加開発で自社仕様に寄せるのはカスタマイズやアドオン開発で、土台そのものを持たないのがスクラッチ開発です。実務では、基幹の一部だけをスクラッチで作り、周辺はSaaSでつなぐ形も普通にあります。全部か既製品かの二択で考える必要はありません。

もうひとつ、発注の場面で効いてくる違いがあります。既製品は「動くものを見てから買う」のに対し、スクラッチは「仕様を決めてから作り始める」ことです。この順番の違いが、後に出てくる工期・契約・補助金の扱いすべてに影響します。

パッケージ・SaaS・ローコードと何が違うのか

違いは機能の多さではなく、「どこまで自分で決められるか」と「どこまで自分で持ち続けるか」の組み合わせです。決められる範囲が広いほど、持ち続ける範囲も広くなります。

ローコード・ノーコードのツールは、この表の中間に位置します。決められる範囲はパッケージより広い一方、作ったものを動かし続ける責任はスクラッチ側に近づきます。判断の軸は同じで、「決める作業を自社が引き受けられるか」に集約されます。

どれくらいの期間と人手がかかるのか

ここは体感で語られやすいところですが、公開されている実績データがあります。IPA（情報処理推進機構）の「ソフトウェア開発分析データ集2022」は、開発ベンダ各社から提供された累計5,546プロジェクトの定量データをまとめたものです。主な値は次のとおりです。

同資料では、工期について「1年以内のプロジェクトは、およそ6割を占める」と記載されています。裏を返すと、4割は1年を超えています。また月あたりの要員数は、新規開発の中央値7.7人に対してパッケージ利用開発は3.8人と、倍近い差があります。ゼロから作るというのは、同じ期間により多くの人が関わり続けるということです。

注意点として、このデータは開発ベンダ各社が提供した実績で、中小企業が発注する小規模な案件はこの分布の左側（短い・小さい側）に寄ります。そのまま自社の見積もりに当てはめる数字ではありません。使い方としては、提示された工期・工数が分布のどのあたりにあるかを確かめ、外れているなら理由を聞く、という当て方が現実的です。

「作る」工程は全体の3割ほどで、残りは設計とテスト

同資料には、新規開発について工程別の工数比率も載っています（表A3-3-8、N=270、開発5工程がそろったプロジェクトが対象）。中央値で見ると、基本設計0.165・詳細設計0.157・製作0.316・結合テスト0.201・総合テスト0.119です（それぞれ独立に求めた中央値なので、合計は1になりません）。

つまり、プログラムを書く「製作」工程はおよそ3割で、設計に3割強、テストに3割強が使われています。発注側から見えやすいのは製作の部分ですが、費用の大半はその前後にあります。「作るだけなら早いはずだ」という感覚と、実際の工数配分はここでずれます。見積もりの内訳で設計とテストの工数が極端に薄いときは、後工程で追加になるか、品質側で吸収されている可能性を疑ったほうがいいところです。

見積書の検算のしかた

金額の相場は、一次情報で裏付けられなかったのでこの記事には書きません。代わりに、手元の見積書だけでできる確認を挙げます。

1. 提示された人月単価を、月間の想定稼働時間で割って人時単価に直す
2. 総額 ÷ 人時単価 で、この見積もりが前提にしている工数（人時）を出す
3. その工数を工程別に割ってみて、設計・製作・テストの比率が上の数字から大きく外れていないかを見る
4. 工期（月数）と工数から、月あたり何人が張り付く前提かを逆算し、そのメンバーが実際に確保されているかを聞く

4番目でつまずくことが多いです。工数は積まれているのに要員計画が示されない場合、期間内に終わらせる根拠が見えません。ベンダー提案そのものの見方はシステム見積もりのセカンドオピニオンに別途まとめています。

費用は作った後にも続く—会計上の扱いと保守

スクラッチ開発でSaaSと決定的に違うのが、支払いのタイミングと会計上の扱いです。国税庁のタックスアンサーNo.5461では、ソフトウェアの耐用年数は「複写して販売するための原本」と「研究開発用のもの」が3年、その他（自社で利用するものを含む）が5年とされています。

自社製作の場合の取得価額は、製作に要した原材料費・労務費・経費の額に、事業の用に供するために直接要した費用を加えたものです。同ページでは、製作計画の変更で不要になった仕損じ費用や、製作原価のおおむね3%以内の間接費・付随費用は取得価額に含めないことができるとされています。

実務的に何が起きるかというと、SaaSの利用料はその期の費用になるのに対し、作ったシステムは5年かけて費用になります。資金の出方と損益への出方がずれるので、支払いの計画と決算の見え方を分けて考える必要があります。ここは顧問税理士に、開発着手前の段階で相談しておくと後がスムーズです。

加えて、リリース後の保守があります。OSやブラウザの更新、法改正、業務の変化に合わせた手直しは、既製品なら提供元の更新で入ってくるものが、スクラッチでは自社の費用として都度出ます。開発費とは別に、この継続費用を最初から予算に置いていないと、数年後に「動いてはいるが誰も直せない」状態になりがちです。

スクラッチ開発は補助金の対象になるのか

結論として、デジタル化・AI導入補助金2026（従来のIT導入補助金にあたる制度）では対象外です。事務局が公開している「ITツール登録マニュアル」の対象・対象外早見表（13ページ）に、対象とならないものとして次の項目が並んでいます。

• ITツールの登録申請時点において、製品が完成しておらず、一般的に販売されていないもの
• 製品が完成しておらず、スクラッチ開発を伴うソフトウェア。過去に特定顧客向けに開発したコード（開発実績）を他の顧客に再利用し、その顧客の要件に合わせ追加スクラッチ開発を伴うもの
• 特定の顧客向けに限定され、一般市場に販売されていないもの

この制度は、事務局に事前登録された既製のITツールを導入する費用を対象にした仕組みなので、個別開発は制度設計上その外にあります。「補助金が使えるらしいので作りたい」という前提で話が進んでいる場合は、ここを最初に確かめたほうがいいところです。なお対象外の経費を含んだ形で交付を受けた場合は返還の対象になる、とも案内されています。

他制度（ものづくり補助金など）については公募回ごとに要件が変わるため、この記事では断定しません。使えるかどうかは、その回の公募要領で「対象経費」の定義を直接読んで判断してください。

契約は請負か準委任か

スクラッチ開発は「仕様を決めてから作る」ので、契約時点では成果物の形が決まっていません。ここを1本の請負契約でまとめようとすると、要件が動くたびに揉めます。

IPAと経済産業省が公開している「情報システム・モデル取引・契約書」第二版（2020年12月22日公開）は、この点を工程ごとに分けて整理したひな型です。要件定義のように、何を作るかを一緒に決めていく工程と、決まったものを完成させる工程とで、契約の型を分ける考え方が示されています。ひな型のWordファイルが無償で公開されているので、ベンダーから提示された契約書と読み比べるだけでも、抜けている条項が見えます。

第二版では、2020年4月施行の改正民法への対応も反映されています。従来の「瑕疵担保責任」が「契約不適合責任」に改められ、報酬減額請求権が加わった点、権利行使の期間制限、プロジェクトマネジメント義務や複数契約の関係の明確化などが見直しの論点として挙げられています。契約書に「瑕疵担保」という語が残っているようなら、いつ作られたひな型なのかを確認する材料になります。

発注側として最低限見ておきたいのは、①どの工程がどちらの契約類型か、②検収の基準は何をもって合格とするか、③完成後に不具合が見つかった場合の期間と手当て、④作ったものの著作権がどちらに帰属するか、の4点です。特に④は、後で別のベンダーに引き継ぐときに効いてきます。

スクラッチを選んでよい場合と、やめたほうがいい場合

ほとんどの業務は既製品で足ります。会計、勤怠、経費精算、名刺管理のように、どの会社でもやり方がだいたい同じ領域で、わざわざ作る理由は基本的にありません。

作る側の検討に入る価値があるのは、次のような場合です。

• 既製品を実際に使ってみたうえで、合わない部分を「この画面のこの項目が持てない」というレベルで具体的に言える
• その合わない部分を、毎月まとまった時間をかけて人が手作業で吸収している
• そのやり方が、他社と同じにしてしまうと競争力が落ちる部分と重なっている
• リリース後に直し続ける体制と費用を、数年単位で置けている

逆に、やめたほうがいい兆候もはっきりしています。合わない理由を業務名（「うちの受注管理は特殊なので」）でしか言えない段階、現場の運用がまだ人によってばらついている段階、そして「補助金が出るうちに」「今期の予算があるうちに」という時期の都合が先に来ている段階です。この状態で着手すると、決めきれないまま設計工程が伸び、工数の3割強を占める設計の部分がそのまま膨らみます。

当社でも、医療・美容分野の医療法人向けに勤怠システムを開発した事例があります。この案件では、既製の勤怠ツールをすでに導入していたものの、自社独自の勤怠ルールを製品側で表現できず、管理したい情報も項目として持てない状態が続いていました。作る判断の前に、既製品で試して、どこが乗らないかを言葉にする段階を通っています。他の事例は導入事例のページに置いています。

なお、外注と内製のどちらで進めるかは、作るかどうかとは別の判断です。そちらは業務改善は外注すべき？内製すべき？に整理しています。IPAの同データ集では、開発プロジェクトにおける外部委託の工数比率は中央値63.4%（N=562）で、作る側の現場でも相当部分が外部に出ている実態が示されています。

発注前に確かめる4つのこと

ここまでを、発注前のチェックとして4つにまとめます。

1. 期間と要員：提示された工期と工数から、月あたり何人が張り付く前提かを逆算する。その人たちが確保されているかを聞く。IPAの実績では新規開発の月あたり要員は中央値7.7人で、1年以内に終わるプロジェクトはおよそ6割
2. 工数の配分：見積もりの内訳で、設計とテストの工数が薄すぎないかを見る。新規開発の実績では、製作は全体の約3割で、残りは設計とテスト
3. 作った後の負担：自社利用のソフトウェアは耐用年数5年で償却する。開発費とは別に、法改正やOS更新に伴う保守の費用を数年分置けているか
4. 制度と契約：デジタル化・AI導入補助金2026ではスクラッチ開発は対象外。契約は工程ごとに型を分け、検収基準・契約不適合責任・著作権の帰属を確認する

4つとも、着手前なら数日で確かめられるものです。着手後に確かめようとすると、どれも交渉ごとになります。

まとめ

スクラッチ開発は、既製品を使わず自社の要件に合わせてゼロから作る進め方です。決められる範囲が広い代わりに、決める作業と持ち続ける責任が自社に残ります。

判断に効く数字は、金額よりも配分のほうです。IPAの実績データでは、新規開発で製作工程が占める工数はおよそ3割で、残りは設計とテスト。月あたりの要員は新規開発の中央値で7.7人、パッケージ利用開発の3.8人と倍近い差があります。作るというのは、書く時間より決める時間とテストする時間を買う判断に近い、というのがこの数字の読み方です。

そのうえで、自社利用のソフトウェアは耐用年数5年で償却が続き、デジタル化・AI導入補助金2026の対象からは外れ、契約は工程ごとに型を分ける必要がある。この3つを織り込んでもなお作る理由が残るなら、その業務はおそらく本当に自社固有の部分です。まずは既製品を試して、乗らない部分を言葉にするところから始めるのをおすすめします。