基幹システム/ERP移行の発注/外注/依頼/委託方法について

基幹システム/ERP移行の外注は、全体像の整理から始めて、発注前の準備、契約、データ移行、発注先の選定へと進みます。

中核業務を一度に乗せ替える移行は社内だけでは難しいため、多くの企業が開発会社などに発注しています。発注範囲や契約形態が曖昧だと、追加費用やベンダーロックイン、データ移行の失敗につながります。

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

基幹システム/ERP移行を外注する前の全体像

基幹システム/ERPの移行を外注する前に、「何を移行するのか」「どの方式で移すのか」を整理しておく必要があります。

基幹システムは会計・人事・販売・購買・在庫などが密接に連携しているため、一部だけを切り出して発注すると、連携部分で齟齬が生じやすくなります。そのため、外注設計は業務範囲と移行方式の見極めから始めます。

リフト&シフトと再構築という二つの移行方式

基幹システム/ERP移行の方式は、大きく「リフト&シフト」と「再構築」に分かれます。

リフト&シフトは、既存の業務やデータ構造をできる限り保ったまま新しい基盤へ移す方式です。短期間で進めやすい一方で、古い業務プロセスをそのまま引き継ぐため、抜本的な改善にはつながりにくい面があります。

  • 方式の選択:業務改善を優先する範囲なら再構築が候補
  • 既存活用:変更を抑えたい範囲ならリフト&シフトが候補

再構築は、業務プロセスやデータモデルを見直しながら新しいERPへ作り替える方式です。改善効果は大きいものの、要件定義からデータ移行まで負荷が高く、費用も期間も膨らみやすくなります。

どちらを選ぶかで外注する作業範囲も契約形態も変わるため、発注前に方式を仮決めしておくことが欠かせません。多くの場合、コア業務は再構築、周辺業務はリフト&シフトといった併用が現実的です。外注先には、この方式の妥当性を客観的に評価してもらう役割も期待できます。

Fit to Standardとアドオン最小化の重要性

ERP移行で成否を分ける最大の論点は、Fit to Standardの徹底です。Fit to Standardとは、自社の業務をパッケージの標準機能に合わせていく考え方で、独自のアドオン開発を最小限に抑えることを目的とします。

標準に寄せるほど開発費用は下がり、将来のバージョンアップや保守も容易になります。

  • 標準機能:標準機能で対応できる業務を先に見極める
  • 例外要件:残す例外とアドオンの必要性を個別に判断する

一方で、「現行システムでできていたから」という理由で例外ルールをすべてカスタマイズしようとすると、開発が肥大化し、費用が当初見積もりの数倍に膨らむこともあります。さらに、アドオンが増えるほど標準機能との整合性検証も必要になり、テスト工数は雪だるま式に増えていきます。

発注時には、「どこまで標準に合わせ、どこを必須要件として残すか」を社内で線引きしておくことが重要です。外注先には、業務を標準に寄せる提案力があるかどうかも評価軸として見ておくとよいでしょう。

発注前の準備とRFPの整え方

業務と連携、データ品質、提案条件、評価基準の4つをパネルで示した図。
4つの論点を揃えると提案の比較軸が整います。

外注の成否は、発注前の準備でほぼ決まります。準備が不十分なまま見積もりを依頼すると、各社の提案がばらつき、比較すらできなくなります。そのため、基幹システム/ERP移行では、現状業務の整理とRFP(提案依頼書)の整備が発注準備の二本柱になります。

現状業務の可視化と移行データの棚卸し

最初に行うべきは、現行の基幹システムが担っている業務とデータを一覧にすることです。長年運用してきた基幹システムはブラックボックス化していることが多く、この整理だけで相応の工数がかかります。会計・人事・販売・購買・在庫などの業務がどのように連携し、どの帳票やマスタが使われているかを洗い出します。

  • 業務と連携:業務の流れ、帳票、マスタ、連携先を洗い出す
  • データ品質:重複、表記揺れ、移行対象期間を確認する

あわせて、移行対象となるデータの量と質を把握します。得意先・仕入先・品目などのマスタは、長年の運用で登録内容が積み重なっていることが多く、移行前のクレンジングが欠かせません。

過去データのどこまでを移行し、どこからを参照用に切り離すかも、この段階で検討しておくと外注時の見積もり精度が高まります。

不要な機能やデータを「勇気をもって廃止する」判断も大切です。使われていない機能まで移行対象に含めると、移行コストと保守費が膨らみ続けます。廃止で浮いた予算をコア業務の刷新に回せば、移行プロジェクト全体の費用対効果も高まります。

