hzy24/validate-data

/validate-data - 分析を共有する前に検証する

不明なプレースホルダーがある場合、または接続されているツールを確認する必要がある場合は、CONNECTORS.md を参照してください。

分析をステークホルダーと共有する前に、正確性、手法、および潜在的なバイアスについてレビューします。信頼度評価と改善提案を生成します。

使用方法

/validate-data <レビューする分析>

分析には以下が含まれます:

• 会話内のドキュメントまたはレポート
• ファイル (markdown、ノートブック、スプレッドシート)
• SQLクエリとその結果
• チャートとその基になるデータ
• 手法と発見の説明

ワークフロー

1. 手法と前提条件のレビュー

以下を検証します:

• 質問の枠組み: 分析は正しい質問に答えていますか？ 質問は別の方法で解釈される可能性がありますか？
• データの選択: 正しいテーブル/データセットが使用されていますか？ 時間範囲は適切ですか？
• 母集団の定義: 分析対象の母集団は正しく定義されていますか？ 意図しない除外がありますか？
• メトリクスの定義: メトリクスは明確かつ一貫して定義されていますか？ ステークホルダーの理解と一致していますか？
• ベースラインと比較: 比較は公平ですか？ 期間、コホートサイズ、コンテキストは比較可能ですか？

2. 納品前QAチェックリストの実行

以下のチェックリスト（データ品質、計算、妥当性、プレゼンテーションのチェック）を実行します。

3. 一般的な分析の落とし穴のチェック

以下の詳細な落とし穴カタログ（結合爆発、生存バイアス、不完全な期間比較、分母の変動、平均の平均、タイムゾーンの不一致、選択バイアス）に対して系統的にレビューします。

4. 計算と集計の検証

可能な場合は、スポットチェックを実行します:

• いくつかの主要な数値を独立して再計算する
• 小計が合計と一致することを確認する
• パーセンテージが予想通り合計100%になること（またはそれに近いこと）を確認する
• 前年同月比/前月比の比較が正しい基準期間を使用していることを確認する
• フィルターがすべてのメトリクスにわたって一貫して適用されていることを確認する

以下の結果の妥当性チェック手法（桁数チェック、相互検証、レッドフラグ検出）を適用します。

5. 可視化の評価

分析にチャートが含まれている場合:

• 軸は適切な値から始まっていますか（棒グラフではゼロ）？
• 比較チャート間でスケールは一貫していますか？
• チャートのタイトルは、表示されている内容を正確に説明していますか？
• 可視化は素早い読者を誤解させる可能性がありますか？
• 切り詰められた軸、不整合な間隔、または知覚を歪める3D効果はありますか？

6. ナラティブと結論の評価

以下をレビューします:

• 結論は表示されたデータによって裏付けられているか
• 代替説明が認識されているか
• 不確実性が適切に伝えられているか
• 推奨事項は発見から論理的に導き出されているか
• 信頼のレベルは証拠の強さと一致しているか

7. 改善点の提案

具体的で実行可能な提案を提供します:

• 結論を強化する追加分析
• 注意すべき注意点や制限事項
• 重要なポイントのためのより良い可視化やフレーミング
• ステークホルダーが求める欠落しているコンテキスト

8. 信頼度評価の生成

分析を3段階で評価します:

共有準備完了 -- 分析は方法論的に健全で、計算は検証され、注意点が記載されています。改善のためのマイナーな提案はありますが、妨げになるものはありません。

注意事項付きで共有 -- 分析は概ね正しいですが、ステークホルダーに伝えなければならない特定の制限や前提があります。必要な注意事項を列挙します。

修正が必要 -- 共有する前に対処すべき具体的なエラー、方法論の問題、または欠落した分析が見つかりました。優先順位を付けて必要な変更を列挙します。

出力形式

## 検証レポート

### 全体的な評価: [共有準備完了 | 注意事項付きで共有 | 修正が必要]

### 手法レビュー
[アプローチ、データ選択、定義に関する所見]

### 見つかった問題
1. [重大度: 高/中/低] [問題の説明と影響]
2. ...

### 計算スポットチェック
- [メトリクス]: [検証済み / 不一致を発見]
- ...

### 可視化レビュー
[チャートや視覚的表現に関する問題]

### 改善提案
1. [改善点とその重要性]
2. ...

### ステークホルダーへの必要注意事項
- [伝えなければならない注意事項]
- ...

---

納品前QAチェックリスト

分析をステークホルダーと共有する前に、このチェックリストを実行してください。

データ品質チェック

