次の方法で共有

Power BI 実装計画: コンテンツを検証する

注

この記事は、 Power BI 実装計画 シリーズの記事の一部です。 このシリーズでは、 Microsoft Fabric 内で Power BI エクスペリエンスを実装する計画に焦点を当てています。 シリーズの 概要を参照してください。

この記事は、コンテンツ ライフサイクルの管理の一部としてコンテンツを検証するのに役立ちます。 主な対象者は次のとおりです。

  • センター オブ エクセレンス (COE) チームと BI チーム: 組織内の Power BI の監督を担当するチーム。 これらのチームには、Power BI コンテンツのライフサイクルを管理する方法を決定する意思決定者が含まれています。 また、これらのチームには、コンテンツ リリースのライフサイクルを処理するリリース マネージャーや、ライフサイクル管理を効果的に使用およびサポートするために必要なコンポーネントを作成して管理するエンジニアを含めることもできます。
  • コンテンツ作成者とコンテンツ所有者: 他のユーザーと共有するために Fabric ポータルに発行するコンテンツを作成するユーザー。 これらの個人は、自分が作成する Power BI コンテンツのライフサイクル管理を担当します。

ライフサイクル管理は、コンテンツの作成から最終的な廃止までの処理に使用するプロセスと作業手順で構成されます。 ライフサイクル管理の第 2 ステージでは、コンテンツを開発し、変更を管理します。これには、コンテンツの開発と、ワークスペースおよびバージョン管理のセットアップの方法に関する重要な決定が含まれます。 第 3 ステージでは、コンテンツを検証して、デプロイの準備ができているかどうかをテストします。

注

通常は、連続する開発と検証のサイクルで、第 2 ステージと第 3 ステージを反復処理します。

コンテンツの検証は、ソリューションの品質と信頼性を確保するために非常に重要です。 このため、運用環境にデプロイする前にコンテンツの変更をテストすることが不可欠です。

次の図は、Power BI コンテンツのライフサイクルを示し、コンテンツを検証する第 3 ステージを強調表示しています。

Power BI コンテンツのライフサイクルを示す図。コンテンツの検証に関する第 3 ステージが強調表示されています。

注

コンテンツ ライフサイクル管理の概要については、このシリーズの最初の記事を参照してください。

この記事は、ライフサイクルを通してコンテンツを検証するための主な考慮事項と意思決定に重点を置いています。 コンテンツの検証方法に関するその他のガイダンスについては、次を参照してください。

  • Power BI への移行: コンテンツの検証: この記事では、他のテクノロジから Power BI に移行するときの検証に関する重要な考慮事項と決定事項について説明します。
  • BI ソリューションの計画: コンテンツの検証: この記事では、Power BI または Fabric ソリューションを計画するときに反復的な開発と検証サイクルを計画する方法について説明します。

コンテンツの検証には、コンテンツが期待どおりに動作するようにするための特定の決定やアクションの実施が含まれます。

コンテンツを検証するときは、ソリューションのさまざまな側面を評価します。

さまざまな種類のテストを実施することで、コンテンツを検証します。 次のセクションでは、コンテンツ作成者とコンテンツ コンシューマーがテストを実行する方法を決定するための主要な考慮事項について説明します。

注

多くのチームは、単体テスト、統合テスト、スモーク テストなどの、ソフトウェア開発に由来するテスト手法を使用します。 コンテンツの検査と検証に同じように有効な方法は、多数あります。 最も重要なのは、ニーズとチームの作業方法に最適なアプローチを使用してコンテンツをテストすることです。

作成者がコンテンツを検証する方法を決定する

コンテンツ作成者は、変更の品質と機能を確保するために、コンテンツに対する自分自身の変更を検証する必要があります。 テストは通常、ソリューションの最新の動作バージョンを含む開発ワークスペースで行われます。 コンテンツ作成者は、ユーザー検証のためにコンテンツがテスト ワークスペースにデプロイされる前に、自分自身の変更をテストします。

注

ユーザーが利用できるようにする前に、コンテンツ作成者が、自分自身のコンテンツを検証することが不可欠です。 明らかな問題を持つソリューションがテスト ユーザーに対して提供されると、ソリューションの信頼性が損なわれます。 テスト時でも、ユーザーは最終製品にそこそこ近いものを期待します。 さらに、機能するソリューションを使用すると、ユーザーはビジネス領域に関連する問題を特定することに集中できます。

