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

Dynamics 365 Financeの発注は、目的と対象範囲を整理し、RFPを作ってから、複数社の提案と見積を比べる順で進みます。

Dynamics 365 Financeは会計方針や業務プロセスを含むクラウドERPのため、発注前に決めることが多くあります。

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

Dynamics 365 Financeの発注・外注で押さえる全体像

Dynamics 365 Financeは、会計方針や業務プロセスを含むクラウドERPです。そのため、発注の対象は会計システムの開発だけでなく、マスターデータや権限、周辺システムにも広がります。

移行や教育、稼働後のアップデート対応も、サービス設計に含めて考えます。発注範囲を分けておけば、追加費用と責任分界を明確にできます。

一括請負・準委任・段階発注の選び方

発注形態は、要件がどこまで確定しているかと、自社でプロジェクト管理をどこまで担えるかで選びます。一括請負は、合意した要件と成果物を完成させる契約で、予算と納期を管理しやすいのが特徴です。

  • 一括請負:契約後の仕様変更が、追加費用になりやすい形態です。
  • 準委任:専門人材の稼働と業務の遂行を委ねる契約です。
  • 段階発注:調査は準委任、要件定義と基本設計は準委任または成果報酬、設定・開発・移行・テストは請負、稼働後は保守とします。

準委任は、Fit/Gapやプロトタイプ検証のように、進めながら要件を具体化する局面に向いています。ただし、発注者側に意思決定者がいないまま選ぶと、作業時間だけが増えてしまうため、注意が必要です。

段階の組み方は、Finance単体で進めるか、周辺製品も扱うかで変わります。周辺製品の例は、Supply Chain ManagementとProject Operationsです。さらに、Power BI、Azure、既存販売管理も対象になります。

RFPには、各フェーズの成果物と前提条件を明記し、受入基準と変更管理の方法も示します。

製品設定から定着化までの委託範囲

見積を比べられるように、委託範囲を分けておきます。

  • 業務と製品:業務構想や改革、Financeの標準設定、追加開発を切り分けます。
  • 移行と検証:外部連携やデータ移行、テスト、教育の担当範囲を定めます。
  • 稼働後:運用保守と、継続アップデートの影響確認を含めます。

範囲を「一式」とだけ書くと、何が含まれるのか分かりません。たとえばデータ移行では、対象テーブルや過去何年分かを決め、重複・欠損のクレンジング担当も決めます。さらに、移行リハーサルを何回実施するかも記載します。

日本企業では、勘定科目や財務ディメンションのほか、請求書や電子取引、電子帳簿保存を業務単位で確認します。また、税務帳票や承認権限、監査証跡も確認の対象です。

Microsoftは、2026年のリリース wave 1で、複数エンティティへの対応や決算期間の短縮を計画しています。この計画には、電子請求書サービスの統合拡張フレームワークやエージェント活用も含まれます(出典: Microsoft Learn「Overview of Dynamics 365 Finance 2026 release wave 1」、2026年)。

ポイント

発注形態は、要件の確定度と自社の管理範囲で選びます。移行や教育、稼働後の対応まで範囲を分けて示すと、追加費用と責任分界を明確にできます。

Dynamics 365 Financeの発注・外注の進め方

発注・外注を目的と範囲の決定から移行・稼働判定まで4段階で示す図。
上流で決めた条件が、後工程の検証や稼働判定につながります。

まず目的とKPIを決め、現行業務とデータを洗い出します。次に、RFPで要件と責任分界を示し、提案と見積を比べます。画面や帳票の細部より先に、経営課題と業務シナリオを定義しておきます。

UnitedLexは、FinanceとSupply Chain Managementを導入し、5つの分散システムを5か月で一つの基盤へ移行しました。同社は、カスタマイズを増やさず設定を活用しました(出典: Microsoft Customer Stories「UnitedLex」、2026年)。ただし、この事例は全案件が5か月で完了することを示すものではありません。

プロジェクト期間は、ライセンス期限などの制約や対象範囲、意思決定の速さによって大きく変わります。

目的・KPIと対象範囲の決め方

