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

Dynamics 365 Salesの発注は、業務の成果と委託範囲を決め、RFPで条件をそろえるところから始まります。移行、検証、定着と進めると、営業業務の標準化につながります。

発注形態から稼働後の支援まで、各段階で押さえる要点を順に記します。全体像は完全ガイドもご覧ください。

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

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

Dynamics 365 Salesのシステムを発注・外注する前に知る全体像

Dynamics 365 Salesは、取引先企業や担当者、リードといった情報を管理します。営業案件や活動履歴も扱い、リード獲得から商談、見積、受注までの営業プロセスを標準化する、クラウド型のCRM・SFAです。

Dynamics 365 SalesはMicrosoft Dataverse上で動作し、Power Appsのモデル駆動型アプリ設計を利用します。Microsoft Learnの「Dynamics 365 Salesへようこそ」では、そのように説明されています（2026年8月確認）。

そのため、発注する範囲は画面設定にとどめません。データモデルに加え、Power Platform、Microsoft 365、基幹システムまで含めて考えます。

外注範囲と社内で持つ範囲の決定

外注範囲は、工程ごとに分けて考えます。上流の企画・現状分析や業務要件定義から、ライセンス選定、環境構築、標準機能の設定、追加開発までを候補にします。

• 専門会社に委託：Dataverse設計、移行リハーサル、連携エラー監視
• 社内で決定：営業ステージ、承認条件、入力ルール
• 追加開発：カスタムテーブルやフォームの追加
• 委託範囲に含める：Power Automate、API連携、データ移行、テスト
• 稼働後の支援：教育、保守

社内に営業業務に詳しい担当者がいても、Dataverseの設計や移行リハーサル、連携エラーの監視は専門会社に任せるほうが安全です。

一方で、営業ステージや承認条件、入力ルールまでベンダー任せにすると、実際には使われない仕組みになりやすくなります。そのため、業務側の意思決定は社内に残します。

Salesと基幹システムの境界の合意

営業案件や見積情報はSalesに集め、商品マスター、在庫、会計、請求の正データはERPや既存の基幹に残す構成が一般的です。

「顧客・案件・活動はSales」「商品・価格・受注後処理は基幹」のように責任範囲を決めて、RFPに記載します。こうすると、連携対象と更新方向が明確になり、二重入力や数字の不一致を抑えられます。

Dynamics 365 Salesの発注形態の選び方

初めて導入する企業には、業務整理から定着まで一貫して支援できる会社への一括委託が適しています。一方、社内にPower Platform人材や既存のMicrosoftパートナーがいる場合は、分割発注も選べます。

発注形態は、ユーザー数、連携数、移行データの品質、導入後の運用体制をもとに選びます。

一括委託による責任分界のシンプル化

一括委託では、現状分析から教育、稼働後の支援までを一つの計画で管理します。そのなかには、Fit to Standardや環境構築、カスタマイズ、データ移行も含まれます。

一括委託にすると、問題が起きたときも、設定会社や連携会社、ライセンス販売会社が責任を押し付け合う事態を避けられます。

旧CRMやExcelから移行する場合は、データクレンジングから移行後の照合まで同じ会社に任せると、品質基準をそろえやすくなります。

分割発注による内製化と費用管理

分割発注では、第一段階を業務要件と設計、第二段階を環境設定と開発、第三段階を運用保守に分けられます。

Power AppsやPower Automateを社内で運用できる場合は、難しいデータモデル設計やAPI連携だけを委託し、軽微な画面変更は内製できます。

複数社が関わる場合は、成果物の所有者、テスト責任者、障害の一次窓口、変更管理を契約書に明記します。安さだけで分割すると、後工程で設計不足を補う追加費用が生じます。

PoCやMVPによる段階導入

全社導入の前に、営業部門の10〜30人程度で最小構成を試す方法があります。試す対象は、取引先、リード、案件、活動履歴、売上予測です。

検証期間は3か月程度とし、入力率、案件ステージの滞留日数、営業会議の準備時間、重複データ率を測ります。

PoCでは、現場の入力、管理者がデータを信頼できるか、経営層が意思決定に使えるかを確かめます。その結果を本番RFPに反映すると、想定外のカスタマイズを減らせます。

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

