基幹システムやERPのリニューアルは、企業の業務プロセス全体に影響を与える大規模プロジェクトです。発注先の選定を誤ったり、契約内容が曖昧だったりすると、数千万円から数億円規模の投資が無駄になりかねません。

本記事では、基幹システム・ERPリニューアルの発注方法について、発注前の準備からRFP作成・契約形態の選択・プロジェクト管理・ベンダーロックイン対策まで実践的に解説します。発注者が主導権を握り、プロジェクトを成功に導くためのポイントを網羅していますので、ぜひ最後までお読みください。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・基幹システム/ERPリニューアルの完全ガイド

基幹システム/ERPリニューアルの発注前準備

基幹システム・ERPのリニューアルプロジェクトは、準備段階の質が成否を大きく左右します。発注前に内部の課題と要件を徹底的に整理しておくことで、ベンダーへの依存度を下げ、適切な発注判断ができるようになります。

ERPリニューアルの最初のステップは、現行業務プロセスの全体像を把握することです。「なんとなく使いにくい」「処理が遅い」といった感覚的な不満だけでは、発注先に適切な要件を伝えられません。各部門のキーパーソンへのヒアリングを実施し、業務フローを図式化・文書化することから始めましょう。

業務プロセスの可視化では、現行システムで行っている処理の一覧（業務機能一覧）、各業務の処理頻度・データ量・関係部門、Excelや手作業で補完している業務（システム化されていない領域）、他システムとのデータ連携フローを整理します。この棚卸しを行うことで、「本当にシステムで解決すべき課題」と「業務ルールや運用の問題」を切り分けられます。ベンダーに依頼する前に課題の根本原因を特定しておくことが、発注範囲の適正化につながります。

また、現行システムの技術的な問題（レガシー言語・ハードウェアの老朽化・ベンダーサポート終了）と業務課題（処理速度・操作性・機能不足）を分けて整理することも重要です。両者を混同すると、本来不要なシステム刷新を過剰に行うリスクがあります。課題の優先度と影響度をマトリクスで整理し、リニューアルで解決すべき課題を経営層と合意しておきましょう。

ERP・基幹システムのリニューアルにおける発注先は大きく3つに分類されます。それぞれの特徴と適合するケースを理解した上で選択することが重要です。

パッケージベンダー（SAP・Oracle・Infor・弥生・マネーフォワードなど）は、自社製品の導入支援・カスタマイズを行います。標準機能が充実しており、導入実績が豊富なため品質が安定しています。一方で、パッケージの制約に合わせた業務プロセス変更（Fit to Standard）が求められる場面も多く、大規模カスタマイズを行うとコストが高騰しやすくなります。業務プロセスをERPのベストプラクティスに合わせられる企業、または中堅・中小企業でスタンダードな機能で充足できる場合に向いています。

SIer（システムインテグレーター）は、パッケージの選定支援からカスタム開発・インフラ構築まで一括で担います。要件に合わせた柔軟な対応が可能ですが、開発費・保守費が高くなる傾向があります。複数のシステムを連携させる必要がある複雑な環境や、業界特有の要件が多い企業に向いています。

ITコンサルティングファームは、要件定義・ベンダー選定・PMO支援など上流工程に特化します。大規模プロジェクトでの意思決定支援や、社内にIT専門人材が不足している場合に有効です。ただし、コンサルと実装ベンダーが分かれる場合は責任分界点を明確にしておく必要があります。自社のIT組織の成熟度と予算規模に応じて、コンサルと実装ベンダーの組み合わせを検討しましょう。

ERP導入・リニューアルは、IT部門だけのプロジェクトではありません。経理・人事・製造・営業など全業務部門に影響が及ぶため、強力な社内推進体制が不可欠です。プロジェクトオーナーとして役員クラスをアサインし、部門横断のステアリングコミッティを設置することを強くおすすめします。

社内推進体制の構築では、プロジェクトマネージャー（PM）の専任化が特に重要です。ERP導入を「片手間業務」で対応すると、意思決定が遅延し、ベンダーのペースに引きずられるリスクが高まります。各業務部門からキーユーザーを選定し、業務要件のインプット・受入テストへの参加・現場への変更管理を担わせる体制を作りましょう。