コンテンツ作成者がコンテンツを検証するには、2 つの方法があります。

  • 手動テスト: 手動テストでは、主観的な評価またはいくつかの客観的なテスト基準との比較によって、コンテンツを手動で検証するユーザーが含まれます。 手動テストは簡単に実行できますが、人為的なエラーや偏りが発生します。 さらに、コンテンツが特定の規模に達すると、手動テストを適切に実行するのが困難になる可能性があります。 手動テストは 2 つの方法で実施できます。
    • 独立したレビュー。これにはセマンティック モデルやレポートなどの、自分自身のコンテンツのテストが含まれます。
    • ピア レビュー。これには、コンテンツの主観的な評価が含まれ、ソリューションを批判的に査定し、それを改善するための提案を提供します。
  • 自動テスト: 自動テストには、事前に準備されたテストが含まれており、人間の介入なしに自動的に評価されます。 自動テストは通常、ソリューション コードの一部を特定のベンチマークまたはベースラインと照合して検査します。 自動テストは実行が難しく、セットアップに時間と労力がかかります。 ただし、大規模な実装およびビジネス クリティカルなソリューションの品質と信頼性を確保するエンタープライズ シナリオでは、自動テストが不可欠です。

以降のセクションでは、コンテンツ作成者が手動テスト、自動テスト、ピア レビューを実行できるさまざまな方法について説明します。

手動テストを実施する

作成するコンテンツに対して自分自身の手動テストを実行する必要があります。 このテストでは、変更が期待どおりに動作し、目的の品質基準を達成することを確認する必要があります。 手動テストには通常、コンテンツまたは特定のコンテンツ変更の使用と主観的な評価、結果の記述と文書化が含まれます。

自分自身のコンテンツをテストするときの考慮事項をいくつか次に示します。

  • テスト条件と成功基準を事前に決定して文書化します。
  • テストと、テスト結果の文書化を徹底的に実施します。 ただし、テスト手法によって開発速度が低下しないように、余分なテストは避けるようにしてください。
  • 項目の種類ごとにテストの標準セットを作成して、再現性を向上させます。
  • テスト結果と結論を文書化します。
  • 複数回テストして、テスト結果がランダムな確率ではなく現実を最もよく反映していることを確認します。
  • 運用環境を代表するテスト条件を使用します。

以降のセクションでは、手動テストに関するその他の主要な考慮事項について説明します。

セマンティック モデルを手動でテストする

セマンティック モデルは、レポート、ダッシュボード、その他のクライアント ツール、Fabric ワークロードのアップストリーム ソースであるため、Fabric と Power BI のソリューションの重要な部分です。 そのため、デプロイの前にセマンティック モデルを検証することが重要です。

次のような質問への回答を考えると、セマンティック モデルの検証に有益です。

  • テーブルに予期しない欠損値、重複値、または正しくない値が含まれますか?
  • DAX メジャーが、長いクエリ時間をかけずに期待した結果を返すことはありますか?
  • スケジュールされた更新が、長い更新時間をかけずに正常に完了しますか?
  • 視覚エフェクト、フィルター、またはクエリ結果に、参照整合性違反によって引き起こされた "(空白)" 結果が観測されますか?
  • RLS やオブジェクト レベル セキュリティ (OLS) などのデータ セキュリティが、承認されていない個人によるモデルやそのデータへのアクセスを十分に阻止しますか?
  • モデル オブジェクト (DAX メジャーやテーブル列など) が表示フォルダーに編成されていますか?

セマンティック モデルの検証に役立つさまざまなツールとアプローチを使用できます。

  • Power BI Desktop: Power BI Desktop では、さまざまな機能を使用してセマンティック モデルのさまざまな側面を検証できます。 セマンティック モデルのテストを支援する Power BI Desktop 機能の例には次のようなものがあります。
  • Fabric: Fabric ポータルの機能と項目を使用すると、ワークスペースにデプロイされたセマンティック モデルの側面を検証できます。
  • サード パーティ製ツール: サード パーティ製ツールを使用すると、より詳細な情報や検証を容易にするその他の機能を提供することで、セマンティック モデルの他の側面を検証できます。 セマンティック モデルのテストを支援するサード パーティのツールの例には次のようなものがあります。
    • DAX Studio: DAX クエリのタイミングとクエリ プランの詳細な内訳を受け取って、DAX コードのパフォーマンスをテストして最適化します。
    • 表形式エディターの: DAX クエリの評価方法とアクティブな評価コンテキストの詳細な内訳を受け取って、DAX コードの精度をテストおよびデバッグします。

