統計検定 学習帳
Textbook

データサイエンティスト検定 教科書

データサイエンティスト検定(リテラシーレベル、通称 DS 検定)は、データサイエンティスト協会が主催する、**データサイエンティストに必要な実務知識を全方位** で問う試験です。「データサイエンス力」「データエンジニアリング力」「ビジネス力」の 3 軸を、リテラシーレベル(=実務に入れるレベル)で押さえます。本教科書では、それぞれの軸の概要と頻出ポイントを整理します。

目次

  1. 第 1 章 · データサイエンティストの 3 つのスキル
    DS 検定の出題範囲を支える「データサイエンス力 / データエンジニアリング力 / ビジネス力」の 3 軸を、それぞれ実務文脈とともに整理します。
  2. 第 2 章 · データエンジニアリング力とビジネス力
    SQL・データ加工・クラウド基礎(エンジニアリング力)、課題定義・KPI・ステークホルダー対応(ビジネス力)。
Chapter 1

第 1 章 · データサイエンティストの 3 つのスキル

§1.1

3 つのスキルとデータサイエンティストの役割

データサイエンティスト は単なる「分析する人」ではありません。データから事業価値を生み出すには、3 つの異なるスキルが必要です。本節では DS 協会が定義する 3 軸スキルセット を整理します。

3 つのスキルセット

用語 ─ DS 協会の 3 軸

データサイエンス力: 統計学・数学・機械学習など、データから情報を引き出す力。

データエンジニアリング力: SQL・データベース・ETL・クラウドなど、データを扱える形にする力。

ビジネス力: 課題設定・コミュニケーション・プロジェクト推進など、データを事業価値に変える力。

リテラシーレベルでは「実務に入って活躍できる最低限の基礎」が問われます。各軸で「この概念は知っている」「この用語の意味は説明できる」のレベルが目標。

なぜ 3 軸なのか

実務で価値を生むには、3 つすべてが揃っている必要があります。

  • データサイエンス力だけ → 「分析できるが、データが取れない」「ビジネスインパクトを説明できない」状態に
  • データエンジニアリング力だけ → 「データは流せるが、何を分析すべきか分からない」状態に
  • ビジネス力だけ → 「課題は分かるが、自分で分析できない・データを準備できない」状態に

現実には、1 人がすべての軸で「達人」である必要はありません。チームとして 3 軸を補完し合うのが標準。ただし「最低限のリテラシー」 として 3 軸の用語と概念を押さえているのが、DS 検定リテラシーレベルが目指す姿です。

DS 協会が公開する「スキルチェックリスト」

DS 協会は「データサイエンティストのスキル定義」を毎年公開しており、約 600 項目のチェックリストとして整理されています。リテラシーレベルでは、その中の ★1(初学者向け) の項目が出題範囲。実務で言うと、各軸で「用語と基本概念を説明できる」レベル。

§1.2

データサイエンス力の基礎

DS 検定の「データサイエンス力」は 統計学 と 機械学習 の両方を含みます。本節では、それぞれの基礎をリテラシーレベルで整理します。

統計学の基礎(DS 検定の出題範囲)

  • 代表値: 平均・中央値・最頻値の使い分け
  • ばらつき: 分散・標準偏差・四分位範囲
  • 確率分布: 正規分布・二項分布・ポアソン分布の概形
  • 仮説検定: 帰無仮説・対立仮説・p 値・有意水準・第 1 種/第 2 種の誤り
  • 推定: 信頼区間の意味と読み方
  • 回帰分析: 単回帰・重回帰の概念、決定係数
  • 相関と因果: 「相関 ≠ 因果」の原則

これらは本サイトの[統計検定 2 級教科書](/textbook/grade-2)とほぼ同じ内容。「式の導出」までは要らないが、「式の意味と使い場面」は説明できるレベルが必要。

機械学習の基礎(DS 検定の出題範囲)

  • 教師あり / 教師なし / 強化学習 の違い
  • 回帰タスク vs 分類タスク の違い
  • 主要アルゴリズム: 線形回帰・ロジスティック回帰・決定木・ランダムフォレスト・SVM・k-means
  • 評価指標: 回帰なら MAE・RMSE、分類なら正解率・適合率・再現率・F 値・AUC
  • 過学習(overfitting) とその対処: 正則化・交差検証
  • 特徴量エンジニアリング: ワンホットエンコーディング・標準化など
00.510.51偽陽性率 FPR真陽性率 TPR強い分類器(AUC≈0.92)普通(AUC≈0.75)ランダム(AUC=0.5)
図: ROC 曲線。曲線下面積(AUC)が大きいほど良い分類器。0.5 はランダム
単純複雑モデル複雑度誤差最適点バイアス²バリアンス合計誤差
図: バイアスとバリアンスのトレードオフ。最適な複雑度で総合誤差が最小になる
なぜ過学習は起きるのか

モデルを複雑にすればするほど訓練データには合いますが、訓練データに含まれる偶然のノイズまで覚えてしまいます。例えるなら『過去問だけ丸暗記して、本番の応用問題で崩れる学生』。バイアス・バリアンス図の右側で『総合誤差』が再上昇しているのが、この現象の正体です。正則化や交差検証は、この最適点に近づくための実用ツールです。

