Power BI ダッシュボード開発の完全ガイド

Power BI ダッシュボードの構築は簡単です。人々が実際に使用し、信頼し、日々の意思決定に依存するものを構築することは、まったく異なる分野です。機能的なダッシュボードと効果的なダッシュボードとの間にギャップがあるため、利用可能な分析がわかりにくく解析できないため、組織はデータの誤解、レポートの無視、直感に基づいた意思決定に何千時間ものコストを費やすことになります。

このガイドでは、適切な KPI の定義や最適な視覚化の選択から、ドリルスルー ナビゲーション、ブックマーク、モバイル レイアウト、行レベルのセキュリティ、自動更新スケジュールの実装まで、Power BI ダッシュボード開発のライフサイクル全体をカバーしています。初めてのエグゼクティブ スコアカードを作成する場合でも、何百ものレポートを含む広大な分析環境を再設計する場合でも、ここでの原則に従えば、大幅なやり直し作業を省くことができます。

重要なポイント

• 効果的なダッシュボードは、ビジュアル デザインではなく KPI の特定から始まります --- Power BI Desktop を開く前にダッシュボードがサポートする必要がある決定を定義します
• 各ダッシュボード ページのビジュアルを最大 5 ～ 7 に制限します。情報密度は理解の敵です
• ドリルスルー ページとブックマークにより、数十の個別レポートの必要性がなくなり、メンテナンスの負担が 60 ～ 70% 軽減されます。
• モバイル レイアウトには、応答性の高いスケーリングではなく、専用のデザインが必要です --- それらを別の成果物として扱います
• 行レベルのセキュリティ (RLS) により、コンテンツを複製することなく単一のレポートを複数の対象者に提供できます。
• 増分更新ポリシーを使用したスケジュールされた更新により、ゲートウェイ リソースを圧迫せずにダッシュボードを最新の状態に保ちます
• 最良のダッシュボードは、ユーザーが開いてから 5 秒以内に質問に回答します

---

設計前に KPI を定義する

KPI 特定フレームワーク

ダッシュボード開発で最もよくある間違いは、データから始めることです。チームは ERP または CRM からすべてをエクスポートし、Power BI にダンプし、興味深そうな列を中心にグラフを作成します。その結果、すべてが表示され、何も伝達されないダッシュボードが作成されます。

代わりに、ダッシュボードを使用するすべての関係者に対して 3 つの質問から始めます。

毎日または毎週どのような意思決定を行っていますか? 毎週月曜日の朝にパイプラインの健全性をレビューする営業ディレクターには、キャッシュ フローを四半期ごとに評価する CFO とは異なる指標が必要です。ダッシュボードをデータの可用性ではなく意思決定サイクルにマッピングします。

1 つの数字しか表示されない場合、どの数字を確認しますか? これにより、主要な KPI が明らかになります。物流管理者にとって、それは納期厳守率かもしれません。マーケティング担当副社長の場合は、資格のあるリードあたりのコストが考えられます。この数字は中心にあり、大きく、見逃せません。

その数値に関してどのようなコンテキストが必要ですか? 主要 KPI にはサポート指標が必要です。納期遵守率 94% は、先月が 91% (改善) だったのか、97% (低下) だったのかが分からなければ意味がありません。傾向線、前期比比較、目標ベンチマークがこのコンテキストを提供します。

Power BI に触れる前に、KPI を構造化された形式で文書化します。

KPI をビジュアル タイプにマッピングする

すべての指標が同じ視覚的扱いに値するわけではありません。 Power BI は 30 を超えるネイティブ ビジュアル タイプと数百のカスタム ビジュアルを提供しますが、ほとんどのダッシュボードに必要なのは 5 つまたは 6 つだけです。

単一数値 KPI の カード ビジュアル。これらは、ダッシュボード ページの上部にある大きく太字の数字です。条件付き書式設定を使用して、目標に対するパフォーマンスに基づいて色を変更します。順調な場合は緑色、警告の場合はオレンジ色、重大な場合は赤色です。サブタイトルまたは小さなトレンド指標を使用して、比較値 (対前回期間、対目標) をカードに直接含めます。

