部門ごとに売上の定義が違う｜分析の前提を揃えるデータ品質管理

部門ごとに売上の定義が違う

本記事のポイント

1. 同じ「配達完了」でも、倉庫部門と営業部門とサポート部門で指す時点が違う
2. 定義をそろえるのは情報システム部門ではなく、そのデータで業務を行う部門
3. 全社を対象にせず、重要な指標を1つ選んで定義をそろえるところから始める

「売上」と聞いたとき、営業部門と経理部門が思い浮かべる数字は同じでしょうか。「顧客」も同じです。見込み客を含めるかどうかで、マーケティング部門と営業部門の顧客数は変わります。多くの企業で、こうした業務上の基本的な用語の定義が部門ごとに違っています。この状態で分析を行っても、前提がそろっていないため、結果を信頼できません。BIツールの導入やAI活用より先に、言葉の定義をそろえる作業が必要になります。

サイロ化を断ち切るデータ活用ガイド自社のデータ活用状況を診断する
データ活用の現在地と課題を整理
資料を無料ダウンロード▶

1. 定義の不一致が引き起こす問題
2. データガバナンスによる解決
3. 仕組みで支える
4. 正式な体制がなくても始められること
5. よくある質問
6. まとめ
7. 出典

1. 定義の不一致が引き起こす問題

配達完了の時点は部門によって違う

倉庫部門にとっての配達完了は、倉庫から出荷した時点です。一方で、営業部門にとっては、顧客先に届いた時点です。また、サポート部門にとっては、設置が完了した時点です。

この3つの部門がそれぞれの定義で配達完了率を集計すると、違う数字が出てきます。経営会議にこれらの数字が並んだとき、出席者はどの数字を使えばよいか判断できません。

同じ指標名で、算定の条件が違う

同じ「売上」という指標名に、部門ごとに違う算定の条件がついています。全社で1つの数字を指せる状態ではありません。

1つのデータについて、部門ごとに加工した版が5つ並ぶような状態も珍しくありません。それぞれのチームが自分たちの定義でデータを加工し、独自の表計算ファイルで管理しているためです。会議の時間の多くが「この数字は正しいのか」「なぜ自分のレポートと数字が違うのか」という確認に使われ、意思決定に進めません。本来は意思決定を支えるはずのデータが、確認の作業を増やしています。

💡STech I ワンポイントアドバイス

定義がそろっていない指標を見つけるには、同じ名前の指標を2つ以上の部門から出してもらい、同じ期間で比べます。差があった場合、各部門の担当者にその差の理由を聞きます。集計の期間、対象の範囲、除外の条件のどれかで説明がつけば、定義の問題です。説明がつかない場合は、データの欠損や更新の遅れが原因のこともあるため、そちらも確認します。

2. データガバナンスによる解決

共通用語を定義して文書にする

業務上の重要な用語について、全社で1つの定義を決めて文書にします。売上、顧客、受注、配達といった語が対象です。

この作業は情報システム部門だけで行うものではありません。各部門の関係者が主体となって進めます。データの意味を最もよく理解しているのは、日々そのデータを使って業務を行っている担当者だからです。

データカタログを作る

データカタログの作成、これも非常に重要です。社内にどのようなデータが存在し、どこに格納され、誰が管理していて、何の目的で使われているかを一覧できるようにします。

データカタログがなければ、「このデータはどこにあるのか」を探すことに時間を使います。同じデータが複数の場所に重複していることに気づかないまま、違うバージョンのデータで分析を行うこともあります。

3つの役割を決める

用語の定義をそろえる作業を続けるには、誰が何を担うかを決めておきます。

データオーナー: 定義について最終的な責任を持ちます。通常は業務部門の管理職が務めます。定義案と品質の基準を承認し、利用の方針を決めます
データスチュワード: オーナーが承認した定義を維持します。定義の更新、品質の監視、利用者からの問い合わせへの対応を担当します
データユーザー: 決まった定義に従ってデータを使います。定義と実際の数字が合わない場合はスチュワードに報告します

データの所有権は情報システム部門ではなく業務部門が持ちます。ここでいう所有権は、データの意味、品質の基準、利用の方針についての業務上の責任を指します。情報システム部門はデータの技術的な管理を担います。この区別がないと、定義を決める人が決まらないまま、集める作業だけが進んでしまいます。

