基幹システムのスクラッチ開発とは｜要件定義・費用・期間・発注方式まで解説

導入 — 「パッケージでは足りない」と感じたときに選択肢に上がるスクラッチ開発

市場環境の変化が速まる中、既存のERPパッケージに限界を感じる企業が増えています。業務プロセスが複雑化・多様化するにつれ、「標準機能では自社の運用に合わない」「カスタマイズを重ねるほど保守コストが膨らむ」といった不満が現場から上がるケースは少なくありません。

こうした背景から、自社の業務要件に合わせてシステムをゼロから構築する基幹システムのスクラッチ開発（独自開発）が、改めて選択肢として注目されています。かつては大企業に限られた手法という印象がありましたが、開発手法の成熟やクラウドインフラの普及により、中堅企業でも現実的な選択肢になりつつあります。

ただし、スクラッチ開発はパッケージ導入と比べて自由度が高い反面、費用・期間・体制の面で検討すべき論点が多岐にわたります。判断を誤ると、開発の長期化やコスト超過につながるリスクもあります。

本記事では、基幹システムのスクラッチ開発を検討している情報システム担当者・経営者を対象に、以下の論点を順を追って解説します。

• スクラッチ開発の定義と「フルスクラッチ」との違い
• ERPパッケージとの比較・向き不向きの判断基準
• 費用相場と開発期間の目安
• 成否を左右する要件定義の進め方
• 請負・準委任・ラボ型など発注方式の選び方

それぞれの論点を整理することで、自社にとって最適な判断ができるよう、具体的な情報をお届けします。

基幹システムのスクラッチ開発とは — 定義と「フルスクラッチ」との違い

スクラッチ開発・フルスクラッチの定義

基幹システムのスクラッチ開発とは、既存のパッケージ製品やフレームワークを前提とせず、自社の業務要件をもとにシステムをゼロから設計・構築する開発手法です。「フルスクラッチ」とも呼ばれますが、両者に定義上の明確な差異はなく、同義として使われるケースがほとんどです。

起点となるのは「製品の仕様」ではなく、あくまで「自社の業務フロー」です。データ構造・画面設計・処理ロジックのすべてを独自に定義するため、業種特有の商習慣や複雑な承認フローにも対応できます。

セミオーダー型・パッケージカスタマイズとの違い — 開発起点が「製品」か「業務」か

スクラッチ開発と混同されやすい手法として、パッケージカスタマイズとセミオーダー型があります。両者の違いを整理すると以下のとおりです。

• パッケージカスタマイズ：ERPなどの製品をベースに、設定変更やアドオン追加で自社仕様に近づける手法。開発起点は製品側にあります。
• セミオーダー型：標準機能を土台としつつ、一部モジュールを個別開発する折衷案。カスタマイズ範囲に上限があるケースが少なくありません。
• スクラッチ開発：業務要件を起点に設計するため、製品仕様による制約を受けません。

どの手法が適切かは、業務の独自性・将来的な拡張性・コストのバランスによって変わります。次のセクションでは、ERPパッケージとスクラッチ開発を複数の軸で比較します。

ERPパッケージとスクラッチ開発の比較 — どちらを選ぶべきか

スクラッチ開発を検討する前に、まずERPパッケージとの比較を整理しておくことが重要です。両者の違いを一言で表すとすれば、「業務をシステムに合わせるか、システムを業務に合わせるか」という意思決定の軸に集約されます。

ERP vs スクラッチ開発 — 5軸比較表

スクラッチ開発が向いている企業・業務の特徴

以下のような条件に当てはまる場合、スクラッチ開発の優位性が高まります。

• 業界特有の商慣習や業務フローがあり、標準パッケージでは対応できない
• 他システムとの連携が複雑で、ERPのアドオン対応だけでは限界がある
• 業務プロセス自体が競争優位の源泉であり、標準化による制約を避けたい

パッケージ導入が向いている企業・業務の特徴

一方で、次のような状況ではERPパッケージの導入が現実的な選択肢になります。

• 業務プロセスが業界標準に近く、大きなカスタマイズを必要としない
• 導入期間・コストを抑えて早期に運用を開始したい
• 社内に開発・保守を継続的に管理できる体制がない

