基幹システム/ERP更改で見直すべき機能・対象範囲の一覧について

長年使い続けてきた基幹システムやERPが、ハードウェアの保守期限切れ、ソフトウェアのサポート終了、保守契約の満了といったタイミングを迎え、「そろそろ更改（入れ替え）を検討しなければならない」という局面に立たされている企業は少なくありません。基幹システム/ERPの更改は、まったくの新規開発とは異なり、すでに業務が回っている現行システムを止めずに作り替えるという難しさを伴います。経済産業省のDXレポートが指摘した「2025年の崖」では、老朽化したシステムを放置した場合に2025年以降で年間最大12兆円もの経済損失が生じるリスクが示されており、日本情報システム・ユーザー協会（JUAS）の調査でも約7割の企業が既存システムの老朽化を経営課題と認識しています。

とはいえ、いざ更改に着手しようとすると、「現行システムのどこまでを見直し、どの範囲を作り替えるべきか」「すべてを一度に刷新すべきか、それとも一部だけで済むのか」が見えず、判断に迷うケースが大半です。本記事では、基幹システム/ERP更改で見直すべき機能・対象範囲の一覧を、(A)更改の対象範囲をどう切るかという「7R」の手法一覧、(B)基幹/ERPで実際に見直すべき機能領域の一覧、という2つの軸で体系的に整理します。手法選定から費用感、進め方の選択肢までを俯瞰したい場合は、基幹システム/ERP更改の完全ガイドもあわせてご覧いただくと、本記事の各論を全体像の中で位置づけやすくなります。

▼全体ガイドの記事
・基幹システム/ERP更改の完全ガイド

更改の対象範囲をどう切るか：7Rの手法一覧と使い分け

基幹システム/ERPの更改で最初に決めるべきは、「現行システムのどの範囲を、どこまで作り替えるか」という対象範囲の切り方です。クラウド移行の世界では、この移行戦略を整理する枠組みとして「7R」が広く知られています。7Rは、現行資産を一律に扱うのではなく、システムやサブシステムごとに最適な手法を選び分けるための共通言語として機能します。

本章では、まずAWSが提唱する7つの移行戦略（7R）を一覧で整理し、続いて日本のIPA（情報処理推進機構）が示すマイグレーション4分類との対応を確認します。そのうえで、単一の手法に固執せず機能ごとに使い分ける「ポートフォリオアプローチ」の重要性を解説します。手法の名前だけを覚えるのではなく、それぞれが「どの対象範囲に、どんな費用・期間で適用できるか」を押さえることが、更改計画の精度を大きく左右します。

AWSが提唱する7Rは、現行システムをどう移行・更改するかの選択肢を7つに整理したものです。それぞれ作り替えの度合いが異なり、対象範囲・費用・期間・適したケースが変わってきます。まずは7つの手法を一覧で押さえましょう。

・Rehost（リホスト）：アプリケーションをほぼ変更せず、そのまま別の基盤へ移設する「リフト&シフト」。対象範囲＝OS・ミドルウェアより上をそのまま移す。費用・期間が小さく、スピード重視の更改に向きます。
・Relocate（リロケート）：仮想化基盤などを単位として、構成をほぼ変えずにまとめて再配置する手法。大量のサーバーを短期間で移したい場合に有効です。
・Replatform（リプラットフォーム）：アプリの主要構造は維持しつつ、OSやデータベース、実行基盤だけを新しいものへ載せ替える「リフト・ティンカー&シフト」。マネージドサービスの活用で運用負荷を下げられます。
・Repurchase（リパーチェス）：既存の自社開発システムを廃し、SaaSやパッケージ製品に置き換える手法。ERP更改ではS/4HANAなどパッケージへの乗り換えがこれに該当します。
・Refactor（リファクタ／リアーキテクト）：要件に合わせてアプリを作り直す手法。費用・期間は最大ですが、拡張性や保守性を抜本的に高められます。
・Retire（リタイア）：使われていない、または役割を終えた機能・システムを廃棄する。棚卸しの結果として対象範囲から外す判断です。
・Retain（リテイン）：あえて現状維持し、当面は更改しないと決める。移行効果が薄い、または依存が強すぎる機能に適用します。

