Dynamics 365 Business Centralのシステム開発の発注/外注/依頼/委託方法について

Business Centralの発注は、標準機能で足りる範囲を確かめ、要件を整理してから、契約と見積を比べる順に進めます。この順番で進めると、追加費用や運用の負担を抑えやすくなります。

▼全体ガイドの記事
・Dynamics 365 Business Centralのシステム開発の完全ガイド

Dynamics 365 Business Centralのシステム発注・外注の範囲

Business Centralの委託範囲を導入設計から定着・運用まで4層で示した図。
各層がつながり、導入前から稼働後までを支えます。

Business Centralの発注は、ソフトを一から作る契約とは性質が違います。業務に合わせた導入設計や設定を軸に、必要な拡張や外部連携、データ移行などを組み合わせて委託します。

発注先には、Microsoftの販売パートナーやERP導入コンサルティング会社、AL拡張の開発会社があります。また、データ移行や保守を担う会社へ個別に依頼する場合もあります。

標準機能を軸にした導入

Business Centralは、中堅・中小企業向けのビジネス管理アプリケーションです。財務、サプライチェーン、製造の業務を一つに統合します。プロジェクトやサービス業務も扱います。

Microsoft Learnの2026年リリースウェーブ1でも、標準機能を構成する製品と説明されています。そのうえで、必要に応じて業界向けソリューションやカスタマイズで拡張します(出典: Microsoft Learn「Dynamics 365 Business Central 2026 リリースウェーブ1の概要」、2026年)。

  • 標準機能を確認:Fit to Standardで、業務との適合度を見ます。
  • 拡張範囲を絞る:競争力や法令対応に直結する部分を対象にします。

導入設計から運用定着までの外注範囲

委託範囲は、導入前の調査から稼働後の支援まで及びます。見積もりでは、次の4つの作業ごとに含まれる内容を確かめます。

  • 導入設計:現状調査、Fit-Gap、業務・権限設計
  • 設定・拡張:環境設定、アドオン選定、AL拡張、API連携
  • 移行・検証:マスタや過去取引データの移行、テスト
  • 定着・運用:操作教育、切替支援、稼働後の問い合わせ対応

会計や在庫では、画面の開発より、業務の決まりごとを整える作業に時間がかかります。勘定科目、税区分、品目コードの整備に加え、在庫ロケーションや締め処理、承認ルールも必要になります。

見積書に「Business Central導入一式」とだけ書かれている場合は、どの作業が含まれ、どの作業が別料金かを確かめてから契約します。

発注形態の選び方

発注形態は、社内のERPや会計の知識、要件を管理する体制に合わせて選びます。一括委託、分離発注、段階発注の3つを比べると、自社に合う進め方が見えてきます。

  • 一括委託:導入全体を1社に任せ、問い合わせ先と受け持ち範囲を一本にします。
  • 分離発注:要件整理と設定・拡張を分け、各社の専門性や価格を比較します。
  • 段階発注:先に調査やPoCを行い、結果を見て本導入を契約します。

社内にERPや会計の知見が少ない場合は、一括委託のほうが進めやすい方法です。一方、要件を自社で管理できる場合は、分離発注や段階発注で透明性を高められます。

責任分界を一本化しやすい一括委託

一括委託では、1社の導入パートナーが要件整理から稼働後の支援まで担当します。設定や拡張、移行、教育も、同じ会社が受け持ちます。

問い合わせ先が一本になり、会社をまたいだ責任の押し付け合いを避けやすくなります。そのため、初めてERPを導入する企業に向いています。

ただし、委託先の提案が要件や費用に反映されやすい面もあります。そのため、契約前に、標準機能と追加開発の区別や再委託先を明記します。納品物の範囲と、追加変更の単価も書いておきます。

専門性と価格を比較しやすい分離発注

分離発注では、工程ごとに委託先を分けます。たとえば、業務コンサルティング会社が要件を整理し、別の会社がBusiness Centralの設定や拡張を担当するといった形です。

会計や製造の業務設計と、AL開発やAPI連携の技術力を、別々に評価できる点が強みです。一方で、要件の伝え漏れや設計の責任の曖昧さ、テスト環境の所有者が決まらないことが起こりやすくなります。

発注者側は、プロジェクトマネージャーを置いて、納品物の受け渡し条件と責任分界表を管理します。

不確実性を小さくしてから拡張できる段階発注

操作感や標準機能との適合度が分からないときは、有償の現状調査やPoC(概念実証)を先に発注します。そして、その結果をもとに本導入を契約します。

