Power BI 実装計画: BI ソリューション計画

この記事は、ビジネス インテリジェンス (BI) 戦略をサポートするソリューションを計画するために役立ちます。 主な対象者は次のとおりです。

• BI および分析のディレクターまたはマネージャー: BI プログラムと戦略的に重要な BI ソリューションの監督を担当する意思決定者。
• センター オブ エクセレンス (COE)、IT、BI チーム: 組織のエンタープライズ BI ソリューションを設計および展開するチーム。
• 領域の専門家 (SME)、コンテンツの所有者と作成者: 部門の分析を支持し、セルフサービス、部門 BI、またはチーム BI の使用シナリオ向けソリューションを設計および展開するチームと個人。

BI 戦略は、データと分析を実装、使用、管理するための計画です。 BI 戦略を定義するには、まず BI の戦略的計画から始めます。 戦略的な計画は、BI の重点分野と目標を特定するのに役立ちます。 BI の目標に向けて進むパスを決定するには、戦術計画を使って具体的な主要な成果を記述します。 次に、BI ソリューションを計画し、展開することで、これらの主要な成果に向けて進捗状況を達成します。

BI ソリューションを計画して実装するには、多くの方法があります。 この記事では、BI 戦略をサポートする BI ソリューションを計画および実装するために実行できるアプローチの 1 つについて説明します。

次の概要図は、BI ソリューション計画を実施する方法を示しています。

BI ソリューションの計画を実施するには、次の手順を実行します。

詳細については、Power BI の移行シリーズを参照してください。 このシリーズは移行に関するものですが、主なアクションと考慮事項はソリューション計画に関連しています。

手順 1: 要件を収集する

ソリューション計画を開始するには、まず要件を収集し、ソリューション設計を定義します。

注: 戦略および戦術計画は "作業チーム" が主導し、このイニシアティブも主導します。 これに対し、ソリューション計画は、コンテンツの所有者と作成者で構成される "プロジェクト チーム" が主導します。

ソリューションの展開と導入を成功させるには、適切な要件を収集することが重要です。 要件を収集する効果的な方法は、適切な関係者を特定して関与させ、解決すべき問題を共同で定義し、その共有された理解を使ってソリューション設計を作成することです。

コラボレーション アプローチを使って要件を収集する利点をいくつか次に示します。

• ユーザーの意見からより有用な設計が生まれる: 焦点を絞ったディスカッションにユーザーに参加してもらい、要件を収集することで、ビジネス データのニーズをより効果的に取り込むことができます。 たとえば、ユーザーは既存のソリューションをどのように使っているかをコンテンツ作成者に実演し、これらのソリューションの認識された有効性についてフィードバックを提供できます。
• 前提を避け、変更要求を軽減する: ユーザーとのディスカッションによって、微妙な違い、例外、隠れた複雑さが明らかになることはよくあります。 後期に要求あると対処にかかるコストが高くなる可能性がありますが、これらの分析情報によってその可能性を軽減できます。
• ユーザーをオンボーディングすることでソリューションの導入率を上げる: 設計と初期開発にユーザーを関与させることで、最終的な結果に影響を与える機会を提供します。 また、ユーザーが関与することで、ソリューションに対する知的財産の所有権とアカウンタビリティを理解することもできます。 関与度が高いユーザーは、ソリューションを支持し、効果的に使用できるようにその実践共同体を主導する可能性が高くなります。
• 設計によって関係者とビジネス ユーザーに期待感を与える: ソリューション設計のモックアップやイラストを作成することで、関係者にソリューションが何を提供するかを明確に示すことができます。 また、想定されるプロジェクトの結果について相互理解を深めることにも役立ちます。 このプロセスは "設計思考" とも呼ばれ、複雑な問題にアプローチして理解するための効果的な方法です。

ユーザーを関与させ、要件を収集するには、さまざまなアプローチを採用できます。 たとえば、"ビジネス設計" と "技術設計" (この記事の後半のセクションで詳しく説明します) を使って要件を収集できます。

ビジネス設計は、ビジネス要件を収集するためのアプローチです。 ビジネス設計セッションでビジネス ユーザーが連携してソリューションを設計することに重点を置きます。 ビジネス設計の出力は、ソリューションのモックアップとわかりやすい設計ドキュメントで構成されます。