発注は、目的とKPIを決め、現状業務とデータを洗い出してRFPを作成するところから始まります。候補会社への説明を経て、提案と見積を比べ、契約に進みます。その後、要件定義、設定と開発、テスト、教育を行い、稼働後の改善に移ります。

まず、営業上の課題と達成したい状態を定義し、製品機能を先に細かく決めすぎないようにします。こうして定めた条件を同じ形で提案会社に渡すと、価格以外の品質も比べられます。

企画段階での対象ユーザーと業務上の成果

対象を営業担当者だけにするか、管理者、営業企画、営業支援、経営者まで含めるかで、必要なライセンスと権限が変わります。

案件登録数の増加、失注理由の標準化、売上予測の精度向上などの目標は、それぞれ区別して考えます。

「入力率を90％以上にする」「営業会議の集計を半日から30分に短縮する」といった測定可能なKPIを決め、導入前の基準値も記録しておきます。

要件定義と設計での標準機能の優先

Dynamics 365 Salesには、営業案件や活動、営業プロセス、予測、ダッシュボードといった標準機能があります。

標準で対応できる要件まで開発すると、四半期ごとの更新や将来のライセンス変更の影響を受けやすくなります。

• 標準機能：製品の機能での対応
• Power Platform：Power AppsやPower Automateでの補完
• 外部実装：Azure FunctionsやWeb APIによる実装
• 業務見直し：不要な要件の削除

既存Excelの帳票をそのまま画面化するより、意思決定に必要な項目だけを残すほうが定着しやすくなります。

開発と同じ重さで扱う移行・連携・テスト

旧CRMやExcelには、会社名の表記揺れや担当者の重複、退職者の案件が含まれることがあります。さらに、古い住所や必須項目の欠損が見られることもあります。

移行前には、重複判定や名寄せ、保持期間、削除基準を決めておきます。そのうえで、テスト環境への移行、本番前のリハーサル、本番後の件数照合を行います。

基幹連携では、API認証や更新頻度、エラー再送、タイムアウト、停止時の手動運用を確認します。さらに、利用者受入テストとデータ照合を、納品の完了条件に含めます。

RFPと要件整理で明記する項目

RFPは、ベンダーに同じ前提で提案してもらうための発注条件です。会社概要や対象部門、現行業務に加えて、ユーザー数やデータ件数、連携先、KPIを記載します。さらに、希望時期や予算の考え方、保守体制、提出形式も示します。

未確定の要件は隠さずに示し、候補会社から確認質問と前提条件を出してもらうと、後からの追加請求を抑えられます。

現状業務と困りごとの業務フロー

営業担当者が顧客情報を登録する時点、案件の承認者、帳票を使う会議を、業務の流れに沿って示します。

Excelの名前やメールの件名だけでなく、入力者、項目、利用目的、更新頻度、保管場所、不要になったあとの扱いまで整理します。

確度の判断が担当者ごとに違う、失注理由を集計できない、受注後に基幹へ再入力するといった課題を、要件とKPIに変えてRFPに記載します。

データ量と連携の前提の数値化

ユーザー数に加えて、移行対象の件数を記載します。取引先、担当者、リード、案件の件数のほか、履歴の保持年数、添付ファイル容量、重複率の見込みも含めます。

連携先は、ERPや販売管理、商品マスターに加え、Microsoft 365（Teams、Outlook、SharePoint）、Power BI、外部APIに分けます。各連携先で正データを決めます。

更新方向や、リアルタイムか日次かといった点、失敗時の検知と復旧担当も明記します。「基幹連携」の前提が曖昧なままだと、見積工数が会社ごとに変わってしまいます。

権限・監査・AI利用の条件

権限・監査・AI利用では、アクセス範囲、アカウント管理、Copilotの条件を整理します。

• アクセス範囲：担当者、マネージャー、企画、管理者、外部委託先ごとの設定
• 権限設計：部署、地域、案件所有者などの単位でのアクセス設計
• アカウント・監査：退職・異動者の停止、ログ保持、出力権限、個人情報の扱い
• AI利用：Copilotの利用可否と社内規程の照合

Copilotでは、リージョン間のデータ移動への同意、コネクタを許可するDLPポリシー、Entraグループ制御、監査履歴の確認が前提です。

