基幹システム・ERP更改は、現状分析と方針決定に始まり、データ移行や稼働後の安定化までを7つのステップで進めます。
ただし、進め方を誤ると数億円規模の損失と数年間の業務混乱を招くおそれがあります。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
基幹システム/ERP更改の定義と、更改が必要になるタイミング
基幹システム・ERPの更改を検討する前に、まず対象システムの定義と業務への影響範囲を正確に把握することが欠かせません。
また、「更改」「バージョンアップ」「新規導入」は意味が異なります。混同したまま進めると、方針がぶれたり予算を超えたりする原因になります。
基幹システム・ERPの定義と業務への影響範囲
基幹システムとは、企業の中核業務を支える情報システムの総称です。具体的には、会計・財務管理と販売管理を代表に、次のような業務領域を指します。
- 在庫・購買管理
- 生産管理
- 人事・給与管理
ERP（Enterprise Resource Planning：統合基幹業務システム）は、これらの業務を統合して管理するパッケージです。企業の規模によって、代表的な製品は次のように分かれます。
- 大手向けのパッケージ：SAP S/4HANA、Oracle EBS・Fusion Cloud、Microsoft Dynamics
- 中小企業向けのクラウド製品：弥生・奉行クラウド
基幹システムの特徴は、企業のほぼ全部門がシステムに依存して業務を行っている点です。販売部門が受注を入力し、在庫部門が出荷指示を受け取り、経理部門が請求・入金を処理する一連の流れが、すべてシステム上で完結します。
このため、システムが止まると業務全体が停止するリスクがあり、更改プロジェクトは「会社全体が参加する大規模案件」となります。調査会社IDCのレポートによれば、ERP導入・更改プロジェクトの平均期間は18ヶ月〜36ヶ月で、大企業では5年以上かかることも珍しくありません。
ERP更改・バージョンアップ・新規導入の違い
「更改」とは、現行システムから別のシステムへ乗り換えること、あるいは同一製品のメジャーバージョンを刷新することを指します。一方「バージョンアップ」は、同一製品内のマイナーアップグレードや保守更新を指し、工数・費用ともに更改より小さく済むことが多いです。「新規導入」は、これまでシステムを持たなかった業務領域に初めてERPを入れるケースです。
更改が必要になる典型的なタイミングとして、ベンダーのサポート期限切れ（SAP ECC 6.0は2027年にメインストリームサポートが終了）が挙げられます。ほかにも、ビジネスモデルの変化に現行システムが追いつかない状況、M&A後のシステム統合ニーズ、クラウド化・デジタルトランスフォーメーション推進などがあります。
特にSAP ECC利用企業は2027年問題として更改を急ぐケースが多く、適切な計画がないまま急ぐと失敗するリスクが高まっています。
基幹システム/ERP更改プロジェクトの全体像と進め方【7ステップ】
ERP更改プロジェクトは、明確な7つのステップに沿って進めることで、スコープのブレや手戻りを最小化できます。
各ステップには固有のリスクと成功のポイントがあります。特に、Step2のFit to Standard方針策定とStep5のUATは、全体の成否を左右する最重要フェーズです。
- Step1：現状分析と課題の洗い出し
- Step2：Fit to Standardの視点で更改方針を策定
- Step3：RFI/RFPの作成とベンダー選定
- Step4：要件定義と設計（Fit to Gap分析）
- Step5：開発・テスト（UAT）
- Step6：データ移行と本番切替
- Step7：初期流動管理とリリース後安定化
Step1 現状分析と課題の洗い出し
最初のステップでは、現行システムの業務範囲・データ量・インターフェース数・カスタマイズ量を洗い出します。そのうえで、「現行システムで何ができて、何ができないか」「どの業務課題がシステム起因で、どれが業務プロセス起因か」を切り分けます。この区別ができないまま要件定義に進むと、業務課題の解決をすべてシステムに求めてしまい、過剰なカスタマイズ要求につながります。
現状分析では、帳票・画面・インターフェースの一覧、業務フロー図、データ移行対象の確認を並行して行います。特に注意が必要なのが「現場のシャドーIT」で、EXCELマクロや独自ツールで補完されている業務は想定以上に多いケースも珍しくありません。これを見落とすと、移行後に業務が回らなくなります。
その把握には、現場ヒアリングと実際のPC画面確認を組み合わせたアセスメントが有効です。また、現行システムのカスタマイズ数と工数を試算しておけば、今後も同じカスタマイズを繰り返すコストを経営陣に示せるため、Fit to Standard移行の説得材料になります。
Step2 Fit to Standardの視点での更改方針策定
方針策定フェーズでは、「Fit to Standard（業務をシステムに合わせる）」と「Fit to Gap（システムを業務に合わせる）」のどちらの姿勢で進めるかを、経営レベルで決定します。この方針が曖昧なまま進むと、現場部門からのカスタマイズ要求が際限なく膨らみ、プロジェクト費用が当初見積もりの2〜3倍に膨張します。
Gartnerの調査によれば、ERP導入失敗の最大要因の1つは「過剰なカスタマイズ」で、カスタマイズが多いほどスケジュール遅延やコスト超過のリスクが高まるとされています。そのため、経営会議で方針を承認してもらうには、「カスタマイズを行うと初期費用が1件あたり平均300万〜500万円増加し、バージョンアップのたびに再対応コストが発生する」といった具体的な数字で示すのが効果的です。
また、SAP・Oracle等のERPパッケージが持つ「業界標準のベストプラクティス」を活用できるのは、Fit to Standardを採用した場合に限られます。カスタマイズ過多になると、競合他社と同じERPを使いながら標準機能の恩恵を受けられないという矛盾が生じます。
Step3 RFI/RFPの作成とベンダー選定
RFI（情報提供依頼書）では、候補ERPパッケージの機能範囲・対応業種・価格帯・導入実績を広く集め、自社の規模・業種・予算に合うものを絞り込みます。大手のSAP・Oracle・Microsoft Dynamicsは大企業向けで、費用が数億円規模になることが多いです。一方、マネーフォワードクラウドERP・弥生・奉行クラウド・freeeは中小企業向けに、月額数万円〜数十万円のSaaS型製品です。
RFP（提案依頼書）では、現状の業務フロー・課題・非機能要件（性能・可用性・セキュリティ）・データ移行方針・プロジェクト推進体制の要求事項を明文化します。ベンダー選定で見落としがちな評価軸は、「Fit to Standardを積極的に推奨する提案をしているか」です。
カスタマイズを多く提案するベンダーは、受注金額を増やす狙いで勧めている場合があり、注意が必要です。そのため、「なぜこのカスタマイズが必要なのか、標準機能で代替できないか」を必ず問い返してください。同業種・同規模の導入実績も確認し、可能であれば参照先企業へのヒアリングを設けることをお勧めします。
Step4 要件定義と設計（Fit to Gap分析）
要件定義フェーズでは、選定したERPパッケージの標準機能と自社業務のギャップ（Gap）を分析する「Fit to Gap分析」を行います。この分析では、各業務プロセスを標準機能で対応できるか（Fit）、カスタマイズが必要か（Gap）を判定します。
Fit to Standardを徹底するなら、Gapが出た際にまず業務プロセスを標準機能に合わせて変えることを検討し、必然性がある場合にだけカスタマイズを認めます。この判断基準を明確にしないと、現場の要望がすべて「カスタマイズ必須」として上がってきます。経験則では、要件定義段階で挙がるGap要件の6〜7割は業務プロセスの見直しで対応でき、実際にカスタマイズが必要なのは2〜3割程度とされています。
業務プロセスオーナーを決め、「このプロセスをシステムに合わせた場合のメリット・デメリット」を整理する場を設けると、現場の合意形成と過剰カスタマイズの抑制を同時に進められます。要件定義書・基本設計書・詳細設計書の3段階でドキュメントを整備し、特に基本設計書は、ベンダーと発注者の双方が署名する形で合意を取り付けてください。
Step5 開発・テスト（UATの成功/失敗事例付き）
開発フェーズでは、カスタマイズ開発・設定パラメータ調整・インターフェース開発・帳票開発を並行して進めます。テストは、単体テスト・結合テスト・システムテスト・ユーザー受入テスト（UAT）の順に実施し、中でもUATはプロジェクト全体の品質を大きく左右します。UATの成功事例としては、大手流通企業の取り組みが参考になります。
この企業では、テストシナリオの作成段階から、各部門の業務に精通した現場のキーユーザーを巻き込み、月1回の現場参加型ワークショップを計6回実施しました。ベンダー主導のシナリオに現場の業務知識を掛け合わせたことで、例外ケース・エラーケースを網羅的にカバーでき、「導入初日からフル稼働、手戻りゼロ」を実現しました。本番稼働後の問い合わせ件数も従来比70%減を達成しています。
一方、UAT失敗の典型は、「ベンダーが作成したテストシナリオを現場がただ実行するだけ」の受動的なUATです。この場合、現場特有の業務フローや例外処理が見落とされ、本番稼働後に大量の障害・手戻りが発生します。
Step6 データ移行と本番切替（コンティンジェンシープラン）
データ移行は、ERP更改プロジェクトで最も技術的難易度が高いフェーズの一つです。移行は、データのクレンジング（名称統一・重複排除・コードマスタ整備）から始まり、移行ツールの開発、移行リハーサル（本番同等データでの移行テスト）、本番移行の順に進みます。
移行リハーサルは最低2〜3回実施し、切替当日の移行手順書（タスクリスト形式）を整えておくことが欠かせません。本番切替では必ずコンティンジェンシープラン（切り戻し計画）を策定し、切り戻し判断の時点、手順と所要時間、判断権限者（通常はプロジェクトオーナー）を事前に明文化しておきます。
本番切替の典型的な形式には、旧システムと新システムを一定期間並行稼働させる「並行稼働切替」と、特定日に一括切替する「一斉切替（ビッグバン方式）」があります。並行稼働は安全ですが、二重入力のコストがかかります。一斉切替はリスクが高い一方でコストを抑えられるため、業務規模とリスク許容度に応じて選びます。
Step7 初期流動管理とリリース後安定化
本番稼働直後の1〜3ヶ月間は「初期流動管理期間」と位置づけ、集中的なサポート体制を敷くことが成功の鍵です。製造業では、新製品の量産開始直後を「初期流動管理」と呼び、品質保証部門が通常より密に製造工程を監視して、問題の早期発見・早期対処を図ります。ERP更改でも同様の考え方が有効です。
具体的には、本番稼働後の問い合わせや障害に対し、「まず暫定対応で業務を継続し、その後に根本対応（プログラム修正）を行う」という2段階で対処します。障害への対応を急ぐあまり業務が止まってしまうのが、最悪のシナリオです。
そこで、EXCELでの一時的な手作業など代替処理で業務を止めない暫定対応を先に行い、業務が動いた状態でじっくり根本対応を検討・実施します。これにより、障害の影響範囲を最小化できます。また、キーユーザーによる社内ヘルプデスク体制の整備やFAQ集の作成・共有も並行して進め、現場の不安解消と問い合わせの分散を図ります。
Fit to Standard vs Fit to Gap｜カスタマイズ判断の実践的考え方
ERP更改プロジェクトにおいて、カスタマイズの判断はコスト・スケジュール・将来の保守性に直結する重大な意思決定です。
「Fit to Standard」と「Fit to Gap」の違いを正しく理解し、現場と経営の双方が納得できる判断基準を持つことが、プロジェクト成功の前提条件となります。
Fit to Standardで業務プロセスをシステムに合わせる理由
SAP・Oracle・Microsoft DynamicsといったERPパッケージには、世界中の企業の業務ノウハウを集約した「業界標準のベストプラクティス」が内蔵されています。Fit to Standardとは、自社の業務プロセスをこの標準機能に合わせ、グローバルな業務標準を自社に取り込む戦略です。コスト削減の策にとどまらず、業務品質そのものを引き上げる取り組みでもあります。
ベンダー選定でFit to Standardを評価する実践的な基準は、「カスタマイズ要求に対して、標準機能での代替案を積極的に提案しているか」という視点です。たとえば、優れたSIerやERPコンサルタントは、現場からカスタマイズ要求が上がると「なぜその業務がこのやり方でなければならないのか」を問い直し、標準機能での業務再設計案を示します。
一方、カスタマイズを積極的に受け入れるベンダーは、受注金額を増やす動機があるため、長期的なパートナーシップの観点では注意が必要です。Fit to Standardを推進するベンダーを「改善提案がない」と見るより、「長期的なコスト抑制と保守性向上に貢献してくれる」と評価する視点を持つことが大切です。
カスタマイズが引き起こすコスト増・バージョンアップ問題
カスタマイズが引き起こす最大の問題は、バージョンアップ時のコスト増と移行の困難さです。たとえば、メジャーバージョンアップ（SAP ECC→S/4HANAへの移行など）では、カスタマイズが多いほど「再テスト・再修正」の工数が膨大になります。
カスタマイズ1件あたりのバージョンアップ対応コストを試算すると、開発費用と同等以上の費用が発生することも珍しくありません。その結果、「バージョンアップできないシステム」が生まれ、次の更改プロジェクトでさらに大きな課題を抱え込む悪循環に陥ります。承認基準として実務でよく使われるのが、「3C基準」です。
3C基準は、Competitive Advantage（競争優位性を生むか：差別化できる独自業務なら許容）と、Compliance（法令・規制対応か：税制・労務管理等は標準機能外でも必須）です。3点目は、Core Business Process（代替不可な中核業務か）です。いずれにも該当しない場合は、標準機能に業務を合わせます。要件定義で明文化すると、現場の感情的な要求を整理しやすくなります。
プロジェクトが炎上したときの立て直し・撤退判断
ERP更改は規模が大きいだけに、一度炎上すると被害が甚大になりがちです。ただし、早期に炎上の兆候を察知して適切なリカバリーを取れれば、プロジェクトを軌道修正できる可能性は十分にあります。
状況によっては「損切り・撤退判断」も、経営上の合理的な選択肢として持っておく必要があります。
炎上の兆候チェックリスト
炎上に向かうプロジェクトには、たいていの場合、共通のサインが現れます。下の5つのうち複数が当てはまるときは、プロジェクトの状況を見直す必要があります。
- スコープが要件定義後も際限なく拡大し、スケジュールが後ろ倒しになり続けている
- 週次の進捗会議でベンダーの報告が「課題対応中」ばかりで解決策が見えず、課題管理表（Issueリスト）の未解決件数も増え続けている
- テストフェーズで摘出されるバグ数が、当初見積もりを大幅に超えている
- ベンダー担当者が頻繁に変わり、ナレッジの継承が途切れている
- 発注者側の現場部門からベンダーへの不満が噴出し始めていて、コスト超過が見込まれるのに報告が上がってきていない
そのような場合は、第三者（PMO・独立系コンサルタント）によるプロジェクトアセスメントを早急に実施することを勧めます。プロジェクト内部だけで問題を抱えると、客観的な判断が難しくなるためです。
ベンダー切替・損切り基準の考え方
炎上プロジェクトの立て直しでは、まず「継続か撤退か」の判断が必要です。継続する場合は、スコープを大幅に削り、業務に必要な最低限の機能から稼働させる「フェーズ分割方式」が有効です。
全機能を一度に稼働させようとすると炎上しやすいため、「コアモジュールだけで第1フェーズ稼働→追加モジュールを第2フェーズで追加」と段階的に切り替えることで、立て直せる場合があります。ベンダー切替・損切りの判断基準の一つは、投入済みコストと追加投入コストの合計が、新規ベンダーでやり直す場合の総コストを超えるかどうかです。
ただし、既存ベンダーへの切替コスト（引き継ぎ・ドキュメント整備・新規立ち上げ工数）を過小評価しないことが重要です。また、既存ベンダーとの契約（遅延ペナルティ・解除条件）を確認し、法務部門・弁護士と連携して進めることを推奨します。撤退判断を支えるため、開始時から「判断閾値（コスト超過率・スケジュール遅延月数）」を経営レベルで定めておくのが理想的です。
中小企業向け｜クラウド型ERPを活用した現実的な更改ロードマップ
大企業向けERPの進め方をそのまま中小企業に当てはめると、リソース不足や予算不足で頓挫するケースが多くあります。専任の情報システム部門がなく、ERPプロジェクトを主導できる社内人材もいないことは、中小企業では当たり前です。そうした状況でも進められる現実的なアプローチを紹介します。
SaaS型ERPを活用した段階的刷新アプローチ
中小企業に適したERP更改の第一歩は、SaaS型（クラウド型）ERPを活用した段階的な刷新です。マネーフォワードクラウドERP・freee・弥生クラウド・奉行クラウドといったSaaS型製品は、初期費用を大幅に抑えられ（多くは初期費用ゼロ〜数十万円程度）、月額数万円〜数十万円の範囲でスタートできます。
オンプレミス型のSAP・Oracleが数千万〜数億円の初期投資を必要とするのと比べると、中小企業にとって現実的な選択肢です。段階的な刷新では、まず最も痛みの大きい業務領域（たとえば会計・財務）からSaaS型ERPを導入し、他の業務は既存システムやEXCELとAPI連携でつないで運用します。
次のフェーズで販売管理・在庫管理をSaaS型に移し、最終的に全業務をSaaS型ERP上に統合する、3フェーズ構成が現実的です。1フェーズを3〜6ヶ月に抑えると、現場の疲弊を防ぎながら着実に刷新を進められます。専任情シスが不在でも進められるよう、月間20〜40時間程度の担当者工数を確保し、外部コンサルタントを活用してスコープを絞ります。
SIer×フリーランスのハイブリッド活用
中小企業のERP更改では、「すべてをSIerに一括委託する」より、「SIer×フリーランスのハイブリッド活用」のほうが費用対効果に優れています。SIerは要件定義・設計・プロジェクト管理といった上流工程と品質保証に強みがあります。一方、フリーランスのERP専門家は、スポット的な技術支援・設定支援・ユーザートレーニングで活躍します。
フェーズ別では、企画・要件定義で外部コンサルタント（フリーランス可）が業務整理とRFP作成を支援します。設計・開発・テストはSIerが主導してプロジェクト管理と品質担保を行い、稼働後の定着支援では、再びフリーランス人材が操作トレーニング・FAQ整備・改善提案を担う構成が効果的です。
SIerへの一括委託と比べて、コストを20〜30%程度抑えられることもあります。ただし、SIerとフリーランス間の情報共有・役割調整（コーディネーション）は発注者側が担うため、プロジェクト責任者の工数確保が欠かせません。フリーランスを使う場合は、特定の個人に依存するリスクを抑えるため、ドキュメント整備と知識移転を契約条件に明記することをお勧めします。
まとめ
ここまで、基幹システム・ERP更改の進め方を7つのステップに沿って解説し、ERP特有の課題であるFit to Standardとカスタマイズコントロールについても、SIerとの実務経験をもとに説明してきました。
最も重要なポイントを改めて整理します。ERP更改の成否を決める最大の要因は、「Fit to Standard方針を経営レベルで確立し、現場のカスタマイズ要求をコントロールできるか」です。
カスタマイズは、プロジェクトコストの膨張と将来のバージョンアップ困難の最大要因です。そのため、ベンダー選定の段階からFit to Standardを推進する姿勢を持つパートナーを選ぶことが大切です。
UATは現場のキーユーザーを能動的に巻き込んだ参加型で実施することで、本番稼働後の品質と現場定着率を大幅に高められます。
中小企業の場合は、SaaS型ERPを活用した段階的刷新と、SIer×フリーランスのハイブリッド活用が、現実的で費用対効果の高いアプローチです。
プロジェクトが炎上の兆候を見せている場合は、継続・撤退の判断基準を事前に設定しておくことで、経営判断をスムーズに行えます。
本記事で解説した内容を参考に、貴社のERP更改プロジェクトを成功に導いていただければ幸いです。具体的な進め方や費用見積もりについてのご相談があれば、お気軽に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を創業。