まずは製品名ではなく、どの業務を変えたいかを言葉にします。たとえば、月次決算を何日短縮するか、請求書の誤りをどの工程で減らすかまで決めておきます。

  • 目的:解決したい業務課題を定めます。
  • KPI:決算日数、消込未処理件数、差戻し率、集計時間、移行後のエラー件数を測ります。
  • 対象範囲:法人・国・通貨・拠点・ユーザーと、製品間の境界を決めます。

さらに、複数法人の残高を把握する頻度や、監査証跡を自動化する範囲も定めます。KPIには、稼働後に測定できる指標を選びます。

財務会計だけであれば、Finance単体で足りる可能性があります。一方で、在庫、購買、倉庫まで一体で管理する場合があり、製造やプロジェクト原価を含むこともあります。その場合は、Supply Chain ManagementやProject Operationsとの境界を決めます。

業務フロー図で、Financeに含める業務と既存システムに残す業務を分けて示すと、過剰な機能提案や後の追加開発を抑えられます。

RFPに書く業務・データ・連携・運用の要求

RFPには、会社概要や希望納期だけでなく、発注先が判断できる具体的な情報を記載します。会計、販売、購買は、一覧にして示します。給与や銀行の業務も、同じ一覧に加えます。請求書受領やデータウェアハウスも、対象に入れます。

  • 現行環境:システム名、保有データ、連携の方式と頻度、廃止予定、担当部署を洗い出します。
  • 業務要件:会計処理から予算・税務・承認・監査まで、業務シナリオに書き起こします。
  • 実施条件:必須・希望・対象外の区分、移行対象期間、受入基準、教育対象、稼働後のSLAを定めます。

売上計上、買掛計上、入金消込のシナリオを書くと、製品の説明からは見えにくいギャップを把握できます。固定資産や予算、経費もシナリオに含めます。さらに、決算、税務、承認、監査も対象にします。

標準機能へ寄せる方針と、追加開発を認める条件も明記します。テストデータの準備を誰が担うかも、決めておきます。

定期アップデートへの対応方法を定めたうえで、パートナーには適合度、前提条件、除外事項を示してもらいます。

条件をそろえておけば、安い初期見積の後に想定外の連携や追加の移行作業、ユーザー教育が膨らむリスクを抑えられます。

Fit/Gapとプロトタイプによる標準化の範囲

対応方法は、Financeの標準機能を基準に検討します。現行業務はそのまま再現せず、標準機能へ寄せる前提で見直します。

  • Fit/Gap:標準機能、設定、運用変更、追加開発に業務を分けます。
  • 試作確認:判断が難しい業務を取引シナリオで検証します。
  • 提案検証:設定・権限・帳票・例外処理を実演できるか確認します。

競争優位に直結しない独自帳票やExcel作業まで再現すると、初期費用が増えます。さらに、将来のアップデート検証と保守費用も膨らみます。

複数法人間の仕訳や外貨建て請求、入金消込、承認差戻しを試します。固定資産の移管や月次締めは、実際のデータに近い形で検証します。

移行・テスト・教育・稼働判定の契約範囲

導入の成否は、設定や開発だけでなく、移行データと現場の利用定着で決まります。

  • 移行対象:顧客・仕入先・品目、勘定科目・財務ディメンションを含めます。残高・明細・固定資産も移行対象に入ります。
  • 移行作業:クレンジング・変換・照合・承認の担当者を割り当てます。
  • 移行期間:必要期間を決め、参照用アーカイブとの役割を分けます。
  • テスト:単体・連携・業務シナリオ・性能を順に計画します。さらに、権限・セキュリティ・ユーザー受入・移行リハーサルも確認します。
  • 教育:操作説明会と手順書、窓口、初月の伴走に加えて、権限申請や障害時の切り分けも含めます。

過去データは、法令・監査・業務分析に必要な期間を決めて移します。経理部門が月末処理を完了し、差異を説明できるかも確かめます。

稼働判定の条件を契約書と計画に記載しておけば、納品済みかどうかを感覚で争わずに済みます。

ポイント

目的とKPI、対象範囲を先に決め、RFPで要件と責任分界を示してから提案と見積を比べます。業務シナリオを先に定義しておくと、各社の提案を同じ基準で比べられます。

Dynamics 365 Financeの費用相場と契約・コストの内訳

案件規模別に導入費と期間の目安を3枚のパネルで並べた図。
対象範囲の広がりに応じて、費用と期間の幅も大きくなります。

