基幹システムやERPの更改は、企業にとって数年に一度のビッグプロジェクトです。経営管理・販売・購買・在庫・人事給与など業務の根幹を担うシステムが切り替わるため、発注の進め方を誤ると数千万円から数億円規模の損失や、業務停止リスクにもつながりかねません。「どのベンダーに頼めばよいか分からない」「RFPをどう書けばよいか」「契約でトラブルになった」という声は多く、実際に要件漏れによる追加費用請求やプロジェクト遅延は珍しくない現実があります。
この記事では、基幹システム・ERP更改における発注・外注・委託の全プロセスを体系的に解説します。発注前の業務棚卸しからRFI・RFP作成、ベンダー評価、契約リスクヘッジ、発注後の運用管理まで、実務で使えるノウハウをまとめました。特に「RFPへの予算記載を避ける駆け引き」「Fit to Standard提案力でベンダーを見極める方法」など、他では語られにくいリアルな知見も盛り込んでいます。
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・基幹システム/ERP更改の完全ガイド
基幹システム/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標準機能に合わせることでカスタマイズを最小化するアプローチであり、長期的な保守コストを抑制する上で極めて有効です。
RFIに盛り込むべき主な確認項目は次のとおりです。①過去3年間のERP導入事例（業種・規模・カスタマイズ率）、②標準機能のカバレッジ率（自社業種に対する適合率の目安）、③Fit to Standard提案を主導した実績の有無、④バージョンアップ対応の方針と実績、⑤導入後の運用保守サポート体制と応答時間SLA。特に③の「Fit to Standard提案を主導した実績」はベンダーの本質的な提案力を測る指標です。「できる」と回答するベンダーは多いですが、具体的な事例を求めると実態が浮かび上がります。
RFPに盛り込むべき必須項目と書き方のコツ
RFPはベンダーに対して具体的な提案・見積もりを依頼する文書です。ERP更改のRFPは汎用的なシステム開発用と異なり、業務要件の網羅性と移行計画の明確さが特に重要です。RFPの質がそのまま提案の質に直結するため、作成に十分な時間を充てることを推奨します。
必須項目は以下のとおりです。「プロジェクト概要」では更改の背景・目的・スケジュール感を記載します。「業務要件一覧」には前述のFit to Gap分析結果を添付し、Fitの業務・Gapの業務・暫定的にアドオンで対応したい業務を分類して示します。「システム要件」では連携対象システム・ユーザー数・データ量・非機能要件（可用性・セキュリティ・レスポンスタイム）を明記します。「データ移行要件」では移行対象マスタ・トランザクションデータの量と質（クレンジングの要否）を記載します。「提案書フォーマット指定」では統一フォーマットで提案を受け取ることで比較が容易になります。
書き方のコツとして、要件はあいまいな表現を避けて定量的に記載することが基本です。「高速な処理を求める」ではなく「月次集計バッチは3時間以内に完了すること」のように数値で表現します。また、優先度（必須・推奨・将来対応可）を付けることで、ベンダーが提案の焦点を絞りやすくなります。
予算を記載すべきか？発注側の駆け引きノウハウ
「RFPに予算を明記すべきか」という問いは、ERP発注において最も意見が割れるテーマの一つです。結論から言えば、予算の上限はRFPに記載しない方が有利です。その理由は明確で、予算上限を提示するとベンダーが「その上限額いっぱいに合わせた見積もり」を作成する傾向が強いためです。
たとえば「予算は8,000万円」と記載すれば、7,000万円で実現可能な案件でも8,000万円近い見積もりが返ってくることが多くあります。ベンダー側からすれば、提示された予算枠は「発注者が払える上限」という情報として使われます。一方、予算非提示で複数社に提案させると、ベンダーは本来のコスト感覚で積み上げるため、競争原理が働き適正価格に近い見積もりが出やすくなります。
ただし、予算非提示には注意点もあります。予算感のミスマッチが起き、自社が想定する3倍の見積もりが返ってくる場合もあります。そこで推奨するのは「予算の上限は非開示、ただし合理的な提案を期待している」という姿勢をRFP説明会で口頭で伝え、ベンダーとのQ&Aセッションで規模感の認識を合わせておくことです。選定フェーズに進んでから予算感の折り合いをつける交渉の余地も残ります。
ベンダー提案の評価・比較手法
ベンダー提案の評価は、感覚や印象で決めてしまうと後から後悔しやすいフェーズです。複数のベンダーを公平かつ多面的に比較するために、定量評価と定性評価を組み合わせた評価体制を整えることが重要です。特にERP更改では、提案内容の技術的正確性に加え、プロジェクトマネージャーの対応力や自社文化との親和性も長期的な成功を左右します。
定量評価（スコアリングシート）の設計方法
スコアリングシートとは、評価項目ごとに重み（ウェイト）を設定し、複数のベンダーを数値で比較するための表です。ERP更改では以下の評価軸とウェイト配分が一般的です。「機能要件適合度」30点、「コスト（総所有コスト5年）」25点、「プロジェクト体制・PM経験」20点、「導入実績・事例」15点、「保守・サポート体制」10点という配分が実務でよく用いられます。
各項目は5段階評価（1〜5点）で採点し、ウェイトを掛け合わせた合計点でランク付けします。機能要件適合度は「RFPで要求した業務要件のうち標準機能で対応できる割合」を数値化することで客観性が生まれます。コストは初期費用だけでなく、ライセンス費・保守費・カスタマイズ費・インフラ費を5年間でトータル計算した「TCO（総所有コスト）」で比較することが鉄則です。単年度の初期費用だけで判断すると、保守コストが高いベンダーを安易に選んでしまうリスクがあります。
Fit to Standard提案力と定性評価の見極め方
定量スコアでは測れない「提案の質」を評価するのが定性評価です。ERP更改において特に重要な定性評価の観点が「Fit to Standard提案力」です。Fit to Standardとは、業務プロセスをERPの標準機能に合わせていくアプローチであり、カスタマイズを最小化することで導入コスト・保守コスト・バージョンアップ対応コストを長期にわたって抑制できます。
Fit to Standard提案力が高いベンダーを見分けるポイントは主に3点です。第一に、提案書の中で「このGapは業務プロセスを変えることで解消できる」と具体的に提案しているかどうかです。単に「カスタマイズで対応します」と記載するベンダーは、長期的な保守負担を発注側に押し付ける可能性があります。第二に、業種・業務に精通したコンサルタントが提案に関与しているかどうかです。ERPパッケージの標準機能を熟知した上で業務改革を提案できる人材がいるかを、プレゼンの質問で確かめましょう。第三に、過去の導入案件でのカスタマイズ率です。平均カスタマイズ率が低い（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を下回った場合のペナルティ（費用控除など）も明記しておくことで、ベンダーの対応品質を担保できます。
「脱依存条項（移行支援義務）」は、契約終了・ベンダー変更時に現行ベンダーが後継ベンダーへの移行を合理的な範囲で支援することを義務付けるものです。ソースコードの提供や設計書の引き渡し、移行期間中の並行稼働支援などが対象になります。この条項がないと、「移行支援は別途有償」「ソースコードは渡せない」とベンダーに主張される事態が生じます。
契約不適合責任・遅延損害金の取り決め
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件の重大障害が発生するプロジェクトも珍しくないため、対応フローは必ず事前に整備しておく必要があります。
初期流動管理の導入で稼働直後の混乱を最小化
初期流動管理とは、ERPの本番稼働直後の一定期間（通常1〜3ヶ月）を「特別管理期間」として設定し、通常運用よりも手厚いサポート体制を組む管理手法です。製造業では品質管理の文脈で普及している概念ですが、ERPプロジェクトにも応用できます。具体的には、ベンダーから追加サポートメンバーを現場に常駐または即応体制で配置し、エンドユーザーからの問い合わせ・操作不明点に迅速に対応します。
初期流動管理の期間中に発生した問題は「FAQ化」して社内ナレッジとして蓄積することも重要です。同じ質問が繰り返されることはよくあるため、対応事例をナレッジベースに登録することで、ベンダー依存を早期に脱却できます。また、この期間に把握した「使いにくい画面」「業務フローとのズレ」を後続の改善フェーズに引き継ぐことで、システムの定着率を高めることができます。初期流動管理の期間終了後に「定常運用移行審査」を設け、問題件数・未解決課題の数を基準に移行可否を判断することをおすすめします。
発注後のプロジェクト管理においては、月次の進捗報告会と課題管理台帳の運用も欠かせません。課題管理台帳には発生した課題・担当者・期限・ステータスを記録し、毎回の会議でステータスを更新します。未解決課題が10件を超えてきたらプロジェクトの健全性に黄色信号と捉え、スケジュール見直しや体制強化の検討タイミングと判断するのが実務的な目安です。
まとめ
基幹システム・ERP更改の発注は、準備・RFP・評価・契約・運用管理という一連のプロセスを適切に設計することで、プロジェクトの成功確率を大きく引き上げられます。本記事で解説したポイントを改めて整理します。
発注前の準備では、業務プロセスの棚卸しとFit to Gap分析が不可欠です。Gap箇所をいかに「Fit to Standard（業務側の変更）」で解消できるかが、長期コストを左右します。RFP作成では、予算の上限を非提示にする駆け引きが有効であり、競争原理を働かせることで適正価格を引き出せます。ベンダー評価では定量スコアリングとFit to Standard提案力の定性評価を組み合わせ、PMの対応力・企業文化との相性まで多角的に判断することが重要です。
契約では「データ所有権」「SLA」「脱依存（移行支援義務）」「契約不適合責任」「遅延損害金」の各条項を明記することでベンダーロックインと法的リスクを防ぎます。発注後は初期流動管理と2段階の障害対応フローを整備することで、本番稼働直後の混乱を最小化し、システムの早期定着を実現できます。
ERP更改は企業の競争力を左右する大プロジェクトですが、正しい知識と準備があれば発注側が主導権を持って進められます。本記事が貴社のERP更改プロジェクトの成功に少しでも貢献できれば幸いです。専門家への相談も活用しながら、ぜひ万全の体制でプロジェクトに臨んでください。
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・基幹システム/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を創業。