基幹システム/ERP改修とは、既存のシステムをゼロから作り直さず、特定のモジュールや画面、機能を部分的に修正・追加することです。
具体的には、影響範囲を調べ、対象を絞って改修し、テストとリリース準備まで進める一連の取り組みです。
▼全体ガイドの記事
・基幹システム/ERP改修の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
基幹システム/ERP改修の全体像と位置づけ
改修では、既存システムを土台に残したまま、特定のモジュールや画面、機能だけを部分的に修正・追加します。
ゼロから作り直さないことが、改修と刷新を分ける境目です。
改修は、すべてを変えずに部分最適を目指す選択です。
技術手法全般を指すモダナイゼーションや、経営判断としての刷新とは、軸が違います。
刷新の手法ごとに、軸となる観点は分かれます。
手法別に見ると、更改は保守契約満了などの外圧を軸にします。リニューアルは操作性、リアーキテクチャは設計、リプレイスは製品・ベンダーの乗り換えが軸です。
特定モジュール・特定機能への対象の限定
改修の対象は、基幹システムやERPの機能のうち、業務上の課題や法改正の影響が出ている部分です。
範囲を区切ると、影響調査や作業量を抑えられます。
- 会計：一つのモジュールに限った改修
- 受発注：特定の画面に限った改修
- 帳票：特定のレイアウトに限った修正
一方で、範囲を広げすぎると複数のモジュールにまたがり、中規模改修に近づいて費用や期間が膨らみます。まず、着手前に対象と次のフェーズへ回す範囲を線引きすることが、部分改修の出発点です。
「リフォーム」に近い考え方と既存資産の活用
改修は建物のリフォームに近い考え方です。このため、既存システムのデータや業務ノウハウ、利用者の操作習熟を生かせます。
ゼロから設計し直すフルスクラッチ開発が「新築」にあたるのに対し、必要な部分だけを変える改修は「リフォーム」です。
ただし、既存の構造を保つことには制約があります。老朽化した基礎を直さず内装だけを変えても長続きしないのと同じで、影響調査を省いた表面的な修正を重ねると、ブラックボックス化のリスクが高まります。
改修の対象になりやすいモジュール・機能
改修の対象には、法改正・制度改定があります。
帳票や画面の微調整、新機能や外部連携、データベースの小規模変更も含まれます。
どの対象も、全体を作り替えず、影響範囲を絞れる点が共通しています。
法改正・制度改定への対応
法改正対応では、対象となる変更の種類を見極めたうえで、費用を修繕費として扱える条件も確かめます。
- 制度・ルールの変更：税率、インボイス、日付表示、給与計算
- 改修範囲：特定のマスタや計算ロジックに絞られるケースが多い
修正費用が20万円未満、または取得価額の10%以下かつ60万円未満なら、税務上の修繕費として処理できる例もあります。
該当するかどうかは、自社の税務方針を踏まえて専門家に確認してください。
帳票・画面UIの微調整
特に、帳票のレイアウトや画面の表示順、ボタンの文言などは、頻繁に発生する改修の対象です。一方で、実作業が数十分から1時間程度でも、最低作業料金がある契約では費用が発生する例があります。こうした小口改修が積み重なると、想定以上にランニングコストへ影響します。
- テーブル項目の追加：8万円の例
- 表示順序の変更：10万円の例
- 印刷レイアウトの調整：12万円程度の例
新機能追加・外部連携とデータベースの小規模変更
既存システムに機能を足す場合、費用や工数は追加する内容と画面の複雑さで変わります。
- 新機能・外部連携：LINEやSlackの通知、CSVの入出力、決済APIとの接続
- データベース変更：マスタ項目の追加など、小規模な手直し
- 改修全体の相場：30万〜160万円程度の目安
- 画面の工数：一覧・検索は0.5〜1人月、入力フォームは1〜2人月
- 複雑な画面：帳票やダッシュボードは2〜4人月程度が目安
部分改修の仕組みと進め方
部分改修は、全面刷新のような大規模な要件定義ではなく、対象を絞った現状把握から始めます。
工程は、影響範囲の調査、設計・改修、テスト、リリース準備の順に進みます。
事前調査・変更箇所調査・影響調査の3段階による現状把握
着手前に事前調査、変更箇所調査、影響調査の順で行い、現行の仕様がどうなっているかを明らかにします。
- 事前調査では構造図を作り、1関数あたり約1分を目安に全体像をつかみます。
- 変更箇所調査で、修正対象を特定します。
- 影響調査で、変更が及ぶ範囲を洗い出します。
実際、派生開発の不具合分析では、影響範囲を洗い出せなかったことによる手戻りが287時間で最大の要因でした。そのため、調査を省くと、改修規模に見合わない手戻りが起きがちになります。
仕様が分からないまま手を入れると、予期しない不具合につながります。そこで、仕様を確かめる作業も改修工程に含める考え方が有効です。
たとえば、作成者の退職などで改修できなくなったAccess受発注システムを、AIで全機能解析して仕様書にまとめ、Webシステムへ移行した事例があります。その事例では、約4ヶ月で3拠点の稼働を開始しました。
開発期間を左右するモジュール単位の切り分け
対象範囲の広さで開発期間がどう変わるかを比べると、改修の規模を見極める手がかりになります。
- 小規模改修：単機能の追加・修正で1〜3ヶ月
- 中規模改修：モジュール刷新や複数部門の業務見直しで4〜8ヶ月
- 全面刷新：全体を作り替える場合で1年以上
中規模改修の工程配分の目安は、要件定義が15〜20%程度（約2ヶ月）、設計が20〜25%程度（約2ヶ月）です。続いて、開発・実装が30〜50%程度（約2〜3ヶ月）、テストが20〜30%程度（約1〜1.5ヶ月）となります。
特にテストでは、デグレードテストに多くの工数を割きます。リリース準備は5〜10%程度（約0.5ヶ月）が目安です。
期間を縮めるには、Must（必須）とWant（希望）を分けて、MVP的に段階リリースする方法が役立ちます。また、経費精算や勤怠管理のような標準的な業務は既存のSaaSへ切り出し、独自性の高いコアだけを改修の対象にする方法もあります。
具体的な選定ポイントや評価軸は、基幹システム/ERP改修の選定ポイント・選び方・種類で整理しています。
モックアップ・プロトタイプ検証の省略の可否
技術的な不確実性が低い小規模改修なら、正式なPoCを省略できる場合があります。たとえば、レイアウトの変更や、既存ルール内での業務フローの変更がこれにあたります。
- 静的モックアップ：画面の見た目を確かめるもの
- 動的プロトタイプ：画面遷移や操作性を試せるもの
中小企業のPoC費用の目安は、30万〜300万円で、期間は2〜8週間、本開発予算の10〜20%程度です。ただし、AI-OCRなどの新技術や未知の外部API連携を含む場合は、小規模でもPoCを省略しない方が安全です。
検証対象を1つに絞り、Go/No-Goの基準を事前に合意しておけば、検証だけで予算を使い切る「PoC貧乏」を防げます。
改修とフルスクラッチ・他の刷新手法との境界線
改修をどこまで続け、いつフルスクラッチや全面刷新に切り替えるかは、多くの企業が悩む判断です。その判断は、将来要件、システム品質、ブラックボックス化、予算と期間の4軸で考えると整理できます。
改修範囲を見極める4つの判断軸
改修か刷新かの判断では、観点ごとに現状を確かめることが出発点になります。
- 将来の業務要件：大きく変える予定がなければ、改修で足ります。
- 現行システムの品質：安定して稼働しているなら、改修や延命を優先できます。
- ブラックボックス化：進んでいる場合は、まず「読める化」が欠かせません。
- 予算と期間：限られるなら、部分改修を段階的に進める形です。
現行システムの品質が破綻しかけている場合は、フルスクラッチに進む前に仕様を見える形にします。
500万円から数億円までの規模の目安と、改修から刷新への境界
金額と改修範囲を照らし合わせると、部分改修を続けるか、切り替えるかの判断材料になります。
- 小規模改修：一部機能の刷新で500万〜2,000万円程度
- 中規模改修：複数部門にまたがるデータ移行を伴い、2,000万〜8,000万円程度
- 刷新の領域：8,000万円〜数億円以上で、全体再構築などを伴う
- 保守費の目安：開発費の年間15〜20%程度、20〜25%超なら切り替えを検討
- 規模による境界：2,000万円超で中規模更改に達する場合の移行の検討
全体再構築や全社横断の業務再編、複数システムの統合を伴う場合は、フルスクラッチや全面刷新の領域に入ります。改修の規模が中規模更改に達したら、モダナイゼーションやフルスクラッチへの移行を検討することになります。
法改正対応改修が求められる場面
消費税率やインボイス制度のように、施行の期日が法令で決まっている改修では、優先度を先に決めて、早めに着手する必要があります。
施行期日が動かせないことによる優先度の最大化
施行日は動かせないため、法改正対応は他の案件より優先度を最大限に上げ、早期に着手する必要があります。
要件定義や影響調査に時間をかけすぎると、テストやリリース準備が圧迫されます。その結果、施行に間に合わないリスクが生じます。
他の改修案件に対するリソースの優先配分
複数案件が並行する場合、法改正対応へ人員を優先配分します。そのうえで、緊急度の低い機能追加や画面調整は後回しにします。
修正費用が20万円未満、または取得価額の10%以下かつ60万円未満なら、修繕費として処理できる例もあります。
費用の見通しは、早めに経理部門と共有しておくと、社内の合意を得やすくなります。ただし、税務上の該当性は、自社の方針と専門家に確認します。
改修を繰り返すことで生じるリスク
改修は低予算・短納期で始めやすい一方、繰り返すとリスクが積み重なります。複雑化やブラックボックス化、そして放置した場合の影響が代表的です。
スパゲッティ化とブラックボックス化の進行
部分改修を繰り返すと、制御フローが複雑になり、スパゲッティ状態に陥りがちです。担当者の退職や異動、設計書の未更新が重なると、全体像を把握できる人がいなくなり、ブラックボックス化も進みます。
スパゲッティ化やブラックボックス化は、次の改修でデグレードのリスクを高め、現場の変更への抵抗感を強めます。
放置した場合の「2025年の崖」のリスク
経済産業省のDXレポートは、老朽化した基幹システムを放置した場合、毎年最大12兆円の経済損失が生じるリスクを指摘しています。
場当たり的な改修で終えず、影響範囲の調査や仕様の確認も進めることが、将来のブラックボックス化を防ぐ実務上の対策になります。
基幹システム/ERP改修の導入前に確認したいポイント
着手の判断は、対象範囲の広さだけでなく、予算、法改正対応の緊急度、ブラックボックス化の状況も含めて行います。そうしておくと、着手後の手戻りを防げます。
小規模改修でも影響調査を省かないこと
たとえ作業が数十分で終わる修正でも、調査を省くと、想定外の箇所に不具合が波及する可能性があります。
なお、最低作業料金が発生する契約もあります。小口改修にも、事前調査の工程を残してください。
フルスクラッチへの切り替え判断（規模と品質）
年間の保守費用が開発費の20〜25%を超える場合や、改修規模が中規模更改に近づいている場合は、刷新を検討します。
切り替えの判断では、将来要件や現行システムの品質を踏まえます。ブラックボックス化や予算と期間も、あわせて見ておきます。
法改正対応の優先度と計画
消費税率やインボイス制度など、施行日が決まっている改修は、早期に着手し、人員を優先的に配分します。
修繕費として扱える金額の目安はあります。ただし、該当するかどうかは、自社の税務方針や専門家への確認が必要です。
まとめ
基幹システム/ERP改修は、全面刷新の予算やリスクを負いにくい企業が、特定の機能に絞って手を加える選択肢です。
主な対象は、法改正対応と、帳票・画面UIの微調整です。ほかに、新機能の追加や外部連携、データベースの小規模変更もあります。まず影響範囲の調査から進めれば、手戻りを防げます。
既存資産を生かして課題を解決する手段
改修を重ねると、スパゲッティ化やブラックボックス化が進み、「2025年の崖」で指摘される損失リスクにつながります。
発注側は、将来要件や現行の品質、予算と期間を踏まえ、改修とフルスクラッチのどちらを選ぶかを定期的に見直します。
対象範囲の可視化から始める進め方
現状を把握し、対応方法を切り分けることから、改修計画は具体的になります。
- 現状を可視化：検討範囲の現行仕様と影響箇所
- 対応方法を分ける：既製のクラウドやノーコードと、独自要件による個別開発を切り分け、無理のない計画を立てる
- 必要な支援を相談：riplaは仕様の可視化、影響調査、部分改修、既存システムとの連携を支援
▼全体ガイドの記事
・基幹システム/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を創業。