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

Microsoft Dataverseのシステム開発は、業務と要件を整理し、契約と委託範囲を決めてから発注します。設計・開発から運用までを一つの流れとして進めると、短期開発の利点を生かせます。

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

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

Microsoft Dataverseのシステム発注・外注の全体像

Dataverseは、Power Apps、Power Automate、Power Pages、Dynamics 365などで使う業務データ基盤です。

テーブルや列に加えて、業務ルールや権限、API連携も設計できます。リレーションや監査まで含めると、設計の範囲はさらに広がります。そのため、発注の対象は単純なデータベース構築に限りません。

Dataverseの開発を外注する理由

社内でPower Appsを試作できても、本番利用には専門的な判断が必要になります。外注先と詰める主な設計は、データと権限、連携と環境の2つです。

• データと権限：顧客・案件のテーブルと部署ごとの閲覧範囲を設計
• 連携と環境：基幹システムとの同期時期と本番への安全な移送を設計

個人が作ったアプリを本番環境で直接変えていくと、作成者の異動や退職の時点で保守できなくなりがちです。そのため、外部会社には作成に加えて、設計書や引き継ぎ資料も求めます。

命名規約やソリューション、テスト記録も含め、成果物の範囲を発注時に決めておきます。

委託範囲の決め方

委託範囲は作業単位で区切り、どの成果物を納めるか、追加費用がどの条件で発生するかをはっきりさせます。

• 上流工程：現状調査と要件定義
• 設計・開発：データモデル、画面、Power Automate、外部API連携
• 導入：データ移行、権限設定、テスト、教育、リリース
• 運用：保守と引き継ぎ

「Dataverseシステム開発一式」とだけ書くと、連携や移行が追加費用になりやすくなります。

外注する範囲は、社内の体制に合わせて分けられます。たとえば、業務部門が画面を確認し、社内ITがユーザーやポリシーを管理する形もあります。

開発会社がデータモデルと連携を担い、残りを社内で進める分担も可能です。完成品を納品してもらうか、伴走型の開発と教育を受けるかは、内製化の方針で選びます。

Dataverseの発注形態の選び方

発注形態は、機能と納期を先に固める請負、専門人材の稼働を確保する準委任、両者を組み合わせるハイブリッド型から選びます。

最初から一つに絞らず、要件の確定度と社内の意思決定の速さに合わせて決めます。

一括請負で委託するケース

要件や画面数、連携先、納品日、受け入れ条件が比較的はっきりしているなら、機能単位で請負に出せます。

• 納品例：申請テーブル、承認フロー、管理者画面、既存システムとの1本のAPI連携
• 完成の定義：機能一覧、テスト項目、性能条件、権限パターン、移行件数を明確化
• 納品物：操作マニュアル、ソース、ソリューションも引き渡す

請負は予算と成果物を管理しやすい反面、契約後に業務ルールを大きく変えると、追加変更として扱われる場合があります。そこで、受け入れテストで確認する事項を先に決めておくと、納品時の認識のずれを減らせます。

準委任で伴走してもらうケース

優先順位を試しながら決める場合や、社内の担当者と専門家が一緒に設計する場合は、準委任が合います。

• 進め方：月ごとの稼働を確保し、短いサイクルで検証する
• 作業：PoC、ワークショップ、データ棚卸し、プロトタイプ評価
• 確認：月次報告、スプリントごとの成果物、未消化タスク、次月の優先順位を合意

短い検証サイクルを回すと、現場の意見を取り込みやすくなります。ただし、準委任は機能の完成や納期を自動的に保証する契約ではないため、稼働に対して何が進んだかを確認していく必要があります。

ハイブリッド型で段階発注するケース

最初は準委任で調査と要件定義を行い、仕様が固まったところで開発を請負に切り替えます。

不確実な部分は小さく検証しながら、確定した範囲については納期と成果物を管理できます。

1. 準委任での現状調査と要件定義
2. 確定した開発範囲の請負への切り替えと、納期・成果物の管理
3. 不確実性の高いデータ移行や外部連携を、アプリ本体と分けた発注
4. 前工程の成果物を後工程の入力として使うルール

要件定義書、テーブル定義、API仕様、権限マトリクス、移行対象一覧は、開発に入る前にそろえておきます。資料が未完成のまま開発へ進まないよう、工程ごとの完了条件を契約書や発注書に記載します。

