次の方法で共有

Power BI に移行するコンテンツを作成する

  • [アーティクル]

この記事では、Power BI に移行するときのコンテンツの作成と検証に関係するステージ 4 について説明します。

Power BI 移行のステージを示すダイアグラム。この記事では、ステージ 4 を重点的に説明します。

Note

上の図の詳細については、「Power BI への移行の概要」を参照してください。

ステージ 4 の主な目的は、概念実証 (POC) を運用可能なソリューションに変換する実際の作業を実行することです。

このステージからの出力は、開発ワークスペースで検証され、運用環境へのデプロイの準備ができている Power BI ソリューションです。

ヒント

この記事で説明するほとんどのトピックは、標準の Power BI 実装プロジェクトにも適用されます。

運用ソリューションの作成

この時点で、POC を実行したのと同じ人物が、運用環境に対応するように Power BI ソリューションの作成を続けて行う可能性があります。 または、別の人物が関係している可能性があります。 タイムラインが守られるのであれば、将来の Power BI 開発を担当する人々を関わらせるのは良いことです。 そうすることで積極的に学習できます。

重要

POC での作業をできるだけ多く再利用します。

新しいインポート セマンティック モデルを開発する

既存の Power BI セマンティック モデルがまだ存在しない場合や、ニーズに合わせて拡張できない場合は、新しいインポート セマンティック モデルを作成することもできます。

理想的には、最初から、データとレポートの開発作業を切り離すことを検討してください。 データとレポートを切り離すことにより、データ モデリングとレポートを別々の担当者が担当する場合に、作業およびアクセス許可の切り分けが容易になります。 これにより、よりスケーラブルなアプローチが可能になり、データの再利用が促進されます。

インポート セマンティック モデルの開発に関連する重要なアクティビティは次のとおりです。

ヒント

開発、テスト、運用の環境が異なる場合は、データ ソースのパラメーター化を検討します。 そうすることで、ステージ 5 で説明されている展開が大幅に簡単になります。

新しいレポートとダッシュボードの開発

Power BI レポートまたはダッシュボードの開発に関連する重要なアクティビティは次のとおりです。

  • 既存のデータ モデルへのライブ接続を使用するか、新しいデータ モデルを作成するかを決定します
  • 新しいデータ モデルを作成する場合は、モデル テーブルのデータ ストレージ モード (インポート、DirectQuery、または複合) を決定します。
  • 要件を満たす最適なデータ視覚化ツールを決定します: Power BI Desktop、Paginated Report Builder、または Excel。
  • レポートで伝える必要があるストーリーを伝え、レポートで答える必要がある質問に対処するための、最適なビジュアルを決定します。
  • すべてのビジュアルに明確で簡潔な、ビジネスに適した用語が示されていることを確認します。
  • 対話性の要件に対処します。
  • ライブ接続を使用する場合は、レポートレベルのメジャーを追加します。
  • Power BI サービスにダッシュボードを作成します (特に、コンシューマーが主要なメトリックを簡単に監視する方法が必要な場合)。

注意

これらの決定の多くは、計画の早い段階または技術的 POC において行います。

ソリューションの検証

Power BI ソリューションの検証には、主に次の 4 つの側面があります。

  1. データの精度
  2. セキュリティ
  3. 機能
  4. パフォーマンス

データの精度の検証

移行中に 1 回限りの作業として、新しいレポートのデータが従来のレポートに表示されるものと一致することを確認する必要があります。 または、違いがある場合は、その理由を説明できるようにします。 従来のソリューションにエラーが見つかり、新しいソリューションでそれを解決することは、皆さんが思っている以上によくあります。

継続的なデータ検証作業の一環として、通常は新しいレポートと元のソース システムをクロスチェックする必要があります。 この検証は、反復可能な方法で、レポートの変更を発行するたびに実行するのが理想的です。

セキュリティの検証

セキュリティを検証する際に考慮すべき主な側面が 2 つあります。

  • データのアクセス許可
  • セマンティック モデル、レポート、ダッシュボードへのアクセス

インポート セマンティック モデルでは、行レベルのセキュリティ (RLS) を定義することによって、データ アクセス許可が適用されます。 DirectQuery ストレージ モード (場合によってはシングル サインオンを使用) を使用する場合、ソース システムによってデータのアクセス許可が適用される可能性もあります。

Power BI のコンテンツへのアクセスを許可する主な方法は次のとおりです。

ヒント

セキュリティを効果的に管理する方法についてコンテンツ作成者にトレーニングを行うことをお勧めします。 また、信頼性の高いテスト、監査、監視を実施することも重要です。

機能の検証