技術設計は、ビジネス要件を技術要件に変換し、設計に関する前提に対処するためのアプローチです。 技術設計は、ビジネス設計を検証することと、使う技術アプローチを定義することに焦点を当てています。 通常は、コンテンツ作成者は設計を検証する際に技術専門家と連携し、必要に応じて技術設計セッションという焦点を絞ったディスカッションを行います。

ソリューション計画を準備する

まず、次のセクションで説明する要因を考慮して、ソリューション計画を準備するようにします。

• ソリューション計画を実施するユーザーを特定する: BI 戦術計画の一環として、作業チームは、優先順位付きでソリューションのバックログを作成しました。 ソリューション計画では、バックログから 1 つ以上のソリューションを設計、開発、展開する役割をプロジェクト チームが担います。 バックログ内の各ソリューションについて、ソリューションを担当するプロジェクト チームを編成する必要があります。 プロジェクト チームは、BI ソリューション計画の実行に加え、次のことを行う必要があります。
  • ソリューション計画のタイムラインとマイルストーンを定義します。
  • 要件の収集に適した関係者を特定し、関与させます。
  • コミュニケーション、ドキュメント、計画のための一元化された場所を設定します。
  • 関係者と連携して要件を収集します。
  • 関係者やビジネス ユーザーとコミュニケーションを取り、調整します。
  • 反復的な開発とテストのサイクルをビジネス ユーザーとの間で調整します。
  • ソリューションを文書化します。
  • トレーニング計画を定義し、適用することで、ユーザーをソリューションにオンボードします。
  • 展開後のソリューション サポートを提供します。
  • 展開後にソリューションの変更または更新を求める合理的なユーザー リクエストに対処します。
  • 必要に応じて、展開後にソリューションの引き継ぎを実施します。
• コミュニケーションとドキュメントの一元化: プロジェクト チームが BI ソリューション計画のコミュニケーションとドキュメントを一元化することが重要です。 たとえば、プロジェクト チームは、要件、関係者のコミュニケーション、タイムライン、成果物を一元化する必要があります。 すべてのドキュメントを一元化されたポータルに格納することを検討してください。
• 計画要件の収集: プロジェクト チームは、ビジネス要件を収集するビジネス設計セッションを計画することから始める必要があります。 これらのセッションは対話型の会議の形式を取ります。戦略的計画ワークショップと同様の形式に従うこともできます。

ビジネス要件を収集する

適切なビジネス要件を収集することは、適切なソリューションを設計するために不可欠です。 適切な要件を収集し、効果的なソリューション設計を定義するために、プロジェクト チームはビジネス ユーザーと共にビジネス設計セッションを実施できます。

ビジネス設計セッションの目的は次のとおりです。

• 最初のソリューションの範囲を確認します。
• ソリューションで対処する必要がある問題を定義して理解します。
• ソリューションに適した主要な関係者を特定します。
• 適切なビジネス要件を収集します。
• ビジネス要件を満たすソリューション設計を準備します。
• サポート設計ドキュメントを準備します。

次の図は、ビジネス要件を収集し、ビジネス設計アプローチを使ってソリューション設計を定義する方法を示しています。

この図は、次のステップを示しています。

Item	説明
	プロジェクト チームは、戦術計画で最初に文書化されたソリューションの範囲を確認することからビジネス設計を始めます。 ソリューションに含まれるビジネス領域、システム、データを明確にする必要があります。
	プロジェクト チームは、ビジネス設計セッションに参加してもらうユーザー コミュニティの主要な関係者を特定します。 主要な関係者とは、ソリューションの主題領域の代表者として話す知識と信頼性を十分に持つユーザーです。
	プロジェクト チームは、ビジネス設計セッションを計画します。 計画には、関係者への通知、会議の開催、成果物の準備、ビジネス ユーザーとの連携が含まれます。
	プロジェクト チームは、ビジネス ユーザーが既存のビジネス データのニーズに対応するために現在使っている既存のソリューションを収集して調査します。 このプロセスを加速するために、プロジェクト チームは、コミュニケーション ハブに文書化した BI 戦略計画の関連調査を使用できます。
	プロジェクト チームは、関係者とのビジネス設計セッションを実施します。 このセッションは小規模な対話型の会議です。プロジェクト チームは、ここで関係者がビジネス データのニーズと要件を理解できるように案内します。
	プロジェクト チームは、関係者や他のユーザーに下書きのソリューション設計を提示し、フィードバックと承認を得ることで、ビジネス設計を完了します。 ビジネス設計が成功したと言えるのは、関係者が自身のビジネス目標の達成にその設計が役立つと同意したときです。

