ビジネスメトリクスとDAXメジャーの考え方

ビジネスレポートは、主要な指標を再利用可能なDAXメジャーとして一度定義すると、より信頼性が高まります。メジャーは、ビジュアル、スライサー、フィルター、またはレポート上の操作によって結果が要求された時点で評価されます。そのため、同じメジャーであっても、すべてのビジュアルごとに計算を重複させることなく、月、商品カテゴリ、地域、顧客セグメントごとに異なる値を返せます。

このレッスンでは、売上レポート用の実践的なメジャー、すなわち売上高、コスト、粗利益、利益率、年初来実績、前年との比較、前年比変動に焦点を当てます。例では、Salesファクトテーブル、Dateテーブル、関連付けられたProductおよびCustomerディメンションで構成されるスタースキーマを前提とします。Salesテーブルには、SalesAmount、CostAmount、Quantity、OrderDateという名前の数値列が含まれています。

メジャーは計算列と同じものではありません。計算列はモデルの更新時に行単位で評価され、テーブルに値を保存します。一方、メジャーは現在のフィルターコンテキストのもとで、クエリ実行時に評価されます。インタラクティブなビジネスダッシュボードでは、ユーザーの選択に応じて変化するため、集計やKPIには通常メジャーが適しています。

基本KPIメジャー

まず、単純な基本メジャーから始めます。これらのメジャーはモデルのビジネス用語を定義し、後続の計算を読みやすく、保守しやすくします。SUMは数値列を集計し、COUNTROWSは現在のフィルターコンテキストで表示されている行をカウントします。

Total Sales = SUM ( Sales[SalesAmount] )

Total Cost = SUM ( Sales[CostAmount] )

Total Quantity = SUM ( Sales[Quantity] )

Order Count = DISTINCTCOUNT ( Sales[OrderID] )

追加のフィルターがないカードビジュアルでは、Total SalesはSalesAmount列の合計金額を返します。同じメジャーをProduct[Category]ごとのマトリックスに配置すると、Power BIはカテゴリごとに個別に評価します。カテゴリフィルターによってコンテキストが自動的に変化するため、カテゴリ専用の別バージョンは必要ありません。

粗利益と利益率は、未加工の列式を繰り返すのではなく、再利用可能なメジャーに基づいて定義する必要があります。ビジネスメトリクスでは、分母が0または空白の場合の処理を指定できるため、除算演算子よりDIVIDEの使用が望ましいです。

Gross Profit = [Total Sales] - [Total Cost]

Gross Margin % = DIVIDE ( [Gross Profit], [Total Sales], 0 )

Gross Profitの出力は金額であるのに対し、Gross Margin %は比率です。前者は通貨または適切なレポート通貨として、後者はモデル内でパーセンテージとして書式設定してください。書式がパーセンテージの場合、マージンのメジャーに100を掛けないでください。Power BIが表示上の変換を処理します。

時間ベースの分析

時間インテリジェンスは、有効な日付モデルに依存します。レポート対象期間の各日付について1行ずつ持つ専用のDateテーブルを作成し、Date[Date]とSales[OrderDate]を関連付け、Power BIでそのテーブルを日付テーブルとして設定してください。Date列には、一意で連続した日付を含める必要があります。月別にグループ化したビジュアルでは、Salesテーブルのテキスト型の月列ではなく、Date[Year]やDate[Month]など、Dateテーブルのフィールドを使用してください。

次のメジャーは、累計売上と比較対象となる前年の結果を計算します。DATESYTDは、現在のコンテキストにおける最新の日付までの、当年の開始日以降の日付を返します。SAMEPERIODLASTYEARは、現在表示されている日付期間を1年前に移動します。

Sales YTD =
CALCULATE (
    [Total Sales],
    DATESYTD ( 'Date'[Date] )
)

Sales Previous Year =
CALCULATE (
    [Total Sales],
    SAMEPERIODLASTYEAR ( 'Date'[Date] )
)

たとえば、マトリックスの行が2025年3月を表している場合、現在のコンテキストがその期間を表していれば、Sales YTDは2025年1月1日から3月31日までの売上を返します。Sales Previous Yearは、2024年の対応する表示期間の売上を返します。レポートで会計年度を使用する場合は、DATESYTDで会計年度末の引数が必要になることがあり、Dateテーブルには関連する会計年度属性を含める必要があります。

よくあるエラーの1つは、ファクトテーブルに接続されていない、または連続していない日付列を使用することです。もう1つは、Dateテーブルの計算が一貫して動作することを期待しながら、軸にSales[OrderDate]を配置することです。時間インテリジェンスによって予期しない空白や繰り返しの合計が返される場合は、まずリレーションシップ、日付テーブルの設定、ビジュアルで使用しているフィールドを確認してください。

比較、目標、ランキング

基本メジャーと時間メジャーが機能したら、ビジネス上の変動を明らかにする比較メジャーを作成します。YoY varianceは金額の差分です。YoY %は相対的な変化であり、分母の扱いに関する方針が必要です。この例では、前年の値が取得できない場合または0の場合に0を返します。これはシンプルなダッシュボードには適していますが、組織によってはその状況で空白値を使用することを好むため、仕様として文書化してください。