折れ線グラフ は、時間の経過に伴う傾向を示します。収益、量、パフォーマンスの指標はすべて、軌道を把握することで恩恵を受けます。折れ線グラフは最大 3 系列に制限します。それを超えると、色がぼやけてチャートが読めなくなります。 3 つ以上の系列を比較する必要がある場合は、代わりに小さな倍数 (個々の折れ線グラフのグリッド) を使用してください。

棒グラフはカテゴリ別比較用です。地域ごとの売上、製品ラインごとの収益、優先度ごとのチケット。横棒グラフは、カテゴリ ラベルが長い場合 (製品名、顧客名)、より適切に機能します。バーをアルファベット順ではなく、常に値で並べ替えます。目は最大値と最小値をすぐに見つけられるはずです。

詳細レベルのデータの テーブルとマトリックス。ユーザーが視覚的なパターンではなく特定の数字を確認する必要がある場合、表は正しい選択です。条件付き書式設定 (データ バー、カラー スケール、アイコン セット) を使用して、精度を犠牲にすることなく表形式のデータに視覚的な重みを追加します。

地図は、地理が意味のある次元である場合にのみ行われます。販売データが 40 か国にわたる場合、塗りつぶされた地図は棒グラフでは表現できない地理的なストーリーを伝えます。データが 3 つの地域をカバーしている場合は、マップをスキップしてください。スペースが無駄になり、洞察が得られません。

---

ダッシュボードのレイアウトとビジュアル デザイン

F パターン レイアウト

視線追跡調査では、ユーザーがダッシュボードを F パターンでスキャンしていることが一貫して示されています。つまり、上部から左側に向かって、右下に向かうほど注意力が低下します。それに応じてレイアウトを設計します。

上の行: カード ビジュアルの主要 KPI。これらはユーザーが目にするようになった数字です。明確なラベル、値、傾向インジケーターを使用して、大きく (高さ 200 ピクセル以上) にしてください。上部に 3 ～ 5 枚のカードを置くのが理想的です。

左の列: メインの分析ビジュアル --- 通常は、主要な傾向 (経時的な収益、経時的な注文、経時的なサポート チケット) を示す折れ線グラフです。これは物語を固定するビジュアルです。

中央エリア: 最上位の KPI の内訳を示すサポート ビジュアル。上の行に総収益が表示されている場合、中央の領域には製品カテゴリ別の収益、地域別の収益、および顧客セグメント別の収益が表示されます。

下のセクション: 詳細テーブル、二次メトリック、またはコンテキスト情報。この領域は最も注目されないため、優先度の低いデータをここに配置します。

カラー戦略

Power BI の既定のカラー パレットはプロトタイピングには許容できますが、運用ダッシュボードには不十分です。意図的な色戦略を定義します。

セマンティック カラー。 緑、琥珀、赤はパフォーマンス インジケーター (良好、警告、不良) 専用に予約してください。カテゴリデータにはこれらの色を決して使用しないでください。棒グラフが「北米」を緑、「ヨーロッパ」を赤とすると、データがそうではないとしても、ユーザーは無意識にヨーロッパのパフォーマンスが低いと解釈してしまいます。

ブランド カラー。 カテゴリ データには組織のブランド パレットを使用します。ブランドがネイビー ブルー、スレート グレー、ティールを使用している場合、それらが棒グラフと折れ線グラフの色になります。これにより、ダッシュボードは汎用の分析ツールではなく、組織のコミュニケーションの一部のように感じられます。

コンテキストのためのグレースケール。 ターゲット、ベンチマーク、および前期間の比較には明るいグレーを使用します。これらの参照線は表示される必要がありますが、注意を引くために主要なデータと競合してはなりません。

合計 5 ～ 6 色に制限します。 1 つのダッシュボード ページに 6 色を超える異なる色を使用すると、視覚的なノイズが発生します。データに 6 つを超えるカテゴリがある場合は、小さいカテゴリを「その他」にグループ化します。

ホワイトスペースと情報密度

ダッシュボード ページにビジュアルを追加すると、そのページ上の他のすべてのビジュアルの効果が低下します。これは意見ではなく、人間の注意力の働きです。 Nielsen Norman Group の調査によると、1 画面あたり 7 つの視覚要素を使用すると、ダッシュボードの理解力が急激に低下します。

ビジュアル間に意図的に空白を残します。 Power BI のグリッドへのスナップ機能は、一貫した間隔を維持するのに役立ちます。関連するビジュアルをグループ化するには、区切り線や微妙な背景の長方形を使用しますが、過度に使用しないでください。グループ化要素が多すぎると、それ自体が視覚的に乱雑になります。