RFPに盛り込むべき要件と評価基準

RFPには、移行の目的と、各社に同じ前提で提案してもらうための条件を書きます。

  • 提案条件:対象範囲、方式、日程、予算をそろえる
  • 評価基準:業務理解、実績、体制、ロックイン対策を評価する

とくにERP移行では、「Fit to Standardを前提とし、アドオンは必要最小限に抑える」という方針をRFPに明記しておくと、各社の提案を同じ条件で比べやすくなります。

データ移行については、対象データの種類・件数・想定品質、文字コードや外字の有無、許容できるダウンタイムの長さを具体的に記載します。これらが書かれていないと、ベンダーはリスクを見込んで高めの見積もりを出さざるを得ず、結果として発注側が損をします。

価格だけで比べないよう、評価基準は業務理解度、移行実績、体制、ロックイン回避への姿勢まで含めて設定します。配点もあらかじめ決めておくと、社内稟議でも選定理由を説明しやすくなります。

ポイント

発注前の準備が足りているかは、各社の提案を同じ条件で比べられるかで見極められます。比べにくい提案が並ぶなら、RFPの範囲・方式・予算・評価基準の書き方から見直します。

委託の進め方と契約形態の使い分け

未確定な要件を整理する準委任契約と、仕様確定後の開発・移行を担う請負契約を左右で比べた図。
工程の確定度に合わせて契約形態を切り替える構成です。

基幹システム/ERP移行を外注する際は、工程ごとに適した契約形態を使い分けることでリスクを抑えられます。

すべてを一括の請負契約で発注すると、要件が固まりきらないうちに金額が膨らみ、想定外の事態にも柔軟に対応しにくくなります。フェーズの性質に合わせて契約を設計することが、トラブル回避の鍵になります。

準委任から請負への切り替えによるリスク抑制

要件が固まっていないアセスメントや要件定義の段階は、準委任契約が適しています。準委任契約は成果物の完成ではなく作業の遂行に対して対価を払う形態で、要件を探りながら進める初期工程と相性が良いためです。この段階で範囲を見極めてから、開発フェーズへ移ります。

  • 初期工程:未確定な要件の整理は準委任で進める
  • 開発工程:仕様確定後の開発・移行は請負を検討する

要件と仕様が固まった開発・移行フェーズでは、成果物の完成責任を負う請負契約に切り替えます。これにより、仕様に対する品質と納期の責任をベンダー側に明確にできます。

準委任で全体を進めてしまうと、完成責任が曖昧になり、品質トラブル時に費用負担の押し付け合いが起きやすくなります。

アセスメントや要件定義は準委任、開発や移行は請負と段階的に切り替えると、初期工程の柔軟性と開発工程の品質責任を両立できます。そのうえで、発注前にこの契約設計をベンダーと合意しておくことが望まれます。

SLAとベンダーロックインを防ぐ契約の工夫

契約では、SLA(サービスレベル合意)と責任分界点を明確にしておくことが大切です。移行後の運用で、どこまでがベンダーの責任で、どこからが自社の責任かを曖昧にしたままだと、障害時に対応が遅れ、業務停止のリスクが高まります。応答時間や復旧目標は、数値で定めておきます。

  • 運用責任:障害時の責任分界と応答・復旧目標を定める
  • 移行可能性:納品物、権利、データ出力方法を契約に含める

特定ベンダーしか保守できない状態になると、保守費が高止まりし、次の移行時に身動きが取れなくなります。そのため、ベンダーロックインを防ぐ工夫も契約段階で講じておきます。具体的には、ソースコードや設定情報の著作権・利用権限、ドキュメントの納品、運用権限の所在を契約に盛り込みます。

たとえば、クラウド型ERPを選ぶ場合は、データのエクスポート手段やAPIの開放度を確認して、将来の乗り換え余地を残しておきます。

発注の段階で「出口」を設計しておくことが、長期的なコストコントロールにつながります。

ポイント

契約形態は、要件が固まっているかで準委任と請負を使い分け、SLAと出口の条項も合わせて判断します。要件が未確定なら準委任、仕様が確定したら請負に切り替えるのが目安です。

データ・基盤移行の進め方と落とし穴

許容ダウンタイム、並行稼働、移行リハーサル、役割分担をカードで整理した図。
切り替え計画と事前検証を並べて確認できます。

