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

Dynamics 365の発注は、業務成果と対象範囲を決め、RFPで要件をそろえ、契約で「どこまでを誰が受け持つか」を定めて進めます。この順で進めると、導入後の運用にもつながります。

発注形態の選択から発注後の管理まで、見出しの順に読むと流れがつかめます。

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

Dynamics 365のシステムを発注・外注する前に押さえる全体像

Dynamics 365の発注では、ライセンスの購入と、業務で使える状態にする導入を分けて考えます。ライセンスはMicrosoftから購入します。

一方、導入の作業は、Microsoftパートナーや開発会社へ委託するのが一般的です。業務ヒアリングや設定、拡張、データ移行を含め、外部連携やテスト、教育、稼働後の保守まで委託の範囲に入ることもあります。

Dynamics 365の構成は業務アプリの組み合わせ

Dynamics 365には、業務に応じて選ぶアプリがあります。

Sales：顧客、リード、商談、見積、受注の管理
Customer Service：問い合わせやナレッジの管理
Finance・Supply Chain Management：財務・会計、購買・在庫・倉庫・生産
Business Central：販売、購買、在庫、会計をまとめて扱いたい中堅・中小企業の候補

FinanceやSupply Chain Managementでは、会計と在庫の業務モデル設計、データ移行が発注範囲に入りやすくなります。ほかにも、次の項目が範囲に含まれやすくなります。

税務の業務モデル設計：Financeで扱う税務の処理
生産の業務モデル設計：Supply Chain Managementで扱う生産の処理
法改正への対応：制度変更に合わせた対応
定期アップデートへの対応：Microsoftの定期更新に合わせた対応

Salesなどの顧客接点アプリでは、Dataverseをデータ基盤にできます。さらに、Power Appsで画面を拡張し、Power Automateで承認や通知を自動化し、Power BIで分析する構成も取れます。

外注の目的は業務成果の実現

発注前に「Dynamics 365を導入する」を、業務成果へ言い換えておきます。営業案件化率や問い合わせの一次解決率が、その例です。月次決算や在庫の実績と計画の差も、業務成果として扱えます。

成果指標が決まると、必要なアプリと利用ユーザーを絞り込めます。移行データ、連携対象、教育対象も、そこから決まります。画面や機能の一覧だけを渡すと、会社ごとに前提の違う見積が集まります。

安く見える提案でも、移行リハーサルや例外処理が別料金になることがあります。教育やアップデート検証が別に計上される場合もあります。そのため、範囲を先に確認しておかないと、後から追加費用が発生することがあります。

Dynamics 365の発注形態の選び方

発注形態は、標準機能中心、一括委託、自社主導の伴走支援の三つに分かれます。選ぶ際は、利用人数と業務範囲に加え、社内に業務設計やプロジェクト管理の人材がいるかを見ます。

標準機能と設定を中心にした導入

Salesを10〜30人程度で使い、営業プロセスを大きく変えず、顧客と案件、活動を一か所にまとめる場合に現実的です。権限とフォームを整えたうえで、ビューやダッシュボード、基本ワークフローを設定します。

データ移行と連携は少数に絞ります。この形態は費用と期間を抑えやすい一方で、使い慣れたExcelの項目や独自承認を、すべて再現できるとは限りません。

まず、Fit to Standard（標準機能に業務を合わせる考え方）の範囲を、発注側と開発会社で合意します。そのうえで、例外だけを追加開発の候補にします。

要件定義から開発・移行・運用までの一括委託

複数法人・拠点や会計・販売・在庫・生産をまたぐ場合は、一括委託が向いています。

計画：Fit & Gapとデータモデルをまとめる
実装と展開：連携方式やテストを含め、教育と切替まで一つの計画にする
責任：Dynamics 365に詳しい開発会社に、範囲ごと委託する

計画を一つにまとめると、責任の所在を明確にしやすくなります。

ただし、意思決定を丸投げしてはいけません。業務フローやマスタの正解は発注者が決めます。残すデータや変えない業務、稼働判定の基準も、発注者が定めます。

受託会社の提案を採用する場合でも、各領域に社内の業務責任者を置きます。

自社主導に専門家が伴走する形態

社内にPMや業務設計の人材がいて、将来の運用を自社に蓄積したい場合に選べます。外注するのは、アセスメントと設計レビュー、難しい拡張、教育だけという形態です。

開発会社がすべてを抱えないため、内製化や段階展開へ進めます。一方、社内担当者の稼働が不足すると、意思決定が遅れます。

