Power BI に移行するための概念実証を実施する

  • [アーティクル]

この記事ではステージ 3 について説明します。これは、Power BI への移行時にできるだけ早期にリスクを軽減して不明な部分に対処するための概念実証 (POC) の実施に関係します。

Diagram shows the stages of a Power BI migration. Stage 3 is emphasized for this article.

Note

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

ステージ 3 の焦点は、できるだけ早期に不明な部分に対処してリスクを軽減することです。 技術的な POC は、前提条件の検証に役立ちます。 これは、ソリューションの展開計画と共に繰り返し実行できます (ステージ 2に関するページを参照)。

このステージからの出力は、スコープが絞り込まれた Power BI ソリューションであり、最初のオープンな質問に対処し、実稼働に対応するためのステージ 4 での追加作業を行う準備ができています。

重要

POC を廃棄可能な作業にすることは意図していません。 むしろ、実稼働の準備ができているソリューションの早期のイテレーションとなることが期待されています。 組織では、このアクティビティをプロトタイプ、パイロット、モックアップ、クイック スタート、または最小限の実行可能な製品 (MVP) と見なす場合があります。 POC の実施は必ずしも必要ではなく、非公式に行うこともできます。

ヒント

この記事で説明するほとんどのトピックは、標準の Power BI 実装プロジェクトにも適用されます。 Power BI に関する組織の経験が豊かになるにつれて、POC を実施する必要性が低下していきます。 ただし、Power BI を使用した迅速なリリースの進行と、新機能の継続的な導入により、学習目的で技術的な POC を定期的に実施する場合があります。

POC の目標とスコープを設定する

POC を実施する場合は、次の目標に焦点を当ててください。

  • 機能の動作に関する前提事項を確認する。
  • Power BI の動作が従来の BI プラットフォームとどのように異なるかについて学習する。
  • 特定の要件に対する初期段階での理解を、分野の専門家と共に検証する。
  • データ構造、リレーションシップ、データ型、またはデータ値に関する問題を理解し、検出するために、実際のデータを含む小規模なセマンティック モデル (旧称はデータセット) を作成する。
  • モデルの計算で使用される DAX 構文式を試し、検証する。
  • ゲートウェイを使用してデータ ソース接続をテストする (ゲートウェイ ソースにする場合)。
  • ゲートウェイを使用してデータ更新をテストする (ゲートウェイ ソースにする場合)。
  • 行レベルのセキュリティを含め (該当する場合)、セキュリティ構成を確認する。
  • レイアウトと見栄えの決定を試してみる。
  • Power BI サービスのすべての機能が想定どおりに動作することを確認する。

POC のスコープは、不明な部分、または同僚と共に検証する必要がある目標に依存します。 複雑さを軽減するには、スコープの観点から POC をできるだけ絞り込みます。

移行時には多くの場合、開始点として既存のソリューションがあるため、要件はよく知られています。 ただし、改善の程度や既存の Power BI スキルによっては、POC からも重要な価値が得られます。 さらに、特に機能強化が行われた場合は、迅速に要件を明確にするために、コンシューマーからのフィードバックを含む迅速なプロトタイプを作成することが適切な場合があります。

重要

POC にデータのサブセットのみが含まれる場合や、限られたビジュアルのみが含まれる場合でも、多くの場合、最初から最後まで実行することが重要です。 つまり、Power BI Desktop での開発から、Power BI サービスの開発ワークスペースへの展開までが対象となります。 それが、POC の目標を完全に達成する唯一の方法です。 これは特に、シングル サインオンを使用する DirectQuery セマンティック モデルなど、以前に使用していない重要な機能を Power BI サービスで提供する必要がある場合に当てはまります。 POC では、不確かな側面、または他のユーザーと共に確認する必要がある側面に作業の焦点を当てます。

Power BI の相違点を処理する

Power BI は、"モデルベースのツール" または "レポートベースのツール" として使用できます。 モデルベースのソリューションでは、データ モデルの開発を行います。一方、レポートベースのソリューションでは、既に展開されているデータ モデルに接続します。

Power BI は柔軟性が非常に高いため、移行元の従来の BI プラットフォームとは根本的に異なる可能性のあるいくつかの側面があります。

データ アーキテクチャの再デザインを検討する

独自のセマンティック レイヤーを持つ従来の BI プラットフォームから移行する場合は、インポート セマンティック モデルの作成が適切である可能性が高くなります。 Power BI は、スター スキーマのテーブル デザインで最適に機能します。 そのため、従来の セマンティック レイヤーがスター スキーマでない場合は、Power BI のメリットを十分に活用するために再設計が必要になる可能性があります。 スター スキーマ デザインの原則に準拠するセマンティック レイヤー (リレーションシップ、一般的に使用されるメジャー、わかりやすい組織用語など) を定義するための作業は、セルフサービスレポート作成者にとって優れた出発点となります。

SQL クエリまたはストアド プロシージャを使用してレポートがリレーショナル データ ソースを参照する従来の BI プラットフォームから移行する場合、および Power BI を DirectQuery モードで使用する予定がある場合は、データ モデルの 1 対 1 の移行に近い状態を実現できる可能性があります。

注意事項

インポートされた 1 つのテーブルを構成する多数の Power BI Desktop ファイルが作成されている場合は、通常、デザインが最適でないことを意味します。 このような状況が発生した場合は、スター スキーマ デザインを使用して作成された共有セマンティック モデルを使用することで結果を改善できるかどうかを調査します。

ダッシュボードの変換を処理する方法を決定する

BI 業界では、ダッシュボードは、1 つのページに主要なメトリックスを表示するビジュアルのコレクションです。 ただし、Power BI のダッシュボードは、Power BI サービスでのみ作成できる特定の視覚化機能を表します。 従来の BI プラットフォームからダッシュボードを移行する場合は、次の 2 つの選択肢があります。

  1. 従来のダッシュボードを Power BI "レポート" として再作成できます。 ほとんどのレポートは Power BI Desktop で作成されます。 ページ分割されたレポートと Excel レポートも代替オプションとなります。
  2. 従来のダッシュボードを Power BI "ダッシュボード" として再作成できます。 ダッシュボードは、Power BI サービスの視覚化機能です。 ダッシュボードのビジュアルは、多くの場合、1 つまたは複数のレポート、Q&A、またはクイック分析情報からビジュアルをピン留めすると作成されます。

ヒント

ダッシュボードは Power BI のコンテンツの種類であるため、レポートまたはダッシュボードの名前に "ダッシュボード" という語を使用しないようにしてください。

ビジュアルを再作成するときに全体像に焦点を当てる

すべての BI ツールには、長所と重点領域があります。 このため、従来の BI プラットフォームで依存していた正確なレポート ビジュアルは、Power BI ではほぼ同等ではない可能性があります。

レポートのビジュアルを再作成するときは、レポートで処理されているビジネス上の問題の全体像に焦点を当てます。 これにより、すべてのビジュアルのデザインをまったく同じ方法でレプリケートしなければならないというプレッシャーから解放されます。 コンテンツの利用者は、移行されたレポートを使用するときに一貫性を評価しますが、些細なことにこだわって時間を浪費しないようにすることが重要です。

関連するコンテンツ

この Power BI 移行シリーズの次の記事では、Power BI への移行時におけるコンテンツの作成と検証に関係するステージ 4 について説明します。

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

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