0中多学習量(エポック / 複雑度)誤差早期終了の理想点過学習の領域 →訓練誤差検証誤差
図: 訓練誤差と検証誤差の典型的な学習曲線。検証誤差が再上昇する手前で止めるのが「早期終了」
実務での使い方:早期終了とハイパーパラメータ調整

Keras / PyTorch などの DL ライブラリには、検証誤差が改善しなくなったら自動で学習を止める「Early Stopping」コールバックが標準で備わっています。実務では「学習エポックを多めに設定して Early Stopping に任せる」のが定石。同じ図はモデル複雑度を横軸にしても成り立つので、決定木の深さ・SVM のカーネル幅などのハイパーパラメータ調整にも応用されます。

Python で交差検証 + ROC AUC を計算する
from sklearn.linear_model import LogisticRegression
from sklearn.model_selection import cross_val_score
from sklearn.metrics import roc_auc_score, roc_curve

model = LogisticRegression(max_iter=1000)

# 5-fold 交差検証で平均精度
scores = cross_val_score(model, X, y, cv=5, scoring="roc_auc")
print(f"AUC = {scores.mean():.3f} ± {scores.std():.3f}")

# ROC 曲線を描画
model.fit(X_train, y_train)
proba = model.predict_proba(X_test)[:, 1]
fpr, tpr, _ = roc_curve(y_test, proba)
print(f"AUC(test) = {roc_auc_score(y_test, proba):.3f}")

scikit-learn は分類モデルの評価関数が一通り揃っており、実務でデファクト。

ビジュアライゼーション

「データを見せる力」も DS 検定では問われます。グラフ選択の基本ルール:

  • 棒グラフ: カテゴリの大きさ比較
  • 折れ線グラフ: 時間変化
  • 散布図: 2 変数の関係
  • ヒストグラム: 1 変数の分布形
  • 箱ひげ図: 群間のばらつき比較
  • ヒートマップ: 2 次元のクロス集計

DS 検定対策のおすすめルート

「データサイエンス力」セクションの基礎は、本サイトの 統計検定 3 級・2 級 の内容と大きく重なります。

  • [3 級教科書](/textbook/grade-3) で 代表値・確率分布・基礎を固める
  • [2 級教科書](/textbook/grade-2) で 推定・検定・回帰までカバー
  • 本検定固有の機械学習アルゴリズムは G 検定や別教材で補強
Chapter 2

第 2 章 · データエンジニアリング力とビジネス力

§2.1

データエンジニアリング力の基礎

データエンジニアリング力(DE 力) とは、データを「分析できる形」に整える力。元データはバラバラの場所にある・形式が違う・量が膨大 ─ これらを使える状態にする工程は、データサイエンスの 見えにくいが時間の 8 割を占める部分 とも言われます。

SQL の基本

SQL は RDB(リレーショナルデータベース)からデータを取り出す共通言語。SELECT / FROM / WHERE / GROUP BY / JOIN の 5 構文だけで、実務の 8 割は対応できます。

基本構文 ─ 取り出し

```sql SELECT 列名1, 列名2, ... FROM テーブル名 WHERE 条件 ORDER BY 列名 DESC|ASC ```

例: 「`users` から年齢 20 以上の人を年齢順に」

```sql SELECT * FROM users WHERE age >= 20 ORDER BY age DESC; ```

基本構文 ─ 集計

```sql SELECT 列, COUNT(*), AVG(数値列), SUM(数値列) FROM テーブル GROUP BY 列 ```

例: 「`orders` テーブルで顧客ごとの注文数と平均注文額」

```sql SELECT customer_id, COUNT(*) AS n_orders, AVG(amount) AS avg_amount FROM orders GROUP BY customer_id; ```

基本構文 ─ 結合(JOIN)

```sql SELECT u.name, o.amount FROM users u INNER JOIN orders o ON u.id = o.user_id ```

INNER JOIN: 両方のテーブルに存在する行のみ LEFT JOIN: 左のテーブル全行 + 右のマッチする行(マッチしない場合は NULL) RIGHT / FULL JOIN: 同様の発想

データ基盤の構成要素

用語 ─ データ基盤の主な構成

データソース: 元データのある場所(業務システム・ログ・外部API)

ETL (Extract / Transform / Load): 元データを抽出 → 変換 → 保管先に投入する工程

データウェアハウス(DWH): 分析用に整理された構造化データの集約。BigQuery、Snowflake、Redshift など

データレイク: 構造化・非構造化問わず生データを大量保存。S3、Azure Data Lake など

BI ツール: ダッシュボード化・可視化。Tableau、Power BI、Looker、Metabase など

DWH vs データレイク ─ 違いの整理

比較

