グローバルERP開発の発注/外注/依頼/委託方法について

グローバルERPの発注・外注は、製品を選んで設定を依頼するだけではなく、対象国ごとの法制度と業務差分を整理し、共通テンプレートと現地運用の境界を合意してから委託先を選ぶことが成功の近道です。

海外拠点ごとに会計ソフトやExcelが分かれ、連結決算や在庫把握に時間がかかっている企業では、グローバルERPの導入が有力な選択肢になります。一方で、発注形態、RFPの作り方、契約方式、費用の見方を誤ると、カスタマイズの増加や追加請求、現地で使われないシステムにつながります。本記事では、グローバルERP開発を外部へ依頼する際の進め方を、発注形態の選択から要件整理、契約、費用相場、委託先の比較、稼働後の体制まで順番に解説します。

▼全体ガイドの記事
・グローバルERP開発の完全ガイド

グローバルERPを外注する前に知っておきたい全体像

グローバルERPは、会計、販売、購買、在庫、生産、人事などを共通のデータ基盤で管理し、本社と海外子会社の数字を同じ定義で把握するための基幹システムです。海外でも使える会計ソフトという意味にとどまらず、多通貨、多言語、タイムゾーン、国別税務、電子請求書、会社間取引、連結決算、監査証跡まで含めて設計する点に特徴があります。

統合対象は財務会計だけではありません。受注、出荷、請求、入金、仕入、在庫、生産、固定資産、予算、資金といった業務を同じマスターと取引データでつなぎます。たとえば海外子会社の売上を現地通貨で計上し、本社の管理通貨へ換算し、会社間取引を相殺して連結するまでを一連の流れにできます。販売管理だけを個別に導入する場合でも、勘定科目、取引先、品目、組織階層、為替レートの設計が曖昧だと、最後にExcelで転記する運用が残ります。

複数国の決算を同じ指標で早く見たい会社、子会社ごとに異なる会計や在庫管理を標準化したい会社、買収や海外展開で拠点が増える会社は外注の効果を得やすいです。反対に、対象国が一つでユーザーも少なく、課題が請求書発行や経費精算だけであれば、いきなり大規模ERPを発注せず、連結会計、BI、業務SaaSの連携から始める方が適切な場合があります。検討開始の目安は国数や人数だけで決めず、決算遅延、手作業の工数、データ不整合、監査対応の負担を金額と日数で把握することです。

グローバルERPの発注形態はどれを選ぶべきですか？

発注形態は、製品ベンダーへ直接依頼する方式、導入支援を担うSIerやコンサルティング会社へ一括委託する方式、複数社を組み合わせる方式に大きく分かれます。自社の業務知識、海外展開の経験、プロジェクト管理の人員が不足しているほど、要件定義から展開までをまとめて管理できる責任体制が重要になります。

SAP、Microsoft、Oracleなどの製品ベンダーへ直接相談する方法は、製品のロードマップ、標準機能、ライセンス体系を確認しやすい点がメリットです。公開価格がある製品ではライセンスの基準を置きやすく、国別機能やサポート範囲も確認できます。ただし、業務要件の整理、データ移行、現地展開、教育、既存システムとの連携は、別の導入パートナーが担当することがあります。契約主体が複数になる場合は、障害時の一次窓口と、どの会社が全体責任を負うかを契約書で明確にします。

要件定義、製品選定、設計、開発、移行、テスト、教育、稼働後支援までを一社または主幹事会社にまとめて依頼する方式です。海外拠点を含むプロジェクトでは、国別の税務・会計、現地語の教育、タイムゾーンをまたぐ問い合わせ対応があるため、窓口が一つになることの価値は大きいです。一方で、一括見積は作業範囲が見えにくくなりやすく、提案書にない作業が追加費用になることがあります。RFPでは、各工程の成果物、前提条件、除外事項、現地パートナーの役割を明記して比較します。

製品ベンダー、業務コンサルタント、開発会社、現地の税務・会計専門家を組み合わせる方式です。製品選定の中立性や、特定国の法令への深い対応を得やすい反面、会社間の責任分界が曖昧になりやすい点に注意が必要です。複数社方式を採るなら、発注者側に全体PMOを置くか、主幹事会社に統合管理を委託します。特にデータモデル、API仕様、テスト環境、障害の切り分け、設計書の所有権を共通ルールとして決めておくことが重要です。

RFPと要件整理はどこまで準備してから発注しますか？