どちらが優れているという話ではなく、自社の業務特性・組織体制・中長期の拡張計画に照らし合わせて判断することが重要です。「パッケージに業務を合わせることで生産性が上がるケース」も多くあり、スクラッチ開発はあくまでパッケージでは対応しきれない場合の選択肢として位置づけるのが適切です。

スクラッチ開発の費用相場 — 規模・機能・体制で変わる目安

基幹システムのフルスクラッチ費用は「数百万〜数億円」と紹介されることが多いですが、この幅では発注側の意思決定に使えません。費用を左右する要素を分解し、規模感ごとの目安を整理します。

費用の構成要素 — 要件定義・設計・開発・テスト・保守それぞれの目安

スクラッチ開発の費用は、大きく「初期開発費」と「保守・運用費」に分かれます。初期開発費はさらに工程別に積み上げられます。一般的な人月単価（エンジニア1人が1か月稼働するコスト）は、ベンダーの規模や技術領域によって60万〜150万円程度で幅があります。

• 要件定義・基本設計：全体工数の15〜25%程度。小規模案件でも数十時間を要し、手を抜くと後工程のやり直しコストが跳ね上がります。
• 詳細設計・開発：全体工数の40〜50%程度。機能数とデータ連携の複雑さで大きく変動します。
• テスト・品質保証：全体工数の15〜20%程度。基幹システムは業務停止リスクが高いため、受入テストに想定以上の工数がかかるケースが少なくありません。
• 保守・運用費：初期開発費の15〜20%/年が目安です。法改正対応・機能追加・インフラ費用を含めると、5年間の総保有コスト（TCO）は初期費用の2〜3倍になることもあります。

規模感別の初期開発費の目安は以下のとおりです。

• 小規模（単機能・社内ツール寄り）：500万〜1,500万円程度。ユーザー数が少なく、外部連携が限定的な場合。
• 中規模（複数業務を統合した基幹系）：1,500万〜5,000万円程度。在庫・受発注・会計など複数モジュールを統合する案件が該当します。
• 大規模（グループ横断・多拠点・高負荷）：5,000万〜数億円。マルチテナント構成や大規模データ処理が伴う場合です。

費用が膨らみやすい要因 — 仕様変更・連携システム・データ移行

見積もりが大きくブレる構造的な理由は、開発着手後に仕様が変わりやすいことにあります。要件定義が浅いまま進んだ場合、設計・開発フェーズでの手戻りが発生し、工数が当初比で30〜50%増になるケースも珍しくありません。

連携システムの数も費用に直結します。会計ソフト・ECプラットフォーム・物流システムなど外部APIとの接続が増えるほど、結合テストの工数が乗数的に増加します。また、既存システムからのデータ移行は「クレンジング（データ整備）」に想定外の時間がかかり、費用超過の主因になりやすい工程です。

補助金・IT導入補助金の活用可能性

中小企業がスクラッチ開発を検討する場合、IT導入補助金（中小企業庁）の活用を検討する価値があります。ただし、補助対象となるのは原則として「ITツール」として登録されたソフトウェア・サービスであり、完全なフルスクラッチ開発は対象外になるケースが多いです。セミオーダー型の開発や、パッケージをベースにカスタマイズする形式であれば対象になる可能性があるため、申請前にベンダーと要件を確認することが重要です。

開発期間の目安と工程 — フェーズ別にスケジュールを把握する

基幹システムのスクラッチ開発では、着手から本番稼働まで一般的に12〜24ヶ月程度かかるケースが多いです。規模や業務の複雑さによってはさらに長くなることもあります。「思ったより時間がかかった」と感じる企業が多い背景には、要件定義・テスト・データ移行といった工程の工数が、計画段階で過小評価されやすい点があります。

標準的な工程とフェーズ別期間の目安

スクラッチ開発の工程は、おおむね以下のフェーズで進みます。

• 要件定義：2〜4ヶ月　業務フローの整理、システム化範囲の確定、非機能要件（性能・セキュリティ・運用方針など）の定義を行います。ERPスクラッチの要件定義では、部門をまたぐ業務調整が発生するため、関係者へのヒアリングだけで数週間を要するケースが少なくありません。
• 基本設計・詳細設計：2〜4ヶ月　画面設計、データベース設計、外部システムとの連携仕様を確定します。
• 開発（実装）：3〜8ヶ月　機能規模に比例して期間が伸びます。並行開発の体制が取れるかどうかで大きく変わります。
• テスト：2〜4ヶ月　単体・結合・総合テストに加え、ユーザー受け入れテスト（UAT）を実施します。
• データ移行・本番切替：1〜2ヶ月　旧システムからのデータ洗浄・移行検証、リハーサルを経て本番稼働に至ります。