PoCでは、受注から出荷・請求、購買から入荷・支払、月次決算までの業務を、少量の実データで確認します。標準対応、追加設定、拡張が必要な範囲を分けておくと、過剰なカスタマイズを避けられます。

ポイント

自社のERPや会計の知見と、要件を管理する体制を基準に、一括委託・分離発注・段階発注のどれが合うかを決めます。迷うときは、問い合わせ先が一本になるかで比べると判断しやすくなります。

RFPと要件整理で準備する内容

RFPにそろえる見積条件として、改善目的、対象業務、利用者、データ、連携を配置した図。
条件を共有すると、各社の提案を同じ土台で見比べられます。

RFP(提案依頼書)は、委託先へ同じ条件で提案と見積を依頼する資料です。細かな画面仕様をすべて決める必要はありませんが、経営目的や対象業務、利用者、拠点を先にそろえます。そのうえで、データや連携、希望稼働日、予算の考え方、保守要件も記載します。

導入の希望だけを伝えて情報が不足したままだと、各社は異なる前提で見積もります。前提がそろわなければ、出てきた金額を比べられません。

業務課題と対象範囲の整理

導入する製品より先に、改善したい業務を書き出します。たとえば、月次決算を10営業日から5営業日へ短縮すること、在庫差異を減らすこと、海外子会社の実績を早く確認すること、Excelの二重入力をなくすことが目的になります。

対象範囲として、会社数や拠点数、倉庫数、ユーザー数を記載します。業種や製造の有無、扱う通貨、国内外の税務も書き込みます。加えて、Dynamics 365 Sales、EC、WMS、銀行、給与システムなどの既存システムも挙げます。

希望稼働日から逆算して、第一フェーズに含める業務と、第二フェーズへ回す業務を分けます。

データ移行と外部連携の前提

見積は、移行データの量と接続するシステムの数で大きく変わります。そのため、RFPには移行と連携の条件を記載します。

  • 移行対象:品目、得意先、仕入先、勘定科目、税区分、価格表、在庫、未収・未払、固定資産、過去取引の保管方法
  • データ品質:行数、重複、欠損、コード体系の不統一、旧システムでの保持期間
  • 連携条件:送受信項目、頻度、リアルタイムか一括か、エラー時の再送、重複防止、障害時の責任者

日本の請求・税務業務を含む場合は、インボイス制度や電子取引データの保存要件も非機能要件に入れておきます。

国税庁は、法人の帳簿や取引書類を原則7年間保存するよう求めています。また、電子取引では、取引情報に係る電磁的記録を一定の要件で保存する必要があります(出典: 国税庁「帳簿書類等の保存期間」「電子帳簿保存法の概要」、2026年確認)。

請求書の発行や受領、検索、訂正履歴、保存責任を、どの製品が担うかも委託先と確かめます。

標準・設定・拡張の区分

RFPでは、各要件を標準機能、設定、AppSourceなどの追加アプリ、AL拡張やPower Platform、業務変更、対象外に分けて提案するよう依頼します。

標準機能で代替できるのに独自画面を作ると、初期費用に加えてアップデート時の検証や保守も増えます。反対に、法令や収益源、製造工程、顧客体験に関わる機能まで標準へ寄せると、現場で使えない場合もあります。

発注者は、その区分にした理由と、将来の変更による影響を、要件ごとに委託先へ残してもらいます。

ポイント

RFPは、各社の見積を同じ前提で比べるための土台として考えます。業務目的からデータ、連携、標準と拡張の区分まで条件をそろえておくと、比較が成り立ちます。

請負と準委任の契約形態

要件が固まっている開発や設定は請負契約、調査や伴走支援、運用改善は準委任契約とする組み合わせが現実的です。ただし、契約名だけで安全性が決まるわけではありません。

契約書には、納品物や完成条件、検収、作業時間、変更の管理、責任分界を具体的に書き込むことが大切です。法務・税務の最終判断は、委託先の説明だけに頼らず、自社の専門家にも確かめておきます。

請負契約の納品物と検収条件

請負契約は、合意した納品物を完成させ、発注者が検収する形に適しています。納品物は、要件定義書や設定一覧、拡張機能、インターフェース仕様書を一つずつ名前で挙げます。移行結果、テスト成績書、操作マニュアルも並べます。

受入テストの合格条件も、あらかじめ決めておきます。「画面が動く」だけでは足りず、月次決算、返品、在庫調整、権限別操作、連携エラー、データ復旧といった業務シナリオを含めます。

要件を変えたときの追加見積と納期変更の手順は、契約書や変更管理表で管理します。