ビジネス設計は次の成果物で締めくくります。

• 下書きのソリューション設計: モックアップ、プロトタイプ、またはワイヤーフレーム図でソリューション設計を示しています。 これらのドキュメントで、要件を具体的な設計図に変換します。
• ビジネス メトリックの一覧: ビジネス定義や想定される集計など、ソリューションに必要な定量的フィールド。 可能であれば、ユーザーにとっての重要度別にランクを付けます。
• ビジネス属性の一覧: ビジネス定義や属性名など、ソリューションで想定される関連属性とデータ構造。 可能であれば、階層を含め、ユーザーにとっての重要度別に属性にランクを付けます。
• 補足ドキュメント: 職務またはコンプライアンスの主要要件の説明。 このドキュメントは、必要な程度には正確に、かつ可能な限り簡潔にする必要があります。

ビジネス設計の成果物は、技術設計で使われ、検証されます。

技術要件を収集する

ビジネス設計を完了したら、プロジェクト チームは技術設計を使って成果を検証します。 技術設計はビジネス設計に似たアプローチです。 ビジネス設計はビジネス データのニーズに焦点を当てていますが、技術設計はソリューションの技術的側面に焦点を当てています。 技術設計の主な成果はソリューション計画です。最終的なソリューション設計と、それを実装する労力を情報に基づいて見積もったものが記載されています。

技術設計の目的は次のとおりです。

• ビジネス設計の結果を検証します。
• 現在の設計における技術に関する前提に対処します。
• 範囲内の関連データ ソースを特定し、各データ ソースのフィールド計算とフィールドとソースのマッピングを定義します。
• ビジネス要件を技術要件に変換します。
• 実装に必要な作業量の見積もりを作成します。

プロジェクト チームは、限定的で焦点を絞った技術設計セッションに技術面または職務面の関係者に参加してもらいます。 こうしたセッションは、技術要件を収集するために職務面の関係者との間で行う対話型の会議です。 関係者は、ソリューションが効果的に機能するために必要な特定の職務領域を担当します。

技術設計の関係者の例を次に示します。

• セキュリティとネットワークのチーム: データのセキュリティとコンプライアンスの確保を担当します。
• 職務チームとデータ スチュワード: ソース データのキュレーションを担当します。
• アーキテクト: 特定のプラットフォーム、ツール、またはテクノロジの所有者。

プロジェクト チームは、ソリューションの技術的な側面に対処するために、技術設計セッションに関係者に参加してもらいます。 技術的な側面には次のようなものがあります。

• データ ソースの接続: データ ソースに接続し、データ ソースを統合する方法の詳細。
• ネットワークとデータ ゲートウェイ: プライベート ネットワークまたはオンプレミスのデータ ソースに関する詳細。
• フィールド ソース マッピング: ビジネス メトリックと属性のデータ ソース フィールドへのデータ マッピング。
• 計算ロジック: ビジネス定義の技術的な計算への変換。
• 技術的な機能: ビジネス要件をサポートするために必要な特性または機能。

次の図は、技術設計を使ってビジネス要件を技術要件に変換する方法を示しています。

この図は、次のステップを示しています。

