Power BI 実装計画: コンテンツの計画と設計

注

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

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

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

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

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

次の図は、Power BI コンテンツのライフサイクルを示しています。ステージ 1 では、コンテンツの計画と設計が行われます。

注

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

ヒント

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

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

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

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

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

ソリューションを設計するときは、コンテンツの内容、コンテンツを作成するユーザー、サポートするユーザー、およびこのコンテンツが組織にとってどれほど重要であるかを説明する必要があります。 これらの要因は、ソリューション設計の一部として要件を 収集 する間、または完了した後に対処する必要があります。

注

要件と同様に、これらの質問に対する回答は、ソリューションの開発時、またはそのライフサイクルの後半で変更される可能性があります。 これらの質問に回答したら、コンテンツに変更を加えたとき、またはサービスを提供するユーザーの数に応じて定期的に再評価するように準備します。

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

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

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

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

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

ヒント

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

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

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

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

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

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

Von Bedeutung

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

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

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

次のような質問に答えて、コンテンツが重要かどうかを判断するのに役立ちます。

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

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

ユーザーがコンテンツを使用する方法を決定する

Power BI では、セマンティック モデルやレポートなど、ユーザーがコンテンツを使用するさまざまな方法があります。 ユーザーがこのコンテンツにアクセスして使用する方法に応じて、その設計と開発方法についてさまざまな決定を行う必要があります。 これらの決定の中には、コンテンツの作成方法と、それにかかる時間と労力の両方が大幅に変更される場合があります。 通常、ユーザーがモデルとレポートを使用する方法が異なるほど、留意すべき考慮事項が多くなり、結果として得られる開発コストが高くなります。

セマンティック モデルの使用と再利用

セマンティック モデルは間違いなく、Power BI と Fabric で最も重要な項目の種類です。ユーザーは、さまざまなダウンストリームのアプローチと項目を使用してそれらを使用できるためです。 レポートのみを配布する場合は、ユーザーがさまざまな項目をモデルに接続して独自の分析を行ったり、独自の目標を達成したりする場合とまったく異なる設計上の決定を行います。

次のダウンストリーム項目の種類を使用して、共有セマンティック モデルを再利用できます。

• Power BI

  • レポート
  • ページ分割されたレポート
  • スコアカード
  • Excel (Excel ピボット テーブルで分析)
  • セマンティック モデル (複合モデル)

• Microsoft Fabric

  • アクティベーター (以前の反射)
  • AI スキル
  • コパイロット
  • 探検
  • 指標セット
  • ノートブック ( セマンティック リンク と セマンティック リンク ラボ ライブラリを使用)

次のセクションでは、これらの項目の一部でセマンティック モデルを使用する場合の重要な考慮事項の概要について説明します。

注

これらのオプションの多くは、関連するテナント設定を有効にした場合にのみ使用できます。 セマンティック モデルを発行するワークスペースで可能な消費方法を把握するために、テナント設定について理解していることを確認します。 これらのオプションが特定のセキュリティ グループに限定されている場合は、ユーザーがこれらのセキュリティ グループに属しているかどうか (または属する必要があるかどうか) を確認してください。

報告書

ユーザーがレポートを介してセマンティック モデルを使用するには、いくつかの方法があります。

• レポートの表示。 配布または共有するレポート内のデータをユーザーが表示する標準シナリオ。
• セマンティック モデルに接続し、新しいレポートを作成する。 ビルドアクセス許可を使用すると、ユーザーは Power BI Desktop または Power BI サービスで新しいレポートを作成できます。 このレポートには、共有セマンティック モデルへのライブ接続があります。 ユーザーは、DirectQuery を使用して元のレポートを照会する新しい複合セマンティック モデルにライブ接続レポートを変換することもできます。
• 既存のレポート ビジュアルから分析を作成する。 ビルドアクセス許可を持つユーザーは、 サポートされているビジュアル を選択して、そのデータの探索を作成することもできます。 これにより、ユーザーがフィールドを追加したり、書式設定を変更したりできる新しい探索項目が作成されます。 ユーザーは、 ライセンス、ワークスペース メンバーシップ、およびアイテムのアクセス許可に必要な条件を満たしている場合に、結果の探索を保存して共有できます。
• ユーザーがフィールドと書式設定を変更できるレポート ビジュアルのカスタマイズ。ビジュアルのカスタマイズは 探索と同様に機能しますが、読み取りアクセス許可のみが必要であり、新しい項目は作成されません。 ビジュアルのカスタマイズでは、ユーザーがレポート ページに適用するパースペクティブも使用されます。これによって、ユーザーが表示および使用できる使用可能なフィールドが制限されます。

