次の方法で共有

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

  • [アーティクル]

Note

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

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

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

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

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

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

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

Note

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

ヒント

この記事では、ライフサイクル管理に関連するコンテンツの計画と設計に関する主な考慮事項と決定事項について説明します。

  • Fabric または Power BI ソリューション を効果的に計画および設計する方法の詳細については、ソリューション計画の記事を参照することをお勧めします。
  • Power BI への移行を効果的に計画する方法の詳細については、Power BI 移行シリーズを参照することをお勧めします。

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

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

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

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

Note

要件と同様に、こうした質問に対する回答は、ソリューションの開発時、またはそのライフサイクルの後半になって変わってくる場合があります。 こうした質問に回答した後、コンテンツに変更を加えたときや、サービスを提供するユーザーの数がスケールインしたときに定期的に再評価するようにしてください。

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

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

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

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

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

ヒント

コンテンツの形式を説明するアーキテクチャ図を作成することを検討してください。 さまざまなデータ ソース、項目の種類、コンテンツ コンシューマー、およびこれらの個別のコンポーネント間のリレーションシップを含めることができます。 アーキテクチャ図を作成すると、コンテンツとその複雑さを簡潔に表現することができ、ライフサイクル管理を計画するのに役立ちます。 Fabric アイコンや Azure アイコンを使用して、これらの図を作成することができます。 または、アイコンと描画ツールが付属している Azure Diagrams を使用して、これらの図を作成することもできます。

このような図の例については、Power BI 実装計画使用シナリオ図を参照してください。

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

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

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

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

重要

コンテンツの作成を担当するユーザーと、運用環境に展開されたコンテンツをサポートするユーザーについてわかりやすく説明する文書を作成してください。 これらの人すべてにコンテンツ ライフサイクル管理計画に関与してもらいます。

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

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

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

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

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

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

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

ヒント

コンテンツ作成者が独立して作業する場合でも、Microsoft Teams や Azure DevOps などのツールを使用して作業を計画し、構造化することにはメリットがあります。

Microsoft Teams

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

図は、Microsoft Teams を使用した共同作業に関するアプローチ 1 を示しています。図に示す項目については、次に説明されています。

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 を使用した共同作業に関するアプローチ 2 を示しています。図に示す項目については、次に説明されています。

Note

Azure DevOps は、Power BI と Fabric と統合してコンテンツ ライフサイクル管理の計画や調整に役立つようにする一連のサービスです。 このように Azure DevOps を使用する場合は通常、次のサービスを利用します。

  • Azure Repos: コンテンツ変更を追跡および管理するために使用するリモート ストレージの場所であるリモート Git リポジトリを作成して使用できるようにします。
  • Azure Pipelines: コンテンツを処理およびテストし、リモート リポジトリからワークスペースに展開する一連の自動化されたタスクを作成して使用できるようにします。
  • Azure Test Plans: ソリューションを検証し、Azure Pipelines と共に品質管理を自動化するテストを設計できるようにします。
  • Azure Boards: ボードを使用して、タスクや計画を作業項目として追跡したり、他の Azure DevOps サービスの作業項目をリンクまたは参照したりできるようにします。
  • Azure Wiki: このチームと情報を共有して、コンテンツを理解し、それに貢献できるようにします。

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

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

ヒント

一元化コンテンツ配信による エンタープライズ シナリオでは、Azure DevOps を使用して効果的なコンテンツ ライフサイクル管理を行うことをお勧めします。 Microsoft Teams や SharePoint を使用した共同作業よりも大規模なシナリオや複雑なシナリオでは、Azure DevOps または同様のツールを使用した共同作業をお勧めします。 堅牢なコラボレーションと自動化のためにより多くのツールとオプションが使えるようになるからです。

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

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

Note

これらのサービスを統合する方法はいくつもあり、Microsoft Teams を Azure DevOps と共に使用することもできます。 たとえば、Azure Boards を表示および管理したり、Microsoft Teams 内から Azure Pipelines のイベントを監視したりできます。

最も重要なのは、チームのニーズと作業方法に最適な、コラボレーションを促進するツールとサービスを使用することです。

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

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

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

ヒント

ファイルは、複数のチーム メンバーがアクセスでき、変更を簡単に追跡できる (バージョン管理と呼ばれます) 場所に保存します。 こうすれば、チーム メンバーの移動やファイルの損失によって作業の中断が発生することはありません。

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

  • コンテンツ ファイル: コンテンツ データまたはメタデータを含むファイル。 .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) ファイル。
    • 視覚化テンプレートとレポート サンプル。
    • ソリューションの設計とドキュメント。
    • ソリューションの計画とロードマップ。
    • ユーザー要求とソリューションの問題。

注意事項

.pbix ファイルや .pbip ファイルなどの一部のコンテンツ ファイルには、データ ソースからインポートされた秘匿性の高いデータを含めることができます。 さらに、TMDL ファイルや .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 テナント設定では、既定で有効になっています。

ヒント

