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