Power BI 実装計画: コンテンツを計画および設計する

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

• センター オブ エクセレンス (COE)、BI チーム: 組織内で Power BI の監視を担当するチーム。 これらのチームには、Power BI コンテンツのライフサイクルを管理する方法を決定する意思決定者が含まれています。
• コンテンツ作成者とコンテンツ所有者: 他のユーザーと共有するために Fabric ポータルに公開するコンテンツを作成するユーザー。 これらの個人は、自分が作成する Power BI コンテンツのライフサイクル管理を担当します。

ライフサイクル管理は、コンテンツをその作成から最後の提供終了まで処理するために使用するプロセスと作業手順で構成されます。 このシリーズの最初の記事で説明されているように、ビジネス ユーザーにコンテンツを一貫性をもって確実に配信するためには、Power BI コンテンツのライフサイクル管理が重要です。

コンテンツ ライフサイクルの最初の段階は、コンテンツの計画と設計です。 通常は、BI ソリューション計画を実行して、コンテンツのライフサイクルを開始します。 ソリューションによる対処が必要な問題を理解して定義するための要件を収集してから、ソリューション設計を行います。 この計画と設計の段階では、後のステージに備えるための重要な決定を行います。

次の図は、Power BI コンテンツのライフサイクルを示し、コンテンツの計画と設計を行う第 1 ステージを強調表示しています。

要件を収集するときは、ライフサイクル管理へのアプローチに影響を与えるコンテンツに関する側面を明確に説明する必要があります。 こうした側面は、ソリューションの計画と設計の際に文書化する必要があります。

この記事の次のセクションでは、コンテンツを計画および設計する際にライフサイクル管理に対するアプローチを決めるソリューションの主な側面と考慮事項について説明します。

コンテンツを特定して説明する

ソリューションを設計するときは、コンテンツの内容、コンテンツを作成するユーザー、サポートするユーザー、およびこのコンテンツが組織にとってどれほど重要であるかを説明する必要があります。 ソリューション設計の際には、要件を収集し、こうした要因に注意を向ける必要があります。

後でライフサイクル管理に関する決定を行うために、コンテンツに関する次の質問に回答します。

コンテンツの形式とは何ですか?

コンテンツの種類、スコープ、複雑さによって、コンテンツの管理方法に関する重要な決定の内容が変わってきます。 たとえば、限られた対象ユーザーに対して 1 つのレポートを作成するには、組織全体および複数の異なるダウンストリーム ワークロードで使用されるセマンティック モデルの場合とは異なるライフサイクル管理アプローチが必要です。

作成するコンテンツの種類を決定するために、次のような質問に回答します。

• 作成する予定のアイテムの種類は何ですか、それぞれをどれくらい作成しますか? たとえば、データフローやセマンティック モデルなどのデータ アイテム、レポートやダッシュボードなどのレポート アイテム、またはその両方の組み合わせを作成しますか?
• コンテンツ コンシューマーにコンテンツはどのように配信されますか? たとえば、コンシューマーはデータ項目を使用して独自のコンテンツを作成しますか、あるいは一元化されたレポートのみを表示しますか、またはその両方を組み合わせて表示しますか?
• コンテンツはどのくらい複雑ですか? たとえば、小さなプロトタイプですか、それとも複数のビジネス プロセスを含む大規模なセマンティック モデルですか?
• コンテンツのスケール、スコープ、複雑さが時と共に拡大することが予想されますか? たとえば、コンテンツは今後、他のリージョンやビジネス領域に含められますか?
• ビジネスにおいてこのコンテンツが必要になると予想されるのはどのくらいの期間ですか? たとえば、このコンテンツは、有限のタイムラインを持つビジネスの主要なイニシアチブをサポートするものですか?

誰がコンテンツを作成してサポートしますか?

コンテンツ作成者には、さまざまなニーズ、スキル、ワークフローがあります。 こうした要因は、さまざまなライフサイクル管理アプローチの成功に寄与します。 コラボレーションを伴う大規模な中央のチームではしばしば、セルフサービス作成者の小規模なチームよりも高度なコンテンツ ライフサイクル管理が必要になることがあります。

