基幹システムやERPの刷新は、単なるシステム入れ替えではなく経営構造そのものを再設計するプロジェクトです。発注先選定を誤れば数億円の損失や訴訟リスクに直結するため、発注前の社内準備とベンダー選定プロセスが成否を大きく左右します。

本記事では、基幹システム/ERP刷新を外注・委託する際の発注準備からRFP作成、ベンダー比較、契約締結、発注後のプロジェクト管理、さらに炎上時の撤退戦略までを体系的に解説します。NHK・日本IBM訴訟やスルガ銀行95億円白紙撤回、キングジムの逆転選定など実例を交えつつ、失敗を避けるための実務的な判断基準をお伝えします。

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

▼全体ガイドの記事
・基幹システム/ERP刷新の完全ガイド

基幹システム/ERP刷新を発注する前にやるべき社内準備

ERP刷新プロジェクトの成否は、RFPを書き始める前の社内準備段階でほぼ決まると言っても過言ではありません。ベンダーに相談する前に、自社の業務と現行システムを構造的に棚卸しし、経営層・現場・情シスの三者で共通認識を形成する必要があります。ここを省略すると、後工程で要件変更が噴出し、スコープクリープと追加費用の温床になります。

まず着手すべきは現行基幹システムの完全な棚卸しです。マスタ数、トランザクション量、連携している周辺システム、バッチ処理の依存関係を網羅したシステム構成図を作成してください。この作業を怠ると、後から「実はあのサブシステムと繋がっていた」という事実が発覚し、追加開発費用が発生します。

次に業務プロセスのAs-Is/To-Be分析を行います。現状の業務フロー(As-Is)を部門横断で可視化し、刷新後のあるべき姿(To-Be)とのギャップを言語化する作業です。BPMN記法で描ける粒度まで落とし込めれば、ベンダーとの要件認識齟齬が激減します。

As-Is分析では現場ヒアリングを重視し、マニュアルに書かれていない「暗黙の運用ルール」まで拾い上げることが重要です。To-Be定義では経営目標との紐付けを明示し、刷新の投資対効果を定量化しておきます。

既存基幹システムに積み上がったアドオン(カスタマイズ機能)の棚卸しは、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には、会社概要とプロジェクトの背景・目的、対象業務範囲、機能要件、非機能要件、スケジュール、予算レンジ、契約条件、提案書の様式と提出期限を必ず盛り込みます。機能要件はFit to Standard方針を明記した上で、アドオン候補を別紙で添付するのが定石です。

非機能要件では、IPAの非機能要求グレードを参照し、可用性・性能・運用保守・セキュリティ・移行性の5カテゴリを数値化します。特にSLA(Service Level Agreement)の想定値は後の契約交渉の土台になるため、稼働率99.9%以上、オンライン応答時間3秒以内、障害復旧RTO4時間以内など具体的な数値を提示しておきます。

予算レンジを開示するか非開示にするかは議論が分かれますが、現実的な提案を引き出すためにはレンジで開示することをおすすめします。非開示にすると、ベンダーが安全側に振った過剰見積もりを出してくるケースが多いためです。

基幹システム/ERPの発注先は大きく5分類できます。メーカー系(富士通、日立、NECなど)は自社ハードと一体のソリューションに強く、安定運用重視の案件に向いています。ユーザー系(NTTデータ、ITホールディングス系列など)は特定業界への深い知見が武器です。

独立系(大塚商会、TISなど)は中立性とコスト競争力でバランスが取れており、中堅企業のERP刷新で採用例が多いカテゴリです。コンサル系(アクセンチュア、アビームなど)は業務改革とセットでのERP導入に強みがあり、上流工程を含めた伴走を期待する場合に適しています。

外資系(SAP、Oracle、IBMなど)はグローバル展開や複雑な連結会計に強い一方、ローカライズ対応や費用面では国内ベンダーと比較検討が必要です。自社の業界特性、海外展開の有無、求める改革の深さによって、どのカテゴリに重点を置くかが変わります。RFP送付先は、異なるカテゴリから最低3社以上を選ぶとバランスの取れた比較になります。

ベンダー比較・選定プロセスの進め方

複数社から提案を受け取った後の評価プロセスは、単純な金額比較ではなく、技術評価・体制評価・実績評価・リスク評価を多面的に行う必要があります。提案金額の差は見かけのものであり、前提条件が異なれば比較は無意味です。RFPで定義した共通条件を基に、提案内容を正規化して評価します。