経営層の巻き込みは、プロジェクト中に必ず発生する「業務プロセス変更の意思決定」や「追加予算の承認」をスムーズに行うために不可欠です。月次での経営層向け進捗報告と、判断を求める事項の事前整理を習慣化することで、プロジェクトの停滞を防げます。

RFI・RFP作成のポイント（ERP特有）

RFI（情報提供依頼書）・RFP（提案依頼書）は、ベンダー選定の品質を決定づける重要なドキュメントです。ERP・基幹システム特有の要素を盛り込むことで、ベンダーからの提案の質が格段に向上します。

ERP向けRFPには、一般的なシステム開発RFPの項目に加えて、以下のERP特有の要素を明記する必要があります。

業務要件の粒度について：ERP向けRFPでは、業務機能の一覧だけでなく、業務フローの詳細レベル（L1〜L3）まで記載することが重要です。「受発注管理」という大分類ではなく、「発注書承認フローにおける承認権限（金額別・部門別）」といった粒度で要件を記述することで、ベンダー側が適切な見積もりと提案ができるようになります。業務要件の曖昧さが後工程での追加費用の温床となるため、できる限り詳細に記載してください。

カスタマイズ方針の明記は、ERP発注で特に重要です。「標準機能を最大限活用する（Fit to Standard）」か「自社業務に合わせてカスタマイズする」かを明示しましょう。カスタマイズ方針が曖昧だと、ベンダーによって提案内容が大きく異なり、比較評価が困難になります。また、カスタマイズの範囲を「バージョンアップに追随できるアドオン方式のみ許容」などと具体的に規定することで、将来の保守コストを抑制できます。

非機能要件についても、ERP特有の観点で記載が必要です。同時接続ユーザー数・ピーク時のトランザクション数・バッチ処理の時間帯と処理量・会計年度末など繁忙期の処理能力を具体的な数値で記載します。また、災害対策（DR）・RTO（目標復旧時間）・RPO（目標復旧時点）・監査ログの保存期間についても明確にしておきましょう。

データ移行はERPリニューアルで最もトラブルが発生しやすい領域の一つです。RFPにおいてデータ移行要件を詳細に記載することで、ベンダーからの適切な見積もりと計画を引き出せます。

RFPに記載すべきデータ移行要件の主な項目は、移行対象データの種類（マスタデータ・トランザクションデータ・履歴データ）と件数の概算、現行システムのデータ品質の現状（重複・欠損・コード体系の不統一など）、移行期間中の業務継続の方針（並行稼働の有無・期間）、移行後の検証方法と合格基準です。特に、過去何年分の履歴データを移行するかは、移行コストに直結するため明確にしておく必要があります。

データ移行の責任分界点も明確にしましょう。「データのクレンジング（整備）は発注者側が行う」「移行プログラムの開発・実行はベンダーが行う」「移行後の検証は双方で実施する」といった形で役割を明記します。データクレンジングはベンダーが見積もりに含めにくい領域であるため、発注者側で事前に現行データの品質確認を行い、その結果をRFPに添付することが理想的です。

ベンダー選定では、価格だけでなく多角的な評価基準を設定することが重要です。ERP・基幹システムのリニューアルでは、5〜10年以上の長期的な付き合いになるため、ベンダーの信頼性・サポート体制・財務基盤も評価に含めるべきです。

評価基準の例として、以下の観点を点数化して総合評価する方法をおすすめします。技術力・実績（同業種・同規模のERP導入実績、自社要件への適合度）、プロジェクト管理能力（プロジェクト推進計画の具体性、リスク管理アプローチ）、サポート・保守体制（SLAの内容、問い合わせ対応時間、バージョンアップへの対応方針）、コスト（初期費用・年間保守費用・将来的な追加開発コストの見通し）、企業信頼性（財務健全性・資本関係・継続性）。RFPにこれらの評価基準と配点を明示することで、ベンダー側も評価ポイントを意識した提案を行いやすくなります。

選定プロセスでは、一次評価（書類選考）→デモ・プレゼンテーション→参照先ヒアリング（レファレンスチェック）の3段階を経ることを推奨します。特にERPでは、デモを自社の業務シナリオに沿って実施させることが重要です。「想定している業務フローをデモで再現してほしい」と依頼することで、ベンダーの技術力と自社業務への理解度を同時に評価できます。