会議体と決裁者、レビュー期限、成果物の受け入れ担当を、あらかじめ決めておきます。さらに、月次の経営報告まで体制図に記載します。

ポイント

発注形態は、利用人数と業務範囲、社内に業務設計やプロジェクト管理の人材がいるかで選びます。標準機能中心、一括委託、伴走支援のどれが合うかを、この3点で見極めます。

RFPと要件整理の進め方

要件を同じ粒度で並べると、提案内容を照らし合わせやすくなります。

RFPは、開発会社へ希望を伝える書類であると同時に、自社の要件を整理する帳面です。まず、現状課題と対象範囲、業務量を記載します。続けて、データや連携、品質、運用も同じ粒度で書きます。

RFPへの業務課題とKPIの記載

「営業情報を一元化する」と書くだけでなく、案件ステージの統一や、担当者別の月次受注見込みの集計まで、業務内容を具体的に書きます。

KPIの候補は、対象業務ごとに異なります。

営業：案件化率、失注理由の記録率、予実差
問い合わせ対応：一次解決率、平均処理時間
ERP：締め処理日数、在庫精度

KPIは、発注先に成果を保証させる数字であるだけでなく、機能の優先順位と初回リリースから外す範囲を判断する基準です。

現状値と目標値、測定方法、測定開始時期まで決めておくと、稼働後の定着支援も具体的になります。

対象アプリ・利用者・データ・連携の具体化

RFPには、対象範囲と規模を次のとおり記載します。

アプリ：Sales、Customer Service、Financeなど、対象とするアプリ
利用規模：ユーザー数と役割、法人・拠点数、月間取引件数
移行データ：顧客、商品、担当者、勘定科目、在庫、過去取引の件数と対象時点
連携先：Microsoft 365、Outlook、Teams、基幹、会計、EC、倉庫、外部API

旧システムとExcelの種類も洗い出し、移行件数と対象時点を決めます。

連携では、リアルタイムか日次か、エラー時の再送や重複排除をどうするかに加え、監視担当や認証情報の管理も記載します。条件が曖昧なままだと、「連携は含まれると思っていた」という認識のずれが生まれ、追加費用につながります。

標準・設定・拡張・外部化の境界の提案

各要件への対応方法を、次の区分で提案書に書いてもらいます。

標準機能：Dynamics 365に備わる機能で対応
設定：標準機能の設定で対応
拡張：Power AppsやPower Automateで対応
外部化：外部システムに機能を配置
個別開発：独自に開発して対応

標準機能から外れるほど、初期費用だけでなくアップデート検証や保守の負担も増えます。

PoCでは、画面の見栄えだけでなく業務の流れも試します。たとえば、権限エラーや重複データ、承認差戻しを確かめます。さらに、API障害や月次締め、移行後の照合も対象にします。

PoCの目的と期間、成果物、継続開発へ移る条件も、RFPに明記します。

ポイント

業務課題とKPIを先に決め、対象アプリや連携、標準・拡張の境界まで提案書に書いてもらうと、各社の提案を同じ土台で比べられます。

Dynamics 365の外注で選ぶ契約形態と責任分界

要件が固まった部分と調査が必要な部分を分けて契約します。工数は、標準機能や移行可能なデータ、連携先APIの仕様で変わるため、すべてを初めから固定価格にすると合わないことがあります。

請負契約の成果物と受け入れ条件

要件定義や設計が終わり、範囲と成果物を固定できる部分は、請負契約の候補になります。契約書には、画面や帳票、ワークフローを記載します。さらに、連携や移行、テスト仕様書も書き込みます。

納期と検収方法、瑕疵対応、変更管理も明記します。「システムが使えること」のような曖昧な条件では、検収の判断がつきにくくなるため、避けます。

判定条件には、テストケースの合格率や重大障害がないこと、移行前後の件数・金額照合を置けます。操作マニュアルの納品や管理者教育の実施も、条件にできます。

準委任契約が向く調査・伴走・変更の多い部分

作業時間や専門知識の提供を重視する部分は、準委任契約が候補です。

現状分析：現行業務の調査、Fit & Gap
設計・管理：アーキテクチャ検討、プロジェクト管理
稼働後：運用支援

担当者の役割と月の稼働上限、会議体を明記します。また、成果物とレビュー期限、再委託条件を書きます。さらに、情報管理と終了時の引き継ぎも定めておきます。

要件が変わりやすい初期フェーズでは、成果物を無理に固定しないほうが進めやすくなります。代わりに、月次報告と合意した稼働範囲で管理し、意思決定に必要な成果を定例で確認します。

