Power BI 実装計画: BI ソリューション計画
Note
この記事は、Power BI 実装計画 シリーズの記事の一部です。 このシリーズでは、主に Microsoft Fabric 内での Power BI のエクスペリエンスに焦点を当てます。 シリーズの概要については、「Power BI 実装計画」を参照してください。
この記事は、ビジネス インテリジェンス (BI) 戦略をサポートするソリューションを計画するために役立ちます。 主な対象者は次のとおりです。
- BI および分析のディレクターまたはマネージャー: BI プログラムと戦略的に重要な BI ソリューションの監督を担当する意思決定者。
- センター オブ エクセレンス (COE)、IT、BI チーム: 組織のエンタープライズ BI ソリューションを設計および展開するチーム。
- 領域の専門家 (SME)、コンテンツの所有者と作成者: 部門の分析を支持し、セルフサービス、部門 BI、またはチーム BI の使用シナリオ向けソリューションを設計および展開するチームと個人。
BI 戦略は、データと分析を実装、使用、管理するための計画です。 BI 戦略を定義するには、まず BI の戦略的計画から始めます。 戦略的な計画は、BI の重点分野と目標を特定するのに役立ちます。 BI の目標に向けて進むパスを決定するには、戦術計画を使って具体的な主要な成果を記述します。 次に、BI ソリューションを計画し、展開することで、これらの主要な成果に向けて進捗状況を達成します。
Note
目標と主要な成果 (OKR) フレームワークにおいて、"目標" は、達成したいことの明確で概観的な記述です。 これに対し、"主要な成果" は、目標の 1 つに向けた進捗状況を測定するための具体的で達成可能な成果です。
さらに、"イニシアティブ" または "ソリューション" は、1 つ以上の主要な成果を達成するために構築されたプロセスまたはツールです。 ソリューションは、ユーザーの具体的なデータ ニーズに対応します。 ソリューションが取り得る形式は、データ パイプライン、データ レイクハウス、Power BI セマンティック モデルやレポートなどさまざまです。
OKR の詳細については、「OKR (Microsoft Viva Goals) を理解する」を参照してください。
BI ソリューションを計画して実装するには、多くの方法があります。 この記事では、BI 戦略をサポートする BI ソリューションを計画および実装するために実行できるアプローチの 1 つについて説明します。
次の概要図は、BI ソリューション計画を実施する方法を示しています。
BI ソリューションの計画を実施するには、次の手順を実行します。
| Step | 説明 |
|---|---|
| 1 | 要件を収集し、ソリューションの設計を定義するプロジェクト チームを編成します。 |
| 2 | ツールとプロセスの初期セットアップを実行して、ソリューションの展開を計画します。 |
| 3 | ソリューションの概念実証 (POC) を実施して、設計に関する前提を検証します。 |
| 4 | 反復的な開発と検証サイクルを使って、コンテンツを作成し、検証します。 |
| 5 | 運用環境にリリースされた後、ソリューションを展開、サポート、監視します。 |
Note
BI ソリューション計画は、セルフサービス BI プロジェクトとエンタープライズ BI プロジェクトの両方に適用されます。
詳細については、Power BI の移行シリーズを参照してください。 このシリーズは移行に関するものですが、主なアクションと考慮事項はソリューション計画に関連しています。
手順 1: 要件を収集する
ソリューション計画を開始するには、まず要件を収集し、ソリューション設計を定義します。
注: 戦略および戦術計画は "作業チーム" が主導し、このイニシアティブも主導します。 これに対し、ソリューション計画は、コンテンツの所有者と作成者で構成される "プロジェクト チーム" が主導します。
ソリューションの展開と導入を成功させるには、適切な要件を収集することが重要です。 要件を収集する効果的な方法は、適切な関係者を特定して関与させ、解決すべき問題を共同で定義し、その共有された理解を使ってソリューション設計を作成することです。
コラボレーション アプローチを使って要件を収集する利点をいくつか次に示します。
- ユーザーの意見からより有用な設計が生まれる: 焦点を絞ったディスカッションにユーザーに参加してもらい、要件を収集することで、ビジネス データのニーズをより効果的に取り込むことができます。 たとえば、ユーザーは既存のソリューションをどのように使っているかをコンテンツ作成者に実演し、これらのソリューションの認識された有効性についてフィードバックを提供できます。
- 前提を避け、変更要求を軽減する: ユーザーとのディスカッションによって、微妙な違い、例外、隠れた複雑さが明らかになることはよくあります。 後期に要求あると対処にかかるコストが高くなる可能性がありますが、これらの分析情報によってその可能性を軽減できます。
- ユーザーをオンボーディングすることでソリューションの導入率を上げる: 設計と初期開発にユーザーを関与させることで、最終的な結果に影響を与える機会を提供します。 また、ユーザーが関与することで、ソリューションに対する知的財産の所有権とアカウンタビリティを理解することもできます。 関与度が高いユーザーは、ソリューションを支持し、効果的に使用できるようにその実践共同体を主導する可能性が高くなります。
- 設計によって関係者とビジネス ユーザーに期待感を与える: ソリューション設計のモックアップやイラストを作成することで、関係者にソリューションが何を提供するかを明確に示すことができます。 また、想定されるプロジェクトの結果について相互理解を深めることにも役立ちます。 このプロセスは "設計思考" とも呼ばれ、複雑な問題にアプローチして理解するための効果的な方法です。
ユーザーを関与させ、要件を収集するには、さまざまなアプローチを採用できます。 たとえば、"ビジネス設計" と "技術設計" (この記事の後半のセクションで詳しく説明します) を使って要件を収集できます。
ビジネス設計は、ビジネス要件を収集するためのアプローチです。 ビジネス設計セッションでビジネス ユーザーが連携してソリューションを設計することに重点を置きます。 ビジネス設計の出力は、ソリューションのモックアップとわかりやすい設計ドキュメントで構成されます。
技術設計は、ビジネス要件を技術要件に変換し、設計に関する前提に対処するためのアプローチです。 技術設計は、ビジネス設計を検証することと、使う技術アプローチを定義することに焦点を当てています。 通常は、コンテンツ作成者は設計を検証する際に技術専門家と連携し、必要に応じて技術設計セッションという焦点を絞ったディスカッションを行います。
重要
間違った要件の収集は、実装が失敗する理由としてよくあることです。 チームが間違った要件を収集する理由は、多くの場合、構築するソリューションに対してトップダウンの要求を出す意思決定者など、間違った関係者と連携するからです。
ビジネス設計などのコラボレーション アプローチを使ってビジネス ユーザーを関与させることで、より良い要件を収集するのに役立ちます。 多くの場合、より良い要件は、より効率的な開発とより堅牢なソリューションにつながります。
Note
チームによっては、構造化された要件収集プロセスを導入することは大きな変化です。 確実にこの変更を管理し、ソリューション計画が中断されないようにしてください。 チームの作業方法に合わせてこれらのアプローチを調整する方法を見つけることをお勧めします。
ソリューション計画を準備する
まず、次のセクションで説明する要因を考慮して、ソリューション計画を準備するようにします。
- ソリューション計画を実施するユーザーを特定する: BI 戦術計画の一環として、作業チームは、優先順位付きでソリューションのバックログを作成しました。 ソリューション計画では、バックログから 1 つ以上のソリューションを設計、開発、展開する役割をプロジェクト チームが担います。 バックログ内の各ソリューションについて、ソリューションを担当するプロジェクト チームを編成する必要があります。 プロジェクト チームは、BI ソリューション計画の実行に加え、次のことを行う必要があります。
- ソリューション計画のタイムラインとマイルストーンを定義します。
- 要件の収集に適した関係者を特定し、関与させます。
- コミュニケーション、ドキュメント、計画のための一元化された場所を設定します。
- 関係者と連携して要件を収集します。
- 関係者やビジネス ユーザーとコミュニケーションを取り、調整します。
- 反復的な開発とテストのサイクルをビジネス ユーザーとの間で調整します。
- ソリューションを文書化します。
- トレーニング計画を定義し、適用することで、ユーザーをソリューションにオンボードします。
- 展開後のソリューション サポートを提供します。
- 展開後にソリューションの変更または更新を求める合理的なユーザー リクエストに対処します。
- 必要に応じて、展開後にソリューションの引き継ぎを実施します。
- コミュニケーションとドキュメントの一元化: プロジェクト チームが BI ソリューション計画のコミュニケーションとドキュメントを一元化することが重要です。 たとえば、プロジェクト チームは、要件、関係者のコミュニケーション、タイムライン、成果物を一元化する必要があります。 すべてのドキュメントを一元化されたポータルに格納することを検討してください。
- 計画要件の収集: プロジェクト チームは、ビジネス要件を収集するビジネス設計セッションを計画することから始める必要があります。 これらのセッションは対話型の会議の形式を取ります。戦略的計画ワークショップと同様の形式に従うこともできます。
ヒント
要件収集プロセスの早い段階で、ソリューションを担当するサポート チームを特定し、関与させることを検討してください。 ソリューションを効果的にサポートするには、サポート チームがソリューション、その目的、ユーザーを包括的に理解する必要があります。 これが特に重要なのは、プロジェクト チームが外部コンサルタントのみで構成されている場合です。
ビジネス要件を収集する
適切なビジネス要件を収集することは、適切なソリューションを設計するために不可欠です。 適切な要件を収集し、効果的なソリューション設計を定義するために、プロジェクト チームはビジネス ユーザーと共にビジネス設計セッションを実施できます。
ビジネス設計セッションの目的は次のとおりです。
- 最初のソリューションの範囲を確認します。
- ソリューションで対処する必要がある問題を定義して理解します。
- ソリューションに適した主要な関係者を特定します。
- 適切なビジネス要件を収集します。
- ビジネス要件を満たすソリューション設計を準備します。
- サポート設計ドキュメントを準備します。
次の図は、ビジネス要件を収集し、ビジネス設計アプローチを使ってソリューション設計を定義する方法を示しています。
この図は、次のステップを示しています。
| Item | 説明 |
|---|---|
 |
