必要な問いとデータ｜データ要求・収集・利用条件

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

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

この授業のゴール

• 「データがほしい」という依頼を、誰が・いつ・何を決めるかという判断の形に書き直せる
• 判断に必要なデータの「1件の単位」「項目」「頻度・期間・精度」を決められる
• 判断に使わない項目（氏名・電話番号など）を収集対象から外す理由を説明できる
• 問いとデータの対応を1枚のデータ要求表にまとめられる

仕事でどう使うか

分析の失敗の多くは、計算の前の段階で起きています。何を決めるためのデータかを決めずに集めると、量は多いのに肝心の項目が足りない、という状態になります。

このモジュール（DA01）では、分析の前に「何を・どこから・どの条件で集めてよいか」を決める力を身につけます。この授業はその出発点です。

前提

次の言葉を使います。不安があれば先に戻ってください。

• データ・情報・判断の違い（データは記録、判断は行動の選択）→ データ・情報・判断の違い
• 1行の単位（表の1行が何を表すか）→ 行と列と1行の単位、テーブルと1行の単位
• 数値・カテゴリ・日時・欠損という列の種類 → 数値・カテゴリ・日時・欠損

この授業ではプログラムを書く力はほとんど必要ありません。本文の Python は 実行 ボタンを押すだけで結果が表示されます。

身近な状況：「売上データを全部ください」から始まった2週間

架空の食品スーパー「みどり商店」（15店舗）で、店長会議の後にこんな依頼がデータ担当に届きました。

売れ残りと品切れが多いので、売上データを全部ください。分析してください。

データ担当は、3年分のレジ明細（約2億行）を取り出しました。会員の氏名・電話番号も付いたままです。抽出と確認に2週間かかりました。ところが、店長と話してわかったのは次のことでした。

• 店長が実際に決めたいのは、毎日15時に、商品ごとの翌日の発注数。
• そのためには「その日、商品が品切れになった時刻」が必要。品切れ後は売れないので、販売数だけでは本当の需要がわからない。
• 会員の氏名や電話番号は、発注数を決めるのに一度も使わない。

つまり、2週間かけて集めたデータには、不要な個人情報が大量に含まれ、必要な「品切れの情報」は入っていませんでした。

この授業では、こうした遠回りを避けるために、判断から逆算して必要なデータを決める方法を学びます。

直感的な説明：献立を決めてから買い物に行く

夕食の買い物を思い浮かべてください。献立を決めずにスーパーに行くと、カゴはいっぱいなのに、肝心のカレールーを買い忘れます。献立（何を作るか）を先に決めれば、必要な材料と量が決まります。

データ収集も同じです。順番は次のとおりです。

1. 判断：誰が、いつ、何を決めるのか（献立）
2. 問い：その判断のために、何がわかればよいか（作り方）
3. 必要な数字：問いに答えるために計算する値（材料の分量）
4. データ項目：その数字を作るために記録・収集するもの（買う材料）

逆向き、つまり「手元にあるデータから何か言えないか」と考えるのが悪いわけではありません。新しい発見のための探索としては役に立ちます。ただし業務の改善や研究では、まず判断と問いを決めないと、集めたデータが判断に届かないことが起きます。

もう1つの直感は「1件の単位を判断に合わせる」ことです。翌日の発注数を商品ごとに決めるなら、データも「店舗×商品×日」で1件にする必要があります。月ごとの店舗合計しかなければ、商品ごと・日ごとの判断はできません。逆に、レシート1枚ごとの細かいデータは、集計すれば使えますが、氏名など余計な情報を含みがちです。

正確な定義：判断・問い・データ要求

この授業で使う言葉を定義します。

• 判断（意思決定）：選択肢の中から行動を1つ選ぶこと。「誰が」「いつ（どの頻度で）」「何を（どの選択肢から）」の3点で書く。例：店舗担当者が、毎日15時に、商品ごとの翌日発注数（0〜200個）を決める。
• 問い：判断のためにデータで答える質問。対象・期間・比べる相手を含めて書く。例：「明日、店舗S1で牛乳は何本売れる見込みか。過去の同じ曜日と比べてどうか」。
• 1件の単位（分析単位）：データの1行が表すもの。表の粒度とも言う。例：店舗×商品×日。
• データ要求：問いに答えるために必要なデータの条件をまとめたもの。次の6つで書く。

