data-validation

データ検証スキル

分析を関係者に共有する前の QA チェックリスト、データ分析でよくある落とし穴、結果の妥当性確認、再現性を高めるためのドキュメント作成基準です。

提出前の QA チェックリスト

分析を関係者に共有する前に、このチェックリストを確認してください。

データ品質チェック

• データソースの確認：使用したテーブル／データソースを確認しました。この質問に答えるうえで適切なものですか？
• 鮮度：分析に十分な最新のデータです。「基準日」を記録しました。
• 完全性：時系列に予期しない空白や欠落した区間はありません。
• NULL の処理：主要な列の NULL 率を確認しました。NULL は適切に処理されています（除外、補完、またはフラグ付け）。
• 重複の排除：不適切な結合やソースレコードの重複による二重計上がないことを確認しました。
• フィルターの確認：すべての WHERE 句とフィルターが正しいです。意図しない除外はありません。

計算チェック

• 集計ロジック：GROUP BY に集計対象でないすべての列が含まれています。集計レベルは分析の粒度と一致しています。
• 分母の正確性：率や割合の計算で適切な分母を使っています。分母はゼロではありません。
• 日付の整合性：比較対象の期間の長さは同じです。不完全な期間は除外するか、その旨を記載しています。
• 結合の正確性：適切な JOIN の種類（INNER と LEFT）を使用しています。多対多の結合によって件数が水増しされていません。
• 指標の定義：指標は関係者の定義と一致しています。相違点があれば記載しています。
• 小計の合計：想定される場合、各要素の合計は全体と一致します。一致しない場合は、理由（重複など）を説明しています。

妥当性チェック

• 規模：数値は妥当な範囲内です。売上がマイナスではありません。割合は 0〜100％の範囲内です。
• 傾向の連続性：時系列に説明のつかない急増や急減はありません。
• 相互参照：主要な数値は他の既知の情報源（ダッシュボード、過去のレポート、財務データ）と一致しています。
• 桁数：売上総額は妥当な範囲です。ユーザー数は既知の数値と一致しています。
• 境界ケース：境界ではどのようになりますか？空の区間、活動のない期間、新しいエンティティを確認しています。

表示チェック

• グラフの正確性：棒グラフの基準はゼロです。軸にはラベルが付いています。パネル間でスケールは統一されています。
• 数値の書式：適切な精度です。通貨と割合の書式は統一されています。必要に応じて桁区切りを使用しています。
• タイトルの明確さ：タイトルは指標だけでなく、そこから得られる知見を示しています。日付範囲を明記しています。
• 注意事項の明示：既知の制約と前提を明示しています。
• 再現性：提供されたドキュメントをもとに、別の人がこの分析を再現できます。

データ分析でよくある落とし穴

JOIN によるレコードの急増

問題：多対多の結合によって行が意図せず増え、件数や合計が水増しされます。

検出方法：

-- Check row count before and after join
SELECT COUNT(*) FROM table_a;  -- 1,000
SELECT COUNT(*) FROM table_a a JOIN table_b b ON a.id = b.a_id;  -- 3,500 (uh oh)

防止方法：

• 結合後は必ず行数を確認します
• 件数が増加した場合は、結合の関係を調べます（本当に 1 対 1 または 1 対多ですか？）
• 結合を通じてエンティティを数えるときは、COUNT(*) ではなく COUNT(DISTINCT a.id) を使用します

生存者バイアス

問題：現在存在するエンティティのみを分析し、削除、解約、または失敗したエンティティを無視します。

例：

• 「現在のユーザー」の行動を分析すると、解約したユーザーを見落とします
• 「自社製品を利用している企業」を調べると、評価後に利用をやめた企業を無視します
• 「成功した」結果のみの特性を調べ、「成功しなかった」結果を無視します

防止方法：結論を出す前に、「このデータセットに含まれていないのは誰か？」と問いかけます。

不完全な期間の比較

問題：一部のみの期間を、完全な期間と比較します。

例：

• 「1 月の売上は 50 万ドルで、12 月の 80 万ドルを下回っています」――ただし、1 月はまだ終わっていません
• 「今週の登録数は減少しています」――水曜日に確認し、前の週全体と比較しています

防止方法：必ず完全な期間でフィルターするか、月の同じ日まで、または同じ日数で比較します。

分母の変更

問題点：期間ごとに分母が変わるため、率を比較できなくなります。

例：

• 「対象」とみなすユーザーの数え方を変えたことで、コンバージョン率が改善する
• 「アクティブ」の定義を更新したことで、解約率が変化する

防止策：比較するすべての期間で、一貫した定義を使用します。定義を変更した場合は、その旨を記録します。

平均値の平均

問題点：グループの規模が異なる場合、あらかじめ計算された平均値を平均すると、誤った結果になります。

例：