5 ～ 7 個のビジュアルを備えた、適切にデザインされた単一ページのダッシュボードは、15 個のビジュアルを備えた乱雑なページよりも常にパフォーマンスが優れています。二次分析をメイン ビューに詰め込むのではなく、ドリルスルー ページに移動します。

---

ドリルスルー ページとナビゲーション

ドリルスルー ページの構築

ドリルスルーは、個別のレポートを作成せずに概要から詳細に移動するための Power BI のメカニズムです。ユーザーはデータ ポイント (製品、地域、顧客) を右クリックし、その選択内容に事前にフィルターされた詳細ページに移動します。

効果的なドリルスルー ページを作成するには:

ステップ 1: 詳細ページを作成します。 新しいページをレポートに追加します。 [視覚化] ペインで、ドリルスルー フィールド (製品名など) を [ドリルスルー] ウェルにドラッグします。 Power BI は、「戻る」ボタンを自動的に追加します。

ステップ 2: 詳細レイアウトをデザインします。 詳細ページでは、次のレベルの質問に答える必要があります。概要ページに製品ごとの収益が表示される場合、特定の製品のドリルスルー ページには、収益傾向、利益分析、その製品の上位顧客、および最近の注文が表示される場合があります。

ステップ 3: クロスフィルター コンテキストを追加します。 概要ページ上のスライサーまたはフィルターは、自動的にドリルスルー ページに適用されます。詳細ページのビジュアルがこれらのフィルターを尊重していることを確認してください --- 動作を確認するには、さまざまなスライサーの組み合わせでテストしてください。

ステップ 4: [戻る] ボタンをカスタマイズします。 デフォルトの [戻る] ボタンは小さく、見落としやすいです。これを、大きくてわかりやすいラベルの付いたボタンに置​​き換えます。より目立つナビゲーション要素を作成するには、アクションが「戻る」に設定されたテキスト ボックスまたは図形を使用します。

ビューのブックマークの実装

ブックマークは、レポート ページの状態、つまりどのフィルタが適用されているか、どのビジュアルが表示されているか、どの選択がアクティブであるかをキャプチャします。単一ページ内で複数の「ビュー」を有効にし、レポートの総ページ数を減らします。

一般的なブックマーク パターンは次のとおりです。

グラフと表を切り替えます。 グラフと表をページ上の同じ位置に配置します。 2 つのブックマークを作成します。1 つはグラフが表示され、表が非表示になり、もう 1 つは反転されます。それぞれのブックマークをアクティブにする「チャート ビュー」および「テーブル ビュー」というラベルのボタンを追加します。

プリセットされたフィルタの組み合わせ。 営業マネージャーは、「私の地域」と「すべての地域」の間、または「今四半期」と「年間累計」の間を素早く切り替えたい場合があります。ブックマークはこれらのフィルター状態をキャプチャでき、ページ上部のボタンの列を使用してワンクリックで切り替えることができます。

ガイド付き分析ナラティブ。 ユーザーにストーリーを説明する一連のブックマークを作成します。「全体的なパフォーマンス → 地域別の内訳 → 問題領域 → 推奨されるアクション」。 「次へ」ボタンを押すとシーケンスが進みます。このパターンは、ダッシュボードがスライド デッキとして機能するエグゼクティブ プレゼンテーションに特に効果的です。

ボタンによるページナビゲーション

Power BI では、ドリルスルーやブックマークのほかに、Web サイトのナビゲーション メニューのように機能するページ ナビゲーション ボタンがサポートされています。 「ページ ナビゲーション」アクションを持つ図形を使用して、すべてのレポート ページにわたって一貫したナビゲーション バーを作成します。

各ページの上部に、概要、販売、運営、財務、人事の各セクションのボタンを備えた水平ナビゲーション バーを設計します。条件付き書式または別の背景色を使用して、現在のページのボタンを強調表示します。これにより、複数ページのレポートが、紛らわしいタブの集合から構造化された分析アプリケーションに変換されます。

---

モバイル ダッシュボードのデザイン

レスポンシブだけでは不十分な理由

