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

Dynamics 365のシステム開発を発注・外注するなら、最初に対象業務と導入範囲を決め、標準機能・追加開発・連携・運用の責任分界をRFPと契約書に落とし込むことが重要です。

Dynamics 365はSalesやCustomer ServiceのCRMだけでなく、FinanceやSupply Chain ManagementなどのERPも含む業務アプリケーション群です。そのため、発注形態の選び方、要件の整理方法、契約形態、費用相場、委託先の比較ポイントを一つずつ整理しないと、見積金額だけでは判断できません。本記事では、2026年時点の公式価格とリサーチノートの市場目安を分けながら、失敗しにくい外注の進め方を解説します。

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

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

Dynamics 365の発注では、製品を買うことと、業務に合わせて使える状態にすることを分けて考えます。ライセンスはMicrosoftから購入しますが、業務ヒアリング、設定、拡張、データ移行、外部システム連携、テスト、教育、稼働後の保守は、Microsoftパートナーや開発会社へ委託することが一般的です。

営業部門が顧客、リード、商談、見積、受注を管理するならDynamics 365 Salesが中心になります。問い合わせやナレッジを扱うならCustomer Service、財務・会計や複数法人管理ならFinance、購買・在庫・倉庫・生産まで扱うならSupply Chain Managementを組み合わせます。中堅・中小企業が販売、購買、在庫、会計をまとめたい場合は、Business Centralが候補になることもあります。

さらに、Salesなどの顧客接点アプリではDataverseをデータ基盤として使い、Power Appsで画面を拡張し、Power Automateで承認や通知を自動化し、Power BIで分析する構成が取れます。FinanceやSupply Chain Managementでは会計・税務・在庫・生産の業務モデル、データ移行、法改正、定期アップデートへの対応が発注範囲に入りやすくなります。

発注前に「Dynamics 365を導入する」という表現を、「営業案件化率を高める」「問い合わせの一次解決率を上げる」「月次決算を早める」「在庫の実績と計画の差を把握する」のような業務成果へ言い換えます。成果指標が決まれば、必要なアプリ、利用ユーザー、移行データ、連携対象、教育対象を絞り込めます。

逆に、目的が曖昧なまま画面や機能の一覧だけをRFPにすると、会社ごとに前提が違う見積が集まります。安い提案に見えても、移行リハーサル、例外処理、教育、アップデート検証が別料金になり、後から追加費用が発生しやすくなります。

Dynamics 365の発注形態はどれを選ぶ？

発注形態は、標準機能を中心に導入するか、独自業務を含めて開発会社に一括委託するか、自社が主導して専門家に伴走してもらうかで大きく分かれます。利用人数や業務範囲だけでなく、自社に業務設計とプロジェクト管理の人材がいるかを基準に選ぶことが大切です。

Salesを10〜30人程度で利用し、営業プロセスを大きく変えずに顧客・案件・活動を一元化する場合は、標準機能と設定を中心にした導入が現実的です。権限、フォーム、ビュー、ダッシュボード、基本的なワークフローを整え、データ移行と少数の連携に範囲を限定します。

この形態は費用と期間を抑えやすい一方、現場が使い慣れたExcelの項目や独自承認をすべて再現できるとは限りません。Fit to Standard、つまり標準機能に業務を合わせる範囲を先に合意し、例外だけを追加開発の候補にします。

複数法人、複数拠点、会計・販売・在庫・生産をまたぐ場合は、Dynamics 365に詳しい開発会社へ要件定義から一括委託する方法が向いています。Fit & Gap、データモデル、連携方式、テスト、教育、切替までを一つの計画にまとめられるため、責任の所在を明確にしやすいことが利点です。

ただし、一括委託でも自社の意思決定を丸投げしてはいけません。業務部門が承認する業務フロー、マスタの正解、残すデータ、変えない業務、稼働判定の基準は発注者が決めます。受託会社の提案を採用する場合も、社内の業務責任者を各領域に置きます。

