基幹システム/ERP改修を発注・外注するときは、対象範囲と目的を明確にし、現状を確認してから段階を分けて進めるのが基本です。
費用、契約、データ移行の条件を整理しておくと、業務を止めずに効果を確認しながら進められます。
▼全体ガイドの記事
・基幹システム/ERP改修の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
基幹システム/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（サービス品質保証）と責任分界点を、契約で明確にしておく必要があります。
- SLA：障害時の対応時間や復旧目標
- 責任分界点：連携部分を含め、どこまでを誰が受け持つか
ここを具体的に決めておけば、トラブル時に責任をなすり合う事態を防げます。
さらに、見落とされがちなのがベンダーロックインの回避です。改修したソースコードの著作権の帰属を、契約で明確にしておくことが大切です。
設計書やデータ仕様などのドキュメント納品、運用権限の引き渡しを契約に盛り込んでおくことで、将来別のベンダーへ切り替える自由を確保できます。
これらが曖昧だと、改修のたびに同じ会社へ依頼せざるを得なくなり、価格交渉力を失います。
IPAは、2030年に最大79万人のIT人材が不足すると試算しています。そのため、人海戦術での内製対応には限界があります。
だからこそ、外部ベンダーと適切な契約を結びながらも、自社が主導権を握り続けられる仕組みを契約段階で作っておくことが、長期的な競争力につながります。
費用相場とコストの内訳・隠れコスト
発注前に費用の全体像を把握しておくことは、予算取りと見積もり評価の両面で欠かせません。基幹システム・ERPの改修費用は、改修範囲や連携の複雑さによって大きく変わります。
全面刷新では、数千万円から2億円規模になることもあります。一方、機能追加や法改正対応といった部分的な改修であれば、数百万円台から取り組めるケースもあります。スコープを絞るほど、費用は抑えられます。
費用の内訳と工数の考え方
改修費用の大半は人件費で、工数（人月）に単価を掛けて算出されるのが一般的です。基幹システムは業務知識が必要なため、ERPに精通した人材の単価は相対的に高くなる傾向があります。
- フェーズごとの人月：アセスメントから運用引き継ぎまで、必要な量を積み上げる
- テストとデータ移行：軽視されがちだが、基幹システム改修では最もブレやすい部分
見積もりを受け取ったら、フェーズごとに工数の根拠が示されているかを確かめます。
一式といった大雑把な記載ではなく、作業の内訳が明示された見積もりを出すベンダーほど、プロジェクト管理が信頼できます。
見落としやすい隠れコスト
初期の開発費用だけを見て発注すると、後から想定外の支出に直面します。見落とされやすい費用は、主に次の2つです。
- データクレンジング：移行できる状態に整える作業で、見積もりに入っていないこともある
- 二重運用：改修中に旧システムと新システムを並行して稼働させる期間の費用
基幹システムのマスタデータは重複や不整合が多く、ここを事前に確認しておくことが大切です。
改修後の操作に慣れるための現場教育費や、保守・ライセンスのランニングコストも、トータルコストとして評価すべき項目です。
コストを抑えるには、前述のとおり不要なアドオンを廃止してスコープを絞ること、そして標準機能を活かすFit to Standardを徹底することが効果的です。
アドオンを最小化すれば、改修費だけでなく改修後の保守費も継続的に下がり、費用対効果が高まります。
発注先の選定基準と失敗しない依頼のポイント
最後に、改修を任せる発注先の選び方を見ていきます。基幹システム・ERPでは、業務をどこまで理解しているかが成否を分けます。
技術力だけでなく、自社の業務やERP製品への理解、プロジェクトを最後までやり切る体制を備えたベンダーを見極めることが大切です。複数社から相見積もりを取り、提案内容と契約姿勢を比較しましょう。
技術力・業務理解・契約姿勢の見極め
選定では、まず実績と業務理解を確かめます。
- 実績：同規模・同業種での基幹システム改修やERP導入の経験
- 業務理解：会計・人事・販売管理といった対象業務の知識
業務知識の差は、要件定義の精度に直結します。また、自社の業務課題を理解しようとするベンダーは、改修後の定着まで見据えた提案ができます。
契約姿勢も重要な判断材料です。準委任と請負の使い分けに柔軟に応じてくれるか、ソースコードやドキュメントの納品、ロックイン回避に前向きかを確認します。
これらに難色を示すベンダーは、将来の主導権を握ろうとしている可能性があるため、慎重に判断する必要があります。
提案を比較する際は、アドオンの追加で要望をすべて叶えようとするベンダーより、標準機能での実現や業務側の運用変更を提案できるベンダーを高く評価します。Fit to Standardの発想を持つパートナーは、長期的な保守負担とコストを抑える観点を共有できる相手だからです。
注意すべきリスクと対策
基幹システム改修で典型的な失敗が、例外的な業務ルールをすべてカスタマイズで作り込み、開発が肥大化して頓挫するパターンです。
これを避けるには、発注前の段階で次の2点を押さえることが最大の対策となります。
- スコープの限定：改修の目的に立ち返り、本当に必要な範囲だけを依頼する
- Fit to Standard：標準機能で代替できないかを先に検討し、アドオンを増やさない
もう一つの落とし穴は、現場の反発です。「前のシステムではできた」という声に押されて旧来の運用を温存すると、改修の効果が薄れます。
発注の段階から現場を巻き込み、なぜ変えるのかを共有するチェンジマネジメントの視点を持つことが、改修を成功させる前提になります。
さらに、レガシーシステムの放置は自社だけの問題にとどまりません。IPAの調査では、古いシステムを抱え続けることが、取引先や調達先などサプライチェーン全体に悪い影響を及ぼすと指摘されています。
改修を先送りせず、適切なパートナーとともに計画的に進めることが、企業の信頼維持にもつながります。
まとめ
基幹システム・ERPの改修を発注・外注する際は、まず現状を洗い出し、改修の範囲を意図的に絞ったうえでRFPを整えることが出発点になります。そのうえで、社内と経営層の合意を取ります。
アドオンを最小化し、Fit to Standardで標準機能を活かす方針は、改修費だけでなく改修後の保守費まで継続的に下げる効果があります。
SLAと責任分界点、ソースコードやドキュメントの納品を契約に盛り込んでベンダーロックインを避けることが、長期的なリスクとコストを抑えます。
費用面では、データクレンジングや並行稼働、教育費といった隠れコストを見込み、内訳が明示された見積もりを比較することが大切です。
発注先は技術力に加え、会計・人事・販売管理への業務理解と、ロックインを生まない誠実な契約姿勢を備えたパートナーを選ぶことが成功の鍵です。
IPAの一次データが示すとおり、古いシステムの放置はサプライチェーン全体に影響し、2030年には最大79万人のIT人材が不足すると試算されています。
費用対効果を見極めながら、信頼できるパートナーとともに計画的な改修を進めていきましょう。
▼全体ガイドの記事
・基幹システム/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を創業。