Power BI に移行するための要件を収集する

この記事では、Power BI に移行する場合の要件の収集と優先順位付けに関するステージ 1 について説明します。

Note

上の図の詳細については、「Power BI への移行の概要」を参照してください。

ステージ 1 の焦点は、Power BI に移行される個々のソリューションに関する情報収集と計画にあります。

ステージ 1 の成果には、優先順位が付けられた詳細な要件などがあります。 ただし、このレベルの作業を完全に見積もるには、ステージ 2 および 3 の追加アクティビティを完了する必要があります。

重要

ステージ 1 から 5 は、1 つの特定のソリューションに関連するアクティビティを表します。 組織やテナント レベルでは、ソリューション レベルでのプロセスに影響を与える意思決定とアクティビティがあります。 このような上位レベルの計画アクティビティの一部については、「Power BI への移行の概要」で説明されています。 効率と一貫性のために、必要に応じて、組織レベルの意思決定に従ってください。

Fabric 導入ロードマップのページでは、このような種類の戦略的および戦術的な考慮事項について説明しています。 ここでは、組織の導入に重点を置いています。

ヒント

この記事で説明するほとんどのトピックは、標準の Power BI 実装プロジェクトにも適用されます。

要件をまとめる

移行前の手順でまとめられた既存の BI 項目のインベントリは、Power BI で作成される新しいソリューションの要件に役立つ情報になります。 要件の収集とは、現状だけでなく、Power BI でレポートのデザインを変更するときにユーザーが変更またはリファクタリングしたい項目を把握することです。 詳細な要件があると、ステージ 2 のソリューション導入計画、ステージ 3 の概念実証の作成時、ステージ 4 の運用環境対応のソリューションを作成するときに役立ちます。

レポートの要件を収集する

次のように、レポートに関する詳細で参照しやすい情報をまとめます。

• 目的、対象ユーザー、予想されるアクション: 各レポートに適用される目的とビジネス プロセスだけでなく、対象ユーザー、分析ワークフロー、レポートのコンシューマーが実行すると予想されるアクションを特定します。
• コンシューマーがレポートを使用する方法: 正確な使用方法を理解できるように、既存のレポートのレポート コンシューマーの立場に立って検討します。 新しい Power BI バージョンでは、レポートの特定の要素を削除または改善できることがわかります。 このプロセスには追加の時間投資が必要ですが、重要なレポートや頻繁に使用されるレポートの場合は大切です。
• 所有者と分野の専門家: レポートの所有者と、レポートまたはデータの領域に関連する分野の専門家を特定します。 今後、新しい Power BI レポートの所有者になる可能性があります。 具体的な変更管理要件 (通常、IT 管理ソリューションとビジネス管理ソリューションでは異なります) と、将来的に変更が行われるときに必要になる承認とサインオフを含めます。 詳細については、 こちらの記事を参照してください。
• コンテンツ配信方法: コンテンツ配信に対するレポート コンシューマーの期待を明確にします。 オンデマンド、対話型の実行、カスタム アプリケーション内への埋め込み、または電子メール サブスクリプションを使用したスケジュールでの配信を行うことができます。 アラート通知をトリガーする要件がある場合もあります。
• 対話機能の必要性: フィルター、ドリルダウン アクション、ドリルスルー アクションなど、対話機能について "必須のもの" と "あるとよいもの" の要件を判断します。
• データ ソース: 確実に、レポートに必要なすべてのデータ ソースが検出され、データの待機時間のニーズ (データの鮮度) が理解されているようにします。 各レポートの履歴データ、トレンド、データ スナップショットの要件を特定して、データ要件に合わせて調整できるようにします。 データ ソースのドキュメントは、ソース データを使用して新しいレポートのデータ検証を実行するときにも役立ちます。
• セキュリティ要件: 通常の組織のセキュリティに対する例外を含め、セキュリティ要件 (許可される閲覧者、許可される編集者、行レベルのセキュリティ ニーズなど) を明確にします。 データの秘密度レベル、データのプライバシー、または規制やコンプライアンスのニーズを文書化します。
• 計算、KPI、ビジネス ルール: 既存のレポート内で現在定義されているすべての計算、KPI、ビジネス ルールを特定して文書化し、データ要件に合わせて調整できるようにします。
• 使いやすさ、レイアウト、外観の要件: データの視覚化、グループ化と並べ替えの要件、条件付きの表示に関連する、具体的な使いやすさ、レイアウト、外観のニーズを特定します。 モバイル デバイスの配信に関連する具体的な考慮事項を含めます。
• 印刷とエクスポートのニーズ: エクスポートまたは印刷可能なレイアウトに固有の要件があるかどうかを判断します。 このようなニーズは、最適な種類のレポートに影響します (Power BI、Excel、またはページ分割されたレポートなど)。 レポート コンシューマーは、いつものやり方を重視する傾向があることにご注意ください。その考え方に疑問を投げかけることを恐れないでください。 必ず、"変更" ではなく "強化" という観点で話してください。
• リスクまたは懸念事項: レポートに他の技術的または機能的な要件があるかどうか、また、レポートに表示される情報に関するリスクや懸念事項があるかどうかを判断します。
• 未解決の問題とバックログ項目: 現時点でバックログに追加する将来的なメンテナンス、既知の問題、または延期されるリクエストを特定します。

