基幹システム/ERP刷新は、経営構造そのものを再設計するプロジェクトです。発注は社内準備から始め、RFP作成、ベンダー選定、契約を経て、現場定着へ進みます。
発注先の選定を誤れば数億円の損失や訴訟リスクに直結するため、社内準備とベンダー選定が成否を左右します。
▼全体ガイドの記事
・基幹システム/ERP刷新の完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
基幹システム/ERP刷新の発注前の社内準備
ERP刷新の成否は、RFPを書き始める前の社内準備段階でほぼ決まると言っても過言ではありません。ベンダーに相談する前に、自社の業務と現行システムを棚卸しし、経営層・現場・情シスの三者で共通認識をつくっておく必要があります。ここを省くと、後工程で要件変更が噴出し、スコープクリープと追加費用の温床になります。
現行基幹の棚卸しと業務As-Is/To-Be分析
まず着手するのは、現行基幹システムの完全な棚卸しです。マスタ数やトランザクション量、連携している周辺システムを網羅したシステム構成図を作成し、バッチ処理の依存関係も洗い出してください。この作業を怠ると、後から「実はあのサブシステムと繋がっていた」という事実が発覚し、追加開発費用が発生します。
次に、業務プロセスのAs-Is/To-Be分析に進みます。現状の業務フロー(As-Is)を部門横断で描き、刷新後のあるべき姿(To-Be)とのギャップを言語化します。BPMN記法で表せる粒度まで落とし込めれば、ベンダーとの要件認識の食い違いが激減します。
As-Is分析では現場ヒアリングを重視し、マニュアルに書かれていない「暗黙の運用ルール」まで拾い上げることが大切です。また、To-Be定義では経営目標との紐付けを明示し、刷新の投資対効果を定量化しておきます。
アドオンの棚卸しとFit to Standard判断
既存基幹システムに積み上がったアドオン(カスタマイズ機能)の棚卸しは、ERP刷新で最もセンシティブな工程です。アドオンごとに「業務上必須か」「標準機能で代替可能か」「そもそも使われているか」を判定し、Fit to Standard(標準機能に業務を合わせる)の方針を経営として決めます。
一般的にERPアドオンの3〜5割は実質使われていないか、標準機能で代替可能と言われています。ここで「残す・切る」の判断を明確にしないままベンダー選定に進むと、提案金額が2倍以上に膨らむリスクがあります。特に、Fit to Standardを徹底する方針を経営トップダウンで宣言することは、予算を圧縮するうえで最大の手立てです。
ただし、業界特有の法規制対応や差別化要因となる業務は、アドオンで残す正当性があります。アドオン判定マトリクスを作り、「売上貢献・法規制・標準代替可否」の3軸で仕分けると、意思決定がぶれにくくなります。
社内「システムキーパーソン」選出と稟議書
ERP刷新では、各部署から「システムキーパーソン」を選び、横断チームを組むことが欠かせません。ある食品加工工場では、生産・購買・在庫・経理の各部門から1名ずつキーパーソンを選び、要件定義から設計レビューまで一貫して関わらせることで、現場反発を最小化できたと報告されています。
キーパーソンには、業務知識と一定のIT理解力に加え、部門内で発言力のある人材を充てます。片手間では要件定義が形骸化するため、少なくとも稼働の50%以上をプロジェクトに割ける体制を組みます。
予算確保のための稟議書は、投資金額だけでなく「投資しない場合のリスク(既存システムEOL、法改正対応不能、競合優位性喪失)」を数値で示すことが鉄則です。ROIだけで稟議を書くと、経営層から「本当にそのリターンが出るのか」と突っ込まれ、通らないケースが多発します。
RFP(提案依頼書)の作り方と発注先の種類
RFP(Request For Proposal、提案依頼書)は、発注側がベンダーに要件を伝える公式文書で、プロジェクトの憲法とも言える存在です。RFPの精度が低いと、ベンダーごとに前提の違う提案が返ってきて、比較が成り立ちません。そこで、最低でも3社以上から提案を取り、同じ土俵で評価できる粒度で書くことが基本原則です。
RFPに記載すべき項目(業務要件、非機能要件、SLA想定)
ベンダーが同じ前提で提案を組めるように、RFPには5つの項目を書き込んでおきます。
- 背景・目的と対象業務範囲
- 機能要件と非機能要件
- スケジュールと予算レンジ
- 契約条件
- 提案書の様式と提出期限
機能面では、Fit to Standardの方針を明記したうえで、アドオン候補を別紙で添付するのが定石です。非機能面では、IPAの非機能要求グレードを参照し、5カテゴリを数値で示します。可用性、性能、運用保守の3つに加えて、セキュリティと移行性も含めます。
特にSLA(Service Level Agreement)の想定値は、後の契約交渉の土台になります。そのため、稼働率99.9%以上、オンライン応答時間3秒以内、障害復旧RTO4時間以内など、具体的な数値を提示しておきます。
予算は、開示するか非開示にするかで議論が分かれます。ただし、現実的な提案を引き出すには、レンジで開示することをおすすめします。非開示にすると、ベンダーが安全側に振った過剰見積もりを出してくるケースが多いためです。
発注先の種類(メーカー系・ユーザー系・独立系・コンサル系・外資系)
基幹システム/ERPの発注先は、大きく5種類に分けられます。メーカー系(富士通、日立、NECなど)は、自社ハードと一体のソリューションに強く、安定運用を重視する案件に向いています。ユーザー系(NTTデータ、ITホールディングス系列など)は、特定業界への深い知見が武器です。
独立系(大塚商会、TISなど)は、中立性とコスト競争力でバランスが取れており、中堅企業のERP刷新で採用例が多いカテゴリです。コンサル系(アクセンチュア、アビームなど)は、業務改革とセットでのERP導入に強みがあり、上流工程を含めた伴走を期待する場合に適しています。
外資系(SAP、Oracle、IBMなど)は、グローバル展開や複雑な連結会計に強い一方で、ローカライズ対応や費用面では国内ベンダーと比較検討が必要です。自社の業界特性、海外展開の有無、求める改革の深さによって、どのカテゴリに重点を置くかが変わります。そこで、RFPの送付先は異なるカテゴリから最低3社以上を選ぶと、バランスの取れた比較になります。
ベンダー比較・選定プロセスの進め方
複数社から提案を受けたあとは、単純な金額比較で決めず、技術評価・体制評価・実績評価・リスク評価の4つを多面的に行う必要があります。提案金額の差は、前提条件が異なれば見かけの差にすぎず、比べても意味がありません。そこで、RFPで定めた共通条件をもとに提案内容をそろえてから比べます。
最低3社からの提案取得と評価基準の設定
ERP刷新では、最低3社、可能なら5社程度から提案を取ることを推奨します。1社のみの提案では相場観が働かず、不当に高い金額や無理なスケジュールを見抜けません。また、2社比較では二項対立に陥りやすく、3社以上でこそ相対比較が機能します。
評価基準は、機能適合度、提案の具体性、プロジェクト体制を含めて、7〜10項目に分けます。類似実績、価格、リスク対応策も項目に加え、重み付け配点で総合評価します。価格の配点は全体の20〜30%程度に留め、品質項目を重く見ることが、炎上を避けるうえで大切です。
評価シートは、選定委員全員で事前に合意しておき、提案書を受け取った後に「情で判断」することを防ぎます。各委員が独立して採点し、差異の大きい項目について議論する形式が、主観の偏りを排除する定番手法です。
リファレンスチェック(過去クライアント直接確認)の実施手順
リファレンスチェックとは、ベンダーが過去に支援したクライアントに直接連絡し、実態を確認する調査手法です。提案書やWebサイトの事例紹介には都合の良い情報だけが載っているため、生の声を聞くことでしか見えない事実があります。最終候補2社まで絞った段階で、必ず実施すべきです。
実施手順としては、まずベンダーに事例紹介を依頼し、紹介先2〜3社にアポイントを取ります。質問では、予算と納期が守られたことや、トラブル時の対応を中心に聞きます。加えて、プロジェクトマネージャーの力量や運用フェーズでの付き合い方など、提案書に書けないリアルな部分も確かめます。
ベンダー経由の紹介だけでなく、業界団体のツテやLinkedIn経由など独自ルートから情報を得られれば、より客観的な評価ができます。また、リファレンスチェックで得たネガティブ情報は、契約交渉で条件改善を求める材料にも使えます。
キングジム事例「最安値ではなく成功への道筋」
文具メーカーのキングジムは、基幹システム刷新で、最終的に最高額を提示したJQ社を選んだと公表されています。決め手になったのは金額よりも、JQ社が旧システムの全構成を洗い出し、移行リスクを具体的に潰していく提案姿勢だったといいます。
安価な提案は一見魅力的ですが、裏には「リスクを発注側に押し付ける前提」や「要件の読み込みが浅い」といった問題が隠れていることが多いものです。ERP刷新のような数年単位のプロジェクトでは、初期コストの数%の差よりも、成功確率を高める提案のほうが、トータルで圧倒的に得になります。
「最安値ではなく成功への道筋で選ぶ」という判断基準を経営層と事前に合意しておくと、稟議段階で金額だけに引っ張られる事態を防げます。さらに、提案プレゼンでは「御社のリスク認識と回避策は何か」を必ず質問し、その深さで選ぶのが実務的なコツです。
契約締結のチェックリスト
ベンダー選定後の契約締結は、プロジェクトの成否を決める最重要フェーズです。契約書の文言ひとつで、障害発生時の責任範囲や損害賠償額が大きく変わります。そのため、法務部門だけでなく、プロジェクトマネージャーと経営層も内容を精査し、曖昧な表現を取り除く必要があります。
請負契約と準委任契約の選択基準
ERP刷新で用いられる契約形態は、主に請負契約と準委任契約の2種類です。請負契約は「成果物の完成」を義務とする契約で、要件が明確な設計・開発・テストフェーズに適しています。準委任契約は「業務の遂行」を義務とする契約で、要件定義や運用保守のように成果が事前に確定しにくい業務に向いています。
実務では、フェーズごとに契約形態を使い分ける多段階契約が主流です。要件定義は準委任、設計・開発は請負、運用保守は準委任、というように切り分けると、発注側・受注側双方のリスクのバランスが取れます。一方で、一括で請負契約を結ぶと、要件変更のたびに契約変更が必要になり、機動性を失います。
準委任契約にしたからといって、発注側が指揮命令できるわけではありません。指揮命令関係を発注側が持つと偽装請負の疑いが生じ、労働者派遣法違反となるリスクがあります。そのため、業務委託の範囲と指示系統の境界を契約書で明確にしておく必要があります。
SLA・瑕疵担保・損害賠償上限の交渉ポイント
SLA(サービスレベル合意)は、稼働率・応答時間・障害復旧時間などを数値で明文化する条項です。RFPで提示した想定値をもとに、ベンダー側と現実的な合意値を交渉します。未達のときのペナルティ(利用料減額や損害賠償)は、同時に定めておきます。
瑕疵担保責任(契約不適合責任)の期間は、民法改正後は「知った時から1年以内に通知」が基本ですが、特約で期間を延長または短縮できます。業務影響の大きい基幹システムでは、1〜2年の延長を交渉するのが一般的です。
損害賠償の上限は、ベンダー側が契約金額相当、または1回分の支払額に設定してくるケースが多いものの、基幹システム障害による逸失利益を考えると不十分な場合があります。重過失や故意の場合は、上限を外すか、上限額を引き上げる交渉が必要です。
スルガ銀行・NHK訴訟に学ぶ契約リスク
スルガ銀行と日本IBMの訴訟は、ERP刷新プロジェクト炎上の代表例として語り継がれています。約95億円を投じたものの要件定義段階で行き詰まり、最終的に計画が白紙撤回されました。訴訟では最高裁まで争われ、日本IBM側に42億円の賠償命令が確定しています。
また、2025年2月に報じられたNHKと日本IBMの訴訟でも、基幹システム開発を巡る発注側・受注側の責任分担が争点となりました。こうした訴訟は、契約書の曖昧さや要件定義段階での合意不足が、数十億円規模の損失に直結することを示しています。
契約締結時に織り込むべき教訓は明確です。要件定義フェーズの成果物と承認プロセスを契約に定めること、スコープ変更時の手続きと費用負担のルールを明記すること、プロジェクトマネジメントの義務を発注側・受注側の双方に負わせる双方向の契約にすることです。これらを曖昧にしたままサインすることが、最大のリスクです。
発注後のプロジェクト管理と現場定着
契約を締結しても、発注側の仕事は終わりません。ERP刷新は、発注後の推進マネジメントと現場定着こそが勝負どころです。
ベンダー任せにした瞬間から、要件のブレと現場の反発が重なり、計画は瓦解していきます。だからこそ、発注側としての主体的な関わりが、成功率を大きく左右します。
チェンジマネジメントとスポンサーロードマップ
チェンジマネジメントとは、システム導入に伴う組織・業務・人の変化を、計画的に管理する活動です。新しいERPが技術的に完璧でも、現場が使いこなせなければROIはゼロです。そこで、導入前後のコミュニケーション計画、研修プログラム、運用ルールの改訂までを、ひとつのロードマップとして設計します。
スポンサーロードマップとは、経営層(スポンサー)が各節目で社内にどんなメッセージを発信するかを、事前に計画する手法です。キックオフでのビジョン発信、要件定義完了時の合意表明、本稼働前の覚悟表明など、節目ごとにトップのコミットメントを示すことで、現場の協力を引き出します。
反対派が出てくるのは自然なことです。そのため、早期に発見して対話していく仕組みが必要です。「変革推進チーム」を別途組成し、部門ごとの温度差を把握しながら個別に対応していく体制が望ましいでしょう。
デジタルデバイドへの具体的対応
製造業や流通業のERP刷新では、高齢従業員を中心としたデジタルデバイド(ITリテラシー格差)が導入の障壁になります。ベンダー標準のUIをそのまま展開すると、操作に慣れない従業員がミスを連発し、業務停止の引き金になります。
具体的な対応としては、現場の業務フローに沿ったボタン配置のカスタマイズ、タブレット端末での大きな文字表示、音声ガイダンスの活用などが挙げられます。また、移行直後は紙の帳票を併用する「紙併用期間」を意図的に設け、段階的にデジタルへ寄せていく運用も効果的です。
研修は、画一的な集合研修だけでなく、現場の「教え役」を任命して日常業務の中でOJTを回す仕組みも取り入れると、定着が加速します。1回の研修で全員が覚えられるわけがないため、3〜6カ月の伴走体制を組むことが現実的です。
並行稼働・段階的移行によるリスク最小化
基幹システムの切り替えでは、新旧システムを一定期間並行稼働させる「パラレルラン」が定石です。1〜3カ月程度、新旧両システムに同じデータを入力して結果を突き合わせることで、移行後の不整合を早期に見つけられます。
全拠点・全業務を一斉に切り替える「ビッグバン方式」は、見た目はシンプルです。ただし、リスクが高く、トラブル時の影響が全社に及びます。そのため、可能な限り「段階的移行方式」を採用し、拠点単位・業務単位で順次切り替えていくほうが安全です。
移行日は、繁忙期や決算期を避け、業務影響が最小となる時期を選びます。移行リハーサルは本番前に最低2回実施し、問題が起きた場合の切り戻し手順(ロールバック)も事前に準備しておく必要があります。
プロジェクト炎上時の撤退戦略
ERP刷新プロジェクトの3〜5割は、何らかの形で失敗または大幅に遅延すると言われています。発注時点で「撤退の選択肢」を意識しておくことは、むしろ成功率を高める現実的なリスク管理です。炎上時の撤退は、サンクコストの判断と法務手続きの両面から考える必要があります。
サンクコストをいつ切り捨てるかの判断基準
サンクコスト(埋没費用)とは、既に支払い済みで回収できないコストのことです。プロジェクトの意思決定では、サンクコストを無視して「今から追加で投じる費用に対して得られるリターン」だけで判断するのが合理的です。ただし、心理的には「ここまでやったのだから」と引きずられがちです。
切り捨て判断の客観的な基準としては、定量的なトリガーを事前に設定しておくことが有効です。たとえば、「完成までに必要な追加予算が当初計画の2倍を超える」「本稼働時期が当初計画から1年以上遅延見込み」「要件定義が3回以上手戻りしている」といった条件が挙げられます。トリガーに抵触した時点で経営判断の俎上に載せる仕組みがあれば、判断の遅れを防げます。
撤退といっても、完全破棄のほかに、スコープを縮小する、フェーズを分けて進める、ベンダーを変えるなど、複数の選択肢があります。完全破棄が最も損失が大きいため、段階的な撤退の可能性を先に検討するのが定石です。
契約解除の法務手続きと責任分解
契約解除の手続きは契約形態によって異なり、請負契約は「仕事が未完成の間」であれば発注側がいつでも解除できますが、ベンダー側に生じた損害を賠償する義務があります。準委任契約は、相手方にとって不利な時期の解除でない限り、原則として双方がいつでも解除できます。解除は、内容証明郵便による正式な解除通知を送ることから始まります。
通知書には、解除理由(債務不履行、合意解除など)と根拠条項を明記します。成果物の扱いや既払金の精算方法も、書き添えておきます。ここで感情的な文言を入れると、後の交渉で不利になるため注意が必要です。
責任分解では、要件定義の曖昧さが原因か、ベンダーの技術力不足が原因か、発注側のプロジェクトマネジメント義務違反が原因かを客観的に整理します。議事録や課題管理表などのエビデンスが全ての鍵を握るため、発注後の文書管理を徹底することが撤退時の武器になります。弁護士(IT訴訟経験者)に早期相談すると、訴訟前の和解交渉を有利に進められるケースも多くあります。
まとめ
基幹システム/ERP刷新の発注は、RFP作成からベンダー選定、契約までと、その後のプロジェクト管理や撤退戦略という一連のプロセスです。発注側が主体的にマネジメントして初めて成功します。特に、発注前の社内準備(As-Is/To-Be分析、アドオン棚卸し、キーパーソン選出)で9割が決まると言っても過言ではありません。
ベンダー選定では、最低3社から提案を取り、リファレンスチェックで実態を確認したうえで、最安値ではなく成功への道筋で選ぶことが重要です。契約では、SLA・瑕疵担保・損害賠償の条件を具体化し、スルガ銀行やNHKの訴訟事例に学んで、曖昧さを徹底的に排除してください。発注後は、チェンジマネジメントとデジタルデバイド対応、並行稼働による段階移行で、リスクを最小化します。
炎上時に備えて、サンクコストの判断基準と契約解除の手続きも事前に想定しておくことで、取り返しのつかない損失を回避できます。本記事を参考に、貴社の基幹システム刷新を成功へ導いてください。
関連する全体ガイドは、次の記事でご覧いただけます。
▼全体ガイドの記事
・基幹システム/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を創業。