Microsoft Teams を使用して共同作業する場合は、チャネル ドキュメント ライブラリにファイルを保存することを検討してください。 この方法により、ファイルを一元化し、コラボレーションをしやすくことができます。

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

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

注意事項

適切なデータ アーキテクチャの代替手段として SharePoint を使用することはしないでください。 SharePoint にデータ ソース ファイルを保存することは一部の限られたシナリオでは便利ですが、この方法は、大規模で複雑なデータ ソースがある場合や、データの待ち時間を短縮する必要がある場合には当てはまりません。

警告

個人用ファイル システムや個人用 OneDrive アカウントを使用してファイルを保存しないでください。 所有者が組織を離れた場合、こうしたファイルを使用できなくなります。

OneLake

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

注意事項

OneLake からファイルをアップロードまたはダウンロードするような操作では、Fabric 容量ユニットを使用します。 容量メトリックを監視し、大きなファイルの不要な移動によって引き起こされる容量の負担を回避するための手順を実行する必要があります。

さらに、ユーザーが OneLake エクスプローラーを使用してアクセスしたファイルは、偶発的な変更や損失に対して脆弱です。 Bus Critical ソリューションには OneLake エクスプローラーを使用しないことをお勧めします。

警告

OneLake エクスプローラーには、いくつかの重要な 制限事項と考慮事項があります。 たとえば、OneLake では、SharePoint や OneDrive などのファイルのバージョン管理はサポートされていません。 ファイルを保存する場所を決定する際には、これらの考慮事項と制限事項を考慮してください。

ヒント

OneLake にデータを保存する場合は、データ損失のリスクを軽減するために、事業継続とディザスター リカバリー (BCDR) を有効にすることを検討してください。 BCDR を有効にすると、Azure の標準リージョンのペアリングに従って、データが複製され、2 つの別々の地理的リージョンに保存されます。

リモート リポジトリ

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

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

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

ヒント

リモート リポジトリを使用する場合は、 Power BI レポートとセマンティック モデルを .pbix ファイルとしてではなく Power BI Desktop プロジェクト (.pbip) ファイルとして保存することを検討してください。 これは、.pbix ファイルでは保存された変更を識別できないためです。

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

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

注意事項

Fabric ポータルで作成された一部のコンテンツは、ファイルとしてダウンロードすることができません。 たとえば、Fabric ポータルで作成されたレポートを .pbix ファイルとしてダウンロードすることはできません。

Fabric ポータルでコンテンツを作成するときは、代わりに Fabric API か Git 統合を使用して、コンテンツ定義をバックアップしてください。 コンテンツ定義をバックアップすると、コンテンツが誤って削除されたり、意図せずに変更されたりした場合の中断を軽減することができます。 コンテンツが誤って削除または変更された場合、バックアップを使用して置き換えることができます。

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

  • ソリューション計画を実行する: ビジネス要件と技術要件を収集して、コンテンツの対象となる問題を十分に理解し、このコンテンツによってどのように問題に対処するかを設計します。
  • コンテンツを作成するユーザーを特定する: 個々のコンテンツ作成者のワークフロー、スキル、ニーズに応じて、ライフサイクル管理のさまざまなアプローチが必要になる場合があります。
  • 複数のコンテンツ作成者が共同作業を行う必要があるかどうかを特定する: 共同作業を行うコンテンツ作成者が、バージョン管理をサポートするファイルの種類 (.pbip ファイルなど) を使用していることを確認します。
  • コンテンツ作成者の共同作業方法を決定する: どの程度高度なコラボレーションを行うかを決定します。 さらに、Microsoft Teams や Azure DevOps を使用するなど、このコラボレーションを行う方法を決定します。
  • コラボレーション ツールを設定する: ソリューションやプロジェクトに必要な初回セットアップを実行していることを確認します。 これらのツールを使用してどのようにコラボレーションを管理するかについて、重要な決定を下します。
  • SharePoint や OneLake にデータ ソース ファイルを保存する: SharePoint に小さくてシンプルなデータ ソース ファイルを保存します。 それ以外のファイルについては、代わりに OneLake や ADLSGen2 (使用可能な場合) を使用します。
  • SharePoint またはリモート リポジトリにコンテンツとサポート ファイルを保存する: シンプルかつ小規模なプロジェクトでほとんどのファイルが整理されていて、適切なアクセス管理を実践している場合には、SharePoint を使用します。 大規模な環境や並列コラボレーションが必要な場合には、リモート リポジトリの使用を検討してください。リモート リポジトリを使用すると、コンテンツの変更が詳細に表示されます。
  • SharePoint にテンプレートとドキュメントを保存する: 他のユーザーが簡単にテンプレートとドキュメントを検索、使用、理解できるようになっていることを確認します。
  • 開発と展開の計画: この最初のステージの最後に、主要な領域に注意を向けて初期セットアップを行うための具体的な計画を実行します。 たとえば、ツールを確定し、データ ソース接続をテストします。

関連するコンテンツ

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