測定単位と定義｜データ要求・収集・利用条件

このページはプロモーション（広告）を含みます。

データ要求・収集・利用条件（初級・読む25分＋演習35分）

この授業のゴール

• 項目ごとに単位と基準（税込・税抜、円・千円、時刻帯、日付の締め）を明記できる
• 「売上」「アクティブ会員」などの言葉を、含める条件・除く条件・計算式・時点で定義できる
• 単位や基準が違うデータを、集計の前に1つの基準へそろえられる
• 測っている量と知りたい量のずれ（販売数と需要、0と欠損）を指摘できる

仕事でどう使うか

同じ「売上」という言葉でも、税込か税抜か、返品を引くか、何時で日付を締めるかで値が変わります。定義をそろえないまま比べると、存在しない差を見つけて間違った判断をします。

前提

次の言葉を使います。

• 単位と桁と丸め（円・千円、四捨五入）→ 単位と桁と丸め
• 割合とパーセントポイントの違い → 比率・割合・パーセントポイント
• 0と欠損（NULL/NaN）の違い → 数値・カテゴリ・日時・欠損、NULLと3値論理
• 判断・問い・1件の単位とデータ要求表 → 必要な問いとデータ

本文の Python では、pandas（表を扱うライブラリ）の基本的な操作を使います。コードを読めなくても、出力の表を見れば内容を追えるように書いています。

身近な状況：本部と店舗で売上が合わない

架空の「みどり商店」S1店の6月の売上について、2つの報告が届きました。

桁が3つ違います。さらに、本部の値を1000倍しても1,980,000で、店舗の値と158,400だけずれます。どちらかが間違っているのでしょうか。

調べると、次のことがわかりました。

• 本部の値の単位は千円。店舗の日報は円。
• 店舗の日報は税込、本部の会計は税抜。この例では税率を8%とします。
• 2,138,400円を税抜にすると、$2138400 \div 1.08 = 1980000$ 円 ＝ 1,980千円。両方とも正しかったのです。

もし単位と基準を確認しないまま「S1店は本部の数字より店舗の数字が8%大きい。日報の記入ミスが多いのでは」と報告していたら、存在しない問題のために店長を問い詰めることになります。

ほかにも、よく起きるずれがあります。

この授業では、こうしたずれを防ぐために、項目ごとに単位と定義を書いてからデータを集める方法を学びます。

直感的な説明：同じ名前、違う中身

体重を「60」と言われても、kg（キログラム）なのかlb（ポンド）なのかで、約2.2倍も違います。数字だけでは意味が決まらず、単位が必要です。

データの項目名も同じです。「売上」「顧客」「アクティブ」という名前は、ラベルにすぎません。中身を決めるには、次の4つが必要です。

1. 何を数えるか・足すか（対象）
2. 何を含め、何を除くか（条件）
3. どの単位・基準で表すか（単位）
4. いつの時点で、何時に締めるか（時点）

もう1つの直感は、測っている量と、本当に知りたい量は違うことがあるという点です。

• レジの「販売数」は、品切れの日には需要より小さくなります。
• アプリの「クリック数」は、関心の強さの代わりに使われますが、誤タップも含みます。
• アンケートの「満足度5段階」は、満足そのものではなく、満足についての回答です。

これらは使ってはいけないわけではありません。ずれがあることを知り、そのずれを要求表と定義書に書いておくことが大切です。

正確な定義：単位・基準・操作的定義・測定のずれ

• 測定単位：数値の大きさを表す基準。円、千円、個、分、%など。
• 基準：同じ単位でも値を変える取り決め。税込／税抜、時刻帯（UTC／日本時間）、日付の締め時刻、為替レートの日付など。
• 操作的定義：抽象的な言葉を、データで計算できる手順に置き換えたもの。対象・含める条件・除く条件・計算式・単位・時点で書く。
• 測定のずれ：測っている量と知りたい量の差。妥当性（知りたいものを測れているか）の問題とも言う。