Power BI Desktop では、「モバイル レイアウト」ビューを使用して、任意のレポート ページのモバイル レイアウトを作成できます。これは実稼働ダッシュボードではオプションではありません。 Power BI コンテンツの 40% 以上がモバイル デバイスで使用されており、デスクにほとんどいないフィールド セールス チーム、幹部、運用マネージャーではその割合が増加します。

モバイル レイアウトは、デスクトップ レイアウトの応答性の高い再拡大縮小ではありません。これは意図的に作成する必要がある別のデザインです。同じビジュアルを垂直スタックに並べ替えるだけでは、モバイル エクスペリエンスが低下します。モバイル ダッシュボードには、さまざまな設計上の決定が必要です。

モバイル設計の原則

容赦なく優先順位を付けます。 デスクトップ ダッシュボード ページには 7 つのビジュアルが含まれる場合があります。モバイル版には 3 ～ 4 つあるはずです。最も重要な KPI と主要な分析ビジュアルのみを表示します。他のすべてを 2 次ページに移動します。

垂直に積み重ねてください。 モバイル画面は高くて狭いです。ビジュアルを 1 列に配置します。各ビジュアルはモバイル キャンバスの幅全体に広がり、目を細めずに読める程度の高さである必要があります。カードの場合は少なくとも 200 ピクセル、グラフの場合は 300 ピクセル以上です。

フォント サイズを大きくします。 27 インチのモニターでは 12 ピクセルで読めるテキストは、6 インチの携帯電話の画面では 12 ピクセルでは読めません。モバイル レイアウトですべてのテキスト サイズを 40 ～ 60% 拡大します。カードのビジュアル値は少なくとも 28 ピクセルである必要があります。軸ラベルは少なくとも 14 ピクセルである必要があります。

タップに適したインタラクションを使用します。 モバイルでは、ユーザーはホバーではなくタップします。ツールチップにアクセスするのが難しくなります。最も重要なデータが操作なしで表示されるようにします。ドリルスルーが必要な場合は、大きなタップ ターゲット (Apple のヒューマン インターフェイス ガイドラインに従って少なくとも 44 ピクセル四方) を備えた、明確にラベルが付けられたボタンを使用してください。

実際のデバイスでテストします。 Power BI モバイル アプリの動作は、Power BI Desktop のモバイル レイアウト プレビューとは若干異なります。デザインをサインオフする前に、レポートを Power BI サービスに発行し、iOS と Android の両方のモバイル アプリで開きます。横向きもチェックしてください。多くのユーザーは、チャートを見やすくするために携帯電話を回転させます。

モバイル固有のビジュアル

一部のビジュアルは他のビジュアルよりもモバイルでより適切に機能します。 KPI カード、ゲージ チャート、および単一値の表示は、一目で数値を伝えることができるため、優れています。折れ線グラフは、系列が 1 つまたは 2 つに限定されている場合に適切に機能します。ラベルが切り捨てられないように、モバイルでは棒グラフを水平にする必要があります。

モバイルではマトリックス ビジュアルを使用しないでください。水平スクロールが必要になるため、イライラさせられます。これらを、最も重要な列のみを表示するフィルター処理された表に置き換えるか、同じ比較を示す棒グラフを使用します。

---

行レベルのセキュリティ (RLS)

RLS が重要な理由

行レベルのセキュリティは、ユーザーに表示されるデータ行をユーザーの ID に基づいて制限します。 RLS を使用しないと、全員がすべてのデータを閲覧するか (セキュリティと機密性のリスク)、対象者ごとに重複したレポートを作成するか (メンテナンスの悪夢)、という 2 つの望ましくない選択肢に直面することになります。

RLS は、レポートを閲覧しているユーザーに基づいてフィルターを自動的に適用することで、この問題を解決します。地域の営業マネージャーは、自分の地域のデータのみを参照します。部門長は自分の部門の指標のみを参照します。 CFO はすべてを見ています。すべて同じレポートからのものです。

Power BI での RLS の実装

ステップ 1: Power BI Desktop でロールを定義します。 [モデリング] → [ロールの管理] → [作成] に移動します。ロールに名前を付けます (たとえば、「地域マネージャー」)。関連するテーブルに DAX フィルター式を追加します。

[Region] = USERPRINCIPALNAME()

より複雑なシナリオの場合は、ユーザーの電子メール アドレスを表示すべきデータにマッピングするセキュリティ テーブルを使用します。このアプローチは、ユーザー名をロール定義にハードコーディングするよりも保守しやすいです。