契約形態の選択と締結時の注意点

ERP・基幹システムのリニューアルプロジェクトでは、フェーズごとに最適な契約形態が異なります。契約形態の選択を誤ると、発注者・受注者双方にとって不利な状況が生まれます。また、ライセンス契約や保守契約には特有の落とし穴があるため、締結前に十分に確認することが重要です。

請負契約と準委任契約は、それぞれ特性が異なります。請負契約はベンダーが成果物を完成させる義務を負い、契約不適合責任が発生します。準委任契約はベンダーが業務遂行の努力義務を負い、成果物の完成責任はありません（履行割合型）または特定の成果物の納入義務を負います（成果完成型）。

要件定義・設計フェーズ：準委任契約（履行割合型）が適切です。要件定義や基本設計は、発注者との対話を通じて成果物が変化するため、完成形を事前に確定しにくい性質があります。準委任契約とすることで、ベンダーが柔軟に対応でき、発注者も途中で方針変更がしやすくなります。ただし、成果物（要件定義書・設計書）の記載レベルと承認基準を契約書に明記しておくことが必要です。

開発・テストフェーズ：請負契約が基本です。要件が固まった後の実装・テストフェーズは、成果物（ソースコード・テスト仕様書・テスト結果）を確定させやすいため、請負契約が適しています。ただし、大規模開発では機能単位で複数の請負契約に分割することも有効です。スコープが明確でない部分は準委任とし、確定した部分から請負に切り替えるハイブリッドアプローチも検討してください。

導入支援・移行フェーズ：準委任契約（成果完成型）が適切です。本番移行作業は予期せぬ事態が発生しやすく、柔軟な対応が求められます。準委任の成果完成型とすることで、ベンダーに移行完了の責任を持たせつつ、環境変化への対応を求めやすくなります。保守・運用フェーズ：SLA付きの準委任契約とし、対応時間・障害対応の優先度・品質基準を数値で規定しておきましょう。

ERPのライセンス契約には、一般のシステム開発では見られない特有の落とし穴があります。契約前に十分確認しておかないと、将来的に大きなコスト増や選択肢の制限につながります。

ライセンス課金モデルの確認は必須です。ERPのライセンスは「名前付きユーザー課金」「同時接続ユーザー課金」「モジュール単位課金」「トランザクション課金」など多様な課金モデルがあります。将来の事業拡大・組織変更・M&Aなどでユーザー数やトランザクション数が増加した場合のコストシミュレーションを行ってから契約することをおすすめします。特に、グループ会社への展開を視野に入れている場合は、エンタープライズライセンスの条件を確認しておきましょう。

保守契約の更新条件にも注意が必要です。ERPの保守料は初期ライセンス費用の15〜22%程度が相場ですが、ベンダーが一方的に保守料を引き上げる権利を持つ条項が含まれる場合があります。保守料の上限値（前年比〇%以内など）を契約書に明記することを交渉しましょう。また、保守契約を解約した場合のバージョンアップ権利・セキュリティパッチの提供有無も確認しておく必要があります。

カスタマイズの知的財産権についても確認が必要です。パッケージERPへのアドオン・カスタマイズの著作権がベンダー側に帰属する契約になっている場合、他社への移行時にカスタマイズ部分を移植できなくなります。カスタマイズ・アドオンの著作権は発注者または共有とし、ソースコードの開示を求めることを検討してください。

ERP導入プロジェクトでは、プロジェクト進行中に要件の変更や追加が頻繁に発生します。この変更要求（チェンジリクエスト）の取り扱いを最初の契約に明確に定めておくことが、コストの肥大化とプロジェクトの遅延を防ぐ鍵となります。

チェンジリクエストの管理プロセスとして、変更要求の申請フォーマット・評価手順・承認権限者・費用見積もりの期限・ベースラインへの反映ルールを契約書または別紙のプロジェクト管理規程として定義しましょう。「軽微な変更」と「重要な変更」の区分基準（工数の閾値など）も明確化しておくと、都度の交渉コストを削減できます。変更管理台帳を共有ドキュメントとして管理し、変更の経緯・承認状況・コストへの影響を見える化することが重要です。