期間が延びやすいフェーズとその対策

特に遅延が起きやすいのは、要件定義・テスト・データ移行の3フェーズです。

要件定義では、業務部門間の認識齟齬が後から発覚し、仕様変更が連鎖するケースが典型的です。対策としては、フェーズ開始前に「確定権限を持つ意思決定者」を明確にし、決定プロセスをあらかじめ設計しておくことが有効です。

テストフェーズでは、バグ修正と再テストの繰り返しにより工期が膨らみやすいです。設計段階でテスト計画を並行して立てておくことで、手戻りを最小化できます。

データ移行は「最後の作業」として後回しにされがちですが、旧システムのデータ品質が低い場合、クレンジングだけで数週間かかることもあります。移行対象データの棚卸しは、要件定義と並行して着手するのが現実的です。

要件定義の進め方 — スクラッチ開発の成否を決める最重要フェーズ

スクラッチ開発における要件定義は、最終的なコスト・品質・スケジュールの大半を決定づけるフェーズです。ここでの曖昧さや抜け漏れは、開発中盤以降の仕様変更や手戻りに直結し、追加費用や納期遅延を引き起こします。ERPスクラッチ・基幹システムの独自開発では特に業務範囲が広く、関係部門も多いため、発注側が主体的に関与する姿勢が不可欠です。

As-Is業務フローの整理 — 現状の棚卸しからはじめる理由

要件定義の出発点は、現行業務の可視化です。「今、社内でどのような業務がどういう順序で行われているか」を整理しないまま新システムの要件を語ると、現場の実態とかけ離れた設計になりやすくなります。

As-Is分析では以下の観点を棚卸しします。

• 各部門が担う業務ステップと担当者の役割
• 現行システムやExcelで処理している作業の一覧
• 部門間のデータ受け渡し方法と発生しているボトルネック
• 属人化している業務・ルール化されていない例外処理

現場へのヒアリングと業務マニュアル・帳票の収集をセットで進めると、ドキュメントに書かれていない実務上のルールを拾いやすくなります。

To-Be設計 — 「あったらいい機能」と「必須要件」を分ける

As-Isの整理を踏まえ、新システムで実現したい状態（To-Be）を定義します。このとき最も重要なのは、要件に優先度をつけることです。

スクラッチ開発では「せっかく作るなら」という発想から要件が膨らみやすく、スコープの肥大化がコスト超過の主因になるケースが少なくありません。要件はMust（業務上必須）・Want（あると望ましい）・Nice to have（将来対応でも可）の3段階に分類し、初期リリース範囲を絞り込む判断が重要です。

特に基幹システムの独自開発では、他システムとの連携仕様（受発注・会計・物流など）をこの段階で明確にしておかないと、後工程でインターフェース設計の手戻りが発生しやすくなります。

発注側が要件定義フェーズで用意すべき資料・情報

要件定義をスムーズに進めるために、発注側が事前に準備しておくべき資料は以下のとおりです。

• 業務フロー図・業務一覧表：部門単位で作成し、担当者・使用ツール・処理頻度を記載する
• 現行システムのER図・データ仕様書：既存データの移行範囲と構造を把握するために必要
• 帳票・画面のサンプル：インプット・アウトプットのイメージを共有することで認識齟齬を防ぐ
• 非機能要件の方針：同時接続数・レスポンス要件・セキュリティポリシー・稼働時間帯などの制約条件
• 関係者リスト：意思決定者・承認フローを整理し、誰が最終確認を行うかを明確にする

これらをベンダー選定前から準備しておくと、提案精度が高まり、見積もり段階での認識ずれも減らせます。

要件定義フェーズでのベンダーとの合意形成のポイント

要件定義フェーズでは、ベンダーとの合意内容をドキュメントとして残すことが後工程のトラブル防止につながります。具体的には以下の点を書面で確認しておくことが重要です。

• 要件定義書・機能一覧のバージョン管理：合意した時点の版を双方が保持する
• スコープ外の明示：「初期リリースに含まない機能」を要件定義書に明記し、追加費用の根拠を透明にする
• 変更管理ルール：要件変更が生じた場合の手続き・承認フロー・費用への影響を事前に取り決める
• レビュー体制：発注側の担当者とベンダーのプロジェクトマネージャーが定期的に進捗・課題を確認する場を設ける