これらのさまざまなシナリオでは、セマンティック モデルに関して留意する必要がある考慮事項がいくつかあります。次に例を示します。

• ユーザーに付与するアクセス許可と、これらのアクセス許可を管理する方法。 ビルドのアクセス許可を取得する前に、ユーザーがトレーニングを完了することをお勧めします。
• パースペクティブを モデルに追加 するかどうか。 パースペクティブを追加できるのは、 Power BI Desktop の TMDL ビューを使用するか、他のサード パーティ製ツールを使用することだけです。 ユーザーがカスタマイズビジュアルまたは複合モデルを使用する場合は、パースペクティブを追加することをお勧めします。
• モデルで非表示にする必要があるフィールドと、テーブルの IsPrivate TOM プロパティを有効にして、それらのフィールドまたはその子オブジェクトが候補として表示されないようにする必要があるかどうか。 Private TOM プロパティは、モデル メタデータ ファイル (.bim や .tmdl など) または Power BI サービスで公開されているリモート モデルの外部ツールを使用してのみ設定できることに注意してください。
• モデルを文書化する方法と、そのドキュメントに必要なもの。 特定のユース ケースに合わせたドキュメントを作成し、関連する有用な情報を含め、DAX メジャー式などのモデル メタデータのエクスポートは含めないことをお勧めします。これは、一般的にエンド ユーザーには役に立ちません。
• ユーザーに対して、別の方法よりも 1 つのアプローチを選択するようアドバイスする方法。

注意事項

セマンティック モデルに対する読み取りまたはビルドのアクセス許可を付与すると、ユーザーは、このセクションで説明する方法を使用して、モデル内の任意のテーブルまたは列に対してクエリを実行できる場合があります。 これは、レポートでそのテーブル、メジャー、または列を公開しない場合でも当てはまります。 データ セキュリティを使用して機密データを常に保護するか、モデルから除外してください。 そうすることで、間違ったユーザーに機密情報が意図せずに公開されるのを回避できます。

Excel (Excel ピボット テーブルで分析)

ユーザーがモデルに対するビルド権限を持っている場合は、 Excel からセマンティック モデルに接続 し、Excel ピボット テーブルの MDX を使用してクエリを実行することもできます。 これは、ユーザーが Excel で作業してデータ自体を探索または分析する場合に便利です。

Excel で分析を使用してセマンティック モデルのクエリを実行する場合は、次の点を考慮する必要があります。

• フィールド パラメーターやメジャー動的書式指定文字列などの特定の機能は、Power BI でのみ機能し、Excel では機能しません。 同様の結果を得るには、他の方法を使用する必要があります。
• Excel で分析するには、列プロパティ IsAvailableinMDX が有効になっている必要があります。 ユーザーが Excel を使用しない場合、このプロパティを無効にすると、モデルが小さくなり、パフォーマンスが高くなる可能性があります。
• ユーザーは、Power BI Desktop の場合と同様に、セマンティック モデルで 非表示の列やメジャー を表示できません (データ ウィンドウを右クリックし、[非表示に表示] を選択します)。
• ユーザーは、Power BI Desktop からのライブ接続を使用する場合と同様に、Excel で独自のメジャーや ビジュアル計算 を作成することはできません。 ただし、他の Excel セルやワークシートのピボット テーブル フィールドを参照して、カスタム計算を行うことができます。
• Excel で分析するユーザーは、多くの場合、その使用方法に関する追加のトレーニングを必要とします。 これは、エクスポートのようなエクスペリエンスが必要な場合や、データのオフライン コピーを保存する意図を表している場合に特に当てはまります。 次のような点についてユーザーをトレーニングすることを検討してください。
  • データを更新する方法。
  • ピボット テーブルにフィールドを追加する 前に 、データをフィルター処理します。
  • フィルターを使用せずに大規模で詳細なクエリを回避する。
  • Power BI Desktop は Excel で分析するよりもパフォーマンスが高くなります。Excel で分析すると、MDX を使用してモデルがクエリされますが、Power BI Desktop では DAX を使用してモデルに対してクエリが実行されるためです。
  • Excel を好みどおり活用しながら、ガバナンスやセキュリティのリスクを生み出さないようにする方法。

