「Garbage In, Garbage Out」── 入力が汚いと出力も汚い。シンプルな格言ですが、前処理を軽視すると分析の信頼性は一気に崩れる。本シリーズは前処理を「単なる作業」ではなく 「データ品質を作り込む工程」 として扱い、欠損・名寄せ・重複排除・スケーリングなど 15 回の連載で体系化します。
なぜ「分析の8割は前処理」と言われるのか
- 生データは決して綺麗ではない：欠損・型不一致・重複・表記揺れが必ずある
- ビジネス指標は前処理で作られる：売上の集計、ユニークユーザー、 はすべて前処理の上に乗る
- 精度を決めるのも前処理：機械学習モデルでも、特徴量エンジニアリング（前処理の一種）が精度の8割を決める
- しかし時間が見積もれない：「データを見ないと工数が読めない」のが前処理の難しさ
前処理の主要カテゴリ
| カテゴリ | 代表処理 | 本シリーズでの回 |
|---|---|---|
| 欠損処理 | 削除・補完・フラグ化 | EP.02 |
| 異常値処理 | 外れ値の検出と扱い | EP.03 |
| 型変換 | 日付・数値・カテゴリの統一 | EP.04 |
| 文字列正規化 | 全角半角・大小文字・空白 | EP.05 |
| 名寄せ | 同一エンティティの統合 | EP.06〜EP.08（3回） |
| 重複排除 | Dedup 戦略 | EP.09 |
| 結合の前処理 | JOIN キー設計 | EP.10 |
| 特徴量変換 | エンコーディング・スケーリング | EP.11〜EP.12 |
| 時系列前処理 | リサンプリング・補間 | EP.13 |
| テキスト前処理 | トークナイズ・ストップワード | EP.14 |
| パイプライン化 | 再現性の確保 | EP.15 |
ふくふくの現場での経験則
- 生データを直接触らない：原本は別レイヤーに保管し、前処理結果を派生テーブルとして作る（ の bronze/silver/gold モデル）
- 前処理は / Polars / pandas で：手書き より変更履歴が追える
- 前処理結果のテストを書く：「行数が変わらない」「主キーが unique」「数値の範囲が想定内」を で確認
- 「綺麗にしたつもり」を疑う：表記揺れは想定外の角度から襲ってくる
次回予告
EP.02 では欠損値の扱い。「とりあえず平均値で補完」は本当に正しいか？ 削除・補完・フラグ化のトレードオフ、そして MCAR / MAR / MNAR（ランダム欠損 / 条件付き欠損 / 非ランダム欠損）の見極めを扱います。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。