ステップ 2: セキュリティ マッピング テーブルを作成します。 データ モデルで、UserEmail の列とアクセスできるディメンション値 (地域、部門、コストセンター) を含む SecurityAccess というテーブルを作成します。このテーブルとファクト/ディメンション テーブル間のリレーションシップを作成します。

役割フィルター式は次のようになります。

[UserEmail] = USERPRINCIPALNAME()

このフィルターは SecurityAccess テーブルに適用されると、リレーションシップを通じて接続されているすべてのテーブルに伝播し、ユーザーを許可されたデータのみに制限します。

ステップ 3: Power BI Desktop でテストします。 モデリング → 表示形式を使用 → ロールを選択し、テスト ユーザー名を入力します。ビジュアルに予期したデータのみが表示されていることを確認します。エッジ ケースをテストします: 複数のリージョンにアクセスできるユーザー、一致する行がないユーザー (すべてのデータではなく、空白のビジュアルが表示されるはずです)、管理者ロール (すべてが表示されるはずです)。

ステップ 4: Power BI サービスのロールにユーザーを割り当てる。 公開後、データセット設定 → セキュリティ → Azure AD ユーザーまたはセキュリティ グループを各ロールに割り当てます。管理を容易にするために、個々のユーザーではなくセキュリティ グループを使用します。

動的 RLS パターン

複雑な階層を持つ組織では、静的な役割は扱いにくくなります。動的 RLS は、セキュリティ マッピング テーブルのアプローチを DAX 関数と組み合わせて使用​​し、階層アクセスを処理します。

マネージャー階層の一般的なパターン: SecurityAccess テーブルには、直接アクセス行と継承アクセス行の両方が含まれます。 3 つの地域マネージャーを管理する副社長は、3 つの地域すべてのデータを自動的に確認します。セキュリティ テーブルの DAX フィルターは、直接アクセス許可と継承されたアクセス許可の両方をチェックします。

CONTAINS(
    FILTER(SecurityAccess, SecurityAccess[UserEmail] = USERPRINCIPALNAME()),
    SecurityAccess[Region], Fact[Region]
)

このアプローチは、誰かが雇用、昇進、異動するたびに役割を変更する必要がなく、数百人のユーザーと複雑な組織図を持つ組織に拡張できます。

---

更新スケジュールとデータ パイプライン

スケジュールされた更新の構成

ダッシュボードに古いデータが含まれている場合は、ダッシュボードがない場合よりも悪いです。一度古い番号に遭遇したユーザーはダッシュボードを完全に信頼しなくなり、その信頼を再構築することはほぼ不可能です。

Power BI は、Premium 容量で 1 日あたり最大 48 件のスケジュールされた更新をサポートします (Pro では 1 日あたり 8 件)。意思決定サイクルに合わせて更新スケジュールを構成します。

朝の更新 (午前 6 時)。 夜間のデータを処理して、ユーザーが午前 8 時にダッシュボードを開いたときに昨日の全体像が表示されるようにします。これは最も一般的なパターンであり、ユースケースの 80% を満たします。

業務終了後の更新 (午後 5 時)。 退社前に毎日のパフォーマンスを確認するチームの 1 日のアクティビティをキャプチャします。営業チームが毎日の目標を追跡するのに役立ちます。

1 時間ごとに更新。 顧客サポートのキューの深さ、製造ラインのステータス、物流の追跡など、ほぼリアルタイムの認識が重要な運用ダッシュボード用に予約されています。プレミアム容量またはユーザーごとのプレミアム ライセンスが必要です。

増分更新

数百万行を超えるデータセットの場合、完全な更新は遅くなり、リソースが大量に消費されます。増分更新は、履歴データをキャッシュしたままにして、最近のデータ (たとえば、過去 7 日間) のみを更新するように Power BI に指示します。

日付列の RangeStart パラメーターと RangeEnd パラメーターを使用して、Power BI Desktop で増分更新を構成します。増分範囲 (過去 N 日間を更新) と履歴範囲 (過去 N 年間のデータを保持) を定義します。 Power BI はデータセットをパーティション分割し、増分範囲内にあるパーティションのみを更新します。

これにより、大規模なデータセットの更新時間が数時間から数分に短縮されます。 5,000 万のトランザクション行を持つ小売会社は、45 分で完全なデータセットを更新しました。 7 日間の期間で増分更新を実装した後、更新は 3 分以内に完了しました。