更改で見落とされがちなのが、最後のRetire（廃棄）とRetain（現状維持）です。「すべてを移行・刷新しなければならない」と思い込みがちですが、実際には使われていない機能を廃棄したり、移行効果の薄い領域をあえて残したりする判断こそが、コストとリスクを抑える鍵になります。7Rは「何を作り替えるか」だけでなく「何を作り替えないか」を決める枠組みでもあるのです。

日本ではIPA（情報処理推進機構）が、マイグレーションの手法を「リビルド」「リライト」「リホスト」「ハードウェア更改」の4分類で整理しています。これは7Rとは別系統の枠組みですが、対応関係を押さえると更改手法の全体像がより立体的に見えてきます。

・ハードウェア更改：老朽化したサーバーなどの機器を、ソフトはほぼそのままに新機器へ載せ替える。7RのRehost／Relocateに近い、最も軽い更改です。
・リホスト：プログラムを変更せず、新しい基盤上で動かす。7RのRehostに対応し、短期・低コストが特徴です。
・リライト：既存の処理ロジックを保ちつつ、古い言語を新しい言語へ書き換える。7RのReplatformとRefactorの中間に位置づけられます。
・リビルド：業務要件を見直し、新しい設計でゼロから作り直す。7RのRefactor／Repurchaseに対応する、最も重い更改です。

費用と期間の目安も手法によって大きく異なります。クラウド移行型（リホスト・ハードウェア更改など）は、おおむね数百万〜1,000万円台で、期間は3〜6ヶ月程度が目安です。一方、再構築型（リビルド・大規模なRefactorなど）は2,000万〜数千万円規模、期間も12〜18ヶ月以上に及ぶことが珍しくありません。

中堅・中小規模の基幹システム/ERP更改では、全体としておおむね3,000万〜1.5億円のレンジに収まるケースが多く、そのうちシステムインテグレーション（SI）費用が全体の60〜75％程度を占める傾向にあります。手法を選ぶ際は、この費用・期間レンジを念頭に、「更改で得たい効果に対して投資が見合うか」を対象範囲ごとに見極めることが重要です。

基幹システム/ERP更改で陥りやすい失敗が、「すべてをリビルドで作り直す」あるいは「すべてをリホストで移すだけ」といった単一手法への偏りです。基幹システムは販売管理・会計・在庫・人事など複数のサブシステムの集合体であり、それぞれ老朽化の度合いも業務上の重要性も異なります。一律の手法を当てはめると、過剰投資や効果不足が生じやすくなります。

そこで有効なのが、機能・サブシステムごとに7Rを使い分ける「ポートフォリオアプローチ」です。たとえば、競争力に直結する独自の生産管理はRefactorで作り込み、汎用的な会計はRepurchaseでSaaS・パッケージへ置き換え、当面変える必要のない周辺機能はRetainで残す、といった具合に対象範囲ごとに最適な手法を割り当てます。

ERP更改の文脈で象徴的なのが、SAPの「2027年問題」です。SAP ERP（ECC6.0）の標準保守が2027年末で終了し、その後はS/4HANAへの移行が求められます。ここで「パッケージ標準へ寄せるRepurchaseを取るのか、独自要件を残してRefactorで作り込むのか」という判断が問われます。ポートフォリオの発想で、標準化できる領域はRepurchase、譲れない競争領域だけRefactor、と切り分けることが現実的な解になります。

基幹/ERP更改で見直すべき機能領域の一覧

手法の枠組みを押さえたら、次は「具体的にどの機能領域を見直すか」を一覧で確認します。基幹システム/ERPは多数の業務モジュールから構成されており、更改の際にはそれぞれの領域で「現行のまま移すのか、標準機能に合わせて見直すのか」を判断する必要があります。本章では、更改で必ず点検すべき主要な機能領域を、業務モジュール・周辺連携・非機能の3つの観点から整理します。

基幹システム/ERPの中核を成すのが、各業務領域を支えるモジュール群です。更改で見直すべき代表的な機能領域を一覧で挙げると、次のようになります。

