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

Dynamics 365 Salesのシステム発注・外注では、ライセンスを購入するだけでなく、営業業務の整理、データ移行、既存システム連携、権限設計、運用定着まで含めて委託範囲を決めることが重要です。

Microsoft製品との親和性に期待して導入を検討していても、RFPの作り方や契約形態、標準機能と追加開発の線引きが曖昧なまま発注すると、見積金額の比較ができず、稼働後に追加費用が発生しやすくなります。この記事では、発注形態の選択から要件整理、契約、費用相場、委託先選定、見積書の読み方までを、Dynamics 365 Salesのシステム開発を外注する担当者向けに解説します。

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

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

Dynamics 365 Salesは、取引先企業、担当者、リード、営業案件、活動履歴を管理し、リード獲得から商談、見積、受注までの営業プロセスを標準化するクラウド型のCRM・SFAです。Microsoft Learnでは、Microsoft Dataverse上で動作し、Power Appsのモデル駆動型アプリ設計を利用する製品と説明されています（出典: Microsoft Learn「Dynamics 365 Salesへようこそ」、2026年8月確認）。そのため、発注対象は画面設定だけではなく、データモデル、Power Platform、Microsoft 365、基幹システムを含む業務システム全体になります。

外注範囲は、企画・現状分析、業務要件定義、ライセンス選定、環境構築、標準機能の設定、カスタムテーブルやフォームの追加、Power Automateによる自動化、API連携、データ移行、テスト、教育、保守に分けて考えます。社内に営業業務を理解する担当者がいる場合でも、Dataverseの設計や移行リハーサル、連携エラーの監視は専門会社に任せる方が安全です。一方、営業ステージや承認条件、入力ルールまで全てをベンダー任せにすると、実際には使われない仕組みになりやすいため、業務側の意思決定は社内に残すことが望ましいです。

Dynamics 365 Salesには営業案件や見積情報を集約し、商品マスター、在庫、会計、請求の正データはERPや既存基幹システムに残す構成が一般的です。Salesに全ての業務を詰め込むのではなく、「顧客・案件・活動はSales」「商品・価格・受注後処理は基幹」といった責任範囲を決めてからRFPに書きます。境界が決まっていれば、連携対象とデータ更新方向が明確になり、二重入力やシステム間で異なる数字が生じるリスクを抑えられます。

Dynamics 365 Salesの発注形態はどれを選ぶとよいですか？

結論として、初めて導入する企業は、業務整理から導入後の定着まで一貫して支援できる会社への一括委託が進めやすいです。ただし、社内にPower Platformの人材がいる場合や、既存のMicrosoftパートナーがいる場合は、要件定義と移行だけを外注し、設定や運用を内製する分割発注も選択肢になります。ユーザー数、連携数、移行データの品質、導入後の運用体制を基準に形態を選びます。

一括委託では、現状分析、Fit to Standard、環境構築、カスタマイズ、データ移行、教育、稼働後支援を一つのプロジェクト計画で管理できます。問題が起きたときに、設定会社、連携会社、ライセンス販売会社の間で責任を押し付け合う事態を避けやすい点がメリットです。特に旧CRMやExcelからの移行を伴う場合は、データクレンジングと移行後の照合まで同じ会社に責任を持たせると、品質基準を統一しやすくなります。

分割発注では、第一段階を業務要件とアーキテクチャの設計、第二段階を環境設定と開発、第三段階を運用保守と分けられます。社内でPower AppsやPower Automateを運用できる企業なら、ベンダーには難易度の高いデータモデル設計やAPI連携だけを依頼し、軽微な画面変更を自社で行う方法もあります。ただし、複数社が関わる場合は、成果物の所有者、テスト責任者、障害の一次窓口、変更管理のルールを契約書に明記します。安さだけで分割すると、後工程で設計不足を埋める追加費用が生じます。

全社一斉導入の前に、10〜30人程度の営業部門を対象に、取引先、リード、営業案件、活動履歴、売上予測の最小構成を試す方法があります。3か月程度の検証期間を置き、入力率、案件ステージの滞留日数、営業会議の準備時間、重複データ率を測定します。PoCの目的はデモ画面を作ることではなく、現場が入力し、管理者が数字を信頼し、経営層が意思決定に使えるかを確認することです。検証結果を本番RFPに反映すれば、想定外のカスタマイズを減らせます。