この情報の出典は、2026年5月更新のMicrosoft Learn「Dynamics 365 Salesが搭載するCopilotの有効化と設定」です。

契約形態の選び方（請負と準委任）

成果物と完成条件を明確にできる工程は請負、要件を検討しながら進める工程は準委任とする組み合わせが現実的です。

要件や移行の難しさは、初期の段階では確定しないことがあります。そのため、全工程を固定金額の請負とせず、上流と開発を分けてリスクを管理します。

契約名に加えて、作業範囲や責任、検収、変更手続きを具体化します。さらに、再委託と保守も明確にします。

要件定義は準委任、確定した開発は請負

準委任では、調査や設計、会議、試作などの業務や体制に対して報酬を支払います。要件が変わりやすい初期段階や、現行データの調査に適しています。

作業が曖昧にならないよう、週ごとの成果物と判断事項を定めておきます。一方、請負では、合意した仕様どおりに、環境や画面、連携、帳票を納期までに完成させます。

検収条件には、機能に加えて、移行件数や権限、性能、エラー処理、操作マニュアルも含めます。

追加要件の変更管理

プロジェクトの途中で、項目や承認の追加要望が出ることはあります。口頭での追加によって、納期や金額だけが後から変わることのないよう、変更管理を行います。

変更依頼では、目的や背景に加えて、画面や連携への影響、工数、費用、納期、テスト範囲、承認者を記録します。さらに、基準との差分を残します。

標準機能で解決できる要望を開発にしないよう、業務効果とアップデートへの影響も確かめます。

保守契約での障害対応と改善支援の区分

保守契約では、障害の受付時間や一次切り分け、Microsoftへの問い合わせを定めます。さらに、復旧目標や月次報告、質問対応、軽微な設定、追加開発の扱いも分けて決めます。

保守費に含む作業と都度見積の作業を一覧にすると、予算を管理しやすくなります。内製化する場合は、管理者研修や手順書、ソリューションのソースや権限、リリース手順も成果物に含めます。

Dynamics 365 Salesの発注・外注費用の相場

費用は、ライセンス、導入支援、設定・開発、移行、連携に分けて見積もります。教育や保守も、別に見ておきます。なお、製品の一律の日本円相場は公開されていません。

金額は、ユーザー数や契約地域、為替、割引、販売パートナーによって変わります。後で示す導入費は、業務システム相場と一般的な工程をもとにした推定です。ここに示すのは目安で、ライセンス費や税、既存基幹の改修費は含みません。

プランと追加サービスごとのライセンス費用

Salesライセンスは、プランごとに価格が異なります。そのため、米国での年間契約価格を比べます（出典: Microsoft「Dynamics 365 Sales pricing」、2026年8月確認）。

• Sales Professional：1ユーザー月額65米ドル
• Sales Enterprise：1ユーザー月額105米ドル
• Sales Premium：1ユーザー月額150米ドル

日本での請求額は、地域や為替、税、契約形態、販売パートナー、割引によって変わります。そのため、円価格とは断定できません。

1米ドル150円で単純に換算すると、月額は1ユーザーあたり約9,750円、15,750円、22,500円です。年額にすると、約11.7万円、18.9万円、27万円となります。

この仮定では、Professionalを10人が使うと年間約117万円です。同じ仮定でEnterpriseを50人なら約945万円、Premiumを50人なら約1,350万円になります。

これはライセンス単価だけの試算で、次に挙げる追加費用は別途かかる場合があります。

• 追加ライセンス：Microsoft 365 Copilot、LinkedIn Sales Navigator、Power Platform
• 容量・分析：Dataverse容量、Power BI
• クラウド・連携：Azure、外部APIの利用料

見積書では、「Dynamics 365本体」「追加ライセンス」「容量・従量課金」を分けて確認します。

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

PoCだけに絞り、画面設定と少量のデータで検証する場合は、100万〜300万円台となる可能性があります。ただし、この額には本番の基幹連携や全データ移行は含まれません。

規模別の導入費用は、次の推定レンジです。