要件定義は「ベンダーに任せるフェーズ」ではなく、発注側が業務知識を提供し、ベンダーがそれをシステム要件に落とし込む共同作業です。発注側の関与度合いが低いほど、要件の精度は下がり、後工程での修正コストが増加する傾向があります。ERPスクラッチ・基幹システムの独自開発においては、この認識を開発開始前から組織内で共有しておくことが、プロジェクト成功の前提条件になります。

発注方式の選び方 — 請負・準委任・ラボ型の違いと向き不向き

スクラッチ開発の発注形態は、大きく3つに分けられます。請負契約・準委任契約・ラボ型（専属チーム型）です。それぞれリスクの所在とコスト構造が異なるため、プロジェクトの性質に合った方式を選ぶことが重要です。

請負契約 — 要件が固まっている場合の定額発注

請負契約は、成果物の完成を約束する契約形態です。あらかじめ決めた要件・仕様に対して固定の金額で発注できるため、予算管理がしやすい点が特徴です。

一方で、要件定義が不十分な状態で契約すると、仕様変更のたびに追加費用が発生しやすくなります。基幹システムのスクラッチ開発では要件が途中で変化するケースが少なくないため、請負契約が適しているのは、業務フローや機能要件がほぼ確定している場面に限られます。

準委任契約 — 要件が変化しやすい業務に向く柔軟な発注

準委任契約は、成果物ではなく「作業そのもの」に対して報酬を支払う契約形態です。エンジニアの稼働時間に対して費用が発生するため、仕様変更や追加要件が生じても柔軟に対応できます。

ただし、稼働時間に応じてコストが積み上がる構造であるため、進捗管理や優先度の判断を発注側が主体的に行う必要があります。要件が流動的な初期フェーズや、アジャイル的に開発を進めたい場合に向いています。

ラボ型・専属チーム型 — 長期・継続開発に向く体制

ラボ型は、開発会社のエンジニアチームを月単位で確保し、継続的に開発・改善を行う契約形態です。基幹システム開発会社の選び方として注目されることが増えており、リリース後の運用・機能追加まで一貫して同じチームに任せられる点が強みです。

初期費用を抑えながら段階的に機能を拡張したい場合や、内製チームの代替として外部リソースを長期活用したい場合に適しています。

3方式の比較表 — リスク・コスト・適した場面

• 請負契約：コストは固定／リスクは仕様変更時の追加費用／要件が確定済みの案件に向く
• 準委任契約：コストは変動（工数ベース）／リスクは進捗管理の負担／要件が流動的な案件や初期フェーズに向く
• ラボ型：コストは月額固定／リスクは長期コミットメント／継続的な開発・運用が前提の案件に向く

スクラッチ開発では、要件定義フェーズを準委任で進め、開発フェーズを請負に切り替えるといった組み合わせも実務上よく見られます。発注方式は開発会社との交渉の中で柔軟に検討することをお勧めします。

開発会社の選び方 — 基幹システム案件で確認すべき5つのポイント

「実績が豊富」「費用が安い」だけを根拠にベンダーを選ぶと、基幹システムのスクラッチ開発では失敗リスクが高まります。基幹システムは業務の根幹に関わるため、開発完了後も長期にわたって関係が続くからです。以下の5つの観点を軸に、選定基準を整理してください。

業務理解力と要件定義への関与スタンスを確認する

スクラッチ開発の品質は、要件定義の精度に大きく左右されます。そのため、ベンダーが「要件を聞いて実装するだけ」なのか、「業務課題を掘り下げて要件を一緒に整理する」スタンスなのかを、初回提案の段階で見極めることが重要です。

確認すべき点は次の3つです。

• 提案書に業務フローや課題の整理が含まれているか
• ヒアリング担当者が業務知識を持つコンサルタントかエンジニアか
• 要件定義フェーズを別契約・別工数として明確に設けているか

要件定義を「無料サービス」として短期間で済ませようとするベンダーは、手戻りや仕様漏れのリスクが高い傾向があります。

保守・運用体制と長期関与の可否を確認する

基幹システムは、リリース後も法改正・業務変更・機能追加への対応が継続的に発生します。開発チームがリリース後も継続して関与できる体制かどうかを、契約前に確認しておく必要があります。