費用は、ライセンスと導入・設定、追加開発の区分で見ます。連携やデータ移行、テスト・教育は、別の区分として見ます。周辺サービスのAzureやPower Platformと、保守・運用も対象です。

導入総額を正しく捉えるには、Microsoftのライセンス価格に加えて、導入や保守の費用も見る必要があります。ここでの数字は、Microsoft公式価格と業務システム一般の相場に基づく目安です。個別案件の公式見積ではないため、RFPの条件をそろえて提案会社に確認してください。

ユーザー種別と利用量によるライセンス費の試算

2026年8月確認時点のMicrosoft公式日本向け価格は、Dynamics 365 Financeが31,484円、Finance Premiumが44,977円です。

  • 価格計算:FinanceとPremiumの料金に、利用ユーザー数を掛けて試算します。
  • 利用形態:フルアクセス以外に、読み取り専用、制限付き、管理者の区分も確認します。
  • 追加費用:容量、Copilot、Power Platform、Azureを分けて見積もります。

いずれも、ユーザー/月相当の年払いで、消費税は含みません(出典: Microsoft「Dynamics 365 Financeの価格」、2026年8月確認)。

単純計算では、Financeを50ユーザーで契約すると年間約1,889万円、Premiumでは年間約2,699万円になります。100ユーザーの場合は、Financeが年間約3,778万円、Premiumが約5,397万円です。

なお、Finance Premiumには、追加の容量・ストレージの権利と、ユーザー/月相当のCopilotクレジットが含まれます。

エージェントを利用する場合は、Azureサブスクリプションや追加クレジットが関わることがあります。契約期間と価格改定の条件は、見積書で確認します。

導入・拡張費の幅(3,000万円から3億円以上)

導入費は対象範囲によって変わるため、案件規模ごとに条件と金額、期間を見ます。

  • 単一法人・標準中心:3,000万〜8,000万円、6〜10か月程度です。
  • 複数法人・国内連携:5,000万〜1.5億円、9〜15か月程度です。
  • 複数国・複雑な拡張:1億〜3億円以上、12〜24か月以上の場合があります。

国内連携の案件では、日本固有の税務や既存会計・販売・銀行連携、データ移行を含みます。複数国展開では、FinanceとSupply Chain Managementの組み合わせや、製造・プロジェクト会計、複雑なアドオンと連携を含む場合があります。

これらの期間・金額は、リサーチノートに基づく編集用の目安です。Finance向けに、Microsoftが一律に公開している標準導入価格はありません。この金額は、業務システム一般の中規模・大規模案件の相場と、Financeが基幹ERPであることに基づく推定です。

金額は、法人・国・通貨の数や、標準機能へ寄せる範囲で変わります。さらに、移行データの品質と連携本数も影響します。帳票と税務の範囲は、金額に響きます。権限や監査の範囲も、金額に響きます。テストや教育・定着化の範囲でも、金額は変わります。

見積依頼では、単価だけでなく、人数、工数、期間、成果物、前提条件を並べて確認します。

契約形態とランニング費用の分け方

契約条件は、作業範囲に合わせて整理します。

  • 請負:成果物、受入基準、検収時期、瑕疵対応、変更単価を明記します。
  • 準委任:稼働時間、役割、会議体、成果報告と納期への影響を定めます。
  • 保守・運用:対象作業、平日・休日の対応時間、重大障害の目標時間、アップデート検証の回数、追加作業の単価を決めます。

要件が固まっていない段階では、全工程を請負にするより、要件定義とプロトタイプを先行させます。そのうえで、確定した範囲を開発の請負へ移すと、双方のリスクを調整しやすくなります。

一般的な業務システムでは、初期開発費の年15〜25%程度を保守・運用費とする目安があります。ただし、Financeの費用は、含める作業によって変わります。

保守の範囲は、まず月次問い合わせや障害一次切り分け、連携監視を含むかを確認します。さらに、法改正、定期アップデート、回帰テスト、権限変更、追加改善まで含むかも確認します。

ポイント

費用はライセンス、導入、追加開発、保守に分けて見ます。金額は法人数や国の数、移行データで変わるため、条件をそろえた見積で比べるのが目安です。

