基幹システムやERPの刷新プロジェクトが炎上する原因の多くは、開発の途中ではなく、その前段にある「アセスメント・要件定義・RFP」の不十分さにあります。現行システムの仕様書が失われていたり、業務がブラックボックス化していたりすると、何を刷新するのかを正確に定義できず、ベンダー選定も曖昧なまま進んでしまいます。SAP ERP（ECC6.0）の保守終了に伴う「2027年問題」を機にSAP S/4HANAへの移行を検討する企業でも、この上流工程の精度が刷新全体の成否を左右します。
本記事では、基幹システム/ERP刷新のアセスメント・要件定義・RFPについて、現状分析（AS-IS）の進め方、要件定義で固めるべき項目、そしてRFPに盛り込むべき内容とベンダー評価の客観的基準を、実務に即して体系的に解説します。刷新全体の流れや費用感を俯瞰したい場合は基幹システム/ERP刷新の完全ガイドをご覧ください。ここでは、その完全ガイドでは概要にとどまる「上流工程をどう設計するか」に絞り込み、RFP項目とベンダー評価観点まで踏み込んで解説します。
▼全体ガイドの記事
・基幹システム/ERP刷新の完全ガイド
刷新の起点となるアセスメントと現状分析（AS-IS）
基幹システム/ERP刷新は、いきなり要件定義から始めるものではありません。その前に、現行システムが「何を、どのように実現しているのか」を把握するアセスメント（現状分析）が必要です。長年使われてきた基幹システムは、当初の設計意図が失われ、ブラックボックス化していることが多いため、この現状把握こそが刷新の起点になります。
アセスメントを軽視すると、要件定義の段階で「現行システムが実は何をしていたのか」を誰も説明できないという事態に陥ります。刷新失敗の大きな原因として、現行システムの仕様書欠如やブラックボックス化による要件定義の不十分さが共通して挙げられているのは、まさにこのためです。本章では、アセスメントで何を明らかにすべきかを整理します。
資産の棚卸しとブラックボックスの可視化
アセスメントの第一歩は、現行システムの資産棚卸しです。どのような機能・プログラム・データ・連携が存在し、それぞれがどの業務を支えているのかを洗い出します。製造業のCOBOL基幹系刷新の成功事例でも、刷新の起点はいきなりの開発ではなく資産の棚卸しでした。棚卸しによって不要な機能を見極め、本当に必要な処理だけを新基盤へ載せ替える判断ができたのです。
棚卸しを効率化するために、ツールを活用する企業も増えています。たとえば富士通が提供する「ソフトウェア地図」は、アプリケーション資産の複雑度や依存関係を可視化するツールで、どのプログラムがどことつながっているかを地図のように示します。人手だけで巨大な基幹システムの依存関係を解きほぐすのは困難なため、こうした可視化ツールを併用することで、ブラックボックスの中身を効率的に明らかにできます。
棚卸しの成果は、単なる一覧表ではなく「刷新方針の根拠」として使うことが大切です。可視化によって、どの領域が複雑で危険か、どの機能はすでに使われていないか、どの連携が刷新の難所になるかが見えてきます。これらをもとに、前段で触れた7Rのような手法を領域ごとに割り当てていくことで、現実的な刷新計画の骨格ができあがります。
AS-ISからTO-BEへ、業務とのギャップを定義する
現状（AS-IS）を可視化したら、次にあるべき姿（TO-BE）を描き、両者のギャップを定義します。基幹システム刷新の目的は、現行をそのまま再現することではなく、業務をより良い形に変えることにあります。AS-ISの棚卸しは、いまの業務を温存するためではなく、「どこを変えるべきか」を見極めるために行うものだと位置づけることが重要です。
ここで意識したいのが、ERPの標準機能に業務を寄せる「Fit to Standard」の考え方です。現行業務をすべて新システムに再現しようとすると、独自カスタマイズが膨らみ、保守が重く費用も高くなります。AS-ISとTO-BEのギャップを定義する際には、「現行を再現すべき本質的な要件」と「標準機能に合わせて見直せる業務」を切り分けることが、後工程の費用と保守性を大きく左右します。
このギャップ定義の成果物が、次の要件定義のインプットになります。アセスメントと要件定義を別工程として切り離すのではなく、AS-ISの可視化からTO-BEのギャップ定義、そして要件定義へと連続した流れで進めることで、上流工程の手戻りを最小化できます。基幹システム刷新の精度は、この連続性をどれだけ保てるかにかかっています。
要件定義で固めるべき項目とまとめ方
アセスメントで現状と方針が見えたら、それを具体的な要件として固めていきます。要件定義では、機能要件（システムが何をするか）と非機能要件（性能・可用性・セキュリティなど、どのように動くか）の両面を漏れなく定義することが求められます。基幹システムは止まると全社の業務が止まるため、非機能要件の定義が他のシステム以上に重要になります。
要件定義のみを外部に依頼する場合の費用相場は、業務棚卸しを含めて200万〜500万円程度が目安です。一見すると小さくない金額ですが、ここを丁寧に固めるかどうかで、後続の開発・移行の手戻りコストが大きく変わります。上流工程への投資は、プロジェクト全体のリスクを下げる保険のようなものだと考えると判断しやすくなります。
機能要件と非機能要件の整理
機能要件では、刷新後の基幹システムが業務上どんな処理を実現するかを定義します。会計の締め処理、受注から出荷までの一連の流れ、在庫の引き当てロジックなど、業務に直結する処理を具体的に記述します。このとき、現行の挙動をそのまま書き写すのではなく、TO-BEで見直した業務に沿って定義することが重要です。Fit to Standardの方針に従い、標準機能で実現できる部分は標準に寄せると明記しておきます。
非機能要件では、性能・可用性・拡張性・セキュリティ・運用などの観点を定義します。たとえば夜間バッチの処理時間をどこまで短縮するか、システム停止が許容される時間はどれくらいか、ピーク時にどれだけの処理量に耐える必要があるか、といった事項です。製造業の事例で夜間バッチを8時間から90分へ短縮できたのも、こうした処理性能の目標を明確に置いたからこそ達成できた成果です。
機能要件と非機能要件は、後のRFPやベンダー評価の土台になります。要件が曖昧なままRFPを出すと、各社の提案を同じ土俵で比較できなくなり、選定が主観的になってしまいます。要件定義の段階で「何を実現し、どの品質で動かすか」を明文化しておくことが、客観的なベンダー選定の前提条件になるのです。
データ移行要件と刷新後のKPI設定
基幹システム刷新で特に難所となるのがデータ移行です。要件定義の段階で、どのデータを、どの範囲まで、どう変換して移行するかを定義しておく必要があります。移行対象のデータマッピングが複雑になりやすく、ここを曖昧にすると移行段階で大きな手戻りが発生します。新旧でデータ項目の意味が異なる場合の変換ルールまで、要件として詰めておくことが望まれます。
あわせて、刷新後のKPI（評価指標）も要件定義の段階で設定します。「処理時間を何分にする」「保守費を何割削減する」「月次決算を何営業日早める」といった具体的な目標を定めておくことで、刷新が成功したかどうかを客観的に評価できます。事例で見た夜間バッチの時間短縮や保守費の削減も、こうしたKPIがあったからこそ成果として語ることができたのです。
データ移行要件とKPIは、いずれもRFPに記載すべき重要項目です。要件定義の成果物をそのままRFPへ反映できるようにまとめておけば、上流工程の連続性が保たれ、ベンダーへの説明もスムーズになります。次章では、こうした要件をRFPにどう落とし込み、ベンダーをどう評価するかを見ていきます。
RFPに盛り込むべき項目とベンダー評価の客観的基準
要件が固まったら、それをRFP（提案依頼書）にまとめてベンダーに提示します。RFPは、各社から同じ前提で提案を集め、客観的に比較するための土台です。RFPの完成度が低いと、提案内容がばらつき、見積金額の根拠も比較できなくなります。本章では、RFPに盛り込むべき項目と、提案を受けたあとのベンダー評価基準を整理します。
RFPに含めるべき具体的な項目
RFPには、刷新の背景・目的に加えて、現行システムの構成図、機能要件・非機能要件、データ移行要件、そして刷新後のKPIを盛り込みます。とくに現行構成図は、ベンダーが提案の前提を正しく理解するために不可欠です。性能要件や移行後のKPIといった定量的な目標も明記することで、各社が同じゴールに向けて提案を作成できるようになります。
あわせて、プロジェクトの体制・スケジュール・予算の前提や、保守・運用に関する要望も記載します。SAPの2027年問題のように期限がある場合は、その期限と段階的な移行スケジュールへの考え方をRFPに明示しておくと、各社の提案の現実性を見極めやすくなります。RFPは「自社が何を求めているか」を過不足なく伝える文書であり、ここが曖昧だと良い提案は集まりません。
RFPを作成する際は、要件を盛り込みすぎて読み手が要点を見失わないよう注意します。必須要件と希望要件を区別し、優先度を示すことで、ベンダーは限られた予算の中で何を重視すべきかを判断できます。要件定義の成果物を整理してRFPに反映する作業そのものが、自社の要望を再点検する良い機会にもなります。
ベンダー評価の5つのチェックポイント
提案を受け取ったら、客観的な基準でベンダーを評価します。評価の軸として有効なのが、次の5つのチェックポイントです。第一に同業界・同規模の実績、第二に段階的な移行を設計できる力、第三にダウンタイム（停止時間）の見積もりの妥当性、第四に24時間365日の保守体制、第五にISO9001やISO27001といった品質・セキュリティの認証です。
これらは、いずれも基幹システム刷新の失敗を避けるために重要な観点です。とくに段階的な移行の設計力とダウンタイムの見積もりは、江崎グリコのような移行トラブルを回避できるかどうかに直結します。価格の安さだけで選ぶと、移行設計の甘いベンダーに当たり、結果として事業停止という高い代償を払うことになりかねません。
この5つの基準は、RFPの段階であらかじめベンダーに開示しておくのが効果的です。何を評価するかを先に示すことで、各社はその観点に沿った提案を作成し、比較が容易になります。要件定義からRFP、ベンダー評価までを一貫した基準で設計することが、基幹システム/ERP刷新の上流工程を成功させる鍵になります。
まとめ
本記事では、基幹システム/ERP刷新のアセスメント・要件定義・RFPについて解説してきました。まずアセスメントで資産を棚卸しし、富士通のソフトウェア地図のような可視化ツールも活用してブラックボックスを解きほぐします。そのうえでAS-ISからTO-BEへのギャップを定義し、Fit to Standardの方針で標準に寄せる部分を見極めることが、後工程の費用と保守性を左右します。
要件定義では、機能要件と非機能要件、データ移行要件、そして刷新後のKPIを固めます。要件定義のみの費用相場は200万〜500万円が目安ですが、この上流投資が後の手戻りを大きく減らします。RFPには現行構成図・性能要件・移行後のKPIを盛り込み、同業界・同規模の実績、段階移行の設計力、ダウンタイム見積もり、24時間365日の保守体制、ISO9001/27001の認証という5つの基準でベンダーを客観的に評価することが、刷新の成否を分けます。
自社の基幹システム/ERP刷新を検討する際は、まずアセスメントから要件定義、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を創業。