スクラッチ開発とは？パッケージ開発との違いと向き不向き

基幹システムやERPの刷新では、「スクラッチ開発にするか、パッケージ導入にするか」という二択にすると、必要以上に作り込んだり、逆に重要な業務要件を見落としたりしがちです。販売・購買・在庫・会計などの中核業務に、独自の処理、既存システムとの連携、データ移行、監査や権限の要件が重なるためです。

重要なのは方式名を先に決めることではありません。この記事では、要件を分解して比較する方法を解説し、個別開発する範囲を定めるための候補構成、見積比較の条件、長期保守の確認点を整理します。読後には、どの要件を標準化・追加開発・後続導入に分けるかを判断し、同じ前提で提案を比較できるようになります。

スクラッチ開発かパッケージ導入かの二択ではなく、業務ごとに実現方式を分け、比較条件をそろえて構成を検討します。

01Sectionスクラッチ開発とは？基幹システムでは「作る範囲」で考える

スクラッチ開発とは、画面、業務処理、データ構造、権限、外部連携などを、自社の個別要件に合わせて設計・開発する方法です。一方のパッケージ導入は、既製の標準機能を中心に利用し、必要に応じて設定や追加開発を組み合わせます。ローコード開発は、プラットフォームが持つ画面・ワークフロー・データ管理・接続機能を用いて構築する方法です。

検索語として「パッケージ開発」と呼ばれることがありますが、本記事では既製パッケージを導入する方法を「パッケージ導入」と表記します。基幹システムでは、全面的に一つの方式を採るとは限りません。会計や在庫の基本処理は標準機能、独自の受注配分は個別開発、現場の申請業務はローコード開発、といった組み合わせも検討対象になります。

業務要件だけでなく、性能、可用性、運用、セキュリティなどの非機能要件も、開発範囲と見積に影響します。デジタル庁の標準ガイドライン解説書は政府情報システム向けの資料ですが、民間企業が要件を整理する際の参考枠組みとしても役立ちます。

見積書で分けて確認する開発範囲

提案書や見積書では、機能名だけでなく「何をどの方式で実現するのか」を区別します。連携・移行はどの方式でも画面や機能の開発費に埋もれやすいため、対象範囲、相手先作業、責任分担を別途確認することが重要です。

02Sectionスクラッチ開発・パッケージ導入・ローコード開発をどう比較するか

方式ごとの優劣ではなく、同じ対象業務と実現条件に対して、適合度、費目、保守責任を比較します。

方式の優劣を一律に決めるのではなく、同じ対象業務、利用規模、連携、非機能要件に対して、何が必要で、誰が保守責任を持つかを比べます。初期費用だけ、あるいは「柔軟性が高い」といった印象だけで判断しないことが大切です。

方式ではなく、構成と責任範囲を比較する

パッケージ導入では、どの種類のパッケージを候補にするかも、個別開発の範囲を左右します。分類や選定観点は、ERPパッケージの種類と選び方で補えます。

ローコード開発は中核・周辺で切り分ける

ローコード開発は、申請・承認、現場入力、部門横断の補助業務などで候補になり得ます。ただし、基幹の中核処理、大量データ処理、複雑な連携、厳しい可用性や監査要件を担わせる場合は、候補プラットフォームごとに実現性を確認します。

組織でのローコード利用には、環境、アクセス、データ接続、監視、役割分担などの統制が必要です。Power Platformのガバナンスに関する公式ドキュメントはその確認例です。ただし、これはPower Platformの公式資料であり、他のローコード製品の機能や統制仕様を示すものではありません。

03Sectionスクラッチ開発の向き不向きは、4条件で判断する

独自業務の有無だけで決めず、4条件を確認して、検証や見積の対象に残す構成を絞ります。

独自業務があることだけを理由に全面スクラッチ開発を選ぶ必要はありません。独自業務の事業価値、パッケージでの代替可否、導入期限、保守・改善体制の4条件で、個別開発する範囲を絞ります。

独自要件を競争優位・必須対応・例外運用に分ける

独自要件は、競争優位につながるもの、法令・監査・業務継続上の必須対応、現行の例外運用から生じたものに分けます。例外運用であれば、業務変更や設定で解消できる場合があり、直ちに個別開発の対象とはなりません。

優先度は、稼働初日から必要な「必須」、KPI改善に寄与するが暫定運用や後続導入の余地がある「重要」、利用頻度・影響が限定的な「後続候補」に分けると整理しやすくなります。

4条件から候補構成を残す

次の表は採用を決めるための結論ではなく、見積・検証の対象に残す構成を絞るためのマトリクスです。連携、移行、性能、可用性、セキュリティといった実現条件は、候補構成ごとに別途確認します。

KPIと非機能要件を初回対象の判断に入れる

初回稼働の範囲は、機能数ではなく、導入目的を達成するために必要な業務シナリオで決めます。たとえば受注処理の迅速化が目的なら、受注入力だけでなく、在庫引当、承認、出荷指示との関係まで確認が必要です。

あわせて、止めにくい業務を必要な時間帯に継続できるかという可用性、利用者やデータ量が増えても処理時間を保てるかという性能・拡張性、障害対応や改修を続けられるかという運用・保守性も確認します。IPAの非機能要求グレード関連情報は、これらを整理する参考資料です。アーカイブ資料であるため、現行制度や個別製品の仕様としてではなく、要件を洗い出す観点として利用します。