• ソースの検証: 使用されたテーブル/データソースを確認しました。この質問に対して正しいものでしたか？
• 鮮度: データは分析に十分最新のものです。「時点」の日付を記載しました。
• 完全性: 時系列に予期しないギャップや欠落セグメントはありません。
• Null処理: キー列のNull率を確認しました。Nullは適切に処理されています（除外、補完、またはフラグ付け）。
• 重複排除: 不適切な結合または重複ソースレコードによる二重カウントがないことを確認しました。
• フィルター検証: すべてのWHERE句とフィルターが正しいです。意図しない除外はありません。

計算チェック

• 集計ロジック: GROUP BYにはすべての非集計列が含まれています。集計レベルは分析の粒度と一致しています。
• 分母の正しさ: 率とパーセンテージの計算は正しい分母を使用しています。分母はゼロではありません。
• 日付の調整: 比較は同じ期間長を使用しています。部分的な期間は除外または注記されています。
• 結合の正しさ: JOINタイプは適切です（INNER vs LEFT）。多対多の結合によってカウントが増加していません。
• メトリクスの定義: メトリクスはステークホルダーの定義と一致しています。逸脱は注記されています。
• 小計の合計: 予想される場合、部分は全体に合計されます。合計しない場合は、その理由を説明してください（例：重複）。

妥当性チェック

• 桁数: 数値は妥当な範囲内です。収益がマイナスになることはありません。パーセンテージは0〜100%の範囲内です。
• トレンドの連続性: 時系列に説明のつかないジャンプや低下はありません。
• 相互参照: 主要な数値は他の既知のソース（ダッシュボード、以前のレポート、財務データ）と一致しています。
• 規模感: 総収益は妥当な範囲内です。ユーザー数は既知の数値と一致しています。
• エッジケース: 境界では何が起こりますか？ 空のセグメント、アクティビティゼロの期間、新しいエンティティ。

プレゼンテーションチェック

• チャートの正確性: 棒グラフはゼロから始まっています。軸はラベル付けされています。スケールはパネル間で一貫しています。
• 数値の書式設定: 適切な精度。一貫した通貨/パーセンテージの書式設定。必要に応じて千単位の区切り記号。
• タイトルの明確さ: タイトルはメトリクスだけでなく洞察を述べています。日付範囲が指定されています。
• 注意事項の透明性: 既知の制限と前提が明示的に述べられています。
• 再現可能性: 提供されたドキュメントから、他の誰かがこの分析を再現できます。

一般的なデータ分析の落とし穴

結合爆発

問題: 多対多の結合が静的に行数を乗算し、カウントと合計を膨らませます。

検出方法:

-- 結合の前後の行数を確認
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 (あらま)

防止方法:

• 結合後は常に行数を確認する
• カウントが増加した場合は、結合関係を調査する（本当に1:1または1:多ですか？）
• 結合を介してエンティティをカウントする場合は、COUNT(*) の代わりに COUNT(DISTINCT a.id) を使用する

生存バイアス

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

例:

• 「現在のユーザー」のユーザー行動を分析すると、解約したユーザーを見逃す
• 「当社製品を使用している企業」を見ると、評価して去った企業を無視する
• 「成功した」結果の特性を「失敗した」結果なしで調査する

防止方法: 結論を引き出す前に、「このデータセットに含まれていないのは誰ですか？」と自問してください。

不完全な期間比較

問題: 部分的な期間を完全な期間と比較します。

例:

• 「1月の収益は50万ドルで、12月の80万ドルに対して」-- しかし1月はまだ終わっていない
• 「今週のサインアップは減少している」-- 水曜日に確認し、完全な前週と比較している

防止方法: 常に完全な期間にフィルターするか、同じ月の日/同じ日数で比較してください。

分母の変動

問題: 期間間で分母が変化し、率が比較できなくなります。

例:

• 「適格」ユーザーのカウント方法を変更したため、コンバージョン率が改善する
• 「アクティブ」の定義が更新されたため、解約率が変化する

防止方法: 比較するすべての期間にわたって一貫した定義を使用してください。定義の変更を注記してください。

平均の平均

問題: グループサイズが異なる場合に、事前に計算された平均を平均すると間違った結果になります。

例:

• グループA: 100ユーザー、平均収益50ドル
• グループB: 10ユーザー、平均収益200ドル
• 間違い: 平均の平均 = (50ドル + 200ドル) / 2 = 125ドル
• 正解: 加重平均 = (10050ドル + 10200ドル) / 110 = 63.64ドル

防止方法: 常に生データから集計してください。事前に集計された平均を平均しないでください。

タイムゾーンの不一致

問題: 異なるデータソースが異なるタイムゾーンを使用し、不整合を引き起こします。

例:

• UTCのイベントタイムスタンプと、ローカル時間のユーザー向け日付
• 異なるカットオフ時間を使用する日次ロールアップ