Sales YoY Variance =
[Total Sales] - [Sales Previous Year]

Sales YoY % =
DIVIDE ( [Sales YoY Variance], [Sales Previous Year], 0 )

比較メジャーは、その粒度と併せて解釈する必要があります。月次のYoY結果は、当月と前年同月を比較します。カテゴリの結果は、現在の日付フィルター下にあるカテゴリと、前年の同じカテゴリを比較します。現在の一部期間と前年の完全な期間をレポートで混在させる場合、比較が誤解を招く可能性があるため、明確なラベルを付けてください。

ランキングもコンテキストに依存します。RANKXはテーブル上で式を評価し、売上に基づいてカテゴリを順位付けできます。ALLSELECTEDは、レポート利用者が意図的に選択したフィルターを保持しながら、現在のカテゴリ行を比較対象から除外します。これにより、スライサーで現在含まれているカテゴリの中で、カテゴリの順位を付けられます。

Category Sales Rank =
RANKX (
    ALLSELECTED ( Product[Category] ),
    [Total Sales],
    ,
    DESC,
    DENSE
)

目標をレポートする場合、通常は目標テーブルを別にモデル化し、明確なリレーションシップまたは意図的な参照戦略を設定します。1つのメジャー内に多数のハードコードされた目標値を埋め込むことは避けてください。選択された目標をスライサーで制御する場合は、非接続の目標テーブルが役立ちます。ただし、その場合、メジャーで選択された値を明示的に取得し、目標が選択されていない場合の処理を定義する必要があります。

レポートの構築と検証

Date[Year] と Date[Month] を基準に、Total Sales、Gross Profit、Gross Margin %、Sales YTD、Sales Previous Year、Sales YoY % をマトリックスに配置します。2つ目のマトリックスには Product[Category] を追加し、Total Sales、Sales YTD、Category Sales Rank を含めます。月次売上には折れ線グラフを使用し、現在のフィルターが適用されたマージンにはカードを使用します。このレイアウトにより、メジャーが時間粒度とカテゴリ粒度の両方で正しく機能するかを検証できます。

検証には、小規模で独立して計算した例を使用します。レポートを1か月と1つのカテゴリに絞り込み、Total Sales を、ソースデータ内で条件に一致する SalesAmount 行の直接合計と比較します。Gross Profit については、売上から原価を引いた値がメジャーの結果と一致することを確認します。Sales YTD では、年末に近い月を選択し、その年のそれ以前のすべての月が値に含まれており、選択した月だけの値になっていないことを確認します。

年、カテゴリ、顧客セグメント用のスライサーを使用します。すべてのビジュアルが期待どおりに変化するか確認します。カードは変化するのにグラフが変化しない場合は、ビジュアルレベルのフィルターとリレーションシップを調べます。すべてのカテゴリで同じ合計が表示される場合、カテゴリのリレーションシップが存在しない、非アクティブである、またはキーが一致していない可能性があります。メジャーがスライサーを無視する場合は、該当するテーブルが Sales テーブルに接続されているか、また計算によって意図的にそのフィルターが削除されていないかを確認します。

本番モデルでは、データ型と書式を明示的に設定し、レポート作成者が使用すべきでない技術用の列を非表示にし、メジャーには業務上わかりやすい説明を付けます。基本メジャーと表示用メジャーは分けて管理します。これによりテストが容易になり、書式設定の判断や数式の重複によってページ間でKPIに不整合が生じるリスクを低減できます。

よくあるエラーとまとめ

よくある間違いの1つは、フィルターに応じて変化すべき指標を計算列として作成することです。行レベルのマージンのような列は行分析には役立ちますが、それを合計または平均しても、マージンの業務上の定義と一致するとは限りません。レポートレベルのマージンには、DIVIDE を使用して、利益合計を売上合計で割って計算します。

もう1つの間違いは、時間インテリジェンスの式で、修飾されていない、または誤った日付フィールドを使用することです。Date テーブルに一意の日付があること、リレーションシップが意図した日付を使用していること、そしてそのテーブルが日付テーブルとしてマークされていることを確認します。また、レポートが OrderDate、ShipDate、その他の業務上の日付のどれを使用しているかも確認してください。選択した日付の役割によって、すべての時間ベースKPIの意味が変わります。

ゼロと空白の扱いは意図的に決める必要があります。ゼロを返すとダッシュボードが完全に見える一方で、比較対象となる過去期間が存在しない事実を隠してしまうことがあります。BLANK を返すと誤解を招くラベルの表示を防げるため、グラフではこちらが適していることも少なくありません。どちらの選択も普遍的に正しいわけではないため、レポート要件に応じて選択し、メジャーの説明にその動作を記載します。

実務的なワークフローでは、まず基本メジャーを定義し、次にそれらのメジャーから業務KPIを組み立て、日付モデルを検証した後に時間インテリジェンスを追加し、現実的なフィルター条件ですべての結果をテストします。再利用可能なメジャーを使うと、各ビジュアルが同じ計算ロジックを使用しながら、それぞれのフィルターコンテキストにも応答するため、ダッシュボードの一貫性を保てます。