Dynamics 365 Salesの発注・外注はどのように進めますか？

発注プロセスは、目的とKPIの設定、現状業務とデータの棚卸し、RFP作成、候補会社への説明、提案・見積の比較、契約、要件定義、設定・開発、テスト、教育、稼働後の改善という順番で進めます。最初から製品機能を細かく指定するのではなく、営業上の問題と達成したい状態を定義し、その手段としてDynamics 365 Salesを設計します。提案会社に同じ条件を渡すことで、価格だけではない品質比較ができます。

対象ユーザーを営業担当者だけにするのか、営業管理者、営業企画、営業支援、経営者まで含めるのかで、必要なライセンスと権限が変わります。さらに、案件の登録数を増やしたいのか、失注理由を標準化したいのか、売上予測の精度を高めたいのかを区別します。「入力率を90％以上にする」「営業会議の集計を半日から30分に短縮する」といった測定可能な目標にすると、導入効果と追加開発の優先順位を判断しやすくなります。KPIは導入前の基準値も記録しておきます。

Dynamics 365 Salesは、営業案件、活動、営業プロセス、予測、ダッシュボードなどの標準機能が揃っています。標準機能で対応できる要件をカスタム開発すると、四半期ごとのアップデートや将来のライセンス変更で影響が出やすくなります。標準でできること、Power AppsやPower Automateで補うこと、Azure FunctionsやWeb APIで外部実装すること、業務を見直して不要にすることの四つに分けて判断します。特に、既存Excelの帳票をそのまま画面化するより、意思決定に必要な項目だけを残す方が定着しやすいです。

旧CRMやExcelの顧客データは、会社名の表記揺れ、担当者の重複、退職者の所有案件、古い住所、欠損した必須項目を含んでいることが多いです。移行前に重複判定、名寄せ、保持期間、削除基準を決め、テスト環境への移行、本番前のリハーサル、本番移行後の件数照合を行います。基幹システム連携では、APIの認証、更新頻度、エラー時の再送、タイムアウト、連携停止時の手動運用まで確認します。開発完了を納品条件にせず、利用者受入テストとデータ照合を完了条件に含めることが大切です。

RFPと要件整理では何を明記しますか？

RFPは、ベンダーに価格を聞くだけの資料ではなく、同じ前提で提案してもらうための発注条件です。会社概要や対象部門だけでなく、現行業務、利用ユーザー数、データ件数、連携対象、必要なKPI、希望時期、予算の考え方、保守体制、提案書の提出形式まで書きます。要件が決まっていない項目は未確定のまま隠さず、候補会社から確認質問と前提条件を出してもらう方が、後からの追加請求を抑えやすくなります。

現状業務は、営業担当者がどのタイミングで顧客情報を登録し、誰が案件を承認し、どの帳票をどの会議で使っているかを流れで示します。Excelファイル名やメールの件名だけでなく、入力者、入力項目、利用目的、更新頻度、保管場所、不要になった後の扱いまで整理します。たとえば「案件の確度が担当者によって違う」「失注理由が自由記述で集計できない」「受注後に基幹へ同じ内容を再入力している」という問題は、システム要件とKPIに変換してRFPへ記載します。

RFPには、利用ユーザー数だけでなく、移行対象の取引先・担当者・リード・営業案件の件数、履歴の保持年数、添付ファイルの容量、重複率の見込みを記載します。連携先は、ERP、販売管理、商品マスター、Microsoft 365、Teams、Outlook、SharePoint、Power BI、外部APIに分け、どのシステムが正となるかを定義します。更新を片方向にするのか双方向にするのか、リアルタイムか日次か、連携失敗を誰が検知して復旧するのかも明記します。ここが曖昧だと、同じ「基幹連携」でも会社ごとに見積の工数が大きく変わります。

営業担当者、マネージャー、営業企画、システム管理者、外部委託先で見られるデータを分け、部署、地域、案件所有者などの単位でアクセスを設計します。退職者や異動者のアカウント停止、監査ログの保持、エクスポート権限、個人情報の閲覧範囲も要件に含めます。Copilotを使う場合は、Microsoft Learnの設定手順でも、リージョン間データ移動の同意、必要なコネクタを許可するDLPポリシー、Entraグループによるアクセス制御、監査履歴の確認が前提とされています（出典: Microsoft Learn「Dynamics 365 Salesが搭載するCopilotの有効化と設定」、2026年5月更新）。AI機能は便利さだけでなく、データ処理地域と社内規程を確認してから有効化します。