ヒント

"必須のもの" または "あるとよいもの" に分類して、要件にランクを付けることを検討します。 多くの場合、コンシューマーは、要求を行う唯一の機会であると考えるため、必要な可能性があるすべてのものを事前に要求します。 また、何度も優先度に対処する場合は、関係者がバックログを使用できるようにします。 コミュニケーション、意思決定、保留中のコミットメントの追跡に役立ちます。

データ要件を収集する

次のようなデータに関する詳細情報をまとめます。

• 既存のクエリ:DirectQuery モデルまたは複合モデルで使用できる、またはインポート モデルに変換できる既存のレポート クエリまたはストアド プロシージャがあるかどうかを特定します。
• データ ソースの種類: 集中管理されたデータ ソース (エンタープライズ データ ウェアハウスなど) や非標準データ ソース (レポート用にエンタープライズ データ ソースを拡張するフラット ファイルや Excel ファイルなど) を含む、必要なデータ ソースの種類をまとめます。 データ ゲートウェイ接続のために、データ ソースの場所を見つけることも重要です。
• データ構造とクレンジングのニーズ: 必要な各データ ソースのデータ構造と、データ クレンジング アクティビティが必要な範囲を判断します。
• データ統合: 複数のデータ ソースがある場合のデータ統合の処理方法と、各モデル テーブル間のリレーションシップの定義方法を評価します。 モデルを単純化し、そのサイズを縮小するために必要な具体的なデータ要素を特定します。
• 許容されるデータ待機時間: 各データ ソースのデータ待機時間のニーズを判断します。 使用するデータ ストレージ モードに関する判断に影響します。 インポート モデル テーブルのデータ更新頻度も把握しておくことが重要です。
• データの量とスケーラビリティ: データ量の予測を評価します。これは、大規模モデルのサポートと、DirectQuery または複合モデルの設計に関する判断の要因となります。 履歴データのニーズに関する考慮事項も理解しておく必要があります。 大規模なセマンティック モデル (旧称はデータセット) の場合、増分データ更新を判断することも必要になります。
• メジャー、KPI、ビジネス ルール: メジャー、KPI、ビジネス ルールのニーズを評価します。 これらは、ロジックを適用する場所 (セマンティック モデルまたはデータ統合プロセス) に関する判断に影響を与えます。
• マスター データとデータ カタログ: 注意が必要なマスター データの問題があるかどうかを検討します。 エンタープライズ データ カタログとの統合が、検出可能性の向上、定義へのアクセス、または組織で受け入れられる一貫した用語の作成に適しているかどうかを判断します。
• セキュリティとデータ プライバシー:行レベルのセキュリティ要件など、セマンティック モデルに固有のセキュリティまたはデータ プライバシーの考慮事項があるかどうかを判断します。
• 未解決の問題とバックログ項目: 現時点で既知の問題、データ品質に関する既知の欠陥、将来のメンテナンス、または延期されるリクエストをバックログに追加します。