RFP・見積比較でDynamics 365 Financeの委託先を選ぶポイント

委託先を実績と専門性、見積範囲、契約リスクの3項目で確認するチェックリスト図。
3項目を同じ条件で照らすと、提案内容の差を追いやすくなります。

委託先は、知名度や提示価格だけでなく、Financeの導入経験や会計・税務の理解を含めて総合的に比べます。データ移行や連携、管理、稼働後支援も、比べる対象です。

Microsoftのパートナーディレクトリで取扱領域を確認したうえで、候補各社に同じRFPを渡します。提案の差が前提条件や除外範囲の違いによる場合もあります。そのため、質問書で条件をそろえます。

Financeの実績と担当チームの専門性

Finance単体と周辺製品を組み合わせた実績を分けて示してもらいます。

  • 導入事例:自社に近い法人・業種・国・会計方針の案件かを確かめます。
  • 実務力:匿名シナリオ、体制図、成果物、テスト計画も判断材料にします。
  • 担当体制:営業と責任者、会計・設定・連携・移行・定着の役割を見ます。
  • 再委託と交代:委託先の責任者、中心メンバーの交代条件と引継ぎを確認します。

周辺製品には、Supply Chain ManagementとPower BIがあります。AzureやPower Platformも、周辺製品に含まれます。プロジェクトの規模、期間、移行対象、稼働後の課題も確認します。

提案営業と、実際のプロジェクト責任者が同じかを確認します。再委託がある場合は、会社名と担当範囲、品質管理と情報管理の責任者を明記させます。

作業単位と除外事項で比べる見積書

総額が安い会社をすぐには選ばず、同じ条件で見積を並べます。

  • 内訳:ライセンスから教育・保守まで作業単位で金額と工数を比べます。
  • 除外事項:成果物、担当、期間、完了条件を明らかにします。
  • 総保有コスト:標準設定・業務変更・追加開発を5年程度で比較します。

環境構築や帳票、権限の有無を確認します。さらに、監査ログやデータクレンジングの有無も見ます。

移行リハーサルとユーザー受入テスト、マニュアル、問い合わせ窓口も確認対象です。

見積書で「一式」が多い場合は、比較前に具体的な作業内容を確認します。

標準機能中心と大規模カスタマイズの差は、品質より設計思想による場合があります。

比較案は3つにします。そのうえで、総保有コストには、将来のアップデート検証や保守、ユーザー教育の費用も含めます。

契約・セキュリティ・アップデートのリスク

契約前には、仕様変更や遅延、データ品質不良、受入未達を想定します。さらに、再委託や情報漏えい、ライセンス変更、Microsoftのリリースによる影響も想定します。変更要求の分析から実施、記録までは、変更管理票で運用します。

  • 契約変更:遅延・受入未達・仕様変更の対応を決め、変更管理票で記録します。
  • 情報と権限:アクセス、監査、復旧、データ返却の責任を定めます。
  • アップデート:新機能の変更可能性、費用、出力確認の担当を明確にします。

要件が曖昧なままの固定価格や、発注者の回答遅れをすべて納期延長とする条項には、注意が必要です。不具合修正と追加要望の区別がない保守契約も、後で紛争になりやすい項目です。

権限では、Entra ID、ロールベースアクセス、職務分掌を確認します。監査ログや特権アカウント、退職者の無効化、バックアップと復旧手順も確認します。データ所有権や環境アクセスも定めます。

設定・ソース・連携仕様書の引き渡しと、契約終了時のデータ返却も定めます。

2026年の新機能やプレビュー機能は、一般提供の予定、変更可能性、追加費用を確認します。誤った出力の確認責任も、明示してもらいます。

新機能を採用しない場合の代替手順も説明できる会社を選ぶと、運用が安定しやすくなります。

ポイント

委託先は実績と担当体制、見積の作業単位、契約リスクを同じ条件で比べます。提案の差が前提条件の違いによる場合もあるので、質問書で条件をそろえます。

よくある質問(FAQ)

発注では、標準機能で実現する範囲と、業務やデータの準備を誰が担うか、稼働後のアップデートを誰が担うかが論点になります。次の質問に順に答えます。

Dynamics 365 Financeのシステム発注は中堅企業でもできますか?