契約形態は請負・準委任のどちらを選びますか？

契約形態は、成果物と完成条件を明確にできる工程は請負、要件を一緒に検討しながら進める工程は準委任とする組み合わせが現実的です。Dynamics 365 Salesでは、業務要件やデータ移行の難しさが初期に確定しないことがあるため、全工程を一つの固定金額で請負にするより、上流と開発を分けてリスクを管理する方法が向いています。契約の名称だけで判断せず、作業範囲、責任、検収、変更手続き、再委託、保守を具体化します。

準委任契約では、ベンダーが専門家として調査、設計、会議、プロトタイプ作成などの業務を行い、作業時間や体制に対して報酬を支払います。要件が変わりやすい初期フェーズや、現行データの調査には適していますが、何をいつまでに作るかが曖昧にならないよう、週次の成果物と判断事項を定めます。請負契約では、合意した仕様の環境設定、画面、連携、帳票などを納期までに完成させ、検収条件を満たすことを求めます。検収項目には機能だけでなく、移行件数、権限、性能、エラー処理、操作マニュアルも含めます。

プロジェクト中に「この項目も欲しい」「この承認も自動化したい」という要望が出ることは自然です。問題は、追加が口頭で進み、納期と金額だけが後から変わることです。変更依頼には、目的、背景、対象画面、影響する連携、追加工数、費用、納期、テスト範囲、承認者を記録し、ベースラインとの差分を残します。標準機能で解決できる要望を追加開発にしないため、変更ごとに業務効果とアップデートへの影響を確認します。

稼働後の契約では、障害の受付時間、一次切り分け、Microsoftへの問い合わせ、復旧目標、月次レポート、ユーザーからの質問、軽微な設定変更、追加開発の扱いを分けます。保守費用に含まれる作業と、都度見積になる作業を一覧にしておくと、予算管理がしやすくなります。社内で運用を引き継ぐ場合は、管理者向けトレーニング、設定変更の手順書、ソリューションのソースや権限、リリース手順の受け渡しを契約上の成果物にします。

Dynamics 365 Salesの発注・外注費用相場はいくらですか？

Dynamics 365 Salesの費用は、ライセンス、導入支援、設定・追加開発、データ移行、外部連携、教育、保守に分けて見積もります。製品の一律の日本円相場が公開されているわけではなく、ユーザー数や契約地域、為替、割引、販売パートナーで変わります。以下の導入費用は、リサーチノートの業務システム相場とDynamics 365 Salesの一般的な工程を組み合わせた推定レンジであり、確定価格ではありません。ライセンス費用、税、既存基幹の改修費を含まない目安として利用します。

Microsoft公式の米国価格ページでは、年間契約・ユーザー／月の表示として、Sales Professionalが65米ドル、Sales Enterpriseが105米ドル、Sales Premiumが150米ドルと掲載されています（出典: Microsoft「Dynamics 365 Sales pricing」、2026年8月確認）。日本での請求額は地域、為替、税、契約形態、販売パートナー、割引で変わるため、円価格として断定できません。仮に1米ドルを150円として単純換算すると、1ユーザーあたり月額約9,750円、15,750円、22,500円、年額約11.7万円、18.9万円、27万円という参考値になります。

たとえば10人がProfessionalを利用する場合は、上記の仮定で年間約117万円、50人がEnterpriseを利用する場合は年間約945万円、50人がPremiumを利用する場合は年間約1,350万円です。ただし、これはライセンス単価だけの機械的な試算です。Microsoft 365 Copilot、LinkedIn Sales Navigator、Power Platformの追加ライセンス、Dataverse容量、Power BI、Azure、外部APIの利用料などが別途必要になる場合があるため、見積書では「Dynamics 365本体」「追加ライセンス」「容量・従量課金」を分けて確認します。