• 小規模：10〜30ユーザー、標準機能中心、Outlook・Teams連携、初期移行で300万〜800万円程度
• 中規模：30〜150ユーザー、複数部門、商品マスター連携、Power BI、権限設計で800万〜2,500万円程度
• 大規模：150ユーザー超。旧CRM、国内外拠点、ERP・複数API、複雑な承認・監査・定着化。2,000万〜5,000万円超

全社CRMの刷新や複数システムの同時再構築では、さらに大きな予算になる可能性があります。なお、これらは一律の価格ではなく、業務システム相場からの推定です。

見積比較では、金額だけでなく、要件定義や移行、テスト、教育が含まれる範囲も確認します。

工程別に分解した金額の妥当性

見積書では、費用を次の工程別に分けます。

• 準備・設計：ライセンス、現状分析、要件定義、環境・権限設定
• 構築・移行：カスタマイズ、連携、データクレンジング・移行
• 検証・運用：テスト、教育、プロジェクト管理、稼働後保守

一般的な開発会社の人月単価は、中小規模会社で80万〜120万円、大手SIerで150万〜200万円と整理されています。

保守運用は初期開発費の年15〜25％程度です（出典: NotebookLM Q&A「業務システム全般_17」、2026年8月確認）。ただし、これはDynamics 365 Sales専用の公定価格ではなく、比較のための材料です。

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

営業業務への理解や移行経験、CRM・ERP連携の実績を見て、委託先を選びます。さらに、権限・監査・DLP設計や稼働後の保守体制も確かめます。

候補会社には同じRFPを渡し、提案の内容と前提、対象外、体制を同じ様式で出してもらいます。さらに、工程や成果物、リスク、費用内訳も同じ形式でそろえます。

判断では、自社に近いユーザー数、業界、データ量、連携方式の事例を確認します。受賞歴やロゴの多さは、それだけで決める材料にはしません。

実績の担当範囲の確認

「Dynamics 365の実績」を比べるときは、製品、担当範囲、規模、導入後支援をそろえて確認します。

• 製品と担当範囲：SalesかCustomer Serviceか、設定・移行・運用のうち担当した範囲
• 導入条件：ユーザー数、期間、利用プラン、データ移行件数
• 技術・支援：連携先、Power Platformの拡張範囲、稼働後の支援内容
• 株式会社シーイーシー：Microsoft Japan Partner of the Year 2025「Dynamics Sales Award」
• 日立ソリューションズ：Fit to Standardによるクイックスタート事例

SBテクノロジーには製造業のSales・Power BI事例があります。なお、各社の公式公開情報は2026年8月に確認しています。

見積比較の前提条件と抜け漏れ

金額だけでなく、対象工程の不足と支援内容の有無を同じ条件で比べます。

• 安い見積：要件定義、移行リハーサル、受入テスト、教育、稼働後対応が対象外なら総額が上がる
• 高い提案：移行テスト、研修、品質保証、連携監視、内製化支援でリスクを下げる場合がある
• 比較条件：工程、成果物、工数、単価、前提、対象外、追加単価、納期、支払条件、保守費の統一

見積書にある「一式」「標準連携」「データ移行」「保守込み」は、それぞれどこまでを指すのか確認します。連携はコネクタ設定だけか、項目対応やエラー再送まで含むのかを尋ねます。

移行対象の件数や年数、リハーサル回数も確認します。また、営業責任者や情報システム、セキュリティ、経理が、価格・機能・運用・リスクの四つの軸で評価します。

提案会での質問への答え方と担当者

営業担当者の一日を例に、流れを説明してもらいます。リード登録から商談化、訪問記録、上司承認、見積連携、受注後の引き渡しまでが対象です。

「追加開発です」と答える会社では、標準機能をどこまで理解しているかを判断しにくくなります。一方、標準、設定、開発、業務変更の範囲を説明できる会社は、将来の変更にも対応しやすいです。

契約前には、実際のプロジェクトマネージャーや設計担当、移行担当、保守窓口も確認します。

発注後と稼働後の定着支援

稼働後は、営業担当者が入力し、管理者がデータを使い、経営者が意思決定に生かすことで、投資効果につながります。

発注時の段階から、操作教育や現場の入力ルール、管理者研修を計画します。あわせて、問い合わせ窓口や定例レビュー、KPI測定も決めておきます。