社内にPMや業務設計の人材がいて、将来の運用を自社に蓄積したい場合は、アセスメント、設計レビュー、難しい拡張、教育だけを外注する形態も選べます。開発会社がすべてを抱えないため、内製化や段階展開につなげやすくなります。

一方で、社内担当者の稼働が確保できないと意思決定が遅れます。会議体、決裁者、レビュー期限、成果物の受け入れ担当を先に決め、月次の経営報告まで含めて体制図に記載します。

RFPと要件整理はどのように進める？

RFPは、開発会社に希望を伝える資料であると同時に、自社の要件を決めるための整理帳です。製品名や画面項目を並べるだけではなく、現状の課題、対象範囲、業務量、データ、連携、品質、運用を同じ粒度で記載すると、複数社の提案を比較しやすくなります。

「営業情報を一元化したい」だけでなく、「案件のステージ定義を統一し、月次の受注見込みを担当者ごとに集計したい」のように書きます。営業なら案件化率、失注理由の記録率、予実差、問い合わせ対応なら一次解決率や平均処理時間、ERPなら締め処理日数や在庫精度などを候補にします。

KPIは発注先に成果を保証させるためだけの数字ではありません。どの機能を優先し、何を初回リリースから外すかを判断する基準です。現状値、目標値、測定方法、測定開始時期まで決めると、稼働後の定着支援も具体的になります。

RFPには、対象アプリをSalesだけにするのか、Customer ServiceやFinanceまで含めるのか、利用ユーザー数と役割、法人・拠点数、月間取引件数、旧システムとExcelの種類を記載します。顧客、商品、担当者、勘定科目、在庫、過去取引など、何件をどの時点まで移行するかも必要です。

連携は、Microsoft 365、Outlook、Teams、基幹システム、会計、EC、倉庫、外部APIなどを洗い出します。リアルタイム連携か日次連携か、エラー時の再送、重複排除、監視担当、認証情報の管理まで書かなければ、後で「連携は含まれていると思っていた」という認識差が起きます。

各要件について、Dynamics 365の標準機能で対応するのか、設定で対応するのか、Power AppsやPower Automateなどで拡張するのか、外部システムに残すのか、個別開発するのかを提案書に分けて記載してもらいます。標準機能から外れるほど、初期費用だけでなくアップデート検証や保守の負担も増えます。

PoCを実施する場合は、見栄えのよい画面だけでなく、権限エラー、重複データ、承認差戻し、API障害、月次締め、移行後の照合といった例外シナリオを試します。PoCの目的、期間、成果物、継続開発へ移行する条件もRFPに明記します。

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

契約は、要件が固まっている部分と、調査しなければ決められない部分を分けて設計します。Dynamics 365では、標準機能で対応できるか、既存データをどこまで移行できるか、連携先のAPI仕様が使えるかによって工数が変わるため、すべてを最初から固定価格にすることが適切とは限りません。

要件定義や設計が完了し、対象範囲と成果物を固定できる部分は請負契約が候補になります。画面、帳票、ワークフロー、連携、移行、テスト仕様書などの成果物、納期、検収方法、瑕疵対応、変更管理を契約書と別紙に記載します。

「システムが使えること」のような曖昧な検収条件は避けます。例えば、指定したテストケースの合格率、重大障害がないこと、移行前後の件数・金額の照合、操作マニュアルの納品、管理者教育の実施など、客観的に判定できる条件へ置き換えます。

現行業務の調査、Fit & Gap、アーキテクチャ検討、プロジェクト管理、運用支援など、作業時間や専門知識の提供を重視する部分は準委任契約が候補です。要件が変化しやすい初期フェーズで無理に成果物を固定せず、月次の作業報告と合意した稼働範囲で管理します。