Item	説明
	プロジェクト チームは、ビジネス設計の結果に基づいてデータ ソースの範囲を定義することから技術設計を始めます。 データ ソースの範囲により、ソリューションをビルドするために必要なデータが宣言されます。 適切なデータ ソースを特定するために、プロジェクト チームはビジネスおよび職務の SME に相談します。
	プロジェクト チームは、技術設計セッションの後期に参加してもらう技術面または職務面の関係者を特定します。
	プロジェクト チームは、ソリューションの技術的な側面に対処するために、職務面の関係者との限定的で焦点を絞った設計セッションを計画します。 計画には、関係者への通知、会議の開催、成果物の準備が含まれます。
	プロジェクト チームは技術的な要件を調査します。 調査には、フィールド計算とデータ ソース マッピングを定義することと、技術的な分析とドキュメントを使ってビジネス設計の前提に対処することが含まれます。
	プロジェクト チームは、必要に応じて技術設計セッションに関係者に参加してもらいます。 セッションでは、セキュリティやデータ ソースの接続など、ソリューションの特定の技術的側面に焦点を当てます。 こうしたセッションで、プロジェクト チームは関係者と SME から質に関するフィードバックを収集します。
	プロジェクト チームは、関係者と意思決定者に提示するソリューション計画を使って、調査結果を準備します。 この計画は、最終設計、見積もり、その他の成果物を含むビジネス設計の成果の反復と拡張です。
	技術設計の最後には、関係者や意思決定者との最終会議で次に進むかどうかを決定するようにします。 この会議は、ソリューション開発にリソースを投入する前に、ソリューション計画を評価する最後の機会になります。

技術設計は、次の成果物で構成されるソリューション計画で締めくくります。

• ツールとテクノロジ: ソリューションの実装に必要な、関連する技術的手段の一覧。 この一覧には、通常、関連する新しいライセンスのオプション (ファブリックの容量、Premium Per User など)、機能、ツールが含まれます。
• ビジネス メトリックの定義済み一覧: 範囲内のすべてのデータ ソースに関するビジネス メトリックの計算とフィールドとソースのマッピング。 この成果物を生成するために、プロジェクト チームはビジネス設計で作成されたビジネス メトリックの一覧を使います。
• ビジネス属性の定義済み一覧: 範囲内のすべてのデータ ソースに関するビジネス属性のフィールドとソースのマッピング。 この成果物を生成するために、プロジェクト チームはビジネス設計で作成されたビジネス属性の一覧を使います。
• 改訂された設計: ビジネス設計に対する変更、または無効な前提に基づくソリューション設計の改訂。 改訂された設計は、ビジネス設計で作成されたモックアップ、プロトタイプ、またはワイヤーフレーム図の更新バージョンです。 改訂が不要な場合は、技術設計がビジネス設計を検証していることを伝えます。
• 作業量の見積もり: ソリューションの開発、サポート、保守に必要なリソースの見積もり。 この見積もりは、ソリューションの実装を進めるかどうかの最終決定に役立ちます。

チェックリスト - 要件を収集する場合、主な決定事項とアクションは次のとおりです。

手順 2: 展開を計画する

プロジェクト チームが要件を収集し、ソリューション計画を作成し、先に進む承認を受けたら、ソリューションの展開を計画する準備が整います。

展開計画タスクは、ソリューション、開発ワークフロー、展開プロセスによって変わります。 通常、展開計画は、ソリューションのツールとプロセスの計画とセットアップに関連する多くのアクティビティに関連します。

主要な領域への対処を計画する

プロジェクト チームは、ソリューション展開の主要な領域を計画する必要があります。 通常、計画は次の領域に対処する必要があります。

• コンプライアンス: 要件の収集で特定されたすべてのコンプライアンス条件が、特定のアクションによって対処されることを確認します。 これらの各アクションを特定の担当者に割り当て、完了の概算時期を明確に定義します。
• セキュリティ: ソリューション アクセスのさまざまなレイヤーを管理する方法と、データ セキュリティ規則の要件がある場合はそれも決定します。 ソリューションのセキュリティがテナントの標準コンテンツより厳密かどうかを確認します。
• データ ゲートウェイ: ソリューションがデータ ソースに接続するためにデータ ゲートウェイを必要とするかどうかを評価します。 特定のゲートウェイ設定または高可用性クラスターが必要かどうかを決定します。 ゲートウェイのセキュリティ ロールを使ってゲートウェイ接続を管理できるユーザーと、ゲートウェイを監視する方法を計画します。 詳しくは、「ゲートウェイ アクセスをプロビジョニングする」をご覧ください。
• ワークスペース: ワークスペースを設定して使う方法を決定します。 ソリューションに Git 統合や配置パイプラインなどのライフサイクル管理ツールが必要かどうか、Azure Log Analytics を使った高度なログが必要かどうかを決定します。
• サポート: 運用環境の展開後にソリューションのサポートと保守の担当者を決めます。 サポートの担当者がプロジェクト チームとは異なる場合は、その個人を開発に関与させます。 ソリューションのサポート担当者が誰であっても、ソリューションの設計、対処すべき問題、使う必要があるユーザー、その方法を理解するようにします。
• ユーザー トレーニング: ソリューションを効果的に使用できるように、ユーザー コミュニティのトレーニングに必要な作業を予測します。 特定の変更管理アクションが必要かどうかを検討します。
• ガバナンス: ソリューションの潜在的なガバナンス リスクがないか確認します。 ガバナンス リスクを (たとえば秘密度ラベルとポリシーを使うなどして) 軽減しつつ、ユーザーがソリューションを効果的に使用できるようにするために必要な労力を予測します。