【独自】発注者が主導権を握るプロジェクト管理術

ERP・基幹システムのリニューアルが炎上する最大の原因の一つは、発注者がプロジェクト管理をベンダーに丸投げしてしまうことです。発注者側のプロジェクトマネジメント能力がプロジェクト成否を大きく左右します。ここでは発注者が主導権を握るための実践的な手法を解説します。

進捗管理を形骸化させないためには、ベンダーが提出するWBS（作業分解構造）を発注者側でも理解・モニタリングできる体制を作ることが重要です。「ベンダーが週次で進捗報告を出しているから大丈夫」という認識は危険です。報告書の内容が実態と乖離していても、発注者側に検証能力がないと問題を見抜けません。

進捗管理の実践的な仕組みとして、タスクレベルの進捗を可視化するWBSの共有管理、週次での作業実績（消化工数・残タスク数）の定点観測、マイルストーンごとの「完了基準」を事前に文書で定義すること（「設計書レビュー完了」ではなく「設計書のレビューで指摘事項ゼロ件となり発注者の承認を得た状態」というレベルで定義）が有効です。また、進捗が遅れた場合の挽回計画の提出を義務づけ、挽回計画の実現可能性を発注者側で評価する習慣をつけましょう。

進捗の「健全性指標」として、EVM（アーンドバリューマネジメント）の活用も検討してください。SPI（スケジュール効率指数）・CPI（コスト効率指数）を毎週モニタリングすることで、プロジェクトの遅延・コスト超過を早期に検知できます。ERP導入の大規模プロジェクトでは、特に重要な管理手法です。

長期間にわたるERP導入プロジェクトでは、口頭での指示や会議での決定事項が後から争点になるケースが頻繁に発生します。「ベンダーが要件変更を承認したと思っていた」「そんな仕様は聞いていない」というトラブルを防ぐために、ドキュメント管理の体制を最初から設計しておくことが重要です。

ドキュメント管理の実践的な手法として、すべての会議・打ち合わせで議事録を作成し、次回会議前にベンダー側の確認・署名（または電子承認）を得ることが基本です。特に「決定事項」「宿題事項」「懸案事項」を明確に分類し、担当者・期限を記録することが重要です。口頭での指示・依頼は、会議後24時間以内にメール・チャットで文書化する習慣を徹底しましょう。要件の変更・追加は必ず変更管理台帳に記録し、発注者・ベンダー双方の承認を証跡として残します。

ドキュメントの保管場所についても、プロジェクト開始時に共有フォルダ・バージョン管理のルールを決めておきましょう。ベンダーがドキュメントを自社サーバーのみで管理している状況は避け、発注者側がいつでもアクセスできる共有環境（プロジェクト管理ツール・SharePoint・Google Workspaceなど）での管理を基本とします。

ERP導入プロジェクトの炎上には、必ず事前の兆候があります。以下のサインを見逃さないようにしましょう。

炎上の初期兆候として、会議での決定事項が次の会議で守られていない（宿題の未完了が続く）、進捗報告が曖昧・楽観的すぎる（「90%完了」が何週間も続く）、ベンダーのプロジェクトマネージャーが頻繁に交代する、成果物のレビューで大量の指摘が出続ける、といった状況が挙げられます。これらの兆候が見られた場合は、早期にエスカレーションすることが重要です。

早期察知後の対処法として、まず現状の正確な把握から始めます。ベンダーのPMとの1on1を設定し、根本原因（要員不足・技術的課題・スコープ認識のずれ）を特定します。原因に応じて、要員増強・スコープ削減・スケジュール見直しのいずれかまたは組み合わせを発注者側から提案します。経営層へのエスカレーションも早期に行い、追加予算・スケジュール延長の意思決定を速やかに行うことが、最終的な損失を最小化します。問題の発覚を先送りにするほど解決コストが増大するため、「小さな問題を早く・大きな問題を素早く」の原則で対処しましょう。

ベンダーロックイン対策

ERP・基幹システムにおけるベンダーロックインは、特定のベンダーへの依存度が高まることで、乗り換えコストが極めて高くなる状態を指します。一度ロックインされると、ベンダーとの交渉力が著しく低下し、不当に高い保守費用を受け入れざるを得なくなるリスクがあります。導入時からロックイン対策を意識することが重要です。

