ERPリニューアルは、現状分析（アセスメント）で今の使われ方を把握し、要件をMust/Wantに仕分けてから、RFPで提案を依頼する順に進めます。
この順に進めると、現場で使われる仕組みにつながります。詳しくは基幹システム/ERPリニューアルの完全ガイドをご覧ください。
▼全体ガイドの記事
・基幹システム/ERPリニューアルの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
アセスメントと要件定義が成否を分ける理由
ERPリニューアルには、すでに動いているシステムと、それに慣れた現場が前提としてあります。そのため、新規開発とは違い、現状分析を出発点にします。
現状の問題や、変えるもの・残すものを把握しないまま理想だけを描くと、現実とかけ離れた要件になってしまいます。だからこそ、現状把握はリニューアルならではの重要な工程です。
要件定義・ディレクションの費用は、リニューアル総予算の一定割合を占めます。とはいえ、開発を急いでこの工程を削ると、後工程の食い違いや手戻りが増え、かえって高くつきます。
要件定義は、リニューアル全体の質を決める投資の対象であり、急いで通過する関門ではありません。
現状（As-Is）と理想（To-Be）の差分
リニューアルの要件は、現状（As-Is）と理想（To-Be）の差分から定めます。まず、現行ERPの使われ方や不満、非効率を洗い出すところから始めます。
- 現状を把握する：業務が依存している画面・機能・アドオン。
- 理想像を描く：リニューアル後に実現したい状態。
- 差分を要件にする：現状と理想の差を埋める内容を、要件として決める。
現状を把握しないまま進めると、変えてはいけないものを変えたり、変えるべきものを見落としたりするおそれがあります。このため、精緻にAs-Isを把握することが、要件定義の肝になります。
この考え方は、要件の絞り込みにも役立ちます。問題なく回っている部分は変えず、変更が必要な点に絞れば、実装可能な要件にまとめられます。
要件が肥大化する最大の落とし穴
要件定義では、各部署から機能追加などの要望が寄せられ、要件が肥大化しやすくなります。すべて受け入れると、費用も期間も当初の想定を大きく超える可能性があります。
また、アドオンを整理するために始めたリニューアルが、新たなアドオンの山を生むこともあります。
- Must（必須）：欠けるとリニューアルの目的を達成できない要件。
- Want（希望）：あれば望ましいが、なくても目的は達成できる要件。
まずMustだけで要件を固めると、肥大化を防ぎながら本質を外さずに済みます。ここで大切なのは、声の大きさではなく目的への貢献度で要望を仕分けることです。その規律が、肥大化を防ぐ唯一の方法です。
たとえば、「現場の入力時間を半減する」「保守費を下げる」といった目的に直結する要望はMustにします。目的に直結しない要望は、Wantに振り分けます。
アセスメント（現状分析）の具体的な進め方
要件定義の前段階となるのが、アセスメント（現状分析）です。現行ERPの使われ方や問題を正確に把握するため、業務・システム・データの3つの側面から確認します。
業務の側面：現場の使われ方と非効率の洗い出し
アセスメントの第一歩は、現場での使われ方の把握です。ヒアリングと観察で非効率を調べ、実際の操作も見せてもらうと、現場の人自身も気づいていない問題が見つかります。
- 使い方と不便：各部署の利用状況と、現場が感じている不便。
- 回避策：Excelでの二重管理など、現場が独自に行っている対応。
- 隠れた業務：ERP外の表計算ソフトや紙帳票による運用。
ERP外で行っている業務は、リニューアルで取り込むべき要件の手がかりになります。なぜ外で行っているのかを掘り下げると、画面・機能・運用のどこに問題があるかが見えてきます。
成果物は、現状の業務フローと課題の一覧です。その一覧は、どの業務をどの画面で行い、どこに非効率があるかを示し、要件定義の土台になります。
この段階で現場を巻き込むと、リニューアル後の定着にも役立ちます。自分たちの声が反映されたと感じられれば、現場は新しいERPを前向きに受け入れやすくなります。
システムとデータの側面：アドオンと連携の棚卸し
業務の把握と並行して、システムとデータの側面も確認します。長年運用したERPは中身が見えにくくなっていることがあり、その実態を調べるだけでも相応の工数がかかります。
- システム：アドオンの本数と利用状況、外部との連携。
- データ：取引先・商品マスタの中身、その量と品質。
- 帳票：レポートの種類と利用状況。
リニューアルでは、旧システムから新システムへのデータ移行が避けられません。形式・量・不整合を早めに把握しておけば、移行リスクの低減につながります。
現行のアドオンや連携、データの実態を踏まえないまま進めると、実装段階で移行できない、連携を切り離せないといった問題が起きます。このため、システムとデータのアセスメント結果は、要件定義の現実性を支えます。技術面の現状を正確に押さえれば、実装可能な要件を定義できます。
アセスメントは地味な工程ですが、その丁寧さがリニューアル全体のリスクを大きく左右します。
RFP（提案依頼書）に盛り込むべき項目と評価観点
アセスメントと要件定義で固めた内容は、RFP（提案依頼書）にしてベンダーへ伝えます。曖昧なRFPには曖昧な提案が返り、的確なRFPには的確な提案が集まります。
RFPに必ず盛り込むべき項目
ERPリニューアルのRFPには、次の情報を盛り込みます。項目が抜けると、ベンダーは前提を推測することになり、提案の精度が落ちます。
- 背景・目的：なぜ今行うのか、何を達成したいのか。
- 現状の課題：アセスメントで把握したAs-Isの問題点。
- 実現したい姿：To-Beと、Must/Wantに分けた要件。
- 現行システム：アドオン本数、外部連携、データ量。
- 移行計画・業務への影響：データ移行の範囲と方針、予算、希望スケジュール、既存業務への影響を抑える移行方式の希望。
特に重要なのは、現状の課題とデータ移行の範囲です。課題を具体的に伝えることで、ベンダーは適切な改善策を提案できます。
データ移行は、リニューアルの大きなリスク要因です。そのため、対象データの量や品質、移行方針を、早い段階でRFPに記して共有します。
また、Fit to Standardに関する自社の方針も明示します。アドオンを減らして標準機能に寄せるのか、残したい独自要件は何かを、ベンダーに伝えます。
方針が曖昧だと、ベンダーは安全側に倒して、再びアドオンだらけの提案をしてくることがあります。方針を明確にしておけば、標準機能を活かす提案を受けやすくなり、リニューアルの目的を見失わずに済みます。
提案を評価する観点とベンダー選定
提案を評価してベンダーを選ぶ際は、価格だけでなく複数の観点を見ます。リニューアルは長期の取り組みで、ベンダーとは数年にわたって付き合うことになるからです。
- 業界・業務の理解：自社の課題を正しく捉えているか。
- 標準機能の活用：Fit to Standardへの共感と提案力。
- 移行の進め方：データ移行や段階的な切り替えの具体性。
- 保守・運用：リニューアル後の体制とコスト。
- 類似実績：規模や業種が近いリニューアルの事例。
評価項目を点数化して、価格と合わせて総合的に判断します。特に、ベンダーが現状の課題をどれだけ正しく理解しているかを確かめます。
課題をなぞるだけでなく、背景を掘り下げて自社が気づいていない論点を指摘する提案は、信頼できるパートナーである可能性があります。そこで、課題理解と改善の発想力も、価格表と並べて見極めます。
ベンダー選定は、長期的な協業の入口です。安さだけで選ぶと、後の保守費が高くなったり、追加要望への対応が遅れたりして、結果的に割高になることもあります。
アセスメントから要件定義、RFP、ベンダー選定まで一貫した視点で進めると、ERPを使われる仕組みに作り替える目的を達成できます。
まとめ
リニューアルの要件定義では、現状（As-Is）と理想（To-Be）の差分を明らかにします。新規開発と違い、現状把握から始めるのがリニューアルの特徴です。
要件の肥大化を防ぐには、リニューアルの目的に立ち返り、Must/Wantに仕分けることが欠かせません。
アセスメントは業務・システム・データの3側面から進めます。使われ方や隠れた業務を押さえ、アドオン・連携・データの状態を把握することで、実装可能な要件の土台を作ります。
RFPには、背景や目的、課題を盛り込みます。加えて、To-Beとデータ移行、Fit to Standardの方針も示します。提案は、価格だけでなく、課題理解の深さや実績も含めて評価します。
ERPリニューアルでは、開発を急ぐ前にアセスメントと要件定義へ十分な時間をかけます。丁寧に進めると後工程の手戻りを減らし、全体の質を高められます。
進め方や費用感、見直す機能の全体像は、完全ガイドでも確認できます。要件定義を具体的なリニューアル計画につなげる際に活用できます。
▼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を創業。