ERP刷新では、最低3社、可能なら5社程度から提案を取得することを推奨します。1社のみの提案では相場観が働かず、不当に高い金額や無理なスケジュールを見抜けません。2社比較では二項対立に陥りやすく、3社以上でこそ相対比較が機能します。

評価基準は、機能適合度・提案の具体性・プロジェクト体制・類似実績・価格・リスク対応策など7〜10項目に分け、重み付け配点で総合評価します。価格の配点は全体の20〜30%程度に留め、品質項目を重視することが炎上回避のポイントです。

評価シートは選定委員全員で事前に合意しておき、提案書受領後に「情で判断」することを防ぎます。各委員が独立して採点した後、差異の大きい項目について議論する形式が、主観の偏りを排除する定番手法です。

リファレンスチェックとは、ベンダーが過去に支援したクライアントに直接連絡し、実態を確認する調査手法です。提案書やWebサイトの事例紹介は都合の良い情報だけが載っているため、生の声を聞くことでしか見えない事実があります。最終候補2社まで絞った段階で必ず実施すべきです。

実施手順としては、まずベンダーに事例紹介を依頼し、紹介先2〜3社にアポイントを取ります。質問内容は「予算と納期が守られたか」「トラブル時の対応」「プロジェクトマネージャーの力量」「運用フェーズでの付き合い方」など、提案書に書けないリアルな部分を中心にします。

ベンダー経由の紹介だけでなく、業界団体のツテやLinkedIn経由で独自ルートから情報を取れれば、より客観的な評価ができます。リファレンスチェックで得たネガティブ情報は、契約交渉で条件改善を求める材料にも使えます。

文具メーカーのキングジムは基幹システム刷新において、最終的に最高額を提示したJQ社を選定したと公表されています。決め手になったのは金額ではなく、JQ社が旧システムの全構成を洗い出し、移行リスクを具体的に潰していく提案姿勢だったと言います。

安価な提案は一見魅力的ですが、裏には「リスクを発注側に押し付ける前提」や「要件の読み込みが浅い」といった問題が隠れていることが多いものです。ERP刷新のような数年単位のプロジェクトでは、初期コストの数%の差よりも、成功確率を高める提案の方がトータルで圧倒的に得になります。

「最安値ではなく成功への道筋で選ぶ」という判断基準を経営層と事前に合意しておくと、稟議段階で金額だけに引っ張られる事態を防げます。提案プレゼンでは「御社のリスク認識と回避策は何か」を必ず質問し、その深さで選ぶのが実務的なコツです。

契約締結のチェックリスト

ベンダー選定後の契約締結は、プロジェクト成否を決める最重要フェーズです。契約書の文言一つで、障害発生時の責任範囲や損害賠償額が大きく変わります。法務部門だけでなく、プロジェクトマネージャーと経営層も内容を精査し、曖昧な表現を排除していく作業が必要です。

ERP刷新で用いられる契約形態は主に請負契約と準委任契約の2種類です。請負契約は「成果物の完成」を義務とする契約で、要件が明確な設計・開発・テストフェーズに適しています。準委任契約は「業務の遂行」を義務とする契約で、要件定義や運用保守のように成果が事前確定しにくい業務に向いています。

実務ではフェーズごとに契約形態を使い分ける多段階契約が主流です。要件定義は準委任、設計・開発は請負、運用保守は準委任、という具合に切り分けることで、発注側・受注側双方のリスクをバランスさせます。一括で請負契約を結ぶと、要件変更のたびに契約変更が必要になり機動性を失います。

注意すべきは、準委任契約にしたからといって発注側が指揮命令できるわけではない点です。指揮命令関係を発注側が持つと偽装請負の疑いが生じ、労働者派遣法違反となるリスクがあります。業務委託の範囲と指示系統の境界を契約書で明確にしておく必要があります。

SLA(サービスレベル合意)は、稼働率・応答時間・障害復旧時間などを数値で明文化する条項です。RFPで提示した想定値を基に、ベンダー側と現実的な合意値を交渉します。未達時のペナルティ(利用料減額や損害賠償)も併せて定義します。

瑕疵担保責任(契約不適合責任)の期間は、民法改正後は「知った時から1年以内に通知」が基本ですが、特約で期間を延長または短縮できます。業務影響の大きい基幹システムでは1〜2年の延長を交渉するのが一般的です。

損害賠償上限は、ベンダー側が契約金額相当または1回分の支払額を上限に設定してくるケースが多いですが、基幹システム障害による逸失利益を考えると不十分な場合があります。重過失や故意の場合は上限を外す、または上限額を引き上げる交渉が必要です。

スルガ銀行と日本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刷新の完全ガイド

株式会社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を創業。