初期セットアップを実施する

プロジェクト チームは、開発を開始するために初期セットアップを実行する必要があります。 初期セットアップ アクティビティには、以下が含まれます。

• 初期ツールとプロセス: 開発、テスト、展開に必要な新しいツールとプロセスがあれば、その初回セットアップを実行します。
• ID と資格情報: ツールとシステムへのアクセスに使われるセキュリティ グループとサービス プリンシパルを作成します。 資格情報を効果的かつ安全に格納します。
• データ ゲートウェイ: オンプレミスのデータ ソース (エンタープライズ モード ゲートウェイ) またはプライベート ネットワーク上のデータ ソース (仮想ネットワーク (VNet)、ゲートウェイ) 用にデータ ゲートウェイを展開します。
• ワークスペースとリポジトリ: コンテンツを発行および格納するためのワークスペースとリモート リポジトリを作成し、設定します。

展開計画の詳細については、「Power BI に移行するためのデプロイを計画する」を参照してください。

チェックリスト - ソリューションの展開を計画する場合、主な決定事項とアクションは次のとおりです。

手順 3: 概念実証を実施する

プロジェクト チームは、未解決の前提を検証し、ビジネス ユーザーにとっての早期の利点を実証するために、ソリューションの "概念実証 (POC)" を実施します。 POC は、範囲と成熟度が限定された初期設計実装です。 POC の適切な実行が特に重要なのは、大規模な、または複雑なソリューションの場合です。なぜなら、技術設計では検出されなかった複雑さ (または例外) を特定し、対処する可能性があるからです。

POC を準備するときは、次の考慮事項を含めることをお勧めします。

• ゴールと範囲: ソリューションの POC の目的と、それに対処する機能領域について説明します。 たとえば、プロジェクト チームは、1 つの職務領域、または特定の要件または機能のセットに POC を制限することを決定できます。
• ソース データ: POC で使われるデータを特定します。 ソリューションによっては、次のようにさまざまな種類のデータを使うことをプロジェクト チームが決定する場合があります。
  • 運用環境 (実際の) データ
  • サンプル データ
  • 運用環境で観測された実際のデータ量と複雑さと似ている、生成した合成データ
• デモ: プロジェクト チームが関係者とユーザーに POC を実演する方法とタイミングについて説明します。 デモは、定期的な更新時、または POC が特定の職務の条件を満たす場合に行うことがあります。
• 環境: プロジェクト チームが POC を構築する場所について説明します。 POC に個別の "サンドボックス" 環境を使い、準備ができたら開発環境に展開することをお勧めします。 サンドボックス環境は、ポリシーの柔軟性とコンテンツの流動性が高く、短時間での結果の生成に重点を置いています。 これに対し、開発環境は、コラボレーションを可能にするより構造化されたプロセスに従い、特定のタスクの完了に重点を置いています。
• 成功条件: POC が成功し、次の反復に進んで正式な開発を開始する必要があるしきい値を定義します。 POC を開始する前に、プロジェクト チームは、POC が成功する場合の明確な条件を特定する必要があります。 プロジェクト チームは、これらの条件を事前に設定することで、POC 開発が終了するタイミングと、反復的な開発と検証のサイクルが始まるタイミングを定義します。 POC のゴールに応じて、プロジェクト チームは次のようにさまざまな成功条件を設定できます。
  • 関係者による POC の承認
  • 特性または機能の検証
  • 一定の開発時間が経過した後の同僚による POC の良好なレビュー
• 失敗: プロジェクト チームが POC の失敗を特定できることを確認します。 早い段階で失敗を特定することは、根本原因の調査に役立ちます。 また、運用環境に展開するときに想定どおりに機能しないソリューションへのさらなる投資を回避するのにも役立ちます。

