基幹システムやERPのモダナイゼーションを成功させられるかどうかは、刷新の入り口である「アセスメント」「要件定義」「RFP（提案依頼書）」の質で大きく決まります。実際、刷新プロジェクトが炎上する原因の多くは、現行システムの仕様書欠如やブラックボックス化による要件定義の不十分さにあると指摘されています。現状を正しく把握しないまま見切り発車してしまうと、移行の途中で想定外の課題が次々と噴出し、コストも期間も大幅に超過してしまうのです。
本記事では、基幹システム/ERPのモダナイゼーションにおけるアセスメント（現状分析）から要件定義、そしてRFP作成・ベンダー選定までの流れを、実務で押さえるべきポイントに絞って解説します。特にRFPに盛り込むべき具体的な項目と、ベンダーを客観的に評価するためのチェックポイントに重点を置いてお伝えします。刷新の全体像や進め方の基礎を確認したい方は、基幹システム/ERPのモダナイゼーションの完全ガイドもあわせてご覧ください。本記事は新規開発の進め方ではなく、既存システムを刷新する際の現状分析と提案依頼の観点で構成しています。
▼全体ガイドの記事
・基幹システム/ERPのモダナイゼーションの完全ガイド
刷新の起点となるアセスメント（現状分析）
モダナイゼーションの最初のステップは、現行システムの実態を正確に把握する「アセスメント（現状分析）」です。刷新の失敗の多くは、このアセスメントを省略したり不十分なまま進めたりすることに起因します。長年運用してきた基幹システムは仕様書が古い、あるいは存在しないことも多く、現状を可視化しないまま要件を固めようとすると、必ずどこかで破綻します。アセスメントは「現状を知る」だけでなく「刷新の優先順位と範囲を決める」ための土台となる工程です。
AS-IS（現状）の可視化と資産棚卸し
アセスメントの中核は、AS-IS（現状）の可視化と資産棚卸しです。具体的には、どのようなシステムが何台のサーバーで稼働し、どの言語・ミドルウェアで構成され、相互にどう連携しているのかを洗い出します。長年の運用で追加・改修が積み重なった基幹システムは、内部の依存関係が複雑に絡み合っており、人手だけで全容を把握するのは困難です。そこで活用したいのが、アプリケーション資産の複雑度や依存関係を可視化するツールです。
たとえば富士通が提供する「ソフトウェア地図」は、アプリケーション資産の複雑度や依存関係を地図のように可視化し、ブラックボックス化したシステムのどこに技術的負債が集中しているかを客観的に示してくれます（出典：富士通）。こうしたツールで現状を見える化することで、「どのシステムを優先的に刷新すべきか」「どこに移行リスクが潜むか」を根拠を持って判断できるようになります。資産棚卸しは地味な作業ですが、刷新の成否を左右する最重要工程です。
アセスメント・要件定義にかかる費用感
アセスメントと要件定義は、刷新本体とは別に投資すべき独立した工程です。費用相場としては、要件定義・業務棚卸しのみで200万〜500万円程度が目安となります。刷新本体の費用（小〜中規模で3,000万〜1.5億円）と比べると小さく見えるかもしれませんが、この上流工程への投資を惜しむと、後工程での手戻りやトラブルでその何倍ものコストが発生しかねません。
むしろ、アセスメントと要件定義を独立したフェーズとして切り出し、ここに十分な予算と時間を投じることが、刷新全体のコストを抑える最も効果的な方法です。この段階でベンダーに丸投げするのではなく、自社の業務とシステムを最もよく知る現場部門が主体的に関わることが重要です。上流工程の質が、刷新プロジェクト全体の品質を決定づけます。
刷新の要件定義で押さえるべき観点
新規開発の要件定義が「これから作るものを定義する」のに対し、刷新の要件定義は「既存のものを踏まえて、何を残し何を変えるか」を定義する点に特徴があります。現行システムが提供している機能のうち、本当に必要なものは何か、廃止できるものは何か、新たに加えるべきものは何かを、現状分析の結果をもとに整理していきます。
現行踏襲かFit to Standardかの方針決定
刷新の要件定義で最初に決めるべき大きな方針が、「現行業務をそのまま新システムに移す（現行踏襲）」のか、「パッケージの標準機能に業務を合わせる（Fit to Standard）」のかという選択です。ERP刷新、特にSAP S/4HANAへの移行では、この方針が移行コストと期間を大きく左右します。現行のアドオン（追加開発）をすべて新環境に移植しようとすると、工数が膨大になり、移行リスクも高まります。
標準機能で代替できる業務はFit to Standardで標準に合わせ、本当に競争力に直結する業務だけを独自要件として残すという取捨選択が、現実的かつ効果的なアプローチです。この判断を要件定義の段階で明確にしておかないと、後でアドオンが際限なく増殖し、SAP導入の3大疾病の一つである「大量のアドオン開発」に陥ります。要件定義は「やりたいことの羅列」ではなく「やらないことを決める」工程でもあるのです。
非機能要件と移行後KPIの定義
刷新の要件定義では、機能要件だけでなく非機能要件と移行後のKPIを明確にすることが欠かせません。非機能要件とは、性能（バッチ処理時間やレスポンス）、可用性（稼働率や障害時の復旧時間）、セキュリティ、拡張性といった「品質に関わる要件」です。たとえば「夜間バッチを90分以内に完了させる」「24時間365日の稼働を保証する」といった具体的な目標値を定めておくことで、刷新後の効果を客観的に検証できます。
あわせて、刷新によって達成したい移行後のKPI（重要業績評価指標）も定義します。保守費を何%削減するのか、処理時間をどれだけ短縮するのか、運用工数をどこまで減らすのかといった数値目標が、RFPでベンダーに求める要件の基盤となり、稼働後の成果評価の基準にもなります。曖昧な目標のまま進めると、刷新が「終わったかどうか」すら判断できなくなるため、測定可能な指標として定めることが重要です。
RFP（提案依頼書）に盛り込むべき項目
アセスメントと要件定義の成果を、ベンダーへの提案依頼に落とし込むのがRFP（提案依頼書）です。RFPの質が低いと、ベンダーごとに前提のバラバラな提案が集まり、比較も判断もできなくなります。逆に、必要な情報を過不足なく盛り込んだRFPは、各社から精度の高い提案を引き出し、適切なベンダー選定を可能にします。
刷新RFPに必須の構成要素
刷新プロジェクトのRFPに盛り込むべき主な項目は次のとおりです。
・プロジェクトの背景と目的（なぜ刷新するのか、解決したい課題）
・現行システムの構成図（サーバー構成・連携関係・データ量）
・現状の課題と移行の対象範囲（どこを刷新し、どこを残すか）
・性能要件・非機能要件（処理時間・可用性・セキュリティ基準）
・移行後に達成したいKPI（保守費削減率・処理時間短縮など）
・希望する移行方式とスケジュール（段階移行の希望など）
・予算規模と契約形態の希望
これらを明記することで、ベンダーは自社の状況を正確に理解したうえで提案を作成できます。
特に「現行システムの構成図」と「移行の対象範囲」は、刷新RFP特有の重要項目です。新規開発と異なり、刷新では既存資産という制約条件が存在するため、これを正確に伝えなければベンダーは移行の難易度を見積もれません。アセスメントで可視化した現状を構成図として整理し、RFPに添付することが、精度の高い提案と適正な見積もりを引き出す鍵となります。
データ移行・並行稼働に関する要件
刷新RFPでは、データ移行と並行稼働に関する要件を明確に提示することが特に重要です。基幹システムやERPには長年蓄積された膨大なデータがあり、その移行の品質が稼働後の安定性を左右します。RFPには、移行対象データの量と種類、データクレンジングの範囲、移行リハーサルの回数、移行時のダウンタイム許容時間などを記載し、ベンダーに具体的な移行計画の提案を求めます。
あわせて、新旧システムの並行稼働期間や、障害発生時に旧システムへ切り戻す体制についても要件として明示します。江崎グリコの出荷停止事例が示すように、移行計画の甘さは深刻な業務停止リスクに直結します。「ダウンタイムをどこまで許容できるか」「切り戻し手順をどう設計するか」をRFPの段階でベンダーに問うことで、移行リスクへの対応力が高いベンダーを見極められます。
失敗しないベンダー選定の評価基準
RFPで集まった提案を、どのような基準で評価するかも刷新の成否を分けます。価格の安さだけで選ぶと、移行リスクへの対応力が不足したベンダーを選んでしまい、結果的に高くつくことになりかねません。刷新プロジェクトでは、技術力・実績・体制を客観的な基準で評価することが重要です。
ベンダー評価の5つのチェックポイント
刷新ベンダーを評価する際に確認すべき主要なチェックポイントは、次の5つに整理できます。
1. 同業界・同規模の刷新実績があるか（業界特有の業務知識を持つか）
2. 段階的移行を設計できる力があるか（ビッグバンを避けるリスク設計力）
3. ダウンタイムを現実的に見積もれているか（楽観的すぎる見積もりは危険信号）
4. 24時間365日の保守体制を提供できるか（稼働後の安定運用）
5. ISO9001・ISO27001などの品質・セキュリティ認証を取得しているか
これらを評価項目として点数化し、複数ベンダーを横並びで比較することで、客観的で説明可能なベンダー選定が可能になります。
なかでも「同業界・同規模の実績」と「段階的移行の設計力」は、刷新の成否に直結する重要な評価軸です。自社と似た規模・業種の刷新を成功させた実績があるベンダーは、起こりうる課題を経験的に把握しており、リスクを先回りして対策できます。逆に、刷新実績の乏しいベンダーは、移行の難所を過小評価しがちです。提案内容だけでなく、過去の実績を具体的に確認することが選定の精度を高めます。
ベンダー丸投げを避ける発注側の体制
優れたベンダーを選定できても、発注側が「丸投げ」してしまうと刷新は失敗します。要件定義やRFP作成をベンダー任せにすると、自社の業務実態と乖離したシステムが出来上がり、稼働後に「使えない」という事態を招きます。アセスメントから要件定義、RFP作成、ベンダー選定までの上流工程は、自社が主体性を持って進めるべき領域です。
とはいえ、社内に刷新の専門知識を持つ人材がいないケースも多いでしょう。その場合は、特定のベンダーに依存しない中立的な立場で上流工程を支援してくれるコンサルティングパートナーを活用するのが有効です。RFP作成やベンダー評価を客観的にサポートしてもらうことで、ベンダー丸投げのリスクを避けながら、社内に刷新を進めるための知見を蓄積できます。発注側の体制づくりこそが、刷新成功の隠れた要諦です。
まとめ
本記事では、基幹システム/ERPのモダナイゼーションにおけるアセスメント・要件定義・RFP作成・ベンダー選定の流れを解説しました。刷新の起点は現行システムのAS-IS可視化と資産棚卸しであり、ソフトウェア地図のようなツールでブラックボックスを見える化することが重要です。要件定義では現行踏襲かFit to Standardかの方針を決め、非機能要件と移行後KPIを数値で定義します。RFPには現行構成図・移行対象範囲・性能要件・移行後KPI・データ移行要件を盛り込み、ベンダーは同業界実績・段階移行の設計力・ダウンタイム見積り・保守体制・各種認証という5つのチェックポイントで評価します。
刷新の失敗の大半は、この上流工程の不足に起因します。要件定義・業務棚卸しには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を創業。