ヒント

クエリ診断を使用して、データフローなどの、Power Query を使用する他の項目から、そのパフォーマンスを手動で検証および最適化できます。

さらに、DAX クエリ ビューと、DAX Studio などのサード パーティのツールを使用して、改ページ対応レポートやスコアカードに対する DAX クエリを検証および最適化できます。

レポートを手動でテストする

レポートは、ユーザーがデータを操作するための一般的な方法です。 多くのユーザーは、意思決定と、ビジネス目標に向けて前進するためのアクションの実行についてレポートに依存しています。 そのため、デプロイの前にレポートを検証することが重要です。

次のような質問への回答を考えると、レポートの検証に有益です。

  • レポートが文書化されたビジネス要件を満たしていますか?
  • 適切な質問に対処するために適切な視覚化タイプが使用されますか?
  • レポート ページは明確かつ簡潔で、色や視覚エフェクトが多すぎていませんか?
  • データのごく一部のサブセットにフィルターを適用しても、レポートが期待どおりに機能しますか?
  • レポートが Excel へのエクスポートを許可していますか? その場合、集計データや基になるデータの取得を許可しますか?
  • レポートを使用して、レポート間のドリルスルーや視覚エフェクトの個人用設定を行うことができますか?

レポートの検証に役立つさまざまなツールとアプローチを使用できます。

  • Power BI Desktop: Power BI Desktop では、さまざまな機能を使用してレポートのさまざまな側面を検証できます。 レポートのテストを支援する Power BI Desktop 機能の例には次のようなものがあります。
    • ビジュアル キャンバス: スライサー、フィルター、およびその他の対話型要素を使用してレポート機能をテストします。
    • パフォーマンス アナライザーの: ビジュアルレンダリングと DAX クエリ時間の を測定してレポートのパフォーマンスをテストします。 パフォーマンス アナライザーから視覚エフェクト DAX クエリをコピーして他のツールで使用し、文書化のためにパフォーマンス結果を保存します。
    • クエリ制限シミュレーション: 展開先の容量においてのメモリ制限をシミュレートして、レポートのパフォーマンスをテストします。
  • Fabric: Fabric ポータルの機能とアイテムを使用すると、ワークスペースにデプロイされたレポートの側面を検証できます。
    • アプリのを更新する: Power BI アプリでレポートを配布し、さまざまなアプリの対象ユーザーを設定して、どのコンテンツを表示できるかを決定するときに、レポートの機能とセキュリティをテストします。 アプリの対象ユーザーを使用すると、自分自身でそれらのユーザーがアクセスできるレポートをプレビューし、アプリ環境をテストできます。
    • ワークスペースまたはアプリのの読み取りビュー: ユーザーと同じ環境でレポートの機能と精度をテストします。

注

ダッシュボードの開発と検証を行うことができるのは、Fabric ポータルのみです。

重要

Power BI Desktop と、デプロイ後の Fabric ポータルの両方でレポートをテストすることが不可欠です。 ローカル マシン上の視覚エフェクトのレンダリングは、Fabric ワークスペース内のレポートと比較して、動作が異なる場合があります。 さらに、ワークスペースまたはアプリからレポートを使用するユーザー環境は、Power BI Desktop でのレポートの使用とは大きく異なることに注意してください。

ピア レビューを実行して手動でテストする

コンテンツを手動で検証するもう 1 つの方法は、ピア レビューを実行することです。 ピア レビューでは、コンテンツ作成者が、評価するソリューションまたはソリューションの一部を同僚に提供します。 ピア レビューの目的は、複数のコンテンツ作成者の集合的な経験と専門知識を使用してソリューションを改善することです。 ピア レビューは、手動テストと自動テストの最中と終了後の両方で実行できます。

注

ピア レビューは、多くの業界で使用される標準的なアプローチです。 このアプローチは、コンテンツ、製品、プロセスの品質を向上させるために一般的に知られています。

ヒント

自分がソリューションの唯一のコンテンツ作成者である場合は、ソリューションをレビューしてもらうコンテンツ作成者を別のチームで見つけて、自分からも同じ作業を提供することを検討してください。