準委任でも、何をしてもらうかが曖昧でよいわけではありません。担当者の役割、月の稼働上限、会議体、成果物、レビュー期限、再委託の条件、情報管理、終了時の引き継ぎを明記します。作業時間だけでなく、意思決定に必要なアウトプットを定例で確認します。

契約時には、要件変更の単価、追加の人月、追加連携、データ再移行、休日切替、教育回数、出張、AzureやPower Platformの利用料、Copilotクレジット、Microsoftのサポート費を分けます。特に「ライセンス費用」と「導入会社への支援費用」は別の請求主体になり得るため、誰にいつ支払うかを確認します。

保守契約では、問い合わせ窓口、受付時間、初動時間、復旧目標、障害と仕様変更の区分、Microsoftの定期アップデートへの対応、脆弱性対応、データ復旧の役割を確認します。契約終了時に設定情報、ソースコード、設計書、移行定義、管理者アカウントを返却できるかも重要です。

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

Dynamics 365の総額は、Microsoftのライセンス費用と、導入・開発会社へ支払う費用の合計です。後者には要件定義、設定、追加開発、データ移行、外部連携、テスト、教育、切替、保守が含まれます。以下の開発費レンジは、Dynamics 365専用の公式定価ではなく、リサーチノートにある業務システム全般の相場を構成規模へ当てはめた推定です。

Microsoft公式の日本向け価格ページを2026年8月に確認したところ、Dynamics 365 SalesはProfessionalが9,745円、Enterpriseが15,742円、Premiumが22,488円のユーザー／月相当、いずれも年払い・税別の表示です。10ユーザーで単純計算すると、Salesの年間ライセンスは約116.9万円から約269.9万円になります（出典: Microsoft「Dynamics 365 Salesの価格」、2026年8月確認）。

Financeは31,484円、Finance Premiumは44,977円のユーザー／月相当、年払い・税別の表示です。10ユーザーなら年間約377.8万円から約539.7万円の単純計算ですが、実際には権限別ライセンス、追加容量、Power Platform、Azure、Copilotクレジット、契約条件が影響します（出典: Microsoft「Dynamics 365 Financeの価格」、2026年8月確認）。Business Centralのようにパートナーへの問い合わせが必要な製品もあるため、一律価格として扱わないことが安全です。

小規模CRM導入は、Salesを10〜30人で使い、標準設定、権限、簡単な帳票、少数のデータ移行と1〜2本の連携に絞る場合、導入・開発費の推定レンジは300万〜800万円、期間は3〜6か月です。中規模CRM／SFAは、20〜100人、旧CRMの履歴移行、Outlook・Teams連携、複数部門の承認、Power Platform、BI、外部基幹とのAPI連携を含めて、800万〜2,000万円、6〜12か月が目安です。

FinanceやSupply Chain Managementを複数法人・複数拠点で展開する場合は、2,000万〜1億円以上、9〜24か月の推定になることがあります。大規模グループで共通テンプレートを作り、海外拠点へ展開する場合は、1億円超や1〜3年以上の計画も想定します。これらは公式見積ではなく、業務システム全般の人月単価50万〜200万円程度というリサーチノートの目安を含む推定です（出典: NotebookLMリサーチノート「Dynamics 365のシステム」、2026年8月作成）。

保守・運用費は、リサーチノートにある業務システム全般の目安では初期開発費の年15〜25％、または月15万〜80万円程度が参考になります。ただし、Dynamics 365ではMicrosoftのライセンスやサービス料金と、パートナーの問い合わせ、監視、改修、アップデート検証を分けて考えます。製品の規模やSLAによって変わるため、特定金額の断定は避けます。

Microsoftの2026年リリースサイクル1は、2026年4月から9月に提供される機能を対象に、Sales、Finance、Supply Chain Management、Business Centralなどで数百の新機能を案内しています（出典: Microsoft Learn「Dynamics 365 2026年リリースサイクル1の計画」、2026年7月更新）。AIエージェントやCopilotを採用する場合も、利用量、権限、データ品質、回帰テスト、利用者教育を保守計画に含めます。

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