チェックリスト - POC を作成するときの主な決定事項とアクションは次のとおりです。

手順 4: コンテンツを作成して検証する

POC が成功すると、プロジェクト チームは、POC からコンテンツの作成と検証に移行します。 プロジェクト チームは、反復的な開発と検証のサイクルで BI ソリューションを開発できます。 これらのサイクルは、プロジェクト チームが開発環境にコンテンツを作成し、テスト環境にリリースするという、反復的なリリースで構成されます。 開発中に、プロジェクト チームは、パイロット プロセスのユーザー コミュニティをテスト環境の初期 (ベータ) バージョンのソリューションに段階的にオンボードします。

反復的な開発と検証のサイクルは、プロジェクト チームが定義済みの結論に達するまで続行されます。 通常、開発は、実装する機能や対処するユーザー フィードバックがなくなった時点で完了します。 開発と検証のサイクルが完了すると、プロジェクト チームは最終的な運用リリースでコンテンツを運用環境に展開します。

次の図は、プロジェクト チームが開発と検証のサイクルで BI ソリューションを繰り返しリリースする方法を示しています。

この図は、次のステップを示しています。

Item	説明
	プロジェクト チームは、各リリースをユーザー コミュニティに伝え、変更と新機能について説明します。 理想的には、コミュニケーションにはソリューションのデモと Q&A を含めて、ユーザーがリリースの新機能を理解し、口頭でフィードバックを提供できるようにします。
	検証中、ユーザーは中央のツールまたはフォームを介してフィードバックを提供します。 プロジェクト チームはフィードバックを定期的に確認して問題に対処し、要求を受け入れるか拒否し、今後の開発フェーズを通知する必要があります。
	プロジェクト チームはソリューションの使用状況を監視して、ユーザーがテストしていることを確認します。 使用されていない場合、プロジェクト チームは、ユーザー コミュニティとやり取りし、理由を理解してもらう必要があります。 低い使用率は、プロジェクト チームがさらに有効化と変更管理の措置をとる必要がある可能性を示しています。
	プロジェクト チームは、ユーザーのフィードバックに速やかに対応します。 プロジェクト チームがフィードバックの対処に時間がかかりすぎると、ユーザーはフィードバックを提供するやる気をすぐに失う可能性があります。
	プロジェクト チームは、受け入れられたフィードバックをソリューション計画に組み込みます。 必要に応じて、計画の優先順位を確認し、次の開発フェーズが始まる前にタスクを明確にして委任します。
	プロジェクト チームは、次のリリースに向けてソリューションの開発を続けます。
	プロジェクト チームは、定義済みの結論に達し、ソリューションを運用環境に展開する準備が整うまで、すべての手順を繰り返し実行します。

以下のセクションでは、反復的な開発と検証のサイクルを使って BI ソリューションをリリースするための重要な考慮事項について説明します。

コンテンツを作成する

プロジェクト チームは、通常の開発ワークフローに従ってソリューションを開発します。 ただし、コンテンツを作成するときは、次の点を考慮する必要があります。

• 各開発サイクル中に、ドキュメントを更新してソリューションについて説明します。
• 各開発サイクルを完了する際には、ユーザー コミュニティに通知します。 通知は一元化されたポータルに投稿し、各リリースの変更と新機能の簡単な説明を提供する必要があります。
• リリースごとに、ユーザー コミュニティに変更と新機能をデモし、口頭での質問に回答するセッションを開催することを検討してください。
• 反復的な開発と検証のサイクルをいつ完了するかを定義します。 サポートと導入アクティビティへの移行など、ソリューションを運用環境に展開するための明確なプロセスがあることを確認します。

コンテンツの検証

個々の反復的な開発サイクルは、コンテンツの検証で締めくくるようにします。 BI ソリューションの場合、通常は 2 種類の検証があります。

• 開発者検証: ソリューションのテストは、コンテンツ作成者と同僚によって行われます。 開発者検証の目的は、ソリューションがビジネス ユーザーに提供される前に、重要かつ明らかな問題をすべて特定して解決することです。 問題は、データの正確性、機能、またはユーザー エクスペリエンスに関係する場合があります。 開発しなかったコンテンツ作成者が検証するのが理想的です。
• ユーザー検証: ソリューションのテストはユーザー コミュニティによって行われます。 ユーザー検証の目的は、後期の反復に関するフィードバックを提供し、開発者が見つけなかった問題を特定することです。 通常、正式なユーザー検証期間は、ユーザー受け入れテスト (UAT) と呼ばれます。