ゲートウェイのベスト プラクティス

オンプレミス データ ゲートウェイは、オンプレミス データ ソース (SQL Server、Oracle、ファイル共有) と Power BI サービスの間のブリッジです。ゲートウェイのパフォーマンスは、リフレッシュの信頼性に直接影響します。

ゲートウェイは専用サーバーにインストールしてください。 開発者のラップトップや共有アプリケーション サーバーにはゲートウェイをインストールしないでください。ゲートウェイには、一貫した可用性とすべてのデータ ソースへのネットワーク アクセスが必要です。

接続プーリングを構成します。 ゲートウェイ構成アプリで、クエリ量の多いデータ ソースの接続プーリングを有効にします。これにより、クエリごとに新しい接続を作成するのではなく、データベース接続が再利用され、更新時間が大幅に短縮されます。

ゲートウェイの正常性を監視します。 Power BI は、Power BI サービス管理ポータルでゲートウェイ ログを提供します。失敗した更新に対するアラートを設定します。ゲートウェイがサイレントに障害を起こすと、数値が古いことがユーザーに示されることなく、ダッシュボードに古いデータが表示されたままになります。

高可用性を実現するにはゲートウェイ クラスターを使用します。 ゲートウェイをクラスター モードで 2 つ以上のサーバーにインストールします。 1 つのサーバーがダウンすると、もう 1 つのサーバーが自動的に引き継ぎます。これは、日々の業務運営をサポートする実稼働ダッシュボードにとって不可欠です。

---

パフォーマンスの最適化

ダッシュボードのパフォーマンスの測定

Power BI Desktop には、各ビジュアルのレンダリングにかかる​​時間を記録するパフォーマンス アナライザー ([表示] → [パフォーマンス アナライザー]) が含まれています。記録を開始し、ダッシュボードを操作して、結果を確認します。

レンダリングに 2 秒以上かかるビジュアルは最適化が必要です。一般的な原因は次のとおりです。

複雑な DAX メジャー。 行ごとに反復するメジャー (SUMX、大きなテーブルでの FILTER、ネストされた CALCULATE を使用) は、ストレージ エンジンを利用するメジャーよりも大幅に遅くなります。可能な場合はフィルター コンテキストを使用するように反復メジャーを書き換えます。

1 ページにビジュアルが多すぎます。 各ビジュアルはデータセットに個別のクエリを送信します。 15 個のビジュアルを含むページは 15 個のクエリを送信し、Power BI はそれらを並行してレンダリングします。視覚的なカウントを 7 以下に減らします。

ビジュアル内のカーディナリティの高い列 10,000 行を表示するテーブル ビジュアルまたは 500 カテゴリを含む棒グラフは、DAX の最適化に関係なく速度が低下します。データをフィルターまたは集計して、管理可能な行数 (通常、テーブルの場合は 100 未満、グラフの場合は 20 未満) を表示します。

DAX 最適化テクニック

変数を使用します。 変数 (VAR) は一度評価されて再利用され、冗長な計算が防止されます。

Revenue Growth =
VAR CurrentRevenue = [Total Revenue]
VAR PriorRevenue = CALCULATE([Total Revenue], DATEADD(Dates[Date], -1, YEAR))
RETURN
DIVIDE(CurrentRevenue - PriorRevenue, PriorRevenue)

CALCULATE で十分な場合は FILTER を使用しないでください。 CALCULATE([Measure], Table[Column] = "Value") は CALCULATE([Measure], FILTER(Table, Table[Column] = "Value")) よりも高速です。前者はストレージ エンジンを使用し、後者は行ごとのスキャンを強制するためです。

Power Query で事前集計します。 ダッシュボードに月次の合計のみが表示される場合は、データ モデルに入力する前に、Power Query で日次データを月次に集計します。これにより、モデルのサイズが削減され、後続のすべての計算が高速化されます。

クエリの折りたたみ

SQL ベースのソースに接続する場合、Power Query は変換をソース データベースに「折りたたむ」ことができます。これは、Power BI がメモリ内の生データを処理するのではなく、データベースがフィルター処理、グループ化、結合を処理することを意味します。

