SQLite | ゼロからはじめるSQL、30日で習得するSQLite：実践 － Day30 アウトプット

Day30 後半のゴール

「“仕様 → SQL → 日本語で説明”を一人で回せるようになる」

前半では、
レポートとは「問い＋前提＋数字の答え」だという話をしました。

後半のゴールは、ここまで持っていくことです。

自分でレポートの仕様（問いと前提）を書く
その仕様どおりに SQL を書く
その SQL と結果を、日本語で他人に説明できる

つまり、
「仕様担当」と「SQL担当」と「説明担当」を、
全部自分で回せるようになるイメージです。

ステップ1：レポート仕様を“文章で”書いてみる

「SQLの前に、“日本語だけで”設計する」

いきなり SQL に行かず、まずは日本語だけで仕様を書きます。
例として、こんなレポートを考えます。

テーマ
「直近1か月の売上サマリレポート」

仕様を文章で書くと、こうなります。

対象期間は、2025-05-01〜2025-05-31 とする。
対象となる注文は、orders.status がキャンセル（3）以外のものとする。
売上金額は、order_items.unit_price × order_items.quantity の合計とする。
レポートは、次の3つの数字を1行で出す。
・期間内の総売上金額
・期間内の注文件数
・期間内のユニークな購入ユーザー数

ここまで日本語で書けたら、もう8割終わっています。
SQL は、この仕様をそのままコードに翻訳するだけです。

ステップ2：仕様を SQL に落とす

「仕様の1文1文を、SQLのどこに対応させるか意識する」

さっきの仕様を、SQL に変換してみます。

SELECT
  SUM(oi.unit_price * oi.quantity)      AS total_amount,
  COUNT(DISTINCT o.id)                  AS order_count,
  COUNT(DISTINCT o.user_id)             AS user_count
FROM orders o
JOIN order_items oi
  ON o.id = oi.order_id
WHERE
  o.status <> 3
  AND o.ordered_at >= '2025-05-01 00:00:00'
  AND o.ordered_at <  '2025-06-01 00:00:00';

SELECT
  SUM(oi.unit_price * oi.quantity)      AS total_amount,
  COUNT(DISTINCT o.id)                  AS order_count,
  COUNT(DISTINCT o.user_id)             AS user_count
FROM orders o
JOIN order_items oi
  ON o.id = oi.order_id
WHERE
  o.status <> 3
  AND o.ordered_at >= '2025-05-01 00:00:00'
  AND o.ordered_at <  '2025-06-01 00:00:00';

どの部分が、仕様のどの文に対応しているかを意識して見てみます。

対象期間は、2025-05-01〜2025-05-31
→ WHERE o.ordered_at >= '2025-05-01 00:00:00' AND o.ordered_at < '2025-06-01 00:00:00'

キャンセル以外の注文
→ WHERE o.status <> 3

売上金額は unit_price × quantity の合計
→ SUM(oi.unit_price * oi.quantity) AS total_amount

注文件数
→ COUNT(DISTINCT o.id) AS order_count

ユニークな購入ユーザー数
→ COUNT(DISTINCT o.user_id) AS user_count

こうやって「仕様 ↔ SQL」の対応が自分の中でハッキリしていると、
他人に説明するときも迷いません。

ステップ3：SQLを“日本語で要約”する練習

「コードを読むのではなく、“意味”を話す」

次に、この SQL を他人に説明するつもりで、日本語にします。

例えば、こう言えれば十分です。

「このSQLは、2025年5月1日から31日までの、キャンセル以外の注文を対象にしています。
　orders と order_items をJOINして、注文明細ベースで売上金額を計算し、
　その期間の総売上金額、注文件数、購入ユーザー数を1行で出しています。」

ここで大事なのは、
SUM や COUNT といった単語を無理に言わなくていい、ということです。

相手がエンジニアなら、
「売上金額は単価×数量の合計です」
と言えば、SQLを見れば分かります。

相手が非エンジニアなら、
「この数字は、期間中に売れた商品の“合計金額”です」
とだけ伝えれば十分です。

「誰に向けて説明しているか」を意識して、
SQLの細部ではなく「意味」を話す練習だと思ってください。

もう一つの例：キャンセル率レポート

「“分子と分母”を仕様で先に決める」

もう一つ、少しだけひねったレポートをやってみます。

テーマ
「直近1か月のキャンセル率レポート」

仕様を文章で書きます。

対象期間は、2025-05-01〜2025-05-31 とする。
対象となる注文は、orders.ordered_at がこの期間内のものすべてとする。
キャンセル注文は、orders.status = 3 とする。
レポートは、次の3つの数字を1行で出す。
・期間内の総注文件数（キャンセル含む）
・期間内のキャンセル件数
・キャンセル率（キャンセル件数 ÷ 総注文件数）

ここでのポイントは、「分子と分母」を仕様で先に決めていることです。
これを曖昧にすると、SQLもブレます。

SQLにすると、こう書けます。