特に確認したいのは以下の点です。

• 保守契約の有無と対応範囲（バグ対応のみか、機能改修まで含むか）
• 開発メンバーとサポート担当の継続性（外注先が変わらないか）
• 障害発生時のSLA（サービスレベル合意）と応答時間の定義

RFP作成時に盛り込むべき確認事項

RFP（Request for Proposal：提案依頼書）を作成する際は、「何を作るか」だけでなく「どう進めるか・どう支えるか」をベンダーに問う設問を盛り込むことが効果的です。

具体的には、以下の項目を設問として設定すると、各社の対応力の差が明確になります。

• 要件定義の進め方と想定工数・期間
• 採用する技術スタックとその選定理由
• 開発中のコミュニケーション頻度と報告形式（週次定例・課題管理ツールなど）
• リリース後の保守体制と月額費用の目安
• 類似業務の開発実績と担当者の参画可否

これらの設問への回答内容と回答の速度・精度を比較することで、単純な見積金額の比較よりも実態に近い評価ができます。

CLANEのアプローチ — 自社ERP「CLANE ERP」とスクラッチ開発の両面対応

CLANEは、自社開発のERPパッケージ「CLANE ERP」と、業務要件に合わせたスクラッチ・準委任開発の両方を提供しています。「パッケージかスクラッチか」を最初から固定するのではなく、企業の業務実態や導入フェーズに応じて選択肢を段階的に検討できる体制が特徴です。

パッケージとスクラッチの二択ではなく段階的に選べる理由

CLANE ERPは、販売管理・在庫管理・請求管理などの標準機能をベースに、カスタマイズの範囲を柔軟に設定できる設計になっています。そのため、まずパッケージで短期導入し、業務フローが固まった段階でスクラッチ開発に移行するという段階的なアプローチが取りやすくなっています。

一方で、既存業務の特殊性が高く、パッケージでは対応しきれないと判断された場合は、要件定義の段階からスクラッチ開発として進めることも可能です。この判断は、ヒアリングを通じて業務フローを整理した上で行われるため、開発着手前に自社に合った方式を見極めやすくなっています。

補助金活用支援と運用まで一貫する体制について

CLANEはIT導入補助金などの補助金申請支援にも対応しており、初期費用の負担軽減を検討している企業にとっての選択肢になり得ます。また、開発完了後の保守・運用フェーズも継続して担当できる体制を持っているため、リリース後に別の会社へ引き継ぐ必要がなく、仕様の背景を知っているチームがそのまま対応を続けられます。

基幹システムの開発会社を選ぶ際には、開発実績だけでなく、運用フェーズまで一貫して関与できるかどうかも重要な確認項目のひとつです。CLANEはこの点で、開発から運用までを単一の体制で担う形をとっています。

まとめ — スクラッチ開発の検討で押さえるべき判断軸

基幹システムのスクラッチ開発（独自開発）を選ぶかどうかは、複数の判断軸を組み合わせて検討する必要があります。以下に、本記事で取り上げた論点を整理します。

• 選択の条件：自社固有の業務フローが競争優位の源泉になっている、あるいはERPパッケージのカスタマイズコストがスクラッチ開発の費用を上回るケースでは、スクラッチ開発の優位性が高まります。
• 費用の目安：小規模システムで500万〜1,000万円程度、中規模で2,000万〜5,000万円程度、大規模になると1億円を超えるケースも少なくありません。機能範囲・体制・発注方式によって大きく変動します。
• 期間の目安：要件定義から本番稼働まで、中規模システムで12〜18か月程度を見込むのが現実的です。要件定義フェーズの遅延が全体工程に直結するため、早期の着手が重要です。
• 要件定義の重要性：スクラッチ開発の成否は要件定義で決まるといっても過言ではありません。業務フローの可視化と優先順位の合意を社内で先行させることが、発注後の手戻りを防ぐ最善策です。
• 発注方式の選択：仕様が固まっていれば請負契約、仕様が流動的な段階では準委任契約やラボ型契約が適しています。プロジェクトの性質に合わせて使い分けることが費用対効果を高めます。

これらの軸を社内で整理したうえで、複数のベンダーに要件を提示し、見積もりや開発アプローチを比較することが、発注判断を適切に進めるための現実的なステップです。