中堅企業でも発注できます。適切な導入規模は、法人・国・ユーザー数、業務範囲、連携本数、既存データの状態によって変わります。

単一法人で標準機能中心なら、大規模な全社刷新を避け、会計と優先連携から段階導入できます。また、将来の拡張も設計しておく方法が現実的です。

RFPはどの程度作り込んでから外注すべきですか?

RFPの段階では、製品の設定値や画面仕様まで確定させる必要はありません。目的と対象範囲、現行システム、業務シナリオを整理します。データと連携、希望時期も整理しておきます。

体制と予算の考え方も示します。そのうえで、必須要件、希望要件、対象外、発注者が準備するものを分けておくことが大切です。情報が不足する場合は、要件定義フェーズだけを先に発注し、その成果物をもとに本開発の見積を取り直す方法も選べます。

標準機能とカスタマイズはどのように判断しますか?

法令・監査・競争優位に関わる必須要件は、標準設定、拡張、外部連携、追加開発の順に代替案を検討します。独自帳票や従来のExcel操作を再現する開発は、業務変更やPower Platformで吸収できないかを先に確認します。

カスタマイズする場合は、アップデートへの影響、テスト方法、保守担当、5年程度の費用を提案書に記載してもらいます。

Dynamics 365 Financeの導入費用は結局いくらですか?

公式に一律の導入費用は公開されていません。金額は要件次第で変わります。

  • 単一法人:標準機能中心・連携少なめなら3,000万〜8,000万円です。
  • 複数法人:国内税務、既存会計・販売・銀行連携、移行を含む場合は5,000万〜1.5億円です。
  • 複数国:Supply Chain Managementや複雑なアドオンを含む場合は1億〜3億円以上です。

複数国の案件では、製造・プロジェクト会計も費用に影響します。これらは推定レンジにすぎないため、同一RFPで2〜3社以上へ見積を依頼します。ライセンス、導入、追加開発、保守は、分けて見ます。

稼働後のアップデート対応も外注できますか?

外注できます。保守契約には、Microsoftのリリース確認や影響調査、検証環境での回帰テスト、設定変更、障害対応の範囲を記載します。

法改正や電子請求書への対応、ユーザー問い合わせを、どこまで含めるかも決めます。プレビュー機能やAIエージェントを使う場合は、変更可能性と、Azure・Copilotクレジットを確認します。利用ログと権限、業務担当者による出力確認も、契約上の役割分担に含めます。

ポイント

中堅企業でも発注でき、導入規模は法人数や業務範囲で決まります。RFPでは製品の設定値まで確定させず、必須要件と対象外を分けて示します。

まとめ

発注時は、製品ライセンスの購入と、導入・設定・開発・移行・教育・保守を分けて考えます。要件が固まる前は、準委任や段階発注が候補になります。

成果物と受入基準を決められる範囲では、請負を組み合わせます。そのうえで、プロジェクトの実態に合わせて契約を設計してください。

発注前に確認する項目

発注前の確認事項は、一枚のRFPにまとめます。

  • 対象:法人・国・通貨、製品の境界、現行システムと連携を記します。
  • 実施範囲:移行データ、標準化する業務、必須の追加開発を整理します。
  • 運用条件:権限・監査、テスト・教育、稼働後の保守を含めます。

Adecco Groupは、450法人・60か国へ段階的に展開しました。同社は、テンプレート方式を成功要因に挙げています(出典: Microsoft Customer Stories「The Adecco Group」、2025年)。大規模案件では、最初から全社一括にせず、共通テンプレートと段階展開の範囲を比べます。

同じ条件での見積比較と発注先の決定

同じ条件のRFPで各社を比較し、提案から稼働後まで評価します。

  • 提案力:Finance実績、会計・税務知識、Fit/Gapの説明を確かめます。
  • 体制と運用:責任分界、担当、再委託、アップデート、稼働後SLAを比べます。
  • 費用:導入・保守・追加クレジットも含む総保有コストで判断します。

ライセンス価格は、2026年8月時点の公開情報でも変わり得ます。そのため、契約時点の価格とライセンス条件も確認します。

RFPと比較表を用意したら、複数の導入パートナーへ相談します。自社の業務シナリオを使って、提案と見積を依頼してください。

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

会社紹介

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

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

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

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

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

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