「民主化のためにみんなにSQL を教えよう」と全社で 8 時間講座を組むのは、ほぼ確実に失敗します。業務での頻出パターンは限定的で、最小集合だけ教える方が定着率が上がる。本記事では、ふくふくが顧客企業で繰り返し使っているカリキュラム設計を共有します。
「教える」より「気づかせる」
民主化の目的は 「自分の業務に必要なデータに辿り着ける人」を増やすこと。SQL を書く人を増やすことではない。Slack Bot に質問できる、Looker のダッシュをいじれる、用語辞書を引ける の 3 つができるだけで、業務の 8 割は回ります。
層別カリキュラム
| 層 | 目標 | 学習時間目安 |
|---|---|---|
| Layer 1: 全員 | Slack Bot で質問できる / Looker を読める | 1 時間 e-learning |
| Layer 2: 部門の数値担当 | + Looker Explore で集計できる、用語を引ける | +2 時間ワークショップ |
| Layer 3: SQLライト層 | + SELECT / WHERE / GROUP BY / JOIN の基本を書ける | +1 日 |
| Layer 4: アナリスト | + Window 関数 / CTE / 統計 / | +1 週間〜 |
Layer 1（全員）の中身
- 1「データはどこにあるか」: グロッサリの引き方、Slack Bot で「これどこ？」と聞く
- 2「数字の意味」: 主要指標 5-10 個の定義（売上、、、 など、組織固有のもの）
- 3「データを見るときの落とし穴」: 期間 / 集計粒度 / 母集団 / NULL の扱いで結果が変わる例
- 4「やってはいけないこと」: 個人情報の Slack 投稿、自分の SQL 結果を Excel 配布、「とりあえず 公開」
- 5「困ったときの相談先」: / 用語辞書 / Slack Bot / アナリストへの依頼導線
Layer 3（SQLライト）の最小集合
| 概念 | 教える | 教えない |
|---|---|---|
| SELECT / WHERE | ✅ | — |
| GROUP BY / 基本集計関数 | ✅ | — |
| JOIN | ✅ INNER と LEFT のみ | FULL OUTER / CROSS / SEMI |
| DATE 関数 | ✅ DATE_TRUNC / DATE_SUB のみ | 全 DATE 関数 |
| NULL の扱い | ✅ COALESCE / IS NULL | — |
| LIKE | ✅ | 正規表現 |
| CASE WHEN | ✅ | — |
| DML (INSERT/UPDATE/DELETE) | ❌ | ❌（権限がないので学ぶ必要なし） |
| Window 関数 | ❌（Layer 4 で） | ❌ |
| CTE / サブクエリ | ❌（Layer 4 で） | ❌ |
「教えないこと」を明示する効果
「これは教えないので、必要なら Layer 4 のアナリストに依頼してください」と最初から明示することで、学習者の負担感が激減します。「全部理解しないといけない」と思うとモチベが下がるが、「ここまでで十分、その先は専門家」と区切る と心理的負担が減る。
教材は「自社データ × 自社業務」で作る
「Customer / Order テーブルで集計しよう」という Web 上の標準教材は 学習効率が低い。自社の実テーブルとよくある業務問いを題材にすると、学んだ瞬間に業務で使える。事前に練習問題セットを 20-30 個用意するのが効く。
ハンズオン形式の威力
1 時間の動画講座より、30 分のハンズオンセッション × 部署別の方が圧倒的に身につく。質問が出やすい、自社データで動かせる、その場でフィードバックできる。部署 5-8 名 × 30 分 × 4 回で十分業務に乗ります。
オンボーディングへの組込み
新入社員研修に Layer 1 を組み込むことで、入社時から「データ民主化の住人」として育つ。リテンション意識調査でも、データに触れている社員ほど エンゲージメントが高い傾向（業界一般）。
次の話
EP.12 では、データオーナー制度の作り方。「この数字の正しさは誰が保証するか」を明確にする組織設計。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。