ピア レビューは、さまざまな方法で実施できます。

  • 機能レビュー: 機能レビューでは、ソリューションが満たす必要がある機能、プロセス、またはビジネス要件に重点を置いています。 機能レビューでは、レビュー担当者はエンド ユーザーであるかのようにソリューションを使用します。 見つけた欠陥や問題を、実装を改善するための主観的な批判とともに文書化します。
  • 技術レビュー: 技術的なレビューでは、データ モデリング、コード、設計など、ソリューションの技術的な側面に重点を置いています。 技術レビューでは、レビュー担当者は特定の機能や変更がどのように実装されたかを評価し、代替アプローチを提案したり、現在のアプローチの潜在的な欠陥やリスクを明示したりします。
  • pull request: ソース管理を実行するときに、pull request (PR) を作成して、変更をソリューションの最新バージョンにマージします。 技術所有者が提案された変更をレビューし、ソース コードを評価します。 この種のレビューは、DAX または M コードの書式設定などの標準規則にコードが準拠していることを確認したり、アンチパターンや潜在的に問題のあるコードを識別したりするのに役立ちます。

ヒント

コンテンツの変更をユーザー受け入れテストに進めるには、何らかの正式なピア レビューと承認を実行することをお勧めします。 これは、テスト中であっても、品質の低いコンテンツがデータ ソリューションの信頼性を損なう可能性があるためです。 さらに、ピア レビューは、チーム メンバー間のコラボレーションと知識共有の点でもメリットを生み出します。

ピア レビュー サイクルを完了したら、推奨される変更を文書化して組み込む必要があります。 必要に応じて、ユーザー テストに進む前に、承認のために変更を再送信する必要があります。 通常、ピア レビューを複数回繰り返す必要があるのは、テスト対象の変更が多いか、複雑な変更がいくつかある場合のみです。

Copilot と AI スキルの出力を手動でテストする

Copilot または AI スキルを使用すると、ユーザーは自然言語を使用してデータ モデルに関する質問をすることができます。 ただし、これらのツールを使用すると、生成 AI が利用され、低品質または不正確な出力が返される可能性があります。 これらの出力を使用する前に、常に評価することが重要です。

Copilot と AI スキルの出力をテストするには、次のことができます。

  • 前月の売上の合計、顧客または製品の合計数など、既知のベンチマークをテストする簡単な質問をします。
  • 出力をレポートの結果またはアドホック分析と比較します。
  • セマンティック モデル に変更を加えるの前後の出力を比較します。

テストを自動化する

コンテンツ作成者はテストを自動化して、デプロイ前にテストが自動的に実行されるようにできます。 自動テストには通常、コンテンツの保存や pull request (PR) の送信などの、特定のアクションに応じてプログラムによって実行および編成される事前準備済みのテスト条件が含まれます。 自動テストの結果は、後で参照および文書化するために自動的に保存されます。

自動テストの目的は、テストの一貫性と結果の信頼性を向上させながら、コンテンツの変更を検証する時間と労力を削減することです。 コンテンツは通常、自動テストに失敗すると、コンテンツ作成者が問題を解決するまでデプロイできません。

効果的な自動テストは、DataOps の実装の主要な部分です。 DataOps を使うと、データと分析の配信を改善および高速化する手法をチームが採用することで、プロセスを自動化し、スケーリングできます。

重要

テストを効果的に自動化するには、適切に設計されたテストを作成する必要があります。 そのようなテストを作成するには、かなりの時間と労力がかかることがあります。 テスト条件と期待値の定義が適切ではない場合、自動テストではコンテンツの適切な側面を検証できないため、そのようなテストを自動化するメリットはほとんどありません。

ヒント

自動テストは、エンタープライズ コンテンツの公開シナリオでソリューションのデプロイと統合するときにメリットが最も大きくなります。 たとえば、コンテンツをデプロイする準備が整っていることを確認する検証パイプラインの一部として Azure Pipelines を使用して、テストを自動化できます。 詳細については、第 4 ステージのコンテンツのデプロイに関する記事を参照してください。

以降のセクションでは、Power BI セマンティック モデルとレポートを自動的にテストするための主要な考慮事項について説明します。

セマンティック モデルのテストを自動化する

セマンティック モデルの自動テストは可能ですが、通常はサード パーティのツールとフレームワークを使用したカスタム セットアップが必要になります。