RFPは、製品名を指定するための依頼書ではなく、自社の課題と達成したい状態を候補会社が同じ条件で見積もるための資料です。対象国、会社数、ユーザー区分、業務範囲、連携先、データ量、稼働希望時期、現地法令、運用体制を記載します。要件を完全に決めてからでなければ発注できないわけではありませんが、最低限の前提がないまま価格だけを求めると、各社の見積条件がばらばらになり比較できません。

最初に、対象会社と国を一覧化します。日本本社、販売子会社、製造拠点、休眠会社などを区別し、各社の決算日、通貨、税務、取引量、利用者数、現行システムを記載します。次に、財務、販売、購買、在庫、生産、固定資産、予算、連結、会社間取引のうち、今回の範囲と将来拡張を分けます。銀行、人事給与、CRM、EC、物流、BIなどの連携先は、方式だけでなく、連携頻度、データ項目、エラー時の再送、担当者まで書くと見積の精度が上がります。

また、非機能要件も省略できません。稼働時間、目標復旧時間、バックアップ、権限の職務分掌、監査ログ、データの保存場所、個人情報の取り扱い、サポート言語、問い合わせ時間帯を示します。経済産業省・IPAの「サイバーセキュリティ経営ガイドライン Ver.3.0」を参考に、経営層が受け入れられるリスクと、委託先に求める管理策をRFPへ落とし込みます。セキュリティを「クラウドなので安心」と一文で済ませないことが大切です。

各業務を「全社共通にするもの」「国別法令のために差分を残すもの」「現地の慣行だが変更を検討できるもの」に分類します。たとえば勘定科目コード、承認ルート、取引先マスターの管理責任者は共通化しやすい一方、税率、電子請求書、法定帳票、支払条件は国別差分になりやすい領域です。現場の要望をそのままカスタマイズに変換せず、法的必須か、経営管理上の必須か、単なる使い慣れかを問い直します。

近年のクラウドERPでは、標準機能に業務を合わせるFit to Standardと、ERP本体の改変を抑えるClean Coreが重要な考え方になっています。日本郵船の事例では、約450件あったアドオン開発による機能を約1割まで縮小し、2025年8月のグローバルバージョンアップを円滑に完了したとSAPが公表しています（出典：SAP Japan、日本郵船導入事例、2025年）。RFPでは「カスタマイズできますか」だけでなく、「標準機能、設定、外部拡張のどれで実現するか」を提案してもらいます。

製品デモは、ベンダーが用意したきれいなサンプルではなく、自社の代表シナリオで実施します。現地通貨で受注し、本社通貨へ換算して売上計上する流れ、海外仕入の入荷と在庫評価、会社間取引の請求と消去、月次締め、税務帳票、権限のない利用者が仕訳を変更できないことまで確認します。候補会社には同じシナリオと同じ評価時間を渡し、標準対応、追加設定、開発、運用回避策を分けて説明してもらいます。

国別ローカライゼーションも、対象国が「対応可能」と書かれているだけでは不十分です。MicrosoftのGlobalization Studioは、210を超える国・地域における税務・規制要件への対応と、継続的な規制更新を掲げていますが、実際の対象範囲、更新時期、追加費用、現地の専門家による確認責任は契約前に確認します（出典：Microsoft Learn、Globalization Studio、2026年確認）。日本の電子帳簿保存法や各国の電子インボイスなど、制度の適用判断は税務専門家にも確認し、システム要件と法令解釈を混同しないようにします。

グローバルERPの契約形態と役割分担を決める方法

グローバルERPでは、要件が変化しやすい企画・要件定義と、成果物を確定しやすい開発・移行・テストで契約の考え方が異なります。すべてを一つの固定価格に押し込むと、前提条件の変更が追加請求や納期延長に直結します。工程ごとに、請負、準委任、ライセンス契約、保守契約を組み合わせ、変更管理のルールを先に合意します。

請負契約は、受託者が合意した成果物を完成させ、発注者が検査・受入する形に向いています。詳細設計書、設定一覧、連携プログラム、移行結果、テスト成績書、操作マニュアルなど、完成条件を具体的に書ける工程で使いやすい方式です。成果物の検査期間、瑕疵対応、受入基準、納品後の著作権や利用権、第三者製品のライセンスを契約書に記載します。仕様が固まっていない段階で請負金額だけを確定すると、双方に無理が生じます。