プロジェクト チームは、戦術計画で最初に文書化されたソリューションの範囲を確認することからビジネス設計を始めます。 ソリューションに含まれるビジネス領域、システム、データを明確にする必要があります。 |
 |
プロジェクト チームは、ビジネス設計セッションに参加してもらうユーザー コミュニティの主要な関係者を特定します。 主要な関係者とは、ソリューションの主題領域の代表者として話す知識と信頼性を十分に持つユーザーです。 |
 |
プロジェクト チームは、ビジネス設計セッションを計画します。 計画には、関係者への通知、会議の開催、成果物の準備、ビジネス ユーザーとの連携が含まれます。 |
 |
プロジェクト チームは、ビジネス ユーザーが既存のビジネス データのニーズに対応するために現在使っている既存のソリューションを収集して調査します。 このプロセスを加速するために、プロジェクト チームは、コミュニケーション ハブに文書化した BI 戦略計画の関連調査を使用できます。 |
 |
プロジェクト チームは、関係者とのビジネス設計セッションを実施します。 このセッションは小規模な対話型の会議です。プロジェクト チームは、ここで関係者がビジネス データのニーズと要件を理解できるように案内します。 |
 |
プロジェクト チームは、関係者や他のユーザーに下書きのソリューション設計を提示し、フィードバックと承認を得ることで、ビジネス設計を完了します。 ビジネス設計が成功したと言えるのは、関係者が自身のビジネス目標の達成にその設計が役立つと同意したときです。 |
ビジネス設計は次の成果物で締めくくります。
- 下書きのソリューション設計: モックアップ、プロトタイプ、またはワイヤーフレーム図でソリューション設計を示しています。 これらのドキュメントで、要件を具体的な設計図に変換します。
- ビジネス メトリックの一覧: ビジネス定義や想定される集計など、ソリューションに必要な定量的フィールド。 可能であれば、ユーザーにとっての重要度別にランクを付けます。
- ビジネス属性の一覧: ビジネス定義や属性名など、ソリューションで想定される関連属性とデータ構造。 可能であれば、階層を含め、ユーザーにとっての重要度別に属性にランクを付けます。
- 補足ドキュメント: 職務またはコンプライアンスの主要要件の説明。 このドキュメントは、必要な程度には正確に、かつ可能な限り簡潔にする必要があります。
ビジネス設計の成果物は、技術設計で使われ、検証されます。
ヒント
ソリューションのモックアップ、プロトタイプ、ワイヤーフレーム図があると、開発者とエンド ユーザーの両方が想定される結果を明確に理解できます。 効果的なモックアップを作成するために芸術的なスキルや才能は必要ありません。 Microsoft Whiteboard、PowerPoint などのシンプルなツールや、単にペンと紙を使って設計を説明することができます。
技術要件を収集する
ビジネス設計を完了したら、プロジェクト チームは技術設計を使って成果を検証します。 技術設計はビジネス設計に似たアプローチです。 ビジネス設計はビジネス データのニーズに焦点を当てていますが、技術設計はソリューションの技術的側面に焦点を当てています。 技術設計の主な成果はソリューション計画です。最終的なソリューション設計と、それを実装する労力を情報に基づいて見積もったものが記載されています。
Note
ビジネス設計とは異なり、技術設計の大部分は、コンテンツの作成者と所有者によって実施されるソース データとシステムに対する独立した調査です。
技術設計の目的は次のとおりです。
- ビジネス設計の結果を検証します。
- 現在の設計における技術に関する前提に対処します。
- 範囲内の関連データ ソースを特定し、各データ ソースのフィールド計算とフィールドとソースのマッピングを定義します。
- ビジネス要件を技術要件に変換します。
- 実装に必要な作業量の見積もりを作成します。
プロジェクト チームは、限定的で焦点を絞った技術設計セッションに技術面または職務面の関係者に参加してもらいます。 こうしたセッションは、技術要件を収集するために職務面の関係者との間で行う対話型の会議です。 関係者は、ソリューションが効果的に機能するために必要な特定の職務領域を担当します。
技術設計の関係者の例を次に示します。
- セキュリティとネットワークのチーム: データのセキュリティとコンプライアンスの確保を担当します。
- 職務チームとデータ スチュワード: ソース データのキュレーションを担当します。
- アーキテクト: 特定のプラットフォーム、ツール、またはテクノロジの所有者。
プロジェクト チームは、ソリューションの技術的な側面に対処するために、技術設計セッションに関係者に参加してもらいます。 技術的な側面には次のようなものがあります。
- データ ソースの接続: データ ソースに接続し、データ ソースを統合する方法の詳細。
- ネットワークとデータ ゲートウェイ: プライベート ネットワークまたはオンプレミスのデータ ソースに関する詳細。
- フィールド ソース マッピング: ビジネス メトリックと属性のデータ ソース フィールドへのデータ マッピング。
- 計算ロジック: ビジネス定義の技術的な計算への変換。
- 技術的な機能: ビジネス要件をサポートするために必要な特性または機能。
ヒント
ビジネス設計を実施したプロジェクト チームも、技術設計を実施する必要があります。 ただし、現実的な理由から、別の担当者が技術設計を主導する場合があります。 この場合、ビジネス設計の成果を確認することから技術設計を始めます。
理想的には、技術設計を主導する担当者が、成果とビジネス ユーザーについて十分に理解している必要があります。
次の図は、技術設計を使ってビジネス要件を技術要件に変換する方法を示しています。
この図は、次のステップを示しています。
| Item | 説明 |
|---|---|
|
プロジェクト チームは、ビジネス設計の結果に基づいてデータ ソースの範囲を定義することから技術設計を始めます。 データ ソースの範囲により、ソリューションをビルドするために必要なデータが宣言されます。 適切なデータ ソースを特定するために、プロジェクト チームはビジネスおよび職務の SME に相談します。 |
|
プロジェクト チームは、技術設計セッションの後期に参加してもらう技術面または職務面の関係者を特定します。 |
|
プロジェクト チームは、ソリューションの技術的な側面に対処するために、職務面の関係者との限定的で焦点を絞った設計セッションを計画します。 計画には、関係者への通知、会議の開催、成果物の準備が含まれます。 |
|
プロジェクト チームは技術的な要件を調査します。 調査には、フィールド計算とデータ ソース マッピングを定義することと、技術的な分析とドキュメントを使ってビジネス設計の前提に対処することが含まれます。 |
|
プロジェクト チームは、必要に応じて技術設計セッションに関係者に参加してもらいます。 セッションでは、セキュリティやデータ ソースの接続など、ソリューションの特定の技術的側面に焦点を当てます。 こうしたセッションで、プロジェクト チームは関係者と SME から質に関するフィードバックを収集します。 |
|
プロジェクト チームは、関係者と意思決定者に提示するソリューション計画を使って、調査結果を準備します。 この計画は、最終設計、見積もり、その他の成果物を含むビジネス設計の成果の反復と拡張です。 |
 |