単位をそろえる計算を確認しましょう。税込金額を $P_{\text{in}}$（円）、税率を $r$（小数。8%なら0.08）とすると、税抜金額 $P_{\text{ex}}$（円）は次のとおりです。

$$P_{\text{ex}} = \frac{P_{\text{in}}}{1 + r}$$

数値を代入すると、$P_{\text{in}} = 2138400$、$r = 0.08$ のとき $P_{\text{ex}} = 2138400 \div 1.08 = 1980000$ 円です。千円単位にするには1000で割り、1,980千円になります。

注意：実際の税率は品目や時期で変わります（執筆時点（2026年）の一般的な説明として、日本では食品などに軽減税率があります。最新は公式情報で確認してください）。データの税率は、定義書に「どの税率で、どの時点の制度で計算したか」まで書きます。

指標の定義書の型：1つの指標について、次の表を埋めます。

0と欠損の区別も定義書に書きます。「0」は測って0だったこと、欠損（NULL、NaN）は測れなかった・記録がないことです。休業日の売上は0ではなく欠損（そもそも営業していない）、と決めておかないと、平均を計算したときに値がずれます。

段階付き例題：「6月30日の売上」をデータから計算する

S1店の取引記録の一部です（金額は税込、税率8%）。

ステップ1（入力）：定義書の「日次売上」を使います。日本時間の0:00〜23:59に支払いが完了した取引の税抜金額。返品は返品日に別計上。

ステップ2（処理：対象を選ぶ）

• T5 は7/1の0:03なので6/30には入らない。
• T6 は取消なので除く。
• T3 は7/1に返品されたが、定義では「返品日に別計上」なので、6/30の売上には含める。

対象は T1〜T4。税込合計は $1080 + 2160 + 540 + 1620 = 5400$ 円。

ステップ3（処理：単位をそろえる）

$5400 \div 1.08 = 5000$ 円（税抜）。

ステップ4（出力と意味）

6/30の日次売上は 5,000円。

別の定義だったら？ もし定義が「返品された取引は、元の注文日にさかのぼって除く」なら、T3（税抜 $540 \div 1.08 = 500$ 円）を除いて 4,500円 になります。さらにこの定義では、7/1に返品が起きた時点で、6/30の値が後から変わることになります。どちらの定義も使われますが、混ぜてはいけません。

データを集める前に、どちらの定義で記録・集計されているかを、データの提供元に確認します。

操作して理解する：時刻帯のずれと、0と欠損

(1) UTCのログを日本時間の日付に直す

アプリのログは UTC（協定世界時）で記録されることがよくあります。日本時間は UTC より9時間進んでいます。pd.Timedelta(hours=9) は「9時間」という時間の長さを表し、日時に足すと9時間後の日時になります。.dt.strftime('%Y-%m-%d') は日時を「年-月-日」の文字列に変換します。

import pandas as pd

logs = pd.DataFrame({
    'event_id': [1, 2, 3, 4, 5],
    'ts_utc': pd.to_datetime(['2025-06-30 14:30', '2025-06-30 15:10', '2025-06-30 23:50',
                              '2025-07-01 02:00', '2025-07-01 16:00']),
})
logs['ts_jst'] = logs['ts_utc'] + pd.Timedelta(hours=9)
logs['date_utc'] = logs['ts_utc'].dt.strftime('%Y-%m-%d')
logs['date_jst'] = logs['ts_jst'].dt.strftime('%Y-%m-%d')
print(logs[['event_id', 'date_utc', 'date_jst']])
print(logs.groupby('date_utc').size())
print(logs.groupby('date_jst').size())

出力（要点）：

date_utc
2025-06-30    3
2025-07-01    2
date_jst
2025-06-30    1
2025-07-01    3
2025-07-02    1

UTCの日付で数えると6/30は3件、日本時間なら1件です。同じ5件のログでも、日付の基準で日別件数が変わります。日本の店舗の売上と比べるなら、日本時間にそろえてから数えます。

(2) 休業日を0にすると平均が下がる