さらに、次の原則を守ります。

• データ最小化：判断に使わない項目は集めない。特に個人を特定できる情報は、使う理由が説明できない限り外す。漏洩・目的外利用のリスクを減らせる（利用条件は 出所と利用条件 で扱います）。
• 入手できる ≠ 使ってよい：手元にあるからといって、利用条件の確認されていないデータを「精度が上がるから」と混ぜない。
• 問いに答えられるかを先に確認する：必要な項目が存在しない場合、分析の前に追加収集を計画する（不足と追加収集）。

段階付き例題：翌日の発注に必要なデータを決める

みどり商店の依頼を、データ要求表にしていきます。

ステップ1：判断を書く（入力：依頼文）

「売れ残りと品切れを減らしたい」は目的であって、判断ではありません。店長に「最終的に何を決めますか」と聞き、次のように書き直しました。

各店舗の日配品担当者が、毎日15時に、商品ごとの翌日発注数を決める。

ステップ2：問いを書く

明日、店舗×商品ごとに何個売れる見込みか。品切れになる確率はどのくらいか。

ステップ3：1件の単位を決める

判断が「店舗×商品×日」なので、1件の単位も 店舗×商品×日。15店舗×300品目×730日＝3,285,000行です。レシート明細の約2億行よりはるかに小さくなります。

ステップ4：項目を選ぶ（処理）

ステップ5：期間・頻度・精度を決める

• 期間：直近2年。年末年始やお盆を2回含めるため。1年だけだと、その年だけの特殊な出来事と季節の違いを区別できない。
• 頻度と鮮度：日次。15時の判断に間に合うよう、前日分が当日9時までに揃うこと。
• 精度：販売数は個数の整数。品切れ時刻は1時間単位で足りる（分単位までは不要）。

ステップ6：意味を確認する（出力）

できた要求表を店長に見せ、「この表があれば発注数を決められるか」を確認します。この時点で「発注から納品まで2日かかる商品がある」とわかり、納品までの日数を項目に追加しました。

注意：品切れした日の販売数を、そのまま「需要」として使ってはいけません。棚が空なら0個しか売れませんが、欲しい人がいなかったわけではないからです。この「測っている量と知りたい量のずれ」は 測定単位と定義 と 収集方法とバイアス で詳しく扱います。

操作して理解する：細かい明細を判断の単位に集計する

レジ明細（1行＝レシートの中の1商品）を、判断の単位「店舗×商品×日」に集計してみます。集計すると、氏名や電話番号は不要になるので受け取らなくてよいことがわかります。

使う関数：groupby([列のリスト], as_index=False) は、指定した列の値の組み合わせごとにグループを作ります。['qty'].sum() は各グループの数量を合計し、結果をデータフレーム（表）で返します。

import pandas as pd

# レジの明細（1行＝レシートの中の1商品）。架空のデータです
pos = pd.DataFrame({
    'receipt_id': [101, 101, 102, 103, 104, 105, 106],
    'store_id':   ['S1', 'S1', 'S1', 'S2', 'S1', 'S2', 'S1'],
    'date':       ['2025-06-01', '2025-06-01', '2025-06-01', '2025-06-01',
                   '2025-06-02', '2025-06-02', '2025-06-02'],
    'item_id':    ['milk', 'bread', 'milk', 'milk', 'milk', 'bread', 'bread'],
    'qty':        [2, 1, 1, 3, 2, 1, 2],
    'member_name':['佐藤', '佐藤', None, '鈴木', '田中', None, '佐藤'],
    'phone':      ['090-xxxx-0001', '090-xxxx-0001', None, '080-xxxx-0002',
                   '070-xxxx-0003', None, '090-xxxx-0001'],
})

need = pos.groupby(['store_id', 'item_id', 'date'], as_index=False)['qty'].sum()
print(need)
print('明細の行数:', len(pos), '→ 判断の単位の行数:', len(need))

出力は次のとおりです。

  store_id item_id        date  qty
0       S1   bread  2025-06-01    1
1       S1   bread  2025-06-02    2
2       S1    milk  2025-06-01    3
3       S1    milk  2025-06-02    2
4       S2   bread  2025-06-02    1
5       S2    milk  2025-06-01    3
明細の行数: 7 → 判断の単位の行数: 6