技術設計の最後には、関係者や意思決定者との最終会議で次に進むかどうかを決定するようにします。 この会議は、ソリューション開発にリソースを投入する前に、ソリューション計画を評価する最後の機会になります。 |
Note
技術設計の結果、想定外の複雑さが明らかになり、現在のリソースの利用可能性や組織の準備状況を考慮すると、ソリューションの計画が実行不可能になる可能性があります。 このような場合は、その後の戦術計画期間でソリューションを評価し直す必要があります。 ビジネス データ ニーズの緊急度によっては、エグゼクティブ スポンサーのような意思決定者が、概念実証、または計画したソリューションの一部分のみを進めたいと考える場合があります。
技術設計は、次の成果物で構成されるソリューション計画で締めくくります。
- ツールとテクノロジ: ソリューションの実装に必要な、関連する技術的手段の一覧。 この一覧には、通常、関連する新しいライセンスのオプション (ファブリックの容量、Premium Per User など)、機能、ツールが含まれます。
- ビジネス メトリックの定義済み一覧: 範囲内のすべてのデータ ソースに関するビジネス メトリックの計算とフィールドとソースのマッピング。 この成果物を生成するために、プロジェクト チームはビジネス設計で作成されたビジネス メトリックの一覧を使います。
- ビジネス属性の定義済み一覧: 範囲内のすべてのデータ ソースに関するビジネス属性のフィールドとソースのマッピング。 この成果物を生成するために、プロジェクト チームはビジネス設計で作成されたビジネス属性の一覧を使います。
- 改訂された設計: ビジネス設計に対する変更、または無効な前提に基づくソリューション設計の改訂。 改訂された設計は、ビジネス設計で作成されたモックアップ、プロトタイプ、またはワイヤーフレーム図の更新バージョンです。 改訂が不要な場合は、技術設計がビジネス設計を検証していることを伝えます。
- 作業量の見積もり: ソリューションの開発、サポート、保守に必要なリソースの見積もり。 この見積もりは、ソリューションの実装を進めるかどうかの最終決定に役立ちます。
重要
技術設計からの変更や予期しない発見があった場合は、プロジェクト チームが関係者に通知するようにします。 このような技術設計セッションには、関連するビジネス ユーザーが引き続き参加する必要があります。 ただし、複雑な技術情報が不必要に関係者の目に入らないようにします。
ヒント
ビジネス目標は常に進化するので、要件も変わることが予想されます。 BI プロジェクトの要件は固定されていると想定しないでください。 要件の変更に苦労している場合は、要件の収集プロセスが効果的ではないこと、または開発ワークフローに定期的なフィードバックが十分に組み込まれていないことを示している可能性があります。
チェックリスト - 要件を収集する場合、主な決定事項とアクションは次のとおりです。
- ソリューション計画を所有するユーザーを明確にする: ソリューションごとに、プロジェクト チームの役割と責任を必ず明確にします。
- ソリューションの範囲を明確にする: ソリューションの範囲は、BI 戦術計画の一環で既に文書化されている必要があります。 ソリューション計画を開始する前に範囲を明確にするために、追加の時間と労力が必要になる場合があります。
- 関係者を特定して通知する: ビジネス設計と技術設計の関係者を特定します。 プロジェクトについて事前に通知し、事業設計の範囲、目標、必要な時間投資、成果物について説明します。
- ビジネス設計セッションの計画と実施: ビジネス設計セッションをモデレートして、関係者やビジネス ユーザーから情報を引き出します。 既存のソリューションをどのように使っているかを実演するようにユーザーに依頼します。
- ビジネスのメトリックと属性を文書化する: 既存のソリューションと関係者からの意見を利用して、ビジネスのメトリックと属性の一覧を作成します。 技術設計では、フィールドをデータ ソースにマップし、定量的フィールドの計算ロジックを記述します。
- ソリューション設計を下書きする: 関係者の意見に基づいて、想定されるソリューション結果を視覚的に反映する反復的なモックアップを作成します。 モックアップがビジネス要件を正確に表し、対処していることを確認します。 技術設計の間にモックアップを検証する (場合によっては改訂する) 必要があることをビジネス ユーザーに伝えます。
- ソリューション計画を作成する: ソース データと関連する技術的な考慮事項を調査して、ビジネス設計が達成可能であることを確認します。 関連する場合は、設計に対する主要なリスクと脅威、代替アプローチがある場合はそれについても説明します。 必要に応じて、ソリューション設計の改訂を準備し、関係者と話し合います。
- 作業量の見積もりを作成する: 最終的なソリューション計画の一環として、ソリューションを構築してサポートするための労力を見積もります。 ビジネス設計と技術設計のセッション中に収集された情報を使って、これらの見積もりが妥当であることを示します。
- 計画を先に進めるかどうか決定する: 要件の収集プロセスを完了するには、関係者と意思決定者に最終的な計画を提示します。 この会議の目的は、ソリューションの開発を進めるかどうかを決定することです。
手順 2: 展開を計画する
プロジェクト チームが要件を収集し、ソリューション計画を作成し、先に進む承認を受けたら、ソリューションの展開を計画する準備が整います。
展開計画タスクは、ソリューション、開発ワークフロー、展開プロセスによって変わります。 通常、展開計画は、ソリューションのツールとプロセスの計画とセットアップに関連する多くのアクティビティに関連します。
主要な領域への対処を計画する
プロジェクト チームは、ソリューション展開の主要な領域を計画する必要があります。 通常、計画は次の領域に対処する必要があります。
- コンプライアンス: 要件の収集で特定されたすべてのコンプライアンス条件が、特定のアクションによって対処されることを確認します。 これらの各アクションを特定の担当者に割り当て、完了の概算時期を明確に定義します。
- セキュリティ: ソリューション アクセスのさまざまなレイヤーを管理する方法と、データ セキュリティ規則の要件がある場合はそれも決定します。 ソリューションのセキュリティがテナントの標準コンテンツより厳密かどうかを確認します。
- データ ゲートウェイ: ソリューションがデータ ソースに接続するためにデータ ゲートウェイを必要とするかどうかを評価します。 特定のゲートウェイ設定または高可用性クラスターが必要かどうかを決定します。 ゲートウェイのセキュリティ ロールを使ってゲートウェイ接続を管理できるユーザーと、ゲートウェイを監視する方法を計画します。 詳しくは、「ゲートウェイ アクセスをプロビジョニングする」をご覧ください。
- ワークスペース: ワークスペースを設定して使う方法を決定します。 ソリューションに Git 統合や配置パイプラインなどのライフサイクル管理ツールが必要かどうか、Azure Log Analytics を使った高度なログが必要かどうかを決定します。
- サポート: 運用環境の展開後にソリューションのサポートと保守の担当者を決めます。 サポートの担当者がプロジェクト チームとは異なる場合は、その個人を開発に関与させます。 ソリューションのサポート担当者が誰であっても、ソリューションの設計、対処すべき問題、使う必要があるユーザー、その方法を理解するようにします。
- ユーザー トレーニング: ソリューションを効果的に使用できるように、ユーザー コミュニティのトレーニングに必要な作業を予測します。 特定の変更管理アクションが必要かどうかを検討します。
- ガバナンス: ソリューションの潜在的なガバナンス リスクがないか確認します。 ガバナンス リスクを (たとえば秘密度ラベルとポリシーを使うなどして) 軽減しつつ、ユーザーがソリューションを効果的に使用できるようにするために必要な労力を予測します。
初期セットアップを実施する
プロジェクト チームは、開発を開始するために初期セットアップを実行する必要があります。 初期セットアップ アクティビティには、以下が含まれます。
- 初期ツールとプロセス: 開発、テスト、展開に必要な新しいツールとプロセスがあれば、その初回セットアップを実行します。
- ID と資格情報: ツールとシステムへのアクセスに使われるセキュリティ グループとサービス プリンシパルを作成します。 資格情報を効果的かつ安全に格納します。
- データ ゲートウェイ: オンプレミスのデータ ソース (エンタープライズ モード ゲートウェイ) またはプライベート ネットワーク (仮想ネットワーク、VNet、ゲートウェイ) 上のデータ ソース用に データ ゲートウェイをデプロイします。
- ワークスペースとリポジトリ: コンテンツを発行および格納するためのワークスペースとリモート リポジトリを作成し、設定します。
Note
展開計画は、ソリューションと推奨されるワークフローによって異なります。 この記事では、大まかな計画と実行可能な項目についてのみ説明します。
展開計画の詳細については、「Power BI に移行するためのデプロイを計画する」を参照してください。
チェックリスト - ソリューションの展開を計画する場合、主な決定事項とアクションは次のとおりです。
- 主な領域を計画する: ソリューションを適切に開発して展開するために必要なプロセスとツールに対処する計画を立てます。 技術的な領域 (データ ゲートウェイやワークスペースなど) と導入 (ユーザー トレーニングやガバナンスなど) の両方に対処します。
- 初期セットアップを実施する: ソリューションの開発と展開に必要なツール、プロセス、機能を確立します。 セットアップを文書化し、今後、初めてセットアップを担当することになる他のユーザーを支援します。
- データ ソースの接続をテストする: 概念実証を開始するために、適切なデータに接続する適切なコンポーネントとプロセスが設定されていることを検証します。
手順 3: 概念実証を実施する
プロジェクト チームは、未解決の前提を検証し、ビジネス ユーザーにとっての早期の利点を実証するために、ソリューションの "概念実証 (POC)" を実施します。 POC は、範囲と成熟度が限定された初期設計実装です。 POC の適切な実行が特に重要なのは、大規模な、または複雑なソリューションの場合です。なぜなら、技術設計では検出されなかった複雑さ (または例外) を特定し、対処する可能性があるからです。
POC を準備するときは、次の考慮事項を含めることをお勧めします。
- ゴールと範囲: ソリューションの POC の目的と、それに対処する機能領域について説明します。 たとえば、プロジェクト チームは、1 つの職務領域、または特定の要件または機能のセットに POC を制限することを決定できます。
- ソース データ: POC で使われるデータを特定します。 ソリューションによっては、次のようにさまざまな種類のデータを使うことをプロジェクト チームが決定する場合があります。
- 運用環境 (実際の) データ
- サンプル データ
- 運用環境で観測された実際のデータ量と複雑さと似ている、生成した合成データ
- デモ: プロジェクト チームが関係者とユーザーに POC を実演する方法とタイミングについて説明します。 デモは、定期的な更新時、または POC が特定の職務の条件を満たす場合に行うことがあります。
- 環境: プロジェクト チームが POC を構築する場所について説明します。 POC に個別の "サンドボックス" 環境を使い、準備ができたら開発環境に展開することをお勧めします。 サンドボックス環境は、ポリシーの柔軟性とコンテンツの流動性が高く、短時間での結果の生成に重点を置いています。 これに対し、開発環境は、コラボレーションを可能にするより構造化されたプロセスに従い、特定のタスクの完了に重点を置いています。
- 成功条件: POC が成功し、次の反復に進んで正式な開発を開始する必要があるしきい値を定義します。 POC を開始する前に、プロジェクト チームは、POC が成功する場合の明確な条件を特定する必要があります。 プロジェクト チームは、これらの条件を事前に設定することで、POC 開発が終了するタイミングと、反復的な開発と検証のサイクルが始まるタイミングを定義します。 POC のゴールに応じて、プロジェクト チームは次のようにさまざまな成功条件を設定できます。
- 関係者による POC の承認
- 特性または機能の検証
- 一定の開発時間が経過した後の同僚による POC の良好なレビュー
- 失敗: プロジェクト チームが POC の失敗を特定できることを確認します。 早い段階で失敗を特定することは、根本原因の調査に役立ちます。 また、運用環境に展開するときに想定どおりに機能しないソリューションへのさらなる投資を回避するのにも役立ちます。
注意事項
プロジェクト チームが POC を実施するときは、前提と制約に関するアラートを保持する必要があります。 たとえば、プロジェクト チームは、少量のデータ セットを使ってソリューションのパフォーマンスとデータ品質を簡単にテストすることはできません。 さらに、POC の範囲と目的が、ビジネス ユーザーに確実に理解されるようにします。 POC は初回の反復であることを必ず伝え、運用ソリューションでないことを強調します。
Note
詳細については、「Power BI に移行するための概念実証を実施する」を参照してください。
チェックリスト - POC を作成するときの主な決定事項とアクションは次のとおりです。
- ゴールを定義する: POC のゴールが、関係者全員に確実に理解されるようにします。
- POC の範囲を定義する: POC の作成に開発の労力がかかりすぎないようにすると同時に、価値を提供し、ソリューション設計をデモできるようにします。
- 使うデータを決定する: POC の作成に使うソース データを特定し、決定が妥当であることを示し、潜在的なリスクと制約の概要を説明します。
- いつ、どのように POC をデモするかを決める: 意思決定者やビジネス ユーザーに POC をプレゼンテーションして進行状況を示す計画を立てます。
- POC の終了時期を明確にする: 必ずプロジェクト チームが POC の明確な結論を決定し、正式な開発サイクルに移行する方法を説明します。
手順 4: コンテンツを作成して検証する
POC が成功すると、プロジェクト チームは、POC からコンテンツの作成と検証に移行します。 プロジェクト チームは、反復的な開発と検証のサイクルで BI ソリューションを開発できます。 これらのサイクルは、プロジェクト チームが開発環境にコンテンツを作成し、テスト環境にリリースするという、反復的なリリースで構成されます。 開発中に、プロジェクト チームは、パイロット プロセスのユーザー コミュニティをテスト環境の初期 (ベータ) バージョンのソリューションに段階的にオンボードします。
ヒント
反復的なリリースにより、早期の検証とフィードバックを促進します。こうすることで、変更要求を軽減し、ソリューションの導入を促進し、運用リリース前にベネフィットを実現できます。
反復的な開発と検証のサイクルは、プロジェクト チームが定義済みの結論に達するまで続行されます。 通常、開発は、実装する機能や対処するユーザー フィードバックがなくなった時点で完了します。 開発と検証のサイクルが完了すると、プロジェクト チームは最終的な運用リリースでコンテンツを運用環境に展開します。
次の図は、プロジェクト チームが開発と検証のサイクルで BI ソリューションを繰り返しリリースする方法を示しています。
この図は、次のステップを示しています。
| Item | 説明 |
|---|---|
|
プロジェクト チームは、各リリースをユーザー コミュニティに伝え、変更と新機能について説明します。 理想的には、コミュニケーションにはソリューションのデモと Q&A を含めて、ユーザーがリリースの新機能を理解し、口頭でフィードバックを提供できるようにします。 |
|
検証中、ユーザーは中央のツールまたはフォームを介してフィードバックを提供します。 プロジェクト チームはフィードバックを定期的に確認して問題に対処し、要求を受け入れるか拒否し、今後の開発フェーズを通知する必要があります。 |
|
プロジェクト チームはソリューションの使用状況を監視して、ユーザーがテストしていることを確認します。 使用されていない場合、プロジェクト チームは、ユーザー コミュニティとやり取りし、理由を理解してもらう必要があります。 低い使用率は、プロジェクト チームがさらに有効化と変更管理の措置をとる必要がある可能性を示しています。 |
|
プロジェクト チームは、ユーザーのフィードバックに速やかに対応します。 プロジェクト チームがフィードバックの対処に時間がかかりすぎると、ユーザーはフィードバックを提供するやる気をすぐに失う可能性があります。 |
|
プロジェクト チームは、受け入れられたフィードバックをソリューション計画に組み込みます。 必要に応じて、計画の優先順位を確認し、次の開発フェーズが始まる前にタスクを明確にして委任します。 |
|
プロジェクト チームは、次のリリースに向けてソリューションの開発を続けます。 |
|
プロジェクト チームは、定義済みの結論に達し、ソリューションを運用環境に展開する準備が整うまで、すべての手順を繰り返し実行します。 |
以下のセクションでは、反復的な開発と検証のサイクルを使って BI ソリューションをリリースするための重要な考慮事項について説明します。
コンテンツを作成する
プロジェクト チームは、通常の開発ワークフローに従ってソリューションを開発します。 ただし、コンテンツを作成するときは、次の点を考慮する必要があります。
- 各開発サイクル中に、ドキュメントを更新してソリューションについて説明します。
- 各開発サイクルを完了する際には、ユーザー コミュニティに通知します。 通知は一元化されたポータルに投稿し、各リリースの変更と新機能の簡単な説明を提供する必要があります。
- リリースごとに、ユーザー コミュニティに変更と新機能をデモし、口頭での質問に回答するセッションを開催することを検討してください。
- 反復的な開発と検証のサイクルをいつ完了するかを定義します。 サポートと導入アクティビティへの移行など、ソリューションを運用環境に展開するための明確なプロセスがあることを確認します。
コンテンツの検証
個々の反復的な開発サイクルは、コンテンツの検証で締めくくるようにします。 BI ソリューションの場合、通常は 2 種類の検証があります。
- 開発者検証: ソリューションのテストは、コンテンツ作成者と同僚によって行われます。 開発者検証の目的は、ソリューションがビジネス ユーザーに提供される前に、重要かつ明らかな問題をすべて特定して解決することです。 問題は、データの正確性、機能、またはユーザー エクスペリエンスに関係する場合があります。 開発しなかったコンテンツ作成者が検証するのが理想的です。
- ユーザー検証: ソリューションのテストはユーザー コミュニティによって行われます。 ユーザー検証の目的は、後期の反復に関するフィードバックを提供し、開発者が見つけなかった問題を特定することです。 通常、正式なユーザー検証期間は、ユーザー受け入れテスト (UAT) と呼ばれます。
重要
データ品質の問題は、開発者検証中に (UAT の前に) 確実に解決しておきます。 このような問題があると、ソリューションへの信頼を簡単に損ない、長期的な導入に悪影響を及ぼす可能性があります。
ヒント
ユーザー検証を実施する場合は、折に触れて主要なユーザーと電話で少し話すことを検討してください。 ソリューションがどのようなときに使われるかを観察します。 使いにくいと感じる点や、ソリューションのどの部分が期待どおりに機能していないかについてメモを取ります。 フィードバックを収集するには、このアプローチが効果的な方法です。
プロジェクト チームがコンテンツを検証するときは、次の考慮事項を含めます。
- ユーザーのフィードバックを促進する: リリースごとに、ユーザーにフィードバックを提供するように求め、効果的に行う方法を示します。 最近の変更や新機能につながったフィードバックや要求の例を定期的に共有することを検討します。 例を共有することで、フィードバックが認められ、評価されることを示します。
- 大きな要求を分離する: 一部のフィードバック項目は、より多くの労力が対処に必要です。 プロジェクト チームがこのような項目を特定し、それらを実装するかどうかを話し合うことができることを確認します。 後期の戦術計画セッションで議論する大きな要求を文書化することを検討します。
- 変更管理アクティビティを開始する: ソリューションの使用方法をユーザーにトレーニングします。 新しいプロセス、新しいデータ、異なる作業方法にはさらに労力をかけます。 変更管理への投資には、長期的なソリューション導入にプラスの効果があります。
ソリューションが定義済みレベルの完成度と成熟度に達したら、プロジェクト チームが運用環境に展開する準備が整います。 展開後、プロジェクト チームは、反復的なリリースから運用ソリューションのサポートと監視に移行します。
Note
開発とテストは、ソリューションと推奨されるワークフローに応じて変わります。
この記事では、大まかな計画と実行可能な項目についてのみ説明します。 反復的な開発とテストのサイクルの詳細については、「Power BI に移行するコンテンツを作成する」を参照してください。
チェックリスト - コンテンツを作成して検証する場合、主な決定事項とアクションは次のとおりです。
- 反復的なプロセスを使ってタスクの計画と割り当てを行う: ソリューションのリリースごとにタスクの計画と割り当てを行います。 タスクの計画および割り当てプロセスが柔軟であり、ユーザーのフィードバックを取り入れていることを確認します。
- コンテンツ ライフサイクル管理を設定する: ツールとプロセスを使って、ソリューションの展開と変更管理を効率化および自動化します。
- フィードバックを一元化するツールを作成する: 自分とユーザーにとってシンプルなソリューションを使って、フィードバックの収集を自動化します。 フィードバックが簡潔で実用的になるように、簡単なフォームを作成します。
- 会議をスケジュールしてフィードバックを確認する: 会議を開き、新規または未処理のフィードバック項目を簡単に確認します。 フィードバックを実装するかどうか、実装を担当するユーザー、フィードバック項目を完了するアクションを決定します。
- 反復的なリリースの完了時期を決定する: 反復的なリリースのサイクルを完了する時期、運用環境にコンテンツをリリースする時期の条件を説明します。
手順 5: 展開、サポート、監視
準備ができたら、プロジェクト チームは検証済みのソリューションを運用環境に展開します。 プロジェクト チームは、展開が成功するように、主要な導入とサポートのアクションを実行する必要があります。
展開が成功するように、次のサポートと導入のタスクを実行します。
- 最終リリースを伝える: エグゼクティブ スポンサー、マネージャー、または十分な権限と信頼性を持つ別の個人が、リリースをユーザー コミュニティに発表する必要があります。 コミュニケーションは明確かつ簡潔にして、関連するソリューションとサポート チャネルへのリンクを含める必要があります。
- コンテンツ コンシューマー向けにトレーニングを実施する: 運用環境へのリリース後の最初の数週間は、コンテンツ コンシューマーがトレーニングを利用できるようにします。 トレーニングは、ソリューション範囲の明確化、ユーザーからの質問への回答、ソリューションの使用方法の説明に重点を置くようにします。
- フィードバックと要求に対処する: フィードバックと要求をプロジェクト チームに送信するためのチャネルをユーザーに提供することを検討します。 必ず適切なフィードバックと要求について話し合い、必要に応じて展開後のサポート期間中に実装します。 運用リリース後にフィードバックと要求に対応することが重要です。 これは、変化するビジネス ニーズに対応するアジャイル ソリューションを示しています。
- ユーザー コミュニティとつながることを計画する: 展開後のサポート期間が終了した後も、ソリューション所有者はユーザー コミュニティと定期的に会議するようにします。 こうした会議は、BI 戦略を改訂するための貴重なフィードバックの源です。 また、ユーザーを可能にすることで、ソリューションの導入をサポートするのにも役立ちます。
- アクションを引き継ぐ: プロジェクト チームのメンバーは、ソリューションの保守を担当しない場合があります。 この場合、チームは担当者を特定し、引き継ぎを実施する必要があります。 引き継ぎは、運用環境へのリリース直後に行い、ソリューションとユーザー コミュニティの両方に対処するようにします。
注意事項
効果的な引き継ぎを実施しないと、ライフサイクル中にソリューションのサポートと導入に関する予防可能な問題が発生する可能性があります。
展開後、プロジェクト チームは、優先順位を付けたソリューション バックログの次のソリューションに進む計画を立てる必要があります。 必要に応じて、新しいフィードバックと要求を収集し、戦術計画 (ソリューション バックログを含む) を改訂します。
チェックリスト - ソリューションの展開を検討する場合、主な決定事項とアクションは次のとおりです。
- コミュニケーション計画を作成する: リリース、トレーニング、その他のソリューション サポートや導入アクションを伝える方法を計画します。 展開後のサポート期間中に機能停止や問題が発生した場合は必ず連絡し、速やかに対処します。
- トレーニング計画に従う: ソリューションを使うようにユーザーをトレーニングします。 リリース後の数週間は、トレーニングにライブと録画両方のトレーニング セッションを含めるようにします。
- 引き継ぎアクティビティを実施する: 必要に応じて、開発チームからサポート チームへの引き継ぎを準備します。
- ソリューションの業務時間を実施する: 展開後のサポート期間が終わったら、定期的な業務時間セッションを開催して質問に回答し、ユーザーからのフィードバックを収集することを検討します。
- 継続的な改善プロセスを設定する: ソリューションの毎月の監査をスケジュールして、時間の経過に伴う変更や改善の可能性を確認します。 ユーザーのフィードバックを一元化し、監査の間にフィードバックを定期的に確認します。
関連するコンテンツ
Power BI の実装の決定に役立つ考慮事項、アクション、意思決定基準、推奨事項について詳しくは、「Power BI 実装計画」をご覧ください。