信頼できるデータがないと起きること

Stage 1 — 第1章 | データマネジメント入門 推定学習時間：30〜40分 | 難易度：★★☆☆☆

この章で学ぶこと

SQL で集計が書けると、最初は「必要な数字は自分で出せる」という感覚があります。 ところが実務に入ると、数字そのものより先に 「その数字を信じていいか」「会議で説明できるか」 で止まることが増えます。

この章では、データマネジメント（Data Management、データを信頼できる資産として扱う仕組み）が必要になる 典型症状 を、架空 EC 会社「さくら商事」の例で見ていきます。

この章を終えると、こんなことができるようになります：

• 「売上が合わない」など、現場でよく起きる症状を具体例付きで説明できる
• その症状が SQL の書き方ではなく、定義・品質・責任の問題である場面を見分けられる
• データマネジメントが「ツールの話」ではなく「意思決定を守る話」だと説明できる
• 次の章以降で学ぶ用語（SSOT、品質、ガバナンス）の 必要性 を自分ごととして理解できる

1. さくら商事という会社

このカリキュラムでは、全 Stage を通して同じ架空会社 さくら商事 を例にします。

さくら商事には、優秀なアナリストもいます。 SQL も書ける人がいて、ダッシュボードも複数あります。 それでも経営会議の冒頭 10 分が、いつも同じ問題で埋まっています。

よくある会議の始まり方

経営の木村さん:「今月の売上、いくらでしたっけ？」

マーケの田中さん:「Looker では 1 億 2,000 万円です。」

経理の佐藤さん:「うちの集計では 1 億 1,500 万円です。差は何ですか？」

データ基盤の鈴木さん:「SQL では 1 億 1,800 万円でした。定義、どれ使いますか？」

…10 分経っても、まだ「どの数字が正しいか」の確認から始まっています。

この状態は、分析力不足というより 信頼できるデータの設計不足 です。

2. 現場で起きること

SQL が書ける人が増えても、次のような症状は残りやすいです。

次の図は、さくら商事の経営会議前によく起きる状態です。 参照元がバラバラだと、どれだけ SQL が書けても会議は前に進みません。

見ているのは計算ミスではなく、正本の不在 です。 マーケ、経理、基盤チームはそれぞれ「自分の数字」は合っているつもりでも、組織としては説明責任を果たせていません。

3. 「売上 1 億 2,000 万円」の中身をほどく

さくら商事で「6 月の売上」を調べると、次のような差が出ました。

3 つとも「間違い」ではありません。 定義が違う のです。

現場メモ

マーケの田中さんは「広告効果を見たいので CV ベースで見ている」と説明できます。 経理の佐藤さんは「会計上の売上高なので返品を反映する」と説明できます。 基盤の鈴木さんは「注文 DB の完了ステータス合計」と説明できます。

問題は、会議で「売上」と一語で呼んでいる ことです。

ここで必要なのは、もう一つ SQL を書くことだけではありません。

1. 何の売上か を言葉で定義する
2. どこを正本にするか を決める
3. 誰がその定義の責任者か を決める

これがデータマネジメントの出発点です。

4. SQL が書けても足りない理由

data-analytics-fundamentals では、売上や CVR を SQL で計算する方法を学びます。 たとえば完了注文の売上は、次のように書けます。

SELECT
            SUM(total_amount) AS sales
          FROM orders
          WHERE status = 'completed';
          

この SQL 自体は有用です。 しかしさくら商事では、次の論点が SQL の外にあります。

つまり、SQL は「定義が決まったあと」に強力になる道具 です。 定義と責任が決まっていないと、正しい SQL を複数本書いても、組織としては信頼できる数字になりません。

現場メモ

新人アナリストの山田さんは、先輩から渡された SQL をそのまま使い、Looker に載せました。 先輩の SQL は「返品未反映」だったため、経理数字との差が毎月出続けました。 山田さんのスキル不足ではなく、定義と正本が共有されていなかった のが原因です。

5. データマネジメントとは何か

ここでのデータマネジメントは、次のような活動全体を指します。

データを組織の資産として、その 生成・保存・加工・活用・廃棄 までのライフサイクル全体にわたり、正確性・一貫性・安全性・可用性 を担保しながら計画・実行・監督すること。

ポイントは次の 3 つです。