結果の表には、member_name も phone もありません。発注の判断には使わないからです。データを受け取る段階で、集計済みの表だけを依頼すれば、個人情報を扱わずに済みます。

考えてみましょう。

1. S2 の bread の 2025-06-01 の行がありません。これは「0個売れた」のでしょうか、それとも「その日は棚になかった（品切れ・未入荷）」のでしょうか。明細からは区別できません。だから品切れ情報（在庫の記録）が別に必要です。
2. 判断が「週に1回、来週分をまとめて発注する」に変わったら、1件の単位はどうなるでしょう。答え：店舗×商品×週。
3. 判断が「会員ごとにおすすめクーポンを送る」に変わったら？ 答え：1件の単位は会員になり、会員IDが必要になります。ただし、会員データをクーポン配信に使ってよいかという利用目的の確認が新たに必要です（出所と利用条件）。

発展：問いの分解と「あると便利」の罠

問いの分解：大きな問いは、答えられる小さな問いに分けます。

副問いごとに項目を書くと、「どの項目が、どの問いのために必要か」が説明できます。説明できない項目は「あると便利」なだけで、収集の理由になりません。

「あると便利」の罠：項目を増やすと、次の費用が増えます。

• 収集費用：現場の入力負担、システム改修、外部データの購入費
• 管理費用：保存、アクセス管理、漏洩時の被害
• 品質費用：項目が多いほど欠損や誤記のチェックが増える

ML（機械学習）での追加の条件：予測に使う項目は、予測する時点で手に入るものだけです。15時の発注判断に、当日夜に確定する販売数は使えません。この「利用時点」の考え方は 目的変数と利用時点 で学びます。

RS（研究）での対応：研究では、問い→構成概念（測りたい抽象的な概念、例：顧客満足）→操作的定義（具体的な測り方、例：5段階評価の回答）の順に決めます。測り方の定義は 測定単位と定義 で扱います。

限界：判断が決まっていない探索的な段階もあります。その場合は「探索用に、期間と項目を限定した小さなデータ」を先に取り、判断が決まってから本格的に要求表を作る、という2段階で進めます。

よくある失敗

失敗1：「とりあえず全部ください」と依頼する

誤った依頼：

売上に関係ありそうなデータを全部ください。

なぜ誤りか：受け取る側は何を出せばよいか判断できず、手元にあるものを出すしかありません。結果として、不要な項目（氏名・電話番号）が大量に届き、必要な項目（品切れ時刻・リードタイム）は抜けます。抽出・確認の手間も大きくなります。

直し方：判断・問い・1件の単位・項目と理由・期間・頻度を書いたデータ要求表で依頼します。

15店舗の日配品（約300品目）について、店舗×商品×日の販売数・閉店時在庫・品切れ時刻（1時間単位）・価格・販促有無を、2023-07-01〜2025-06-30の期間でください。翌日発注数を決めるために使います。会員情報は不要です。

失敗2：1件の単位が判断とずれている

誤った例：店舗ごとの月次合計だけで、商品ごとの日次発注を決めようとする。

ある店舗の牛乳の6月の販売合計が3,000本だったとします。1日平均は $3000 \div 30 = 100$ 本です。この100本を毎日発注するとどうなるでしょう。

（平日86本×22日＋土日138本×8日＝1892＋1104＝2996本で、月合計とほぼ一致します。）

なぜ誤りか：月次合計は曜日の違いを平均で消してしまいます。判断が日次なら、データも日次でなければ判断に使えません。

直し方：判断の単位（店舗×商品×日）を先に決め、その粒度のデータを要求します。粗いデータから細かいデータは作れませんが、細かいデータは集計して粗くできます。

失敗3：判断に使わない個人情報まで受け取る

誤った例：レジ明細を会員の氏名・電話番号付きのまま受け取り、分析用フォルダに保存する。

receipt_id, store_id, date, item_id, qty, member_name, phone
101, S1, 2025-06-01, milk, 2, 佐藤, 090-xxxx-0001

なぜ誤りか：

• 発注数の判断には一度も使わない。
• 分析用フォルダは多くの人が見られることが多く、漏洩したときの被害が大きい。
• 会員情報は「会員サービスの提供」などの目的で集めたもので、別の目的に使ってよいかは確認が必要（目的外利用の恐れ）。

