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