【ITニュース解説】From Dirty Logistics Data to a Management-Ready Power BI Solution

ビジネスインテリジェンス（BI）プロジェクトでは、単に見た目の良いグラフを作るだけでは不十分で、その土台となるデータの準備が極めて重要だ。データがビジネスの意思決定に使える状態になるまでには、データの意味を理解し、汚れた部分をきれいにし、統一し、適切な形にモデル化し、そして正しく検証するという一連の工程が不可欠となる。これは、JCars Logisticsという自動車販売・物流会社のPower BIプロジェクトを通じて得られた中心的な学びである。

このプロジェクトは、ケニアに拠点を置くJCars Logistics社のために、包括的なBIソリューションを開発することを目的とした。提供された元データには、販売、顧客、車両、支払い、配送状況、物流コスト、収益など、多様な情報が含まれていたが、実際の業務データによく見られる多くの問題も抱えていた。具体的には、重複した識別子、日付形式の混在、無効な日付、数値であるべき列に文字が混入している、複数通貨の使用、財務的な値の不一致などだ。この記事では、このような課題を抱えた生データから、経営層が意思決定に使えるPower BIレポートを作成するまでの過程を解説する。

まず、JCars Logisticsの経営層が何を求めているのかを深く理解することから始めた。彼らは、会社の収益と利益の実態、貢献度の高い支店や車両タイプ、配送サービスの品質、物流コストや赤字注文の特定、返品が多い車両、そして元データの信頼性といった具体的なビジネス上の問いに対する答えを求めていた。これらの課題を解決するため、プロジェクトは、元データの状態を把握する「プロファイリング」から始まり、Power Queryというツールでの「データクリーニングと検証」、データを分析しやすい形に整える「次元モデルの構築」、DAXという数式言語での「メジャー作成」、経営層向けレポートの「デザイン」、レポート全体の「テスト」、そして分析結果からの「提言」という流れで進められた。

入手した生データは276行32列のCSVファイルで、各行が注文記録を表していた。ここで重要な判断は、元データの注文IDが信頼できないため、別途Source Row ID（元行ID）という安定した識別子を追加したことだ。データクリーニングに取りかかる前に、全てのデータ列を詳しく確認する「データプロファイリング」を行った。この作業により、日付の混在、表記揺れ、数値列への文字混入、複数通貨の使用など、21もの異なるデータ品質上の問題が明らかになった。この結果、不確実なデータに対しては無理に完璧な形に修正するのではなく、ヌル値や品質ステータスを明示することで、データの不確実性をレポート上で可視化する方針を定めた。

データクリーニング作業はPower Queryを使って段階的に進められた。元のデータを参照用として保持しつつ、別のクエリで変換を行う方法を採用した。特に日付フィールドは、様々な形式が混在し、無効な日付も含まれていたため、慎重な解析と判断を要した。修正可能な日付は補正し、修正できない場合はヌル値とし、そのデータの「日付検証ステータス」を明確にした。これにより、日付に問題がある記録もデータセットから除外せず、かつ誤った計算に使われないようにした。

財務データには複数の通貨が混在していたため、これらを正確に合計できるよう、プロジェクトで定めた固定換算レートを用いて全ての金額をケニアシリングに統一した。また、データセット内の「記録された収益」をそのまま信用せず、販売単位や価格、割引率などから「計算された収益」を独自に算出し、両者を比較検証した。その結果、約半数の記録で収益が不一致であることが判明した。この重要な事実はレポート上で明確に表示され、ビジネスパフォーマンスだけでなく、その基となるデータの信頼性も伝える方針とした。

さらに、支払い、配送、返品といった情報を分析し、注文が「アクティブな収益」としてカウントされるべきかを判断するため、「最終取引ステータス」という新しい分類を作成した。これは「アクティブセール」「返品済み」「キャンセル済み」「払い戻し済み」の四つのカテゴリから成り、主要なビジネス指標（KPI）では「アクティブセール」の記録のみを対象とすることで、実際のビジネス状況をより正確に反映させた。

データが整備された後、最終的なPower BIモデルを、分析に適した効率的な「スター型スキーマ」構造で構築した。中央に全ての注文情報を集約したファクトテーブルを置き、その周りに日付、支店、営業担当者、車両といったマスターデータを格納したディメンションテーブルを配置した。これらのテーブル間は、効率的なデータ抽出とフィルタリングを可能にするよう、適切な関係性で結び付けられている。特に日付テーブルは、注文日と配送日という二つの異なる日付軸での分析を、一つのテーブルでサポートできるように工夫された。

次に、DAXという数式言語を使って、分析に必要な「メジャー」（計算式）を多数作成した。これらのメジャーは、ビジネスロジックを明確にし、一度作成すればレポートの様々な場所で再利用できる利点がある。Power Queryが行レベルのデータ変換を行うのに対し、DAXはレポート上でフィルターに反応する集計値や計算値を生み出す役割を担った。

レポートは、経営層向けの概要、販売と収益性、運用と物流、顧客とデータ品質、そして洞察と提言という五つの主要なページで構成された。「顧客とデータ品質」ページを含めたのは、経営層が提示されたKPIの信頼性を理解することが重要だと考えたからである。支店詳細や車両ツールチップといったインタラクティブな機能も盛り込み、主要な情報をシンプルに保ちつつ、必要に応じて詳細な情報を確認できるように工夫した。

最終的な分析結果として、約9億500万KESのアクティブセール収益と約9,920万KESのアクティブ粗利益が確認された。オンタイム配送率は91.87%と良好だったが、一部支店では配送パフォーマンスにばらつきが見られた。返品率は34.38%と高く、特に一部の車両タイプで高かった。SUVは最も収益性の高い車両タイプだったが、製品集中リスクも指摘された。これらの分析結果に基づき、収益性の保護、配送パフォーマンスの改善、返品の削減、データコントロールの強化、集中リスクの管理という五つの具体的な経営提言がまとめられた。

プロジェクトの最終段階では、レポート全体の徹底的な品質保証レビューを行い、データの一貫性、機能性、表示の正確性を確認した。このプロジェクトを通じて、データクリーニングは単なる技術作業ではなく、ビジネス理解と判断が不可欠であること、計算値と記録値の不一致が重要なビジネス上の発見となること、Power QueryとDAXの役割分担、そしてデータ品質をビジネスパフォーマンスの一部として扱うことの重要性を再認識した。

結論として、JCars Logisticsのソリューションは単なるダッシュボードではなく、元データを保持し、仮定を明確にし、財務値を検証し、取引の状態を分類し、具体的なデータから経営層の行動へと繋がる、包括的で信頼性の高い分析システムとなった。最も重要な成果は、単にKPIを生成したことではなく、それらのKPIが、明確に文書化されたルール、クリーニングの決定、そして検証結果まで遡って確認できるような信頼性の高いレポートを構築できたことにある。