分析ワークフロー: 問いからSQL、可視化、改善まで

Stage 5 — 第5章 | データ分析基礎カリキュラム 推定学習時間：30〜40分 | 難易度：★★★☆☆

この章で学ぶこと

SQLを書けるようになることは重要ですが、実務の分析はSQLだけで完結しません。 問いを決め、データを確認し、SQLで集計し、可視化し、改善につなげる流れが必要です。

この章では、実務の入口としての 分析ワークフロー を学びます。

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

• 分析の流れを手順で説明できる
• 問いをSQLに落とし込む考え方を理解できる
• 集計結果を可視化や改善案につなげられる
• 分析時に記録すべき情報を整理できる

1. 分析は問いから始まる

よい分析は、よい問いから始まります。 たとえば「売上が下がった理由を知りたい」という問いは、まだ少し広すぎます。

次のように分解すると、SQLに落とし込みやすくなります。

問いを具体化すると、必要なテーブルと指標が見えてきます。

2. 分析依頼を受けたときの整理メモ

実務では、「売上を見て」「ユーザーの動きを見て」のように、依頼が曖昧な状態で届くことがあります。 そのままSQLを書くと、依頼者の知りたいことと違う集計になることがあります。

まず、次のようなメモに整理します。

このメモがあると、SQLの目的が明確になります。 分析は「数字を出す作業」ではなく、「判断に必要な数字を定義する作業」から始まります。

3. データを確認する

SQLを書く前に、対象データを確認します。

SELECT
            order_id,
            customer_id,
            order_date,
            status,
            total_amount
          FROM orders
          ORDER BY order_date DESC
          LIMIT 10;
          

ステータスの種類も確認します。

SELECT
            status,
            COUNT(*) AS order_count
          FROM orders
          GROUP BY status
          ORDER BY order_count DESC;
          

いきなり最終集計を書くのではなく、まず列、値、件数、欠損を確認します。 この作業で、指標定義や除外条件の抜けに気づけます。

4. SQLで集計する

問いが「月別に売上が下がったか」を見るものなら、月別売上を集計します。

SELECT
            DATE_TRUNC('month', order_date) AS order_month,
            COUNT(*) AS order_count,
            COUNT(DISTINCT customer_id) AS purchasing_customers,
            SUM(total_amount) AS sales,
            AVG(total_amount) AS average_order_amount
          FROM orders
          WHERE status = 'completed'
          GROUP BY DATE_TRUNC('month', order_date)
          ORDER BY order_month;
          

この結果から、売上低下が注文件数の減少なのか、平均注文金額の低下なのかを見ます。 必要に応じて、商品カテゴリや都道府県でさらに分解します。

5. 可視化して伝える

集計結果は、表だけでなくグラフにすると伝わりやすくなります。

可視化では、見た人が次の判断をしやすいようにします。 「売上が落ちています」だけでなく、「どの月から、どのカテゴリで落ちているか」を示します。

6. 改善につなげる

分析の最後は、改善アクションにつなげることです。 たとえば、カテゴリ別に売上を確認します。

SELECT
            p.category,
            SUM(oi.quantity * oi.unit_price) AS sales,
            SUM(oi.quantity) AS quantity_sold
          FROM order_items AS oi
          JOIN products AS p
            ON oi.product_id = p.product_id
          GROUP BY p.category
          ORDER BY sales DESC;
          

もし特定カテゴリの販売数量が下がっていれば、在庫、価格、広告、商品ページなどを確認します。 SQLは答えを断定するものではなく、次に確認すべき仮説を作るための道具です。

7. 分析メモを残す

実務では、分析結果だけでなく、前提も残します。

メモを残すことで、後から同じ分析を再現しやすくなります。

8. 成果物を出す前のチェックリスト

SQLの結果を共有する前に、次の点を確認しましょう。

このチェックを入れるだけで、分析の信頼性はかなり上がります。 特に、比率を出したときは分母の件数を必ず確認しましょう。

ミニ演習

次の依頼を、分析メモに分解してみましょう。

最近、売上が落ちている気がするので原因を見たい。

考える項目は次の通りです。

1. どの期間を対象にするか。
2. 売上をどう定義するか。
3. まず見るべき指標は何か。
4. どの軸で分解すると原因に近づけるか。
5. SQLの結果をどのグラフで見せると伝わりやすいか。

この演習は、SQLを書く前の設計力を鍛えるためのものです。 実務では、この設計ができているほど、SQLの修正回数が減ります。

まとめ

この章のキーメッセージ： 分析は、問いから始まり、SQL、可視化、改善へ進む一連の流れです。SQLはその中心にありますが、前提の確認と意思決定への接続まで含めて実務の分析です。

この章の確認

1. 分析を始める前に問いを具体化する理由を説明してください。
2. SQLを書く前に確認すべきデータの状態を2つ挙げてください。
3. 月別売上を見るとき、売上以外に一緒に見るとよい指標は何ですか？
4. 分析メモに残すべき情報を3つ挙げてください。

関連演習

• SQL基礎（SELECTとフィルタリング）
• SQL集計（GROUP BY）
• SQL結合の基礎
• データ可視化リテラシー