Dataverseの発注・外注の進め方

発注を急ぐと、画面を作ること自体が目的になり、業務課題やデータの責任範囲が曖昧なまま残ります。そこで、発注前の準備と要件定義を先に固め、各工程に意思決定者を置いて進めます。後半の3工程では、どこまでを誰が受け持つかを工程ごとに決めておきます。

• 設計・開発：データモデル、画面、フロー、連携を作る
• テスト・移行：移行の件数や照合方法の決定と、業務部門による受け入れテスト
• 運用引き継ぎ：保守と引き継ぎの範囲を発注時に決める

発注前の現状と目的の整理

業務の現状、目標、利用者を整理しておくと、各社の提案を比べられます。

• 現状：業務、利用者、処理件数、Excel・SharePointリスト、基幹システム、困りごと
• 目標：入力時間を何分短縮し、承認の滞留を何日減らし、入力漏れをどの程度抑えるか
• 利用者：閲覧、登録・更新、管理者、外部ユーザー別の人数と頻度

顧客情報や個人情報を扱う場合は、保存地域や保持期間を発注条件に含めます。あわせて、監査ログや削除手順、委託先のアクセス方法も条件として整理します。

要件定義で決めるデータ・権限・連携

画面一覧を作る前に、データの意味と権限の考え方を定めておきます。

• データ：顧客、案件、商品、申請、点検結果などの意味と正本
• 項目：必須項目、重複、履歴、添付、参照関係を整理
• 権限：部署、役職、担当範囲、レコード所有者の組み合わせ

ExcelやSharePointの項目は、検索・集計・連携を考えて見直してから移します。

権限の整理では、Microsoft Learnの案内も参考になります。環境ロール、アプリやフローのリソース権限、Dataverseのセキュリティロールを分けて考える構造が示されています（出典: Microsoft Learn「Security and governance considerations in Power Platform」、2026年確認）。

見積を比べる際は、ログイン機能の有無だけでなく、権限パターンごとのテストが含まれるかも見ます。

テスト・移行・リリースの別工程管理

本番で使うには、画面が表示されるだけでなく、テストや移行の条件も満たす必要があります。そのため、受け入れテスト、移行条件、環境分離を、別々の管理項目として扱います。

• テスト：正常・異常、権限別、大量データ、連携停止、二重登録を確認
• フロー：失敗時の再実行、通知先、重複処理、タイムアウトを確認
• 移行：期間、件数、文字コード、添付、重複、欠損、照合方法の決定
• 環境：開発・テスト・本番を分け、ソリューションで移送

受け入れテストは、業務部門が実施します。環境分離は、リリース後の変更管理にもつながります。

環境の使い分けやALMの組み立てについては、Microsoft Learnが目的別の環境利用と、ソリューションや自動化によるALM構築を案内しています（出典: Microsoft Learn「ALM basics with Microsoft Power Platform」、2026年確認）。

Dataverseのシステム発注費用相場とコストの内訳

Dataverseに限った日本の開発費の平均を示す公的統計は確認できていません。そこで、業務システム一般の人月単価や規模別の相場を基にした、発注判断用の推定レンジを示します。

推定では、テーブル数や連携、権限、移行、ALMなどを加味しています。ただし、既存資産や利用者数、データ量、品質、開発体制によって、実際の価格は変わります。

規模別の開発委託費

費用レンジは規模や含める要件によって変わるため、下の規模区分と合わせて見積もります。

• PoC・MVP：1〜3テーブル、入力・一覧・承認、簡易通知で100万〜300万円程度
• 小規模：5〜15テーブル、モデル駆動型またはキャンバスアプリ、権限、監査、基本連携で300万〜800万円程度
• 中規模：複数部門、移行、基幹・API連携、複数環境、ALM、運用設計で800万〜3,000万円程度
• 全社案件：多拠点、多言語、大量データ、複雑なERP・CRM連携、厳格な監査やBCPを含み3,000万円〜1億円超の可能性

これらはリサーチノートに基づく要件別の推定で、市場価格を断定するものではありません。

ライセンスとランニング費用の切り分け

開発委託費とは別に、サービスごと、容量ごと、連携基盤ごとの費用がかかります。