基幹システム/ERP移行で最も失敗が起きやすいのは、データ移行と基盤移行です。会計や販売のデータは一件の誤りが決算や請求に直結するため、精度が厳しく求められます。

ダウンタイムを最小限にしつつ、データを確実に移し替える計画が必要です。委託する際は、こうした移行設計の経験が豊富なベンダーを選ぶことが重要になります。

ダウンタイムと並行稼働の計画

基幹システムは業務を止められないため、切り替え時のダウンタイムをどこまで許容できるかを、早い段階で決める必要があります。連休や月末月初を避けて切替日を設定し、業務が動かない時間帯を確保するなど、現場業務との調整が前提になります。許容ダウンタイムが短いほど、移行手順の作り込みも求められます。

  • 停止時間:許容ダウンタイムと切替可能な時間帯を決める
  • 並行稼働:対象と期間を絞って二重運用を抑える

リスクを抑える方法の一つに、新旧システムを一定期間並行稼働させるアプローチがあります。新旧の結果を突き合わせて検証できるため安全性は高まりますが、二重運用による工数とコストが発生します。この並行稼働コストは見落とされやすいため、見積もり段階で必ず織り込んでおくべき項目です。

並行稼働の期間と範囲は、業務の重要度に応じて段階的に設計します。すべてを長期間並行させるとコストが膨らむため、リスクの高い会計・販売を重点的に検証するなど、メリハリをつけることが有効です。

移行リハーサルとデータクレンジングの落とし穴

本番移行をぶっつけ本番で行うのは極めて危険です。そのため、本番に近い環境で移行リハーサルを複数回行い、手順を固めておきます。その精度が、本番でのダウンタイム短縮と成功率向上に直結します。

  • 事前検証:本番相当の環境で移行時間とエラーを確認する
  • 役割分担:データ修正を自社とベンダーで分担する

データクレンジングは、隠れコストになりやすい工程です。得意先・仕入先マスタの重複や名寄せ、文字コードの差異や外字、旧システム特有のデータ構造の不整合などが、移行を進めるなかで次々と発覚します。そのため、修正に想定以上の工数がかかり、スケジュールと予算を圧迫しがちです。

データクレンジングは現場の業務知識が不可欠なため、ベンダー任せにはできません。このため、発注側がオーナーシップを持ち、ベンダーと役割分担を明確にしたうえで進める体制を組むことが、データ移行の落とし穴を回避する近道です。

ポイント

移行計画の良し悪しは、リハーサルで移行時間とエラーがどこまで見えているかで判断できます。許容ダウンタイムに収まらないなら、切替日や並行稼働の範囲を先に見直します。

費用相場と隠れコストの内訳

基幹システム/ERP移行の費用は、対象業務の範囲・移行方式・アドオンの量によって大きく変動します。一般的には、小規模で数百万円、中堅規模で数千万円、大規模では一億円を超えることも珍しくありません。

発注時には、表面上の見積金額だけでなく、隠れコストを含めた総額で判断する視点が欠かせません。

費用の内訳と工程ごとの目安

ERP移行の費用は、アセスメントや要件定義から運用保守まで、工程ごとに発生します。

なかでも、データ移行と並行稼働は、前述のとおり工数が読みにくく、費用が膨らみやすい工程です。見積もりでは、これらが内訳としてはっきり示されているかを見ておく必要があります。

  • 工程別費用:設計・開発、データ移行、並行稼働も含めて、工程ごとに分けて見積もってもらう
  • 運用費用:初期費用と複数年の利用・保守費を比較する

会計・人事・販売といった業務連携の数が増えるほど、インターフェース開発やテストの工数が増えます。連携先システムが多い企業ほど費用は上振れしやすいため、連携の優先順位を整理してから発注することが、コスト管理に有効です。

初期費用に目を奪われがちですが、移行後の運用コストまで含めて比べることが重要です。たとえばクラウド型ERPは、初期費用を抑えやすい反面、月額利用料が継続的に発生します。そのため、複数年の総保有コストで比べる必要があります。

見落としやすい隠れコストと抑え方

隠れコストは、初期見積もりに含まれにくく、プロジェクトが進んでから発覚することが多いものです。代表例は、データクレンジング、新旧並行稼働の二重運用費、現場への教育・トレーニング費です。こうした費用は、あらかじめ予備費として確保しておくことが賢明です。

  • 見積もり外:教育、二重運用、データ整備の費用を確認する
  • 将来費用:アドオンの保守や更新時の再改修費も考慮する