さまざまなツールとアプローチを使用して、セマンティック モデルのテストを自動化できます。

  • ベスト プラクティス アナライザー (BPA): ベスト プラクティス アナライザー では、セマンティック モデルの評価に使用できるルールを指定できます。 セマンティック モデル内の規則違反を特定する Tabular Editor を使用して、BPA を実行できます。 Azure DevOps とともに、または別のスケジュールされたプロセスの一部として Tabular Editor のコマンド ライン インターフェイス (CLI) を使用することで、BPA 規則違反の検査を自動化できます。
  • Fabric ノートブックとセマンティック リンク: Fabric のノートブックを使用すると、セマンティック リンクを使用して、プログラムによりセマンティック モデルと対話できます。 ノートブックを使用して、データを検証するために Great Expectations (GX) などのフレームワークを実行できます。 さらに、メジャーと DAX クエリを評価し、次に既知のベースラインと照合して結果をテストできます。
  • Power Automate: Power Automate を使用すると、Power BI REST APIを使用してセマンティック モデルに対してクエリを実行し、レポートをエクスポートできます。 既知のベースラインと照合してクエリ結果を検査し、次にコンテンツ所有者にアラートをトリガーするなどのダウンストリーム アクションを実行できます。

ヒント

自動テストとセマンティック モデルの編成を組み合わせることを検討してください。 たとえば、ノートブックや Power Automate を使用して更新する前に、データ ソースとセマンティック モデルに対して自動テストを実施できます。 テストが失敗した場合は、更新を阻止できます。これにより、更新エラーや不適切なデータのビジネス レポートへの到着も阻止できます。

レポートのテストを自動化する

レポートのテストを自動化するために使用できるオプションは限られています。 このようなオプションは、外部ツールまたはコミュニティ ソリューションに依存して、レポート メタデータの検証やユーザーのレポートとの対話のシミュレートなどの、視覚エフェクトやレポートのプロパティの自動検証を行います。

レポートのテストを自動化するために、さまざまなツールとアプローチを使用できます。

  • レポートのベスト プラクティス アナライザー: レポート定義を調べることでレポート内の問題の検出を自動化するベスト プラクティス アナライザーのような機能をサポートする、さまざまなサード パーティ製ツールがあります。 この機能をサポートするツールの 2 つに、PBI Explorer と PBI Inspector があります。
  • Power Automate Desktop: Selenium for Python や Power Automate Desktop などの UI オートメーション ツールを使用すると、レポートを使用してユーザーのマウス操作をシミュレートできます。 ユーザー フローを定義することで、ナビゲーションと対話をテストできます。 これらのテストは、フローを完了できたときに合格になり、画面上の特定の単語や画像 (エラー メッセージや空の視覚エフェクトなど) を検出したときに不合格になります。

ユーザーがコンテンツを検証する方法を決定する

コンテンツは、手動テスト、自動テスト、ピア レビューに合格すると、ユーザー テストに進むことができます。 ユーザーは、コンテンツをテストするとき、そのコンテンツがビジネス要件を満たし、期待どおりに実行される (正確な結果を返すなど) かどうかについて、主観的なフィードバックを提供します。

通常、ユーザー検証はテスト ワークスペースで行われます。 テスト ワークスペースをセットアップするときは、次の事項を考慮に入れてください。

  • テスト アプリを作成する: Power BI アプリを使用してコンテンツを配布する場合は、テスト ユーザーがコンテンツを検証するためのテスト アプリを設定します。 そのテスト アプリは、運用環境でセットアップするアプリと同じである必要があります。 テスト アプリのナビゲーションには、文書化、トレーニング、フィードバック フォームへのリンクを含めることを検討してください。
  • アクセスの提供: ソリューションを検証するコミュニティのユーザーの一部を特定します。 これらのユーザーに連絡し、このコンテンツを検証する必要がある時期と理由について契約を結びます。 次に、ユーザーについて、コンテンツへのアクセス権の付与と、適切なセキュリティ ロールへの追加を確実に行います。 それらのユーザーがテストを開始できるように、コンテンツまたはテスト アプリへのリンクを共有します。
  • スケジュールされた更新を設定する: ユーザー検証は通常、より長い期間に及びます。 ユーザーがテストに最新のデータを使用するように、テスト ワークスペース内のデータ項目のスケジュールされた更新をセットアップすることをお勧めします。

重要

テスト ワークスペースにコンテンツをデプロイするときは、レポートとダッシュボードへの変更をユーザーに表示する前に、アプリを手動で更新する必要があります。

注