• 対象サービス：Power Apps、Power Automateの実行、Power Pagesの外部ユーザー
• 容量・接続：Dataverse容量、プレミアムコネクタ
• 基盤：Azure Functionsやゲートウェイなど

Microsoftの日本向け価格ページでは、Power Apps Premium通常プランは1ユーザーあたり月額2,998円相当、年払い、税別です。また、2,000シート以上は月額1,799円相当です。

Dataverse Database Capacity add-onは、1GBあたり月額5,997円相当と掲載されています（出典: Microsoft公式「Power Appsのライセンスと価格」、2026年8月確認）。

料金は契約条件や為替、販売経路、税、プラン変更によって変わるため、最新の見積を取得しておきます。

Premiumには一定のDataverse容量が含まれます。ただし、どれだけ使うかはテナントのユーザー数とデータ増加量で変わるため、確認が必要です。データベース、ファイル、ログの追加容量は、別々に試算します。

保守・運用費と初期費用の区分

保守費は、範囲を定めたうえで初期費用とは分けて見積もります。

• 日常対応：問い合わせ、障害調査、ユーザー・権限追加
• 保守作業：Microsoft側の仕様変更対応、フロー監視、バックアップ確認、軽微改修、月次報告
• 内製支援：教育、管理者育成、DLP、環境棚卸し、所有者変更

業務システムでは、初期費用の年間15〜25％を保守費と見る考え方があります。ただし、これはDataverse案件の公的な平均ではないため、対象時間やSLA、件数、改修枠を分けて見積もります。

市民開発に取り組む企業では、社内が一次受付を担い、外部会社が設計レビューや障害対応を担う形も選べます。

RFP・要件整理で決めておくべき項目

RFPは、開発会社へ同じ条件で提案と見積を依頼する資料です。

画面デザインを決めきっていなくても、目的と業務、利用者は揃えておきます。そのほかに、次の条件も揃えます。

• データ：顧客や案件などの意味と正本
• 連携：基幹システムとの連携の方法と同期時期
• 制約：保存地域や保持期間などの条件
• 希望日程・予算：納期の希望と、かけられる予算
• 納品物：操作マニュアル、ソース、ソリューションなど、引き渡す成果物

条件を揃えておくと、開発会社ごとの提案の違いが見えてきます。

RFPに書く業務目的と対象範囲

RFPでは、業務、対象範囲、段階、構成候補をはっきり示します。

• 業務情報：現行手順、月間件数、担当部署、承認者、例外、KPI
• 対象範囲：対象外業務と今回作らない機能も明記
• 段階：MVPと将来拡張を分け、初期予算と拡張性を評価
• 構成候補：モデル駆動型、キャンバス、Power Automate、Power Pages、Dynamics 365連携

方式を一つに固定せず、SharePointリストやAzure SQL、既存ERPを残す案も比べます。

技術・セキュリティ条件の記載漏れ防止

RFPには技術・セキュリティ条件を明記し、必要な管理策もそろえます。

• アクセス・情報：利用地域、Microsoft Entra ID認証、社外利用、個人情報、監査、保持期間
• 継続性・接続：バックアップ、復旧目標、ネットワーク、オンプレミス連携
• Power Pages：匿名・認証ユーザー、公開データ、攻撃対策、ライセンス
• AI・Copilot：データ品質、権限、監査、人の承認、利用費上限

試作を本番に出す前に、機密情報や誤回答の影響、ログ保存、テスト責任者を決めて、段階的に導入します。

成果物と移管条件の明記

納品資料、所有者、保守と契約終了時の引き継ぎは、RFPで条件として示します。

• 設計資料：要件、テーブル・列、画面・フロー、連携仕様、権限表
• 導入資料：テスト結果、移行・運用手順、管理者マニュアル、ソリューション、設定値、教育記録
• 所有権：ライセンスと環境は発注者が所有し、個人アカウントに依存しない
• 保守・終了：問い合わせ、障害重要度、初動、復旧、改修単価、終了時の引き継ぎ

見積の前提と内訳がはっきりしていると、初期見積は安くても、保守や追加改修の費用が高い提案を見分けやすくなります。

委託先選定と見積比較のポイント