np.nan は欠損を表す値です。mean() は欠損を除いて平均し、fillna(0) は欠損を0で埋めます。

import numpy as np
import pandas as pd

sales = pd.Series([100, 120, np.nan, 110, 90, 130, 150],
                  index=['月', '火', '水', '木', '金', '土', '日'])  # 水曜は休業
print('欠損を除いた平均:', round(sales.mean(), 1))
print('欠損を0にした平均:', round(sales.fillna(0).mean(), 1))

出力：

欠損を除いた平均: 116.7
欠損を0にした平均: 100.0

「営業日1日あたりの売上」を知りたいなら116.7が正しく、100.0は休業日を「売上0の営業日」と扱った誤りです。値を変えて試してください。水曜の np.nan を 0 に書き換えると、2つの平均は同じになります。それは「水曜は営業したが1つも売れなかった」という別の事実を表すことになります。

発展：信頼性・妥当性と、定義の変更

信頼性と妥当性：測定の良さには2つの面があります。

信頼性が高くても妥当性が低いと、同じ方向に毎回ずれるため、データを増やしても誤りが減りません。このようなずれを系統誤差と呼び、毎回ランダムにぶれる偶然誤差と区別します。

代理指標：直接測れない量の代わりに使う指標です（例：関心の代わりにクリック数）。代理指標を目標にすると、代理指標だけが改善して本来の目的が改善しないことがあります（クリックを増やすために紛らわしいボタンを置く、など）。定義書に「何の代理か」「どこがずれ得るか」を書きます。

定義の変更：業務の変化で定義は変わります（例：4月から社員割引を売上に含める）。変更した場合は、変更日・変更前後の定義・影響の大きさを記録し、前後の期間をそのまま比べないようにします。データの版の管理は 「データセット版」（有料版） で扱います。

時刻帯の正確な扱い：本文では9時間を足しましたが、夏時間がある国では時差が季節で変わります。実務では、時刻帯の情報を持つ日時型（pandas なら tz_localize('UTC').tz_convert('Asia/Tokyo')）を使い、保存はUTC、表示や日付の集計は業務の時刻帯、と決めることが多いです。

よくある失敗

失敗1：税込と税抜を混ぜて合計する

誤った計算：店舗Aは税込、店舗Bは税抜で報告しているのに、そのまま足して比べる。

そのまま比べると「Aのほうが30,000円多い」。しかし税抜にそろえると A は $1080000 \div 1.08 = 1000000$ 円で、実はBのほうが50,000円多いのです。

なぜ誤りか：基準が違う数字を足したり比べたりすると、差の向きまで逆になることがあります。

直し方：データ要求表とデータ辞書に「税込／税抜」の列または注記を必ず入れ、集計の前に1つの基準にそろえます。

失敗2：UTCのまま日付で集計する

誤った例：アプリの購入ログ（UTC）を、日付部分だけ取り出して日別売上にする。

日本時間の7月1日 08:30 の購入は、UTCでは6月30日 23:30 と記録されます。日付部分だけ取ると「6月30日の購入」になります。日本時間の0時〜9時の購入が、すべて前日に計上されるのです。

なぜ誤りか：店舗のレジ（日本時間）と比べると、アプリだけ朝の売上が前日にずれ、「アプリは前日夜に強い」という誤った傾向が見えます。

直し方：時刻の項目には必ず時刻帯を書きます（例：ordered_at_utc）。日付で集計する前に業務の時刻帯へ変換します。

失敗3：欠損（休業・記録なし）を0で埋める

誤った例：休業日の売上が空欄だったので、0で埋めてから1日平均を出す。本文の例では、正しい営業日平均116.7が100.0に下がりました。

なぜ誤りか：0は「営業して1つも売れなかった」という観測値です。休業や記録漏れは「観測していない」ので、0とは意味が違います。0で埋めると平均が下がり、来週の発注量も少なくなります。