準委任契約は、受託者が専門家として業務を遂行し、稼働時間や役割に応じて精算する形です。現状分析、業務標準化、製品選定、RFP作成、PMO、現地キーユーザー支援など、進めながら論点を整理する工程に適しています。発注者側も意思決定や資料提供を担う必要があるため、週次会議の頻度、参加者、課題管理表、成果の評価方法、稼働上限を決めておきます。時間精算だから無制限に増えるのではなく、追加稼働の承認手順を設けることが大切です。

海外拠点を含む契約では、データの所有権と利用権、バックアップ、国外移転、保存期間、委託先の再委託、秘密保持、監査権、インシデント報告時間を確認します。ERPを解約した後に、マスターデータと取引履歴をどの形式で返却できるか、設計書や設定情報を誰が保有するかも重要です。ベンダーロックインを避けるには、API仕様、データ辞書、アカウント一覧、運用手順を成果物に含め、契約終了時の移行支援を見積に入れておきます。

また、国別の税務や法制度の変更を誰が監視し、誰が設定変更とテストを行うかを決めます。国税庁は令和7年度税制改正後の電子帳簿等保存制度について、請求書等の電子取引データを帳簿へ自動連携する仕組みに関する制度を案内しています（出典：国税庁「電子取引関係」、2026年確認）。制度対応を委託先任せにせず、自社の経理・法務・情報システムが受入判断をできる体制にします。

グローバルERPを発注してから稼働するまでの進め方

グローバルERPは、発注後に要件を一から考えるプロジェクトではありません。経営課題と対象範囲を決め、代表拠点で標準テンプレートを作り、パイロットで検証してから国別に展開する流れが現実的です。全拠点を一斉に切り替える方法もありますが、データ品質、教育、法令差分、現地の稼働日が重なるため、初回発注の段階では段階展開を前提にした方がリスクを管理しやすいです。

最初の工程では、決算日数、連結作業時間、Excel転記の回数、在庫差異、手入力の件数、監査指摘、現地からの問い合わせを調査します。目的を「ERP導入」ではなく、「月次決算を何日短縮する」「海外子会社の損益を何営業日以内に見えるようにする」「マスターの重複を何割減らす」のように測定可能にします。そのうえで、対象国、対象会社、業務範囲、予算上限、稼働希望日を経営会議で承認します。

次に、本社または業務とデータが代表的な拠点を選び、共通勘定科目、組織、取引先、品目、承認、締め、レポートのテンプレートを作ります。対象国のうち、法令差分が大きすぎない拠点をパイロットにすると、標準化の考え方を検証しやすいです。移行では、古い取引データをすべて載せるのではなく、残す履歴、参照用に保管する履歴、残高だけ移す履歴を分け、マスターの重複と表記揺れを先に解消します。

ユーザー受入テストは、システム担当者だけでなく、経理、営業、購買、倉庫、生産、現地のキーユーザーが参加します。日常処理だけでなく、締め処理、返品、為替差損益、会社間取引、税務帳票、権限変更、障害復旧を含めます。データ移行は本番直前に一度だけ行わず、少なくとも複数回のリハーサルで件数、残高、突合結果を確認します。

パイロットで決めた標準テンプレートを、対象国の法令と業務へ適用します。国別の差分を追加するたびに、共通プロセスへ戻せるか、他国へ影響しないか、アップデートで壊れないかを確認します。切替方式は一斉切替、段階切替、並行稼働から選びますが、決算期や繁忙期を避け、旧システムの参照期限、データ凍結、戻し方を決めておきます。

稼働後は、本社のCoE（Center of Excellence）と各国のキーユーザーを置きます。CoEはマスター、権限、リリース、法令対応、KPI、改善要求を管理し、現地キーユーザーは教育と一次問い合わせを担います。日本郵船のように多数の国内外子会社へ標準化を広げる事例でも、発注時点から導入後の運用組織まで設計する必要があります。システムを納品して終わりにせず、決算日数、手作業時間、データ鮮度、ユーザー定着率を毎月確認します。

グローバルERPの費用相場と見積の内訳

グローバルERPの費用は、ライセンス、導入支援、業務設計、設定・開発、データ移行、連携、テスト、教育、現地展開、保守に分かれます。国数、会社数、ユーザー数、対象業務、連携本数、データ品質、法令差分で大きく変わるため、単一の定価で判断できません。以下は、リサーチノートで整理した2025〜2026年の企画段階の概算レンジです。個別製品の正式見積ではなく、RFPの予算枠を置くための目安として使います。

