基幹システムやERPの更改は、経営管理・販売・購買・在庫・人事給与など業務の根幹を担うシステムが切り替わるため、進め方を誤ると数千万円から数億円規模の損失や業務停止のリスクにもつながりかねません。発注は、業務の棚卸しから始め、RFI・RFPで情報と提案を集めて評価し、リスクに備えて契約したうえで、発注後の運用管理へ進みます。
このテーマの全体ガイドは、次の記事にまとめています。
▼全体ガイドの記事
・基幹システム/ERP更改の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
基幹システム/ERP更改の発注前の準備
ERP更改プロジェクトを成功させる最大の決め手は、発注前の準備の質にあります。ベンダーへRFPを送る前に自社の業務実態を正確に把握できていないと、「要件が足りなかった」「想定外の業務フローが発覚した」といったトラブルが後から頻発します。そのため、まずは業務プロセスの棚卸しと体制構築を徹底して行うことが欠かせません。
業務プロセスの棚卸しとFit to Gap分析
業務プロセスの棚卸しとは、各部門が現在どのような業務フローで何を行っているかを一覧にする作業です。受注処理や在庫管理、請求発行、給与計算など、ERPが対象とする全業務の現状（As-Is）を図や文書にまとめます。この作業を省くと、RFP作成時に見積もりへ含まれていなかった業務が後から次々と発覚し、追加費用が膨らむ原因になります。
棚卸しが終わったら、次はFit to Gap分析に進みます。Fit to Gapとは、ERPパッケージの標準機能が自社業務に「合う（Fit）」か「合わない（Gap）」かを分析する手法です。Gapが見つかった箇所は、①業務プロセスをシステム標準に合わせる（Fit to Standard）、②システムをカスタマイズする、③アドオン開発で補う、の3つのいずれかで対応方針を決めます。
Gapの数と対応方針は開発費や保守費に直結するため、発注前にできる限り絞り込んでおくことが大切です。業界平均では、ERPのGapの約60〜70%は業務プロセス側を変えることで解消できると言われ、この割合を高めるほど、カスタマイズやバージョンアップ対応のコストを大幅に削減できます。また、Fit to Gap分析の結果を後述のRFPに盛り込むと、ベンダー提案の精度も格段に上がります。
IT人材不在の場合の体制構築
多くの中堅・中小企業では、社内にERPプロジェクトをリードできるIT人材がいないケースがほとんどです。「情報システム部門はいるが、ERP選定の経験はゼロ」という状況も珍しくなく、そのままベンダーに丸投げすると交渉力を失い、ベンダー主導で進む事態に陥ります。
体制構築では、最低限の役割を社内外で確保することを推奨します。プロジェクトオーナー（経営層）は意思決定者として全体の責任を持ち、プロジェクトマネージャー（PM）は日々のベンダー折衝と進捗管理を担います。業務キーユーザーは各部門の代表として、要件を代弁する立場になります。
社内のリソースだけでPMを担うのが難しい場合は、外部のITコンサルタントやPMO（プロジェクト管理オフィス）を活用する選択肢もあります。ITコンサルタントの費用は月100〜200万円程度が相場ですが、要件漏れや契約トラブルによるリスクを考えると、費用対効果は十分にあります。
RFI・RFPの作成方法と実践テンプレート
RFI（情報提供依頼書）とRFP（提案依頼書）は、ERP更改の発注プロセスの核となる文書です。RFIで市場とベンダーの概況を把握し、RFPで具体的な提案を引き出す2段階で進めると、プロジェクトの精度が高まります。それぞれの作成方法と、ERP特有の記載事項を押さえておきましょう。
ERP更改特有のRFI項目（Fit to Standard対応能力・実績確認）
RFIは、ベンダー各社の基本情報や製品概要を集めるための文書です。ERP更改では特に、Fit to Standardへの対応の実績と姿勢を確かめる質問を盛り込むことが大切です。
Fit to Standardとは、自社業務をERP標準機能に合わせてカスタマイズを最小化するアプローチで、長期の保守コストを抑えるうえで極めて有効です。
ERP更改のRFIでは、次の5項目を確認すると提案力を比較しやすくなります。
- 導入事例：過去3年間の業種、規模、カスタマイズ率
- 標準機能の適合率：自社業種へのカバレッジ率
- Fit to Standard実績：提案を主導した実績の有無
- 更新対応：バージョンアップ対応の方針と実績
- 運用保守：導入後の体制と応答時間SLA
特に③のFit to Standard提案を主導した実績は、ベンダーの本質的な提案力を測る指標です。「できる」と答えるベンダーは多いものの、具体的な事例を求めると実態が見えてきます。
RFPに盛り込むべき必須項目と書き方のコツ
RFPは、ベンダーに具体的な提案と見積もりを依頼する文書で、汎用的なシステム開発と違い、ERP更改では業務要件の網羅性と移行計画の明確さが特に重要です。RFPの質がそのまま提案の質に直結するため、作成には十分な時間を充てましょう。必須項目のうち「プロジェクト概要」には、更改の背景・目的・スケジュール感を記載します。
「業務要件一覧」には前述のFit to Gap分析結果を添付し、Fitの業務、Gapの業務、暫定的にアドオンで対応したい業務に分類して示します。「システム要件」では、連携対象システムやユーザー数、データ量を明記し、非機能要件（可用性・セキュリティ・レスポンスタイム）も書き込みます。「データ移行要件」では、移行対象のマスタとトランザクションデータの量と質（クレンジングの要否）を記載します。
提案書フォーマットの指定では、統一した形式で提案を受け取ると、各社の提案を並べて比べられます。要件は、あいまいな表現を避けて数値で定量的に書くことが基本で、「高速な処理を求める」より、「月次集計バッチは3時間以内に完了すること」のように数値で表します。また、優先度（必須・推奨・将来対応可）を付けることで、ベンダーは提案の焦点を絞れます。
予算記載の是非と発注側の駆け引き
RFPに予算を明記すべきかは、ERP発注で最も意見が割れるテーマの一つです。予算の上限はRFPに記載しないほうが有利です。上限を示すと、ベンダーはその上限額いっぱいに合わせた見積もりを作る傾向が強いためです。たとえば「予算は8,000万円」と記載すると、7,000万円で実現できる案件でも8,000万円近い見積もりが返ってくることが多くあります。
ベンダー側から見ると、提示された予算枠は「発注者が払える上限」という情報として使われます。一方、予算を伏せて複数社に提案させると、ベンダーは本来のコスト感覚で積み上げるため、競争原理が働いて適正価格に近い見積もりが集まります。
ただし、予算非提示には注意点もあり、予算感がずれて自社の想定の3倍の見積もりが返ってくる場合もあります。そこで推奨するのは、「予算の上限は非開示、ただし合理的な提案を期待している」という姿勢をRFP説明会で口頭で伝え、規模感の認識を合わせておくことです。また、選定フェーズに進んでからも、予算感の折り合いをつける交渉の余地は残ります。
ベンダー提案の評価・比較手法
ベンダー提案の評価を感覚や印象で決めると、あとで後悔する結果になりがちです。そのため、複数のベンダーを公平かつ多面的に比べられるよう、定量評価と定性評価を組み合わせた評価体制を整えておくことが大切です。
特にERP更改では、提案内容の技術的な正確さに加え、プロジェクトマネージャーの対応力や自社文化との親和性も、長期的な成功を左右します。
定量評価（スコアリングシート）の設計方法
スコアリングシートは、評価項目ごとに重み（ウェイト）を設定して、複数のベンダーを数値で比べるための表です。ERP更改では、「機能要件適合度」を30点、「コスト（総所有コスト5年）」を25点、「プロジェクト体制・PM経験」を20点とする配分がよく使われます。残りは、「導入実績・事例」が15点、「保守・サポート体制」が10点です。
各項目は5段階評価（1〜5点）で採点し、ウェイトを掛けた合計点でランク付けします。機能要件適合度は、RFPで要求した業務要件のうち標準機能で対応できる割合を数値にすると、客観性が生まれます。
コストは、初期費用だけでなくライセンス費・保守費・カスタマイズ費・インフラ費を5年間でトータル計算した「TCO（総所有コスト）」で比べるのが鉄則です。逆に、初期費用だけで判断すると、保守コストの高いベンダーを安易に選んでしまうリスクがあります。
Fit to Standard提案力と定性評価の見極め方
定量スコアでは測れない提案の質は、定性評価で見極めます。ERP更改では特に、業務を標準機能に合わせてカスタマイズを最小化し、保守コストを長期に抑えるFit to Standard提案力が重要です。提案力の高いベンダーを見分けるポイントは、主に3点です。
- Gapの解消方法：「業務プロセスを変えて解消する」と具体的に示せるか。「カスタマイズで対応」だけでは、保守負担を発注側に押し付けかねません。
- コンサルタントの関与：業種・業務に精通し、標準機能を熟知したうえで業務改革を提案できる人が関わっているかを、プレゼンの質問で確かめる。
- 過去案件のカスタマイズ率：導入案件のカスタマイズ率が低い（平均20%以下が目安）ベンダーほど、Fit to Standard提案が定着しています。
定性評価のもう一つの観点は、PMの対応力と企業文化との相性です。プレゼンや質疑応答で、担当PMが自社の業務課題を的確に理解しているか、質問への回答が具体的かつ誠実かを見ると、プロジェクト中のコミュニケーション品質を推測できます。大手ベンダーでは途中で担当者が変わるリスクもあるため、プロジェクト期間中の担当者変更ポリシーも確認しておく必要があります。
同点時の最終判断基準
スコアリングと定性評価を行っても、上位2社が拮抗するケースは少なくありません。そうした場合の最終判断基準として有効なのが、「リファレンスチェック」と「PoC（概念実証）」です。リファレンスチェックは、ベンダーが過去に対応した類似企業（同業種・同規模）の担当者に直接話を聞き、提案書には載らないプロジェクト運営の実態を把握する手法です。
ベンダーに「同業種の導入先を1〜2社紹介してほしい」と依頼するのが一般的なアプローチです。さらに、PoCは、特定の業務モジュール（例：受注処理画面）を実際にERPパッケージで動かしてもらい、使い勝手とFitの度合いを体験する手法です。
費用と期間は発生しますが、導入後の現場ユーザーの受容度に大きく影響するため、大型案件では実施する価値があります。最終的にリファレンスとPoCの結果が揃えば、数字では測れないリスクを軽減したうえで意思決定できます。
契約締結時に押さえるべきリスクヘッジ
ベンダーを選び、いよいよ契約締結という段階で法的リスクへの対策を怠ると、後々深刻なトラブルに発展しかねません。ERP更改では、要件漏れによる追加費用の請求、納期遅延、ベンダーロックインなど固有のリスクが多く、契約書にどう書くかが発注者の権利を守る決め手になります。
請負契約 vs 準委任契約の使い分け
ERP更改では、フェーズによって適した契約形態が異なります。請負契約は、仕事を完成させて納めることを義務づける契約で、要件定義が終わったあとの設計・開発・テストで主に使われます。完成しなければ報酬を支払わなくてよい一方、要件が曖昧なままだと、ベンダー側が追加費用を請求する根拠にもなりえます。
準委任契約は「業務の遂行」を目的とし、完成までは保証されないため、要件定義やアジャイル型のプロジェクトで使われることが多いです。実務では、フェーズ分割発注が一般的なリスクヘッジ手法です。要件定義を準委任で発注し、完成した要件定義書をもとに設計・開発を請負で発注します。
これにより、要件定義の段階でベンダーとの認識のずれを解消したうえで、開発に進む前に「この金額・スコープで開発します」という合意を取り付けられます。さらに、初期投資を分散できるほか、プロジェクト中断時の損害を限定できるメリットもあります。
ベンダーロックイン防止条項（データ所有権・SLA・脱依存）
ベンダーロックインとは、特定ベンダーへの依存が高まり、乗り換えや内製化が事実上困難になる状態です。ERP更改後には、「データを取り出せない」「保守費を大幅に値上げされた」「担当者が辞めたら誰もシステムが分からなくなった」といったトラブルが、実際に多発しています。これを防ぐには、契約段階で次の条項を明記することが不可欠です。
- データ所有権条項：蓄積されたすべてのデータ（マスタ・トランザクション・ログを含む）が発注者に帰属すると明記する。
- 契約終了時のデータ返還義務：契約終了から30日以内に、標準フォーマット（CSV等）でのデータ提供を定める。
- SLA（サービスレベル合意）条項：稼働率（例：月間99.9%以上）、障害時の一次応答時間（例：2時間以内）、復旧目標時間（RTO）を数値で合意する。
- SLA未達時のペナルティ：SLAを下回った場合の費用控除などを明記し、ベンダーの対応品質を担保する。
- 脱依存条項（移行支援義務）：契約終了時などに、現行ベンダーが後継への移行を合理的な範囲で支援する義務。
脱依存条項の対象は、ソースコードの提供や設計書の引き渡し、並行稼働の支援などです。この条項がないと、ベンダーから「移行支援は別途有償」「ソースコードは渡せない」と主張されかねません。
契約不適合責任・遅延損害金の取り決め
2020年の民法改正により、「瑕疵担保責任」は「契約不適合責任」に変わりました。契約不適合責任とは、納品されたシステムが契約内容に適合しない場合（バグ・機能不足など）に、ベンダーへ修補・代金減額・損害賠償を請求できる権利です。
契約書に「契約不適合責任の請求期間は納品後1年」などの特約があると、法定の期間（知った時から1年）より短くなる場合があるため、注意が必要です。また、ERP更改では本番稼働後に初めて発覚するバグも多いため、「本番稼働後12ヶ月以内に発見した不具合は無償修正対象」という条項を盛り込むことを推奨します。
遅延損害金は、納期を過ぎた場合にベンダーが発注者へ支払う損害補償です。一般的な設定は「遅延日数×契約金額×年率14.6%÷365」ですが、プロジェクトの実態に合わせて交渉することが大切です。ただし、ERPプロジェクトの遅延は発注者側の意思決定の遅れや追加要件の挿入によるものも多いため、「遅延原因が発注者にある場合は免責」という相互条項を設けるのが公平な取り決めです。
発注後のプロジェクト管理と障害対応
発注が終わると、プロジェクトはいよいよ実行フェーズに入ります。ERPプロジェクトは長期にわたり（中規模で12〜18ヶ月、大規模で2〜3年以上が一般的）、発注後も継続的に管理することが品質とスケジュールを左右します。
特に本番稼働直後は、障害や問い合わせが集中する「初期流動期間」になるため、事前の対応計画が業務継続を守るうえで欠かせません。
暫定対応（業務継続優先）と根本対応（バグ修正）の2段階フロー
本番稼働後に障害が起きたときは、業務を止めないことを最優先に考えます。そこで有効なのが「2段階対応フロー」で、第1段階の暫定対応では、根本原因の特定よりも業務継続を優先します。たとえば受注処理バッチが異常終了した場合、バグ修正に時間がかかるなら、手動処理やデータの直接投入で業務を回します。
次に、第2段階の根本対応では、暫定対応後に余裕ができた段階で原因を分析し、恒久的な修正を行います。そのうえで、この2段階フローはプロジェクト契約と運用手順書に明記しておくことが大切です。
「障害発生時の1次応答はXX時間以内」「暫定対応方針はYY時間以内に提示」「根本修正リリースはZZ営業日以内」といった時間軸を事前に合意しておくと、障害発生時の混乱を防ぎ、ベンダーとの期待値を揃えられます。また、稼働直後の3ヶ月は月1〜2件の重大障害が起きるプロジェクトも珍しくないため、対応フローは必ず事前に整備しておく必要があります。
初期流動管理の導入で稼働直後の混乱を最小化
初期流動管理とは、本番稼働直後の一定期間（通常1〜3ヶ月）を「特別管理期間」として設定し、通常より手厚いサポート体制を組む管理手法です。製造業の品質管理で普及している考え方ですが、ERPプロジェクトにも応用できます。具体的には、ベンダーから追加のサポートメンバーを現場に常駐または即応体制で配置し、問い合わせや操作の不明点に迅速に対応します。
初期流動管理の期間中に発生した問題は、「FAQ化」して社内ナレッジに蓄積することが大切です。同じ質問は繰り返されることが多いため、対応事例をナレッジベースに登録すると、ベンダー依存を早期に脱却できます。発注後は、月次の進捗報告会と課題管理台帳の運用も欠かせず、台帳には課題・担当者・期限・ステータスを記録して、毎回の会議で更新します。
また、この期間に把握した「使いにくい画面」「業務フローとのズレ」を後続の改善フェーズに引き継ぐことで、システムの定着率を高められます。初期流動管理の期間終了後には「定常運用移行審査」を設け、問題件数や未解決課題の数を基準に移行の可否を判断することをおすすめします。未解決課題が10件を超えたら、プロジェクトの健全性に黄色信号と捉え、スケジュール見直しや体制強化を検討するのが実務的な目安です。
まとめ
基幹システム・ERP更改の発注は、準備から運用管理までの一連の流れを適切に設計することで、プロジェクトの成功確率を大きく引き上げられます。発注前の準備では、業務プロセスの棚卸しとFit to Gap分析が欠かせません。Gapの箇所を、Fit to Standard（業務側の変更）で解消できるかどうかが、長期コストを左右します。
RFP作成では、予算の上限を非提示にする駆け引きが有効で、競争原理を働かせることで適正価格を引き出せます。ベンダー評価では、定量スコアリングとFit to Standard提案力の定性評価を組み合わせ、PMの対応力や企業文化との相性まで多角的に判断することが重要です。
契約では、データ所有権、SLA、脱依存（移行支援義務）の各条項でベンダーロックインを防ぎ、契約不適合責任と遅延損害金の条項で法的リスクに備えます。また、発注後は、初期流動管理と2段階の障害対応フローを整備しておくことで、本番稼働直後の混乱を抑え、システムの早期定着につなげられます。
ERP更改は企業の競争力を左右する大プロジェクトですが、正しい知識と準備があれば、発注側が主導権を持って進められます。本記事が貴社の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を創業。