コンテンツを作成またはサポートするユーザーを決定するために、次のような質問に回答します。

• このコンテンツを作成する人はどのくらいいますか? 複数のコンテンツ作成者が共同作業を行いますか、それとも一人がコンテンツの作成を担当しますか?
• コンテンツ作成者は、ライフサイクル管理と、バージョン管理などの関連概念に精通していますか? コンテンツ作成者はライフサイクル管理の利点を理解していますか?
• ソリューションを開発するコンテンツ作成者は、デプロイ後にサポートを行うのと同じ人ですか?
• コンテンツ作成者またはチームは、既存のソリューションをサポートするために既存のライフサイクル管理プラクティスを実施していますか?
• コンテンツ作成者は現在、Azure DevOps などのライフサイクル管理ツールを使用していますか?

コンテンツの重要性とは何ですか?

ビジネスにとってのコンテンツの重要度に応じて、コンテンツの管理方法についてのさまざまな決定を行います。 Bus Critical コンテンツでは、品質を保護し、中断の可能性を軽減するために、より堅牢なコンテンツ ライフサイクル管理アプローチが必要です。

コンテンツが重要かどうかを判断するために、次のような質問に回答します。

• このコンテンツはビジネスにとってどのくらい重要ですか? 開発要求の緊急度はどのくらいですか?
• Bus Critical な意思決定やアクションは、このコンテンツによって提供される情報から行われますか?
• このコンテンツを (組織全体から限られたローカル チームに) どの程度広く配信することが予想されますか?
• エグゼクティブやその他の戦略的意思決定者は、仕事のためにコンテンツに依存しますか?
• このコンテンツの影響とは何ですか? たとえば、このコンテンツが突然利用できなくなったら、収益の損失やビジネス プロセスの中断など、ビジネスにどのような影響が生じますか?

作成するコンテンツを十分に特定して説明したら、今度はコンテンツ作成者が共同作業を行う方法を決定する必要があります。

コンテンツ作成者が共同作業を行う方法を決定する

ソリューションのスコープが広くなり、複雑になると、複数のコンテンツ作成者と所有者による共同作業が必要になる場合があります。 複雑なソリューションを作成する場合は、コラボレーションの体制、管理、サポートに役立つ効果的なツールを使用することをお勧めします。 Microsoft Teams や Azure DevOps を使用するなど、Power BI コンテンツの生成時に共同作業を行う方法は多数あります。

Microsoft Teams

小規模なプロジェクトや単純なプロジェクトの場合、コンテンツ作成者は Microsoft Teams を使用して共同作業を行うことができます。

Microsoft Teams を使用すると、コンテンツ作成者はチームやチャネルでコミュニケーション、計画、作業を行うことができます。 多くの場合、Microsoft Teams は単純なコラボレーション シナリオに適しています。 たとえば、限られた対象ユーザー向けにコンテンツを生成する分散型チームは、ドキュメント ライブラリを使用してファイルを格納したりバージョン管理を行ったりすることができます。 また、他の統合済みツールやサービスを利用することもできます。

Microsoft Teams で共同作業とコミュニケーションを行うために、Power BI コンテンツのライフサイクル全体を通してサポート サービスを使用します。

• Planner: コンテンツ所有者は Planner を使用して計画を作成できます。このプランは、タスクの追跡やコンテンツ作業のスコープ設定に使用されます。 タスクにより、ソリューション内の問題、バグ、または機能、および対応する利害関係者について説明することができます。
• SharePoint: コンテンツ作成者は、各チャネルの Microsoft Teams ドキュメント ライブラリまたは接続済みサイトにファイルを保存したり、ファイルを管理したりすることができます。 SharePoint に保存されているコンテンツ ファイルは、バージョン管理を使用して、コンテンツの変更を追跡および管理するのに役立ちます。 SharePoint を使用した変更の追跡と管理の詳細については、第 2 ステージ: コンテンツの開発と変更管理を参照してください。
• 承認: コンテンツ作成者と所有者は、ワークフローを設定して使用して、レビュー後にコンテンツの変更やリリースを承認することができます。
• Fabric と Power BI: コンテンツ作成者と所有者は、Microsoft Teams 内から Fabric ポータルにアクセスできます。 そこから、コンテンツを管理したりコンテンツについて話し合ったり、Teams チャネルのタブに役立つレポートを追加したりできます。
• その他の統合: コンテンツ作成者は、Microsoft Teams と統合された他の Microsoft またはサード パーティのサービスを利用して、好みのワークフローを実現し、ニーズを満たすことができます。