重要

データの再利用は、共有セマンティック モデルを使って実現できます。これは、信頼性を示し、検出性を高めるために、必要に応じて認定できます。 データフローを使用してデータ準備の再利用を実現し、複数のセマンティック モデル内の反復ロジックを減らすことができます。 また、データが取得される頻度が低くなるため、データフローによってソース システムの負荷を大幅に削減できます。複数のセマンティック モデルを使って、データフローからデータをインポートすることができます。

改善の機会を特定する

ほとんどの場合、いくつかの変更と改善が行われます。 リファクタリングや拡張を行わずに、1 対 1 の直接の移行が行われることはまれです。 次の 3 種類の機能強化を検討できます:

• レポートの統合: 同様のレポートは、フィルター、ブックマーク、個人用設定などの手法を使用して統合される場合があります。 レポートの数が少ないほど、柔軟性が増し、レポート コンシューマーのエクスペリエンスが大幅に向上します。 レポート コンシューマーがより柔軟に、独自の視覚エフェクトを作成できるよう、Q&A (自然言語クエリ) 用のセマンティック モデルを最適化することを検討してください。
• 効率の向上: 多くの場合、要件の収集中に改善点を特定できます。 たとえば、アナリストが数値を手動でまとめている場合や、ワークフローを合理化できる場合などです。 Power Query は、現在実行されている手動のアクティビティを置き換える上で大きな役割を果たすことができます。 ビジネス アナリストが、同じアクティビティを定期的に実行してデータをクレンジングおよび準備していることに気付いた場合は、繰り返し可能な Power Query データ準備手順により、大幅な時間の節約とエラーの削減を実現できます。
• データ モデルの一元化: 権限のある認定されたセマンティック モデルは、管理されたセルフサービス BI のバックボーンとして機能します。 この場合、データは 1 回だけ管理され、アナリストは、レポートや分析のニーズに合うようにそのデータを柔軟に使用および拡張できます。

注意

データ モデルの一元化の詳細については、「中核部での統制」と「エッジにおける柔軟性」を参照してください。

複雑さの優先順位付けと評価

この時点で、初期インベントリは使用可能であり、特定の要件が含まれる場合があります。 移行の準備が整った最初の BI 項目のセットに優先順位を付ける場合、複数のレポートとデータをまとまったものとして、または相互に独立したものとして検討する必要があります。

次のようなレポートが含まれる場合がある、優先度の高いレポートを特定します:

• ビジネスに大きな価値をもたらす。
• 頻繁に実行される。
• 上位の指導者や経営幹部が必要としている。
• 適度なレベルの複雑さを伴う (最初の移行の反復時に成功する可能性を高めるため)。

次のデータが含まれる場合がある、優先度の高いデータを特定します:

• 重要なデータ要素が含まれている。
• 多くのユース ケースに役立つ一般的な組織データである。
• レポートや多くのレポート作成者が再利用する共有セマンティック モデルを作成するために使用できます。
• 適度なレベルの複雑さを伴う (最初の移行の反復時に成功する可能性を高めるため)。

関連するコンテンツ

この Power BI 移行シリーズの次の記事では、1 つの Power BI ソリューションの移行を計画する場合に関連するステージ 2 について説明します。

その他の役に立つリソースは次のとおりです。

• Microsoft の BI 変換
• Power BI 実装計画
• わからないことがある場合は、 Power BI コミュニティで質問してみてください。
• Power BI チームへのご提案は、 Power BI を改善するためのアイデアをお寄せください

経験豊富な Power BI パートナーを活用して、組織の移行プロセスを成功させることができます。 Power BI パートナーを手配するには、Power BI パートナー ポータルにアクセスしてください。