基幹システム・ERPのリニューアルは、準備、発注先の選定、契約、プロジェクト管理、ベンダーロックイン対策の順に、発注者が主導して進めます。
発注先の選定や契約を誤ると、数千万円から数億円規模の投資が無駄になりかねません。全体像は、次の完全ガイドにまとめています。
▼全体ガイドの記事
・基幹システム/ERPリニューアルの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
基幹システム/ERPリニューアルの発注前準備
基幹システム・ERPのリニューアルは、準備段階の質が成否を大きく左右します。そのため、発注前に内部の課題と要件を整理しておくと、ベンダーへの依存度を下げ、適切な発注判断ができます。
現行業務プロセスの可視化と課題整理
ERPリニューアルの最初のステップは、現行業務プロセスの全体像を把握することです。「なんとなく使いにくい」「処理が遅い」といった感覚的な不満だけでは、発注先に適切な要件を伝えられません。そこで、各部門のキーパーソンにヒアリングして業務フローを図にまとめるとともに、ベンダーに依頼する前に課題の根本原因を特定しておくと、発注範囲の適正化につながります。
業務プロセスの可視化では、現行システムの処理の一覧（業務機能一覧）と、各業務の処理頻度、データ量、関係部門を整理します。さらに、Excelや手作業で補っている業務（システム化されていない領域）と、他システムとのデータ連携の流れも洗い出します。この作業で、「本当にシステムで解決すべき課題」と「業務ルールや運用の問題」を切り分けられます。
現行システムの技術的な問題（レガシー言語・ハードウェアの老朽化・ベンダーサポート終了）と、業務課題（処理速度・操作性・機能不足）は、分けて整理します。両者を混同すると、本来は不要なシステム刷新まで過剰に行うおそれがあります。そこで、課題の優先度と影響度を表にまとめ、リニューアルで解決する課題を経営層と合意しておきます。
発注先タイプの選択（パッケージベンダー/SIer/コンサル）
発注先は大きく3つに分かれ、特徴と適合するケースを理解して選ぶ必要があります。パッケージベンダー（SAP・Oracle・Infor・弥生・マネーフォワードなど）は、自社製品の導入支援やカスタマイズを行い、標準機能と導入実績から品質が安定しています。ただし、制約に合わせた業務変更（Fit to Standard）が求められる場面が多く、大規模なカスタマイズはコストが高騰しやすくなります。
パッケージは、業務をERPのベストプラクティスに合わせられる企業や、中堅・中小企業で標準機能で足りる場合に適しています。SIer（システムインテグレーター）は、パッケージの選定支援からカスタム開発・インフラ構築まで一括で担い、要件に合わせた柔軟な対応が可能です。ただし、開発費・保守費が高くなる傾向があります。
SIerは、複数システムの連携や業界特有の要件が多い企業に向いています。ITコンサルティングファームは、要件定義・ベンダー選定・PMO支援など上流工程に特化し、社内にIT専門人材が不足する場合に有効です。コンサルと実装ベンダーが分かれる場合は責任分界点を明確にし、IT組織の成熟度と予算規模に応じて組み合わせを検討しましょう。
社内推進体制の構築と経営層の巻き込み
ERP導入・リニューアルは、経理・人事・製造・営業など全業務部門に影響が及びます。そのため、強力な社内推進体制が欠かせません。プロジェクトオーナーには役員クラスを充て、部門横断のステアリングコミッティを設けることをおすすめします。
特に、プロジェクトマネージャー（PM）は専任にすることが大切です。ERP導入を「片手間業務」で進めると、意思決定が遅れ、ベンダーのペースに引きずられやすくなります。各業務部門からキーユーザーを選び、業務要件の提示、受入テストへの参加、現場への変更管理を担ってもらいます。
プロジェクト中には、業務プロセス変更の意思決定や追加予算の承認が必ず発生します。だからこそ、経営層を巻き込んでおく必要があります。月次で経営層に進捗を報告し、判断を求める事項を事前に整理しておくと、プロジェクトの停滞を防げます。
RFI・RFP作成のポイント（ERP特有）
RFI（情報提供依頼書）・RFP（提案依頼書）は、ベンダー選定の質を左右する文書です。ERP・基幹システム向けのRFPには、一般的なシステム開発のRFPの項目に加えて、ERP特有の要素を盛り込む必要があります。その要素があると、ベンダーからの提案の質が格段に上がります。
RFP必須記載項目とカスタマイズ方針の明記
業務要件の粒度について：ERP向けRFPでは、業務機能の一覧だけでなく、業務フローの詳細レベル（L1〜L3）まで記載します。「受発注管理」と大分類で書くより、「発注書承認フローにおける承認権限（金額別・部門別）」のように書いたほうが、ベンダーは適切な見積もりや提案をしやすくなります。業務要件が曖昧だと後工程で追加費用が生じやすいため、できる限り詳細に書きます。
カスタマイズ方針の明記は、ERP発注で特に大切です。「標準機能を最大限活用する（Fit to Standard）」か、「自社業務に合わせてカスタマイズする」かを明示します。方針が曖昧だと、ベンダーごとに提案内容が大きく異なり、比較評価が難しくなります。また、カスタマイズの範囲を「バージョンアップに追随できるアドオン方式のみ許容」などと規定すると、将来の保守コストを抑えられます。
非機能要件も、ERP特有の観点で記載が必要です。同時接続ユーザー数、ピーク時のトランザクション数、バッチ処理の時間帯と処理量を、会計年度末など繁忙期の処理能力を含めて数値で書きます。あわせて、災害対策（DR）のRTO（目標復旧時間）とRPO（目標復旧時点）、監査ログの保存期間を明確にしておきます。
移行・データ移行要件の記述方法
データ移行は、ERPリニューアルで最もトラブルが起きやすい領域の一つです。そのため、RFPでデータ移行要件を詳しく書いておくと、ベンダーから適切な見積もりと計画を引き出せます。
RFPには、移行対象データの種類（マスタデータ、トランザクションデータ、履歴データ）と件数の概算を書きます。あわせて、現行データの品質（重複、欠損、コード体系の不統一など）も書きます。過去何年分の履歴データを移行するかは、移行コストに直結するため特に明確にしておく必要があります。
移行期間中の業務継続方針（並行稼働の有無・期間）と、移行後の検証方法・合格基準も、RFPに書いておきます。データ移行の責任分界点も明確にし、「クレンジングは発注者、移行プログラムの開発・実行はベンダー、検証は双方」のように役割を書きます。データクレンジングはベンダーが見積もりに含めにくいため、発注者が事前に現行データの品質を確認し、結果をRFPに添付するのが理想的です。
提案評価基準と選定の進め方
ベンダー選定では、価格だけでなく多角的な評価基準を設けることが大切です。ERP・基幹システムは5〜10年以上の長い付き合いになるため、ベンダーの信頼性、サポート体制、財務基盤も評価に含めるべきです。
評価基準の例として、以下の観点を点数化して総合評価する方法をおすすめします。
- 技術力・実績：同業種・同規模のERP導入実績と自社要件への適合度。
- プロジェクト管理能力：推進計画の具体性とリスク管理アプローチ。
- サポート・保守体制：SLA、問い合わせ対応時間、バージョンアップ方針。
- コスト：初期費用、年間保守費用、将来的な追加開発コストの見通し。
- 企業信頼性：財務健全性、資本関係、継続性。
RFPにこれらの評価基準と配点を明示すると、ベンダーも評価ポイントを踏まえた提案を行えます。
選定は、一次評価（書類選考）→デモ・プレゼンテーション→参照先ヒアリング（レファレンスチェック）の3段階で進めることをおすすめします。
特にERPでは、デモを自社の業務シナリオに沿って行ってもらうことが大切です。「想定している業務フローをデモで再現してほしい」と頼むと、ベンダーの技術力と自社業務への理解度を同時に確かめられます。
契約形態の選択と締結時の注意点
ERP・基幹システムのリニューアルでは、フェーズごとに最適な契約形態が異なります。契約形態の選択を誤ると、発注者・受注者の双方にとって不利な状況が生まれます。
ライセンス契約や保守契約には特有の落とし穴があり、締結前に十分確かめておかないと、将来的に大きなコスト増や選択肢の制限につながります。
フェーズ別の最適な契約形態（請負 vs 準委任）
請負契約では、ベンダーが成果物を完成させる義務を負い、契約不適合責任が生じます。準委任契約は業務遂行の努力義務を負い、履行割合型では成果物の完成責任はありません。要件定義・設計フェーズ：準委任契約（履行割合型）が適切です。
要件定義や基本設計は、発注者との対話で成果物が変わるため、完成形を事前に確定しにくい性質があります。準委任契約なら、ベンダーは柔軟に対応でき、発注者も途中で方針を変えやすくなります。スコープが不明確な部分は準委任とし、確定部分から請負に切り替えるハイブリッドな進め方も検討します。ただし、要件定義書や設計書の記載レベルと承認基準は、契約書に明記しておく必要があります。
開発・テストフェーズは請負契約が基本で、要件が固まれば成果物（ソースコード・テスト仕様書・テスト結果）を確定させやすく、大規模なら機能単位で分けることもできます。導入支援・移行は予期せぬ事態が起きやすいため、準委任契約（成果完成型）が適切です。保守・運用はSLA付きの準委任契約とし、対応時間、障害対応の優先度、品質基準を数値で定めます。
ライセンス契約・保守契約の落とし穴
ERPのライセンス契約には特有の落とし穴があり、ライセンス課金モデルの確認は必須です。名前付きユーザー課金、同時接続ユーザー課金、トランザクション課金などの違いを押さえます。事業拡大、組織変更、M&Aなどでユーザー数やトランザクション数が増えた場合のコストは、契約前にシミュレーションしておくことをおすすめします。グループ会社への展開を考えるなら、エンタープライズライセンスの条件も確認します。
保守契約の更新条件にも注意が必要です。保守料は初期ライセンス費用の15〜22%程度が相場ですが、ベンダーが一方的に保守料を引き上げられる条項が含まれる場合があります。そのため、保守料の上限値（前年比〇%以内など）を契約書に明記するよう交渉し、解約後のバージョンアップやセキュリティパッチの提供有無も確認します。
カスタマイズの知的財産権も確認が必要です。カスタマイズの著作権がベンダー側に帰属すると、他社への移行時にカスタマイズ部分を移植できなくなります。こうした事態を防ぐため、著作権は発注者または共有とし、ソースコードの開示を求めることを検討します。
スコープ変更・追加開発の取り決め
ERP導入プロジェクトでは、進行中に要件の変更や追加が頻繁に起きます。そのため、変更要求（チェンジリクエスト）の扱いを最初の契約で明確に定めておくことが、コストの膨張とプロジェクトの遅延を防ぐ鍵になります。
変更管理では、申請フォーマット、評価手順、承認権限者を決め、契約書または別紙のプロジェクト管理規程に定めます。さらに、費用見積もりの期限や、ベースラインへの反映ルールも同じ規程に含めます。「軽微な変更」と「重要な変更」の区分基準（工数の閾値など）を決めておくと、都度の交渉コストを削減できます。
発注者は、変更管理台帳を共有ドキュメントとして管理し、変更の経緯、承認状況、コストへの影響を一覧できるようにします。
【独自】発注者が主導権を握るプロジェクト管理術
ERP・基幹システムのリニューアルが炎上する最大の原因の一つは、発注者がプロジェクト管理をベンダーに丸投げしてしまうことです。
発注者側のプロジェクトマネジメント能力が、成否を大きく左右します。そのため、発注者が主導権を握るための実践的な手法を押さえておく必要があります。
ベンダー任せにしない進捗管理の仕組み
進捗管理を形骸化させないため、ベンダーが提出するWBS（作業分解構造）を、発注者側でも理解しモニタリングできる体制を作ります。「ベンダーが週次で進捗報告を出しているから大丈夫」と考えるのは危険です。報告書が実態と乖離していても、発注者側に検証能力がないと問題を見抜けません。
仕組みとしては、WBSの共有管理、週次の作業実績（消化工数・残タスク数）の定点観測、マイルストーンごとの完了基準の事前文書化が有効です。完了基準は、「設計書のレビューで指摘事項ゼロ件となり発注者の承認を得た状態」といったレベルで定義します。また、進捗が遅れた場合は挽回計画の提出を義務づけ、その実現可能性を発注者側で評価します。
進捗の「健全性指標」として、EVM（アーンドバリューマネジメント）の活用も検討します。SPI（スケジュール効率指数）とCPI（コスト効率指数）を毎週モニタリングすると、遅延やコスト超過を早期に検知できます。特にERPのような大規模プロジェクトで有効な管理手法です。
「言った言わない」防止のドキュメント管理
長期間のプロジェクトでは、口頭の指示や会議の決定事項が後から争点になることが頻繁にあります。「ベンダーが要件変更を承認したと思っていた」といったトラブルを防ぐには、ドキュメント管理の体制を最初から設計しておく必要があります。
基本は、すべての会議で議事録を作成し、次回会議の前にベンダー側の確認と署名（または電子承認）を得ることです。「決定事項」「宿題事項」「懸案事項」を分類し、担当者と期限を記録します。口頭の指示や依頼は、会議後24時間以内にメールかチャットで文書化する習慣を徹底します。
要件の変更や追加は、必ず変更管理台帳に記録し、発注者とベンダー双方の承認を証跡として残します。ドキュメントの保管場所も、プロジェクト開始時に共有フォルダやバージョン管理のルールを決めておきます。ベンダーの自社サーバーだけで管理する状況は避け、プロジェクト管理ツールやSharePoint、Google Workspaceなど、発注者がいつでもアクセスできる共有環境を基本とします。
炎上兆候の早期察知と対処法
ERP導入プロジェクトの炎上には、必ず事前の兆候があります。たとえば、会議の決定事項が次回も守られず宿題が未完了のまま続く、進捗報告が楽観的すぎて「90%完了」が何週間も続くといった状況です。ほかにも、ベンダーのPMが頻繁に交代する、成果物のレビューで大量の指摘が出続けるといった状況も兆候になります。
兆候が見られたら、まず現状を正確に把握するため、ベンダーのPMと1on1を設定します。要員不足、技術的課題、スコープ認識のずれといった根本原因を特定し、原因に応じて、要員増強、スコープ削減、スケジュール見直しのいずれか、あるいは組み合わせを発注者側から提案します。
経営層へのエスカレーションも早期に行い、追加予算やスケジュール延長の判断を速やかに下すことで、最終的な損失を最小化できます。問題の先送りは解決コストを増やすため、「小さな問題を早く・大きな問題を素早く」の原則で対処します。
ベンダーロックイン対策
ERP・基幹システムにおけるベンダーロックインとは、特定のベンダーへの依存度が高まり、乗り換えコストが極めて高くなる状態を指します。
一度ロックインされると、ベンダーとの交渉力が著しく低下し、不当に高い保守費用を受け入れざるを得なくなります。だからこそ、導入時からロックイン対策を意識しておくことが大切です。
ERP特有のデータ・ライセンス囲い込み問題
ERP特有のロックイン問題は、主に3つあります。データのロックインは、ERPのデータが独自フォーマットや独自のデータベース構造で保存され、他システムへの移行が困難になる問題です。特に、ベンダーのAPIのみでデータにアクセスできる閉鎖的な設計や、エクスポート機能が限定的または有料オプションになっているケースに注意が必要です。
ライセンスのロックインは、投資済みのライセンス費用の埋没コスト効果と、移行時に既存ライセンスが無価値になることへの心理的・財務的な障壁です。また、ベンダーがBI・CRM・HRMなど周辺製品との連携を強みに訴求し、追加のERPモジュールを導入させて依存度を高めるケースもあります。
スキル・ノウハウのロックインは、特定のERP製品に精通した人材が社内に蓄積され、他製品への移行時に再教育や再習熟のコストが高くなる問題です。内部人材が特定ベンダーに偏らないよう、汎用的なIT・PM・データ管理スキルの育成も並行して行うことをおすすめします。
データポータビリティの確保と移行時の交渉術
データポータビリティは、導入時の契約段階から確保しておくことが大切です。契約終了時のデータ提供義務を契約書に明記し、フォーマット（CSV・XML・JSONなど標準的な形式）、提供期限（契約終了後〇ヶ月以内）、費用（無償または上限金額）を具体的に定めます。また、毎年の全データバックアップ提供など、定期的なデータエクスポートを権利として盛り込むと有効です。
技術面では、ERPと他システムの連携に標準API（REST API）や標準フォーマット（EDI・XML）を採用し、独自の連携方式への依存を避けることをおすすめします。さらに、データウェアハウスやデータレイクへのデータレプリケーションを構築すると、ERPからのデータ抽出を恒常的に行え、ERPに依存しない分析・活用の環境を確保できます。
更新や移行の交渉では、保守契約の更新時に複数のERP製品を評価したと示すことが有効です。実際に他ベンダーからRFIや見積もりを取っておくと、現行ベンダーと対等な立場で交渉できます。長期保守契約（3年・5年）は割引率が高い反面、値上げ交渉力が低下するため、契約期間と値上げ上限の条項をセットで交渉する必要があります。
まとめ
基幹システム・ERPのリニューアルは、企業の経営基盤を左右する大型プロジェクトです。
発注前の準備からベンダーロックイン対策まで、多くの判断ポイントがありますが、成功の鍵は「発注者が主体性を持って関与し続けること」に尽きます。
発注の進め方は、次の5つに整理できます。
- 第一に、発注前に現行業務の課題を洗い出し、経営層と合意してから発注先を選定します。
- 第二に、RFPにERP特有の業務要件、カスタマイズ方針、データ移行要件を詳しく書き、質の高い提案を引き出すための土台です。
- 第三に、フェーズごとに請負と準委任を使い分け、ライセンス・保守契約の落とし穴にも注意します。
- 第四に、発注者側の専任PMがWBS・議事録・炎上兆候を管理し、プロジェクトを主導します。
- 第五に、データポータビリティを契約に明記し、標準APIとデータレプリケーションの活用を図ります。
基幹システム・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を創業。