Azure Databricks概要資料データ定義・メタデータを
一元管理する方法を知る
資料を無料ダウンロード▶

3. 仕組みで支える

用語の定義をそろえ、データカタログを作る。決めた内容を維持し続けるには、仕組みの側でも支える必要があります。Databricks の Unity Catalog がその例です。

メタデータと権限を1か所で管理する

Unity Catalog は、テーブル、ビュー、ボリューム、モデル、関数といったデータとAIの資産について、メタデータ、アクセス権限、来歴を1か所で管理する仕組みです。

業務用語の定義そのものを Unity Catalog が決めるわけではありません。部門間で合意した定義を、テーブルや列のコメントなどのメタデータとして紐づけて保持します。定義を決めるのは業務部門で、決まった定義を仕組みの上で保つのが Unity Catalog の役割です。

データの来歴をたどる

あるデータがどこから取り込まれ、どのような変換を経て、どのテーブルやモデルに使われているかをたどれます。定義を変更したときに、どこまで影響が及ぶかを事前に確認する材料になります。

自動で取得できるのは、主に Databricks 上で実行された処理です。外部のETLツールやBIツールで行われた処理は、連携の設定をするか、外部の来歴として登録しないと記録に残りません。そのため、取得できていない処理もあり、影響範囲を完全に把握できるわけではありません。

検索とメタデータの自動生成

自然文でテーブルを探したり、テーブルの説明を自動で作ったりする機能も提供されています。カタログを作って維持する手間を減らせます。ただし機能によって提供の段階が異なるため、利用する前に現在の提供状況を確認してください。

💡STech I ワンポイントアドバイス

来歴をたどると、途中で途切れている箇所が見つかります。外部のツールで処理している場合と、担当者が表計算ファイルで加工している場合のどちらもあります。どちらであるかは、その処理を行っている部門に聞かないと分かりません。途切れた箇所を一覧にして、外部ツールなら連携の設定を、手作業なら処理の内容の文書化を進めます。

4. 正式な体制がなくても始められること

データガバナンスと聞くと、全社的な組織改革が必要な大規模プロジェクトを想像されるかもしれません。しかし、最初の一歩は、もっと小さく始められます。

重要なデータを1つか2つ選ぶ

経営判断に効くデータを1つか2つ選び、そのデータに絞って定義をそろえます。売上データか、顧客データか、製品データか。自社にとって重要で、かつ定義の不一致が問題を起こしているデータから着手します。

利用者と所有者に聞く

データの現状を知るには、実際にデータを作り、管理し、使っている人に聞くことになります。どの部門がどのような定義でデータを使っているのか、どこで数字の不一致が起きているのか、どのような加工をしているのか。これらはシステムを調べるだけでは分かりません。

聞き取った内容を文書にし、関係者に共有します。この積み重ねが、全社のデータガバナンスの土台になります。

定義を揃える作業の流れ

💡STech I ワンポイントアドバイス

最初に選ぶデータは、経営会議に出ている指標の中から選びます。定義をそろえた結果が経営層の目に触れるため、次のデータへ進むときの合意を得やすくなります。着手は、対象の指標について部門ごとの現在の定義を1枚の表にまとめるところからです。差がどこにあるかが見えると、議論が具体的になります。

5. よくある質問

Q.　定義を決めるのは誰ですか。
定義案を作るのは、そのデータを使って業務を行っている部門です。複数の部門で案が分かれた場合に承認するのがデータオーナーです。情報システム部門は、決まった定義どおりにデータを保つ仕組みを作ります。

Q.　定義をそろえると、既存のレポートは作り直しになりますか。
対象の指標を使っているレポートは、集計の条件を直すことになります。作り直しの範囲を先に知るために、定義を変える前に、その指標がどのレポートで使われているかを調べます。データの来歴をたどれる仕組みがあれば、この調査を短くできます。

Q.　部門間で定義が折り合わない場合はどうしますか。
用途が違うために定義が分かれていることがあります。その場合は無理に1つにせず、別の名前の指標として両方を残し、それぞれの算定条件を文書に書きます。同じ名前で違う条件のまま残すことだけを避けます。