Dynamics 365 UAT：実践ガイド

Dynamics 365 で UAT が必要なとき

ユーザー受け入れテストが答える問いは 1 つです。このバージョンの Dynamics 365 で、業務部門は仕事ができるか？ 本番環境に届く前に、実際にその仕事をする人が、自分の言葉でテストします。UAT が必要なのは次のタイミングです。

• 本番稼働。初めての Dynamics 365 Sales や Customer Service、または他の CRM からの移行。
• 新しいアプリやモジュール。Sales に加えて Customer Service を導入する、チーム向けの新しいモデル駆動型アプリ、顧客ポータル、有効にする Copilot 機能など。
• 大きな変更。ERP との新しい連携や、ケースの新しい振り分け方法など。
• Microsoft からのアップデート。Microsoft は、Dynamics 365 の変更を年 2 回のリリースウェーブにまとめることをやめました。新機能や変更は年間を通じて順次提供されます。リリース計画は 2026 年 10 月にアーカイブされ、今後の予定は Microsoft のロードマップ aka.ms/AIatWorkRoadmap に掲載されています。自分では何も変更していなくても、どのアップデートでもシステムの動作が変わる可能性があります。

本番稼働には完全な UAT が必要です。アップデートには、最も重要なプロセスに絞った短い回帰テストを、決まったリズムで行う必要があります。詳しくは本番稼働後をご覧ください。

環境

本番環境では決してテストしないでください。Power Platform 管理センターでは、すべての環境に種類があります。UAT にはサンドボックスを使います。

本番環境のコピー

実際の状況に最も近いのは、サンドボックス環境にある本番環境のコピーです。環境をコピーするときは、何をコピーするかを選びます。

• すべて：カスタマイズ、スキーマ、すべてのデータ。本番環境に最も近い一方で、実際の顧客データと、ユーザーが作成したすべてのレコードが含まれます。
• カスタマイズとスキーマのみ：データを含まない構成のみ。テストデータは後から自分で読み込みます。

コピーすると、コピー先の環境の内容は置き換えられます。そのため、コピーは UAT の前に行い、UAT 中には決して行わないでください。コピー後は、連携と Power Automate フローの接続先を本番環境ではなくテストシステムに変更し、メールボックスを確認し、準備ができたら環境の管理モードを解除します。

ソリューションとビルド

プロジェクトの変更は、ソリューションとして UAT 環境に届きます。パイプラインがあればそれを使い、マネージド ソリューションとしてインポートします。そうすれば、UAT 環境には、後で本番環境が受け取るものとまったく同じものが入ります。

• テスト中にソリューションをいつインポートするかを合意しておきます。たとえば、毎日トリアージの後に 1 回などです。テストの途中でインポートすると、テスターが見ている画面が変わってしまうことがあります。
• UAT 環境に入っているソリューションとバージョンを記録します。ソリューションのバージョン番号がテスト対象のビルドであり、すべての課題と再テストはいずれかのビルドに属します。

テストデータ

データの準備ができていないと、テスターは何時間も無駄にします。最初のテスト日の前に準備してください。

• テストする顧客の種類ごとに、適切な所有者と部署を持つ取引先企業と取引先担当者。
• 製品と価格表。製品を正しい価格で追加するには価格表品目が必要で、営業担当者が使えるようにするには製品を公開する必要があります。各営業チームの価格表があることを確認してください。
• Customer Service 向けのキュー、SLA、ナレッジ記事：ケースの振り分け先となるキュー、有効な SLA、検索対象となる公開済みの記事。
• 作業に使う未完了のレコード：リード、さまざまなステージの営業案件、未解決のケース。
• 避けられる場合は実際の個人データを使わないこと。すべてでコピーするとすべてのデータが含まれるため、テスターが見る必要のないデータはマスキングまたは匿名化してください。

セキュリティロール、部署、ロールごとのユーザー

UAT では、各ロールが自分の仕事をこなせること、そして自分の仕事しかできないことを証明します。Dynamics 365 では、それはユーザーのセキュリティロール、部署、チームによって決まります。アプリもセキュリティロールを通じて共有されるため、適切なロールがなければ、ユーザーにはアプリが表示されることさえありません。

• テストするロールを、部署とともに一覧にします。たとえば、営業担当者、営業マネージャー、サービス担当者、サービススーパーバイザーなどです。
• UAT 環境で、テスターごとにちょうどそのロールを持つユーザーを用意します。サンドボックスでも、すべてのユーザーにライセンスが必要です。
• 1 人で複数のロールをテストする場合は、ロールごとに別のテストユーザーを使うか、テストの合間にロールを変更して、どのロールを使ったかを記録します。
• システム管理者ロールでは決してテストしないでください。すべてを閲覧でき、すべての操作ができるため、UAT で見つけるべき問題がまさに隠れてしまいます。

環境についてテスターに伝えること