調査・伴走・運用支援に向いた準委任契約

準委任契約は、専門家の知識や時間を使って一定の業務を支援してもらう形です。また、開始時点で成果の形を決めにくい業務にも合っています。

対象になるのは、現状業務のヒアリングやFit-Gapワークショップ、データクレンジング支援です。ほかにも、ユーザー教育や稼働後の問い合わせ、アップデート影響調査があります。

作業時間や担当者、定例会、報告内容、対応時間帯、未消化時間の扱い、納品物の帰属を明記します。そのうえで、作業実績は月次で確認します。

ライセンス・知的財産・保守の責任分界

Microsoftライセンスの契約主体と更新条件を確かめます。そのうえで、追加アプリの所有者、拡張コードや設定情報の利用権、連携用アカウント、データの返却方法を決めておきます。

委託先を変えるときに、設定一覧やソースコード、テスト資産、運用手順を引き継げるかどうかが大切です。終了時の移行条件を契約前に確かめておくと、将来のベンダーロックインを避けやすくなります。

保守では、障害の受付時間や重大度ごとの初動、復旧目標を決めます。さらに、Microsoft更新の検証や追加開発の単価、ユーザー教育の範囲も決めます。

ポイント

請負か準委任かより、変更時の追加見積、受入の条件、保守の範囲が契約書に具体的に書かれているかを基準にします。書かれていなければ、契約前に委託先と詰めます。

発注・外注費用の相場

導入規模別の初期支援費を3区分の金額レンジで比べる横棒グラフ。
対象範囲が広がる区分ほど、費用レンジも大きくなります。

Microsoftが導入支援や開発費の公式価格を一律に定めているわけではありません。ここで示すのは、一般的な業務システムやERPの相場、必要な工程、公開事例をもとにした推定レンジです。

価格は、ユーザー数や会社・拠点数、業務範囲によって変わります。さらに、移行量や連携本数、追加アプリ、標準化の度合い、保守時間も影響します。そのため、ここで示す金額は初期予算の目安として使い、同じRFPで複数社へ見積を依頼します。

ライセンス費と導入支援費の区分

ライセンス単価と導入費は分けて考えます。その基準にするのは、Microsoft公式の日本向け価格です(出典: Microsoft「Business Centralの価格」、2026年8月確認)。

ここで示す価格は、いずれも税別で、1ユーザーあたり年払いの月額相当です。

  • Essentials:1ユーザーあたり月額11,994円相当です。
  • Premium:1ユーザーあたり月額16,491円相当です。
  • 20ユーザーの年間額:Essentialsは約287.9万円、Premiumは約395.8万円です。
  • エディションの機能:Essentialsは財務・販売・購買・在庫、Premiumは製造・サービス管理を含みます。

この金額には、導入支援、移行、連携、追加アプリ、教育、保守は含まれません。

標準機能中心の小規模導入(300万〜800万円程度)

単一法人で会計、販売、購買、在庫を中心に導入し、業務を標準機能へ寄せられる場合の推定レンジです。

  • 初期支援費:導入設計、環境設定、基本マスタ移行、権限設定、操作教育を含む推定レンジは300万〜800万円程度です。
  • 期間:3〜6か月程度が一つの目安です。
  • データの状態:ユーザー数が少なくても、データ重複やコード不統一が多いと移行費が増えます。

金額だけでなく、見積書で移行対象とテスト範囲も確かめます。

複数拠点・外部連携を含む導入(800万〜2,000万円程度)

複数拠点、複数倉庫、複数会社に加え、EC、WMS、銀行、給与、請求、CRMなどと連携するケースもあります。その場合、初期の導入・開発支援は800万〜2,000万円程度という推定レンジです。

期間は5〜10か月程度と想定されます。API連携では、項目のマッピングに加えて、エラー時の再送や重複防止、締め処理、認証情報、障害時の責任分界まで設計します。

連携の本数が増えるほど、設定や開発、テストの量も増えます。

製造・多法人・海外展開(1,500万〜5,000万円超)

製造や多法人、海外拠点を含む導入では、業務と連携の範囲に応じて費用が広がります。

  • 大規模導入:サービス管理、多通貨、多言語、WMSや生産設備との連携を含む場合、1,500万〜5,000万円超が目安です。
  • さらに大きい案件:大規模アドオン、複雑な移行、グローバル展開を含むと、5,000万〜1億円以上のケースもあります。
  • 価格の扱い:一般的なERP・業務システムの相場と工程からの推定で、Business Central固有の一律価格ではありません。

