最初の Power BI ダッシュボードを作成する
ダッシュボードで答える質問から始める
Power BI を開く前に、ダッシュボードでどのビジネス上の意思決定を支援するのかを決めます。最初の問いとしては、「先月、最も多くの売上を生み出した商品はどれか。また、返品によって結果がどの程度減少したか」が有効です。この問いによって、必要なフィールド、日付範囲、比較項目が決まります。売上スプレッドシートの場合、最初のバージョンでは、売上高、販売数量、返品率、地域別売上高を追跡するとよいでしょう。
レポートを誰が使用し、閲覧後にどのような行動を取るべきかを特定します。店舗マネージャーには地域別の実績や在庫の少ない商品が必要かもしれません。一方、マーケティングマネージャーにはキャンペーン費用やコンバージョンデータが必要になる場合があります。利用可能なすべての列を集めるのではなく、これらのニーズを3～5個の質問として書き出してください。こうすることで、最初のページが有用なものになり、追加する各ビジュアルを検証するための明確な基準も得られます。
乱雑なスプレッドシートを監査する
乱雑なスプレッドシートには、1つのシート上に複数のテーブルが含まれていたり、装飾用のタイトル行、結合セル、空白行、表記の不統一、テキストとして保存された数値が含まれていたりすることがあります。まず最初の数行を確認して、本当のヘッダー行を特定し、その後で列名とデータ型を調べます。たとえば、日付列に同じフィールド内で 2025-01-05、05/01/2025、Pending という値が混在している場合があります。売上高の列にも、正しい計算を妨げる通貨記号や空白が含まれていることがあります。
変更を加える前に、簡単なデータ監査を実施します。各取引に一意の注文 ID があるか、商品名と地域名のスペルが統一されているか、空白セルが情報の欠落を意味するのか、それとも活動がなかったことを意味するゼロなのかを確認します。同じ注文 ID が同一の値で2回登場する場合は重複の可能性があります。一方、2つの商品行に登場する場合は、有効な複数商品注文かもしれません。これらの判断を記録しておくと、合計値に与える影響を把握でき、後のトラブルシューティングも大幅に容易になります。
Power Query でデータをクリーニングする
Power Query を使用して、各セルを手動で編集することなく、元のワークシートを一貫性のあるテーブルに変換します。ファイルをインポートし、タイトル行と空白行を削除し、正しい行をヘッダーに昇格させたうえで、日付、整数、10進数、テキストに明示的なデータ型を設定します。次に、余分なスペースをトリミングし、North、north、N などの値を標準化し、業務ルール上妥当な場合にのみ、本当に欠落している数値を置き換えます。新しいファイルが届いたときにクリーニング処理を繰り返せるよう、元のスプレッドシートは変更せずに保持します。
各変換ステップには明確な名前を付け、重要な変更を行った後はプレビューを確認します。月次ファイルの列が同じであれば、1つのブックに行をコピーして貼り付けるのではなく、フォルダー クエリを使用して結合します。1つの列に Hanoi, North のように City と Region が単一の値として含まれている場合は、データを読み込む前に別々のフィールドに分割します。再利用可能なクエリは、ソースがレポート対応データになるまでの手順を正確に記録するため、一度限りのクリーニングよりも信頼性が高くなります。
信頼性の高いデータモデルを構築する
クリーニング後は、取引データと説明情報を分離するシンプルなモデルにデータを読み込みます。中央の Sales テーブルには、OrderID、Date、ProductID、RegionID、Quantity、SalesAmount、ReturnAmount を含めることができます。個別の Product、Region、Date テーブルには、商品名、カテゴリ ラベル、地域名、カレンダー属性を保持します。この構造により、ラベルの重複によって計算が分かりにくくなるのを防ぎ、フィルター処理をより予測しやすくできます。
ユーザーによって表記が異なる可能性のある名前ではなく、ProductID や RegionID などの安定したキーを使用してリレーションシップを作成します。一般的なパターンは、Product テーブルの1行を複数の Sales 行に関連付け、Product テーブルから Sales テーブルをフィルターする形です。月、四半期、年、年初来の分析が必要な場合は、適切な Date テーブルを追加し、Power BI で日付テーブルとして設定します。1つの商品を選択し、関連する売上と取引件数が想定どおり変化することを確認して、モデルをテストします。
メジャーとKPIを作成する
個別のスプレッドシート セルに結果をハードコーディングするのではなく、フィルターに応じて計算結果を変化させる必要がある計算には、DAX メジャーを使用します。基本的なメジャーは Revenue = SUM(Sales[SalesAmount]) と記述でき、Returned Amount = SUM(Sales[ReturnAmount]) は選択された返品金額を計算します。率は Return Rate = DIVIDE([Returned Amount], [Revenue]) とすることで、分母が0の場合もレポートで安全に処理できます。これらのメジャーは、ユーザーが月、商品、地域でフィルターすると再計算されます。
まずは、定義を簡単に説明できる少数の指標から始めます。たとえば、レポート上部に総売上、販売ユニット数、返品率、平均注文金額を表示します。平均注文金額を個々の商品行ではなく、重複しない注文数で売上を割って算出すべきか確認します。各メジャーには明確な名前を付け、通貨、パーセンテージ、10進数を一貫した形式で表示し、ソース ファイルを開かなくても数値を解釈できるようにします。
効果的なダッシュボード ビジュアルを選択する
各ビジュアルを、それが答える問いに合わせます。月ごとの売上推移を示すには折れ線グラフ、商品を比較するには棒グラフ、注文単位の正確な詳細が必要な場合にはテーブルを使用します。カードには総売上を表示できますが、売上が変化した理由までは説明できないため、推移または比較のビジュアルと組み合わせます。日付、地域、商品カテゴリのスライサーは、ユーザーが意思決定を調査するのに役立つ場合にのみ追加します。
ページを見やすくするため、主要な指標を上部、中心となる傾向を中央、補足情報を下部に配置します。パフォーマンスを順位付けする際は、売上高の順に商品バーを並べ、関連するビジュアル間では同じカテゴリに同じ色を使用します。同じ比較を繰り返したり、関連性のない疑問を持ち込んだりする複数のグラフを1ページに配置することは避けます。通常のブラウザーサイズでページを確認し、軸ラベル、凡例、ツールチップ、テーブルの列が読みやすい状態に保たれていることを確認します。
検証、公開、改善
共有する前に、ダッシュボードをデータソースと照合して検証します。レポートを1か月・1地域に絞り込み、売上高と注文数を、手作業で確認したスプレッドシートのサンプルと比較します。重複行、空白の日付の除外、返品ロジック、誤ったリレーションシップが原因で差異が生じていないかを調査し、数値が見慣れたものになるまで変更することは避けます。また、スライサーの組み合わせ、選択項目が空の場合、返品商品がない商品についてもテストし、ビジュアルが適切に動作することを確認します。
Power BI Desktopでレポートページを作成し、Power BIサービスに公開します。単一の監視ビューが役立つ場合は、選択したビジュアルをダッシュボードにピン留めします。データソースの資格情報、更新設定、ワークスペースのアクセス許可が、想定する対象者向けに設定されていることを確認します。各KPIについて、分子、分母、日付のルールを含む簡潔な定義を追加し、将来のユーザーが返品率を異なる意味で解釈しないようにします。ユーザーがダッシュボードを使い始めた後は、実際の意思決定に役立つフィルターやビジュアルを確認し、根拠を示さずノイズを増やす要素を削除します。
参考資料
タグ :
- データ分析