プロジェクト チームがコンテンツを検証するときは、次の考慮事項を含めます。

• ユーザーのフィードバックを促進する: リリースごとに、ユーザーにフィードバックを提供するように求め、効果的に行う方法を示します。 最近の変更や新機能につながったフィードバックや要求の例を定期的に共有することを検討します。 例を共有することで、フィードバックが認められ、評価されることを示します。
• 大きな要求を分離する: 一部のフィードバック項目は、より多くの労力が対処に必要です。 プロジェクト チームがこのような項目を特定し、それらを実装するかどうかを話し合うことができることを確認します。 後期の戦術計画セッションで議論する大きな要求を文書化することを検討します。
• 変更管理アクティビティを開始する: ソリューションの使用方法をユーザーにトレーニングします。 新しいプロセス、新しいデータ、異なる作業方法にはさらに労力をかけます。 変更管理への投資には、長期的なソリューション導入にプラスの効果があります。

ソリューションが定義済みレベルの完成度と成熟度に達したら、プロジェクト チームが運用環境に展開する準備が整います。 展開後、プロジェクト チームは、反復的なリリースから運用ソリューションのサポートと監視に移行します。

この記事では、大まかな計画と実行可能な項目についてのみ説明します。 反復的な開発とテストのサイクルの詳細については、「Power BI に移行するコンテンツを作成する」を参照してください。

チェックリスト - コンテンツを作成して検証する場合、主な決定事項とアクションは次のとおりです。

手順 5: 展開、サポート、監視

準備ができたら、プロジェクト チームは検証済みのソリューションを運用環境に展開します。 プロジェクト チームは、展開が成功するように、主要な導入とサポートのアクションを実行する必要があります。

展開が成功するように、次のサポートと導入のタスクを実行します。

• 最終リリースを伝える: エグゼクティブ スポンサー、マネージャー、または十分な権限と信頼性を持つ別の個人が、リリースをユーザー コミュニティに発表する必要があります。 コミュニケーションは明確かつ簡潔にして、関連するソリューションとサポート チャネルへのリンクを含める必要があります。
• コンテンツ コンシューマー向けにトレーニングを実施する: 運用環境へのリリース後の最初の数週間は、コンテンツ コンシューマーがトレーニングを利用できるようにします。 トレーニングは、ソリューション範囲の明確化、ユーザーからの質問への回答、ソリューションの使用方法の説明に重点を置くようにします。
• フィードバックと要求に対処する: フィードバックと要求をプロジェクト チームに送信するためのチャネルをユーザーに提供することを検討します。 必ず適切なフィードバックと要求について話し合い、必要に応じて展開後のサポート期間中に実装します。 運用リリース後にフィードバックと要求に対応することが重要です。 これは、変化するビジネス ニーズに対応するアジャイル ソリューションを示しています。
• ユーザー コミュニティとつながることを計画する: 展開後のサポート期間が終了した後も、ソリューション所有者はユーザー コミュニティと定期的に会議するようにします。 こうした会議は、BI 戦略を改訂するための貴重なフィードバックの源です。 また、ユーザーを可能にすることで、ソリューションの導入をサポートするのにも役立ちます。
• アクションを引き継ぐ: プロジェクト チームのメンバーは、ソリューションの保守を担当しない場合があります。 この場合、チームは担当者を特定し、引き継ぎを実施する必要があります。 引き継ぎは、運用環境へのリリース直後に行い、ソリューションとユーザー コミュニティの両方に対処するようにします。

展開後、プロジェクト チームは、優先順位を付けたソリューション バックログの次のソリューションに進む計画を立てる必要があります。 必要に応じて、新しいフィードバックと要求を収集し、戦術計画 (ソリューション バックログを含む) を改訂します。

チェックリスト - ソリューションの展開を検討する場合、主な決定事項とアクションは次のとおりです。

関連するコンテンツ

Power BI の実装の決定に役立つ考慮事項、アクション、意思決定基準、推奨事項について詳しくは、「Power BI 実装計画」をご覧ください。