ERP特有のロックイン問題は主に3つあります。データのロックイン、ライセンスのロックイン、そしてスキル・ノウハウのロックインです。

データのロックインは、ERPのデータが独自フォーマット・独自データベース構造で保存されており、他システムへのデータ移行が困難になる問題です。特に、ERPベンダーが提供するAPIのみでデータにアクセスできる閉鎖的な設計や、データのエクスポート機能が限定的・有料オプションになっているケースに注意が必要です。

ライセンスのロックインは、投資済みのライセンス費用の埋没コスト効果と、移行時に既存ライセンスが無価値になることへの心理的・財務的障壁です。また、ERPベンダーが自社製品のエコシステム（BI・CRM・HRMなど周辺製品）との連携を強みとして訴求することで、追加のERPモジュールを導入させ、依存度を高めるケースもあります。

スキル・ノウハウのロックインは、特定のERP製品に精通した人材が社内に蓄積されることで、他製品への移行コスト（再教育・再習熟）が高くなる問題です。内部人材のスキルが特定ベンダーに偏らないよう、汎用的なIT・PM・データ管理スキルの育成も並行して行うことをおすすめします。

データポータビリティを確保するための具体的な対策を、導入時の契約段階から組み込んでおくことが重要です。

契約段階での対策として、「契約終了時のデータ提供義務」を契約書に明記しましょう。データのフォーマット（CSV・XML・JSONなど標準的な形式）・提供方法・提供期限（契約終了後〇ヶ月以内）・費用（無償または上限金額）を具体的に規定します。また、定期的なデータエクスポート（毎年の全データバックアップ提供など）を権利として契約書に盛り込むことも有効です。

技術的な対策として、ERPと他システムの連携にはなるべく標準API（REST API）・標準フォーマット（EDI・XML）を採用し、独自の連携方式への依存を避けることをおすすめします。データウェアハウスやデータレイクへのデータレプリケーションを仕組みとして構築しておくことで、ERPからのデータ抽出を恒常的に行い、ERPに依存しない分析・活用ができる環境を確保できます。

更新・移行交渉術として、保守契約の更新時は複数のERP製品の評価を実施したと示すことが有効です。実際に他ベンダーからのRFI・見積もりを取得しておくことで、現行ベンダーとの交渉において対等な立場を保てます。長期保守契約（3年・5年）は割引率が高い反面、値上げ交渉力が低下するため、契約期間と値上げ上限の条項をセットで交渉することが重要です。

まとめ

基幹システム・ERPのリニューアルは、企業の経営基盤を左右する大型プロジェクトです。発注前の準備からベンダーロックイン対策まで、多くの判断ポイントがありますが、成功の鍵は「発注者が主体性を持って関与し続けること」に尽きます。

本記事でお伝えした主なポイントをおさらいします。第一に、発注前に現行業務プロセスを可視化し、課題を経営層と合意してから発注先の選定を行うことが重要です。第二に、RFPにはERP特有の要素（業務要件の粒度・カスタマイズ方針・データ移行要件）を詳細に記載し、ベンダーから質の高い提案を引き出しましょう。第三に、フェーズごとに最適な契約形態（請負/準委任）を使い分け、ライセンス・保守契約の落とし穴にも注意が必要です。

第四に、プロジェクト管理は発注者側の専任PMが主導し、WBSの共有管理・議事録の徹底・炎上兆候の早期察知を実践することが肝要です。第五に、ベンダーロックイン対策として、データポータビリティを契約に明記し、技術的にも標準APIの活用とデータレプリケーションの仕組みを構築しておきましょう。

基幹システム・ERPのリニューアルは、適切に進めれば企業の競争力を大きく向上させる投資です。本記事の内容を参考に、発注者として主導権を握りながらプロジェクトを成功に導いてください。不安な点や詳細なご相談については、ぜひ専門家へのご相談もご活用ください。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・基幹システム/ERPリニューアルの完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また「Boxシリーズ」による、受発注管理・在庫管理・配送管理・業務システム・生成AI・SaaS・マッチングサイト・EC・アプリ・LINEミニアプリなどの標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」を活用することで、低コスト・短期間でのスクラッチ開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。