1〜3カ国、財務中心、20〜50ユーザーであれば、初期導入・設定・移行・連携は2,000万〜6,000万円程度、ライセンスなどの年間ランニングは1,000万〜3,000万円程度、期間は6〜12カ月が一つの目安です。3〜10カ国、財務に販売・購買・在庫を加え、100〜300ユーザーで展開する場合は、初期費用8,000万〜3億円程度、年間ランニング4,000万〜1.6億円程度、期間12〜24カ月程度を見込みます。10カ国以上、製造・物流・連結・多数の連携があり、500ユーザー以上なら、初期費用3億〜10億円超、年間ランニング1.5億〜5億円超、期間18〜36カ月以上となる可能性があります。

このレンジは、グローバルERPの公開価格と類似する基幹システム案件をもとにした企画段階の推定です。一般的な国内基幹システムの参考値としては、限定領域で数百万円〜1,500万円、複数業務で1,500万〜4,000万円、エンジニア単価で月80万〜120万円程度という整理がありますが、国別対応と多拠点展開が加わると別の予算構造になります。したがって、数字をそのまま発注額とせず、対象範囲と前提条件を添えて社内予算に使います。

公開価格の一例として、日本マイクロソフトのDynamics 365 Financeは、2026年確認時点で通常プランが31,484円／ユーザー／月相当、Premiumが44,977円／ユーザー／月相当です（税別、年払い。出典：Microsoft「Dynamics 365 Financeの価格」、2026年確認）。通常プランを50ユーザーで使う場合、単純計算の年間ライセンスは約1,889万円、Premiumは約2,699万円です。ただし、これは財務製品の一例であり、販売、サプライチェーン、人事、環境、導入支援、連携、追加の国別機能は別に発生する可能性があります。ユーザー区分や契約条件もあるため、公開価格から全体費用を断定してはいけません。

見積比較では、初期費用だけでなく5年TCOを作ります。ライセンスとクラウド利用料、導入支援、追加開発、データ移行、教育、保守、サポート、法令更新、現地対応、環境増設、為替変動、将来のユーザー追加を含めます。見積書に「一式」と書かれた項目は、人数、工数、成果物、回数、対応言語、訪問回数、対象国を分解してもらいます。

企画・要件定義、業務標準化、設定・設計、追加開発、データ移行・連携、テスト・教育・展開、PMO・予備費に分けると、金額の理由を追いやすくなります。企画段階では、要件定義・業務標準化10〜15%、設定・設計15〜25%、データ移行・連携15〜30%、テスト・教育・展開20〜30%、PMO・現地展開・予備費10〜20%程度を仮置きして、提案書との違いを確認します。これは案件の実績単価ではなく、予算構成の目安です。各社の提案で割合が大きく違う場合は、対象工程の抜けや前提条件を質問します。

費用を抑える方法は、単純に一番安い会社を選ぶことではありません。標準機能を使う範囲を増やし、不要な履歴移行を減らし、国別展開を段階化し、共通テンプレートを再利用することで、初期費用と将来保守を抑えられます。逆に、既存業務をすべて再現するカスタマイズは、テストとバージョンアップの負担を増やします。原田伸銅所の事例のように、海外売上高が約3割の企業でも、まず標準化されたクラウドERPを中核にしてデータを一元化する方針が選択肢になります（出典：SAP Japan「原田伸銅所導入事例」、2025年掲載）。

委託先の選定と見積比較で確認すべきポイント

委託先は、知名度や製品の認定数だけでなく、自社と同じ規模・業界・対象国を経験しているかで選びます。製品ベンダーと導入支援会社では役割が異なるため、製品の機能説明とプロジェクトを完遂する力を分けて評価します。候補は2〜4社程度に絞り、同じRFP、同じデモシナリオ、同じ見積条件で比べると、価格だけに引っ張られにくくなります。

確認する実績は、単に「グローバルERPを導入した」では足りません。対象国、会社数、ユーザー数、モジュール、製造や物流の有無、連結・会社間取引、移行データ量、導入期間、稼働後の保守体制を聞きます。実名事例が難しい場合でも、匿名化した規模、課題、採用方式、追加開発の量、現在の支援範囲を確認します。可能であれば、同規模の顧客へのリファレンスチェックを依頼し、提案時の担当者が稼働後も関与するかを確かめます。

比較表には、ライセンス、導入支援、追加設定、開発、移行、連携、テスト、教育、現地展開、保守、予備費を横並びにします。さらに、含まれる国、会社数、ユーザー区分、環境数、データ件数、連携本数、対応言語、訪問・オンライン支援の回数を記載します。安い見積が、対象範囲を狭くしているだけの場合もあるため、初期費用、年間費用、5年TCO、追加変更の単価を分けて比べます。