コンテンツ作成者が Microsoft Teams を使用してどのように共同作業すべきかについて、構造化されたプロセスを定義することをお勧めします。 次のことを決めてください。

• チームとチャネルへのアクセスを管理する方法。
• チームとチャネルの管理を担当するユーザー。
• 作業の範囲を指定し、個別のチーム、チャネル、および計画に組み入れる方法。
• コンテンツ作成者がドキュメント ライブラリを使用してファイルを整理し、変更を追跡および管理する方法。 例: ドキュメント ライブラリを整理する方法や、コンテンツ作成者がファイルをチェックインしてチェックアウトする必要があるかどうか。
• コンテンツ作成者が OneDrive 更新を使用して Power BI Desktop (.pbix) ファイルを自動的に発行するかどうかを指定します。
• ファイル同期の競合を解決する方法。
• 関連性がなくなったドキュメント ライブラリのファイルをアーカイブおよび削除するタイミング。

Azure DevOps

コンテンツ作成者と所有者は、Azure DevOps を使用して、中央の整理されたハブでコミュニケーションと共同作業を行うこともできます。

Azure DevOps では、コンテンツ作成者はプロジェクトを使用して、コミュニケーション、計画、作業を構造化します。 さらに、コンテンツ作成者は、ソース管理、検証、デプロイを実施して、Azure DevOps 内からコンテンツ ライフサイクル管理を調整することができます。 ソース管理は、コンテンツ コードとメタデータに対する細かい変更を管理するプロセスです。

多くの場合、Azure DevOps には、コンテンツの作成とデプロイを調整するためのサポート サービスとオプションがあるため、より高度なコラボレーション シナリオに適しています。

コンテンツ作成者が Azure DevOps を使用してどのように共同作業すべきかについて、構造化されたプロセスを定義することをお勧めします。 次のことを決めてください。

• 作業のスコープ設定方法と、コンテンツ ブランチの作成、名前付け、使用の方法。
• 作成者が変更をグループ化してコミットし、コミット メッセージで説明する方法。
• pull request を使用した変更の確認および承認の担当者。
• pull request のマージ競合を解決する方法と、誰がそれを行うか。
• さまざまなブランチで行われた変更を 1 つのブランチにマージする方法。
• コンテンツをテストする方法と、コンテンツのデプロイ前にテストを実行する担当者。
• 開発、テスト、運用環境のワークスペースに変更をデプロイする方法とタイミング。
• デプロイ済みの変更またはソリューションのバージョンをロールバックする方法とタイミング。

コンテンツ作成者が共同作業を行うかどうか、どのように行うかを決定したら、次にファイルを保存する場所を決定する必要があります。 これらのファイルの多くは、共同作業を行う場所に保存されます。

ファイルの格納場所を決定する

通常、コンテンツの作成時にはさまざまな種類のファイルが生成されます。 ファイルの格納場所を決定して、これらのファイルを効果的に管理することが重要です。

多くの場合、保存する必要があるファイルの種類は次のとおりです。

• コンテンツ ファイル: コンテンツ データまたはメタデータを含むファイル。 .pbix や Power BI Project (.pbip) ファイルなどのデータを含むコンテンツ ファイルには、秘匿性の高い情報が含まれています。 コンテンツ ファイルは、アクセスする必要があるユーザーのみがアクセスできる安全な場所に保存します。 また、コンテンツ ファイルは、Microsoft Teams のドキュメント ライブラリや Azure DevOps の Git リポジトリなど、バージョン管理をサポートする場所に保存する必要があります。 コンテンツ ファイルの例を次に示します。
  • Power BI Desktop (.pbix) ファイル
  • Power BI Project (.pbip) ファイル
  • Power BI 改ページ対応レポート (.rdl) ファイル
  • モデル メタデータ (.bim または TMDL) ファイル
  • データフロー メタデータ (.json) ファイル