委託先は知名度や見積総額だけで決めません。Sales、Finance、Supply Chain Management、Business Centralのどこを得意とする会社か、同じ業種・規模・利用人数の事例があるか、移行と連携を誰が担当するか、導入後の窓口があるかを確認します。Microsoftのパートナーディレクトリで候補を探し、RFPを同じ条件で渡すと比較の精度が上がります。

CRMの案件なら、営業プロセス、OutlookやTeams連携、重複顧客の統合、活動履歴、権限設計、現場定着まで聞きます。ERPなら、法人・拠点・通貨・税務・原価・在庫・生産、決算、マスタ統合、移行リハーサルまで確認します。同じDynamics 365でも、Salesの経験が豊富な会社とFinanceの経験が豊富な会社では、得意領域が異なります。

公開事例も、委託先の適合性を考える材料になります。Microsoft Customer Stories（2026年4月10日公開）では、デンソー工機部がDynamics 365、Power BI、AIを組み合わせ、約20％の作業工数削減と年間約8万時間の創出を見込んでいます。一方、AGC化学品カンパニーの事例（2026年5月22日公開）では、Dynamics 365 FinanceとSupply Chain Managementを関係会社3社で共通利用し、受発注・生産・在庫・原価管理の標準化を進めています。前者は段階的なAI・業務改善型、後者は複数会社のERP標準化型であり、自社の発注目的に近い事例を優先して確認します。

事例は導入効果の数字だけでなく、導入前の分断や老朽化、標準化した業務、段階展開の順序、連携方式、稼働後の支援内容まで確認します。可能であれば、候補会社から同規模案件のプロジェクト責任者や担当コンサルタントの経歴を提示してもらいます。

見積書は、ライセンス、要件定義、業務設計、環境構築、設定、追加開発、データクレンジング、移行、外部連携、テスト、教育、切替、保守、予備費に分けてもらいます。各項目に、対象範囲、数量、単価、工数、前提条件、除外条件、検収物、追加時の計算方法を付けてもらうと、総額だけの比較を避けられます。

例えば、A社は初期費用が低くてもデータ移行と教育が除外され、B社は高く見えても移行リハーサルや稼働後の伴走が含まれている可能性があります。価格差の理由を「安い・高い」で終わらせず、要件ごとの含む・含まないをRFPの回答表で照合します。

Microsoft Learnは、Dynamics 365のセキュリティ、コンプライアンス、プライバシー、データ保護をMicrosoftと利用企業の共有責任と説明しています。Microsoftがデータセンター、OS、ネットワーク制御、セキュアなアプリケーション基盤を担っても、ユーザー、環境、アプリ、データ権限、連携先の認証、監査ログの確認は利用企業側の設計が必要です（出典: Microsoft Learn「Secure your Dynamics 365 data and apps」、2026年8月確認）。

要件にはMicrosoft Entra ID、最小権限、職務分掌、Dataverseのロール、管理者権限、監査ログ、バックアップ・復旧、開発・検証・本番環境の分離を含めます。Financeを使う場合は、適格請求書、電子取引データ、証憑と仕訳のひも付け、検索性、保存方法を税務担当者と確認します。国税庁は法人の帳簿と取引書類を原則として確定申告書の提出期限翌日から7年間保存する必要があると案内しています（出典: 国税庁「帳簿書類等の保存期間」、令和7年4月1日現在）。

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

発注先が決まった後は、要件定義、設計、開発、テスト、教育、切替のゲートを設定します。各ゲートで承認する成果物と、未解決課題、追加変更、リスク、次の判断者を確認すると、納期直前に問題が集中することを防げます。