04Section費用・期間は相場ではなく、比較条件とTCOで見る

合計額を比較する前に前提条件をそろえ、初期費用と稼働後の継続費用を同じ期間で確認します。

基幹システムの費用や期間は、対象業務、利用者数、拠点数、既存システムからの移行、連携、非機能要件、支援範囲で大きく変わります。現在のERP・基幹システムについて、これらの条件と費目、税区分をそろえた方式別の通貨建て相場は、公開情報だけでは比較しにくい状況です。

そのため、候補構成ごとに対象業務と初回稼働範囲、利用規模、移行範囲、連携方式、性能・可用性・監査・セキュリティ、保守年数、税別・税込の区分を固定して見積を取ります。対象が異なる見積の差額は、方式の差ではなく、対象範囲や責任分担の差である可能性があります。

3年または5年のTCOで比較する

比較期間は、契約更新や更改計画に合わせて3年または5年のいずれかに統一します。TCOは、初期費用だけでなく、稼働後に必要になる費用まで含めた総保有コストです。

比較条件がそろっていない見積は、合計額だけで優劣を決めないことが重要です。

IPAの工期・工数データは提案への質問起点にする

IPA「ソフトウェア開発分析データ集2022」には、情報システム開発プロジェクト全体の公開データがあります。詳細資料では、プロジェクト全体工期はP25が6.0か月、中央値が10.1か月、P75が15.0か月（N=1,396）、総工数はP25が3,105人時、中央値が7,395人時、P75が20,446人時（N=1,444）とされています。詳細資料を確認し、提案の工期・工数に差がある場合は、対象範囲、工程、体制、移行・連携の含有範囲を質問します。

05Sectionスクラッチ開発は時代遅れなのか：長期保守のリスクで考える

スクラッチ開発が時代遅れかどうかは、方式名だけでは判断できません。独自要件への適合を得られる一方で、要件、設計、技術、保守体制を自社または委託先と継続して管理する必要があります。評価すべきなのは、「作れるか」だけではなく、「変更・障害・技術更新を含めて維持できるか」です。

管理すべきリスクを運用条件に置き換える

スクラッチ開発では、要件、設計、技術、保守体制を自社または委託先と継続して管理します。評価すべきなのは、「作れるか」だけでなく、「変更・障害・技術更新を含めて維持できるか」です。

スクラッチ開発で特に確認したいのは、次の5点です。

• 要件膨張：対象外と優先順位を定め、変更要求を記録・承認します。
• 委託先・担当者依存：設計書、ソースコード、テスト証跡、構成情報を引き継げる形で残します。
• 技術更新の停滞：採用技術、部品、更新時期、脆弱性対応の責任者を保守計画で管理します。
• 品質不足：重要業務シナリオ、例外処理、連携異常時の再処理まで、受入条件とテスト証跡を整えます。
• 運用設計不足：監視、バックアップ、復旧、問い合わせ、障害連絡、権限管理を本番前に定義します。

連携先の仕様変更に備え、連携仕様、変更通知の窓口、異常時の再送・照合方法、手作業での暫定運用をあらかじめ決めておきます。

パッケージ導入・ローコード開発にも別種の確認事項がある

パッケージ導入では、標準機能へ業務を合わせる範囲、アドオンの保守性、製品の更新方針やロードマップへの依存を確認します。パッケージを使うことで保守の検討が不要になるわけではありません。

ローコード開発では、環境管理、作成者・利用者の権限、データ接続、監視、変更・配布の統制が継続課題になります。どの方式でも、責任分担、変更手順、運用証跡を残せるかが長期利用の条件です。

06Section外部へ依頼する場合の見積・契約・検収の確認点

外部へ依頼する場合は、依頼前整理、要件定義、設計、開発・テスト、移行・受入、本番移行・安定化の順に、発注側の確認を進めます。見積額の差を比較する前に、対象・対象外、前提、成果物、受入条件がそろっているかを確認してください。

IPA「情報システム・モデル取引・契約書」は、受託開発だけでなく、保守運用、パッケージ、SaaS/ASP活用を含む取引で、役割分担、成果物、変更、保守条件を確認するための資料です。個別契約の結論を示すものではありませんが、発注条件を整理する参考になります。

依頼前から安定化までに確認すること

07Sectionまとめ：個別開発する範囲と比較条件を先に決める

スクラッチ開発を選ぶかどうかではなく、基幹システムのどこまでを標準機能、設定、アドオン、個別開発、ローコード、連携・移行で実現するかを決めることが出発点です。

次の作業は、独自要件を目的・影響・代替可否・初回必要性・保守責任者まで棚卸しすることです。その後、独自業務の事業価値、パッケージでの代替可否、導入期限、保守・改善体制の4条件で候補構成を残します。最後に、対象範囲、移行、連携、非機能要件、税区分をそろえ、3年または5年のTCOと保守体制を比較します。

よくある質問

要件整理や候補比較を外部と進める場合

社内で要件を整理したうえで、ERP導入や個別開発を含む候補構成の比較を外部と進める場合は、対象業務、連携、移行、保守範囲を共有できるパートナーを検討します。

ERP導入564社掲載

ERP導入の支援会社を探す