「管理画面の売上数字と、情シスからもらったCSVの集計結果が全然合わない……」
月末の会議前、Excelと睨めっこしながら冷や汗を流した経験、ないだろうか。
私は何度もある。
営業企画やマーケティングの仕事をしていると、どうしても避けて通れないのがデータ抽出。でも、情シスに依頼すると「要件が曖昧」「どのテーブルをつなぐの？」と煙たがられ、自分でどうにかしようと分厚いSQLの入門書を買ってみたものの……。
通勤電車の中で開いた瞬間に「SELECT * FROM...」という暗号の羅列に絶望し、静かに本を閉じた。あれは数年前の冬だったか。
「エンジニアになりたいわけじゃない。ただ、今の仕事で正しい数字を出して、まともに企画を進めたいだけなのに」
そんな本音を抱えながら、毎日往復3時間の電車に揺られていた。
もしあなたも同じように、CRMやBIツールの数字は見るけれど「データの保存方法や抽出条件はサッパリ説明できない」と悩んでいるなら、少しだけ安心してほしい。
非エンジニアがデータベースを学ぶとき、絶対にやってはいけないことがある。それは「いきなりSQLの構文を暗記すること」だ。
断言する。
私たちが最初にやるべきは、コードを書くことではない。業務上の顧客、商品、注文といったデータが「何を一件として、どのテーブルに保存され、どのIDでつながっているか」を把握すること。
この構造さえ見えれば、SQLを学ぶ意味も、数字が合わない原因も、痛いほどわかるようになる。
正論や綺麗事は抜きにして、非エンジニアが会社で賢く生き残り、データと仲良くなるための「超・泥臭いデータベースの歩き方」を伝えていく。
【結論】データベースは「何を一件として保存するか」から理解する
「とりあえず必要なデータを全部一つのExcelにまとめてよ」
過去の私は、息を吐くようにこんな指示を出していた。そして見事に自爆した。
なぜなら、データベースの根本的なルールを全く理解していなかったからだ。
最初にデータの単位を考える
データを扱うとき、最も重要なのは「その行は、一体何を表しているのか？」という単位（粒度）の概念。
例えば、ECサイトのデータを思い浮かべてほしい。
- 鈴木さんが
- 10月1日に
- Aという化粧品と、Bというサプリを一緒に買った
これを無理やり1行の表にすると、商品が2つあるせいで、鈴木さんの名前や注文日が重複するか、無理やり横に列を増やすことになる。Excelなら「気合いで何とかする」で済むかもしれない。でも、データが100万件になったら？ あっという間に破綻する。
だからこそ「顧客を1件とするまとまり」「注文を1件とするまとまり」「商品を1件とするまとまり」というように、データの単位を明確に分ける必要があるのだ。
異なる種類の情報を一つの表へ詰め込まない
当時の私は「データは一覧になっている方が見やすい」と信じて疑わなかった。
でも、顧客の情報（名前、住所、登録日）と、注文の情報（いつ、いくら買ったか）を一緒の表に詰め込むと、とんでもない悲劇が起きる。鈴木さんが引っ越しをして住所が変わったとき、過去の注文履歴100件すべての住所を書き換えないといけなくなるからだ。
「更新漏れで、一部だけ古い住所のままの行が残っている……！」
こんなExcelあるあるの悲劇、心当たりはないだろうか。データベースは、この地獄を回避するために「異なる種類の情報は、別々の表（テーブル）に分けて保存する」という鉄則がある。
データはIDを使って関連づける
「分けて保存したら、後で集計するときに困らないの？」
初めてこれを聞いたとき、私は本気でそう思った。でも、そこで登場するのがID（識別子）だ。
顧客テーブルには「顧客ID」、注文テーブルには「注文ID」と「誰が買ったかを示す顧客ID」、商品テーブルには「商品ID」。
名前や商品名ではなく、絶対に重複しない、変わることのない「ID」をキーにして、分断されたパズルのピースを繋ぎ合わせる。
これが、データベースを理解するための最重要ポイントと言っても過言ではない。
SQLの前にテーブル構造を理解する
ここまで来れば、なぜ「いきなりSQLを学んではいけないか」がわかるはず。
SQLは魔法の呪文ではなく、「分かれて保存されているデータを、どのIDで繋いで、どう持ってくるか」をデータベースにお願いするためのお手紙に過ぎない。
手紙を出す相手（どのテーブルに何が入っているか）も、宛先（どのIDで繋がるか）も分かっていないのに、手紙の書き方（SQLの構文）だけ暗記しても意味がないのだ。
「SELECT」や「JOIN」を覚える前に、まずは自社のデータがどんな箱に分かれていて、どの線で繋がっているのか。その地図（構造）を頭に入れること。これが非エンジニアにとっての最強のショートカットになる。
データベースとは何か
そもそも、データベースって何なのか。
「データを保存しておくデカい箱みたいなものでしょ？」
数年前、情シスの担当者にこう言い放った私は、冷ややかな目で見られた。「ハルさん、それただのファイルサーバーです」と。
データを整理・保存・検索・更新する仕組み
データベースは、単なるデータの置き場ではない。
膨大なデータを「決められたルール」に従って整理し、安全に保存し、必要な時に一瞬で検索し、矛盾なく更新するための「システム全体」のことを指す。
Excelファイルがただの「ノート」だとしたら、データベースは優秀な司書が常駐している「超巨大な国立図書館」のようなもの。
ノートは誰かが書き込んでいると他の人は使えないし、どこに何が書いてあるか探すのも一苦労。でも図書館なら、目録（インデックス）を使って目当ての本をすぐに見つけ出し、複数人が同時に利用しても混乱が起きない。
ファイルを置くだけの仕組みではない
当時の私が勘違いしていたのは、「CSVファイルを共有フォルダに置いておくのもデータベースの一種」という思い込み。
確かにデータは集まっている。しかし、誰かが間違えて上書き保存したら？ パソコンがフリーズしてファイルが壊れたら？ 共有フォルダのファイルは、何の守りも持たない丸裸の状態だ。
本物のデータベースは、途中でエラーが起きてもデータを元に戻したり、一部の人しか見られないように権限を管理したりする機能が備わっている。ただの保管庫ではなく、データを守り抜く強固な要塞なのだ。
身近なサービスはデータベースを利用している
小難しく聞こえるかもしれないが、私たちは毎日、無意識にデータベースを使っている。
例えば、通勤電車で開く会員アプリ。あなたのポイント残高や購入履歴が瞬時に表示されるのは、裏側にデータベースがあるからだ。
ECサイトでの買い物も、スーパーのPOSレジも、会社の勤怠管理システムも、すべてデータベースが動いている。あなたがCRMツールで「昨日3万円以上買った20代女性」をポチッと検索した瞬間にも、裏側ではデータベースがものすごい勢いで整理された棚から条件に合うデータを引っ張り出してきている。
データベース管理システムの役割
少しだけ専門用語を出すと、この「要塞の管理人」にあたるのが「DBMS（データベース管理システム）」だ。Oracle、MySQL、PostgreSQLなど、耳にしたことがあるかもしれない。
彼らは、私たちが書いたSQL（お手紙）を受け取り、「はいはい、鈴木さんの最新の注文履歴ですね。少々お待ちを」とデータをかき集めてきてくれる優秀な執事。
非エンジニアの私たちが、彼らの裏側の仕組みをエンジニアレベルで理解する必要はない。ただ、「彼らがどんなルールで整理整頓しているか」を知っておくだけで、データ抽出の依頼も、日々の集計作業も、劇的にスムーズになるという事実だけ覚えておいてほしい。
Excelとデータベースは何が違う？
Excelとデータベースは、どちらかが優れているという話ではない。そもそも目的と用途が根本的に異なるツールだ。
Excelは個人的な試算や小規模な表計算に向いており、データベースは大量データの安全な保存や複数人での同時利用に向いている。
Excelは表計算と個人・小規模な分析に向いている
「全部Excelで管理すれば十分じゃない？」
ぶっちゃけ、私も昔は本気でそう思っていた。手軽だし、関数を使えば一瞬で集計できるし、グラフも綺麗に作れる。
営業企画に異動したばかりの頃、私は会社中のデータをCSVでダウンロードしては、手元でVLOOKUP関数を使いまくって「最強の顧客管理ファイル」を作ろうとしていた。
数万行程度のデータで、自分1人が集計や分析をするだけなら、Excelは間違いなく世界最強のツールだ。
デザインも自由に変えられるし、直感的にセルを操作できる。これほど扱いやすい道具は他にない。
非エンジニア向けIT基礎として最初に触れるツールがExcelなのも当然だし、それ自体は何も間違っていない。
データベースは大量データや複数利用者に向いている
だが、その「手軽さ」が裏目に出る瞬間が必ずやってくる。
数万件を超えて数十万、数百万件のデータになったとき、Excelは悲鳴を上げ始める。
一方、データベースは最初から「大量のデータを、複数人で、安全に使う」ことだけを考えて作られたシステムだ。
100万件の顧客データの中から「先月購入した20代女性」を一瞬で探し出せるし、全国の店舗から同時にアクセスしてデータを書き込んでも壊れない。
データを計算して見せるのがExcelなら、大量のデータを矛盾なく保管・整理するのがデータベースの役割。得意分野がまったく違うのだ。
Excelが劣っているわけではない
勘違いしてほしくないのは、「データベースの方が高級で、Excelは遅れている」という訳ではないこと。
データベースから取り出したデータを、最後に手元でグラフ化したり、一時的な試算をしたりするときはExcelが一番使いやすい。
要はバトンの引き継ぎだ。
大量データの蓄積と整理はデータベースに任せ、そこから必要な分だけを抽出して、手元での細かい分析や資料作成はExcelで行う。
この役割分担（非エンジニア向けデータ・AI資格ロードマップでも重要とされる視点）が頭に入っていれば、無駄にExcelをフリーズさせて溜息をつくこともなくなる。
Excel管理が限界になる兆候
私が過去にやらかした失敗談を共有しておこう。
当時、共有フォルダーに置いた顧客データ_最新_v3_修正2.xlsxという巨大ファイル。
マーケ部の同僚が「ハルさん、ファイルが開かないんだけど」と焦って声をかけてきた。開こうとすると画面が真っ白になり、「応答なし」の文字。無理やり開けば、誰かが誤ってフィルターをかけたまま上書き保存していて、数字がめちゃくちゃ……。
以下のような状態が発生したら、それは「Excel管理の限界」であり、データベースが必要なサインだ。
| 比較項目 | Excel管理 | データベース管理 |
|---|---|---|
| 得意な用途 | 表計算・グラフ化・個人での一時的な分析 | 大量データの保存・複数人での同時検索・自動連携 |
| データ量の限界 | 数万〜数十万件で動作が極端に重くなる | 数百万〜数億件でも高速に検索・集計が可能 |
| 複数人での利用 | 「読み取り専用」になる／上書き事故が発生 | 何百人が同時にアクセスしても安全に同時更新 |
| データの信頼性 | セルを直接書き換えられるためミスが起きやすい | 決められたルールに従って厳格にデータを保持 |
「ファイルを開くのに3分かかる」「上書き事故が怖い」と感じたら、それはあなたが悪いのではない。ツールの用途がズレているだけなのだ。
テーブル・行・列を理解する
データベースは「テーブル（表）」「行（1件のデータ）」「列（属性）」という極めてシンプルな構造で成り立っている。
まずはこの3つの要素と、データの入れ物である「データ型」「NULL」の概念を正しく理解することが、誤集計を防ぐ第一歩だ。
テーブルは同じ種類のデータを保存する表
データベースの中には、何種類もの「表」が存在する。この表のことを専門用語で「テーブル」と呼ぶ。
昔の私は、このテーブル・行・列とはの概念が分かっておらず、1つの表に顧客の名前も、注文した商品も、配送先の住所も全部詰め込もうとして情シスに怒られた。
データベースでは「同じ種類のデータ」ごとにテーブルを分けるのが鉄則。
- 顧客の情報だけを集めた「顧客テーブル」
- 商品の情報だけを集めた「商品テーブル」
- 日々の注文履歴を集めた「注文テーブル」
このように、役割ごとに整理された引き出し（テーブル）がデータベースの中にいくつも並んでいるイメージを持ってみてほしい。
一行は一件の対象を表す
テーブルの中にある「横の一行」は、その対象の「1件のデータ」を表している。
ここがめちゃくちゃ重要だ。集計で数字が合わなくなる原因の多くは、この「1行が何を表しているか（粒度）」を勘違いしていることから始まる。
- 顧客テーブルの1行 ＝ 特定の顧客「1人」
- 注文テーブルの1行 ＝ 発生した「1回の注文」
- 注文明細テーブルの1行 ＝ 注文の中に含まれる「1つの商品」
「このテーブルの1行は、一体何を1件として数えているのか？」
これを常に意識するだけで、データを見る時の解像度は格段に上がる。
列は対象が持つ属性を表す
「縦の一列」は、その対象が持っている「属性（項目）」を表す。
例えば「顧客テーブル」なら、以下のような列が並ぶことになる。
- 顧客ID（識別するための番号）
- 氏名（顧客の名前）
- メールアドレス
- 登録日
1行（1人の顧客）に対して、それぞれの列（氏名やアドレス）に値が入っていく。Excelの表と同じ見た目なので、ここは直感的に理解しやすいはずだ。
データ型によって入れられる値が決まる
Excelとデータベースの大きな違いの一つが、この「データ型」の存在だ。
Excelなら、数値が入っている列に突然「未定」という文字を入力しても怒られない。しかし、データベースはそれを絶対に許さない。列ごとに「ここにはどんなデータを入れるか」というルール（型）が厳格に決まっているからだ。
- 数値型（INTEGERなど）：100、500などの数値（計算ができる）
- 文字列型（VARCHARなど）：田中太郎、東京都などの文字
- 日付・時刻型（DATE、DATETIMEなど）：2026-08-06などの日付
もし「売上金額」の列に「10000円」と「円」まで文字列で入れてしまうと、データベースは計算ができなくなってしまう。
だからこそ「売上金額」の列は数値型にし、「10000」という数値だけを入れる。この厳しいルールがあるからこそ、何百万件あっても正確に計算ができるのだ。
NULLはゼロや空文字と同じではない
非エンジニアがSQLや集計で最もハマりやすい罠、それが「NULL（ヌル）」だ。
結論から言おう。NULLは「数字の0」でもなければ「空文字（スペース）」でもない。「データが存在しない（未知・未入力）」という状態そのものを意味している。
例えば、会員登録時のアンケートで「生年月日」が任意項目だったとする。
入力しなかった人のデータは、0歳になるわけでもなく、空白という文字が入るわけでもない。何が入っているか分からない「NULL」という状態になる。
集計のとき、これを理解していないと大事故になる。
平均値 = 合計 / 件数 を計算するとき、値が「0」の人は件数としてカウントされるが、「NULL」の人はカウント対象から除外されることが多い。
「集計結果が画面の数字と10件だけズレる……」という場合、このNULLの扱いを勘違いしているケースが本当に多いのだ。データがない状態を意味する特殊なマーク、それがNULLだと覚えておこう。
主キーと外部キーは何のためにある？
「田中太郎さんからクレームが入っています！」
カスタマーサポートからの連絡を受け、慌てて顧客データベースで「田中太郎」を検索したときの絶望感。画面には、住所や電話番号が微妙に違う「田中太郎」が3人も並んでいた。
一体、どの田中さんが怒っているのか……。
データベースを扱う上で、この「誰が誰だか分からない問題」は致命傷になる。これを防ぎ、データを正確に結びつけるための絶対的なルールが「主キー」と「外部キー」だ。
主キーは一件のデータを識別する
主キー（Primary Key）とは、テーブルの中にある1行（1件のデータ）を「絶対にこれだ」と特定するための唯一無二の目印のこと。
学校の出席番号や、社員証の社員番号をイメージしてほしい。
- 顧客テーブルなら「顧客ID」
- 商品テーブルなら「商品ID」
- 注文テーブルなら「注文ID」
1つのテーブルの中で、主キーは「絶対に重複してはいけない（一意性）」し、「空っぽ（NULL）であってもいけない」という厳しい掟がある。この主キーがあるおかげで、100万人の中から特定の1人を一瞬で、かつ正確に探し出すことができるのだ。
氏名や商品名を主キーにしにくい理由
昔の私は「わざわざ連番のIDなんて作らなくても、名前かメールアドレスをキーにすればいいのでは？」と情シスに食い下がったことがある。
答えは即答でNGだった。
氏名は同姓同名が存在する。結婚して苗字が変わることもある。
商品名も「【期間限定】」などの文字が後から追加されたり、全角と半角がブレたりする。
メールアドレスでさえ、顧客が変更する可能性があるし、家族で使い回しているケースもある。
値が変わったり、重複したりするものを主キーにしてしまうと、過去のデータとの繋がりがすべて切れてしまう。だからこそ、意味を持たないただの連番やランダムな文字列（システムが自動で発行するID）を主キーにするのが鉄則なのだ。
外部キーは別のテーブルと関連づける
主キーが「自分自身を証明する名札」だとしたら、外部キー（Foreign Key）は「別のテーブルにいる誰かを指差すための矢印」だ。
例えば「注文テーブル」。ここには「いつ、いくら売れたか」が記録されているが、「誰が買ったか」は記録されていない。代わりに「顧客ID：1050」という列がひっそりと置かれている。
この「顧客ID：1050」が外部キーだ。
「この注文をしたのは、顧客テーブルにいる『IDが1050』の人ですよ」と、別のテーブルへ案内してくれる役割を持つ。
主キーと外部キーの違いを理解できれば、バラバラに保存されたデータたちが、どうやって手を繋いでいるのかがはっきりと見えてくる。
IDが一致しないとデータを統合できない
ここで、マーケティング担当者が血の涙を流す「ID問題」の現実を話そう。
実店舗のレジ（POS）と、自社のECサイト。それぞれ別のシステムで構築されていることはよくある。
店舗では「ポイントカード番号」で顧客を管理し、ECサイトでは「メールアドレス」で管理している。
この状態だと、店舗とECの両方で毎月5万円ずつ買ってくれている超優良顧客がいたとしても、データ上は「店舗のAさん」と「ECのBさん」という別人に分断されてしまう。IDが共通化されていないと、どんなに高度な分析ツール（BI）を入れてもデータを繋ぐことは不可能なのだ。
ID統合にはルールと品質管理が必要
顧客IDと会員IDの違いを埋め、複数システムのデータを繋ぎ合わせる（名寄せ・ID統合）のは、魔法のようにボタン一つでは終わらない。
「名前と電話番号が一致したら同一人物とみなすか？」
「家族で同じ固定電話を使っていたらどうする？」
こうした業務上のルールを泥臭く決め、データの入力ミス（全角半角の揺れなど）を整える地道な品質管理が絶対に必要になる。データベースの力だけでは解決できない、人間の業務フローの問題なのだ。
なぜ複数のテーブルに分けるのか
主キーと外部キーでデータを繋ぐ仕組みは分かった。でも、そもそも最初から1つの巨大なテーブルに全部まとめておけば、こんな面倒な「キー」なんて意識しなくていいのでは？
……本音を言えば、私も最初はそう思っていた。
なぜデータベースは、わざわざデータをバラバラのテーブルに分けて保存するのか。それは「データの重複による矛盾」を徹底的に排除するためだ。
顧客と注文は一対多の関係になる
1人の顧客は、生涯で何度も注文をしてくれる。
つまり、顧客テーブルの「1件」に対して、注文テーブルには「複数件」のデータがぶら下がることになる。これをデータベースの世界では一対多・多対多とはの関係（一対多）と呼ぶ。
もしこれを1つのテーブルにまとめてしまうと、注文が発生するたびに、顧客の「名前」「住所」「電話番号」を何度も繰り返し記録しなければならない。
注文と商品は多対多になる
さらに複雑なのが「注文」と「商品」の関係だ。
- 1回の注文の中に、複数の商品が含まれる（シャンプーとリンスを一緒に買うなど）
- 1つの商品は、複数の注文に含まれる（シャンプーはいろんな人に買われる）
これを「多対多」の関係と呼ぶ。
このままではデータベース上で綺麗に繋ぐことができないため、間に「注文明細テーブル」というクッションを挟む。
「注文ID：001」の明細として「商品Aが1個」「商品Bが2個」というように、1行を「1回の注文の中の、1つの商品」という単位（粒度）に分解するのだ。
重複を減らして更新ミスを防ぐ
なぜここまで細かく分けるのか。
答えはシンプル。「変更があったとき、1箇所だけ直せば済むようにするため」だ。
例えば、商品Aの価格が値上がりしたとする。
もし1つの巨大なテーブルに過去の全履歴を詰め込んでいたら、商品Aが売れた過去1万件の行をすべて探し出し、価格を書き換えないといけなくなる（しかも過去の売上金額まで狂ってしまう）。
でも「商品テーブル」として独立していれば、商品テーブルの価格を1箇所だけ「ピッ」と更新するだけで済む。他の注文データには一切影響を与えない。この「矛盾なく安全に更新できる仕組み」こそが、データベース最大の強みなのだ。
正規化はデータを適切な単位へ分ける考え方
このように、データの重複をなくし、矛盾が起きないようにテーブルを綺麗に切り分けていく作業や考え方のことを正規化とは（せいきか）と呼ぶ。
ITの資格試験などでは「第1正規形」「第3正規形」といった難しい専門用語で暗記させられるが、非エンジニアの私たちがそれを丸暗記する必要はない。
大事なのは、「なぜこのデータは別のテーブルに追い出されているのか？」という背景（理由）を想像できるようになること。それさえできれば、情シスが作ったテーブル設計の意図が手に取るように分かるようになる。
分けすぎると扱いにくくなる場合もある
ただし、ここで実務ならではのリアルな話をひとつ。
「正規化」は完璧な理論だが、実務のデータベースがすべて極限まで細かく分割されているとは限らない。
テーブルを細かく分けすぎると、今度は「データを取り出すときに、たくさんのテーブルを結合（JOIN）しまくらなければならず、検索に時間がかかってしまう」という弱点が出てくるのだ。
だから、データ分析用のデータベース（データウェアハウスなど）では、検索スピードを優先して、あえてルールを破り「最初からある程度まとめておく（非正規化）」という設計をとることもある。
「正しいテーブル設計」は一つではない。システムが何を目的にしているかによって、形を変えているという現実を知っておこう。
マスターデータとトランザクションデータの違い
テーブルを分ける理由は分かっても、実際の業務データを見渡すと「一体どのテーブルから手をつければいいのか」と途方に暮れることがある。
かつての私は、顧客テーブルも注文履歴もWebのアクセスログも、すべて同じ粒度で横並びに考えていた。だから集計のたびに混乱し、「どこから手をつければ正しい数字が出るんだ」とパニックになっていたのだ。
データベースの世界には、大きく分けて「2種類の性質を持つデータ」がある。
これを区別できるようになると、データ構造の見通しが一気に良くなる。それが「マスターデータ」と「トランザクションデータ」だ。
マスターデータは業務の基準になる
マスターデータとは、企業活動の「基準」や「台帳」となるデータのこと。
例えば、顧客（誰が）、商品（何を）、社員（誰が担当で）、店舗（どこで）といった情報がこれに当たる。
マスターデータの特徴は、「頻繁には増えないし、めったに変わらない」こと。
新商品が発売されたり、顧客が引っ越したりした時は更新されるが、毎秒のようにポコポコと新しいデータが生まれ続けるわけではない。業務の土台となる、比較的どっしりとした安定感のあるデータだ。
トランザクションデータは日々発生する事実を記録する
対してトランザクションデータとは、日々の業務の中で「発生した事実（出来事）」を記録し続けるデータのこと。
- いつ、誰が、何を買ったか（注文履歴）
- いつ、誰がサイトを訪れたか（アクセスログ）
- いつ、誰にメルマガを送ったか（配信履歴）
こちらはマスターデータとは正反対。業務が動いている間、毎秒、毎分ものすごい勢いでデータが増え続ける。そして、「一度記録された過去の事実は、後から書き換わるべきではない」という性質を持っている。
「顧客マスター」に登録されている田中さんが、「商品マスター」にある化粧品を買った事実が、「注文トランザクション」として日々蓄積されていく。この構造をイメージしてほしい。
マスターが乱れると集計も乱れる
ここで、現場の人間を泣かせるあるある話を一つ。
「売上ランキングを出したら、1位と3位に同じ名前の商品が別々に集計されているんですが……」
こんな悲劇の99%は、マスターデータが乱れていることに原因がある。
商品マスターに「商品A」と「【夏限定】商品A」が別のIDで登録されてしまっていると、トランザクション（注文履歴）側では当然「別の商品が売れた」として記録されてしまう。
マスターデータという「基準」が揺らぐと、そこに紐づくトランザクションの集計もすべて連鎖的に狂う。だからこそ、現場の運用担当者は「マスターデータに重複や入力ミスがないか」に血眼になるのだ。
どのシステムのデータを正とするか決める
マーケティングや営業企画の現場でよく起きるのが「CRMシステムの商品名と、販売管理システムの商品名が微妙に違う」という問題。
こういう時、「気合いでExcelで突き合わせる」のは最悪の悪手だ。
会社として「商品名や商品IDは、どのシステムに登録されているものを『正（シングル・ソース・オブ・トゥルース）』とするか」を決めなければならない。
マスターデータの一元管理（MDMなどと呼ばれる）はエンジニアだけの仕事ではない。業務フローを理解している現場の非エンジニアこそが、「うちの正しい商品マスターはここにあるべきだ」と声を上げる必要があるのだ。
SQLはデータベースへ指示を出す言語
さて、データがどんな単位で、どう分けて保存されているか。その構造（地図）が頭に入ったら、いよいよデータベースから必要なデータを取り出すための「お手紙」の書き方について触れていこう。
それが「SQL（エスキューエル）」だ。
SQLはプログラミング言語と役割が異なる
私が最初に挫折した最大の理由は、「SQL＝難しいプログラミング言語」だと思い込んでいたことだ。
PythonやJavaScriptのように、画面を動かしたり複雑な計算アプリを作ったりするものだと勘違いしていた。
でも、SQLとはただの「指示書」であり「依頼書」だ。
「このテーブルから、こういう条件に合う行だけを、こんな順番で持ってきてくださいね」
データベースの執事（DBMS）に、そうやってお遣いを頼むためだけの、極めて限定的でシンプルな言語。複雑なシステムを作るための言語ではないからこそ、文系・非エンジニアでも少し練習すれば読めるようになる。
SELECTは必要なデータを取り出す
SQLで最もよく使い、そして私たちが最初に覚えるべきなのが「SELECT（セレクト）」だ。
これは「〜を持ってきて」という、取得を指示する合言葉。
例えば、顧客テーブルから「名前」と「メールアドレス」だけが欲しい場合。
SELECT文の基礎としては、こんな風に書く。
SELECT 氏名, メールアドレス FROM 顧客テーブル;
たったこれだけ。英語の「Select（選ぶ） from（〜から）」そのままの直感的な構造だ。プログラミングのような複雑な構文は一切ない。
WHEREは対象を絞り込む
全員分のデータはいらない、「30代の人だけ」欲しい。
そんな風に対象を絞り込みたい時に使うのが「WHERE（ウェア）」だ。
WHERE句の使い方を覚えると、Excelでちまちまフィルターをかける作業から解放される。
SELECT 氏名, メールアドレス FROM 顧客テーブル WHERE 年齢 >= 30;
「どこから（FROM）」「どんな条件で（WHERE）」「何を持ってくる（SELECT）」
たったこれだけの組み合わせで、何百万件のデータからでも一瞬でターゲットを絞り込めるようになる。
GROUP BYは同じ種類のデータをまとめる
「商品ごとの売上合計が知りたい」「店舗ごとの来店客数を出したい」
Excelのピボットテーブルでよくやるこの「集計」を、SQL上でやってしまうのが「GROUP BY（グループバイ）」だ。
GROUP BYの仕組みは、文字通り「同じ種類のものをグループにまとめる」機能。
店舗ごとにまとめるなら GROUP BY 店舗名。これで、10万件のバラバラの注文データが、「東京店：500件」「大阪店：300件」というようにキュッと集約されて手元に返ってくる。情シスから重たい全件データをもらって自分のPCをフリーズさせる前に、データベース側で集計を終わらせてしまう強力な技だ。
ORDER BYは並び順を指定する
取得したデータを「売上の高い順に並べてほしい」「登録日の新しい順に見たい」という時に使うのが「ORDER BY（オーダーバイ）」。
ORDER BY 売上金額 DESC（降順：大きい順）
これを最後につけ足すだけ。
ここまでの「SELECT」「WHERE」「GROUP BY」「ORDER BY」の4つが読めるようになるだけで、他人が書いたSQL文が「ただの英語の依頼書」に見えてくるはずだ。
INSERT・UPDATE・DELETEはデータを変更する
最後に、非エンジニアが「知っておくべきだが、軽々しく実行してはいけない」恐ろしい呪文を3つ紹介しておく。
- INSERT（追加）：新しい行を登録する
- UPDATE（更新）：既存のデータを書き換える
- DELETE（削除）：データを消し去る
SELECTは単にデータを「見る」だけなので、間違えても誰も傷つかない。
しかし、この3つはデータベースの中身そのものを変えてしまう。私が過去、テスト環境でWHERE（条件）をつけ忘れてUPDATEを実行し、全員の住所を「東京都」に書き換えてしまった時の血の気も引くような恐怖は、今でも忘れられない……。
データを変更する処理は、検索よりもはるかに慎重な権限管理と条件確認、そしてバックアップが必要になる。「読み取り専用」でデータを引き出すのと、「中身を書き換える」のは次元が違う責任が伴うということを、肝に銘じておこう。
JOINは複数テーブルの情報を組み合わせる
「データの重複を防ぐために、テーブルを分ける理由は分かった。でも、いざ分析しようとした時に、顧客の名前と買った商品が別々のテーブルにあるんじゃ、何も集計できないじゃないか！」
初めて正規化の概念を知ったとき、私はPCの画面に向かってこう毒づいた。
安心してほしい。データベースはただデータをバラバラに分解するだけではない。必要なときに、分断されたパズルのピースを完璧な形でくっつけ直す強力な接着剤を用意してくれている。
それが「JOIN（ジョイン・結合）」だ。
テーブルを分けたため、必要なときに組み合わせる
バラバラに保存されている「顧客テーブル」と「注文テーブル」。
この2つを、共通のID（顧客ID）をキーにして、横にガッチャンコと繋ぎ合わせるのがJOINの役割だ。
ExcelのVLOOKUP関数をイメージすると分かりやすいかもしれない。VLOOKUPは「このIDをキーにして、あっちの表から名前を持ってきて」と指示するものだが、JOINはそれをデータベースの内部で、しかも数百万件という規模で一瞬にしてやってのける。
JOINの種類と使い方にはいくつかパターンがあるが、非エンジニアが実務で使うのは主に2つだけだ。
INNER JOINは両方に存在するデータを取り出す
一つ目が「INNER JOIN（内部結合）」。
これは、2つのテーブルを突き合わせて「両方にデータが存在するものだけ」を取り出す方法。
例えば、全員が登録されている「顧客テーブル」と、実際に商品を買った履歴である「注文テーブル」をINNER JOINで繋ぐとどうなるか。
結果として出てくるのは「（過去に一度でも）注文したことがある顧客」だけのリストだ。まだ何も買っていない無料会員のデータは、条件に一致しないためバッサリと切り捨てられる。
「購入者だけの分析をしたい」という時は、迷わずこれを使う。
LEFT JOINは左側を残して関連データを付ける
二つ目が「LEFT JOIN（左外部結合）」。マーケターや営業企画が最もお世話になるのがこちらだ。
これは「基準となるテーブル（左側）のデータはすべて残したまま、もう一方のテーブル（右側）に一致するデータがあればくっつける」という方法。
「顧客テーブル」を左、「注文テーブル」を右にしてLEFT JOINすると、「全員のリスト」を維持したまま、注文履歴がある人にはその金額がくっつき、一度も買っていない人の注文履歴の欄には「NULL（空っぽ）」が入る。
「まだ一度も購入していない休眠顧客をあぶり出して、DMを送りたい」
そんな時は、LEFT JOINをして「注文金額がNULLの人」をWHEREで絞り込めば、一瞬でターゲットリストが完成するのだ。
結合条件を誤ると件数が増える
ここで、過去の私がやらかした最も恐ろしい失敗を告白しよう。
「注文明細テーブル」と「商品テーブル」をJOINしようとした時のこと。本来なら「商品IDが一致するもの同士を繋いで」と条件を書くべきなのに、私はその結合条件を書き忘れてSQLを実行してしまった。
どうなったか。
データベースは「どの行とどの行を繋げばいいか分からないから、とりあえずすべての組み合わせを作っておこう」と解釈してしまう（これをクロスジョインと呼ぶ）。
1万件の注文明細と、1,000件の商品マスターが掛け合わされ、一瞬にして1,000万件の無意味なデータが生成された。会社の分析サーバーは重くなり、情シスの担当者からチャットが飛んできた。あれは本当に寿命が縮む思いだった。
件数と粒度を結合前後で確認する
JOINを使うとき、非エンジニアが絶対に守るべき鉄則がある。
それは「JOINする前の件数」と「JOINした後の件数」を必ず確認することだ。
- 1人の顧客が3回注文している場合、顧客テーブル（1行）に対して注文テーブル（3行）をJOINすると、結果は「3行」に増える。
- これが「1回の注文」という粒度で正しいなら問題ない。
- しかし、もし結合条件を間違えていて、意図せず件数が爆発しているなら、それは集計結果（売上合計など）も何倍にも膨れ上がる大事故を意味する。
「JOINの前後で、1行が表す意味（粒度）はどう変わったか？ 件数はおかしくないか？」
これを確認する癖をつけるだけで、データ抽出のミスは劇的に減らすことができる。
同じ数字がシステムごとに違う理由
「社長、今月のWeb経由の売上は1,000万円で着地しました」
「あれ？ 経理から上がってきた数字は850万だけど。君の出している数字、どこから持ってきたの？」
会議室が静まり返るあの瞬間。
マーケティング部門が見ているBIツール（ダッシュボード）の数字と、営業部門が見ているCRMの数字、そして基幹システム（経理）の数字が合わない。会社員を長くやっていれば、誰もが一度はぶち当たる「数字のミステリー」だ。
なぜ同じ会社のデータなのに、システムによって数字が変わってしまうのか。
数字の定義が違う
最も多い原因は、「売上」という言葉の定義が部署によって違うことだ。
- マーケティング部：ユーザーがECサイトで「購入ボタンを押した日（受注日）」
- 物流・営業部：倉庫から商品が「発送された日（出荷日）」
- 経理部：お客様の手元に届き、お金の回収が確定した日（検収・計上日）
月末の30日に購入ボタンが押され、発送が翌月2日になった場合。マーケ部では「今月の売上」としてカウントされるが、経理部では「来月の売上」になる。これだけでもBIの数字が合わない原因としては十分すぎる理由だ。
集計するタイミングが違う
「管理画面で見ると売上は100万円なのに、情シスからもらったデータだと95万円になっている」
こういう場合、データを抽出した「タイミング」がズレていることが多い。
日々動いているトランザクションデータは、キャンセルや返品処理によって後から数字が変動する。朝9時に出したデータと、夕方17時に出したデータでは、その間に発生したキャンセル分だけ数字が変わっていて当然なのだ。
除外条件が違う
- 社内のテスト注文（テストアカウント）は除外しているか？
- 返品やキャンセルのデータはマイナス処理しているか？
- 送料や手数料は売上に含めているか？
システム側でこれらの「除外条件」がどう設定されているかによって、最終的な数字は大きくブレる。ダッシュボードを作った人がどこまで条件を指定（WHERE句で除外）しているか、裏側のロジックを確認しない限り、数字のズレは永遠に解消しない。
更新時間が違う
これも非エンジニアが陥りやすい罠だ。
会社で導入しているBIツール（TableauやLookerなど）の数字は、必ずしも「今この瞬間のリアルタイムなデータ」ではないことが多い。
「本番のデータベースに負荷をかけないよう、夜中（夜間バッチ）に1日1回だけ、分析用のデータベースにデータをコピーする」という仕組みをとっている会社は非常に多い。
つまり、あなたが今日のお昼に見ているBIのダッシュボードは「昨日の夜時点までの数字」だということ。これを知らずに、今さっき売れた最新の数字と突き合わせようとしても合うはずがないのだ。
データの粒度が違う
「税抜」か「税込」か。
「ポイント利用前」か「ポイント利用後」か。
「クーポン割引」は商品ごとに按分されているか、注文全体の合計から引かれているか。
データの粒度（細かさ）が違うものを足し合わせると、1円単位でのズレが発生する。このズレを気持ち悪がって「1円単位で合わせろ！」と指示を出す上司もいるが、原因がこの粒度や税計算の丸め処理によるものだと分かっていれば、不毛な修正作業に時間を溶かすこともなくなる。
正しい数字は目的によって変わる
結論を言おう。
「どの数字が絶対に正しいか」という問い自体が間違っている。利用目的によって「正しい数字」の定義は変わるのだ。
決算発表や税務署に出すための「経理の数字」は、1円の狂いも許されない厳格なもの。
一方で、Web広告の費用対効果を明日すぐに見直したいマーケターにとっては、「1円単位の正確さ」よりも「スピード（受注日ベースでの大まかな傾向）」の方がはるかに価値がある。
数字が合わないとき、「誰が間違えているか」を犯人探しするのではなく、「それぞれの数字は、どんな定義と除外条件で計算されているか」を言語化してすり合わせること。
これが、データと関わる非エンジニアに求められる最も重要なスキルなのだ。
データ品質を左右する5つの問題
「SQLは完璧に書けた。JOINも合っている。なのに、出てきたリストが使い物にならない……」
苦労して抽出したデータを前に、絶望した経験はないだろうか。
私がCRMの担当になりたての頃、意気揚々と抽出した「優良顧客リスト」の上位に、同じ名前の人が5人も並んでいたことがある。
データベースの世界には「Garbage In, Garbage Out（ゴミを入れたら、ゴミが出てくる）」という冷酷な格言がある。
どんなに立派なシステムを使い、どんなに美しいSQLを書いても、中に入っているデータ自体が汚ければ、結果はゴミになる。
現場の人間を悩ませる「データ品質」の5つの正体を、私の泥臭い失敗談とともに暴いていこう。
重複
最も厄介で、最もよく遭遇するのが「重複」だ。
同じ「鈴木一郎」さんが、別のメールアドレスを使って3回も会員登録をしている。あるいは、店舗のポイントカードとECサイトのアカウントが統合されず、別々の顧客として登録されている。
これを放置して「会員数100万人突破！」と喜んでいても、実は同じ人が何重にもカウントされているだけかもしれない。DMを送れば同じ家に3通届き、クレームに直結する。
データ品質とは何かを考えるとき、まず真っ先に疑うべきはこの重複だ。
欠損
「20代向けのキャンペーンを打ちたいのに、年齢が未入力（NULL）の人が半分もいる……」
これもよくある悲劇。必須項目にしていなかったため、あるいはシステム移行時のエラーで、肝心なデータがスッポリと抜け落ちている状態だ。
欠損が多い列を条件にして絞り込み（WHERE）を行うと、本来ターゲットになるはずだった人が大量に漏れてしまう。分析結果が大きく歪む原因になる。
誤り
「生年月日が2999年」
「電話番号が『ああああああ』」
笑い話のようだが、実務のデータベースを覗くと本気でこういうデータが転がっている。
入力画面のチェック（バリデーション）が甘いと、ユーザーは適当な値を入れてしまう。これを真に受けて「未来人の顧客がいます！」と報告するわけにはいかない。異常値やあり得ないデータを見抜く目が求められる。
表記・定義の不統一
- 株式会社A
- （株）A
- ㈱A（環境依存文字）
- ｶﾌﾞｼｷｶﾞｲｼｬ A（半角カタカナ）
BtoBの営業企画が一番泣かされるのがこれだ。
同じ会社なのに、入力された表記がバラバラ。データベースからすれば、これらはすべて「全くの別物」として扱われるため、GROUP BYで会社ごとに集計しようとしても、見事にバラバラに分割されてしまう。全角と半角、スペースの有無。この揺れを整える（クレンジングする）作業だけで、1日の大半が終わることも珍しくない。
鮮度不足
データはナマモノだ。
「3年前に抽出した優良顧客リスト」に今さらDMを送っても、宛先不明で大量に返ってくるのがオチ。人は引っ越すし、転職するし、好みも変わる。
最新の状態に更新されていない「古いデータ」は、存在しないことよりもタチが悪い誤判断を生む。
品質問題はシステムだけでは解決できない
これらの問題に直面したとき、当時の私は情シスに「なんとか自動で綺麗にしてくださいよ！」と噛み付いた。
しかし、データガバナンスとは何かを学んだ今なら分かる。品質問題はシステムだけでは絶対に解決しない。
- 店舗のスタッフが、レジで正しく顧客IDを検索してからポイントを付与する。
- Webの入力フォームで、全角半角を自動で統一する。
- 重複を見つけたら、どちらのデータを「正」として統合するかの運用ルールを決める。
こうした「入力時のルール」「業務フロー」「人間のチェック体制」が整って初めて、データベースの中身は綺麗に保たれる。データ品質を守る最前線にいるのは、エンジニアではなく、現場でシステムを使っている非エンジニアの私たちなのだ。
トランザクションと同時更新の基礎
データの品質と同じくらい、データベースの根幹を支えている見えない仕組みがある。
少し想像してみてほしい。
ECサイトで最後の1個の限定商品を買おうとした瞬間。クレジットカードの引き落としだけが完了して、肝心の注文完了画面でエラーが出た。商品は手に入らないのに、お金だけが引かれている……。
もしこんなことが起きたら、暴動が起きる。
これを絶対に防ぎ、データを安全に処理するための仕組みが「トランザクション」だ。
複数処理を一つの単位として扱う
実務における「注文」というアクションは、データベースの内部では複数の処理（SQL）の連続で行われている。
- 在庫テーブルから商品の数を「-1」する
- 顧客のポイント残高から使った分を「マイナス」する
- 注文履歴テーブルに新しいデータを「追加（INSERT）」する
この3つの処理は、どれか1つでも欠けてはいけない。トランザクションとは、これらの一連の処理を「絶対に分割できない1つのセット（単位）」として扱う考え方だ。
途中まで成功した状態を残さない
もし、2番目のポイントをマイナスした直後にサーバーの電源が落ちたらどうなるか。
データベースは、処理が最後まで完走しなかったことを検知し、「1」と「2」の処理を瞬時にキャンセルして、完全に元の状態に巻き戻す（これをロールバックと呼ぶ）。
「全部成功するか、全部失敗して元に戻るか」のどちらかしかない。途中まで成功した中途半端なデータ（お金だけ払って商品がない状態）を絶対に作らない。これがデータベースの底力だ。
ACID特性は安全な取引処理の考え方
IT系の資格試験などでは、この安全性を「ACID（アシッド）特性」というイカつい言葉で学ばされる。
Atomicity（原子性）、Consistency（一貫性）、Isolation（独立性）、Durability（耐久性）の頭文字なのだが、非エンジニアがこの英単語を丸暗記する必要はない。
要するに、「どんなエラーが起きても、データが矛盾したり壊れたりしないように、超安全に処理をやり遂げる（もしくは無かったことにする）ためのお約束ごと」だと思えばいい。銀行のシステムやクレジットカード決済が安心して使えるのは、このACID特性が裏でガッチリと守ってくれているからだ。
複数人が同時に更新すると競合が起きる
もう一つ、Excelでよく起きる悲劇を思い出してほしい。
共有サーバーのExcelをAさんとBさんが同時に開き、それぞれ別の編集をして上書き保存した。結果、後から保存した人のデータだけが残り、先の人の編集は消え去った。
これが「同時更新による競合」だ。
全国の店舗から、数千人のスタッフが同時にデータベースへアクセスしてデータを書き換える。もし何の対策もしていなければ、Excelと同じようにデータが上書きされ、在庫数がメチャクチャになってしまう。
ロックや同時実行制御で矛盾を防ぐ
この大惨事を防ぐため、データベースには「ロック」という機能がある。
Aさんが在庫データを書き換えようとしている一瞬の間、データベースはそのデータに鍵（ロック）をかける。その直後にアクセスしてきたBさんは、Aさんの処理が終わって鍵が開くまで、ほんのコンマ数秒だけ「順番待ち」をさせられるのだ。
この「同時実行制御」のおかげで、私たちは「誰かが編集中なので開けません」というExcelのストレスから解放され、数万人が同時にアクセスするWebサービスを矛盾なく利用できている。
データベースはただデータを保存しているだけでなく、こうした見えない交通整理を、文句一つ言わずに毎秒何百万回とこなしてくれているのだ。
インデックス・ログ・バックアップの役割
「検索が遅いなら、インデックスを貼ればいい。データが消えたら、バックアップから戻せばいい」
かつての私は、この呪文さえ知っていればデータベースの運用は完璧だと思い込んでいた。そして、見事に痛い目を見た。
データベースを安全かつ高速に動かすためには、インデックス、ログ、バックアップという3つの強力な裏方（仕組み）が存在する。しかし、これらは「ただ入れれば解決する魔法のツール」ではない。それぞれの役割と「間違えたときの恐ろしさ」を知っておくことが、情シスと対等に話すための第一歩になる。
インデックスは検索を速くする
100万ページの分厚い百科事典から、「データベース」という単語が載っているページを探し出せと言われたらどうするか。
1ページ目から順番にめくっていたら、日が暮れてしまう。誰もが巻末の「索引」を使うはずだ。
インデックスとは、まさにデータベースにおける「索引」のことだ。
例えば、顧客テーブルの「電話番号」列にインデックスを作成しておくと、データベースは内部で「電話番号順に並べた目次」を自動的に作ってくれる。
これがあるおかげで、数百万件の顧客データの中から、カスタマーサポートが特定の電話番号で検索をかけた瞬間、1秒もかからずに該当の顧客情報を引っ張り出せるのだ。
インデックスを増やせばよいわけではない
「検索がそんなに速くなるなら、全部の列にインデックスをつけちゃえばいいじゃないか！」
検索の遅さにイライラしていた私は、情シスに無邪気にこう提案した。しかし、相手の顔は完全に引きつっていた。
なぜか。
インデックス（目次）を作ると、検索は劇的に速くなる。しかし、データが新しく追加（INSERT）されたり、更新（UPDATE）されたりするたびに、データベースはその「目次」も書き直さなければならなくなるのだ。
- 顧客の住所が変わる
- 新しい注文が入る
- 商品名が変更される
すべての列にインデックスを貼ってしまうと、データが更新されるたびに莫大な量の「目次の書き直し」が発生し、システム全体が異常に重くなる。
検索を速くするためのインデックスが、逆にシステムを停止させる原因になり得る。「増やすほど常に良いわけではない」という事実だけは、絶対に覚えておこう。
ログは処理や変更を記録する
「誰だよ、昨日の夜に商品マスターの価格を全部ゼロ円に書き換えたのは！」
こんな大惨事が起きたとき、犯人探し……もとい、原因究明を可能にするのが「ログ（操作履歴）」だ。
データベースは、いつ、誰が、どんなSQLを実行して、どのデータをどう書き換えたかという処理のすべてを「トランザクションログ」として内部に細かく記録し続けている。
飛行機のフライトレコーダー（ブラックボックス）のようなものだと思ってほしい。万が一、途中でサーバーの電源が落ちても、このログさえ残っていれば「電源が落ちる直前の状態」までデータを正確に復元することができる。
バックアップは障害や誤削除に備える
そして、システム運用における最後の命綱がバックアップと復旧の基本だ。
ハードディスクが物理的に壊れる。落雷でサーバーが焼ける。あるいは、私のようにWHERE条件をつけ忘れてデータを全件吹き飛ばしてしまう。
こんな絶望的な状況から会社を救うために、1日1回など定期的にデータベースの中身を丸ごと別の安全な場所にコピーしておく。これがバックアップ。ここまでは非エンジニアでも直感的に理解できるはずだ。
バックアップがあっても復旧できるとは限らない
しかし、ここで私が体験した最も背筋の凍る現実を一つ。
「バックアップはあるから大丈夫だろう」と高を括っていた障害発生時。情シスが復元作業に入ったが、数時間経ってもシステムは戻らなかった。
理由は「バックアップファイルが壊れていたから」ではない。「復元する手順書の想定が古く、本番環境に戻すためのテスト（訓練）を一度もやっていなかったから」だ。
バックアップが存在する＝復旧できる、ではない。
いざという時に、誰が、どのバックアップファイルを使って、何時間以内に元に戻すか。その復元手順が明確に決まっており、定期的に復元テストをしている会社だけが、本当の意味でデータ品質を守ることができる。
「毎日バックアップを取っています」という報告だけで安心せず、「いざという時に本当に戻せるのか？」と問いかける視点を持とう。
非エンジニアはどこまでSQLを学ぶべき？
「SQLは全員が書けるようになるべきだ！」
最近、DX推進の名の下にこんな号令をかける会社が増えている。私も一時期、「これからはSQLが書けないマーケターは生き残れない」という煽り文句に踊らされ、分厚い専門書を買い込んだ。
結論から言うと、全員が高度なSQLを書けるようになる必要は全くない。
自分の役割（立ち位置）に合わせて、非エンジニア向けSQL学習ロードマップの中で「どこまで学ぶか」の線を引くことが、挫折しない唯一の方法だ。
データを利用する人は読み方を理解する
「ダッシュボードの数字を見るだけ」
「情シスが作ったExcelを加工するだけ」
この層（利用するだけの人）に、SQLを白紙から書くスキルは不要だ。
しかし、「SQLの読み方」だけは理解しておいた方がいい。
例えば、他人が作った抽出条件のSQLを見せられたとき、「WHEREのところに退会者を除外する条件が入ってないな」「INNER JOINをしているから、未購入者が消えているな」と、大まかな意味（翻訳）ができること。
これだけで、「なぜBIツールの数字と現場の肌感が違うのか」を自分で見抜けるようになる。
抽出依頼をする人は条件を言語化する
マーケティング担当や営業企画など、「こういうデータを出してほしい」と情シスや外部ベンダーに依頼する層。ここが一番苦労する。
彼らに必要なのは、SQLを書く技術ではなく、「自分が欲しいデータを、データベースの構造（テーブルとID）に沿って言語化する力」だ。
「最近よく買っている優良顧客のリストを出して」というフワッとした依頼は最悪だ。
「【顧客テーブル】と【注文テーブル】を【顧客ID】で結合して、注文日が【過去半年以内】で、購入合計金額が【5万円以上】の顧客をリストアップしてほしい」
このように、テーブル名、条件（WHERE）、粒度（GROUP BY）の概念を使って依頼できるようになれば、情シスとの無駄なラリーは劇的に減る。CRM担当者がSQLを学ぶメリットの9割はここにある。
自分で分析する人はSQLを実行する経験を持つ
アクセスログや購買データなど、数百万件の生データを自分でゴリゴリ分析したい人。
この層は、SELECT、WHERE、GROUP BY、JOINといった検索系のSQLを自分で書き、実行する経験が必須になる。
ただし、ここで求めるのは「美しいコードを書くこと」ではない。
- 自分が書いたJOINで、意図せず件数が爆発していないか確認する。
- NULLの扱いを間違えて、集計漏れを起こしていないか検算する。
こうした「泥臭い自己チェック」の経験を積むことが、データ分析者としての信頼に直結する。
DB設計・運用を担う人はさらに深く学ぶ
ここから先は、システム開発やデータベースの保守・運用を担う、あるいはそこへキャリアチェンジしたい人の領域だ。
データを安全に変更する（INSERT/UPDATE）、正規化によってテーブル設計を行う、インデックスを調整して検索スピードを上げる（チューニング）、トランザクション制御やバックアップ計画を策定する……。
非エンジニアが、いきなりこの領域に足を踏み入れると必ず火傷する。「なんとなく」でUPDATE文を実行し、会社に数千万円の損害を出しかねないからだ。
全員がデータベーススペシャリストを目指す必要はない
だからこそ、断言する。
CRMやBIを利用するすべての非エンジニアに、高度なDB設計や「データベーススペシャリスト」のような専門的な資格を勧めるのは、全くの的外れだ。
全員がエンジニアを目指す必要はない。自分の業務に必要な深さを見極め、まずは「自社のデータがどんなテーブルに分かれ、どのIDで繋がっているか」を知ること。そこから一歩ずつ、必要な分だけ武器を拾っていけばいいのだ。
資格はどのように選ぶ？
「資格さえ取れば、データ人材として華麗に転職できるかも」
過去の私はそんな淡い期待を抱き、一番難しそうな「データベーススペシャリスト試験」の分厚い参考書を買って、見事に1ページ目で挫折した。
エンジニアを目指すわけでもないのに、高度な専門資格に無防備に突撃するのは、草野球のおじさんがいきなりプロのキャンプに参加するようなものだ。
非エンジニアには、非エンジニアのための戦い方がある。自分の立ち位置と実務に合った資格を賢く選ぼう。
（※本項の試験制度や実施時期等の情報は、2026年8月時点のIPA公式発表に基づく確定情報、および予定・検討中の情報を整理したものです）
IT全体の基礎から学ぶならITパスポート
まずはここから。データベースの仕組み以前に、ネットワーク、セキュリティ、果ては会社の経営戦略まで、ITに関わる社会人としての「共通言語」を身につけるためのパスポートだ。
Excelやパワポしか触ってこなかった非エンジニアが、初めて「ITシステムの全体像」を俯瞰し、情シスが普段どんなことを気にしているのかを知るのに最適である。
業務データの管理・活用を学ぶならデータマネジメント試験
もしあなたが「事業会社でデータを使ってビジネスを動かす」立場なら、一番注目すべきがこれだ。
IPA（情報処理推進機構）の発表によると、2027年度から幅広いビジネスパーソンを想定した「データマネジメント試験の解説（新設予定）」が開始される予定となっている。
これは、データ・AIを効果的・効率的に活用するための基本的な知識・技能を評価する試験とされている。
2026年8月時点では詳細なシラバスが準備中であるため、「SQLの記述問題がどこまで出題されるか」などを推測で断定することは避けるが、CRMやBIツールを利用する現場の非エンジニアにとって、最も実務に直結する資格になる可能性が高い。
技術基礎を広く学ぶなら基本情報相当
単なるデータ活用だけでなく、システムが裏側でどう動いているか、プログラミングの基礎的なアルゴリズムやネットワークの仕組みまで踏み込んで知っておきたいなら、基本情報技術者試験（またはそれに相当するレベル）になる。
外部ベンダーと要件定義レベルで会話をしたいディレクターやDX推進担当者には、非常に強力な土台となる。
DB設計・運用の専門家を目指すならデータベーススペシャリスト
逆に、システム部門に異動して、本気でデータベースシステムの企画・要件定義・開発・運用・保守を主導したいならこれ。高度IT人材向けの超難関資格だ。
なお、2026年度のデータベーススペシャリスト試験の解説はCBT方式の後期試験として案内されており、現行の試験制度は「2026年度の実施をもって終了」することが確定している。
マーケターや企画職など、すべての非エンジニアがこの頂を目指す必要は全くない。
2027年度以降はPDS（データ・AI／システム）も確認する
資格マニアになる必要はないが、国の制度が変わる大きな流れは知っておいて損はない。
2027年度からは、現行の応用情報技術者試験・高度試験が「PDS（Professional Data/System）のマネジメント領域、データ・AI領域、システム領域」へと大幅に再編される予定となっている。
データベース関連の知識が、新制度のどの試験で、どの深さまで扱われるかは流動的だ。受験を検討する際は、必ず執筆時点ではなく「受験時点のIPA公式情報」を確認する癖をつけてほしい。
| 資格・試験名（※予定含む） | 対象者 | 学ぶ内容 | 実務での用途 | 次の学習 |
|---|---|---|---|---|
| ITパスポート | IT知識ゼロの全社会人 | IT・経営・セキュリティの基礎 | ベンダーや情シスとの共通言語獲得 | 基本情報、データマネジメント |
| データマネジメント試験 （※2027年度新設予定） |
データ活用を担うビジネスパーソン | データ・AIを効果的に活用する基本知識 | データ品質管理、データ分析企画の立案 | 専門領域の深掘り（PDS等） |
| 基本情報技術者 | ITに関わるすべての基礎を固めたい人 | システム構造、アルゴリズム基礎 | システム開発の要件定義サポート | 応用情報技術者 |
| データベーススペシャリスト （※現行制度は2026年度で終了） |
DB開発・保守を主導する高度IT人材 | 高度なDB設計、チューニング、復旧計画 | 大規模DBのパフォーマンス改善・運用 | PDS等の別領域の高度試験 |
データベース学習を実務につなげる方法
ここが本記事で一番大事なところ。
「資格の勉強をしました！」「SQLの本を読みました！」
それだけで、明日から給料が上がったり、華麗にデータサイエンティストへ転職できたりするほど、世の中は甘くない。
資格や本で得た知識は、自社の泥臭い業務データに当てはめて、初めて「使えるスキル」に化ける。私が長年もがき苦しみながら実践して、最も効果があった行動ステップを共有する。
自分が扱うデータを棚卸しする
まずは、普段エクセルでダウンロードしているデータや、BIツールで眺めている数字の「本当の置き場所」を書き出してみよう。
「顧客のマスターデータはSalesforceにある」「日々の売上トランザクションは自社開発の基幹システムにある」「WebのアクセスログはGA4にある」
この物理的なデータの住処（すみか）を把握することが、すべてのスタートラインになる。
一行が何を表しているか確認する
そのデータをシステムから出力したとき、横の一行は「何を一件」としてカウントしているのか。
顧客1人なのか。注文1回なのか。それとも注文明細の中の1商品なのか。
この粒度を言語化できないデータは、絶対にExcelでSUM（合計）してはいけない。数字が狂う元凶だ。
IDとテーブルの関係を図にする
紙とペンでいい。
「顧客テーブル」と「注文テーブル」を四角で囲み、どのIDとどのIDが繋がっているか（外部キー）、矢印を引っ張ってみる。
「あ、うちは店舗の会員IDと、ECの顧客IDがシステム的に繋がってないんだな」と、視覚的に絶望……いや、気づくことができるはずだ。
ER図の読み方にあるようなエンジニア向けの厳密な記法でなくていい。自分がデータの繋がりを理解できれば十分だ。
数字の定義を文章にする
「うちの会社の『売上』とは何か？」
これを、他部署の人間が読んでも絶対に誤解しないレベルで文章化する。
「出荷日を基準とし、テストアカウントの注文と返品を除外し、消費税を含まない金額の合計」
ここまで定義できて初めて、データベースから正しい数字を引き出すための条件（WHERE句や除外条件）が完成する。
簡単なSQLを読んでみる
情シスが作ってくれたデータ抽出用のクエリや、ツールの裏側で動いているSQLを見せてもらおう。
白紙から書けなくてもいい。「SELECT（持ってくる）」「FROM（どのテーブルから）」「WHERE（この条件で）」の英単語を追いかけ、自分が定義した条件と合致しているかを翻訳（リーディング）する練習をするのだ。
抽出結果を検算する
データベースから出てきた数字を、神の啓示のように鵜呑みにしてはいけない。
必ず、別ルートで算出した確実な数字（経理が確定させた月次売上など）と突き合わせて検算する。
もしズレていたら、JOINの結合条件を誤って件数が増えていないか、NULLのデータを集計から弾いてしまっていないかを確認する。この地道な検算作業こそが、社内での「データ人材としての信頼」を作る。
「資格×現職」で専門性を作る
資格を取っただけで「SQL書けます！」とアピールしても、実務経験がなければ市場価値は上がらない。
しかし、「データマネジメントの体系的な知識を持ち、現職でCRMデータのテーブル構造を整理し、マーケ・営業間の数字の定義統一をリードしました」と言えれば、それは立派な専門性になる。
学ぶだけで終わらせず、いま目の前にある会社の散らかったデータを整理する。
それが、無理に会社を辞めるリスクを取らず、社内で賢く生き残るための、一番確実なキャリア戦略だ。
データベースに関するよくある質問
ここまで読んでくれたあなたは、もう「データベース＝ただのファイル置き場」という勘違いからは完全に抜け出しているはずだ。
最後に、私が過去に社内で非エンジニアの同僚たちからよく相談された「データベースとSQLにまつわるリアルな悩み」を一問一答形式で整理しておく。当時の私のように、分厚い参考書の前で立ち尽くしている人のヒントになれば嬉しい。
数学やプログラミングが苦手でも理解できますか？
断言する。全く問題ない。
データベースの基本は「整理整頓のルール」であり、高度な数式を使うわけではない。SQLに至っては、単なる「英語のお願い文（Select、From、Where）」だ。
数学の知識よりも、「この数字の定義は何だ？」「このテーブルの1行は何を表している？」と、泥臭く言葉の定義を突き詰める国語力や論理的思考力の方が、実務では100倍役に立つ。
SQLとデータベースはどちらから学ぶべきですか？
絶対に「データベースの構造（テーブルとIDの繋がり）」から学ぶべきだ。
手紙を出す相手（テーブル）と宛先（ID）を知らないまま、手紙の書き方（SQL）だけを暗記しても、実務では一行もコードを書けない。まずは自社のデータがどんな箱に分かれているか、地図を頭に入れることから始めてほしい。
Excelが使えればデータベースは不要ですか？
用途が違うため、両方必要になる。
数十万件を超える大量データの安全な保存や、複数人での同時利用はデータベースの独壇場。そこから必要なデータだけを抽出し、手元でサクッとグラフ化したりシミュレーションしたりするのはExcelの得意分野だ。「どちらが偉いか」ではなく、適材適所で使い分けるのが正解。
主キーは必ず数字でなければいけませんか？
数字（連番）である必要は必ずしもない。ランダムな英数字の文字列（UUIDなど）が使われることも多い。
大切なのは「絶対に重複せず、後から変わらない値」であること。名前やメールアドレスのように、人間が意味を読み取れる値（変わる可能性があるもの）を主キーにするのだけは避けるべきだ。
JOINすると件数が増えるのはなぜですか？
大半の原因は「結合条件（ON句）の指定ミス」か、「一対多のデータを繋いだから」のどちらかだ。
1人の顧客に対して、3件の注文履歴があるテーブルをJOINすれば、結果は当然「3行」になって出力される。これが意図したものなら問題ないが、結合条件を書き忘れて全件掛け合わせ（クロスジョイン）になっていないかは、実行前に必ず確認する癖をつけよう。
正規化はどこまで覚える必要がありますか？
非エンジニアであれば「第3正規形」などの学術的な用語や定義を丸暗記する必要はない。
「なぜこのデータは別のテーブルに追い出されているのか？（＝重複をなくして、更新時の矛盾を防ぐため）」という【目的】さえ腹落ちしていれば十分。情シスが作ったテーブル設計の意図が読めるようになれば、あなたの勝ちだ。
マーケターにもSQLは必要ですか？
ゼロから複雑なコードを書ける必要はないが、「読む力」と「条件を言語化する力」は必須だと言っていい。
情シスに抽出を依頼するとき、「どのテーブルとどのテーブルを繋ぎ、どういう条件で絞り込むか」を指定できるようになれば、的外れなデータを出されてイライラする無駄なラリーは激減する。
Pythonより先にSQLを学ぶべきですか？
実務でデータ分析をしたいなら、まずはSQLが先だ。
Pythonは強力な分析ツールだが、そもそも「分析するための綺麗なデータ」をデータベースから引っ張り出してこないことには何も始まらない。データの抽出（SQL）があってこその、高度な分析（Python）だ。
データマネジメント試験ではSQLも出題されますか？
2027年度に新設予定のデータマネジメント試験だが、2026年8月時点では詳細なシラバスが準備中である。
具体的な出題範囲やSQLの記述問題が出るかどうかを推測で語ることは避ける。受験を検討する際は、必ずIPAの公式発表で最新のシラバスを確認してほしい。
データベーススペシャリスト試験は非エンジニアにも必要ですか？
全く必要ない。
これは、データベースシステムの要件定義から開発、保守までを主導する「高度ITエンジニア」向けの試験。非エンジニアが無理に手を出すと、難解な専門用語の壁に跳ね返されて挫折するだけだ。自分の実務範囲に合った資格（データマネジメント試験など）を選ぶことが、遠回りに見えて一番の近道になる。
AI時代にもデータベース知識は必要ですか？
AI時代だからこそ、データベースの知識はより一層重要になる。
どんなに優秀なAIも、学習させるデータが重複だらけで、欠損があり、表記がバラバラ（品質が低い状態）なら、使い物にならないゴミしか出力しない。AIに綺麗な餌（データ）を食べさせるための基盤作りこそが、これからのビジネスパーソンに求められる必須スキルだ。
まとめ｜SQLを書く前に、データの単位とつながりを理解しよう
「SQLさえ書ければ、データ人材として活躍できる」
もしあなたが今、そんな甘い言葉に踊らされて分厚い入門書を買おうとしているなら、そっと本棚に戻してほしい。
過去の私がそうだったように、構文の暗記から入る学習は必ず行き詰まる。
私たちが本当に知るべきなのは、魔法の呪文ではなく「目の前の業務データが、どんなルールで箱に収められているか」という構造そのものだ。
- そのデータは「何を一件」としているのか？
- マスターデータとトランザクションデータの違いは何か？
- 分断されたデータは、どのID（主キーと外部キー）で繋がっているのか？
- その「売上」という数字は、誰が、どんな条件で定義したものか？
この泥臭い事実を一つひとつ紐解くこと。
往復3時間の通勤電車の中で、私は暗号のようなSQLの参考書を読むのをやめ、自社のテーブル構造をノートに書き出すことからやり直した。結果的に、それが情シスと対等に話し、マーケターとして正しい数字を根拠に企画を通すための最強の武器になった。
エンジニアになる必要はない。
今の仕事のまま、データという最強の武器を味方につけるために。
今日、明日からできる行動として、まずは「あなたが毎日見ているその数字の定義」を、一つだけでいいから文章にして書き出してみてほしい。その小さな一歩が、データに振り回されるだけの会社員から抜け出すためのスタートラインになる。