スクラッチ開発とは

スクラッチ開発とは

業務パッケージやSaaS（Software as a Service）のような既製の製品を前提にせず、自社の業務の要件を起点にシステムの設計から開発までを行う形です。
画面、データの構造、業務のルールをすべて自社向けに決定できます。

開発は開発会社に依頼する場合も、社内の技術者が担う場合もあります。

フルスクラッチと呼ぶこともありますが、プログラムを1行目から全部書くという意味ではありません。
現在の開発ではオープンソースのフレームワークやライブラリ、クラウドが提供するデータベースや認証の機能を併用するのが一般的です。
自社向けに開発するのはその上に構築する業務のルール、画面、データの構造です。

発注側は見積もりの前提として、どの既製の機能を利用し、どこを自社向けに開発するかを開発会社に確認します。

製品に適合させると強みを喪失する業務

パッケージやSaaSは多くの会社に共通する業務の進め方を前提に設計されています。
自社の業務がその前提に一致しない場合、業務を製品に適合させるか、製品を追加の開発で拡張することになります。
顧客に提供するサービスそのものや、独自の料金計算や配送の割り当てのように他社との差になっている業務は、製品に適合させると強みを喪失します。
追加の開発で拡張した部分は製品の更新のたびに改修と再テストが発生します。
スクラッチ開発はこの差を自社の側で維持するための手段です。

効果

• 業務のやり方を変更せずシステムへ反映できる。他社との差になっている手順やルールをそのまま実現できる
• 機能の追加や変更の順番と時期を自社で決定できる。製品の更新計画に左右されない
• 本体のライセンス料は利用者数に応じて増加しない。ただし併用するクラウドの機能やインフラの費用は利用量に応じて増加する
• 他のシステムとの接続やデータの構造を自由に設計できる

コストとリスク

• 初期費用が高額で、期間も長期になる。要件の整理、設計、テストをすべて自社向けに行う
• 稼働後も保守と改修の費用が毎年続く。法令改正やセキュリティの更新への対応も自社の負担になる
• 仕様を決定する社内の担当と保守を担う技術者が稼働後も必要で、担当が異動・退職すると中身を理解する人がいなくなる
• 要件が確定しないまま開発を開始すると、手戻りで費用と期間が膨張する
• 開発した会社しか中身を理解できない状態になると、保守の依頼先を変更できなくなる

保守の依頼先を変更できなくなるリスクはソースコードの権利と設計書の引き渡しを契約で定めるだけでは解消しません。
権利は切り替えの前提です。
そのうえで設計書を最新の状態に維持する取り決めと、仕様を説明できる社内の担当が必要です。

スクラッチ開発か製品の利用かの判断

スクラッチ開発を採用してよい業務

スクラッチ開発を採用してよいのは、対象の業務が他社との差の源泉で、その差をパッケージやSaaSの設定と追加の開発で解消できないときだけです。
会計、給与、勤怠、経費精算のように法令や商慣行で進め方がほぼ定型化している業務は、製品を利用して業務を製品に適合させるほうが安全です。
情報処理推進機構のDX白書2023の第3部も同じ立場で、競争領域に該当しない業務は標準化してパッケージやSaaSを活用することでIT投資を削減できるとしています。
同じ白書はパッケージへの多数のカスタマイズを非効率な投資の例として指摘しています。

採否を決定する3つの確認事項

判断には次の3点を確認します。

• 業務の差が売上や顧客の選択に直結しているか。社内の慣習や帳票の形式の違いだけなら、業務を製品に適合させる
• パッケージの見積もりで、追加開発の費用が製品本体と導入の費用を上回っていないか。上回るときは同じ範囲をスクラッチで開発した場合の見積もりも取得する
• 5年以上利用を継続し、仕様の変更が年に何度も発生するか。数年で再構築する試行や、変更がほぼない業務なら製品を利用する

製品と自社開発の組み合わせ

1つのシステムの中でも、標準的な部分は製品を利用し、差になる部分だけを自社向けに開発する組み合わせが現実的です。
たとえば顧客向けの予約や見積もりの画面はスクラッチで開発し、請求と会計はSaaSに連携させます。
画面と簡単な処理だけで十分な部分は、ローコードの開発基盤の上で構築する中間の選択肢もあります。
ローコードはコードの記述を最小限にし、画面や処理の大半を設定で実現する開発の形です。

初期費用でなく5年間の総額で比較する

スクラッチ開発とパッケージを比較するときは、初期費用でなく、稼働後5年程度の保守と改修まで含めた総額で比較します。

稼働後5年間の費用の倍率

日本情報システム・ユーザー協会（JUAS）のソフトウェアメトリックス調査2020では、スクラッチ開発に該当する自社開発のシステムの保守費は年に初期開発費の1割弱です。
稼働後の追加開発を含めると年に2割程度で、開発から5年間の総額は初期開発費の約2倍になっています。
同じ調査でのパッケージの倍率は、製品本体の部分が5年間で導入時の約1.5倍、カスタマイズの部分が約2.6倍です。
既製品でもカスタマイズした部分は稼働後に毎年その初期費用の3割前後が発生し、5年間の倍率はスクラッチ開発を上回ります。

初期費用と人材の目安

総額の起点になる初期費用の目安は、部署単位の業務システムをスクラッチ開発する場合に数百万円から数千万円規模、基幹システムでは数億円規模です。

人材の費用も総額に含めます。
稼働後も仕様を決定できる社内の担当が少なくとも1人必要です。
保守の技術者は部署単位のシステムなら外部の保守会社の兼任で十分ですが、基幹システムでは専任の数人が必要です。

規模	初期費用の目安	保守の技術者
部署単位の業務システム	数百万円から数千万円規模	外部の保守会社の兼任
基幹システム	数億円規模	専任の数人

保守の技術者を確保できるかは、採否を決定する前に確認します。
JUASの企業IT動向調査2026でも、システム開発の品質や納期が悪化した要因として、社員とベンダーの双方のスキル不足と人材確保の困難さが指摘されています。
スクラッチ開発では稼働後の改修も自社で手配した技術者が担います。
保守を担う人を確保できる見通しがないなら、業務の差があっても製品の利用を優先するほうが安全です。

よくある誤解

スクラッチで開発すれば稼働後の保守や改修の費用はほとんどかからない

製品の利用料はかかりませんが、保守費、インフラ費、改修の費用が使い続ける限り発生します。
フレームワークやクラウドの機能は他社と共通のものを利用するため、それらの更新に追随する作業も毎年発生します。
これらの更新を放置すると数年後にシステムの大規模な改修か再構築が必要になります。