| | DWH | データレイク | |---|---|---| | データ形式 | 構造化(SQL で扱える) | 構造化・非構造化(画像・音声・JSON など) | | スキーマ | 事前定義(Schema-on-Write) | 後で定義(Schema-on-Read) | | 典型用途 | BI レポート・ダッシュボード | 機械学習・データサイエンス | | 代表サービス | BigQuery、Snowflake | S3、Azure Data Lake |

実務では 両者を併用 することが多い。生データは安価なデータレイクに保管しつつ、よく使う集計結果は DWH に整理する、というハイブリッド構成。

クラウド主要 3 社

  • AWS(Amazon): S3 / Redshift / EC2 / SageMaker
  • GCP(Google): Cloud Storage / BigQuery / Vertex AI
  • Azure(Microsoft): Blob Storage / Synapse / ML Studio

DS 検定では「どのクラウドサービスがどの役割か」(例: BigQuery は DWH、S3 はオブジェクトストレージ)を 大まかに理解 していることが問われます。

データ品質の観点

  • 完全性: 必要なデータが欠損なく揃っているか
  • 正確性: 値が正しいか(誤入力・重複なし)
  • 一貫性: 表記揺れがないか(「東京都」「東京」が混在しないか)
  • 時系列の整合性: 過去のデータと連続性があるか
  • 鮮度: いつのデータか、最新か

「Garbage In, Garbage Out(GIGO)」 ─ データの質が悪ければ、どんなに優れた分析手法を使っても得られる結論は信頼できません。データ品質はデータエンジニアリング力の核心です。

§2.2

ビジネス力の基礎

「統計や ML を知っているだけでは、データ職として活躍できない」 ─ DS 検定が ビジネス力 を独立した軸として置く理由がここにあります。本節では、課題設定からプロジェクト推進、コミュニケーションまでの基本を整理します。

課題設定 ─ 「何のための分析か」を明確に

データ分析プロジェクトの 最も重要な工程は最初の課題設定。ここを誤ると、どんなに精緻な分析をしても価値が生まれません。

  1. ビジネス課題を明確化: 「売上を上げたい」のような漠然とした要望を、「離脱率を下げたい」のような具体的な問いに変換
  2. 意思決定との連結: 「分析結果が出たら、誰がどう動くか」を最初に確認
  3. KPI(Key Performance Indicator)定義: 成果を測る数値指標を 1〜3 個に絞る
  4. スコープと制約: いつまでに / どんなデータが使えるか / どこまでの精度を目指すか

KPI 設計のコツ

良い KPI の条件 ─ SMART 原則

S(Specific): 具体的 M(Measurable): 測定可能 A(Achievable): 達成可能 R(Relevant): ビジネスに関連 T(Time-bound): 期限が明確

例: × 「サイトを良くする」 → ○ 「3 か月以内に主要 LP の直帰率を 50% から 40% に下げる」

CRISP-DM ─ データ分析プロジェクトの定番モデル

プロセス ─ CRISP-DM の 6 ステップ

1. ビジネス理解: 課題と目的を整理

2. データ理解: 利用可能なデータを把握、品質確認

3. データ準備: 前処理、特徴量エンジニアリング(プロジェクト時間の 60-80% を占める)

4. モデリング: 機械学習モデル等の構築

5. 評価: ビジネス目的に対する成果を確認

6. 展開: 本番環境への投入、運用・モニタリング

CRISP-DM は順番通りに進むとは限らず、前のステップに戻ることが頻繁にある反復プロセス。「モデリングしてみたら、データ理解の段階に戻る必要があった」 ─ これは失敗ではなく正常な進行です。

ステークホルダーとのコミュニケーション

  • 用語を聞き手に合わせる: 経営層には「離脱率」「ROI」、エンジニアには「特徴量」「F1 スコア」
  • 結論ファースト: 結果 → 根拠 → 詳細の順。プレゼン時間が短くても要点が伝わる
  • 不確実性を素直に伝える: 「精度 80%、ただし 〇〇 の制約あり」
  • Next Action を提示: 「だから何をすべきか」を含める。ただの分析報告で終わらせない
  • 可視化で理解を促進: 数字だけでなく、グラフで直感的に

データ倫理とコンプライアンス

  • 個人情報保護法: 個人情報の取り扱いに関する日本の基本法。匿名化・仮名化の概念
  • GDPR(EU): 欧州市民のデータを扱う場合に適用。違反は売上の最大 4% の罰金
  • 社内ガバナンス: データ利用ポリシー・アクセス権限の管理
  • バイアスへの注意: 学習データの偏りが意思決定に与える影響を意識

実務でよくある失敗パターン

  • 「分析のための分析」: ビジネス価値につながらない技術自慢
  • 過剰な精度追求: 99% 精度を目指すより、80% でも実用に投入したほうが価値が出ることが多い
  • ステークホルダー巻き込み不足: 自分だけで進めて、最終報告で「これが欲しかったわけじゃない」となる
  • 運用設計の軽視: モデルを作って終わり、本番で性能劣化に気づかない(モニタリング不足)

DS 検定の「ビジネス力」セクションは、正解が 1 つではない問題が多い のが特徴。原則を理解しておけば、「最も適切な対応」 を選ぶ問題で迷わなくなります。