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