委託先は、知名度や単価だけでなく、設計、ガバナンス、連携、移行、保守、内製化支援の力を見て選びます。同じRFPを使い、少なくとも3社程度から同じ粒度の提案を受けると、比べやすくなります。

Dataverseの直接経験という実績の確認

「Power Platformの実績あり」と言われただけでは、判断材料として足りません。Dataverseのどの範囲を担当したのかを、具体的に聞きます。

• データとアプリ：テーブル設計、モデル駆動型・キャンバスアプリ
• 連携と移行：Power Automate、Web API、データ移行、Dynamics 365連携
• 運用設計：環境分離、監査、ガバナンス、内製化支援

同業界や同規模の事例では、課題、期間、体制、運用開始後の支援も確認します。

内製化を重視するなら、完成品を納めるだけでなく、社内の管理者を育てる力も見ます。

Microsoftのスズキ事例では、2025年1月公開時点で、約18,000名分のPower Apps Premium購入と全社展開が紹介されています（出典: Microsoft Customer Stories「スズキが約18,000名分のPower Apps Premiumを購入」、2025年）。大規模に展開する場合は、アプリを作る力に加えて、ガバナンスと教育の経験が欠かせません。

さらに、SCSKの商工中金事例では、2026年1月末までの半年で社内開発者が約4倍になり、市民開発アプリが1,800超に増えたと説明されています（出典: SCSK「商工中金様 Power Platform活用事例」、2026年）。この規模になると、個別のアプリだけでなく、教育や審査、環境管理、利用状況の監視も委託範囲に入れます。

見積書の作業項目と前提条件による比較

見積書は、作業項目と工数、単価を中心に、役割や期間、前提、対象外も分けて出してもらいます。

• 開発工程：要件定義、データモデル、アプリ画面、フロー、連携、移行
• 品質と導入：権限、テスト、教育、リリース
• 運用：保守とその対象範囲

「開発一式」「調整一式」の内訳が分からない場合は、その中身を質問します。

価格差には画面数のほかに、移行のクレンジングや異常系テストが影響します。権限、環境、文書の扱いも費用を左右し、管理と保守も価格に響きます。

見積では、必要な項目が抜けていないか、過剰な機能が入っていないかを比べ、値引きだけで決めないようにします。

提案会で確かめる設計の考え方

提案会では、設計判断の理由と担当体制を具体的に聞いておきます。

• 設計理由：Dataverse、SharePoint、Azure SQLの使い分けと大量データ時の構成
• 実装判断：標準・独自テーブル、アプリ形式、連携失敗時の復旧
• 担当体制：役割、交代時の引き継ぎ、仕様変更、障害時の連絡先

PM、アーキテクト、開発者、連携担当、テスト担当がそろっているかを確かめると、契約後のリスクを抑えられます。

契約形態と発注時の失敗を防ぐ方法

技術仕様だけでなく、契約上の責任分界も決めておく必要があります。そのうえで、法務・購買部門と条件を確認します。

• 契約・成果：請負、準委任、検収、変更管理、知的財産権
• 情報管理：再委託、秘密情報、個人情報、アカウント管理
• 運用対応：障害対応と責任分界

請負契約の変更管理

仕様変更が追加費用や納期延長につながる条件は、あらかじめ決めておきます。あわせて、変更票、影響範囲の算定、承認者、緊急変更、軽微改修の上限を定めます。

口頭依頼が無制限に増えるのを防ぐため、検収の条件にはテスト結果と未解決課題の扱いも明記します。

準委任契約での成果の見える化

稼働時間だけでは成果を判断しにくいため、週次の進捗や決定・未決事項を記録しておきます。設計・設定や次の検証項目も残し、スプリントの終わりにアプリや文書を確認します。

社内レビューが遅れて納期に影響した場合も、どこまでが誰の責任かを記録しておきます。

属人化と環境の混在を防ぐ管理

設定や接続情報、環境は、発注者側で管理できる状態にしておきます。

• 環境：開発・テスト・本番を分け、既定環境への直接変更を避ける
• 所有と権限：発注者が管理者権限と請求情報を持つ
• 接続情報：個人所有を避け、サービスアカウントや運用ルールで管理

担当者だけが知る設定や個人所有の接続は、異動後に引き継げなくなるおそれがあります。