追加変更・ライセンス・運用の費用負担の切り分け

契約時に確認する費用と運用条件は、次のように分けて考えます。

追加作業：要件変更の単価、追加の人月や連携、データの再移行
導入時：休日切替、教育回数、出張
利用料金：Azure、Power Platform、Copilotクレジット、Microsoftサポート
保守：受付時間、初動・復旧目標、障害と変更の区分、更新、脆弱性、データ復旧
契約終了時：設定情報、ソースコード、設計書、移行定義、管理者アカウントの返却

ライセンス費用と導入会社への支援費用は、請求元が異なる場合があります。そのため、支払先と時期を確認しておきます。

ポイント

成果物と範囲を固定できる部分は請負、調査や伴走が中心の部分は準委任と、部分ごとに契約を分けて考えます。費用の変更条件と責任の範囲も、契約書で確かめます。

Dynamics 365の発注費用相場と見積の内訳

対象範囲が広がるにつれて、想定費用の幅も大きくなります。

総額は、Microsoftのライセンス費用と、導入・開発会社へ支払う費用の合計です。後者には、要件定義や設定、追加開発が含まれます。

さらに、移行や連携、テストが含まれ、教育や切替、保守も対象になります。下に示す開発費は、Dynamics 365専用の公式定価ではなく、リサーチノートの業務システム全般の相場を構成規模に当てはめた推定です。

公式ライセンス価格の目安とユーザー数・アプリによる違い

Microsoftの日本向け価格ページで2026年8月に確認した価格は、次のとおりです。いずれも年払い・税別で、ユーザー1人あたりの月額に相当する金額です。

Sales Professional：9,745円、Enterprise：15,742円
Sales Premium：22,488円
Salesの年間額：10ユーザーで約116.9万円から約269.9万円
Finance：31,484円、Finance Premium：44,977円
Financeの年間額：10ユーザーで約377.8万円から約539.7万円

年間額は、年払い・税別価格を10ユーザー分で単純計算した金額です。Salesの価格は、Microsoft「Dynamics 365 Salesの価格」を参照しました。

Financeの価格はMicrosoft「Dynamics 365 Financeの価格」を参照しました。いずれも2026年8月に確認しています。

実額には、権限別ライセンスや追加容量、契約条件が影響します。さらに、Power PlatformやAzure、Copilotクレジットも影響します。

Business Centralのように、パートナーへの問い合わせが必要な製品もあります。そのため、一律の価格とは扱わず、個別に確認します。

導入・開発費の規模別の推定レンジ

小規模CRMから海外拠点を含むERPまで、対象規模によって導入費と期間が変わります。

小規模CRM：300万〜800万円、3〜6か月
中規模CRM／SFA：800万〜2,000万円、6〜12か月
複数法人・拠点のERP：2,000万〜1億円以上、9〜24か月
大規模グループの海外展開：1億円超、1〜3年以上

小規模CRMは、Salesを10〜30人で使い、標準設定や権限、簡単な帳票に絞る場合です。移行は少数、連携は1〜2本に限ります。

中規模CRM／SFAは20〜100人で使い、旧CRMの履歴移行や、Outlook・Teams連携、複数部門の承認を含みます。さらに、Power PlatformやBI、外部基幹とのAPI連携も対象です。

FinanceやSupply Chain Managementを複数法人・拠点で展開する場合、2,000万〜1億円以上の推定になることがあります。期間は9〜24か月です。

大規模グループで共通テンプレートを作り、海外拠点へ展開する場合は、1億円超や1〜3年以上の計画も想定されます。

これらは公式見積ではなく、業務システム全般の人月単価50万〜200万円程度という目安を含む推定です（出典: NotebookLMリサーチノート「Dynamics 365のシステム」、2026年8月作成）。

保守・運用とアップデート対応の見積の分け方

保守の範囲では、Microsoftの料金と、委託先の運用作業、定期更新への対応を分けて見積もります。

業務システム全般の目安：初期開発費の年15〜25％、または月15万〜80万円程度（リサーチノート）
Microsoft側：ライセンス・サービス料金
パートナー側：問い合わせ、監視、改修、アップデート検証
更新計画：リリースサイクル1では対象製品に数百の新機能を案内

保守費は規模やSLAで変わるため、特定の金額は断定せずに扱います。Microsoftの2026年リリースサイクル1は、2026年4〜9月の機能が対象です。

Sales、Finance、Supply Chain Managementなどで、数百の新機能を案内しています（出典: Microsoft Learn「Dynamics 365 2026年リリースサイクル1の計画」、2026年7月更新）。