Copilot と AI スキル

ユーザーがモデルに対する読み取りアクセス許可を持っている場合は、自然言語を使用して 、Copilot を使用してデータについて調べて質問できます。 または、 AI スキルのデータに関するデータの質問をすることもできますが、Copilot とは異なり、最初にこの項目を作成して共有する必要があります。

ユーザーが自然言語を使用してセマンティック モデルを操作する場合、モデルの設計と実装にはかなりの影響があります。

• 言語スキーマ: 適切な英語の単語と用語が正しいモデル オブジェクトに関連付けられるように、モデルにシノニムとリレーションシップを追加する必要があります。
• 名前付け規則: AI に優しい英語の名前付け規則を使用する必要があります。 つまり、組織内で標準のフィールド名、頭字語、記号、および省略形が重複または過度に類似しないようにする必要があります。
• プロパティ： AI ツールでこれらのフィールドをより適切に認識して使用できるように、列やメジャーの説明、データ カテゴリなどのプロパティを設定する必要があります。
• フィールドの非表示: Copilot に公開したり、応答で使用したりしたくないフィールドを非表示にする必要があります。

また、ユーザーのトレーニングに追加の労力を費やす必要もあります。

• Copilot または AI スキルでできることとできないこと。
• Copilot または AI スキルを使用して、別の (AI 以外の) アプローチでデータを探索する場合。
• 効果的なプロンプトを記述する方法。
• 出力を検証する方法。
• 予期しない出力をトラブルシューティングする方法。

ヒント

Copilot で適切に動作するようにモデルを最適化する場合のその他の詳細なヒントと考慮事項については、次の記事を参照してください。

• レポート作成者とモデル コンシューマーの最適化
• Power BI 用 Copilot で適切に動作するようにデータ モデルを更新する
• Copilot を使用して DAX クエリを記述する

Copilot やその他の生成 AI テクノロジには、コンテンツの計画と設計の段階でも理解しておく必要がある重要な制限事項と考慮事項があります。

• これは非決定的です。つまり、同じコンテキストで同じ入力が異なる出力を生成する可能性があります。
• ツールが誤った情報を生成したり、特定の事実の重要性を誇張したりする場合など、低品質または不正確な出力を得ることができます。 また、省略によって、Copilot が不正確または不正確になる可能性もあります。この場合、重要な情報は除外されます。
• ツールはトレーニング データによって制限されるため、より新しい情報に関する質問は有用な出力を生成する可能性が低くなります。

注意事項

これらの制限事項と考慮事項のリスクを軽減する必要があります。 Copilot、AI スキル、LLM、および生成 AI は新しいテクノロジであるため、自律的、高リスク、またはビジネスクリティカルなプロセスや意思決定に使用しないでください。 詳細については、 大規模言語モデルのセキュリティ ガイダンスも参照してください。

改ページ対応レポート

セマンティック モデルの DAX クエリを記述して、クエリ結果を含むページ分割されたレポートを作成できます。 これは、ユーザーがページ分割されたレポートを必要とし、セマンティック モデルをデータ ソースとして使用する場合に関連します。

セマンティック モデルでページ分割されたレポートを作成する場合は、次の点を考慮する必要があります。

