基幹システム/ERP刷新は、アセスメントで現状を把握し、要件定義で固め、RFPでベンダーに伝えるという順で進めます。この流れを守ると、手戻りを抑えやすくなります。SAP ECC6.0の保守終了（2027年問題）に伴うS/4HANA移行でも、上流工程の精度が成否を左右します。
▼全体ガイドの記事
・基幹システム/ERP刷新の完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
刷新の起点となるアセスメントと現状分析（AS-IS）
基幹システム/ERP刷新では、要件定義に入る前に、現行システムが何をどう実現しているかを調べます。これがアセスメント（現状分析）です。
長年使われたシステムは、設計の意図が失われてブラックボックス化していることがあります。仕様書が残っていなかったり、実態を把握できていなかったりすると、要件定義が不十分になる原因になります。
アセスメントを軽視すると、要件定義の段階で現行システムの実態を誰も説明できない事態に陥ります。アセスメントで明らかにすべきなのは、現行システムの機能やデータ、連携と、刷新の対象です。その結果を要件定義へつなげます。
資産の棚卸しとブラックボックスの可視化
アセスメントの第一歩は、現行システムが抱える資産を棚卸しすることです。棚卸しでは、機能やプログラム、データ、連携を洗い出し、それぞれがどの業務を支えているかを確認します。
棚卸しの結果は刷新方針の根拠になるため、刷新時に扱いが変わる箇所を明らかにしておきます。
- 不要な機能：新基盤へ移さない候補
- 複雑な領域：刷新時に注意が必要な範囲
- 連携の難所：プログラム間の依存関係が絡む箇所
製造業のCOBOL基幹系刷新の成功事例でも、開発に入る前の資産棚卸しが刷新の起点になりました。その結果、必要な処理だけを新基盤へ載せ替える判断につながりました。
棚卸しの手間を減らすため、ツールを使う企業も増えています。富士通の「ソフトウェア地図」を使うと、アプリケーション資産の複雑度や依存関係を把握できます。人手で巨大なシステムの依存関係を追うのが難しい場合は、こうしたツールを併用できます。
棚卸しの一覧は表にとどめず、刷新方針を決める根拠として使います。そのうえで、見えてきた領域ごとに7Rのような手法を割り当てると、刷新計画の骨格を作れます。
AS-ISからTO-BEへの業務ギャップの定義
現状（AS-IS）を把握したあとは、あるべき姿（TO-BE）を描き、両者のギャップを定義します。刷新の目的は、業務をより良く変えることにあります。
そのため、AS-ISの棚卸しでは、いまの業務をそのまま残さず、どこを変えるかを見極めます。
ギャップを整理する際は、現行をそのまま再現する要件と、標準機能に合わせて見直せる業務を切り分けます。
- 現行を再現する要件：業務上必要な本質的要件の特定
- 見直せる業務：ERPの標準機能に業務を寄せる対象
現行業務をすべて再現しようとすると、独自のカスタマイズが増え、保守の負担と費用も大きくなります。標準に寄せる範囲は、Fit to Standardの考え方で見極めます。
ギャップの定義は、要件定義へ渡す材料になります。AS-ISの把握からTO-BE、要件定義へと連続して進めると、手戻りを抑えやすくなります。刷新の精度は、この連続性を保てるかどうかにかかっています。
要件定義で固めるべき項目とまとめ方
アセスメントで見えた現状と方針を、具体的な要件にまとめます。機能要件と非機能要件の両面を定義します。基幹システムが止まると全社の業務が止まるため、性能や可用性などの非機能要件も重要です。
要件定義のみを外部に依頼する費用は、業務棚卸しを含めて200万〜500万円程度が目安です。丁寧に固めると、後続の開発や移行での手戻りコストに差が出ます。そのため、上流工程への投資は、プロジェクト全体のリスクを下げるものとして捉えられます。
機能要件と非機能要件の整理
機能要件は、刷新後のシステムが業務上どんな処理を実現するかを定めるものです。記述は、現行の挙動をなぞるのではなく、TO-BEで見直した業務に沿って行います。
要件には、業務処理とシステム品質に関わる内容を含めます。
- 業務処理：会計の締めや、受注から出荷、在庫引き当てなど
- 性能・可用性：バッチ時間や停止可能時間、ピーク時の処理量
- その他の品質：拡張性、セキュリティ、運用の要件
Fit to Standardの方針に従い、標準機能で実現できる部分は標準に寄せると明記します。製造業の事例では、夜間バッチを8時間から90分へ短縮しました。処理性能の目標を明確に置いたことが、この成果につながりました。
機能・非機能要件はRFPとベンダー評価の土台です。曖昧な要件では提案を同じ条件で比べられず、選定が主観的になります。そのため、何を実現し、どの品質で動かすかを要件定義で明文化しておくことが、客観的なベンダー選定の前提になります。
データ移行要件と刷新後のKPI設定
データ移行は基幹システム刷新の難所です。要件定義では、移行するデータの範囲と変換方法を決めておきます。
移行要件と評価指標は、項目ごとに具体化しておきます。
- データマッピング：対象範囲と新旧項目の対応関係
- 変換ルール：新旧で意味が異なる項目の扱い
- 刷新後のKPI：処理時間、保守費、月次決算の目標
移行対象のデータマッピングは複雑になりやすく、曖昧なままだと移行時に大きな手戻りにつながります。そこで、移行要件は早い段階で詰めておくことが望まれます。
KPIは、刷新が成功したかを客観的に評価するための指標です。たとえば、夜間バッチの短縮や保守費の削減も、目標があれば成果として評価できます。
移行要件とKPIは、RFPにも記載します。要件定義の成果物をRFPに反映すると、上流工程の連続性が保たれ、ベンダーへの説明もしやすくなります。
RFPに盛り込むべき項目とベンダー評価の客観的基準
要件が固まったら、RFP（提案依頼書）にまとめてベンダーへ提示します。RFPは、各社の提案を同じ前提で集め、客観的に比べる土台です。
RFPの完成度が低いと、提案内容にばらつきが出て、見積金額の根拠も比べられなくなります。RFPに記載すべき項目を押さえたうえで、提案後は価格以外の観点で各社を評価します。
RFPに含めるべき具体的な項目
RFPでは、刷新の目的と提案の前提をそろえるため、各情報を具体的に伝えます。
- 現状と目的：刷新の背景や現行システムの構成図。
- 実現要件：機能・非機能要件、データ移行要件。
- 目標：性能要件と刷新後のKPI。
- プロジェクト条件：体制、スケジュール、予算、保守・運用の要望。
現行構成図は、ベンダーが提案の前提を正しく理解するために欠かせません。さらに、定量目標も記載すれば、各社が同じゴールに向けて提案できます。
SAPの2027年問題のように期限がある場合は、期限と段階的な移行スケジュールの考え方を示します。そうすると、提案の現実性を見極めやすくなります。
RFPは自社の要望を過不足なく伝える文書です。内容が曖昧だと、良い提案は集まりません。
また、要件を盛り込みすぎると、読み手が要点を見失うため注意が必要です。そこで、必須要件と希望要件を区別して優先度を示すと、ベンダーは限られた予算の中で重視点を判断できます。
要件定義の成果物を整理してRFPに反映する作業は、自社の要望を再点検する機会にもなります。
ベンダー評価の5つのチェックポイント
提案を受け取ったら、価格以外の5つのチェックポイントを使ってベンダーを評価します。
- 同業界・同規模の実績：類似する刷新経験の有無
- 段階移行の設計力：移行を分けて設計できるかどうか
- 停止時間の見積もり：ダウンタイムの見積もりが妥当か
- 保守体制：24時間365日の対応体制
- 品質・セキュリティ認証：ISO9001やISO27001の取得状況
5つの基準は、いずれも基幹システム刷新の失敗を避けるうえで欠かせません。
段階移行の設計力と停止時間の見積もりは、江崎グリコのような移行トラブルを避けられるかどうかに関わります。さらに、価格の安さだけで選ぶと、移行設計が不十分なベンダーを選んでしまい、事業停止という代償につながることがあります。
評価基準をRFPの段階で開示すると、各社が同じ観点で提案でき、比較の土台がそろいます。要件定義から評価まで、基準を一貫させます。
まとめ
アセスメントでは資産を棚卸しし、富士通のソフトウェア地図のようなツールも使って、ブラックボックスの中身を明らかにします。AS-ISとTO-BEのギャップを定め、Fit to Standardに基づいて標準に寄せる範囲を見極めます。
要件定義では、機能・非機能要件、データ移行要件、KPIを固めます。業務棚卸しを含む要件定義のみの費用は、200万〜500万円が目安です。上流への投資は、後の手戻りを大きく減らします。
RFPには、現行構成図、性能要件、移行後のKPIを盛り込みます。ベンダーを選ぶ際は、同業界・同規模の実績、段階移行の設計力、ダウンタイムの見積もりを確認します。また、24時間365日の保守体制とISO9001/27001の認証も評価します。
この5つの基準による評価が、刷新の成否を分けます。アセスメントからRFPまで連続して設計し、上流工程を丁寧に進めることは、プロジェクト全体のリスクを下げる一歩になります。
刷新全体の進め方や費用感、手法の選択肢を俯瞰したい場合は、完全ガイドもご活用ください。
▼全体ガイドの記事
・基幹システム/ERP刷新の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。