特に「標準機能で対応」「製品標準外」「別途見積」「顧客作業」という表現を見逃さないようにします。顧客作業に、データクレンジング、マスター登録、テストシナリオ作成、現地教育、税務確認が含まれると、社内工数が膨らみます。見積の評価は、提示額に自社の人件費と現地法人の負担を加えた実質TCOで行います。作業を安く見せるために、発注者側の負担を過小評価していないかを確認します。

代表的な失敗は、経営層が目的を決めないまま現場の要望を積み上げること、対象国の法令差分を後から発見すること、データ移行を最後に回すこと、現地ユーザーを教育に参加させないこと、契約上の責任分界が曖昧なことです。対策として、経営KPIを先に定め、国別差分の台帳を作り、移行リハーサルを早期に行い、各国のキーユーザーを任命します。発注先には、リスク一覧、課題の期限、意思決定者、エスカレーション経路を週次で共有してもらいます。

AI機能や自動化も、導入すればすぐに成果が出る機能としてではなく、データ品質、権限、監査証跡、人による承認を前提に評価します。たとえば自動仕訳や予測分析を使う場合、入力データの欠損、異常値、モデルの説明責任、誤処理時の取消手順をRFPに含めます。ランサムウェア、退職者アカウント、特権ID、委託先の再委託先まで確認し、セキュリティを導入後の運用項目として契約とKPIに結びつけます。

よくある質問（FAQ）

グローバルERPの発注では、国数やユーザー数だけでなく、法令対応、業務標準化、データ移行、稼働後の体制まで確認する必要があります。ここでは、発注前に特に相談されやすい質問へ直接回答します。

外注できますが、海外拠点が1〜2カ国で課題が限定的なら、財務や連結会計から段階的に始める方法も検討します。対象国、ユーザー数、決算遅延、現行システムの保守期限を整理し、フルERP、連結会計、BI、業務SaaS連携を同じ目的指標で比べると過剰投資を避けやすくなります。

企画段階では、1〜3カ国・財務中心なら初期2,000万〜6,000万円程度、3〜10カ国・複数業務なら8,000万〜3億円程度を予算検討の幅として置きます。ただし、これは公開価格や類似案件から整理した概算であり、正式な発注額ではありません。ユーザー区分、モジュール、連携、移行、現地展開、5年TCOを分けたRFPを作り、複数社から同じ条件で見積を取得します。

要件整理やPMOのように進めながら論点を決める工程は準委任、設計書や設定・開発物など完成条件を定義できる工程は請負が基本です。実際には、企画・要件定義を準委任、開発・移行・テストを請負、ライセンスと稼働後支援を別契約にする組み合わせが使いやすいです。契約方式の名前だけでなく、成果物、受入基準、変更管理、追加費用、設計書とデータの扱いまで確認します。

「対象国・対象業務が自社と近い導入実績はあるか」「標準機能、設定、開発をどう切り分けるか」「発注者側に必要な作業は何か」「稼働後に誰が現地を支援するか」「5年TCOと追加変更の条件は何か」を質問します。加えて、データ移行の責任者、法令更新の確認者、重大障害時の連絡時間、再委託先、契約終了時のデータ返却方法も確認すると、価格表だけでは見えないリスクを比較できます。

まとめ

グローバルERPの発注・外注で最初に決めるべきことは、製品名ではなく、解決したい経営課題、対象国、共通化する業務、国別に残す差分、稼働後の責任体制です。発注形態は、製品ベンダーへの直接相談、一括委託、複数社の組み合わせから、自社の人員と海外展開の経験に合わせて選びます。

まず、現行システム、対象会社、ユーザー、決算日数、連携先、データ量、国別法令を棚卸しし、MustとWantを分けます。その情報をRFPにまとめ、同じ実データに近いシナリオでデモと見積を依頼します。費用は初期導入だけでなく、ライセンス、教育、保守、現地対応、アップデート、追加改修を含む5年TCOで判断します。

契約では、工程ごとの成果物、受入基準、変更管理、追加費用、データと設計書の権利、再委託、セキュリティ、法令更新、稼働後の窓口を明確にします。段階展開と現地キーユーザーの参加を前提に、導入後のCoEまで含めて計画すれば、グローバルERPを単なるシステム刷新ではなく、グループ経営の共通基盤として定着させやすくなります。

▼全体ガイドの記事
・グローバルERP開発の完全ガイド

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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