基幹システムやERPの刷新を検討し始めると、最初にぶつかるのが「いったいどこまでを刷新の対象にすればよいのか」という範囲の問題です。会計・販売・購買・在庫・生産・人事といった広範な業務をカバーする基幹システムは、すべてを一度に作り替えようとすると費用も期間も膨れ上がります。逆に範囲を絞りすぎると、古い仕組みが残って効果が中途半端に終わってしまいます。SAP ERP（ECC6.0）の保守が2027年末に終了する「2027年問題」を機にSAP S/4HANAへの移行を考える企業も、まずは「どの機能・領域を、どの手法で刷新するか」を見極めることが出発点になります。
本記事では、基幹システム/ERP刷新で見直すべき機能・対象範囲の一覧について、どの業務領域を棚卸しの対象とすべきか、そしてそれぞれをどの手法で刷新するかを体系的に整理します。あわせて、移行手法の代表的なフレームワークである「7R」や、領域ごとの費用・期間の目安も具体的に解説します。刷新の進め方や事例まで含めた全体像は基幹システム/ERP刷新の完全ガイドで確認いただけます。ここでは、その完全ガイドでは概要にとどまる「対象範囲の切り分けと手法選定」を、実務で使える粒度まで掘り下げます。
▼全体ガイドの記事
・基幹システム/ERP刷新の完全ガイド
基幹システム/ERP刷新で見直すべき機能・対象範囲の一覧
基幹システム/ERP刷新の対象範囲は、業務領域を横軸に、技術基盤を縦軸にして整理すると見通しが良くなります。横軸とは会計・販売・購買・在庫・生産といった業務機能のことであり、縦軸とはサーバー・データベース・連携基盤・帳票といった技術要素のことです。この章では、まず業務機能の側から「見直すべき領域の一覧」を示します。
すべての領域を同じ深さで刷新する必要はありません。競争優位に直結する領域は手厚く、定型業務に近い領域はパッケージの標準機能に寄せるという濃淡をつけることが、費用対効果を高めるうえで重要です。以下では、刷新の検討対象となる代表的な機能領域を順に見ていきます。
会計・販売・購買・在庫・生産という業務機能の領域
基幹システムの中核を成すのが、会計（財務会計・管理会計）、販売（受注・出荷・売上）、購買（発注・仕入）、在庫（入出庫・棚卸）、生産（生産計画・原価管理）といった業務機能です。これらは相互にデータが連携しており、たとえば受注が在庫を引き当て、出荷が売上を計上し、会計に反映されるといった一連の流れでつながっています。刷新範囲を考えるときは、この連携の流れを断ち切らないように領域をまとめることが基本になります。
領域ごとに刷新の優先度は異なります。会計領域は法令対応や監査の要件が厳しく、標準機能で対応しやすい一方、変更の影響が全社に及びます。販売・在庫領域は自社の商習慣やビジネスモデルが色濃く反映されるため、独自要件が多くなりがちです。生産領域は製造業にとって競争力の源泉であり、安易に標準化すると現場が回らなくなるリスクがあります。こうした領域特性を踏まえて、どこを標準に寄せ、どこに独自性を残すかを見極めます。
見落とされがちなのが、人事・給与、固定資産、債権債務といった周辺領域です。これらは目立たないものの、会計領域と密接に連携しているため、刷新範囲から外すと連携の作り込みが新たな負担になります。対象範囲を決める際は、中核モジュールだけでなく、それと連携する周辺領域までを一覧として洗い出すことが欠かせません。
インフラ・データベース・連携・帳票という技術基盤の領域
業務機能の裏側には、それを支える技術基盤があります。具体的には、サーバーやネットワークといったインフラ、データを保持するデータベース、他システムとつなぐ連携（インターフェース）基盤、そして出力を担う帳票・データ出力の仕組みです。基幹システム刷新では、業務機能だけを見て技術基盤を後回しにすると、古い基盤がボトルネックとなって効果が出ないことがあります。
とくに連携基盤は刷新の難所になりやすい領域です。基幹システムは販売管理、生産管理、外部のEDIや銀行システムなど多くの周辺システムとつながっており、その接続点（インターフェース）が長年の運用で複雑化していることが少なくありません。刷新の際にこの連携の本数と仕様を一覧化しておかないと、移行時に「つながらない」「データが流れない」というトラブルを招きます。連携の棚卸しは対象範囲の検討で必ず行うべき作業です。
帳票やデータ出力も見落としやすい領域です。請求書や納品書、各種の管理帳票は、業務の現場で長年使われてきたフォーマットがあり、刷新後も同じ形が求められることが多くあります。一方で、本当に必要な帳票なのか、Excel出力やBIツールで代替できないかを見直す好機でもあります。技術基盤の刷新範囲を決める際は、インフラ・データベースだけでなく、連携と帳票まで含めて一覧にすることが重要です。
領域ごとに使い分ける刷新手法「7R」の一覧
刷新する機能・対象範囲を一覧化したら、次はそれぞれをどの手法で刷新するかを決めます。ここで役立つのが、AWSが提唱する「7R」というフレームワークです。7Rは、Rehost（リホスト）、Relocate（リロケート）、Replatform（リプラットフォーム）、Repurchase（リパーチェス）、Refactor（リファクタ）、Retire（リタイア）、Retain（リテイン）の7つの選択肢を指します。基幹システム全体に単一の手法を当てはめるのではなく、領域ごとに最適な手法を組み合わせる「ポートフォリオアプローチ」が現実的です。
7Rそれぞれの意味と適したケース
7Rの各手法は、刷新の深さとコストが段階的に異なります。リホストは既存システムをそのままクラウドなどの新環境へ載せ替える方法で、改修が最小限のため短期間・低コストで実施できます。リプラットフォームはOSやミドルウェアなど一部を最適化しながら移行する方法で、リホストより一歩踏み込んだ改善が可能です。リファクタはアプリケーションの構造そのものを作り直す方法で、効果は大きい反面、期間と費用がかさみます。
リパーチェスは、独自開発をやめてSAP S/4HANAのようなパッケージ製品に置き換える方法です。標準機能に業務を寄せる「Fit to Standard」の発想と相性が良く、ERP刷新ではこの選択肢が中心になることが多くあります。リロケートは仮想環境ごと別基盤へ移す方法、リタイアは不要になった機能を廃止する方法、リテインは当面そのまま維持する方法です。すべてを刷新するのではなく、廃止や維持という判断も立派な選択肢である点が7Rの本質です。
なお、IPA（情報処理推進機構）も、リビルド・リライト・リホスト・ハードウェア更改という4つの分類でモダナイゼーション手法を整理しています。7Rとは粒度が異なりますが、「どこまで作り直すか」を段階的に捉える考え方は共通しています。フレームワークは絶対的なものではなく、自社の議論を整理するための共通言語として使うのが賢明です。
領域ごとに手法を組み合わせるポートフォリオの考え方
基幹システム全体を一つの手法で刷新しようとすると、無理が生じます。たとえば「すべてリビルドする」と決めると費用と期間が跳ね上がり、「すべてリホストする」と決めると老朽化した業務ロジックがそのまま残ってしまいます。現実的なのは、領域ごとに7Rを使い分けるポートフォリオアプローチです。
具体的には、競争優位に直結しない会計や購買はパッケージ標準への置き換え（リパーチェス）、独自性が強い生産管理は構造から作り直すリファクタ、まだ役割を終えていない周辺システムはひとまず維持（リテイン）、すでに使われていない機能は廃止（リタイア）、といった具合に組み合わせます。こうして領域×手法のマトリクスを作ると、刷新の全体像と優先順位が一目で把握できるようになります。
このマトリクスは、経営層への説明資料としても有効です。「すべてを一気に作り直すわけではなく、領域ごとにコストとリスクを見極めて手法を変えている」という説明は、投資判断を後押しします。対象範囲の一覧と7Rの組み合わせをセットで示すことが、刷新計画の納得感を高めるのです。
対象範囲・手法ごとの費用と期間の目安
対象範囲と手法を決める際には、それぞれにかかる費用と期間の目安を押さえておくことが欠かせません。範囲を広げれば効果は大きくなりますが、その分コストと期間も増えます。ここでは、刷新の規模・手法ごとの費用相場と期間の目安を整理します。あくまで目安であり、実際の金額は自社の規模・業種・要件によって変動する点にはご留意ください。
規模・手法別の費用相場
費用は刷新の範囲と手法によって大きく変わります。要件定義・業務棚卸しのみを行う場合は、200万〜500万円程度が目安です。単一の業務システムを対象とする小〜中規模の刷新では、3,000万〜1.5億円程度が相場で、このうちSI費（システムインテグレーションの費用）が60〜75％を占めることが多くあります。基幹システムに複数の周辺システムを加えた中〜大規模の刷新になると、1.5億〜5億円規模に達することもあります。
手法別に見ると、リホストなどのクラウド移行型は数百万〜1,000万円台で実施できることが多く、比較的低コストです。一方、リビルドなどの再構築型は2,000万円から数千万円規模に及びます。手法によって一桁単位で費用が変わるため、対象範囲ごとにどの手法を選ぶかが、総額を大きく左右することがわかります。
これらの費用は「投資」として捉えることが重要です。実際の刷新事例では、保守費を年2,400万円から850万円へ約65％削減したケースもあり、初期投資を数年で回収できる見込みが立つことも珍しくありません。費用の絶対額だけでなく、削減できる運用コストや得られる効果と合わせて判断することが、適切な範囲設定につながります。
手法別の期間とスケジュールの考え方
期間も手法によって大きく異なります。クラウド移行型（リホスト等）は3〜6ヶ月程度で完了することが多く、短期間で着手しやすい選択肢です。再構築型（リビルド等）になると12〜18ヶ月以上かかることが一般的で、実際の製造業の事例ではCOBOL基幹系の刷新に約16ヶ月を要しています。範囲を広げるほど期間が延びるため、スケジュールから逆算して着手時期を決める必要があります。
とくにSAPの2027年問題のように明確な期限がある場合、期間の見積もりは計画の根幹を成します。再構築型で18ヶ月かかるのであれば、保守終了の2年以上前には意思決定を終えていなければ間に合いません。対象範囲を欲張りすぎて期間が延び、結果として期限に間に合わなくなる事態は避けたいところです。範囲・手法・期間の三つを連動させて計画することが求められます。
期間を現実的に収めるためにも、前章で触れた段階的な移行が有効です。全領域を一度に刷新するのではなく、優先度の高い領域から順に着手し、新旧を並行稼働させながら置き換えていけば、長い期間でもリスクを抑えられます。対象範囲の一覧を作る目的のひとつは、こうした段階的な計画を組み立てる土台を用意することにあります。
まとめ
本記事では、基幹システム/ERP刷新で見直すべき機能・対象範囲の一覧について解説してきました。対象範囲は、会計・販売・購買・在庫・生産といった業務機能の横軸と、インフラ・データベース・連携・帳票という技術基盤の縦軸で整理すると見通しが良くなります。連携と帳票は見落とされやすいため、棚卸しの段階で必ず一覧化しておくことが重要です。
手法は、リホスト・リプラットフォーム・リファクタ・リパーチェス・リロケート・リタイア・リテインという7Rを領域ごとに使い分けるポートフォリオアプローチが現実的でした。費用は要件定義のみで200万〜500万円、小〜中規模で3,000万〜1.5億円、中〜大規模で1.5億〜5億円が目安であり、クラウド移行型は3〜6ヶ月、再構築型は12〜18ヶ月以上という期間感も押さえておきたいところです。SAPの2027年問題のような期限がある場合は、範囲・手法・期間を連動させた計画が欠かせません。
自社の基幹システム/ERP刷新の対象範囲を検討する際は、まず業務機能と技術基盤を一覧として洗い出し、領域ごとに7Rを当てはめてマトリクスを作ることから始めてください。そのうえで、手法選定の背景にある進め方や事例を体系的に把握したい場合は、完全ガイドもあわせて活用いただくと、対象範囲の判断がより確かなものになります。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。