• Power BI Desktop の DAX クエリ ビューやその他のサード パーティ製ツールを使用して、DAX クエリを記述および管理する方法。
• モデル列やテーブル内の特定のデータの具体化など、クエリ時にセマンティック モデルがパフォーマンスを発揮するように設計上の決定を行う必要があるかどうか。
• ページ分割されたレポート ビジュアルを使用して、ページ分割レポートを対話型の Power BI レポートに埋め込むかどうか。
• ページ分割されたレポートとその他のレポートの間に冗長性がないことを確認する方法。
• ページ分割されたレポートを配布する必要がある形式と、それらの出力がガバナンスまたはセキュリティ リスクにならないように保護するために秘密度ラベルまたはデータ損失防止が必要かどうか。

その他

セマンティック モデルを使用する他の方法もあります。 いくつかの例を次に示します。

• アクティベーター (以前の反射): セマンティック モデルを使用して、データ アラートを自動化し、Power Automate を使用して作成したフローなどのダウンストリーム フローをトリガーできます。
• メトリック セット: メトリック セットを作成できます。これには、複数のセマンティック モデルからのメジャーと推奨ディメンションが 1 か所に含まれます。 メトリック セットを使用すると、ユーザーのデータ検出を向上させることができます。
• 探検： レポートと Copilot 出力から探索を作成する以外に、ユーザーはセマンティック モデルから探索を作成することもできます。

レポートの配布と共有

Power BI レポートの 配布方法と共有 方法に応じて、異なる設計の選択を行います。 たとえば、レポート間のドリルスルーは、ユーザーが同じワークスペースまたはアプリ内のレポート間を移動できるようにする機能です。 ただし、レポートを埋め込んだり、Publish-to-Web でパブリックに共有したりする場合は、レポート間のドリルスルーを使用できません。

その他の項目

ユーザーがコンテンツと基になるデータをどのように使用するかに応じて、Power BI または Fabric の他の項目の種類に目を向ける必要がある場合があります。 たとえば、ユーザーが独自のデータと計算を追加する場合、セマンティック モデルで複合モデルを使用できます。 または、データフローなどの新しいモデルで使用するために、他の一元化されたデータ項目を作成することもできます。

作成したコンテンツをユーザーが使用する方法を決定したら、次に、開発中にコンテンツ作成者が共同作業を行う方法を決定する必要があります。

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

ソリューションの範囲と複雑さが増すにつれて、複数のコンテンツ作成者と所有者が共同作業を行う必要が生まれる場合があります。 複雑なソリューションを作成する場合は、コラボレーションの構造、管理、サポートに役立つ効果的なツールを使用することをお勧めします。 Microsoft Teams、Azure DevOps、GitHub を使用するなど、Power BI コンテンツを生成するときに共同作業を行う方法は多数あります。

ヒント

コンテンツ作成者が独立して作業する場合でも、Microsoft Teams、Azure DevOps、GitHub などのツールを使用して作業を計画し、構造化することでメリットを得ることができます。 これは、Microsoft Teams ドキュメント ライブラリから OneDrive Refresh を使用する場合や、Azure DevOps または GitHub リポジトリからの Git 統合 を使用するなど、コンテンツをデプロイする方法を計画する場合に特に重要です。

Microsoft Teams

小規模またはシンプルなプロジェクトでは、コンテンツ作成者は 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 または GitHub Enterprise

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

注

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

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

ヒント

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

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

• 作業の範囲と、コンテンツ ブランチの作成、名前付け、および使用方法。
• 作成者が変更をグループ化してコミットし、コミット メッセージで記述する方法。
• pull request を使用して変更を確認および承認する責任者。
• プルリクエストのマージ競合がどのように解決され、誰がそれを解決するか。
• 異なるブランチで行われた変更を 1 つのブランチにマージする方法。
• コンテンツのテスト方法と、コンテンツを展開する前にテストを実行するユーザー。
• 変更を開発、テスト、運用のワークスペースにデプロイする方法とタイミング。
• ソリューションの変更またはバージョンをデプロイする方法とタイミングをロールバックできます。

GitHub

コンテンツ作成者と所有者は、 GitHub (クラウド バージョンのみ) と GitHub Enterprise を使用して通信および共同作業を行うこともできます。 Azure DevOps と同様に、GitHub には、Power BI または Fabric 環境の側面の調整と管理に役立つサービスを備えたプラットフォームが用意されています。