ワークスペース間でのアプリのデプロイやコピーはできません。 アプリに対する変更は、そのワークスペースの構成で手動で行う必要があります。

ユーザー検証を開始する前に、必要な準備を行う必要があります。

  • ユーザー検証を行う時期を計画します。
  • ユーザー検証を特定の期間に限定するか、反復プロセスの一部にするかを指定します。
  • Microsoft Forms の使用などのフィードバック収集手段を作成します。
  • 検証に関係するユーザーに、計画と期待内容を連絡します。
  • ユーザーをガイドし、期待内容を管理するために、ユーザー検証のキックオフを編成します。
  • 検証とフィードバックのプロセスを示すユーザー向けのトレーニングを実施します。

コンテンツのユーザー検証を支援する他の方法をいくつか次に示します。

  • 観測所のテスト: 観測所テストは、コンテンツ作成者が 1 人以上のユーザーがガイダンスや指示なしにコンテンツを使用するのを見る短いセッションです。 これらのセッションで、コンテンツ作成者は観測により、ソリューションの潜在的な欠陥、問題、または改善点を特定します。 これらのテストは、編成に必要な時間と労力が少なく、ソリューションの特定の機能や部分に限定できるため、有益になる可能性があります。 観測テストは、概念実証 (POC) などの、設計やアプローチに関する早期のフィードバックを得る点で最も有益です。
  • フォーカス グループ テストの: フォーカス グループ テストは、コンテンツを一緒に使用する少数のユーザーグループで構成された制限付きセッションです。 これらのフォーカス グループは、特定の機能に関する最適なフィードバックを提供できる主要な利害関係者と領域の専門家が選択されるように厳選されます。 フォーカス グループ テストは、複数の対話型セッションで行うことができます。 フォーカス グループ テストは、観測テストよりも多くの時間と労力が必要ですが、ソリューションに関するより詳細なフィードバックを提供できます。
  • ユーザー受け入れテストの: ユーザー受け入れテスト (UAT) は、ユーザー コミュニティの大規模な個人グループがソリューションに関する非同期フィードバックを検証して提供する正式なプロセスです。 UAT は、編成に最も多くの時間と労力が必要ですが、ユーザー テストを実施する最も徹底的な方法です。 テスト ユーザーがソリューションを受け入れ、フィードバックの問題が解決されたら、コンテンツを運用ワークスペースにデプロイできます。

コンテンツを検証する方法を決定したら、ワークスペースに対して、およびワークスペース間で、コンテンツをデプロイする方法を計画できます。

チェックリスト - コンテンツの公開を計画するときに、主要な決定事項とアクションは次のとおりです。

  • テスト条件設計と文書化: 実施するテスト、テスト内容、実行方法について説明します。
  • ピアレビューのプロセスを決定する: 自分以外に誰がコンテンツを検証するのかについて説明します。
  • 手動テストのアプローチを決定する: 作成するコンテンツの検証に使用するツールと機能を決定します。
  • 自動テストを使用するかどうかを決定する: コンテンツのスケールとスコープが、自動テストを設定することを正当化するかどうかを識別します。 なる場合は、これらのテストが期待内容を検証するように、設計と実装に必要な時間とリソースを計画してください。
  • 開発ワークスペースからテスト ワークスペースにコンテンツを展開: ユーザーが変更を表示できるように、開発ワークスペースからテスト ワークスペースに変更をデプロイします。 テスト アプリの設定や更新などの必要なデプロイ後アクティビティを、テスト ワークスペースで完了したことを確認します。
  • をテストする方法を決定する: ユーザーがコンテンツを検証する方法を決定します。
  • テスト ユーザーの識別: ユーザー コミュニティ内でコンテンツを検証するユーザーを特定します。 その関与と期待内容について、それらの個人と合意に達します。
  • ユーザー フィードバックの収集: フィードバックを自動的に収集するためのツールとプロセスを設定します。 たとえば、Microsoft Teams や Microsoft Forms でタスクと Planner を使用できます。
  • テスト結果を文書化する: すべてのコンテンツ検証の結果と、テスト結果の結果として行われた変更を文書化します。 この文書は、簡単に見つけられるようにします。
  • 実稼働へのデプロイを計画する: ユーザー テストが終了したら、テスト ワークスペースから運用ワークスペースにコンテンツをデプロイする準備をします。

関連するコンテンツ

このシリーズの次の記事では、コンテンツ ライフサイクル管理の一部としてコンテンツをデプロイする方法について説明します。