基幹システム/ERP更改の対象範囲は、7Rの手法、見直す機能領域、資産棚卸しの結果に応じて切り分けると、現実的な更改計画につながります。
7Rで作り替え方を分け、見直す機能領域を一覧で押さえ、棚卸しから段階移行までの流れをたどると、更改の全体像がつかめます。
▼全体ガイドの記事
・基幹システム/ERP更改の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
更改の対象範囲をどう切るか：7Rの手法一覧と使い分け
長年使う基幹システムやERPは、ハードウェアの保守期限切れやソフトのサポート終了、保守契約の満了を迎え、更改を迫られる企業も少なくありません。経済産業省のDXレポートは、老朽システムを放置すると2025年以降に年間最大12兆円の経済損失が生じるリスクを示しました。
日本情報システム・ユーザー協会（JUAS）の調査では、約7割の企業が既存システムの老朽化を経営課題と認識しています。
基幹システム/ERP更改では、現行システムのどの範囲を作り替えるかを、最初に決めておく必要があります。ただ、どこまでを見直すか、すべてを一度に刷新するか一部で済ませるかは見えにくく、判断に迷うケースが大半です。
対象範囲は、7Rの手法と機能領域の2軸で整理すると、更改の見通しが立ちます。手法選定から費用感、進め方の選択肢までを俯瞰したい場合は、基幹システム/ERP更改の完全ガイドもご覧ください。この記事の各論は、完全ガイドと合わせて読むと全体の中での位置づけがわかります。
クラウド移行の戦略を整理する枠組みとして、7Rが広く知られています。7Rは、現行資産を一律に扱わず、システムやサブシステムごとに手法を選ぶための共通言語です。
AWSの7つの移行戦略と、IPAのマイグレーション4分類との対応を順に見ていきます。機能ごとに手法を使い分けるポートフォリオアプローチの重要性にも触れます。
各手法は、対象範囲や適したケース、費用・期間が異なるため、適用条件を押さえることが更改計画の精度を左右します。
AWSの「7R」：7つの移行戦略の一覧
AWSの7Rは、現行システムの移行・更改方法を作り替えの度合いで分類したものです。まずは7つの手法を一覧で確認します。
- Rehost（リホスト）：ほぼ変更せず、別の基盤へ移す方式。
- Relocate（リロケート）：仮想化基盤などを単位とした再配置。
- Replatform（リプラットフォーム）：主要構造を保ったままの基盤の載せ替え。
- Repurchase（リパーチェス）：自社開発からSaaSやパッケージへの置き換え。
- Refactor／Retire／Retain：要件に合わせた作り直し、廃棄、現状維持の選択肢。
Rehostは、アプリをほぼ変更せず、OS・ミドルウェアより上を別の基盤へ移す方法です。「リフト&シフト」とも呼ばれ、費用・期間が小さく、スピード重視の更改に向きます。とくに、大量のサーバーを短期間で移したい場合に有効です。
Replatformで載せ替える対象には、OSやデータベース、実行基盤が含まれます。別名を「リフト・ティンカー&シフト」といい、マネージドサービスで運用負荷を下げられます。
ERP更改では、S/4HANAなどのパッケージへ乗り換えるケースが、Repurchaseに当たります。Refactorは費用・期間が最も大きい一方で、拡張性や保守性を抜本的に高められます。
Retireは、使われていない機能や役割を終えたシステムを廃棄する判断です。棚卸しの結果、対象範囲から外す場合に選びます。
Retainは、移行効果が薄い領域や、依存が強すぎる機能を当面残す判断です。更改では、RetireとRetainが見落とされがちです。
すべてを刷新せず、不要な機能を廃棄し、効果の薄い領域は残すという判断もできます。こうした選択が、更改のコストとリスクを抑える鍵になります。7Rは、作り替える対象だけでなく、作り替えない対象も決める枠組みです。
IPAの4分類と費用・期間の目安の対応
IPA（情報処理推進機構）は、マイグレーションを4つの手法に分類しています。
- ハードウェア更改：老朽サーバーなどを、ソフトはほぼそのままに新機器へ載せ替える。
- リホスト：プログラムを変えず、新しい基盤の上で動かす方式。
- リライト：処理ロジックを保ったまま、古い言語の部分を書き換える。
- リビルド：業務要件を見直したうえで、新しい設計で作り直す方式。
この4分類は7Rとは別の系統ですが、対応関係を押さえると、更改手法の全体像を立体的に捉えられます。ハードウェア更改は7RのRehost／Relocateに近く、最も軽い更改です。
リホストは7RのRehostに対応し、短期・低コストが特徴です。リライトは7RのReplatformとRefactorの中間に位置づけられます。最も重いのはリビルドで、7RのRefactor／Repurchaseに対応します。
クラウド移行型の費用は、おおむね数百万〜1,000万円台が目安です。リホストやハードウェア更改などが該当し、期間は3〜6ヶ月程度です。
一方、再構築型は2,000万〜数千万円規模で、期間は12〜18ヶ月以上に及ぶことが珍しくありません。リビルドや大規模なRefactorなどが該当します。
中堅・中小規模の基幹システム/ERP更改は、3,000万〜1.5億円に収まるケースが多いです。加えて、システムインテグレーション（SI）費用は、全体の60〜75％程度を占める傾向です。費用・期間の目安が手法で大きく違うため、更改で得たい効果と投資が見合うかを、対象範囲ごとに確認します。
単一手法に頼らない「ポートフォリオアプローチ」
すべてをリビルドする方法にも、すべてをリホストする方法にも偏りがあります。また、基幹システムは販売管理や会計など、複数のサブシステムで構成されます。
老朽化の度合いや業務上の重要性は領域ごとに異なります。そのため、一律の手法では過剰投資や効果不足が起きやすくなります。機能やサブシステムごとに7Rを使い分ける方法が、ポートフォリオアプローチです。
- 独自の生産管理：Refactorによる作り込み。
- 汎用的な会計：SaaSやパッケージへの置き換え（Repurchase）。
- 当面変えない周辺機能：Retainによる現状維持。
SAPの「2027年問題」は、ERP更改で手法選択が問われる例です。SAP ERP（ECC6.0）の標準保守は2027年末に終了し、その後はS/4HANAへの移行が求められます。
ERP更改では、標準対応と競争上譲れない独自要件を見極めることが大切です。そのうえで、作り込むのは後者の独自要件だけに絞るのが現実的です。
基幹/ERP更改で見直すべき機能領域の一覧
7Rの枠組みを押さえたら、次は見直すべき機能領域を具体的に見ていきます。基幹システム/ERPは多くの業務モジュールから構成されるため、それぞれの扱いを決める必要があります。現行のまま移すか、標準機能に合わせて見直すかを、領域ごとに判断します。
対象は、業務モジュール、周辺連携、非機能の3つの観点から整理できます。
業務モジュール：販売・購買・在庫・生産・会計・人事給与
ERPの中核は、販売から人事給与まで業務領域ごとに分かれたモジュール群です。更改で見直す代表的な機能領域は下の一覧で確認でき、領域ごとに標準化するか作り込むかを分けて考えます。
- 販売管理：受注・出荷・売上・請求・債権管理。
- 購買・在庫管理：発注・入荷・在庫引当・棚卸。
- 生産管理：所要量計算（MRP）・工程管理・原価計算。
- 会計／財務：総勘定元帳・債権債務・固定資産・原価。
- 人事給与：勤怠・給与計算・社会保険・人事情報。
販売管理は商習慣に依存したカスタマイズが溜まりやすい領域です。購買・在庫管理では、在庫評価方法や引当ロジックの見直しが論点になります。製造業の生産管理は競争力に直結し、独自要件が多い領域です。
会計／財務は制度対応が必要ですが、標準化しやすい領域でもあります。さらに、人事給与は法改正への対応頻度が高く、SaaS化が進んでいます。
見直しの基本姿勢は、業務を標準機能に合わせるFit to Standardです。従来は、自社業務に合わせたカスタマイズが一般的でした。これに対し、更改を機に業務をパッケージやSaaSの標準機能へ寄せると、過剰なアドオンを削減できます。
会計・人事給与は制度で型が決まっているため、標準機能で対応できるケースが多い領域です。RepurchaseによるSaaS・パッケージへの置き換えに適しています。
一方で、生産管理や独自の販売プロセスは、競争優位の源泉となる場合があります。こうした領域は安易に標準へ寄せず、必要に応じてRefactorで作り込む判断も必要です。モジュールごとに標準化するか作り込むかを切り分けることが、見直しの第一歩です。
周辺連携・夜間バッチ・帳票という見落としやすい対象
対象範囲を考えるときは業務モジュールに目が向きがちですが、周辺機能が難航の原因になることもあります。外部システム連携、夜間バッチ処理、帳票、マスタ／データ構造の4つは、業務モジュールと並べて見直す必要があります。
- 外部システム連携：EDI、会計システム、BIツール、ECサイトなど。
- 夜間バッチ処理：締め処理・集計・データ連携など。
- 帳票：請求書・納品書・各種管理帳票など、業務に密着した出力形式。
- マスタ／データ構造：取引先・商品・勘定科目の設計とデータモデル。
EDIは電子データ交換を指します。外部連携と夜間バッチには、現行システムの見えない依存関係が集まります。長年の運用で追加された連携やバッチは、資料が残っていないこともあります。
更改の初期に資産を棚卸しし、必要な連携・バッチを洗い出しておくと、更改時の手戻りを防げます。
マスタとデータ構造も、更改の成否を左右する重要な対象です。現行マスタには、未使用のコードや重複データが蓄積していることがあります。
そのまま新システムへ移すと、データの汚れも引き継ぐことになります。そのため、品質確保の前提として、データクレンジングも対象範囲に含めます。
過剰アドオンの棚卸しと権限・内部統制の見直し
長年積み上がったアドオン（追加開発機能）は、重要な見直し対象です。運用年数の長い基幹システムでは、現場の要望に応じた個別機能が増え、保守を圧迫します。更改は、過剰なカスタマイズをリセットする機会になります。
棚卸しでは、各アドオンを個別に判定します。
- 標準機能での代替：同じ用途を標準機能で満たせるか。
- 利用の有無：現在も使われているか。
判定結果は、移行方針に反映します。標準で代替できる機能は、Retireして標準機能へ寄せます。
利用されていないと判定した機能を削除すれば、移行対象そのものを減らせます。その結果、更改の費用・期間・リスクも同時に圧縮できます。Fit to Standardの考え方は、アドオンの棚卸しという具体的な作業で形になります。
権限管理と内部統制に関わる機能も見直し、誰がどの機能・データにアクセスできるかを、権限設計から組み直します。この作業は、職務分掌や承認フローといった内部統制の面でも欠かせません。
新基盤の標準的な権限管理機能を使えば、属人的な運用を整理できます。統制の効いた状態へ刷新するため、非機能・統制の領域も対象範囲に含めます。
対象範囲の決め方：棚卸しから手法割り当てまでの流れ
7Rの手法と機能領域を押さえたところで、最後にこれらを更改計画へ落とし込む流れを見ていきます。対象範囲は感覚で決めず、棚卸し、分類、手法の割り当てを経て確定させます。
資産棚卸しによる対象範囲の把握
対象範囲を決める出発点は、現行システムの資産棚卸しです。まず、次の資産を洗い出します。
- 機能・サブシステム
- データ・外部連携
- 夜間バッチ
洗い出したうえで、資産が現在どの程度使われているかも確認します。把握せずに手法を決めると、不要な機能まで移行対象に含めてしまうおそれがあります。その結果、費用と期間を無駄に膨らませることにもつながります。
棚卸しでは、機能ごとに利用頻度や業務上の重要度を評価します。加えて、老朽化の度合いと外部依存の強さも、評価の観点になります。評価結果は、後の手法割り当てで使う判断材料です。
未使用のまま残る機能が見えれば、Retireの候補を明確にできます。さらに、対象範囲も効果的に絞り込めます。
機能ごとの7Rの割り当てと段階移行
棚卸しで範囲を把握したら、機能・サブシステムごとに7Rを割り当てます。
- 会計・人事給与：標準化できる領域はRepurchase。
- 生産管理：競争領域はRefactor。
- 周辺機能：当面変えない場合はRetain。
- 未使用機能：Retire。
このように分けて割り当てると、一律に扱う場合より投資効率の高い計画を組めます。割り当てたあとは、対象範囲ごとに移行の進め方を設計します。
全社を一度に切り替えるビッグバン型は、トラブルが起きたときの影響が大きくなります。機能や対象を区切って段階的に置き換える進め方が、現実的です。
サブシステム単位で7Rを割り当てると、優先度の高い領域から進める段階移行と整合します。
棚卸しから段階移行までの順で、更改の全体像を組み立てます。一覧はあくまで道具で、自社の対象範囲を過不足なく切り出すために活用します。
まとめ
基幹システム/ERP更改では、7RとIPAの4分類を対応づけ、手法ごとの費用・期間も確認しました。クラウド移行型は数百万〜1,000万円台で3〜6ヶ月、再構築型は2,000万〜数千万円で12〜18ヶ月以上が目安です。
機能領域では、業務モジュールのほか、外部連携や夜間バッチを確認しました。帳票やマスタも、見落としやすい対象として確認しました。過剰アドオンや権限・内部統制も、更改の対象範囲として整理しました。
更改では、機能・サブシステムごとに7Rを使い分けることが重要です。標準化できる会計・人事給与はRepurchaseで標準機能に寄せ、競争領域はRefactorで作り込みます。未使用機能はRetireで廃棄します。
SAPの2027年問題が示すように、ERPでは標準化と作り込みの見極めが必要です。範囲を切り分けて手法を配分することで、現実的な解につながります。
更改を検討する際は、まず資産を棚卸しして現状を把握します。機能領域の一覧と照らし合わせ、どこを見直すかを整理します。そのうえで各領域に7Rを割り当て、段階的な移行計画へ落とし込みます。
手法や費用感の全体像は、完全ガイドもあわせてご覧ください。
▼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を創業。