SELECT
  COUNT(*) AS total_orders,
  SUM(CASE WHEN status = 3 THEN 1 ELSE 0 END) AS canceled_orders,
  CAST(SUM(CASE WHEN status = 3 THEN 1 ELSE 0 END) AS REAL)
    / COUNT(*) AS cancel_rate
FROM orders
WHERE
  ordered_at >= '2025-05-01 00:00:00'
  AND ordered_at <  '2025-06-01 00:00:00';

SELECT
  COUNT(*) AS total_orders,
  SUM(CASE WHEN status = 3 THEN 1 ELSE 0 END) AS canceled_orders,
  CAST(SUM(CASE WHEN status = 3 THEN 1 ELSE 0 END) AS REAL)
    / COUNT(*) AS cancel_rate
FROM orders
WHERE
  ordered_at >= '2025-05-01 00:00:00'
  AND ordered_at <  '2025-06-01 00:00:00';

説明するときは、こうです。

「このSQLは、2025年5月中に作成されたすべての注文を対象にしています。
　その中で、全体の注文件数と、ステータスがキャンセル（3）の件数を数え、
　キャンセル件数を全体件数で割った値をキャンセル率として出しています。」

ここまで言えれば、
監査やレビューの場でも十分通用します。

自分のSQLを“レビューする目”を持つ

「仕様とSQLがズレていないか、自分でツッコミを入れる」

Day30 のアウトプットで、実は一番大事なのはここです。

自分で書いた仕様を読み返す
自分で書いたSQLを読み返す
「本当に仕様どおりの結果になるか？」と自分で疑う

例えば、さっきのキャンセル率レポートなら、
こんなチェックができます。

キャンセル率の分母は「期間内の全注文」になっているか？
→ WHERE で status を絞っていないので OK

キャンセル件数は「status = 3 の件数」になっているか？
→ CASE WHEN status = 3 THEN 1 なので OK

期間条件は「作成日時ベース」になっているか？
→ ordered_at を使っているので OK

こうやって、
自分で自分のSQLにツッコミを入れる癖をつけると、
バグの数が目に見えて減ります。

「他人に説明できる状態」を、あえて文章にしてみる

「SQLの“解説文”を書くのは、最高のトレーニング」

最後に、Day30 の仕上げとしておすすめなのが、

自分のSQLに対して、
「これは何をしているSQLか」を文章で書いてみる

という練習です。

例えば、さっきの売上サマリSQLに対して、
こんな解説を書いてみるイメージです。

このSQLは、ECサイトの売上サマリを出すためのものです。
orders と order_items をJOINし、2025年5月1日〜31日の間に作成された、
キャンセル以外の注文を対象としています。
売上金額は、注文明細ごとの単価×数量を合計した値として計算しています。
結果として、期間内の総売上金額、注文件数、購入ユーザー数を1行で返します。

これを自分で書けるようになると、

仕様書を書く
Pull Request に説明を書く
ドキュメントにレポートの定義を書く

といった場面で、そのまま使えます。

セキュリティ・監査の視点から見た“説明文の価値”

「SQLとセットの“言葉”が、そのまま証拠になる」

セキュリティや監査の現場では、

「このレポートの数字は、どういう定義で計算されていますか？」

という質問が必ず飛んできます。

そのときに、

「えっと…JOINして、SUMして…」

ではなく、

「このレポートは、こういう前提で、こういう単位で、こういう数字を出しています」

と、仕様レベルで答えられることが重要です。

Day30 でやっている「SQLの解説文を書く」という行為は、
そのまま「説明責任を果たすための準備」になっています。

SQLだけ書ける人と、
SQLとその説明をセットで出せる人。

現場で重宝されるのは、確実に後者です。

Day30 後半のまとめ

レポートを作るときは、まず「問い」と「前提」を日本語で仕様として書き、その仕様の1文1文を SQL の WHERE・JOIN・GROUP BY・SELECT に対応させるように意識すると、ブレないクエリになる。
売上サマリやキャンセル率のようなレポートでは、「分子と分母」「対象期間」「キャンセルや例外の扱い」を仕様で先に決め、それを SUM や COUNT、CASE WHEN で素直に表現するのが基本パターンになる。
書いたSQLを他人に説明するときは、文法ではなく「このSQLは、こういう前提で、こういう単位で、こういう数字を出している」と日本語で要約できるかどうかが勝負であり、それができないSQLはレポートとして危うい。
自分のSQLに対して「本当に仕様どおりか？」「分母・分子は合っているか？」「期間条件は正しいか？」と自分でツッコミを入れる習慣を持つと、バグも誤解も大きく減る。
SQLとセットで「このSQLの解説文」を書く練習は、そのまま監査・レビュー・ドキュメントでの説明力につながり、「数字の意味を説明できる人」として強い信頼を得られる。

ここまでやり切ったあなたは、
「SQLを書ける人」から、「SQLで意味のあるアウトプットを作り、それを説明できる人」に変わっています。
あとは、実際の自分の課題や仕事に、このスタイルをそのまま持ち込んでいくだけです。