AIエージェントやCopilotを採用する場合は、利用量や権限、データ品質を保守計画に含めます。加えて、回帰テストと利用者教育も、同じ計画に入れます。

ポイント

総額は、ライセンス費と導入・開発費を合わせて考えます。導入・開発費は規模で大きく変わるため、ここに示す推定レンジは比較の目安として使い、見積で確かめます。

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

知名度や見積総額だけで委託先を決めず、得意なアプリや同じ業種・規模・利用人数の事例を確かめます。移行・連携の担当者と、導入後の窓口も確認します。

Microsoftのパートナーディレクトリで候補を探し、同じ条件のRFPを渡すと比較しやすくなります。

自社の対象アプリと同じ実績の有無

担当アプリごとの経験と、導入後まで支援できる実績を確かめます。

CRM：営業プロセス、Outlook・Teams、重複顧客、活動履歴、権限、現場定着
ERP：法人・拠点、通貨・税務、原価・在庫・生産、決算、マスタ統合、移行リハーサル
デンソー工機部：Dynamics 365、Power BI、AIを活用。作業工数約20％削減、年間約8万時間創出を見込む
AGC化学品カンパニー：関係会社3社でFinanceとSupply Chain Managementを共通利用

Microsoft Customer Storiesのデンソー工機部の事例は、2026年4月10日公開です。SalesとFinanceでは、会社ごとに得意な領域が異なります。

AGC化学品カンパニーの事例は2026年5月22日公開です。受発注・生産・在庫・原価管理の標準化を進めています。

前者は段階的なAI・業務改善型、後者は複数会社のERP標準化型です。そのため、自社の発注目的に近い事例を優先します。

事例では、導入効果だけでなく、導入前の分断や老朽化を確かめます。あわせて、標準化した業務や段階展開、連携方式、稼働後の支援を見ます。

可能であれば、同規模案件のプロジェクト責任者や担当コンサルタントの経歴も提示してもらいます。

同じ項目に分けた見積の比較

見積書は、作業と費用を次の項目に分けて示してもらいます。

導入・構築：ライセンス、要件定義、業務設計、環境構築、設定、追加開発
移行・検証：データクレンジング、移行、外部連携、テスト
展開・運用：教育、切替、保守、予備費

各項目に、対象範囲と数量、単価、工数を付けます。さらに、前提・除外条件や検収物、追加時の計算方法も添えてもらうと、総額だけで比べる失敗を避けられます。

A社は、初期費用が低くても、移行と教育が除外される場合があります。一方、B社は高く見えても、移行リハーサルや稼働後の伴走を含むことがあります。

価格差を「安い」「高い」だけで判断せず、要件ごとに含むか含まないかを、RFP回答表で照合します。

提案に含めるセキュリティと日本の制度対応

Microsoft Learnは、Dynamics 365のセキュリティやコンプライアンスを、共有責任として説明しています。プライバシーとデータ保護も、同じ考え方で扱われます（出典: Microsoft Learn「Secure your Dynamics 365 data and apps」、2026年8月確認）。

要件では、担当範囲を分けて書きます。

Microsoft：データセンター、OS、ネットワーク制御、セキュアなアプリ基盤
利用企業：ユーザー、環境、アプリ、データ権限、連携先認証、監査ログ
環境・権限：Microsoft Entra ID、最小権限、職務分掌、Dataverseロール、管理者権限、監査ログ、バックアップ・復旧、環境分離
Finance：適格請求書、電子取引データ、証憑と仕訳のひも付け、検索性、保存方法

Financeの保存方法は、税務担当者と確認します。

国税庁は、法人の帳簿と取引書類を原則として確定申告書の提出期限翌日から7年間保存する必要があると案内しています（出典: 国税庁「帳簿書類等の保存期間」、令和7年4月1日現在）。

ポイント

知名度や見積総額だけで選ばず、担当アプリの実績や同規模の事例、移行・連携の担当者を、同じRFPへの回答で比べます。

発注後のプロジェクト管理で失敗を防ぐ方法

稼働前の判定条件と、稼働後の更新担当を結び付けて確認できます。

発注後は、要件定義から設計、開発、テスト、教育、切替までの流れに、段階ごとのゲートを設定します。各ゲートでは、承認する成果物を決めておきます。加えて、未解決課題や追加変更、リスク、次の判断者を確認します。

この管理により、問題が納期直前に集中するのを防げます。

移行リハーサルとUATの本番前の実施

移行リハーサルとUATは、本番前に次の手順と確認項目をそろえて行います。

