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

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

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

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

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

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

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

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

• 機能: ソリューションを構成する項目と機能が機能しているかどうか。 機能をテストする例として、セマンティック モデルがスケジュールされている更新を遂行できるかどうかが挙げられます。
• データの精度: 表示される数値と結果が完全で、ビジネスの期待と一致しているかどうか。 データの精度をテストする例として、レポート内の値が既知のベースラインと一致しているかどうかが挙げられます。
• パフォーマンス: 使用可能なユーザー リソースやユーザーの待機時間に対してクエリが発生させる影響が最小限に抑えられるかどうか。 パフォーマンスをテストする例として、データフローがタイムアウトに到達したり、長い更新時間を発生させたりせずに確実に更新されるかどうかが挙げられます。
• セキュリティ: 承認されていない個人に対して、情報やソリューション全体の表示やアクセスが制限されているかどうか。 セキュリティをテストする例として、行レベルのセキュリティ (RLS) を検証するときのユーザーまたはロールの権限借用が挙げられます。
• 有効性: ソリューションが関連するビジネス上の問題またはプロセスに対処し、意図したとおりにビジネス目標を十分にサポートするかどうか。 有効性をテストする例として、ユーザー受け入れテスト (UAT) を実施するときのユーザー フィードバックの収集が挙げられます。
• アクセシビリティ: できるだけ多くのユーザーが使用できるように、ソリューションが既知のアクセシビリティ標準を満たしているかどうか。 アクセシビリティをテストする例として、レポートが Microsoft のレポートのアクセシビリティ チェックリストを満たしていることの確認が挙げられます。

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

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

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

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

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

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

手動テストを実施する

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

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

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

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

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

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

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

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

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

• Power BI Desktop: Power BI Desktop を使用すると、さまざまな機能を使用してセマンティック モデルのさまざまな側面を検証できます。 セマンティック モデルのテストを支援する Power BI Desktop 機能の例には次のようなものがあります。
  • 視覚エフェクト キャンバス: ドラッグ アンド ドロップによる視覚エフェクトを使用してモデルの機能と精度をテストします。
  • DAX クエリ ビュー: モデルの精度と、後で保存して再利用できる DAX クエリ付き DAX コードをテストします。
  • クエリ診断: Power Query でのクエリの評価方法に関する診断情報を取得して、更新のパフォーマンスをテストします。
• Fabric: Fabric ポータルの機能と項目を使用すると、ワークスペースにデプロイされたセマンティック モデルの側面を検証できます。
  • セキュリティ: セキュリティ ロールまたはユーザーの権限を借用して、モデルのセキュリティをテストします。
  • ノートブック: セマンティック リンクを使用して、モデルの機能と精度をテストします。
  • 監視ハブ: セマンティック モデルとその他の Fabric データ項目のデータ更新をテストおよび監視します。
• サード パーティのツール: サード パーティのツールを使用すると、より詳細な情報や、検証を支援するその他の機能を提供することで、セマンティック モデルの他の側面を検証できます。 セマンティック モデルのテストを支援するサード パーティのツールの例には次のようなものがあります。
  • DAX Studio: DAX クエリのタイミングとクエリ プランの詳細な内訳を受け取って、DAX コードのパフォーマンスをテストおよび最適化します。
  • Tabular Editor: DAX クエリの評価方法とアクティブな評価コンテキストの詳細な内訳を受け取って、DAX コードの精度をテストおよびデバッグします。

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

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

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

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

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

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

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

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

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

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

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

テストを自動化する

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

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

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

以降のセクションでは、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 を使用して、セマンティック モデルに対してクエリを実行し、レポートをエクスポートできます。 既知のベースラインと照合してクエリ結果を検査し、次にコンテンツ所有者にアラートをトリガーするなどのダウンストリーム アクションを実行できます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

関連するコンテンツ

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