Power BIのモデルが育ってくると、最初に困るのが「メジャーが増えすぎて見つからない」問題です。売上、前年差、前年差率、目標差、累計、移動平均……必要な指標を追加していくほど、フィールド一覧は長くなり、似た名前のメジャーが並び、作った本人ですら迷子になります。結果として、同じ計算が別名で重複したり、誤った指標をレポートに置いてしまったり、保守のコストが跳ね上がります。
ここでは、表示フォルダと命名規則の2本柱で「探せるモデル」を作る手順を、実務でそのまま使える形でまとめます。いわゆる power bi measure folder を使った整理は、見た目をきれいにするだけではなく、開発スピードと品質を同時に上げるための設計作業です。
なぜ整理が必要なのか：メジャーの増殖が起こす3つの損失
1) 探す時間が増える
メジャー名が曖昧だったり、分類が無いと「どれが正しい売上？」を探す時間が発生します。小さなロスの積み重ねが、開発全体を遅らせます。
2) 重複メジャーが増える
見つからないので新しく作ってしまう。ロジックが微妙に違う同名メジャーが増え、数字の不一致が起きます。
3) 誤用・誤解が増える
「率」と「差」を取り違える、単位が違う、フィルター前提が違うなど、利用者側の誤解が起きやすくなります。整理は、誤解の芽を早めに潰す作業でもあります。
整理の基本方針：表示フォルダと命名規則はセットで効く
表示フォルダは、フィールド一覧の見え方を整える仕組みです。命名規則は、言葉の揺れや並び順の混乱を抑える仕組みです。どちらか片方だけだと効果が弱く、両方を揃えると「視覚的にも、文字検索でも」見つかるモデルになります。
また、整理の目的は「美しさ」ではなく「再利用性と事故防止」です。次の3つが満たされていれば成功です。
-
誰が開いても、目的のメジャーに最短で到達できる
-
似たメジャーの違いが、名前と配置だけでわかる
-
新しいメジャーを追加するとき、置き場所と名前が迷わない
ステップ1：メジャーの棚卸しで「役割」を分類する
まずは現状のメジャーを、役割で分けます。テーブルの所属は後で変えられますが、役割の分類がブレるとフォルダ設計が崩れます。おすすめは次の5分類です。
A. 基礎（ベース）メジャー
最小単位の集計。例：売上金額、数量、粗利金額 など。ここが安定すると派生メジャーが増えても管理しやすいです。
B. 派生（計算）メジャー
Aを材料にした計算。例：粗利率、単価、前年差、前年差率 など。
C. 時系列（Time Intelligence）メジャー
累計、前年差、前月、移動平均など、日付テーブル前提で動くもの。用途が多く混乱しやすいので独立させる価値が高いです。
D. 表示専用・スイッチ系
条件で返す値を変える、表示用の文字列を返す、選択された項目名を返す等。数値計算と混在させないほうが誤用が減ります。
E. デバッグ・検証用
一時的に作る確認用メジャーや、フィルター状況の確認用。運用に残すなら明確に隔離します。
棚卸しの時点で、同じ意味の重複が見つかることが多いです。すぐ削除できなくても、候補をメモしておくと後で効きます。
ステップ2：表示フォルダの設計を「利用者の探し方」から決める
表示フォルダを考えるときのコツは、作り手の都合ではなく「使う側がどう探すか」を起点にすることです。よくある探し方は次の3パターンです。
1) 業務領域で探す
例：売上、在庫、顧客、広告など。部門別にレポートが分かれる場合に相性が良いです。
2) 指標の種類で探す
例：基礎、KPI、前年差、前年差率、累計など。全社共通の見方がある場合に強いです。
3) レポート画面で探す
例：サマリー用、詳細用、ドリルスルー用など。レポートが固定化されている場合に便利ですが、レポート変更に弱い面もあります。
迷ったら、まずは「指標の種類」で大分類し、必要なら「業務領域」で2階層目を作るのが無難です。階層を深くしすぎると逆に迷うので、2階層、頑張っても3階層までに収めるのがおすすめです。
表示フォルダ名の例（2階層）
-
01 基礎/売上
-
01 基礎/数量
-
02 KPI/売上
-
02 KPI/利益
-
03 時系列/累計
-
03 時系列/前年差
-
04 分析/構成比
-
90 表示/ラベル
-
99 検証/デバッグ
先頭に番号を付けているのは、アルファベット順・五十音順の並びに引っ張られず、意図した順序で表示するためです。番号は「整理のための索引」と割り切ると運用が楽になります。
ステップ3：命名規則は「読みやすさ」と「検索性」を両立させる
命名規則で大事なのは、次の2つです。
-
見た瞬間に役割がわかる
-
検索したときに狙ったものが引っかかる
おすすめの考え方は「名詞で統一し、計算の種類を接頭語または接尾語で表す」です。Power BIはDAXで角括弧が付きますが、メジャー名そのものには不要です。
命名規則の例（日本語ベース）
-
売上 金額
-
売上 数量
-
粗利 金額
-
粗利 率
-
売上 前年差
-
売上 前年差率
-
売上 累計
-
売上 12か月移動平均
スペース区切りは読みやすい一方で、環境によってはアンダースコア派もいます。どちらでも良いのですが、混ぜないことが最重要です。すでに社内で慣習があるなら、それに寄せたほうが浸透します。
計算タイプを揃える小技
-
差は「差」、率は「率」、比は「比」を固定する
-
前年差と前月差を混在させるなら「前年」「前月」を必ず明記する
-
単位が違うものは「金額」「数量」「件数」を必ず入れる
-
税抜/税込、為替換算など前提条件があるなら末尾に付ける（例：売上 金額 税抜）
英語プレフィックスを使う場合の例
-
m 売上 金額
-
m 売上 数量
-
kpi 売上 達成率
-
ti 売上 累計
-
ti 売上 前年差
-
dbg フィルター状態
日本語だけでも運用できますが、プレフィックスは「並び替え」と「種類の瞬時判別」に効きます。特に検証用の dbg は、残す場合に必須級です。
ステップ4：メジャーテーブルを作って「置き場」を固定する
表示フォルダは分類に効きますが、メジャーが散らばると作成・管理が面倒です。そこで、専用のメジャーテーブル（例：_Measures）を作り、基本的にメジャーはそこに集約します。これにより、モデルのテーブル構造と指標の構造を分離でき、初心者が列とメジャーを取り違える事故も減ります。
運用イメージ
-
ファクト/ディメンションの列は必要に応じて非表示にする
-
メジャーは _Measures に集め、表示フォルダで分類する
-
テーブル名の先頭に _ を付けて上部に固定する（並び順の都合）
注意点として、既存メジャーの所属テーブルを変えると、レポート側で参照している表示位置が変わるだけで、メジャー自体は壊れません。ただし、利用者が「いつもの場所」に慣れている場合は移行期に混乱が起きるので、段階的に行うのが現実的です。
ステップ5：説明文と書式で「誤用」を減らす
探せるモデルは、見つかった後に「正しく使える」ことまで含みます。そこで次の2つをセットで整えます。
1) メジャーの説明（Description）
-
何を表すか（定義）
-
前提（税抜、除外条件、フィルター前提）
-
推奨用途（カード用、行レベルで使えるか等）
説明は短くて構いません。重要なのは、曖昧なメジャーほど説明を付けることです。
2) 書式（Format）
金額は通貨、率はパーセント、小数桁は統一。これだけで誤解が減ります。例えば粗利率が 0.34 と表示されるのか 34% と表示されるのかで、利用者の混乱は大きく変わります。
ステップ6：ルールを破らないための運用を決める
整理は一度やって終わりではなく、増えるメジャーに耐える仕組みにする必要があります。おすすめの運用は次の通りです。
-
新規メジャーは必ず分類（フォルダ）と命名規則をセットで決める
-
基礎メジャーを増やす前に、既存に同義がないか検索する
-
派生メジャーは基礎メジャーを参照し、直書き集計を避ける
-
検証用はフォルダ 99 検証 に隔離し、リリース前に棚卸しする
-
月1回など定期的に「重複・未使用・暫定」を点検する
小さなチームほど、口頭ルールで回しがちですが、簡単なチェックリストを残すだけで崩壊を防げます。
よくある失敗と対策
失敗1：フォルダを業務別にしすぎて深くなる
対策：大分類は指標タイプ、業務別は2階層目まで。深い階層は検索性を落とします。
失敗2：命名規則が例外だらけになる
対策：例外を作るときは「なぜ例外か」を説明文に残す。例外が増えたら規則を見直して一般化する。
失敗3：メジャー名が短すぎて意味が曖昧
対策：略語を減らし、単位と対象を明記する。売上 とだけ書かないで 売上 金額 のように具体化します。
失敗4：検証用メジャーが本番に残って混乱を招く
対策：dbg プレフィックスまたは 99 検証 フォルダで隔離し、不要になったら削除候補として管理します。
実務で効く最小セット：まずはこれだけやる
いきなり完璧を目指すと止まります。最初の一歩としては、次の最小セットが効果的です。
-
_Measures テーブルを作る（新規はそこに作る）
-
表示フォルダを 01 基礎、02 KPI、03 時系列、99 検証 の4つにする
-
メジャー名に 金額、数量、率、差、累計、前年 などの語を必ず入れる
-
主要KPIだけでも説明文と書式を統一する
この段階でも「探す時間」と「誤用」は大きく減ります。余力が出たら、業務別のサブフォルダや、より細かな命名規則に広げていけば十分です。
まとめ：探せるモデルはチームの資産になる
表示フォルダと命名規則は、単なる整理整頓ではなく、モデルをチームで育てるための土台です。メジャーが増えるほど効果は大きくなり、後から効いてきます。power bi measure folder を活用して分類を作り、名前で意味と前提を揃える。これだけで、開発スピードも、数字の信頼性も、レポート利用者の体験も、まとめて改善できます。今日追加する1本のメジャーから、ルールに沿って積み上げていきましょう。
コメント