直し方：定義書に「欠損の意味」（休業／システム障害／未入力）を書き、欠損のまま扱うか、理由ごとに別の処理をします。0で埋めてよいのは「記録がない＝0件」と定義で決まっている場合だけです（例：問い合わせが1件もなかった日）。

失敗4：割合の差を「%」で言う

誤った報告：「アクティブ会員率が30%から33%に、3%上がりました」。

なぜ誤りか：30%から33%への変化は、差で言えば 3ポイント（pt）、比で言えば $(33 - 30) \div 30 = 0.10$ で 10%の増加です。「3%上がった」は、どちらの意味か読み手にわかりません。

直し方：割合どうしの差は「ポイント（pt）」、元の値に対する増え方は「%増」と書き分けます。定義書の「単位」欄に「%（差はpt）」と書いておくと混乱が減ります。

まとめ

• 数字の意味は、単位（円・千円）と基準（税込・税抜、時刻帯、締め時刻）がそろって初めて決まる。
• 指標は、対象・含める条件・除く条件・計算式・単位・時点・責任者で定義書に書く。
• 単位や基準が違うデータは、集計の前に1つにそろえる。税込から税抜は (1＋税率) で割る。
• 0は「測って0」、欠損は「測れていない」。0で埋めると平均がずれる。
• 測っている量と知りたい量はずれることがある。信頼性（安定）と妥当性（的を射ている）は別。

用語

操作的定義（operational definition）

抽象的な言葉を、データで計算できる手順（対象・条件・計算式・単位・時点）に置き換えたもの。

UTC（協定世界時）（Coordinated Universal Time）

世界共通の時刻の基準。日本時間はUTCより9時間進んでいる。

妥当性（validity）

測定が、知りたいものを測れている度合い。

信頼性（reliability）

同じものを測ったときに同じ値が得られる度合い。

代理指標（proxy metric）

直接測れない量の代わりに使う指標。何の代理で、どこがずれ得るかを記録する。

よくある質問

なぜ指標の定義をわざわざ文書にする必要があるのですか？

定義が人の頭の中にしかないと、担当者が変わったり部署をまたいだりしたときに数字が合わなくなるからです。数字が合わない原因を調べる時間は、定義書を作る時間よりずっと大きくなります。

「単位」と「基準」は何が違うのですか？

単位は数値の大きさの尺度（円・千円・個・分）です。基準は、同じ単位でも値を変える取り決め（税込／税抜、UTC／日本時間、締め時刻）です。どちらも書かないと値の意味が決まりません。

どこで失敗しやすいですか？

複数のシステムのデータを結合するときです。レジは日本時間・税込、アプリはUTC・税抜、会計は千円・税抜、というように、システムごとに基準が違うことがよくあります。結合の前に、項目ごとの単位と基準を表にして確認します。

定義が途中で変わったらどうすればよいですか？

変更日、変更前後の定義、影響の大きさ（変更前の期間を新しい定義で計算し直すと何%変わるか）を記録します。変更前後をそのまま並べたグラフには、変更日に線を引き注記します。

仕事でどちらの定義を選ぶか、どう判断しますか？

その数字で行う判断に合う定義を選びます。たとえば日々の発注には「当日に確定し後から変わらない」定義が使いやすく、利益の評価には「返品を差し引いた」定義が適しています。1つに決められなければ、2つの指標を別名で並べます。

測定のずれがあるデータは使わないほうがよいですか？

完全にずれのないデータはほとんどありません。ずれの向きと大きさを把握し、定義書や報告に書いたうえで使います。品切れ日の販売数のように向きがわかっているずれは、補正したり、その日を分けて扱ったりできます（収集方法とバイアス）。

確認問題

次に学ぶこと

次は 収集方法とバイアス で、データの集め方によって生じる偏り（バイアス）を扱います。この授業の「品切れ日の販売数は需要より小さい」は、集め方の偏りの代表例として続きます。

割合とポイントの違いに不安があれば 比率・割合・パーセントポイント、NULLの扱いは NULLと3値論理 に戻ってください。指標の定義書はDXの 「成果と先行指標」（有料版） でも使います。