・販売管理：受注・出荷・売上・請求・債権管理。商習慣に依存したカスタマイズが溜まりやすい領域です。
・購買・在庫管理：発注・入荷・在庫引当・棚卸。在庫評価方法や引当ロジックの見直しが論点になります。
・生産管理：所要量計算（MRP）・工程管理・原価計算。製造業では競争力に直結し、独自要件が多い領域です。
・会計／財務：総勘定元帳・債権債務・固定資産・原価。制度対応が必要で、標準化しやすい領域でもあります。
・人事給与：勤怠・給与計算・社会保険・人事情報。法改正対応の頻度が高く、SaaS化が進む領域です。

これらのモジュールを見直す際の基本姿勢が、「Fit to Standard（業務を標準機能に合わせる）」という考え方です。従来は自社業務に合わせてシステムをカスタマイズするのが一般的でしたが、更改を機に発想を反転させ、パッケージやSaaSの標準機能に業務側を寄せることで、過剰なアドオンを削減できます。

とくに会計・人事給与のように制度で型が決まっている領域は、標準機能で十分対応できるケースが多く、Repurchase（SaaS・パッケージ置換）の好適領域です。一方で、生産管理や独自の販売プロセスなど競争優位の源泉となる領域は、安易に標準へ寄せず、必要に応じてRefactorで作り込む判断も必要になります。モジュールごとに「標準化するか作り込むか」を切り分けることが、見直しの第一歩です。

更改の対象範囲を考えるとき、業務モジュール本体に目が向きがちですが、実際にプロジェクトを難航させるのは周辺機能であることが少なくありません。見直すべき周辺領域を一覧で挙げると次のとおりです。

・外部システム連携：EDI（電子データ交換）、会計システム、BIツール、ECサイトなどとのインターフェース。
・夜間バッチ処理：締め処理・集計・データ連携など、夜間にまとめて実行される処理群。
・帳票：請求書・納品書・各種管理帳票など、出力フォーマットが業務に密着した部分。
・マスタ／データ構造：取引先・商品・勘定科目などのマスタ設計と、それを支えるデータモデル。

とくに外部連携と夜間バッチは、現行システムの「見えない依存関係」が集中する領域です。長年の運用で追加されたEDI連携や夜間バッチは、ドキュメントが残っていないことも多く、更改時に思わぬ手戻りを生みます。だからこそ、更改の初期に資産の棚卸しを行い、どの連携・バッチが今も本当に必要かを洗い出すことが欠かせません。

マスタとデータ構造の見直しも、更改の成否を左右する重要な対象範囲です。現行のマスタには、すでに使われていないコードや重複データが蓄積していることが多く、それをそのまま新システムへ移行すると、せっかくの更改が「汚れたデータを引き継いだ新システム」で終わってしまいます。データクレンジングを更改の対象範囲に明確に含めておくことが、品質確保の前提になります。

更改で最も効果が大きい見直し対象のひとつが、長年積み上がった「アドオン（追加開発機能）」の棚卸しです。基幹システムは運用年数が長くなるほど、現場の要望に応えて作られた個別機能が増え、保守を圧迫していきます。更改は、この過剰なカスタマイズを一度リセットする絶好の機会です。

棚卸しの際は、各アドオンについて「標準機能で代替できないか」「そもそも今も使われているか」を一件ずつ判定します。標準で代替できるものはRetire（廃棄）して標準機能に寄せ、使われていないものは思い切って削除する。これにより、移行対象そのものを減らし、更改の費用・期間・リスクを同時に圧縮できます。Fit to Standardの考え方は、ここで具体的な棚卸し作業として実を結びます。

あわせて見直したいのが、権限管理と内部統制に関わる機能です。更改では、誰がどの機能・データにアクセスできるかという権限設計を再構築する必要があり、これは内部統制（職務分掌や承認フロー）の観点からも重要です。新しい基盤の標準的な権限管理機能を活用すれば、属人的になりがちだった権限運用を整理し、統制の効いた状態へと刷新できます。見直すべき機能領域の一覧の締めくくりとして、この非機能・統制領域も対象範囲に必ず含めておきましょう。