Power Query のステップを右クリックし、[ネイティブ クエリの表示] を探して、変換が折りたたまれるかどうかを確認します。オプションが利用可能な場合、ステップは折りたたまれます。グレー表示されている場合、ステップは Power BI でローカルに実行され、大規模なデータセットの場合は遅くなります。

通常、折りたたまれる変換: 列の選択、行のフィルタリング、グループ化、並べ替え、同じソース上のテーブル間の結合、データ型の変更。通常、折りたたみを中断する変換: M 式を使用したカスタム列の追加、異なるソースからのテーブルのマージ、ピボット/ピボット解除。

---

ガバナンスと展開

ワークスペースのアーキテクチャ

組織の構造とデータ ガバナンスの要件に合わせて Power BI ワークスペースを整理します。一般的なパターンでは、次の 3 つの層が使用されます。

開発ワークスペース 各開発チームまたはプロジェクトには、レポートを構築して反復処理するためのワークスペースが与えられます。アクセスは開発者に限定されています。命名規則: DEV - Department - Project。

ステージング ワークスペース。 完成したレポートはレビューとテストのためにステージングに移動します。ビジネス関係者はデータの正確性と使いやすさを検証します。命名規則: STG - Department。

実稼働ワークスペース。 承認されたレポートは実稼働ワークスペースに公開されます。これらは、エンド ユーザーがアクセスするワークスペースです。実稼働環境で直接変更が加えられることはありません。命名規則: PRD - Department。

デプロイメントパイプライン

Power BI 展開パイプラインは、開発からステージング、運用までのコンテンツのプロモーションを自動化します。これにより、エラーが発生しやすく、バージョンが追跡されない .pbix ファイルのダウンロードと再アップロードという手動プロセスが不要になります。

ステージ間のプロモート時にデータ ソース接続を自動的に更新するようにデプロイメント ルールを構成します。開発レポートは開発データベースに接続し、ステージング レポートはステージング データベースに接続し、運用レポートは運用データベースに接続します。デプロイメント パイプラインは、接続のスワップを自動的に処理します。

バージョン管理とドキュメント

Power BI .pbix ファイルはバイナリであるため、従来の Git ワークフローでは適切に機能しません。ただし、この制限を軽減することはできます。

Power BI プロジェクト (.pbip) を使用します。 .pbip 形式は、テキストベースで Git に適した JSON ファイルおよび TMDL ファイルのフォルダーとしてレポートを保存します。これは、適切なバージョン管理を必要とするチームに推奨されるアプローチです。

変更ログを維持します。 新しいメジャーの追加、データ ソースの変更、ビジュアル レイアウトの変更など、レポートに対するすべての重要な変更を文書化します。変更の日付、作成者、理由を含めます。

重要なページのスクリーンショットを作成します。 レイアウトを大幅に変更する前に、現在の状態のスクリーンショットを作成します。これにより、技術変更ログを補足する視覚的な履歴が提供されます。

組織が Power BI ガバナンスの確立や拡張性のあるダッシュボードの構築に支援を必要としている場合は、ECOSIRE の Power BI ダッシュボード開発サービス が、KPI 定義から運用展開までのエンドツーエンドのサポートを提供します。

---

避けるべき一般的なアンチパターン

「すべてのダッシュボード」

経営陣、マネージャー、アナリスト、運用チームにサービスを提供しようとする単一のダッシュボードは、どのチームにも十分なサービスを提供しません。経営幹部は、トレンドのコンテキストを備えた高レベルの KPI を必要としています。アナリストは、柔軟なフィルタリングを備えた詳細なデータを必要としています。これらは根本的に異なる使用例であり、異なる設計が必要です。

共有セマンティック モデルによって接続された、対象者ごとに個別のダッシュボードを構築します。基礎となるデータ モデルは同じであるため、一貫性が保証されます。ビジュアル レイヤーは、各視聴者のニーズと意思決定のコンテキストに合わせて調整されます。

「きれいだが役に立たない」ダッシュボード

美学は重要ですが、それが目的ではありません。グラデーションの背景、3D グラフ、不要なアニメーション、装飾的な画像で埋め尽くされたダッシュボードは、スクリーンショットでは印象的に見えるかもしれませんが、日常的に使用するには役に立ちません。データを伝達しないあらゆる視覚要素は気を散らすものです。