JBSはミウラボイラメキシコのBusiness Centralを約5か月で導入した事例を公開しています(出典: JBS「ミウラボイラメキシコ株式会社」導入事例、2026年確認)。

ただし、対象会社や業務範囲が異なるため、5か月を標準の納期とは断定できません。自社の対象範囲と意思決定の体制を踏まえて、計画を立てます。

保守・運用費と更新対応の別枠見積もり

初期費用のほかにも、ライセンス、追加アプリ、Power Platformや連携サービス、保守・運用、ユーザー教育の費用は継続してかかります。

一般的な業務システムでは、年間の保守・運用費を初期開発費の15〜25%程度とする目安があります。ただし、これはBusiness Central固有の公式料金ではないため、予算計画の参考レンジとして扱います。

Microsoft更新の回帰テストや問い合わせ、障害対応、軽微な変更、データ修正、月次報告について、保守契約に含まれる範囲を分けて記載してもらいます。

ポイント

予算は、ライセンス費だけで判断せず、導入支援や保守・運用、更新対応まで含めた金額で組みます。区分の目安は、自社の対象範囲に近いものを使います。

委託先の選定と見積比較の観点

委託先は、自社と近い業種や規模の導入経験、会計や製造の業務知識で比べます。Microsoftのパートナー資格や知名度は、判断材料の一つにとどめます。データ移行や連携、教育、運用保守の体制も確かめます。

提案書の見た目より、要件を標準・設定・拡張に分けて、費用とリスクを説明できるかを重視します。同じRFPを2〜3社に渡し、同じ質問と評価基準で比べると、価格差の理由が見えてきます。

同業・同規模の実績と担当者の専門性

導入社数だけでなく、会社数や拠点数、ユーザー数を尋ねます。さらに、対象モジュールや製造・サービスの有無、海外展開、連携先、稼働後の支援期間も確かめます。

公開事例の会社名だけでは、担当範囲は分かりません。そこで、提案に参加するコンサルタントやエンジニアが、その案件で何を担当したかを確かめます。

会計担当者や現場責任者、データ移行担当者、技術担当者と面談し、質問に分かりやすく答えられるかを評価します。

見積書の工程・工数・前提条件

見積書は工程ごとに分けてもらい、作業の抜けや費用の違いを比べられる形にします。

  • 対象工程:要件定義、Fit-Gap、基本設計、環境設定、拡張開発、外部連携、データ移行、テスト、教育、切替、稼働後支援
  • 各工程の条件:担当ロール、工数、単価、期間、納品物、前提条件、除外事項
  • 一式項目:「移行一式」などは件数、画面数、帳票数、データ量、対応時間を明確にします。

内訳があれば、安さが作業の抜けによるものか、効率化によるものかを判断できます。

価格差は、初年度だけでなく、3〜5年のTCO(総保有コスト)で試算します。試算には、ライセンスのユーザー構成や追加アプリの年額、保守料を含めます。さらに、アップデート検証や連携基盤、教育、障害対応、将来のユーザー追加も入れます。

初期費用が低くても、独自アドオンが多く更新のたびに手作業の検証が必要なら、長期では高くなる可能性があります。逆に、標準機能中心の導入でも、移行や教育が不足すれば、稼働後に追加費用が発生します。

提案内容と運用体制のリスク

提案内容、更新対応、セキュリティ、運用体制は、合わせて確かめます。特に次の点は、契約前に候補会社へ聞いておきます。

  • 提案の妥当性:短納期・低価格だけを強調する、標準と追加開発の区分がない、特定担当者に依存する提案に注意します。
  • 更新の責任:影響調査、受入テスト、既存拡張との互換性を誰が確認するか決めます。
  • セキュリティ:ロールと権限セット、承認者と入力者の分離、特権アカウント、外部連携認証、監査ログ、退職者のアカウント、バックアップと復旧を確かめます。
  • 運用体制:障害時の連絡、再委託管理、担当者交代、教育、実運用メンバーの提案同席を確認します。

Business Central Onlineは、継続的に更新されます。2026年リリースウェーブ1などの機能追加やAI・Power Platform連携を踏まえて、影響調査と受入テストの担当者を確かめます。

Microsoft Learnは、2026年4月から9月の機能計画を示しています。対象には、AIによる自動化や財務、製造、サプライチェーン、連携、コンプライアンスなどがあります(出典: Microsoft Learn「2026 リリースウェーブ1」、2026年確認)。

新機能を使うかどうかより先に、既存の拡張との互換性と、更新時の責任分界を契約に定めます。