対象範囲の決め方：棚卸しから手法割り当てまでの流れ

ここまで「7Rの手法一覧」と「見直すべき機能領域の一覧」を見てきました。最後に、これらを実際の更改計画へ落とし込む流れを整理します。対象範囲は感覚で決めるものではなく、棚卸し・分類・手法割り当てという段階を踏んで論理的に確定させていきます。

対象範囲を決める出発点は、現行システムの資産棚卸しです。どんな機能・サブシステム・データ・外部連携・夜間バッチが存在し、それぞれが現在どの程度使われているかを洗い出します。この可視化を飛ばして手法を先に決めてしまうと、不要な機能まで移行対象に含め、費用と期間を無駄に膨らませることになります。

棚卸しでは、機能ごとに「利用頻度」「業務上の重要度」「老朽化の度合い」「外部依存の強さ」といった軸で評価します。この評価結果が、後段の手法割り当ての判断材料になります。とくに「使われていないのに残っている機能」を可視化できれば、それだけでRetire（廃棄）候補が明確になり、対象範囲を効果的に絞り込めます。

棚卸しで対象範囲を可視化したら、機能・サブシステムごとに7Rのいずれかを割り当てていきます。たとえば、標準化できる会計・人事給与はRepurchase、競争領域の生産管理はRefactor、当面変えない周辺機能はRetain、使われていない機能はRetire、という具合に、ポートフォリオとして手法を配分します。これにより、全体を一律で扱うよりも投資効率の高い更改計画が組み立てられます。

手法を割り当てたら、移行の進め方も対象範囲ごとに設計します。全社を一度に切り替える「ビッグバン」型はトラブル時の影響が大きいため、機能や対象を区切って段階的に置き換えていく進め方が現実的です。サブシステム単位で7Rを割り当てておけば、優先度の高い領域から順に更改を進める段階移行とも自然に整合します。

このように、「見直すべき機能・対象範囲の一覧」を起点に、棚卸し→分類→手法割り当て→段階移行という流れを踏むことで、更改の全体像が論理的に組み上がります。手法や機能の一覧は、それ自体が目的ではなく、自社の対象範囲を過不足なく切り出すための道具として活用することが大切です。

まとめ

本記事では、基幹システム/ERP更改で見直すべき機能・対象範囲の一覧を、2つの軸で整理してきました。第一の軸である更改手法では、AWSの7R（Rehost・Relocate・Replatform・Repurchase・Refactor・Retire・Retain）と、IPAの4分類（リホスト・リライト・リビルド・ハードウェア更改）を一覧で対応づけ、クラウド移行型は数百万〜1,000万円台で3〜6ヶ月、再構築型は2,000万〜数千万円で12〜18ヶ月以上という費用・期間の目安を確認しました。第二の軸である機能領域では、販売・購買在庫・生産・会計・人事給与といった業務モジュールに加え、外部連携・夜間バッチ・帳票・マスタ、そして過剰アドオンの棚卸しや権限・内部統制までを対象範囲として整理しました。

更改を成功させる鍵は、単一の手法に頼らず、機能・サブシステムごとに7Rを使い分ける「ポートフォリオアプローチ」にあります。標準化できる会計・人事給与はRepurchaseで標準機能に寄せ（Fit to Standard）、競争領域はRefactorで作り込み、使われていない機能はRetireで廃棄する。SAPの2027年問題に象徴されるように、ERP更改では「標準へ寄せるか作り込むか」の見極めが問われますが、対象範囲を切り分けて手法を配分すれば、現実的な解にたどり着けます。

自社の基幹システム/ERP更改を検討する際は、まず資産の棚卸しで現状を可視化し、本記事の機能領域一覧と照らし合わせて「どこを見直すか」を整理することをおすすめします。そのうえで、各領域に7Rを割り当て、段階的な移行計画へと落とし込んでください。手法や費用感の全体像をより体系的に把握したい場合は、完全ガイドもあわせて活用いただくと、対象範囲の判断をより確かなものにできます。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。