ビジネス上の目的

Power Queryは、Power BIで分析する前にビジネスデータソースへ接続し、データを整形するためのデータ準備レイヤーです。ばらつきのある業務記録を、レポートに使える再利用可能なデータセットに整えるのに役立ちます。売上ダッシュボードの信頼性は、その基となる日付、商品、顧客、金額の正確さに左右されます。データ準備の段階で、これらの入力を確認し、一貫性を持たせます。

ある小売業者を例に考えてみましょう。各店舗から毎週の売上データがスプレッドシートで届く一方、商品説明やカテゴリの割り当ては別のファイルで管理されています。レポートでは、店舗、商品、週ごとの売上を比較する必要があります。スプレッドシートごとに列名が異なったり、日付や金額の形式が異なったりする場合、すべてのファイルをそのまま読み込むだけでは、比較が不完全または誤解を招くものになる可能性があります。Power Queryでは、新しいソースデータが届いたときに更新できる、目に見える変換手順を作成できます。

目的は、すべてのソースをただ同じ形式にそろえることではありません。各変換は、レポートのニーズに応える、ビジネスルールを守る、またはデータの検証を容易にするものであるべきです。可能な範囲でソースレコードを追跡できる状態に保ち、ビジネス上の意味が不確かな値を、気づかれないまま変更しないようにします。

データソースへの接続

まず、データの保存場所と管理者を確認します。一般的なビジネスデータソースには、Excelブック、テキストファイルやCSVファイル、定期的にエクスポートされるファイルを格納したフォルダー、データベース、クラウドの業務アプリケーションなどがあります。実際のソースとアクセス方法に合ったコネクタを選択します。新しいファイルが毎回同じ構造で作成される場合はフォルダーコネクタが便利ですが、構成の異なるファイルを同じフォルダーから結合すると、予期しない列や重複レコードが混入する可能性があります。

接続する前に、対象となるテーブルまたはファイル、レポート対象期間、ソースが最新の業務データ抽出なのか過去のアーカイブなのかを確認します。アクセスに使うアカウントに必要な権限があることも確認してください。Power BIでは認証情報が必要になる場合があり、プライバシー設定は複数のソースのデータを結合する際に影響することがあります。認証情報とアクセス権は、レポートの管理に含まれるものとして扱いましょう。レポート作成者のアカウントでしか更新できない状態では、信頼できる業務プロセスとはいえません。

Power Queryのプレビューで変更を加える前に、列名、サンプル値、データの構造を確認します。選択したワークシートまたはテーブルに、タイトルページ、小計部分、メモではなく、必要なレコードが含まれていることを確認してください。レコードが複数の説明行の後から始まる場合は、データの範囲外であることが一貫している行だけを削除します。ファイル名や必須列など、ソースに関する前提を記録し、エクスポート形式が変更されたときに後任の担当者が気づけるようにします。

レポート用のデータ整形

変換を使用してレコードを整合させ、分析に適した状態にします。各列には適切なデータ型を設定します。取引日は日付、数量は数値として扱い、識別子は業務上の利用方法に応じて、テキストまたは数値として一貫して扱います。たとえば、先頭にゼロが付く商品コードは、そのゼロに意味がある場合、数値に変換しないでください。データ型は早い段階で正しく設定してください。データ型は、フィルタリング、計算、リレーションシップ、エラー検出に影響するためです。

テキストフィールドは、必要に応じて不要な空白や印字されない文字を削除してクリーンアップし、店舗名やステータスラベルなど、合意された対応表がある値は標準化します。曖昧な列名は明確な業務用語に変更し、レポートや監査上の目的がない列は削除します。また、繰り返し表示されるヘッダーや空白行など、取引データではない行を除外します。原因を理解せずにエラーを自動的に削除しないでください。変換エラーは、修正が必要な不正なレコードや、文書化された除外ルールの必要性を示している可能性があります。

レポートで答えるべき問いに合わせてデータの形を整えます。スプレッドシートで各月が別々の列に保存されている場合、それらの月列をピボット解除すると、商品と月ごとに1行が作成され、時間の経過に沿った分析が容易になることがあります。同じ構造を持つ1月と2月の店舗別エクスポートを結合するには、行を追加します。売上レコードに商品カテゴリを追加するには、商品キーを使って売上クエリと商品検索テーブルをマージし、その結果、レコード数が予期せず増えていないか、また商品が未一致のまま残っていないかを確認します。追加はレコードを積み重ね、マージは関連する列をまとめます。

準備済みデータの検証

検証では、変換が完了したかどうかだけでなく、業務上の意味も確認します。ソースの行数と準備済みデータの行数を比較し、意図的に除外したデータを説明できるようにします。空白の日付、欠落した取引識別子、負またはゼロの数量、想定外の売上値、重複レコードを確認します。返品や調整など、正当なケースもあるため、エラーと判断する前に業務ルールを適用してください。

マージでは、一致する商品が見つからなかった売上レコードの数と、検索テーブルの商品キーが一意であるかを確認します。キーが重複した検索テーブルをマージすると、売上行が重複し、売上高が水増しされる可能性があります。追加では、想定されたソースファイルがすべて含まれていること、またスペルや大文字・小文字の違いがあっても列が正しく対応していることを確認します。同じ店舗および期間について、準備済みデータの売上合計を信頼できるソースレポートと比較し、除外やタイミングの違いがあれば説明します。

変換処理は、別のアナリストが確認できるよう、理解しやすく順序立てて管理します。Power Queryでは、各操作が適用したステップとして記録されるため、値がどの段階でフィルタリング、名前変更、または形状変更されたかを確認できます。ソースのエクスポート形式が変わった場合は、更新が完了したからといって有効だと決めつけず、プレビューと影響を受けるステップを確認します。更新が成功したことは、データが取得されてステップが実行されたことを示すだけであり、最終的な業務上の数値が正しいことを証明するものではありません。

読み込み、更新、所有責任

準備済みクエリがレポートの要件を満たしたら、必要なテーブルをPower BIモデルに読み込みます。準備処理だけに使用し、個別のモデルテーブルとして必要ない中間クエリは、読み込みを無効にできる場合があります。これにより、モデルを必要なものに集中させられます。ただし、これは一律のルールではなく、レポート設計と監査要件に基づいて判断してください。Power Queryはデータを準備し、リレーションシップ、メジャー、レポートのビジュアルはモデル層とレポート層で処理します。

ソースの実際の運用プロセスに合わせて更新を計画します。毎週ファイルが特定のフォルダーに配置される想定であれば、フォルダーの場所とファイル構造が安定していること、また更新に使用するIDがアクセスできることを確認します。関連するすべてのソースの認証情報、想定する更新スケジュール、障害発生時の調査担当者を確認します。ファイルが移動または改名された場合や、列がなくなった場合は、ダッシュボードを再び信頼できる状態にする前にクエリの対応が必要になることがあります。

実務的な引き継ぎには、データソースの場所、重要な変換の目的、既知の除外事項、検証時の合計値、そしてソース変更の担当者を含めます。公開前のリリースチェックとして、必須レコードが存在すること、主要フィールドに適切なデータ型が設定されていること、結合が想定どおりに動作すること、合計値の整合が取れていること、そして更新アクセスの管理が個々のアナリストではなく業務プロセスによって行われていることを確認します。これらの管理策により、データ準備を再現可能にし、レポート利用者がダッシュボードを信頼するための明確な根拠を提供できます。