小規模導入の目安は、10〜30ユーザー、標準機能中心、OutlookやTeams連携、初期データ移行を対象にした300万〜800万円程度です。PoCだけに対象を絞り、画面設定と少量のデータで検証する場合は100万〜300万円台に収まる可能性がありますが、本番の基幹連携や全データ移行を含む金額ではありません。中規模では、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専用の公定価格ではないため、会社の体制や作業難度を含めた比較材料として扱います。

委託先の選定と見積比較では何を見ますか？

委託先は、Microsoft製品を扱えるかだけでなく、営業業務の理解、データ移行の経験、既存CRMやERPとの連携力、権限・監査・DLPの設計力、導入後の保守体制で選びます。候補会社には同じRFPを渡し、提案書、前提条件、対象外、体制、工程、成果物、リスク、費用内訳を同じ様式で提出してもらいます。受賞歴やロゴの多さだけで決めず、自社と似たユーザー数、業界、データ量、連携方式の事例を確認します。

「Dynamics 365の実績」という表現だけでは、SalesなのかCustomer Serviceなのか、設定だけなのか、移行や運用まで含むのかが分かりません。問い合わせ時には、Dynamics 365 Salesのユーザー数、導入期間、利用したプラン、データ移行件数、連携先、Power Platformの拡張範囲、稼働後の支援内容を聞きます。公開事例では、株式会社シーイーシーのMicrosoft Japan Partner of the Year 2025「Dynamics Sales Award」、日立ソリューションズのFit to Standardによるクイックスタート、SBテクノロジーの製造業におけるSalesとPower BIの事例など、得意領域の違いが確認できます。出典は各社公式公開情報で、2026年8月に確認しています。

見積金額が安い会社でも、要件定義、移行リハーサル、受入テスト、マニュアル、教育、稼働後の問い合わせ対応が対象外なら、実際の総額は高くなります。逆に高い提案でも、複数回の移行テスト、業務部門向け研修、データ品質の保証、連携監視、内製化支援が含まれていれば、リスクを下げられる場合があります。比較表には、工程、成果物、工数、単価、前提、対象外、追加単価、納期、支払条件、保守費を横並びにして、同じ条件に補正します。

特に注意したいのは、「一式」「標準連携」「データ移行」「保守込み」という表記です。標準連携がコネクタ設定だけを指すのか、項目マッピングやエラー再送まで含むのかを確認し、移行は何件・何年分・何回のリハーサルかを確認します。最終候補には、提案内容を自社の営業責任者、情報システム、セキュリティ、経理のそれぞれがレビューし、価格・機能・運用・リスクの四軸で評価します。

提案会では、想定する営業担当者の一日をもとに、リード登録、商談化、訪問記録、上司承認、見積連携、受注後の引き渡しを説明してもらいます。製品デモがきれいでも、質問に対して「追加開発です」と答えるだけなら、標準機能を理解しているか判断できません。標準で可能な範囲、設定で対応する範囲、開発する範囲、業務を変える範囲を分けて説明できる会社は、将来の変更にも対応しやすいです。契約前に、実際のプロジェクトマネージャー、設計担当、移行担当、保守窓口が誰かも確認します。

発注後と稼働後にどのような定着支援を行いますか？

システムは稼働しただけでは成果にならず、営業担当者が正しく入力し、管理者がデータを使い、経営者が意思決定に活用して初めて投資効果につながります。発注段階から、操作教育、現場向けの入力ルール、管理者向けの設定研修、問い合わせ窓口、定例レビュー、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機能を有効にする作業だけでなく、権限と運用ルールを含めて見積に入れてもらいます。

まとめ

Dynamics 365 Salesのシステムを発注・外注するときは、ライセンスの安さではなく、営業業務の成果、データの正しさ、既存システムとの境界、権限・AIの安全性、稼働後の定着までを一つの計画にまとめます。発注形態は、一括委託、分割発注、PoCからの段階導入を自社の体制に合わせて選び、RFPにはユーザー数、データ件数、連携対象、KPI、希望時期、保守条件を記載します。

費用は、ライセンス、導入支援、追加開発、移行、教育、保守に分解し、同じ前提で複数社の見積を比較します。標準機能を優先し、必要な拡張だけをPower PlatformやAPIで補い、移行リハーサルと受入テストを省かないことが成功のポイントです。契約後も、入力率、重複データ率、営業会議の時間、売上予測の差などを90日単位で検証し、営業部門と情報システム部門が改善を続けられる体制を整えます。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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