直し方：データを出す側で「店舗×商品×日」に集計してから受け取ります。どうしても個人単位の分析が必要なら、氏名の代わりに仮名ID（本人と直接結びつかない番号）を使い、その理由を要求表に書きます。

失敗4：期間が短すぎて季節を区別できない

誤った例：直近3か月（4〜6月）のデータだけで、12月の発注量を決める仕組みを作る。

なぜ誤りか：4〜6月には年末の需要の増加が1回も含まれていません。どれだけ精密に計算しても、データにない状況は学べません。

直し方：判断が対象とする状況（季節・曜日・販促・年末年始）が、期間の中に少なくとも数回含まれるように期間を決めます。翌日発注なら、季節を2回含む2年が目安です。期間を伸ばせない場合は、「年末は対象外」と適用範囲を明記します。

まとめ

• データ収集は「判断 → 問い → 必要な数字 → データ項目」の順に逆算して決める。
• 判断は「誰が・いつ・何を」、問いは「対象・期間・比べる相手」を含めて書く。
• 1件の単位は判断の単位に合わせる。粗いデータから細かい判断はできない。
• データ要求は、1件の単位・項目と理由・対象範囲・期間・頻度と鮮度・精度の6つで書く。
• 判断に使わない項目、特に個人情報は集めない（データ最小化）。入手できることと使ってよいことは別。

用語

判断（意思決定）（decision）

選択肢の中から行動を1つ選ぶこと。誰が・いつ・何をの3点で書く。

1件の単位（分析単位）（unit of analysis）

データの1行が表すもの。判断の単位に合わせて決める。表の粒度とも言う。

データ要求（data requirements）

問いに答えるために必要なデータの条件。1件の単位、項目と理由、対象範囲、期間、頻度と鮮度、精度で書く。

データ最小化（data minimization）

目的に必要な範囲のデータだけを集め、保存する原則。

仮名ID（pseudonymous ID）

氏名などの代わりに使う番号。それだけでは本人を直接特定しにくいが、対応表があれば特定できるため、取り扱いには注意が必要。

よくある質問

なぜデータを集める前に判断を決める必要があるのですか？

判断が決まると、1件の単位・項目・期間・鮮度が決まるからです。判断を決めずに集めると、量は多いのに必要な項目（品切れ時刻など）が抜け、不要な項目（個人情報）が混ざります。集め直しは時間も費用もかかります。

「目的」と「判断」は何が違うのですか？

目的は「売れ残りを減らしたい」のような望む状態です。判断は「誰が・いつ・何を選ぶか」という具体的な行動の選択です。目的だけでは必要なデータが決まらないので、目的を達成するために実際に何を決めるのかを聞き出します。

探索的に「何か面白いことがわからないか」とデータを見るのはダメですか？

ダメではありません。新しい仮説を見つける段階では役に立ちます。ただし、期間や項目を限定した小さなデータで行い、個人情報は外します。探索で仮説が見つかったら、判断と問いを決めて正式なデータ要求表を作ります。

細かいデータ（レシート明細）を受け取っておけば、後で何にでも使えるのでは？

細かいデータは集計して粗くできるので便利なのは事実です。しかし個人情報が含まれやすく、保存・管理の費用とリスクが増えます。判断の単位まで集計してから受け取れるなら、そのほうが安全です。個人単位の分析が本当に必要なら、仮名IDを使い、理由を記録します。

判断する人がはっきりしない依頼はどうすればよいですか？

「この分析の結果を見て、誰が何を変えますか」と聞きます。答えが出ない場合、分析しても行動につながらない可能性が高いです。仕事では、判断する人と時期がはっきりするまで、大きなデータ収集を始めないのが安全です。

要求表を作っても、後から項目が足りないとわかったらどうしますか？

よくあることです。足りない項目と、それがどの問いのために必要かを書き足し、追加収集を計画します（不足と追加収集）。最初の要求表は完璧である必要はなく、何を根拠に集めたかが記録されていることが大切です。

確認問題

次に学ぶこと

次は 測定単位と定義 で、集める項目の測定単位と定義を決めます。「販売数」「売上」「顧客」という同じ言葉でも、人や部署によって意味が違うことを扱います。

表の1行の単位に不安があれば 行と列と1行の単位 に戻ってください。この授業の確認問題だけでモジュールの習得とはしません。DA01 の総合テストと、別の業務課題で行う自力課題で判定します。