最も効果的なダッシュボードは、視覚的にすっきりしていてデータ密度が高いものです。ホワイトスペース、明確なタイポグラフィー、セマンティックカラーを使用して、目を重要なものに導きます。アートプロジェクトではなく、よくデザインされたツールのように感じられます。

「設定したらあとは忘れる」ダッシュボード

ダッシュボードには継続的なメンテナンスが必要です。データ ソースはスキーマを変更し、ビジネス要件は進化し、ユーザーのフィードバックによって設計のギャップが明らかになります。四半期ごとのダッシュボード レビューをスケジュールし、使用状況メトリクスを評価し (Power BI は表示数とユーザー リストを提供します)、ユーザー フィードバックを収集し、設計を繰り返します。

更新されないダッシュボードは 6 ～ 12 か月以内に意味がなくなります。一回限りの成果物ではなく、生きた製品として扱います。

学習曲線を必要とせずに効果の高いダッシュボードを構築したいと考えているチームのために、ECOSIRE は、KPI ワークショップ、ダッシュボード設計、継続的な最適化を含む包括的な Power BI サービスを提供しています。特定のユースケースについてご質問がある場合は、分析チームにお問い合わせ ご相談ください。

---

よくある質問

Power BI ダッシュボード ページにはビジュアルをいくつ含める必要がありますか?

各ページのビジュアルを 5 ～ 7 個に制限します。ダッシュボードの理解に関する調査では、視覚的な密度が増加するにつれて、ユーザーが情報を処理する精度が低下することが示されています。 7 つを超えるビジュアルが必要な場合は、すべてを 1 つの画面に詰め込むのではなく、ドリルスルー ページ、ブックマーク、または追加のレポート ページを使用します。エグゼクティブ サマリー ページにはさらに少なくする必要があります。多くの場合、3 ～ 5 枚の KPI カードと 1 つの主要グラフが理想的です。

Power BI のダッシュボードとレポートの違いは何ですか?

Power BI の用語では、「ダッシュボード」は、1 つ以上のレポートの固定されたタイルを表示する、Power BI サービスの単一ページのキャンバスです。 「レポート」は、Power BI Desktop で作成された複数ページの対話型ドキュメントです。実際には、ほとんどの人は、技術的にダッシュボードであるかレポートであるかに関係なく、分析表示を意味するために「ダッシュボード」を使用します。ほとんどのユースケースでは、タイルをダッシュ​​ボード キャンバスに固定するよりも、ナビゲーション ボタンを備えた複数ページのレポートを作成する方が優れたユーザー エクスペリエンスを提供します。

Power BI データはどのくらいの頻度で更新する必要がありますか?

更新頻度をデータの可用性ではなく決定サイクルに合わせます。毎日の朝の更新 (営業時間前) は、ユースケースの 80% を満たします。リアルタイムの意思決定 (サポート キュー、製造ステータス) をサポートする運用ダッシュボードには 1 時間ごとの更新が必要な場合があり、それには Premium 容量が必要です。月次レビューに使用される財務ダッシュボードは毎週更新できます。過剰なリフレッシュはゲートウェイのリソースを無駄にし、意思決定の品質を向上させることなくコストを増加させます。

Power BI ダッシュボードを自分の Web アプリケーションに埋め込むことはできますか?

はい。 Power BI Embedded を使用すると、JavaScript API を使用してカスタム Web アプリケーションにレポートとダッシュボードを埋め込むことができます。 Power BI Embedded 容量 (A-SKU) または Power BI Premium (ファブリック経由の P-SKU または F-SKU) のいずれかが必要です。埋め込みレポートには、フィルタリング、ドリルスルー、ブックマーク、RLS などのすべての対話型機能が維持されます。これは、多くの SaaS プラットフォームが Power BI ライセンスを必要とせずに顧客に分析を提供していることを示しています。

組織外のユーザーに対して行レベルのセキュリティを処理するにはどうすればよいですか?

外部ユーザー (顧客、パートナー) の場合は、Power BI Embedded で「アプリがデータを所有する」埋め込みパターンを使用します。アプリケーションはユーザーを認証し、RLS ロールとユーザー名を指定する有効な ID を持つ埋め込みトークンを生成します。外部ユーザーは Power BI サービスと直接対話することはなく、Power BI ライセンスは必要ありません。データ モデルで定義した RLS ルールは埋め込みビューに適用され、各外部ユーザーが承認されたデータのみを参照できるようにします。