次は、フィールド名、書式設定、並べ替え、既定の概要作成の動作など、セマンティック モデルの詳細をダブルチェックします。 スライサー、ドリルダウン アクション、ドリルスルー アクション、式、ボタン、ブックマークなど、対話型のレポート機能もすべて検証する必要があります。

開発プロセスでは、Power BI ソリューションを Power BI サービスの開発ワークスペースに定期的に発行する必要があります。 すべての機能がサービスで期待どおりに動作することを確認します (カスタム ビジュアルのレンダリングなど)。 それは、さらにテストを実行するのにも適したタイミングです。 スケジュールされた更新、Q&A、また、レポートとダッシュボードがモバイル デバイスでどのように表示されるかをテストします。

パフォーマンスの検証

Power BI ソリューションのパフォーマンスは、コンシューマーのエクスペリエンスにとって重要です。 ほとんどのレポートでは、10 秒以内にビジュアルが表示される必要があります。 読み込みにそれよりも時間がかかるレポートがある場合は、一度立ち止まって、何が遅延の原因になっているかを再検討します。 レポートのパフォーマンスは、Power BI Desktop に加えて、Power BI サービスで定期的に評価する必要があります。

基準を下回る DAX (Data Analysis eXpressions)、不適切なセマンティック モデル デザイン、または最適でないレポート デザイン (たとえば、1 つのページに表示されるビジュアルの数が多すぎるなど) によって、多くのパフォーマンスの問題が発生します。 ネットワーク、過負荷のデータ ゲートウェイ、Premium 容量がどのように構成されているかといった技術的な環境の問題も、パフォーマンスの問題の原因になることがあります。 詳細については、「Power BI の最適化ガイド」と「Power BI でのレポートのパフォーマンスのトラブルシューティング」を参照してください。

重要

この記事では、Power BI Premium またはその容量サブスクリプション (P SKU) に言及することがあります。 現在、Microsoft は購入オプションを統合し、容量あたりの Power BI Premium SKU を廃止していることに注意してください。 新規および既存のお客様は、代わりに Fabric 容量サブスクリプション (F SKU) の購入をご検討ください。

詳細については、「Power BI Premium ライセンスに関する重要な更新」と「Power BI Premium のよく寄せられる質問」を参照してください。

ソリューションの文書化

Power BI ソリューションに役立つドキュメントには、主に次の 2 種類があります。

  • セマンティック モデルのドキュメント
  • レポートのドキュメント

ドキュメントは、対象ユーザーが最も簡単にアクセスできる場所に保存できます。 一般的なオプションは次のとおりです。

  • SharePoint サイト内: SharePoint サイトは、センター オブ エクセレンスまたは社内 Power BI コミュニティ サイトとして存在する場合があります。
  • アプリ内: Power BI アプリを発行するときに URL を設定して、コンシューマーに詳細情報を案内することができます。
  • 個々の Power BI Desktop ファイル内: テーブルや列などのモデル要素に説明を定義できます。 このような説明は、レポートを作成するときに、 [フィールド] ペインにヒントとして表示されます。

ヒント

Power BI 関連のドキュメントのハブとして機能するサイトを作成する場合は、その URL の場所を使用して [ヘルプの表示] メニューをカスタマイズすることを検討します。

セマンティック モデルのドキュメントの作成

セマンティック モデルのドキュメントは、将来、セマンティック モデルを管理するユーザーを対象としています。 次のものを含めると便利です。

  • 設計上の決定とその理由。
  • セマンティック モデルを所有、保守、認定するユーザー。
  • データ更新の要件。
  • セマンティック モデルで定義されているカスタム ビジネス ルール。
  • 特定のセマンティック モデルのセキュリティまたはデータのプライバシーに関する要件。
  • 将来のメンテナンスのニーズ。
  • 既知の未解決の問題または遅延バックログ項目。

また、時間の経過に伴ってセマンティック モデルに発生した最も重要な変更をまとめた、変更ログを作成することもできます。

レポートのドキュメントの作成

レポートのドキュメントは、通常、レポート コンシューマーを対象とするチュートリアルとして構成されており、コンシューマーがレポートやダッシュボードからより多くの価値を得るのに役立ちます。 多くの場合、短いビデオ チュートリアルが効果的です。

また、レポートの非表示ページに追加のレポート ドキュメントを含めることもできます。 これには、設計上の決定と変更ログを含めることができます。

関連するコンテンツ

この Power BI 移行シリーズの次の記事では、Power BI に移行するときのコンテンツの展開、サポート、監視に関係するステージ 5 について説明します。

その他の役に立つリソースは次のとおりです。

経験豊富な Power BI パートナーを活用して、組織の移行プロセスを成功させることができます。 Power BI パートナーを手配するには、Power BI パートナー ポータルにアクセスしてください。