基幹システム・ERP更改は、現状評価、要件定義、RFP比較の順で進めると手戻りを抑えられます。契機は、ハード・ミドルウェアのEOL（保守終了）、ソフトの保守契約、ベンダー支援の終了です。
更改は多くの企業が避けて通れないテーマです。全体像は完全ガイドもご覧ください。
▼全体ガイドの記事
・基幹システム/ERP更改の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
更改のアセスメントと現状分析（AS-IS）の重要性
基幹システムやERPは、一度導入すると10年、15年と使い続けられることも珍しくありません。また、経済産業省のDXレポートが示した「2025年の崖」も、更改が避けて通れない背景を象徴しています。
更改では、稼働中の仕組みを止めずに作り替える必要があります。さらに、長年の運用で仕様が複雑になり、設計意図が失われたケースも少なくありません。
そのため、設計や開発の前に行うアセスメントと現状分析（AS-IS）が、更改の成否を左右します。ここを飛ばすと、後工程で手戻りが発生します。
まず、アセスメントは、現行システムの状態を客観的に評価する工程で、機能や老朽化、ブラックボックス化の状況を見える形にします。そのうえで、現状評価をもとに、どこまで作り替え、どこを残すかという更改方針を定めます。
資産の棚卸し：機能・データ・連携・依存関係の洗い出し
長年使われてきた基幹システムほど、未使用の機能や理由の分からない処理が積み重なっています。そのため、AS-IS分析では、現行システムの要素を一つずつ洗い出します。
棚卸しの対象は、おおむね次の4点です。各項目を確認すると、業務への影響と更改の範囲をつかめます。
- 機能：業務を担う画面や処理
- データ：マスタやトランザクションの種類と量
- 連携：外部システムと接続するインターフェース
- 依存関係：機能の変更が影響する範囲
洗い出した情報があれば、更改で残すもの、捨てるもの、作り替えるものを判断できます。特に、依存関係を見落とすと、ある処理を止めた影響が別の業務にも及び、停止するおそれがあります。
棚卸しは地味で手間のかかる作業ですが、省くと要件定義の段階で情報が足りなくなります。そのため、影響範囲は事前に把握しておく必要があります。
仕様書欠如・ブラックボックス化が失敗を招く構造
更改の失敗要因には、仕様書がない、または更新されていないことで生じるブラックボックス化があります。設計書がないまま長年改修された基幹システムでは、ソースコードを読まないと仕様が分からない場合があります。
現状を正確に把握できないと、要件定義は不十分になります。たとえば、「現行と同じ動き」を求める要望が出ても、その中身を誰も示せない事態が起こります。
- 仕様の不明確さ：現行の動作を正確に説明できない
- 移行後の問題：以前できた処理ができなくなり、稼働後の混乱や事業停止を招く
- 要件定義への影響：AS-ISの把握が足りないと、要件に抜けが生じる
富士通は、アプリケーション資産の複雑度や依存関係を見えるようにする「ソフトウェア地図」という考え方を示しています。コードや処理の関係を俯瞰して、複雑な箇所と着手点をアセスメントの段階で押さえる発想です。
このため、ツールも使いながら、ブラックボックスを放置せず見える形にすることが、更改成功の前提になります。
要件定義で固める内容
AS-IS分析の次は、現状をもとに更改後の姿（TO-BE）を定める要件定義に進みます。要件定義で必ず固めるのは、機能・非機能の要件のほか、データ移行の範囲、外部連携、移行後のKPIです。ここで決めた内容が、RFPやベンダー選定、開発の基準になります。
要件が曖昧なままだと、提案の評価や見積もりが難しくなり、稼働後の品質も担保できません。
アセスメント、要件定義、業務棚卸しなどの上流工程は、一般に200万円から500万円程度が相場です。金額は、現行システムの規模や複雑度によって変わります。
上流工程への投資を惜しんで早く開発に進むと、後工程で手戻りが起き、コストが膨らみます。要件定義は設計の前に行う確認で、更改全体の成否を左右します。
機能要件と非機能要件の切り分け
要件定義では、機能要件と非機能要件を分けて整理します。機能要件は、受発注、在庫管理、会計処理など、システムが行う業務上の振る舞いを指します。
非機能要件は、機能をどの品質水準で実現するかを示すものです。性能や可用性のほか、セキュリティや拡張性なども対象になります。
性能要件は見落としやすいため、具体的な数値で決めておく必要があります。決める観点は、次の4つです。
- 処理性能：月次バッチの完了時間
- 同時接続：ピーク時に利用するユーザー数
- 応答時間：画面表示や検索にかかる時間
- 可用性：稼働率や許容ダウンタイム
目標が曖昧なままだと、移行後のシステムは動いても、遅くて使えない事態になりかねません。機能要件は現行業務から洗い出しやすい一方で、非機能要件には現状の実測値が必要です。
そこで、現状の処理時間や負荷を測定し、更改後の目標値を定めます。前章のアセスメントで得た情報が、実現可能な要件設定につながります。
データ移行範囲・外部連携・移行後KPIの定義
要件定義では、現行システムの全データを移すか、古いデータはアーカイブにとどめるかを決めます。この線引きは、移行作業の工数とリスクに直結します。
全件移行が常に正解とは限りません。棚卸しの結果をもとに、移行が必要なデータを選び分けます。
外部連携では、販売管理や会計、物流、ECサイトなどとの接続を整理します。維持・更新する連携について、その方式やタイミングを明確にしないと、連携が切れて業務が止まるおそれがあります。
AS-IS分析で洗い出した連携一覧について、TO-BEでどう扱うかまで詰めます。また、更改後のKPI（評価指標）も、要件定義の段階で設定します。
- バッチ処理：処理時間の短縮率
- 保守：コストの削減目標
- 業務：特定業務の処理工数
指標を先に決めておけば、稼働後に更改の効果を評価できます。目的を数値で定めないと、作り替えた効果が分からなくなるおそれがあります。
RFPに盛り込む項目とベンダー評価基準
要件定義の内容をベンダーに伝え、提案を求める文書がRFP（提案依頼書、Request for Proposal）です。RFPの精度が低いと、各社は異なる前提で見積もることになり、提案を比べられません。逆に、RFPに必要な情報を盛り込み、項目と評価観点を前もって決めておけば、提案の質と選定の公平性が上がります。
RFPに含めるべき項目一覧
RFPには、ベンダーが提案を組み立てるために必要な情報を記載します。更改後の要件と運営の前提として、最低限、次の項目を盛り込みます。
- 現行構成図・外部連携：システム全体像、連携先と方式
- 機能要件：更改後に求める業務上の振る舞い
- 非機能要件：性能・可用性・セキュリティの目標値
- データ移行範囲：対象とする範囲や方針
- 移行後KPI：更改で達成したい数値目標
プロジェクトを動かす実務情報も明記します。希望する稼働時期やマイルストーン、稼働後に求める保守水準、概算予算と支払条件を示すと、ベンダーは現実的な提案を組み立てられます。
上流のアセスメントと要件定義だけで、200万円から500万円程度が相場です。開発や移行も含む全体感を踏まえ、RFPに概算予算を示すとよいでしょう。
予算を示さないと、ベンダーは提案の規模を測れず、過剰または過小な提案になることがあります。また、要件定義の精度は、そのままRFPの精度につながります。
ベンダー評価の5つのチェックポイント
提案の比較では、保守が稼働後まで続くことを踏まえ、価格に加えてベンダーの実力や体制も見ます。次の5点は、提案を比べる観点として有効です。
- 更改実績：同業界・同規模の経験
- 段階移行：対象を区切って置き換える設計力
- ダウンタイム：見積もりの妥当性
- 保守体制：24時間365日の対応体制
- 認証：ISO9001やISO27001などの保有状況
経験が近い案件ほど、想定外の論点を事前に潰せます。段階移行については、全社を一度に切り替える「ビッグバン」型を避けられるかを見ます。
ダウンタイムの見積もりは、切り替えの際に業務を止める時間の見通しです。見積もりが甘い場合、移行設計が雑な可能性があります。
基幹システムの停止は事業停止につながるため、保守体制は稼働後の安心感に直結します。なお、認証は、品質管理やセキュリティ管理の仕組みが組織として整っていることの裏づけになります。
5点をRFPで問い、提案書と質疑応答で確かめれば、価格に引きずられず、実態に即して選定できます。
SAP 2027年問題とFit to Standardを前提にしたRFPの論点
ERP更改では、多くの企業が「SAP 2027年問題」に直面しています。SAPの主力ERPであるECC6.0の標準保守は2027年末に終了する見込みで、後継のS/4HANAへの移行が求められています。
これは保守終了を契機とする更改の一例です。ここまでのアセスメント、要件定義、RFPの考え方を当てはめると、移行時に問うべき内容が見えてきます。
RFPで問う標準機能とアドオンの線引き
S/4HANAへの移行では、「Fit to Standard」が基本になります。これは、ERPの標準機能に業務を合わせる方法で、自社業務に合わせて作り込む量をできるだけ減らす考え方です。
業務に合わせた追加開発は「アドオン開発」と呼ばれます。アドオンが増えるほど、将来のバージョンアップや更改の保守負担が増えるため、標準機能の活用が推奨されます。
RFPでは、どこまで標準機能でまかない、どこからアドオンにするかを問います。現行の独自機能をそのまま移すと、Fit to Standardの利点が薄れ、コストと保守負担も増えます。
- 標準機能で代替する範囲：AS-ISで洗い出した機能から検討する
- 独自対応が必要な範囲：代替の難しい機能を見極める
- アドオン最小化：切り分け方針や工夫を提案項目にする
提案の段階で、ベンダーと機能を突き合わせ、標準機能への寄せ方を確認します。この線引きは、移行後の保守性と総コストを大きく左右します。
切り分けの方針をRFPに明記すると、ベンダーの設計思想を見極めやすくなります。また、標準機能への寄せ方の具体性は、前章の評価項目とあわせて選定の材料になります。
まとめ
更改は、アセスメントとAS-IS分析で現行システムを客観的に評価するところから始まります。仕様書の欠如やブラックボックス化を放置すると、要件定義が不十分になり、更改失敗の主因になります。
要件定義では、機能要件と非機能要件を分けて整理し、性能目標やデータ移行範囲、外部連携、移行後KPIを定めます。RFPには、これらに加えて現行の構成図を入れ、スケジュールや保守体制、概算予算も盛り込みます。
ベンダー選定では、同業界・同規模の実績や段階移行の設計力を確かめます。加えて、ダウンタイムの見積もり、保守体制、ISO9001やISO27001などの認証も確認します。
SAPの2027年問題に関わるERP更改では、Fit to Standardを前提に標準機能とアドオンを線引きします。
アセスメントと要件定義だけでも、200万円から500万円規模の投資が必要になり、規模や複雑度によって変わります。上流への投資は、後工程の手戻りを防ぎ、更改全体の成否を左右します。
全体像や進め方、費用感を体系的に確認する場合は、完全ガイドもあわせてご活用ください。
▼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を創業。