会計や人事、販売管理といった企業の中核を担う基幹システムやERPは、長年の運用でアドオンが積み重なり、保守コストが膨らみ、改修の判断が難しくなりがちです。全面刷新まで踏み切れないものの、特定の機能だけを追加・改善したい、法改正に対応したい、連携部分のボトルネックを解消したいといった「部分的な改修」のニーズは、むしろ全面刷新よりも頻度高く発生します。そして、その改修を社内だけで完結できる企業は限られているため、ベンダーへの発注・外注・委託という選択が現実的な手段となります。
本記事では、基幹システム・ERP改修を外部へ発注する際の進め方を、発注前の準備から契約形態の使い分け、ベンダーロックインを避ける契約の工夫、費用相場と隠れコスト、発注先の選定基準まで一気通貫で解説します。独立行政法人情報処理推進機構（IPA）の一次データや、基幹システム特有のFit to Standard・データ移行の重さといった実務上の落とし穴も踏まえ、この記事を読めば「誰に、どう頼み、いくらで、何に注意して進めればよいか」が判断できる構成にしています。スコープを限定し、費用対効果を最大化する発注の考え方を身につけていただける内容です。
▼全体ガイドの記事
・基幹システム/ERP改修の完全ガイド
基幹システム/ERP改修を発注する前の準備
発注の成否は、ベンダーに依頼を出す前の準備でほぼ決まります。とくに基幹システムやERPは会計・人事・販売といった複数業務が密接に連携しているため、改修したい範囲を曖昧なまま渡すと、見積もりがぶれ、後工程で要件追加が発生し、費用と期間が膨らみます。まずは「何を、なぜ、どこまで改修するのか」を社内で固めることが先決です。
現状の可視化と改修スコープの明確化
最初に行うべきは、現行の基幹システム・ERPがどの業務をどう支えているかを棚卸しすることです。長年の運用で追加されたアドオン（独自開発の追加機能）や、外部システムとの連携箇所、帳票やバッチ処理などを洗い出し、ブラックボックス化している部分を可視化します。この作業を怠ると、改修の影響範囲が読めず、ベンダーも正確な見積もりを出せません。
次に、改修のスコープを意図的に「絞る」ことが重要です。改修は全面刷新と異なり、部分的な改善・機能追加が主眼となるため、費用対効果の高い範囲に限定するほど成功確率が上がります。たとえば法改正対応や特定の連携不具合の解消、利用頻度の高い画面のUI改善など、効果が明確な箇所から優先順位をつけます。
このとき意識したいのが、長年積み上がったアドオンの取捨選択です。使われていない機能や、業務が変わってもう不要になった処理を「勇気を持って廃止する」ことで、改修対象が減り、コストも維持費も下がります。残すアドオンを最小化する方針は、後述するFit to Standardの考え方とも直結します。
RFP（提案依頼書）の作成と社内合意
改修スコープが固まったら、それをRFP（提案依頼書）としてまとめます。RFPには、改修の目的と背景、対象業務と機能範囲、現行システムの構成や連携先、希望する納期と予算感、評価したい観点などを記載します。ここを文書化しておくことで、複数ベンダーに同じ条件で見積もりを依頼でき、提案の比較が公平になります。
基幹システム・ERPの改修では、会計・人事・販売管理など部門をまたいだ影響が出ます。そのため、RFP作成の段階で関係部門と合意を取り、現場が「何が変わるのか」を理解している状態をつくることが欠かせません。IPAが約4,000社を対象に行い799社が回答した調査では、CDOやCIOといったCxOを設置している企業ほど社内の情報共有が円滑で、可視化や内製化が進み、システム刷新が順調に進むという明確な相関が示されています。経営層を巻き込んだ意思決定の仕組みづくりが、結果として発注の精度を高めます。
また、稟議を通すためには「初期コストの安さ」ではなく「改修後の運用コスト低減」で説得する視点が有効です。保守費の削減や業務時間の短縮を試算し、投資回収の見通しを添えることで、社内の合意形成がスムーズになります。
委託の進め方とフェーズごとの役割分担
発注先が決まったら、改修プロジェクトをフェーズに分けて進めます。基幹システム・ERP改修は、影響範囲を見極めるアセスメントから始まり、要件定義、設計・開発、テスト、移行・リリースへと進みます。各フェーズでベンダーと自社の役割を明確にしておくことが、トラブルを避ける鍵になります。
アセスメント・要件定義フェーズ
改修の初期では、現行システムの調査と改修要件の確定を行います。とくにドキュメントが残っていない古い基幹システムでは、ソースコードやデータ構造を解析するリバースエンジニアリングが必要になることがあり、ここで影響範囲の見極めが甘いと、後工程で想定外の改修が次々と発生します。
このフェーズでは、改修方針として「既存基盤を活かす部分改修（リフト&シフト的な発想）」で進めるのか、「特定機能を作り直す部分的な再構築」で進めるのかを見極めます。基幹システム・ERPの場合、安易にアドオンを増やすのではなく、標準機能で代替できないかを検討するFit to Standardの観点を要件定義に組み込むことで、改修後の保守負担を抑えられます。
要件定義はゴールが流動的になりやすいフェーズです。そのため後述するように、この段階は成果物の完成を約束しにくく、準委任契約で柔軟に進めるのが適しています。発注側も主体的に参加し、業務知識を提供することで、認識のずれを早期に解消できます。
開発・テスト・移行フェーズ
要件が固まった後の設計・開発フェーズは、成果物が明確になるため請負契約での委託が向いています。ベンダーが仕様に基づいて改修を実装し、自社は進捗確認やレビューに集中します。基幹システムは会計・人事・販売管理が連携しているため、改修した機能が他業務に与える影響を、連携テストで丁寧に確認することが欠かせません。
移行フェーズでは、基幹システム・ERP特有の「データ移行の重さ」が最大の関門となります。会計の勘定科目、得意先や仕入先のマスタ、人事の従業員データなどは、長年の運用で重複や表記ゆれ、不整合を抱えていることが多く、移行前のデータクレンジングに想定以上の工数がかかります。文字コードの差や外字、旧システムと新仕様のデータ構造のずれも、移行時のトラブル要因です。
こうしたリスクに備え、本番移行の前に移行リハーサルを複数回実施し、ダウンタイムを最小化する計画を立てます。会計年度の締めや給与計算のタイミングを避けて切り替えるなど、業務カレンダーと整合させた移行スケジュールを、ベンダーと早い段階で握っておくことが重要です。
契約形態の使い分けとベンダーロックインの回避
外注で失敗を避けるには、契約のかたちを工夫することが極めて重要です。基幹システム・ERP改修は中核業務に関わるため、いったん特定ベンダーに依存すると、その後の改修や保守でも他社に切り替えにくくなります。フェーズに応じた契約形態の使い分けと、ロックインを防ぐ契約条項の盛り込みが、長期的なコストとリスクを左右します。
準委任契約と請負契約の使い分け
契約形態は大きく準委任契約と請負契約に分かれます。準委任契約は、成果物の完成ではなく業務の遂行に対して対価を払う形態で、要件が固まりきっていないアセスメントや要件定義のフェーズに適しています。仕様変更が柔軟に行える反面、進捗管理は発注側の関与が前提となります。
一方、請負契約は成果物の完成を約束する形態で、仕様が確定した設計・開発フェーズに向いています。完成責任がベンダー側にあるため発注側のリスクは下がりますが、後からの仕様変更には追加費用が発生しやすくなります。実務では「アセスメント・要件定義は準委任、開発は請負」と段階的に契約を切り替えることで、双方のリスクをバランスよく抑えられます。
改修のように範囲が限定的なプロジェクトでも、この使い分けの考え方は有効です。曖昧な段階で大きな請負契約を一括で結ぶと、要件変更のたびに交渉が発生し、かえって費用がかさみます。フェーズを分けて契約することが、費用対効果を守る基本です。
SLAとベンダーロックインを防ぐ契約の工夫
基幹システムは止まると業務全体が止まるため、保守・運用に関するSLA（サービス品質保証）と責任分界点を契約で明確にしておく必要があります。障害時の対応時間、復旧目標、連携部分の責任範囲などを具体的に定めることで、トラブル時の押し付け合いを防げます。
そして見落とされがちなのがベンダーロックインの回避です。改修したソースコードの著作権の帰属、設計書やデータ仕様などのドキュメント納品、運用権限の引き渡しを契約に盛り込んでおくことで、将来別のベンダーへ切り替える自由を確保できます。これらが曖昧だと、改修のたびに同じ会社へ依頼せざるを得なくなり、価格交渉力を失います。
IPAは2030年に最大79万人のIT人材が不足すると試算しており、人海戦術での内製対応には限界があります。だからこそ、外部ベンダーと適切な契約を結びながらも、自社が主導権を握り続けられる仕組みを契約段階で作っておくことが、長期的な競争力につながります。
費用相場とコストの内訳・隠れコスト
発注前に費用の全体像を把握しておくことは、予算取りと見積もり評価の両面で欠かせません。基幹システム・ERPの改修費用は、改修範囲や連携の複雑さによって大きく変動します。全面刷新では数千万円から2億円規模になることもありますが、機能追加や法改正対応といった部分的な改修であれば、数百万円台から取り組めるケースもあります。スコープを絞るほど費用は抑えられます。
費用の内訳と工数の考え方
改修費用の大半は人件費、すなわち工数（人月）で構成されます。アセスメント、要件定義、設計・開発、テスト、データ移行、運用引き継ぎといった各フェーズに必要な人月に、エンジニアの単価を掛け合わせて算出されるのが一般的です。基幹システムは業務知識が必要なため、ERPに精通した人材の単価は相対的に高くなる傾向があります。
見積もりを受け取ったら、フェーズごとに工数の根拠が示されているかを確認します。とくにデータ移行とテストの工数は軽視されがちですが、基幹システム改修では最もブレやすい部分です。一式といった大雑把な記載ではなく、作業の内訳が明示された見積もりを出すベンダーほど、プロジェクト管理が信頼できます。
見落としやすい隠れコスト
初期の開発費用だけを見て発注すると、後から想定外の支出に直面します。代表的な隠れコストが、データクレンジングの費用です。基幹システムのマスタデータは重複や不整合が多く、移行可能な状態に整える作業は、見積もりに含まれていないことが少なくありません。ここを事前に確認しておくことが大切です。
また、改修中に旧システムと新システムを並行して稼働させる期間が生じる場合、その二重運用のコストも見込んでおく必要があります。さらに、改修後の操作に慣れるための現場教育費や、保守・ライセンスのランニングコストも、トータルコストとして評価すべき項目です。
コストを抑えるには、前述の通り不要なアドオンを廃止してスコープを絞ること、そして標準機能を活かすFit to Standardを徹底することが効果的です。アドオンを最小化すれば、改修費だけでなく改修後の保守費も継続的に下がり、費用対効果が高まります。
発注先の選定基準と失敗しない依頼のポイント
最後に、改修を任せる発注先をどう選ぶかを整理します。基幹システム・ERPは業務理解が成否を分けるため、技術力だけでなく、自社の業務やERP製品への理解、プロジェクトを最後までやり切る体制を備えたベンダーを見極めることが重要です。複数社から相見積もりを取り、提案内容と契約姿勢を比較しましょう。
技術力・業務理解・契約姿勢の見極め
選定では、まず同規模・同業種での基幹システム改修やERP導入の実績を確認します。会計・人事・販売管理といった対象業務の知識があるかどうかで、要件定義の精度が大きく変わります。技術力に加えて、自社の業務課題を理解しようとする姿勢があるベンダーは、改修後の定着まで見据えた提案ができます。
契約姿勢も重要な判断材料です。準委任と請負の使い分けに柔軟に応じてくれるか、ソースコードやドキュメントの納品、ロックイン回避に前向きかを確認します。これらに難色を示すベンダーは、将来の主導権を握ろうとしている可能性があるため、慎重に判断する必要があります。
提案を比較する際は、安易にアドオンの追加で要望をすべて叶えようとするベンダーよりも、標準機能での実現や業務側の運用変更を提案できるベンダーを評価します。Fit to Standardの発想を持つパートナーは、長期的な保守負担とコストを抑える観点を共有できる相手だからです。
注意すべきリスクと対策
基幹システム改修で典型的な失敗が、例外的な業務ルールをすべてカスタマイズで作り込み、開発が肥大化して頓挫するパターンです。これを避けるには、発注前のスコープ限定とFit to Standardの徹底が最大の対策となります。改修の目的に立ち返り、本当に必要な範囲だけを依頼することが肝心です。
もう一つの落とし穴は、現場の反発です。「前のシステムではできた」という声に押されて旧来の運用を温存すると、改修の効果が薄れます。発注の段階から現場を巻き込み、なぜ変えるのかを共有するチェンジマネジメントの視点を持つことが、改修を成功させる土台になります。
そして、レガシーシステムの放置は自社だけの問題にとどまりません。IPAの調査では、古いシステムを抱え続けることが、取引先や調達先などサプライチェーン全体に負の波及を及ぼすと指摘されています。改修を先送りせず、適切なパートナーとともに計画的に進めることが、企業の信頼維持にもつながります。
まとめ
基幹システム・ERPの改修を発注・外注する際は、まず現状を可視化し、改修スコープを意図的に絞ったうえでRFPを整え、社内と経営層の合意を取ることが出発点となります。アドオンを最小化し、Fit to Standardで標準機能を活かす方針は、改修費だけでなく改修後の保守費まで継続的に下げる効果があります。
進め方では、アセスメント・要件定義は準委任契約、設計・開発は請負契約と段階的に使い分け、SLAと責任分界点、ソースコードやドキュメントの納品を契約に盛り込んでベンダーロックインを避けることが、長期的なリスクとコストを抑えます。費用面ではデータクレンジングや並行稼働、教育費といった隠れコストを見込み、内訳が明示された見積もりを比較することが大切です。
発注先は技術力に加え、会計・人事・販売管理への業務理解と、ロックインを生まない誠実な契約姿勢を備えたパートナーを選ぶことが成功の鍵です。IPAの一次データが示すように、システムの放置はサプライチェーン全体に影響し、2030年には大幅なIT人材不足も見込まれます。費用対効果を見極めながら、信頼できるパートナーとともに計画的な改修を進めていきましょう。
▼全体ガイドの記事
・基幹システム/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を創業。