• データ ソース ファイル: セマンティック モデルやデータフローなどのデータ項目によって使用されるファイル。 コンテンツはデータ ソース ファイルに直接依存しており、コンテンツを削除するとデータ更新エラーが発生するため、保存場所を慎重に検討することが重要です。 さらに、これらのファイルには秘匿性の高い情報が含まれている場合があります。 そのため、データ ソース ファイルは、他の個人によるアクセスが制限されている、セキュリティで保護されたセキュアで信頼性の高い環境に保存します。 データ ソース ファイルの例を次に示します。
  • Excel ブック、Parquet、CSV ファイルなどの構造化データ ソース。
  • JSON ファイルや XML ファイルなどの半構造化データ ソース。
  • レポートにインポートする画像などの非構造化データ ソース。
• サポート ファイル: コンテンツの作成または管理をサポートするものの、機能上は必要ないファイル。 サポート ファイルは、バージョン管理をサポートする場所、および他のツールやコンテンツ作成者がアクセスできる場所に保存する必要があります。 サポート ファイルの例を次に示します。
  • ベスト プラクティス アナライザー ルール (.json) ファイル。
  • Power BI テーマ (.json) ファイル。
  • コンテンツとクエリのソース コード ファイル。
  • カスタム視覚化 (.pbiviz) ファイル。
• テンプレートとドキュメント: セルフサービス コンテンツの作成や既存のコンテンツの記述に役立つファイル。 テンプレートとドキュメントは、使用する必要があるユーザーが簡単にアクセスできるようにする必要があります。 テンプレートとドキュメントの例を次に示します。
  • Power BI テンプレート (.pbit) ファイル。
  • 視覚化テンプレートとレポート サンプル。
  • ソリューションの設計とドキュメント。
  • ソリューションの計画とロードマップ。
  • ユーザー要求とソリューションの問題。

ファイルを保存するオプションにはさまざまなものがあります。 ファイルの種類、内容、使用方法に応じて、適切な場所を選択してください。

SharePoint Online または OneDrive

ファイルを保存するための一般的なソリューションは、SharePoint サイトを使用することです。 SharePoint はほとんどのユーザーが利用でき、Power BI と Microsoft Teams などの他の Microsoft 365 アプリケーションと高度に統合されています。 さらに、バージョン管理が組み込まれているため、ほとんどの種類のファイルを保存するのに便利です。 バージョン管理機能を使用すると、保存されているさまざまなバージョンのファイルを表示したり管理したりすることができます。

SharePoint にファイルを保存する場合は、次の点を考慮してください。

• 組織: 特定のファイルを簡単に見つけられるように、一貫性のある論理的な構造を維持するようにしてください。 適切な名前付け規則を使用し、フォルダー内のファイルを整理し、進行中のプロジェクトに関連しなくなったファイルをアーカイブします。
• OneDrive の更新: SharePoint または OneDrive for Business (職場用または学校用の OneDrive とも呼ばれます) サイトに保存されている .pbix ファイルに、公開済みのセマンティック モデルまたはレポートをリンクすることができます。 この方法で行う場合、変更を有効にするためにセマンティック モデルを公開しなくてもよくなりました。 変更は、OneDrive の自動更新 (1 時間ごとに行われる) 後に表示されます。 この方法は便利ですが、いくつかの注意事項と問題点があることに注意してください。 更新されると、簡単に元に戻すことはできません。
• プレビュー レポート: SharePoint では、Power BI Desktop をインストールしたり、.pbix ファイルをローカルにダウンロードしたりしなくても、Power BI レポートを表示することができます。 この方法でレポートを開くと、ブラウザーにレポートが表示されます。 この機能は、Fabric ポータルからレポートを表示するのに便利です。 Fabric テナント設定では、既定で有効になっています。

次の種類のファイルを SharePoint に保存することを検討してください。

