データ分析に必要なSQLの6つのレベル
はじめに
最近はビジネスパーソンがSQLを書くべきか否かが議論されることが増えてきたように感じます。個人的には、SQLに関して議論されること自体がとても嬉しく感じています。SQLを使ったデータ分析が話題になることは、データ活用が社会的にも進んでいる証拠だと感じます。
様々な意見がある中で、「ビジネスパーソンもSQLを書いた方が良い」という意見と、「ビジネスパーソンはSQLを書かない方が良い」という意見の両方があります。それぞれの主張にも一理あり、私もどちらの意見も一定の理解はできます。
しかし、個人的には「ビジネスパーソンはSQLを学んだ方が良い」と考えています。あえて「学ぶ」という表現に変えてますが、SQLを「使う」のと「学ぶ」のとは少し違いがあると思っていて、SQLを「学ぶ」ことに関しては全てのビジネスパーソンがやって欲しいと考えています。そこで今回はなぜそう思うのか、「学ぶ」と「使う」のレベルの違いは何か、詳しくまとめてみたいと思います。
ビジネスパーソンがSQLを学ぶべき理由
まず、「ビジネスパーソン」とはその名の通り仕事をしている人を指しており、営業、マーケター、人事、エンジニア、アナリスト、マネージャー、経営者など、様々な職種や役職を含んでいます。いかなる職種であっても、SQLを学ぶ意義はあると考えているため、あえて広い主語として「ビジネスパーソン」を用いています。
また、「学んだほうが良い」と表現したのは、SQLを学んで「使える」ようになるまでにはいくつかのレベルがあり、目指すべきレベルは人や組織によって異なるからです。その中でも、SQLの基礎的な部分を「学ぶ」ことは、すべてのビジネスパーソンにぜひ取り組んでほしいと考えています。
ビジネスパーソンがSQLを学ぶべき理由としては大きく以下3つあると思っています。
①データベースやテーブルなどのデータ構造が理解できるようになり、それによってデータの利活用に対する基礎知識を身につけることができる。
②職種に関わらず実務で幅広く活用できるため広く「ビジネスパーソン」が学ぶ価値がある
③学習コストが低く、一度覚えると長期で使えるスキルなので学習することに対する投資対効果が高い
ビジネスパーソンがSQLを学ぶべき理由についての詳細は、以下でも言及しているので見ていただけると嬉しいです。（興味あがればSQL研修サービスと合わせて見ていただけると大変嬉しいです。）
ビジネスパーソンがSQLを学ぶための6つのレベル
ビジネスパーソンがSQLを学ぶことに意味があるという前提に立った時に、どこまで何を学ぶ必要があるかについて、6つのレベル分けをしてみました。また、6つのレベルとそれぞれのレベルを目指す対象者のイメージもまとめてみました。全ての人がSQLを完全に使いこなす必要もなく、日々の仕事内容や職種に応じて学ぶレベル感が変わってくると思っています。
レベル6：他の人にSQLを教えることができる
レベル5：複雑なデータでも自分でゼロからSQLを使ってデータ集計ができる
レベル4：簡単なデータであれば自分でゼロからSQLを使ってデータ集計ができる
レベル3：既存のSQLから一部の条件などを修正して実際のデータ集計ができる
レベル2：データ分析に必要なSQLの基礎的な構文について理解する
レベル1：知識としてSQLに関連する概念（データベース、テーブル、クエリ）を理解する
レベル1：知識としてSQLに関連する概念を理解する
レベル1は単純な知識としてSQLに関する概念を理解するレベルです。具体的にはSQLを扱う上で必須になる「データベース」や「テーブル」の概念を把握し、SQLで何ができるかを理解することです。
今の時代、企業でデータ分析をすることは当たり前になっています。データを活用して意思決定をしていくことが変化の激しい時代に生き残る方法の一つだと考えています。そんなデータ分析が必須になっている時代において、具体的なデータとは何か？データ分析とは何をやるのか？基本的な概念を理解することはとても重要です。その意味で「データベース」や「テーブル」などのデータを扱うための基本的な概念としてSQLを学ぶことは一定の意味があると思っています。
単純に「データ」だけを理解するのであればSQLまで学ぶ必要はないかもしれません。しかし、SQLを学ぶメリットとしてはデータの理解だけでなくその先のデータの取得やデータの活用という観点も合わせて学ぶことができることにあると思います。
例えばテーブルとはどういうものか、行と列で構成されたデータの塊という概念を理解できると、実際にどのようにデータを扱うのかが分かりやすくなり、データ分析に対する解像度も上がると思います。
エクセルのセル結合の例
よくSNSなどで「エクセルでセル結合するのは悪」といった議論を見かけます。これは、行と列で構成されているデータに対して「結合」という操作を行うと、データが扱いづらくなるという不満から来ているのだと思います。
セル結合を行うと、データの並びが崩れ、後で集計を行う際に問題が生じる可能性があります。これは、テーブルの概念や行と列の構造を理解していないと起こりがちなミスです。
※補足：個人的には、エクセルのセル結合自体が悪だとは思っていません。エクセルにはCSVのようなデータそのものを表現する機能もあれば、グラフ化などのビジュアライゼーション機能もあります。CSVのようなデータそのものを表現する際にはセル結合はNGですが、ビジュアライゼーションが目的であればセル結合も有用だと思っています。
データベースやテーブルの概念を理解していて、データの扱いに長けている人だとセルが結合されるとテーブルの構造から逸脱してデータが扱いにくくなってしまうという例です。分かっていて意図的にやっている（エクセルをデータの可視化目的で使っている）場合には特に問題ないですが、そのデータをローデータとして活用することを考えると、事前にテーブルの概念やそれをどう使っていくのかの概念を理解していないと使いにくいデータが生まれてしまいます。
オープンデータの活用
最近では、オープンデータとして様々なデータが公開され、誰でも自由に使えるようになっています。しかし、そのデータが使いやすい形式になっているとは限りません。先ほどのエクセルの話にも近いですが、オープンデータとして公開されてはいるもののデータ分析としては決して使いやすいデータになっているとは限りません。
e-Govデータポータルでは、行政機関等が保有する公共データがエクセルやCSV形式で公開されています。しかし、CSVとしてデータが公開されてはいるものの、実際に中身を見てみるとテーブルの概念が正しく適用されておらず、データ分析に適していないファイルもあります。
例えば「人口動態調査_人口動態統計_確定数_総覧_年次_2015年」のCSVファイルを見てみると、以下のようになっています。（データをダウンロードをしてみると以下のようになっています。）
正直なところ、これをそのままデータ分析に使うのは難しいです。なぜなら、そもそもCSVファイルとしての形式に適しておらず、行と列の概念でデータが整理されていないため、SQLやBIツールなど、他のツールで活用としても取り込みにくいから
データの概念を理解する重要性
こういったデータが公開されてしまう背景には、テーブルの概念や行と列の構造を理解していない人が多いのではないかと思います。データベース、テーブル、SQLなどのデータを扱う基本的な概念を理解していれば、このような使いづらいオープンデータも減ってくるのではないかと期待しています。
今後オープンデータを様々な企業で活用していくことを考えたり、社内のデータ利活用が当たり前になっていくことを考えると、「知識としてSQLに関連する概念を理解する」ことは、SQLを使ってデータ分析をするかどうかに関わらず、現代においては全ての人が理解しておいて損はない内容だと思います。
レベル2：データ分析に必要なSQLの基礎的な構文について理解する
レベル1がデータベースの概念、テーブルの概念、SQLの概念の理解に対して、レベル2ではもう少しSQLについて広く浅く理解するイメージです。
ここでいうSQLとは、データ分析で使うSQLのことを指しています。SQLは幅が広く、データ分析で使うSQLもあれば、WebサービスやiOSアプリなどアプリケーション開発でもSQLが使われることがあります。アプリケーション開発で使うSQLはデータベースやテーブルの構成から処理速度を考慮した複雑なSQLを覚える必要があります。
一方、データ分析で使うSQLであれば、SELECT文を中心とした基本的な構文を覚えることで一定のデータ集計が可能になります。SQLにはデータの取得、更新、削除など様々な用途があります。ただし、アプリケーション開発で使うSQLとデータ分析で使うSQLでは、覚えるべきポイントが異なります。データ分析でよく使うSQLの基本構文を覚えることでデータ分析についての解像度がより高まると思っています。
基本的な構文とは
今回のレベルで定義しているデータ分析でよく使うSQLの基本構文とは、具体的には以下のことを指しています。
1. SELECT / LIMIT / ORDER BY：必要なデータを取得する。
2. 集約関数 / GROUP BY / DISTINCT：複数のデータを集約して1つにまとめる。
3. WHERE / HAVING：特定の条件でデータを抽出する。
4. JOIN：複数のテーブルを横に結合する。
5. UNION：複数のテーブルを縦に結合する。
6. CASE：条件に応じてデータを分類する。
7. サブクエリ / WITH句：複数のクエリを組み合わせる。
これらの構文は私が出版した本で取り扱っている構文です。ビジネスパーソンがゼロからデータ分析で使うSQLを学ぶ際に必要最低限の内容です。サブクエリやWITH句は基本的な構文というよりは、少し実践的な領域になりますが、データ分析でよく使う観点から含めています。これらSQLの構文について「理解する」ことがレベル2になります。あくまで「理解する」、というレベル感なのでこれらSQLを実際に「使う」のはまた次以降のレベルになります。
理解することのハードルは低い
ここでは「理解する」と定義していますが、SQLの構文を理解すること自体はそれほど難しくありません。この内容は私が出版した本の中に書かれているものですが、私が本を出版する前に内容のわかりやすさを確認するため、妻に協力してもらいSQLの基礎をレクチャーしたことがあります。私の妻は非IT系でPC操作も得意ではなく、もちろんSQLについては見たことも聞いたこともない状態でした。そんな妻にゼロからSQLについて説明し、ハンズオン形式で上記構文を少しずつレクチャーしていきました。
2,3時間程度レクチャーしましたが、結果的に妻は「内容は理解できる」と言ってくれました。もちろん一回聞いただけで全てを完璧に理解している状態とは思いませんが、少なくとも私が説明した内容については理解でき、SQLについても基本的な概念含めて理解ができたと思います。つまり、SQLの概念や基本的な構文の理解であれば短時間で誰でも学べる内容なのです。
SQLの具体的な構文を理解したり、ハンズオン形式で実際にSQLを簡易的に触って実行してみることができれば、SQLを使ってデータを取得することへの理解が深まると思います。データの取得についての理解が深まると、データ分析の具体的な作業やアウトプットもイメージができます。たとえ自分でデータ分析ができなくとも、データ集計を依頼する場合やデータ活用についての理解が深まることで、データを活用した意思決定プロセスに近づくことができます。その意味でも多くのビジネスパーソンがSQLについて理解することの意味は大きいと思っています。
レベル3：既存のSQLから一部の条件などを修正して実際のデータ集計ができる
レベル2では知識としてSQLを理解する段階でしたが、レベル3では実際に業務の中でSQLが実行できるレベルです。イメージとしては実務において他の人が書いたSQLに対して一部日付の条件を変えて実行したりできるような状態です。自分でゼロからSQLを書くのは難しいけど、既存のSQLを使いながらデータ集計業務の一部ができるようなレベル感です。
「知っている」と「できる」の違い
何事にも「知っている」と「できる」には大きな差があります。知識として理解しているからといってそれを実際に使えるとは限りません。SQLについても同様で、知識としてSQLを知っていても、実際に自分で使えるかどうかは別問題です。
レベル2と3の大きな違いとしては、レベル2が「知っている」状態なのに対して、レベル3は「できる」状態になっていることです。ただし「できる」にもさらにグラデーションがあるのでそれについてはレベル4以降とも関連します。少なくともレベル3については多少なりともSQLが「できる」状態に入りかけている状態を指しています。
実務での活用例
例えば、マーケターがデータ抽出を依頼し、データアナリストやデータエンジニアがSQLでデータを取得して結果を共有するケースは事業会社などではよくあることだと思います。この場合、マーケターにSQLの理解があれば、提供されたSQLとデータをもとに、自分で条件を変更してデータを取得することができます。都度データ抽出依頼するのも悪くはないですが、日付を変えたり、少し条件を変えるくらいであればデータアナリストやデータエンジニアがサポートすればビジネスサイドでも活用することができます。
アドホックの集計に関しては都度BIを作るのは手間になることが多く、SQLで集計することの方が効率が良い場合が多いです。その際にSQLを使い捨てるよりはSQLをちゃんと資産として残し、他の人が活用できるようにすることでデータの活用もしやすくなります。
また、仮にマーケターなどがSQLを自分で書かずに依頼する場合であっても、ある程度自分でSQLが使えると依頼する時の解像度が高まり、データ抽出の際のコミュニケーションも円滑になるメリットもあると思っています。
一方でこの辺りの話になると、ビジネスサイドがSQLを触ることに対するネガティブな意見も出てきますが、冒頭お伝えした通り、個人的にはマーケターやプロダクトマネージャーなどがSQLを触ってデータを取得できた方がデータ抽出のスピードが上がり、業務効率も向上すると思っています。それがたとえ自分でゼロからSQLをかけなくとも、SQLの基本的な構文を理解していて、自分で少し条件を変えて実行できるくらいであったとしても効果はあると思っています。データ分析に重要なことはデータを活用して意思決定することです。意思決定するスピードは早ければ早いほど良いのでビジネスサイドがSQLを使うことにメリットはあると思っています。
レベル4：簡単なSQLをゼロから書いてデータ集計ができる
このレベルでは、ほしいデータがあるときに、自分でゼロからSQLを書いてデータを取得できるレベルです。レベル3は自分でゼロからSQLを書くのは難しく、人が書いたSQLを見て条件を変えて実行できる状態なのに対して、レベル4では自分の頭でSQLを組み立て必要な情報を取得できるという点です。ただし、複雑なデータ集計ではなく、基礎集計に近いデータの集計ができる状態を指しています。SQLでの具体的な活用イメージとしては以下の通りです。
JOINは1～2テーブル程度
ウィンドウ関数や複雑なサブクエリは使用しない
WITH句も1つくらい使用する程度
実際のデータ分析例
例えばECサイトのデータ分析で1年間の購入日数ごとの購入者を把握したい場合を考えてみます。アウトプットのイメージは以下の通りです。
購入日数 購入者数
1日 300人
2日 100人
3日 50人
・
・
・
これをSQLで書くと以下のようになります。（※テーブル、カラム、条件などはサンプルです）
WITH order_data_users AS(
SELECT
o.user_id,
COUNT(DISTINCT order_date) AS count_order_date
FROM
orders o
LEFT JOIN products p ON o.order_product_id = p.product_id
LEFT JOIN users u ON o.user_id = u.user_id
WHERE
order_date BETWEEN '2022-01-01' AND '2022-12-31'
GROUP BY
o.user_id
)
SELECT
count_order_date,
COUNT(DISTINCT user_id) AS user_count
FROM
order_data_users
GROUP BY
count_order_date
ORDER BY
count_order_dateこれはまずWITH句を使って、ユーザーごとの年間の購入日数を抽出しています。LEFT JOINを使って注文情報、商品情報、顧客情報を結合し、WHEREで期間の条件を指定して、GROUP BYでユーザー単位の集計を行います。その結果をもとにして、最後に注文日数別にユーザー数を集計することで購入日数ごとの購入者を把握することができます。
これはWITH句が使えたりJOINが使えれば、集計のやり方を少し考えれば比較的簡単に出せるデータです。実際にECサイトの分析とかでもよくみるような数値です。レベル4ではこれくらいのSQLが自分で考えて書ける状態です。
実務での活用イメージ
上記よりももっと単純に、日別の売り上げをSQLで出すとか、商品ごとの購入者数を出すとか、そういった基本的な集計をしたいときに自分でSQLを考えてデータの抽出ができると、ちょっとしたデータを確認したいときにも便利です。
このような「よく見る」数値に関してはBIでダッシュボード化されていて、毎回SQLを書く必要はないことが多いとは思います。ただ、例えばBI上だとデータの制限があり、直近3年分のデータしか見れないが、もっと過去に遡ってデータを見たい場合など、自分でSQLがかければすぐにデータが確認できたりします。このようなわざわざエンジニアやデータアナリストに依頼するほどのことでもないけど、手元ですぐに確認したい数値が自分で見れるようになると意思決定も早くなるメリットがあると思っています。
また先ほどの例のような年間10回購入しているユーザーがどんなユーザーなのか詳細を確認したいときに、ユーザーIDを抽出してそのユーザーの購入日時、購入商品などを把握することでN1分析のようなこともすぐにできるようになります。マーケターであればそこからペルソナをイメージしたり、具体的な施策を考えたりもできます。
SELECT
*
FROM
order_data_users
WHERE
user_id = 'XXXXXXX'なのでそこまで複雑ではないSQLが自分で書けるとそれだけでも日々の業務の中で活かせることや意思決定に繋げることができるので、ビジネスパーソンとしてもこのレベル4を目指せるととても良いと思っています。
レベル5：複雑なSQLをゼロから書いてデータ集計ができる
レベル5ではレベル4と違い、複雑な要件であっても自分でSQLに落とし込んでデータの集計ができるようなレベル感を指します。具体的なSQLのスキルのイメージは以下の通りです。
2つ以上のサブクエリやウィンドウ関数、相関サブクエリなどが使える
既存のデータを使って演算や条件によって新しいデータが作れる
データの前処理を含めたSQLの記述ができる
可読性が高く汎用的なSQLを書ける
例えば、以下は実際に私がとあるプロジェクトで書いたSQLです。ウィンドウ関数や相関サブクエリは使っていないですが、データの前処理や複数のWITH句を使いながら最終的にデータを抽出しています。（※テーブル、カラム、条件はあくまでサンプルです。また、可読性が高いかは怪しいところですが、あくまでイメージとしてこれくらいのボリュームのSQLがある程度自分で考えて書けるレベルというニュアンスです）
WITH defective_order_number AS(
SELECT DISTINCT
伝票番号
FROM
生産依頼情報マスタ
WHERE
(番号 LIKE '%不適合%' OR 番号 LIKE '%不良%')
),
target_order_data AS(
SELECT
*,
-- 生産開始までの日数を追加
cast(julianday(生産開始予定日) AS int) - cast(julianday(受注日) AS int) AS 生産開始までの日数
FROM
order_data
-- 納期条件
WHERE
納期 >= 0
AND 納期 < 20
-- 期間条件
AND 受注日 >= '2010-01-01'
AND 受注日 <= '2021-12-31'
AND 伝票番号 NOT IN (SELECT 伝票番号 FROM defective_order_number)
),
-- 伝票番号、製品名ごとの工程
order_product_process AS(
SELECT
伝票番号,
製品名,
GROUP_CONCAT(工程名, '-') AS 工程名,
CASE
WHEN GROUP_CONCAT(工程名, '-') IS NULL THEN 製品名
ELSE 製品名 || '：' || GROUP_CONCAT(工程名, '-')
END AS 製品工程名,
MAX(生産完了日) AS 工程完了日
FROM
order_data_detail
-- 物流を除外
WHERE
工程名 NOT LIKE '%物流%'
GROUP BY
伝票番号,
製品名
),
-- 日毎の生産ストック数を追加
target_order_data_add_production_count AS(
SELECT
*,
-- 並び替え用に数字でレンジを分ける
CASE
WHEN stock < 1000 THEN 1000
WHEN stock <= 2000 THEN 2000
WHEN stock <= 3000 THEN 3000
WHEN stock <= 4000 THEN 4000
WHEN stock <= 5000 THEN 5000
WHEN stock <= 6000 THEN 6000
WHEN stock <= 7000 THEN 7000
WHEN stock <= 8000 THEN 8000
WHEN stock <= 9000 THEN 9000
WHEN stock <= 10000 THEN 10000
WHEN stock > 10000 THEN 10001
END AS 生産中の数量_数字,
-- 表示用
CASE
WHEN stock < 1000 THEN '1000未満'
WHEN stock <= 2000 THEN '1000〜2000'
WHEN stock <= 3000 THEN '2001〜3000'
WHEN stock <= 4000 THEN '3001〜4000'
WHEN stock <= 5000 THEN '4001〜5000'
WHEN stock <= 6000 THEN '5001〜6000'
WHEN stock <= 7000 THEN '6001〜7000'
WHEN stock <= 8000 THEN '7001〜8000'
WHEN stock <= 9000 THEN '8001〜9000'
WHEN stock <= 10000 THEN '9001〜10000'
WHEN stock > 10000 THEN '10000以上'
END AS 生産中の数量
FROM
target_order_data o
LEFT JOIN production_count pc ON o.受注日 = pc.target_date
),
-- 製品工程別、生産中の数量別の最短納期日数
min_production_count AS(
SELECT
pp.製品工程名,
生産中の数量_数字,
MIN(納期) AS 最短納期
FROM
target_order_data_add_production_count o
LEFT JOIN order_product_process pp ON o.伝票番号 = pp.伝票番号
GROUP BY
pp.製品工程名,
生産中の数量_数字
)
SELECT
pp.製品工程名,
o.生産中の数量,
COUNT(DISTINCT o.伝票番号) AS 受注数,
AVG(納期) AS 平均納期,
MIN(納期) AS 最短納期,
MAX(納期) AS 最大納期,
AVG(生産開始までの日数) AS 平均生産開始までの日数,
MIN(生産開始までの日数) AS 最短生産開始までの日数,
MAX(生産開始までの日数) AS 最大生産開始までの日数,
AVG(cast(julianday(工程完了日) AS int) - cast(julianday(生産開始予定日) AS int)) AS 平均工程完了日数,
MIN(cast(julianday(工程完了日) AS int) - cast(julianday(生産開始予定日) AS int)) AS 最短工程完了日数,
MAX(cast(julianday(工程完了日) AS int) - cast(julianday(生産開始予定日) AS int)) AS 最大工程完了日数,
AVG(cast(julianday(出荷日) AS int) - cast(julianday(工程完了日) AS int)) AS 平均出荷日までの日数,
MIN(cast(julianday(出荷日) AS int) - cast(julianday(工程完了日) AS int)) AS 最短出荷日までの日数,
MAX(cast(julianday(出荷日) AS int) - cast(julianday(工程完了日) AS int)) AS 最大出荷日までの日数,
COUNT(
DISTINCT CASE
WHEN 納期 = 最短納期 THEN o.伝票番号
ELSE NULL
END
) AS 最短納期一致受注数,
round(cast(COUNT(
DISTINCT CASE
WHEN 納期 = 最短納期 THEN o.伝票番号
ELSE NULL
END
) AS real) / cast(COUNT(DISTINCT o.伝票番号) AS real) * 100, 2) AS 最短納期一致割合,
COUNT(
DISTINCT CASE
WHEN 納期 <= 最短納期 + 1 THEN o.伝票番号
ELSE NULL
END
) AS 最短納期プラス1日一致受注数,
round(cast(COUNT(
DISTINCT CASE
WHEN 納期 <= 最短納期 + 1 THEN o.伝票番号
ELSE NULL
END
) AS real) / cast(COUNT(DISTINCT o.伝票番号) AS real) * 100, 2) AS 最短納期プラス1日一致割合,
SUM(注文数) AS 注文数,
SUM(生産数) AS 生産数,
SUM(注文数 * 単価) AS 売上
FROM
target_order_data_add_production_count o
LEFT JOIN order_product_process pp ON o.伝票番号 = pp.伝票番号
LEFT JOIN min_production_count m ON m.生産中の数量_数字 = o.生産中の数量_数字 AND m.製品工程名 = pp.製品工程名
WHERE
pp.製品工程名 IS NOT NULL
AND 生産開始までの日数 >= 0
AND cast(julianday(工程完了日) AS int) - cast(julianday(生産開始予定日) AS int) >= 0
AND cast(julianday(出荷日) AS int) - cast(julianday(工程完了日) AS int) >= 0
GROUP BY
pp.製品工程名,
o.生産中の数量
ORDER BY
pp.製品工程名,
o.生産中の数量_数字詳細な解説は控えますが、WITH句を複数使って事前にデータの処理を何度も行ったり、既存の日付の値を使って「生産開始までの日数」という新しい値を作ったりしています。またCASE式も使いながら条件に合わせて分析ようの新しい軸を作ったりしながら最終的に欲しいデータを抽出しています。
レベル5ではこのような一見複雑そうに見えるSQLを自分で最初から順序立てて考えて組み立てができ、必要なデータの集計が可能な状態のイメージです。
実務での活用イメージ
このレベルになるといわゆるデータエンジニアやデータアナリストのような、ビジネスサイドからの要件を聞いてそれをSQLに落とし込むことができるレベル感です。ただし、ここではあくまで「SQLのレベル」を定義しているので、要件を正しく理解するとか、ビジネスゴールと出すべき数値が本当に一致しているのかなどをチェックするようなSQL力と直接関係のしないことはあえて定義の中には入れてません。なので、SQLのレベルとしてはここまでできるけど、それだけで優秀なデータエンジニアやデータアナリストになれるかというとそういう訳でもありません。
もちろんマーケター、営業、プロダクトマネージャーなどのビジネスサイドの人であってもこのレベル感までSQLが書けるとできる範囲も広がるのでできるに越したことはありません。ただ、このレベルはどちらかというとデータエンジニアやデータアナリストなどのデータを抽出することが専門的な役割の方が身につけておくべきレベル感だと思っているので、ビジネスパーソンとしては必須のレベルだとは思っていません。
レベル6：他の人にSQLを教えることができる
最後のレベルは、他の人にSQLを教えることができる段階です。「知ってる」と「できる」に壁があるように、「できる」と「人に教えることができる」にも壁が存在します。自分の言葉で、他の人に教えることができるのはその分、その技術に対して精通していることを意味しています。その意味でレベル6として人に教えることができる、という定義をしています。
一方で、人に教えること自体に対して得意や苦手があると思っています。なので、レベル5とレベル6は正確には上下関係にあるわけではなく、レベル6は少し方向が違う部分もあります。ここでは分かりやすさのためにあえてレベル分けをしていますがレベル5よりレベル6の方が優れているというイメージではありません。
また、そこまで複雑なSQLは書けず、基本的な集計であればSQLを使える人がそのレベルを他の人に教えることも十分可能ですし、それはそれで十分意味のあることだと思います。例えばレベル4の人がレベル4の内容を他の人に教えることもできますし、それもとても大切なことだと思います。その意味でもレベル5,6は明確な上下関係があるわけではありません。
おわりに
今回はデータ分析に必要なSQLの6つのレベルについてまとめました。これはビジネスパーソンはSQLを学ぶ必要はないとか、どこまで学ぶ必要があるのかとかその辺りの議論をする時の参考になればと思ってまとめました。
全てのビジネスパーソンがレベル4,5のように自分でSQLを書けるようになる必要性はないと思っています。ただし、繰り返しになりますが、個人的には全てのビジネスパーソンにSQLは学んで欲しいと思っています。その時のイメージとしてはレベル1,2のように概念としてのSQLやSQLを使って何ができるのか具体的なSQLの構文を「知る」ところまでは全てのビジネスパーソンが学んで損はないと思っています。その取り組みこそがビジネスパーソン全体のデータリテラシーの向上やデータ活用のレベルアップにつながると思っているからです。
マーケター、営業、プロダクトマネージャーのように欲しいときに欲しいデータが自分で取得できると効率が良い場面は多々あります。そういった職種の方はレベル3,4までSQLのスキルが身につけられると一定業務でも役に立つと思います。
これからSQLを学習したい人は自分がどのレベルまで目指すのかをイメージしながら学習を進めていけると良いなと思います。もしデータ分析で使うSQLを本気で学びたい方がいれば全力でサポートしますのでぜひご連絡ください！