• グループ A：ユーザー 100 人、平均収益 50 ドル
• グループ B：ユーザー 10 人、平均収益 200 ドル
• 誤り：平均値の平均 = （50 ドル + 200 ドル） / 2 = 125 ドル
• 正しい方法：加重平均 = （100 * 50 ドル + 10 * 200 ドル） / 110 = 63.64 ドル

防止策：必ず生データから集計します。事前に集計された平均値を平均してはいけません。

タイムゾーンの不一致

問題点：データソースごとにタイムゾーンが異なると、データのずれが生じます。

例：

• イベントのタイムスタンプは UTC で、ユーザー向けの日付は現地時間で記録されている
• 日次集計で異なる締め時刻が使われている

防止策：分析の前に、すべてのタイムスタンプを単一のタイムゾーン（UTC を推奨）に統一します。使用したタイムゾーンを記録します。

セグメンテーションにおける選択バイアス

問題点：測定対象の結果によってセグメントを定義すると、循環論法になります。

例：

• 「オンボーディングを完了したユーザーは継続率が高い」――当然ながら、彼らは自ら選択したユーザーです
• 「パワーユーザーはより多くの収益を生み出す」――収益を生み出したことで、パワーユーザーになったのです

防止策：結果ではなく、処置前の特性に基づいてセグメントを定義します。

結果の妥当性確認

規模のチェック

分析における主要な数値について、「違和感がないか」を確認します。

指標の種類	妥当性チェック
ユーザー数	既知の MAU／DAU の数値と一致していますか？
収益	既知の ARR と比較して、桁の規模は適切ですか？
コンバージョン率	0％から 100％の範囲内ですか？ ダッシュボードの数値と一致していますか？
成長率	前月比 50％以上の成長は現実的ですか？ それともデータに問題がありますか？
平均値	分布について把握している内容を踏まえて、妥当な平均値ですか？
パーセンテージ	セグメントごとのパーセンテージの合計は約 100％ですか？

クロスバリデーションの手法

1. 同じ指標を異なる 2 つの方法で計算し、一致することを確認します
2. 個々のレコードを抜き取り確認します――具体的なエンティティをいくつか選び、そのデータを手作業で追跡します
3. 既知のベンチマークと比較します――公開済みのダッシュボード、財務レポート、または過去の分析と照合します
4. 逆算します――総収益が X の場合、ユーザーあたりの収益にユーザー数を掛けた値は、おおよそ X になりますか？
5. 境界値を確認します――単一の日、単一のユーザー、または単一のカテゴリに絞り込むと、どうなりますか？ こうした小規模な結果は妥当ですか？

調査が必要な危険信号

• 明確な原因がないのに、期間ごとの比較で 50％を超えて変化した指標
• ちょうど切りのよい整数になっている件数や合計（フィルターまたは既定値の問題を示唆します）
• ちょうど 0％または 100％の率（データが不完全である可能性があります）
• 仮説を完璧に裏付ける結果（現実は通常、もっと複雑です）
• 期間やセグメントをまたいで同じ値が続く場合（クエリがディメンションを無視している可能性があります）

再現性のためのドキュメント作成基準

分析ドキュメントのテンプレート

重要度の高い分析には、すべて以下を含めます。

## Analysis: [Title]

### Question
[The specific question being answered]

### Data Sources
- Table: [schema.table_name] (as of [date])
- Table: [schema.other_table] (as of [date])
- File: [filename] (source: [where it came from])

### Definitions
- [Metric A]: [Exactly how it's calculated]
- [Segment X]: [Exactly how membership is determined]
- [Time period]: [Start date] to [end date], [timezone]

### Methodology
1. [Step 1 of the analysis approach]
2. [Step 2]
3. [Step 3]

### Assumptions and Limitations
- [Assumption 1 and why it's reasonable]
- [Limitation 1 and its potential impact on conclusions]

### Key Findings
1. [Finding 1 with supporting evidence]
2. [Finding 2 with supporting evidence]

### SQL Queries
[All queries used, with comments]

### Caveats
- [Things the reader should know before acting on this]

コードのドキュメント化

再利用する可能性のあるコード（SQL、Python）については、以下を記載します。

"""
Analysis: Monthly Cohort Retention
Author: [Name]
Date: [Date]
Data Source: events table, users table
Last Validated: [Date] -- results matched dashboard within 2%

Purpose:
    Calculate monthly user retention cohorts based on first activity date.

Assumptions:
    - "Active" means at least one event in the month
    - Excludes test/internal accounts (user_type != 'internal')
    - Uses UTC dates throughout

Output:
    Cohort retention matrix with cohort_month rows and months_since_signup columns.
    Values are retention rates (0-100%).
"""

分析のバージョン管理

• クエリとコードをバージョン管理（git）または共有ドキュメントシステムに保存します
• 使用したデータスナップショットの日付を記録します
• 更新されたデータで分析を再実行した場合は、何が変わったのか、またその理由を記録します
• 傾向を比較できるよう、定期的に実施する分析の以前のバージョンへのリンクを記載します