Microsoftへの問い合わせ方法も確かめておきます。実運用を担うメンバーから体制を聞いておくと、契約後の認識のずれを小さくできます。

ポイント

委託先の比較は、同じRFPに対して、工程ごとの金額と前提条件がそろうかを基準にします。価格差の理由を説明できない提案は、契約前に確かめ直します。

Dynamics 365 Business Centralの発注・外注に関するよくある質問

費用や期間は、会社の条件によって大きく変わります。ここで示す範囲を、そのまま契約条件にはせず、RFPと見積の前提をそろえて確かめます。

Business Centralは普通のシステム開発会社へ依頼できますか?

依頼はできます。ただし、一般的なWeb開発だけでなく、Business Centralの導入や設定、AL拡張、データ移行、運用に詳しいパートナーを選ぶ必要があります。

ERPの会計や在庫、販売、購買の業務知識が不足すると、画面は作れても、月次決算や在庫評価が成り立ちません。

候補の会社には、Microsoft製品の実績や同業の導入事例、担当者の業務知識、アップデート対応の体制を確かめます。

見積もりにはどのくらいの期間が必要ですか?

簡単な初期相談や概算は、数週間程度で示される場合があります。一方、正確な見積には、現状ヒアリングや対象業務の確認、データと連携の洗い出し、Fit-Gapが必要です。

標準機能中心の小規模導入は3〜6か月程度、中規模は5〜10か月程度です。製造や多法人、海外、複雑な連携を含む場合は、8〜18か月程度が推定の目安になります。

JBSは約5か月の導入事例を公開しています。ただし、対象範囲と意思決定の速さが異なるため、自社の納期は別途計画します。

一番安い見積を選べば問題ありませんか?

一番安い見積が適切とは限りません。要件定義や移行、テスト、教育、保守が除外されていると、追加費用や納期の延長が起こる可能性があります。

工程別の費用、前提条件、除外事項、変更時の単価、初年度から5年間の運用費を同じ条件で比べ、価格差の理由を説明できる会社を選びます。

また、標準化で安くした提案なのか、作業を削った提案なのかも見分けます。

ライセンスだけ契約して社内で導入できますか?

小規模で標準機能を使い、社内に会計や業務設計、Microsoft製品の知識がそろっていれば、社内主導で進められる可能性があります。

社内主導の場合は、データ移行や税務要件、権限、連携、受入テスト、稼働後の更新対応まで、自社で担う必要があります。

まず導入パートナーに現状診断やPoCを依頼すると、外注する範囲と社内で担える範囲を分けやすくなります。その結果、過剰な委託を避けながら、リスクも把握できます。

まとめ

対象範囲と責任を明確にし、見積と契約を同じ前提で比べることで、導入後の想定外を減らせます。発注前に確かめる事項は、大きく二つの観点に分かれます。一つはRFPと評価表で、もう一つは初期導入後の運用と更新の契約確認です。

発注前のRFPと評価表

RFPには、改善したい業務や対象の会社・拠点・ユーザー、標準化と拡張の希望を記載します。さらに、移行データや連携先、税務・セキュリティ要件、希望稼働日、保守条件も書き込みます。

評価表では、業務理解やBusiness Centralの実績、提案の具体性を見ます。費用面では、初期費用、ライセンス、保守、5年間のTCOを並べ、体制や契約条件も同じ表に加えます。

同じ資料を2〜3社に渡すと、価格以外の提案の質も比べられます。

初期導入後の運用と更新の契約確認

発注の段階で、導入後の運用範囲も契約に書き込んでおく必要があります。初期設定の範囲だけでは足りず、移行のやり直しや障害対応、Microsoft更新への対応まで誰が受け持つかを決めておきます。契約で見る項目は、次の2つです。

  • 運用支援:初期設定・開発に加え、移行のやり直し、ユーザー教育、障害対応、Microsoft更新、アドオンの互換性確認を含めます。
  • 引き継ぎ:担当者交代時の引き継ぎと、終了時に設定情報・コード・テスト資産を返却する条件を決めます。

Business Centralでは、標準機能を軸に設計や設定、拡張を組み合わせます。連携や移行、テスト、教育、保守も、この流れの中に位置づけます。

標準化する業務と、自社固有の価値を守る業務を分けて整理し、費用や責任、納品物を契約で明確にします。

こうしておくと、導入後の追加費用や運用の負担を抑えやすくなります。

▼全体ガイドの記事
・Dynamics 365 Business Centralのシステム開発の完全ガイド

会社紹介

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

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

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

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

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

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