抽出から照合までを複数回試し、手順を固める。
顧客・商品、過去活動、残高、在庫、未完了案件、添付ファイルの移行範囲を決め、件数と金額の照合まで行う。
業務部門がUATを行い、通常処理に加えて承認差戻しや取消、重複、権限不足、連携停止、月次締め、税務帳票、障害復旧を試す。
合格基準、残課題の重大度、対応期限を合意し、基準未達のまま稼働日を迎えない。

UATは、開発会社がするテストとは別に、業務部門が実際のシナリオで受け入れる試験です。

教育・運用・アップデートの担当分担

教育、日々の運用、継続的な更新のそれぞれについて、次の内容を担当者に割り当てます。

教育：操作説明だけでなく、入力時期や承認者、確認するレポートを業務ルールとして伝え、現場リーダーを育成
運用：問い合わせ受付、権限申請、マスタ変更、障害連絡、月次の利用状況確認
アップデート：リリースノート確認、検証環境での影響調査、採用・延期・対象外の判断
委託時：更新前の回帰テストと変更履歴の管理を保守契約に含める

Dynamics 365は継続して更新されるクラウドサービスのため、担当の分担は稼働後も続きます。

Dynamics 365の発注・外注でよくある質問（FAQ）

具体的な金額や期間は、対象アプリやユーザー数によって変わります。データや連携、業務の複雑さでも変わるため、自社条件をRFPにそろえて確認します。

Dynamics 365の開発はいつ外注すべきですか？

業務要件やデータ移行、外部連携のほか、権限やテストで判断しにくい点があれば、早い段階で相談します。

製品選定後の開発だけでなく、アセスメントやRFP作成、PoCの段階から支援を受けることもできます。こうすると、先に不確実性を減らせます。

Dynamics 365の外注費を安くする方法はありますか？

標準機能を優先し、初回リリースの対象業務を絞ります。移行データや連携本数を減らし、帳票と教育範囲を狭めると、初期費用を抑えやすくなります。

必要なテストやセキュリティは削らず、段階導入で後回しにする範囲を明確にします。そのうえで、同じRFPを複数社へ渡し、作業範囲と除外条件をそろえて比較します。

Dynamics 365の契約は請負と準委任のどちらがよいですか？

要件と成果物を固定できる設定・開発・移行は請負が候補です。調査や設計レビュー、PM、運用伴走のように内容が変わりやすい作業は、準委任が向きます。

フェーズごとに契約を分けることもあります。契約名だけで決めず、成果物と範囲、検収の条件を確認します。さらに、変更費用と責任分界も見ておきます。

CopilotやAI機能も発注時に含めるべきですか？

AI機能を発注範囲に含めるかは、利用目的やデータなどの条件で判断します。

対象範囲：利用目的、データ品質、権限、利用量を確認し、必要な機能を選ぶ
提供計画：2026年計画はSalesのCopilot体験と、Finance・Supply Chain ManagementなどのAI活用を案内
見積：AI導入費、Copilotクレジット、Azure、評価、監査、教育、回帰テストを含める

計画上の機能は、提供時期や内容が変わる可能性があります。

まとめ

発注時は、対象アプリと業務成果を決めたうえで、RFPに利用人数やデータ、連携を記載します。品質や運用も、RFPに書いておきます。さらに、標準・設定・拡張・外部化の境界も整理します。

請負と準委任を使い分け、ライセンスと導入費、見積の除外条件を確認すると、責任分界を判断しやすくなります。

発注前の確認項目

最終候補には、同じRFPへの回答と同規模の事例を提出してもらいます。さらに、担当者の経験や移行・連携方法を示してもらいます。テスト・教育計画と保守・アップデート範囲も、あわせて提出してもらいます。

価格だけでなく、稼働後に自社で運用できるかを確かめます。問題が起きたときに、誰が判断し、誰が直すかも確認すると、外注の失敗を防げます。

最初の一歩は自社の業務とデータの洗い出し

最初に洗い出す内容は、一枚の一覧にまとめます。

業務と現行環境：現場の課題、使用中のExcelや旧システム
導入範囲：移行データ、必要な連携、利用者数
計画条件：希望時期、予算の考え方

自社だけで進めるのが難しい場合は、製品領域と業種実績を確認した専門会社へ相談します。そのうえで、PoCやRFP作成から段階的に発注します。

標準機能を活かし、独自性が必要な部分だけを拡張すると、費用と将来の保守を両立できます。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
 ・スクラッチシステム開発の完全ガイドブック
 ・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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