• UAT 環境のアドレス。いつものブックマークでは本番環境が開きます。
• 開くアプリ（Sales Hub や Customer Service ワークスペースなど）と、サインインに使うアカウント。
• データはテストデータであること。何をしても実際の顧客には届かず、表示される内容も最新ではありません。
• サインインできないときや、アプリが表示されないときの連絡先。

UAT Studio ではテスターごとに、セキュリティロールなどの Test role と Test account が割り当てられ、テストの上部に Log in as … として表示されます。Notes for testers には、環境のアドレス、テスト用メールボックス、問い合わせ先を記載します。テスターは、メールで届くコード、または Sign in with Microsoft で UAT Studio にサインインします。

ユーザーストーリーとプロセスからテストケースを作る

Dataverse のテーブルからではなく、業務のプロセスから始めます。Dynamics 365 の UAT の大部分は、次の 2 つのプロセスでカバーできます。

• リードから営業案件、見積まで。リードが登録され、認定されて取引先企業、取引先担当者、営業案件になります。営業案件はビジネスプロセスフローに沿って進み、価格表から製品が追加され、見積が作成、承認、有効化されます。そして受注となり、次のチームやシステムに渡ります。
• ケース管理。ケースがメールやポータルから登録され、適切なキューや担当者に振り分けられ、SLA に沿って進み、ナレッジ記事で解決され、必要に応じてエスカレーションされ、解決済みになります。

各プロセスを、1 つの業務シナリオごとのテストケースに分割します（例：既存の取引先企業でリードを認定する）。そのうえで、対象範囲のすべてのユーザーストーリーに少なくとも 1 つのテストケースがあることを確認します。

ビジネスプロセスフロー

ビジネスプロセスフローは、ユーザーをステージに沿って導きます。次のステージに進む前に必須となるステップを設定できます。ユーザーと同じようにテストしてください。

• すべてのステージと、必須のステップが空のときにどうなるか。
• すべての分岐と、すべてのロール：フローは一部のセキュリティロールに対してだけ有効にできます。

ルーティング、SLA、ナレッジ

Customer Service では、多くの作業がクリックなしで行われます。システムが自動で行うべきことをテストしてください。メールが適切な取引先企業のケースになる、ケースが適切なキューに入る、SLA が正しい時間を表示し期限切れの前に警告する、担当者が適切なナレッジ記事を見つけられる、といったことです。

業務テスターにわかるステップ

各ステップは、操作と期待結果としてテスターの言葉で書きます。必要な箇所にはテストデータを添えます。ステップが合格したかどうかを、テスターが推測しなければならない状況は避けてください。

優先度とリスク

すべてのテストケースが同じように重要なわけではありません。それぞれに Must、Should、Could を付けます。Must は、見積の作成やケースの振り分けなど、初日から動かなければならないものです。さらにリスク、つまり本番稼働後にうまくいかなかった場合の損失を加えます。テスターは Must で高リスクのものから始めるため、時間が足りなくなっても重要なテストは完了します。

うまくいかないケースも加えてください。必須項目が空のまま、上限を超える値引き、本来見えてはいけないレコードが見えてしまう別の部署のユーザーなどです。

UAT Studio ではPriority と Risk の列を含む Excel からテストケースを取り込むか、Azure DevOps Test Plans から読み込むか、テンプレートライブラリ（すべての有料プランに追加できるアドオン）の Dynamics 365 スクリプトから始められます。AI テスト設計では、Azure DevOps のユーザーストーリーから AI がテストケースを提案します。Microsoft Foundry / Azure OpenAI など自社のモデルでも利用できます。あなたが承認するまで、テストケースにはなりません。

テスター

毎日その仕事をしている人を選びます。アカウントマネージャー、サービス担当者、そして承認、キュー、ダッシュボードを担うそのマネージャーです。Dynamics 365 を使っているすべてのチームと国からテスターを選んでください。プロセス、部署、価格表がそれぞれ異なるためです。

必要な時間

テスターごとの時間をそのマネージャーと合意し、再テストの時間も確保してください。電話対応や顧客訪問を続けながらでは、テスターはテストを終えられません。

キックオフ

まず短いキックオフを行います。なぜそのテストが重要か、UAT 環境の開き方、結果の記録方法、課題の登録方法を説明します。キックオフ中に、テスター全員に一度サインインしてアプリを開いてもらいましょう。ライセンス、ロール、環境の取り違えに関する問題の多くは、テスト日ではなくここで見つかります。

テスト日は 1 日か、1 週間か

1 日のテスト日なら、集中でき、すぐに答えが得られます。スコープが小さい場合に向いています。数時間単位のブロックで 1 週間かければ、新しいビルドと再テストの余裕が生まれ、多くのプロセスがある本番稼働に向いています。どちらの場合も、毎日トリアージの時間を決めておきます。

UAT の最中

課題の登録

良い課題は、会議なしで修正できます。テスターには次の情報を求めましょう。