1. データを集めること自体が目的ではない
   • 意思決定、業務改善、説明責任を支えるための「信頼できる燃料」を整えることが目的です。
2. ツールを入れれば終わりではない
   • DWH や BI ツールがあっても、定義・品質・権限がなければ症状は残ります。
3. 一人の SQL 力だけでは組織問題は解けない
   • 誰が定義を決め、誰が品質を見て、誰が利用を許可するかが必要です。

さくら商事の例に戻ると、必要なのは次のような状態です。

このカリキュラムでは、これらを 現場の困りごと → 判断 → 次の一手 の順で学びます。

6. この章で扱わないこと

入門の初章なので、次の内容は 後の章または別トラック に回します。

初章の役割は、「なぜ学ぶのか」を 自分ごと にすることです。

体系コラム：カリキュラム上の位置づけ

コラム：よくある誤解 —「SQL が書ければデータ問題は解決する」

さくら商事の基盤チームでは、優秀な SQL エンジニアが複数います。それでも経営会議の冒頭は数字の定義確認から始まります。よくある誤解は、「もっと速いクエリ」「もっと綺麗なダッシュボード」を入れれば揃う、という発想です。

新人の山田さんも最初は、先輩の SQL をそのまま使えば数字は合うはずだと考えていました。実際には、返品反映の有無・税込税抜・期間の切り方が SQL の外側でバラバラに決まっていたため、正しいつもりの集計が 3 本乱立しました。計算そのものより 何を数えるか が先です。

もう一つの誤解は、「データマネジメント＝DWH や BI ツール導入」と捉えることです。さくら商事は BigQuery と Looker を既に持っていますが、ツールが増えるほど参照元が増え、会議は長くなりました。ツールは 定義と責任が決まったあと に威力を発揮するインフラです。

木村さんが最初に変えたのは、追加の SQL ではなく「公式売上を誰が決めるか」という問いかけでした。データマネジメント入門は、この視点転換から始まります。

まとめ

この章のキーメッセージ：

SQL が書けることと、組織が信頼できる数字を使えることは別問題です。 さくら商事のように数字は出せても会議が進まないとき、必要なのは追加の集計より 定義・正本・責任・品質 です。 それを整えるのがデータマネジメントです。

次に読む

• 次章（同一トラック）: 誰が何を担うか — 責任の空白地帯を整理する
• 関連（Analytics Engineering）: 指標定義: 売上、CVR、継続率をそろえる — SQL で書く前の定義の考え方
• 関連（スキルチェック）: 15 問で現在地を確認する — データマネジメント軸の自己評価

確認問題

問題 1

さくら商事の経営会議で、マーケ・経理・基盤チームの「6 月売上」が一致しませんでした。 このとき 最初に確認すべきこと として最も適切なのはどれですか。

A. 3 チームの SQL 実行速度とインデックス設定
B. 「売上」に含める対象・期間・税/返品の扱いなどの定義
C. Looker Studio のグラフ色と凡例の見やすさ
D. 経理 Excel のマクロが最新版かどうか

正解: B

解説: 数字が食い違う典型原因は、計算ミス以前に 定義の不一致 です。性能や見た目、Excel マクロは二次的な確認です。データマネジメントでは、まず「何を数えているか」を言葉で揃えます。

問題 2

新人アナリストが先輩の SQL をそのままダッシュボードに載せ、経理数字との差が毎月出続けた。 この事例で 最も本質的な問題 はどれですか。

A. 新人の SQL スキル不足
B. 先輩の SQL が古い
C. 指標定義と正本が組織として共有されていない
D. ダッシュボードツールの機能不足

正解: C

解説: SQL そのものが動いていても、返品反映などの 定義と正本（SSOT） が共有されていなければ、正しいつもりの数字が複数存在します。これは個人スキルより組織設計の問題です。

問題 3

「データマネジメント」と聞いて、さくら商事の文脈で 最も近い説明 はどれですか。

A. BigQuery や Looker などのツールを導入すること
B. 分析用 SQL をできるだけ多く書くこと
C. データを信頼できる資産として、定義・品質・権限・責任まで含めて整えること
D. 統計検定に合格すること

正解: C

解説: データマネジメントはツール導入や個人の SQL 量ではなく、ライフサイクル全体を信頼できる状態にする 活動です。資格学習は別の学習目標です。

用語メモ（この章）