防止方法: 分析前にすべてのタイムスタンプを単一のタイムゾーン（UTC推奨）に標準化してください。使用されたタイムゾーンを文書化してください。

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

問題: セグメントが測定対象の結果によって定義され、循環論理を生み出します。

例:

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

防止方法: セグメントを処理前の特性に基づいて定義し、結果に基づいて定義しないでください。

その他の統計的トラップ

• シンプソンのパラドックス: データを集計するとトレンドが逆転する vs. セグメント化する
• 因果関係として提示される相関関係: 裏付けとなる証拠がない
• 信頼性の低い結論につながる小さなサンプルサイズ
• 平均に不均衡に影響を与える外れ値: 代わりに中央値を使用すべきか？
• 多重検定 / チェリーピッキング: 有意な結果を選ぶ
• 先見バイアス: 過去の出来事を説明するために将来の情報を使用する
• 特定のナラティブに有利なように選ばれた時間範囲

結果の妥当性チェック

桁数チェック

分析内の主要な数値について、「匂いテスト」に合格することを確認します:

メトリクスの種類	妥当性チェック
ユーザー数	既知のMAU/DAU数値と一致しますか？
収益	既知のARRと比較して正しい規模感ですか？
コンバージョン率	0%から100%の間ですか？ ダッシュボードの数値と一致しますか？
成長率	50%以上の前月比成長は現実的ですか、それともデータの問題ですか？
平均	分布について知っていることから、平均は妥当ですか？
パーセンテージ	セグメントのパーセンテージは合計で約100%になりますか？

相互検証テクニック

1. 同じメトリクスを2つの異なる方法で計算し、それらが一致することを確認する
2. 個々のレコードをスポットチェックする -- いくつかの特定のエンティティを選び、それらのデータを手動でトレースする
3. 既知のベンチマークと比較する -- 公開されたダッシュボード、財務レポート、または以前の分析と照合する
4. 逆算する -- 総収益がXの場合、ユーザーあたりの収益にユーザー数を掛けると約Xになりますか？
5. 境界チェック -- 単一日、単一ユーザー、単一カテゴリにフィルターするとどうなりますか？ それらのミクロ結果は妥当ですか？

調査を正当化するレッドフラグ

• 明らかな原因なしに、前期比で50%以上変化したメトリクス
• 正確な整数であるカウントまたは合計（フィルターまたはデフォルト値の問題を示唆）
• 正確に0%または100%の率（不完全なデータを示す可能性あり）
• 仮説を完全に確認する結果（現実は通常もっと複雑）
• 期間またはセグメント間で同一の値（クエリが次元を無視していることを示唆）

再現可能性のためのドキュメント標準

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

重要な分析にはすべて以下を含める必要があります:

## 分析: [タイトル]

### 質問
[回答される具体的な質問]

### データソース
- テーブル: [スキーマ.テーブル名]（[日付]時点）
- テーブル: [スキーマ.その他のテーブル]（[日付]時点）
- ファイル: [ファイル名]（ソース: [出典]）

### 定義
- [メトリクスA]: [正確な計算方法]
- [セグメントX]: [メンバーシップの決定方法]
- [期間]: [開始日] から [終了日]、[タイムゾーン]

### 方法論
1. [分析アプローチのステップ1]
2. [ステップ2]
3. [ステップ3]

### 前提と制限
- [前提1 とそれが妥当である理由]
- [制限1 と結論への潜在的な影響]

### 主要な発見
1. [裏付け証拠と共に発見1]
2. [裏付け証拠と共に発見2]

### SQLクエリ
[使用されたすべてのクエリとコメント]

### 注意事項
- [読者がこれに基づいて行動する前に知っておくべきこと]

コードドキュメント

再利用される可能性のあるコード（SQL、Python）の場合:

"""
分析: 月次コホート保持率
作成者: [名前]
日付: [日付]
データソース: eventsテーブル、usersテーブル
最終検証日: [日付] -- 結果はダッシュボードと2%以内で一致

目的:
    初回アクティビティ日に基づいて月次ユーザー保持率コホートを計算します。

前提:
    - 「アクティブ」とは、その月に少なくとも1つのイベントがあることを意味します
    - テスト/内部アカウントを除外します（user_type != 'internal'）
    - 全体を通してUTC日付を使用します

出力:
    コホート月を行、サインアップからの経過月数を列とするコホート保持率マトリックス。
    値は保持率（0-100%）です。
"""

分析のバージョン管理

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

例

/validate-data この四半期の収益分析を役員チームに送る前にレビューしてください: [分析]

/validate-data このコホート分析のSQLクエリと結果を確認し、計算が正しいことを確認してください: [SQLと結果]