Azure DevOps と GitHub の主な違いは、Azure DevOps にはソフトウェア開発ライフサイクルを管理するための一連のツールが用意されていますが、GitHub では主に Git リポジトリのホスト、ソース管理、コードでのコラボレーションに重点を置いています。 Git 統合を使用して コンテンツをデプロイ する予定の場合は、主に GitHub を使用します。 さらに、GitHub を使用して 、パブリックなオープンソース リポジトリ からワークスペースにコンテンツを同期できます。

GitHub との Git 統合を使用するには、管理者テナント設定を有効にする必要があります 。ユーザーは、ワークスペース項目を GitHub リポジトリと同期できます。

注

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

ここに記載されていない他のツールを使用して、共同作業やコンテンツの計画を立てることもできます。 最も重要なのは、コラボレーションを促進するツールとサービスを使用し、チームのニーズと作業方法に最も適していることです。

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

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

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

ヒント

複数のチーム メンバーがアクセスできるファイルと、変更を簡単に追跡できる場所 ( バージョン管理と呼ばれます) を格納します。 この方法により、チーム メンバーの退出やファイルの損失が中断を招くことはありません。

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

• コンテンツ ファイル: コンテンツ データまたはメタデータを含むファイル。 .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 ファイルなどの半構造化データ ソース。
  • レポートにインポートする画像などの非構造化データ ソース。
• サポート ファイル: コンテンツの作成または管理をサポートしているが、機能するために必要ではないファイル。 サポート ファイルは、バージョン管理をサポートする場所、および他のツールやコンテンツ作成者がアクセスできる場所に格納する必要があります。 サポート ファイルの例を次に示します。
  • Power BI テーマ (.json) ファイル。
  • Power BI レポートの画像 (.png、.jpg、または .gif) ファイル。
  • ベスト プラクティス アナライザー ルール (.json) ファイル。
  • コンテンツとクエリのソース コード ファイル。
  • カスタム視覚化 (.pbiviz) ファイル。
• テンプレートとドキュメント: セルフサービス コンテンツの作成に役立つファイル、または既存のコンテンツを記述するファイル。 テンプレートとドキュメントは、使用する必要があるユーザーが簡単にアクセスできる必要があります。 テンプレートとドキュメントの例を次に示します。
  • Power BI テンプレート (.pbit) ファイル。
  • 視覚化テンプレートとレポートの例。
  • ソリューションの設計とドキュメント。
  • ソリューションの計画とロードマップ。
  • ユーザー要求とソリューションの問題。

注意事項

.pbix ファイルや .pbip ファイルなどの一部のコンテンツ ファイルには、データ ソースからインポートされた機密データを含めることができます。 さらに、メタデータ ファイルには、機密情報や場合によってはデータ ポイントを含めることもできます。 その例として、レポート メタデータと .pbit テンプレートがあり、特定の状況で列の値を含めることができます。 これらのファイルを安全な場所に保存するために必要な予防措置を講じ、効果的な データ損失防止を実践してください。

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

SharePoint Online または OneDrive

ファイルを格納するための一般的な解決策は、 SharePoint サイトを使用することです。 SharePoint は、ほとんどのユーザーが広くアクセスでき、Power BI や他の Microsoft 365 アプリケーション (Microsoft Teams など) の両方と高度に統合されています。 さらに、 バージョン管理が組み込まれているため、ほとんどのファイルの種類を格納するのに便利です。 バージョン コントロールを使用すると、保存されているさまざまなバージョンのファイルを表示および管理できます。

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

• 組織: 特定のファイルを簡単に見つけられるように、一貫性のある論理的な構造を維持してください。 適切な名前付け規則を使用し、フォルダー内のファイルを整理し、進行中のプロジェクトに関連しなくなったファイルをアーカイブします。
• OneDrive の更新: 発行されたセマンティック モデルまたはレポートを、SharePoint または OneDrive for Work または School サイトに格納されている .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 にデータ ソース ファイルを格納すると、一部の限られたシナリオでは便利ですが、この方法は、大規模で複雑なデータ ソースがある場合や、データ待機時間を短くする必要がある場合にはスケーリングされません。