データ移行は、抽出、クレンジング、変換、取り込み、照合の手順を複数回試します。顧客や商品だけでなく、過去の活動、残高、在庫、未完了の案件、添付ファイルをどこまで持ち込むかを決め、件数と金額の照合結果を残します。

UATは開発会社のテストではなく、業務部門が実際のシナリオで受け入れる試験です。通常処理だけでなく、承認差戻し、取消、重複、権限不足、連携停止、月次締め、税務帳票、障害復旧を確認します。合格基準を満たさないまま稼働日を迎えないよう、残課題の重大度と対応期限を合意します。

ユーザー教育は操作説明だけでなく、どの情報をいつ入力し、誰が承認し、どのレポートを見るかを業務ルールとして伝えます。現場リーダーを育成し、問い合わせの一次受付、権限申請、マスタ変更、障害連絡、月次の利用状況確認を運用手順にします。

Dynamics 365は継続的に更新されるクラウドサービスです。新機能をすべて有効にするのではなく、リリースノートを確認し、検証環境で影響を調べ、採用・延期・対象外を判断します。発注先に任せる場合も、アップデート前の回帰テストと変更履歴の管理を保守契約へ含めます。

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

ここでは、Dynamics 365のシステム開発を発注するときに多く寄せられる疑問へ、先に結論を回答します。具体的な金額や期間は対象アプリ、ユーザー数、データ、連携、業務の複雑さで変わるため、自社条件をRFPにそろえて確認します。

業務要件、データ移行、外部連携、権限、テストのいずれかに社内だけでは判断しにくい要素があるなら、早い段階で外注先へ相談します。製品選定後の開発だけでなく、アセスメントやRFP作成、PoCから支援を受ける方法もあります。発注を急ぐより、最初に不確実性を減らすことが重要です。

標準機能を優先し、初回リリースの対象業務、移行データ、連携本数、帳票、教育範囲を絞ると、初期費用を抑えやすくなります。ただし、必要なテストやセキュリティを削るのではなく、段階導入で後回しにする範囲を明確にします。複数社へ同じRFPを渡し、作業範囲と除外条件をそろえて比較することも有効です。

成果物と要件を固定できる設定・開発・移行作業は請負、調査や設計レビュー、PM、運用伴走のように内容が変わりやすい作業は準委任が向いています。実際にはフェーズごとに契約を分けることもあります。契約名だけで判断せず、成果物、作業範囲、検収、変更時の費用、責任分界を確認します。

利用目的とデータ品質、権限、利用量を確認したうえで、必要な機能だけを発注範囲に含めます。Microsoftの2026年リリース計画では、SalesのCopilot体験や、Finance・Supply Chain ManagementなどのAI活用が案内されていますが、計画上の機能は提供時期や内容が変わる可能性があります。AIの導入費だけでなく、Copilotクレジット、Azure、評価、監査、教育、回帰テストを見積へ含めます。

まとめ

Dynamics 365のシステムを発注・外注するときは、対象アプリと業務成果を決め、RFPへ利用人数、データ、連携、品質、運用を書きます。そのうえで、標準・設定・拡張・外部化の境界、請負と準委任の使い分け、ライセンスと導入費の分離、見積の除外条件を確認します。

最終候補には、同じRFPへの回答、同規模の事例、担当者の経験、データ移行と連携の方法、テストと教育の計画、保守とアップデートの範囲を提出してもらいます。価格だけでなく、稼働後に自社が運用を続けられるか、問題が起きたときに誰が判断し、誰が直すかまで確認することが、外注の失敗を防ぎます。

まずは、現場が困っている業務、使っているExcelや旧システム、移行したいデータ、必要な連携、利用者数、希望時期、予算の考え方を一枚にまとめます。自社だけで整理しにくい場合は、製品領域と業種実績を確認した専門会社へ相談し、PoCやRFP作成から段階的に発注します。標準機能を活かし、独自性が必要な部分だけを拡張することが、費用と将来の保守を両立しやすい進め方です。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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