稼働直後は、入力方法についての質問が増えます。そのため、ベンダーと伴走する期間を設けておくと、運用でのつまずきを早く解消できます。

90日後のKPIによる導入効果の検証

稼働後30日では、ログイン率、必須項目の入力率、重複データ数、問い合わせ件数を確認します。60日では、案件滞留や失注理由の登録率、会議でのダッシュボード利用を見ます。

90日では、会議準備時間、売上予測と実績の差、案件化率、受注率、担当者ごとの入力品質を導入前と比べます。

数値が振るわないときも、機能不足と決めつけず、入力項目、権限、上司のデータ利用、古いマスターなどの原因を切り分けます。

定例会での保守と改善の優先順位の更新

定例会では、障害や問い合わせ、設定変更、追加開発、ライセンス変更、Microsoftの更新が、どう影響するかを整理します。

要望はすべて開発せず、利用率やKPIへの影響が大きいものから改善します。また、Copilotや営業アクセラレータは、権限、監査、データ処理、DLP、教育を確認して段階的に導入します。

ベンダーと社内管理者が同じバックログを見て次の四半期の改善を決めると、稼働後の形骸化を防げます。

よくある質問（FAQ）

発注時には、ライセンス価格以外にも確認したい論点があります。よく寄せられる質問を、いくつか挙げておきます。

Dynamics 365 Salesの導入は何か月くらいかかりますか？

標準機能中心で10〜30ユーザーなら、要件整理から稼働まで2〜4か月程度が目安です。

複数部門や旧CRMの移行、基幹連携、複雑な権限・承認を含む場合は、4〜9か月程度です。大規模な全社展開では、6〜12か月以上になる可能性があります。

期間は、社内の意思決定やデータ整理、受入テストに割ける時間によっても変わります。

ライセンスを買えば自社だけで導入できますか？

標準機能を小規模に使う程度であれば、自社で環境設定やユーザー追加を行える場合があります。

一方、業務の標準化や移行、基幹連携を含む場合は、専門会社に相談するのが安全です。そのほか、次の項目を含む場合も、相談の対象になります。

• 権限・監査
• CopilotのDLPやデータ移動の条件
• 教育

社内に担当者がいる場合は、設計レビューや移行リハーサルだけを外注して、運用を内製化することもできます。

見積を比較するときに最初に見る項目は何ですか？

まず、対象範囲や前提、対象外を確認します。続けて、成果物や移行回数、連携方式、受入テスト、教育、保守を見ます。

その後、ライセンス、導入支援、開発の費用を分けて比べます。残りの費用も、次の項目ごとに分けて確認します。

• 移行
• 教育
• 保守

「一式」と書かれた見積が安く見えても、工程が抜けていれば追加費用が発生します。そのため、同じRFPの回答を工程別にそろえます。

Copilotを使う場合に発注先へ何を確認すべきですか？

まず、対象ユーザーや参照するテーブル、SharePointフォルダーを確認します。そのうえで、監査履歴や処理地域、リージョン間移動への同意、DLP、Entraグループも確かめます。

また、Microsoft 365 Copilotなどの追加ライセンスが必要かどうかも確認します。閲覧権限を整理し、誤回答を業務判断に使わないよう、教育と確認手順を設けます。

AI機能の有効化に加えて、権限と運用ルールも見積もりに含めてもらいます。

まとめ

発注前に決めることの整理

ライセンスの安さだけでなく、営業業務の成果やデータの正確さ、基幹との境界、権限・AIの安全性、稼働後の定着を計画に入れます。

一括委託、分割発注、PoCからの段階導入のなかから、自社の体制に合うものを選びます。そのうえで、RFPにはユーザー数やデータ件数、連携先、KPI、時期、保守条件を記載します。

見積と定着までの一つの基準での比較

費用をライセンス、導入支援、開発、移行、教育、保守に分け、同じ前提で見積もりを比べます。さらに、標準機能を優先し、必要な拡張はPower PlatformやAPIで補います。

移行リハーサルと受入テストを行ったうえで、入力率、重複データ率、会議時間、売上予測の差を90日単位で検証します。営業部門と情報システム部門が、改善を続ける体制を整えます。

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

▼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を創業。