Warnung

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

OneLake

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

注意事項

OneLake からのファイルのアップロードやダウンロードなどのアクションでは 、Fabric 容量ユニットが消費されます。 容量メトリックを監視し、大きなファイルの不要な移動による容量の負担を回避するための手順を実行する必要があります。

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

Warnung

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

ヒント

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

リモート リポジトリ

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

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

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

ヒント

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

また、 レポートには Power BI 拡張レポート形式 (PBIR) を使用することを検討してください。 PBIR 形式を使用すると、レポート メタデータの読み取りが容易になり、ソース管理での変更の追跡と管理が容易になります。 さらに、この形式を使用するレポートは、 Semantic-link-labs などのプログラム ツール (Fabric ノートブックで使用できる Microsoft の Python ライブラリ) によって、より簡単に管理できます。

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

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

注意事項

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

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

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

• ソリューション計画の実施: ビジネス要件 と 技術的要件 を収集して、コンテンツが対処する問題を十分に理解し、このコンテンツが問題にどのように対処するかを設計します。
• コンテンツを作成するユーザーを特定する: 個々のコンテンツ作成者のワークフロー、スキル、ニーズに応じて、ライフサイクル管理のさまざまなアプローチが必要になる場合があります。
• 複数のコンテンツ作成者が共同作業を行う必要があるかどうかを特定する: 共同作業を行うコンテンツ作成者が、バージョン管理をサポートするファイルの種類 (.pbip ファイルなど) を使用していることを確認します。
• コンテンツ作成者が共同作業を行う方法を決定する: コラボレーションの高度さを決定します。 さらに、Microsoft Teams、Azure DevOps、GitHub などを使用して、このコラボレーションを容易にする方法を決定します。
• コンテンツの形式を決定する: Power BI セマンティック モデルとレポートが .pbix ファイルまたは .pbip ファイル (またはモデルの場合は .bim や .tmdl などの他の形式) で構成されるかどうか、およびレポートで PBIR 形式を使用するかどうかを決定します。
• コンテンツの使用方法を決定する: ユーザーがデータに関わる方法を評価します。 消費をサポートするために作成する必要がある項目の種類と、ユーザーが読み取りアクセス許可のみを必要とするか、基になるセマンティック モデルまたはその他のデータ項目に対するアクセス許可を構築するかを決定します。 ユーザーがビルドアクセス許可を必要とする場合は、セマンティック モデルを使用する方法と、これを効果的に行う方法を早期に決定します。
• コラボレーション ツールを設定する: ソリューションまたはプロジェクトに必要な初回セットアップを確実に実行します。 これらのツールを使用してコラボレーションを管理する方法について重要な決定を下します。
• SharePoint または OneLake にデータ ソース ファイルを格納する: SharePoint に小規模で単純なデータ ソース ファイルを格納します。 それ以外の場合は、代わりに OneLake または ADLSGen2 (使用可能な場合) を使用します。
• SharePoint、Microsoft Teams、または Git リポジトリにコンテンツとサポート ファイルを格納する: よりシンプルで小規模なプロジェクトの場合は、SharePoint を整理し、適切なアクセス管理を実践する場合は、ほとんどのファイルに SharePoint を使用します。 大規模な環境や並列コラボレーションが必要な場合は、GitHub または Azure DevOps で Git リポジトリを使用することを検討してください。GitHub または Azure DevOps では、コンテンツの変更を詳細に把握できます。
• Microsoft Teamsまたは SharePoint にテンプレートとドキュメントを保存する: これらのテンプレートとドキュメントは、ユーザー コミュニティを対象としています。 テンプレートとドキュメントを他のユーザーが簡単に検索、使用、理解できるようにします。
• 開発とデプロイの計画: この最初のステージを終了するには、 主要な領域に対処 し、 初期セットアップを行うための特定の計画を実行します。 たとえば、ツールを確立し、データ ソース接続をテストします。

関連コンテンツ

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