はじめに
セルフサービスBIを行うときも、チームや組織でPower BIを導入するときも、レポート作成方法や共有方法などなど、ある程度ガイドラインを決めておくと運用及びメンテナンスがしやすくなります。開発が始まって、社内で運用が軌道にのったあとでは、ルールを変えるのは大変ですよね。「お作法」「おまじない」と呼ばれる基本的には行うべき必要があること、「このへんは決めておくと後々良いんじゃない？」というもの、思いつく限り列挙してみました。
サンプルデータ
Power BI Desktopを触るに当たり、データがないと始まりません。自分の業務データを触るのが、馴染みもあり一番おもしろいと思いますが、それがかなわない場合はサンプルデータを使いましょう。
また、組織で同じサンプルデータを共有しておくと、勉強会を行うときなど、同じデータ、同じデータモデルで行うことができるので共通理解が捗ります。組織でデータモデル開発を行っていると、クエリフォールディングが重要になる局面もあるため、クエリフォールディング対応のデータソースも用意しておくとより捗ります。
フォールディングに対応しているソース
クエリ言語の概念に基づく多くのデータ ソースでは、クエリ フォールディングがサポートされます。 そのようなデータ ソースには、リレーショナル データベース、OData フィード (SharePoint リストなど)、Exchange、Active Directory が含まれます。 しかし、フラット ファイル、BLOB、Web などのデータ ソースでは、通常サポートされません。
Contoso Sales For PowerBI(.pbixファイル)
データ加工をいつ・どこで行うか
データ加工は可能な限り上流で行うことがベストプラクティスです。
上流は、組織やチームによって異なります。
データベース上で加工・集計を行うことが上流の組織・チーム・局面もあれば、Dataflow、DatamartといったPower BI Serviceで行うことが上流と定義付けられる組織もあるでしょう。チームごとに上流とはどこなのか？を事前にきめておくと、データ加工のサイロ化を防ぐことができます。
クエリフォールディング対応のデータソースを上流と定めた場合は、PowerQueryでデータ加工をしたあとにネイティブクエリを出力することができます。加工後のデータとクエリをエンジニアに見せてあげれば作業効率もよく、上流で加工する・・というルールも守りやすくなります。
カレンダーテーブル
レポートを作成する際に、カレンダーテーブルは多くのケースで必要になります。
ファクトテーブルに入っている日付列をグラフの軸に使用すると、売上が立っていない日が抜けてしまったり、予期せぬ計算ミスが発生することがあります。また、年別にみたい、曜日別にみたい…などさまざまな要望に答えるためにも、別途カレンダーテーブルを用意するのがベストプラクティスです。
そのカレンダーテーブルをPower Queryで作成し、組織共通のデータフローで作成しておくのか。あるいは、都度必要なときに共通のDAXで計算テーブルを作成するのか…。カレンダーテーブルを共通化しておくと、考えなければいけないことが一つ減るため、組織で運用するのがとても楽になります。
どこで組織共通のカレンダーテーブルを持つのか
DAXで計算テーブルを作成するのか。
Power Queryで記述し、データフローにしておくのか。
Power Queryでの記述例
DAXでの記述例
カレンダーテーブルはBravoでつくる
組織で共通のカレンダーテーブルを作成するという考え方もありますが、カレンダーテーブルを作成するツールを共通化するという考え方もあります。SQLBIが2022年に発表したbravoを使えば簡単にカスタマイズされたカレンダーテーブルを自分のモデルの中に作成できます。ツール内でカスタマイズは可能ですが、DAXでの文法が統一されているため理解しやすいです。日本の祝日にも対応しています。
[必須] 自動で作成される日付階層をオフにする
オプションのタイムインテリジェンスという項目のチェックを必ず外しましょう。これにチェックが入っていると、データモデル内にある全ての日付型の列にたいして、年、四半期、月という階層構造を自動作成します。ファクトテーブルに受注日、発送日、データ更新日など日付列が複数あり、そもそもファクトテーブルの行数が〇〇億行とかあると、データサイズが爆裂に大きくなりパフォーマンスに影響を与えます。これは必ず行いましょう！
[必須] 日付テーブルをマークする
カレンダーテーブルを作成したら日付が入っている列を「日付列としてマーク」をしましょう。これをすることで日付列に抜けや重複がないかチェックしてくれます。
データモデルはスタースキーマ
データモデルを構成する際に、スタースキーマを目指すことが重要です。人が見て、理解できるリレーションシップの構成です。DAXもデータモデルがスタースキーマの前提で設計されている言語です。（たぶん）
列名の命名規則
データベースの列名は英語かつCamelCaseの場合が多いと思います。
UnitSales
SalesQuantity
SalesAmount
Power BIでデータを取得したあとカラム名は変更可能です。日本語も対応しています。
列名を変えるのか、変えないのか。変える場合はデータフローで列名を変更するのか、各レポート単位で変更するのか。
メジャー関連
メジャーの命名規則
メジャーの名前は日本語・英語両方に対応しています。メジャー表記のルールを決めておきましょう。ローマ字的なものも許容してもいいから英語にするのか。ユーザーも理解可能な日本語表記にするのか。
計算列の命名規則
計算列や、メジャー記述過程で計算列を作成したときは、
列名に「＠」をつける。
※可読性を高めたいだけなので、それ以上の意味は無い。組織のルールがあれば良い。
暗黙のメジャーは避ける
Power BIはテーブルビジュアルに売上列をドラッグ＆ドロップするだけで合計や平均などの基本的な計算はしてくれます。が、こういった暗黙のメジャー（計算）は非推奨です。Excelでモデルにつないだとき、暗黙のメジャーは表示されません。簡単なDAX関数でも丁寧に書いていきましょう。
なるべく変数を使用して可読性を高める
VARを使用して可読性の高いコードを書く。
変数の命名規則
変数名には「__」(アンダースコア2つ)をつける。
※可読性を高めたいだけなので、それ以上の意味は無い。組織のルールがあれば良い。
作成したメジャーはフォーマットをする
可読性の高いコードを書いたほうがいいのはPower BIでも同様です。他人が見たとき、半年後に自分が見たときでも理解が早くなるように、DAXを書いたらフォーマットを掛けて保存をしましょう。Tabular EditorはDax Formatterも内包している開発ツールです。こういった外部ツールの活用も考えましょう。
メジャー記載時、列名は完全修飾、メジャーは[]のみ
列名は、
'売上テーブル'[商品ID]
'売上テーブル'[売上日]
'売上テーブル'[売上数量]
のように、テーブル名も全てつけて記述します。
一方、メジャーは
[Sales Amount]
[Distinct Color]
のように[]でメジャー名を書くだけでOKです。
このルールを徹底している前提があると、コードの可読性が大きく上がります。
メジャーのフォルダー整理
メジャーが増えてきたときに汚くなっていくので、モデルビューからフォルダーを作成し整理するのも一考する余地ありです。
とくに、タイムインテリジェンス系DAXが増えてくる可能性がある場合は、ベースメジャーごとにフォルダーを作成する…など方針を決めておくのがいいでしょう。
行レベルセキュリティの使用
行レベルセキュリティはどこで、どのような実装をしたのかあとからわからなくなりがちです。権限設計はワークスペースやアプリベースで行うようにしていったほうが、シンプルな運営が可能です。
[必須] ディメンジョンテーブルの使わない列は非表示にする
データモデルは最終的にユーザーにも開示していくことになると思います。ユーザーが一見して意味の分からない、使用していない列は非表示にしましょう。
[必須] ファクトテーブルはメジャーのみにする
ファクトテーブルの列をスライサーに使用するのは非推奨です。ですので、ファクトテーブルで表示しておく必要があるのはメジャーのみです。
多対多のリレーションシップは避ける
双方向のリレーションシップは避ける
プレビュー機能の利用
プレビュー機能をどこまで使うかも話し合うポイント。
便利な機能が多いので、全部ONにできればいいですよね😀
データフローの使用を検討する
データフローの使用有無、使い方
- 共通のデータ加工をデータフローで行う
- データソースへの接続回数を減らす
外部ツールを使用する
主な外部ツール。下記３つくらいはインストール必須。その他ツールはよく話し合ってから導入しましょう。
[必須] Bravo for Power BI
[必須] DAX Studio
[必須] Tabular Editor
外部ツールでしか設定できないことを使用するか
計算グループやオブジェクトレベルセキュリティ（OLS）など、外部ツール（主にTabular Editor）を使用して設定するしか方法のないこともあります。とても便利な機能ですが、Tabular Editorなどの開発ツールを使用できる人でなければその後のメンテナンスができなくなるため、組織としてルールを決めておく必要がある部分になります。
Power BI Serviceをよく学ぶ
Power BI Desktopはレポートのオーサリングツールで、Power BIの活用においてなくてはならないツールです。が、実際にユーザーに共有し、BIとして機能させる多くの局面で活躍するのはPower BI Serviceです。データ更新の仕組み、共有の仕方、テナント設定など、
レポートの共有はまずアプリから考える
アプリ→ワークスペース→レポートの順番で考えよう。
ビジュアルについて
誤解を与える表現はやめましょう。
グラフのスタートはゼロから
グラフの役割を整理する
それぞれのグラフには役割があります。比較するにはこのグラフ、推移を見たいときはこのグラフ。理解を深めてビジュアルの選択をしていきましょう。
円グラフの使用をどうするか
円グラフは特に使い所が難しいグラフです。円グラフで表現できるものは、棒グラフで代替できる場合がほとんどです。
カスタムビジュアルの使用
カスタムビジュアルはデータの持ち方、操作方法が独特なものが多いため、組織で長期にわたるレポート運用を考えると導入は慎重に行ったほうが良いでしょう。一時的な見た目の良さだけをとらず、伝えたいことをシンプルに表現できる標準ビジュアルがないか検討しましょう。
フィルターペインはOFFにする
フィルターペインは、閉じてしまうと、なんのフィルターをかけているのか設定したユーザー自身もわからなくなることがあります。そのためビジネス判断をする際に誤った数字をもとにしてしまいます。フィルターペインはPower BI Desktopで非表示にすることができるので、消しておくのがいいと考えています。
各種ベストプラクティスを一読しておく
開発チーム、ビジネスユーザー、それぞれのロール用の各種ベストプラクティスが用意されています。一度読んでおくと、その後の理解も早いためオススメです。
- DAXのベストプラクティス集
データフローを使用してディメンショナル モデルを作成するためのベスト プラクティス
Power Query を使用するときのベスト プラクティス
Microsoft Power Platform 導入のベスト プラクティス
Power BI の Q&A を最適化するためのベスト プラクティス
Power BI 埋め込み分析のパフォーマンスを向上させるベスト プラクティス
Best practice rules to improve your model’s performance:モデルのパフォーマンスを向上させるためのベストプラクティスルール
Power BI Development Best Practices
Power BI導入ロードマップを一読する
Power BI 実装計画を一読する
アイコン
組織内でドキュメントを作成するときも、アイコンくらいは正式なものを使用しましょう💪
最後に
一つ一つのルールは手間もかかるし、めんどくさいと感じるかもしれないけれど、半年後、1年後に自分がもう一回レポートを開いたとき、理解ができるかたちにするためには必要な作業です。チーム内の別メンバーが作成したレポートを引き継がれたとき、オレオレルールだと泣くのは自分です。まだ組織やチームできちんとルール決めがされていなければ、早めに決めて、継続的・効率的なレポート運用をしていきましょう😁🎉