アドオン開発も、隠れコストの温床になります。標準で対応できない要件を安易にカスタマイズすると、開発費だけでなく、将来のバージョンアップ時の再改修費まで発生します。

Fit to Standardを徹底してアドオンを最小化することが、長期的なコスト抑制に最も効きます。コストを抑えるもう一つの鍵は、不要機能の廃止と、段階的な移行です。

一度にすべてを移すビッグバン方式は、リスクも費用も高くなりがちです。そのため、優先度の高い業務から順に移行すると、投資を平準化しながらリスクを抑えられます。

ポイント

費用は見積金額ではなく、隠れコストを含めた総額で比べます。見積もりに二重運用やデータ整備の費用が入っていなければ、その分の予備費を別に確保しておくのが目安です。

発注先の選定基準と失敗しない依頼のポイント

発注先の選定は、移行プロジェクトの成否を左右する最重要の意思決定です。価格や知名度だけで選ぶと、業務理解の浅さや体制不足によって後から苦しむことになります。

発注側は、基幹システム/ERP移行に特有の論点を理解し、伴走できるパートナーを見極めることが大切です。

業務理解と移行実績の確認

選定で重視すべきは、自社の業界や業務への理解度と、同規模・同種の移行実績です。会計や販売といった基幹業務の勘所を理解しているベンダーは、要件のヒアリングが的確で、Fit to Standardの提案も具体的です。

実績は、移行方式やデータ移行の難所をどう乗り越えたかまで踏み込んで聞くとよいでしょう。

  • 業務理解:自社業務と同規模の移行実績を確認する
  • 支援体制:構想から開発・運用までの責任範囲を把握する

コンサルティングから開発・運用まで同じ会社が受け持つかも、重要な観点です。工程ごとに会社が分かれると、責任の所在が曖昧になり、引き継ぎのたびに認識のずれが生じます。上流から下流まで一貫して伴走できるパートナーであれば、こうした断絶を避けられます。

株式会社riplaは、コンサルティングから開発まで一気通貫で支援できる企業です。営業・顧客・生産・販売管理など幅広い基幹システムの構築・導入実績があり、企業の業務要件に合わせて柔軟に対応できる体制を整えています。発注先を検討する際の選択肢の一つとして参考になります。

人材不足の現実と内製・外注のバランス

IPAの調査は約4,000社を対象とし、799社から回答を得ています。その結果では、レガシーシステムの放置が調達元や提供先など、サプライチェーン全体へ負の影響を及ぼすことが示されています。

CDOやCIOなどのCxOを設置している企業では、社内の情報共有や業務の見える化、内製化が進み、モダナイゼーションも順調に進む傾向が報告されています。

  • 社内が担う:業務判断やデータ品質の責任を持つ
  • 外部に任せる:専門技術や実装の不足を外部人材で補う

IPAは、2030年に最大79万人規模のIT人材不足が生じると見込んでおり、人海戦術には限界があると指摘しています。

IT人材の不足を踏まえると、すべてを内製で抱え込むのは非現実的であり、外注を前提に専門知識と実行力を補う発注設計が合理的だと言えます。

一方で、丸投げは内部にノウハウが残らず、次の移行や運用で再び外部に依存する悪循環を生みます。

そのため、要件定義やデータクレンジングには自社が主体的に関わり、技術的な実装は外注する形が現実的です。業務知識を社内に残しながら、人材不足を補えます。

ポイント

発注先は、価格や知名度よりも、業務理解と同種の移行実績で絞り込みます。コンサルティングから運用まで同じ会社が受け持つかも、引き継ぎのずれを減らす目安になります。

まとめ

基幹システム/ERP移行を外注する際は、移行方式とFit to Standardの方針を定め、現状業務とデータの棚卸しから始めます。現状業務の可視化とRFP整備で発注準備を固めることが、外注の出発点になります。

契約は、アセスメントと要件定義を準委任、開発と移行を請負として段階的に切り替え、SLAやベンダーロックイン回避の条項まで盛り込むことで、リスクを抑えられます。移行の主軸となるデータ・基盤移行では、ダウンタイムと並行稼働を計画し、移行リハーサルとデータクレンジングを丁寧に進めることが成功の条件です。

費用は隠れコストを含めた総額で判断し、業務理解と移行実績を備えたパートナーを選ぶことが重要になります。IPAのデータが示す人材不足を踏まえ、内製と外注のバランスを設計しながら、自社の移行プロジェクトを着実に前へ進めていきましょう。

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

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。