• テンプレートとドキュメント: 既存のストレージ ソリューションがない場合は、SharePoint にテンプレートとドキュメントを保存します。 SharePoint は、他のユーザーにアクセス権を付与し、複雑なセットアップやプロセスなしでファイルを管理できるため、こうしたファイルの保存に最適です。
• サポート ファイル: 既存のストレージ ソリューションがない場合は、SharePoint にサポート ファイルを保存します。 ただし、一部のサポート ファイル (レポート用の Power BI テーマ .json ファイルなど) は、保存された変更を表示および管理できるバージョン管理システムに保存する方が良い場合があります。
• コンテンツ ファイル: ビジネスにとって重要でない場合や、Azure Repos などのリモート リポジトリにアクセスできない場合には SharePoint にコンテンツを保存します。
• データ ソース: サイズが小さく複雑なものに限り、SharePoint にデータ ソースを保存します。 SharePoint を使用してデータ ソース ファイルを保存する場合は、規律を守ってください。 OneLake など、他の考えられる代替手段を検討してください。

OneLake

Fabric 容量がある場合は、OneLake を使用してデータ ソース ファイルを保存することをお勧めします。 OneLake エクスプローラーを使用して、ファイルをアップロードしたり同期したりすることができます。OneLake エクスプローラーでは、Power BI などのダウンストリーム ワークロードで使用するためにファイルをテーブルに変換することができます。 大規模なデータ ソースや定期的に更新されるデータ ソースの場合は、Fabric Data Factory、または Azure Data Lake Storage (ADLS) Gen2 API または Azure Storage Python SDK を使用する他のアプリケーションを使用して、OneLake にファイルを自動的に読み込むことができます。

リモート リポジトリ

コンテンツ作成者は開発時に一定の間隔で、ローカル コンピューターから Azure Repos Git リポジトリ—などのリモート リポジトリに作業をコミットして保存することができます。 リモート リポジトリにはソリューションの最新バージョンが格納されており、開発チームの全員がアクセスできます。 通常、リモート リポジトリを使用すると、Teams、SharePoint、または OneDrive するよりも高度なライフサイクル管理を行えます。 これは、リモート リポジトリを使用するコンテンツ作成者は、ファイルで共同作業を行ったり、ファイルの変更を追跡および管理したりするためのより高度なオプションを利用できるためです。 たとえば、コンテンツ作成者はリモート リポジトリの独自のブランチで作業して変更を加え、準備ができたらそれらの変更をメイン ブランチにマージするように要求できます。

次の種類のファイルをリモート リポジトリに保存することを検討してください。

• テンプレートとドキュメント: Azure DevOps などの関連サービスを使用してプロジェクトを管理する場合には、リモート リポジトリにテンプレートとドキュメントを保存します。
• サポート ファイル: 変更を簡単に追跡および管理できる場合には、サポート ファイルをリモート リポジトリに保存します。
• コンテンツ ファイル: ビジネスにとって重要な場合や、同じコンテンツで他の開発者と共同作業を行う場合には、コンテンツをリモート リポジトリに保存します。 リモート リポジトリは、コンテンツの変更を追跡し、コラボレーションを促進するのに最適です。

ファイルなし: Fabric ポータルで作成されたコンテンツ

コンテンツ作成者は、Fabric ポータルでコンテンツを直接作成できます。 このシナリオでは通常、コンテンツ ファイルを直接操作することはありません。 通常、Fabric ポータルでコンテンツを作成するのは、アイテムの種類を他の場所 (データフロー、ダッシュボード、スコアカードなど) で作成できない場合に限られます。 Windows マシンにアクセスできず、Power BI Desktop を使用できない場合は、Fabric ポータルでレポートとセマンティック モデルを作成することもできます。 詳細については、「ユーザーのツールとデバイス」を参照してください。

チェックリスト - コンテンツを計画および設計する場合、主な決定事項とアクションは次のとおりです。

関連するコンテンツ

このシリーズの次の記事では、コンテンツ ライフサイクルの管理の要素としてコンテンツを開発し、変更を管理する方法について説明します。