基幹システム/ERP改修で、フルスクラッチ・オーダーメイド開発に切り替えるかどうかは、部分改修と比べた費用・期間・リスクと、固有要件をどこまで作り込むかで決まります。ここでいう改修は、会計や人事給与などの基幹システムで、特定の機能やモジュールだけを対象にする小規模な修正です。
- 選択基準：部分改修とフルスクラッチの境界
- 費用・リスク：固有要件と運用負荷の比較
- 移行：切り替えと技術体制の確認
本テーマの全体像は、以下の記事をご覧ください。
同じ基幹システム/ERPを扱う記事でも、主軸は異なります。「基幹システム/ERPのモダナイゼーション」は5つの技術手法を横断する総論、「基幹システム/ERP刷新」は経営層の投資判断、「基幹システム/ERP更改」は契約起点の期限が軸です。
「基幹システム/ERPリニューアル」は現場ユーザーの体験起点、「基幹システム/ERPリアーキテクチャ」は技術の深掘り、「基幹システム/ERPリプレイス」は製品・ベンダー選定の意思決定が軸です。
▼全体ガイドの記事
・基幹システム/ERP改修の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
改修とフルスクラッチという根本的な違い
改修とフルスクラッチの選択は、既存の基幹システムを土台として活かすか、土台ごと作り直すかという判断です。この違いは、家に例えると分かりやすくなります。
「リフォーム」としての改修と「新築」としてのフルスクラッチ
改修は、今の家をリフォームするように、すでにあるシステムを活かしながら機能の追加や修正を行う手法です。また、従業員が新しい操作を覚える手間が少なく、既存のデータもそのまま使い続けられるという利点があります。
一方、フルスクラッチ（リビルド）は、新しい家を建てるように業務要件から見直し、ゼロから設計・開発を行う手法です。自由度は最も高いものの、要件定義の負荷が大きく、コストや期間が大幅に膨らむリスクがあります。
このたとえで言えば、改修は傷んだ部屋だけを直すアプローチです。家全体を建て替えるほどの予算も時間もかけずに、困っている部分だけを解決したいというニーズに応えるものです。
基幹システム/ERPリプレイスとの違い
混同されやすい「基幹システム/ERPリプレイス」は、自社で作り続けるか、他社のパッケージ製品に乗り換えるかという、製品・ベンダー選定の意思決定を扱います。
一方、この記事のフルスクラッチ・オーダーメイド開発は、自社や開発パートナーによる独自開発が前提です。その中で、部分的な改修で行うか全体を作り直すかというスコープの選択を扱います。
両者は隣り合う論点ですが、判断の軸は異なります。リプレイスは、自社で作り続けるか他社の製品を買うかを決める判断です。これに対して改修とフルスクラッチは、既存の基幹システムという資産を活かすか作り直すかを問うものです。
改修対象になりやすいモジュール・機能の代表例
フルスクラッチに踏み切るかを判断する前に、改修がどの機能に対して選ばれているかを把握しておくと役立ちます。
法改正・制度改定への対応
基幹システムで部分改修の対象になりやすいのは、外部環境の変化への対応です。消費税率の変更やインボイス制度の導入に伴う改修が代表的です。国税庁の例では、POSレジシステムや受発注・経理システムについて、「請求書フォーマットへの登録番号・適用税率・消費税額等の追加」や「積上げ計算方式への対応仕様変更」などが挙げられています。
また、元号変更に伴う日付表示の変更や、新しい給与計算ルールへの対応（人事モジュール）なども、頻繁に発生します。これらは、会計・人事など特定モジュールに限った改修で対応でき、基幹システム全体をフルスクラッチで作り直す必要は通常ありません。
帳票・画面UIの微調整、新機能追加・外部連携
印刷レイアウトの微調整や、画面の表示項目の並べ替え、見出しやボタン文言の変更など、使いやすさを上げる改修が代表的です。複雑なダッシュボードやレポート機能の追加も、改修の対象になります。
アラートや通知機能の追加（LINEやSlackへの通知など）や、データのCSV入出力機能の追加も、よくある改修内容です。さらに、外部の決済・APIサービスとの新たな連携や、マスタデータへの項目追加は、データベースの小規模な変更にあたります。
これらは「困っている一点」にピンポイントで対応するもので、フルスクラッチの発想とは対照的な、部分改修ならではの機動力を発揮できる領域です。
改修を繰り返すことで生じるスパゲッティ化・ブラックボックス化のリスク
改修は単発なら低リスクな選択肢ですが、何年も積み重ねると、フルスクラッチへの切り替えを検討せざるを得ない固有のリスクを生みます。
場当たり的な改修の積み重ねが招くスパゲッティ状態
既存システムへの機能追加や場当たり的なカスタマイズを長年繰り返すと、プログラムの制御フローが複雑に絡み合う「スパゲッティ状態」になり、保守性や可読性が著しく下がります。また、当時の開発担当者が退職・異動したり、改修のたびに設計書が更新されず実態と乖離したりすると、全体像や内部構造を誰も把握できない「ブラックボックス化」が進みます。
ブラックボックス化が進むと、小さな機能追加でも想定外の箇所に悪影響（デグレード）が及ぶようになります。変更には多大な時間とリスクを伴うため、システムを変えることへの抵抗感が組織に蔓延します。
この状態が放置されると、2025年以降に毎年最大12兆円の経済損失が生じる「2025年の崖」を招くおそれがあると、経済産業省のDXレポートで警告されています。
リスクを予防する改修の進め方
こうしたリスクは、改修を場当たり的に積み重ねた結果として生じるものです。改修のたびに設計書・仕様書を更新して変更履歴を一元管理し、改修の累積規模を定期的に洗い出して、スパゲッティ化の進み具合を可視化しておくことが、将来の大規模な手戻りを防ぐ予防策になります。
低予算・短期間で改修を繰り返すこと自体は合理的な戦略です。ただし、履歴管理を怠ると、いずれフルスクラッチでしか解決できない状態に陥ります。この点は、あらかじめ認識しておく必要があります。
部分改修とフルスクラッチの境界線
部分改修で足りるか、フルスクラッチで再構築すべきかは、判断の軸と規模感の目安から見極められます。
判断の4つの軸（将来要件・現行品質・ブラックボックス度・予算期間）
判断は主に4つの軸で行われます。1つ目は将来の業務要件で、今後大きく変える予定がなければ部分改修、業務プロセスを抜本的に見直したい場合や独自性が強く既製品も合わない場合はフルスクラッチが適します。
2つ目は現行の品質で、安定して動いているなら部分改修や延命を、設計に無理があり破綻しかけているならフルスクラッチを検討します。3つ目はブラックボックス度で、中身の仕様が誰も分からない状態でのフルスクラッチは、要件がブレて失敗するリスクが極めて高くなります。
そのため、どの手法を選ぶにせよ、まずは現状の仕様を「読める化（文書化）」する工程が欠かせません。4つ目は予算と期間の制約で、限られる場合は、最も課題の大きい部分に絞り、段階的に部分改修を進めるのが現実的です。
規模の境界線（500万〜2,000万円は改修、8,000万円超はフルスクラッチ領域）
一部機能の刷新や特定画面の再構築（目安：約500万円〜2,000万円）は、部分改修の範囲に収まりやすいとされています。複数部門をまたぐデータ移行を伴う刷新（目安：約2,000万円〜8,000万円）も、同じ範囲に入ると言えます。
一方、基幹システム全体の再構築や全社横断の業務再編、複数システムの統合などで、対象システムや拠点数が多く、絶対に止められない業務が広範囲にわたる場合は、大規模なフルスクラッチ（全体刷新）の領域です。費用は8,000万円〜数億円以上にのぼります。
改修規模が2,000万円を超え、中規模な更改（2,000万〜8,000万円）に達する場合は、単なる部分改修の枠を超えます。機能を独立したモジュールに切り出したり、APIを介した疎結合な構造に移したりして、システムの根本的なアーキテクチャを見直すモダナイゼーションを検討すべき境界線とされています。
フルスクラッチへの切り替えを検討すべきタイミングと発注実務
境界線を数値で押さえたうえで、どのタイミングで切り替えを検討すべきかを、指標と事例から見ていきます。
数値指標（保守費用が開発費の20%超え）と事例
現行システムの維持費や追加改修費が高すぎると感じたら、切り替えを考えるきっかけになります。一般的な年間保守費用の相場は開発費の15〜20%とされ、老朽化で保守工数が増えるなどしてこの比率が20%を大幅に超えていれば、大きなサインです。調査・解析コストが実作業コストを上回る場合も、一から作り直す方が合理的という判断に至る典型的なサインです。
事例として、従業員50名の製造業A社では、15年前に導入したシステムの月額保守費用が5万円に抑えられていました。一方で、帳票修正や画面変更といった保守契約外の追加改修が、年間平均80万円も発生していました。
A社は、不透明な追加費用の支払いに限界を感じ、クラウド型ERPへの移行を決断しました。月額利用料は8万円（保守費用込み）に上がったものの、軽微な設定変更を自社で対応できるようになり、長期的なランニングコストの大幅な削減に成功しています。
発注前の整理事項
フルスクラッチへの切り替えを検討する段階になったら、まず改修履歴と現行仕様が、どこまで把握できる状態かを整理します。その内容を依頼先の候補に共有できる状態にしておく必要があります。
ブラックボックス化が進んでいる場合は、フルスクラッチの要件定義そのものが難航します。そのため、仕様を文書に起こす工程から先行して依頼できるパートナーを選ぶことをお勧めします。
一方、まだ部分改修の範囲で対応できる規模であれば、無理にフルスクラッチへ切り替えず、改修を続けながら定期的に境界線を見直していく判断も、限られた予算を有効に使う現実的な選択肢です。
まとめ
ここまで、改修とフルスクラッチの違いから、切り替えを検討するタイミングまでを見てきました。
費用の目安では、500万〜2,000万円程度の一部機能の刷新や、2,000万〜8,000万円程度の中規模な更改は、部分改修の範囲に収まりやすいとされています。8,000万円〜数億円以上の規模になって初めて、フルスクラッチが視野に入ります。
保守費用が開発費の20%を超えていたり、調査・解析コストが実作業コストを上回ったりしたら、切り替えを検討すべき明確なサインです。
開発期間や費用の詳細は、基幹システム/ERP改修の開発期間・スケジュール・納期や、保守・運用費用・ランニングコストの各記事に譲ります。特に強調したいのは、改修の履歴を記録し続けることが、切り替えの時期を見誤らないための最も確実な備えだという点です。
改修とフルスクラッチの両方に実績のあるパートナーに、早めに相談してみてください。
▼全体ガイドの記事
・基幹システム/ERP改修の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。