• ステップ、期待していたこと、実際に起きたこと。
• ページのスクリーンショット。エラーメッセージが出た場合はそれも含めます。
• レコードへのリンク。ブラウザーのアドレスバーにあり、コンサルタントは問題が起きた営業案件やケースへ直接移動できます。
• テストに使ったユーザーとセキュリティロール。

UAT Studio ではChrome と Edge 用のブラウザー拡張機能で、Dynamics 365 の横のサイドパネルにテストが表示されます。ステップが不合格になると、スクリーンショット、レコードへのリンク、ページのエラーメッセージも一緒に記録されます。課題には、テスターの名前の横にそのロールが表示されます。

トリアージ

新しい課題は毎日、業務部門と Dynamics 365 チームが一緒に確認します。それぞれに重大度と修正担当者を決め、次のいずれかを判断します。

• 修正：実際の問題で、このリリースで修正します。
• 却下：Dynamics 365 は設計どおりに動作している、またはテストが誤っていた。
• 変更要求：不具合ではなく要望です。このリリースではなく、バックログに入れます。

修正する課題は、スクリーンショットとレコードへのリンクを添えて開発者に送ります。送り先は多くの場合 Azure DevOps です。

再テスト

修正が新しいビルドとして UAT 環境に入ったら、課題を見つけたテスターがそのステップを再テストします。各再テストをどのビルドで行ったかを記録してください。大きな修正の後は、その周辺のプロセスも再テストします。

毎日のステータス

ステアリングコミッティには毎日、計画に対する進捗、重大度別の未解決の課題、妨げになっていることを簡潔に報告します。go/no-go 会議で驚きがないようにします。

UAT Studio ではトリアージは共有画面で、Fix、Reject、Change request を使って進めます。課題は Azure DevOps の Bug ワークアイテムになり、そちらで完了すると課題は Ready for retest になり、テスターにメールが届きます。各ラウンドには、リリース、ビルド、環境が記録されます。Microsoft Teams では、新しい課題、ラウンド、サインオフがチャネルに投稿されます。

サインオフと go/no-go

UAT は業務部門の判断で終わります。最後になって議論にならないよう、最初のテスト日の前に終了基準について合意しておきます。

• Critical の課題が未解決で残っていない。
• Must のテストケースがすべて合格している。
• 未解決の High の課題すべてに、業務部門が受け入れる回避策か修正予定日がある。
• スコープ内のすべてのテストケースに結果がある。

誰がサインオフするか

各プロセスのオーナーがサインオフします。たとえば、リードから見積までなら営業部長、ケース管理ならカスタマーサービス部門の責任者です。オーナーは、承認、条件付き承認、却下のいずれかを選びます。条件はすべて、誰がいつまでに対応するかとともに記録します。そのうえで、ステアリングコミッティが本番稼働を判断します。

レポートに含めるもの

• スコープに含まれていたもの、テストしなかったもの。
• プロセスまたはチームごと、優先度ごとの結果。
• テストした環境、ソリューション、ビルド。
• 重大度別の未解決の課題と、それぞれに対する判断。
• サインオフとその条件、そして最初の数週間の既知のリスク。

UAT Studio ではグループごとのサインオフ：Accepted、Accepted with conditions、Rejected。既定では、Critical の課題が未解決の間は誰も承認できません。最後の結果が入ると、go/no-go レポートが PDF またはスライドで用意されます。

決まったリズムで行う回帰テストラウンド

本番稼働後もアップデートは年間を通じて続き、そのたびにフォーム、フロー、権限が変わる可能性があります。UAT のテストケースは、業務部門が承認した内容を正確に表しているため、最良の回帰テストになります。

• リズムを決めます。たとえば毎月または四半期ごとに回帰テストラウンドを実施し、今のうちにテスターのカレンダーに日程を入れておきます。
• 各ラウンドの前に、Microsoft のロードマップと管理者向けのメッセージを読み、どの変更が自社のプロセスに影響するかを書き留めます。
• プレビューや早期アクセスの機能は、ユーザーに届く前に、まずサンドボックス環境で試します。
• 業務部門の数名のテスターで Must のテストケースを再テストし、時間があれば Should も再テストします。
• UAT と同じように課題を登録し、変更がユーザーに届く前に修正します。

UAT Studio ではプロジェクトの CRM として Dynamics 365 を選びます。Start a regression round で、以前の UAT から選んだテストケースを、ステップ、テストデータ、期待結果とともにコピーします：Must and Should、Only Must、または All test cases in scope。

無料で使える

UAT の前、最中、後に準備すべきことについては、CRM 本番稼働のための UAT チェックリストをご覧ください。こちらも無料の Excel ファイルで提供しています。Dynamics 365 の UAT で UAT Studio ができることについては、Dynamics 365 UAT をご覧ください。

Microsoft、Dynamics 365、Power Platform、Azure DevOps、Microsoft Teams は Microsoft グループ企業の商標です。UAT Studio は Microsoft と提携しておらず、Microsoft の承認も受けていません。