環境の考え方については、Microsoft Learnが環境戦略、ソリューション、継続展開、ガバナンスの組み合わせを案内しています（出典: Microsoft Learn「Organize your solutions in Power Platform」、2025年更新・2026年確認）。

環境の作成と廃止、アプリの所有者、DLP、監査、リリース承認は、発注時から設計しておきます。こうすると、アプリが乱立するのを抑えられます。

よくある質問（FAQ）

提案を依頼する前によく寄せられる、費用、期間、内製化の線引きについての疑問を取り上げます。

Dataverseのシステム開発を外注するといくらかかりますか？

費用は開発規模や含める要件で変わるため、まずは規模別の推定レンジを確認します。

• 小規模PoC：100万〜300万円程度
• 小規模業務アプリ：300万〜800万円程度
• 中規模：800万〜3,000万円程度（いずれも要件別の推定レンジ）
• 連携・移行・監査・環境分離・全社展開を含む場合：3,000万円〜1億円超の可能性
• 提案依頼時：開発委託費、ライセンス、追加容量、保守費を分けて考える

Dataverseの開発期間はどのくらいですか？

1〜3テーブルのPoCは1〜2か月、権限と基本連携を含む小規模アプリは2〜4か月です。中規模システムは3〜9か月程度が目安で、要件の複雑さや社内レビューの速さで変わります。

移行や接続試験、受け入れテストを含めた期間は、画面開発だけの場合より長くなります。

Dataverseの開発は内製と外注のどちらがよいですか？

データ構造と権限が単純な小規模の部門アプリなら、社内で試作しやすい領域です。一方、複数部門の共通データや個人情報を扱う場合は、専門会社の支援を受けるほうが安全です。次のような場合も、専門会社の支援が役立ちます。

• 基幹連携：基幹システムとの同期や連携
• 大量移行：件数が多いデータの移行と照合
• 監査：監査ログや削除手順の整備
• 複数環境のALM：開発・テスト・本番をまたぐ変更の管理

内製か外注かの二択にせず、社内が業務判断と受け入れを担い、外部会社が設計レビューや難しい連携を担う方法もあります。

発注先を選ぶときに最も重要な確認事項は何ですか？

委託先の判断では、まずDataverseの実績とデータモデルの設計を確かめます。あわせて、次の4点も見ておきます。

• 権限：部署、役職、担当範囲、レコード所有者の組み合わせ
• 既存連携：基幹システムなど既存の仕組みとの連携
• 移行・テスト：データ移行の条件と、業務部門による受け入れテスト
• 運用・内製化支援：保守と引き継ぎ、社内の管理者を育てる支援

そのうえで、担当予定者の工程経験や、障害・仕様変更への対応を質問します。会社名や資格は、参考材料として扱います。

まとめ

業務課題とKPIを整理し、利用者やテーブル、データ量をRFPにまとめます。ほかに次の項目も含めます。

• 連携先：接続する既存システムや外部サービス
• 権限：部署、役職、担当範囲ごとの閲覧・更新の範囲
• 監査：監査ログや削除手順の記録
• 環境：開発・テスト・本番を分けた運用
• 保守：対象時間やSLAを含めた保守の範囲

仕様が確定している部分は請負、検証が必要な部分は準委任か段階発注にします。

費用と見積の確認

規模別のレンジを基に、委託費とライセンスを分けて比べます。そのほかの費用は、容量から保守まで5つに分けて見ると、見積の差が見えてきます。

• 容量：Dataverseの追加容量にかかる費用
• 連携基盤：Azure Functionsやゲートウェイなどの費用
• 移行：データ移行の作業にかかる費用
• 教育：社内向けの教育と管理者育成
• 保守：範囲を定めたうえで、初期費用とは分けた保守費

見積では、価格だけでなく、テスト、文書、環境分離、引き継ぎ、障害対応が含まれているかも確認します。

最初の一歩は小さな業務での検証

最初から全社展開を契約せず、効果を測りやすい小さな業務でPoCを行います。

1. 申請、点検、営業活動など、効果を測りやすい業務でのPoC
2. 入力率、処理時間、エラー率、利用率の確認
3. 次の発注での、データモデルと運用ルールの活用

Dataverseは、短期開発の道具で終わらせず、継続的に改善できる業務基盤として育てられます。

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

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