Excel情報整理術の実践手引き
～設計思考と教育導入による現場実装の手引き～
Copyright © 2025 LWP 山中 一弘 本資料は、出典を明記いただければ、商用・非商用を問わず、ご自由に複製・改変・再配布していただけます。なお、著作権表示は改変せず、そのまま記載してご利用くださいますようお願いいたします。
【要約】
本記事では、『Excel情報整理術』の理論をどのように実戦へと落とし込むかを体系化する。その鍵となるのは、操作スキルの強化ではなく、構造的な発想の獲得であり、最も効果的な導入手段がSQLとRDBの基礎研修である。
リレーショナルデータベースの設計思想を理解することにより、項目と記録の区別、IDによる一意管理、再利用可能な構造の構築といったExcelの実戦的設計力が飛躍的に高まる。
本記事では、業務ファイルの再設計、教育への落とし込み、組織的な整備の3軸で構造的実践法を提示し、「見た目ではなく構造を整える」文化を定着させる方法を論じる。
第1章 実戦の鍵は「構造的思考」である
1.1 実務で情報整理術が定着しない理由
Excelの操作を習得しても、情報整理術が業務に定着しない主な理由は「構造的思考」の不足にある。多くの業務ユーザーは「表を作ること＝Excelを使うこと」と誤解し、見た目の整備や関数の小技に終始してしまう。これにより、ファイルが肥大化し、属人化し、再利用も共有も難しくなる。
また、既存のテンプレートや雛形をそのまま使い回す文化が、構造を考え直す機会を奪っている。したがって、情報整理の定着には、まず業務の中でデータを「構造」としてとらえる意識改革が必要である。
1.2 Excelの問題は“道具”ではなく“構造”にある
Excelは高度なツールであるが、構造的に設計されていない表やシートを量産すると、逆に作業の非効率やミスを誘発する。たとえば、結合セルや見た目重視のレイアウト、セルの使い回しなどは、データの一貫性や処理の自動化を著しく阻害する。
本質的な問題は「Excelが使われていること」ではなく、「構造を持たずに使われていること」にある。構造を持たない表は、どれほど関数を駆使しても破綻する。構造を備えた設計に変えることが、Excelの可能性を引き出す第一歩である。
1.3 SQLとRDB研修こそが最短の導入手段である
構造的思考を身につけるためには、SQLとRDBの初級研修が極めて効果的である。特に「行＝記録」「列＝項目」という基本構造、主キーによる一意管理、リレーションによる分割設計などは、そのままExcelに応用可能である。
Excelしか使ってこなかった人でも、SQLのSELECT文やRDBのテーブル設計を学ぶことで、「構造を持って情報を整理する」という観点を獲得できる。これは単なる操作テクニックではなく、設計思想の導入であり、Excel情報整理術を定着させる最短ルートである。
1.4 リスト構造と設計思考の基礎力がExcelを変える
リストとは、一定のルールで整形された「表形式データ」のことであり、これを正しく設計・運用する力がExcelの実力を左右する。各列には意味を持った項目名が必要であり、各行は独立した記録として定義されるべきである。
このようなリスト構造を意識した設計を繰り返すことで、「どのように整理すれば再利用できるか」「関数や集計をどう適用すれば破綻しないか」といった実践的な判断力が養われる。設計思考とは、情報の流れと構造を意識してファイルを構築する力であり、それはExcelの最も根幹的なスキルである。
第2章 業務ファイルを構造的に再設計する
2.1 「まず壊す」ことから始める再設計
既存の業務ファイルには、多くの不要な装飾や非構造的な情報が含まれている。それらを「いま動いているから」という理由で温存したままでは、改善は望めない。まず既存のファイルを「壊す」こと、すなわち構造を見直すために分解・再分析することから始めなければならない。
見た目を真似るのではなく、情報の流れや粒度を可視化し、何を記録し、どう使われるべきかを問い直すことで、根本的な再設計が可能となる。
2.2 入力・加工・出力の三層を明示的に分離する
Excel業務では、入力用シート、計算用シート、出力・閲覧用シートが混在していることが多い。この三者を明示的に分け、物理的にも別シートにすることで、構造の明確化と保守性の向上が実現される。
入力層では構造を厳密に守り、加工層では数式の正確性と可読性を担保し、出力層では利用者の視認性を考慮した体裁を整える。この三層構造が、業務Excelにおける基本設計単位となる。
2.3 マスタ／トランザクションの表構造を分ける
「マスタ」と「トランザクション」は、RDB設計における基本概念である。Excelでもこの区別を導入することで、データの整合性と管理性が飛躍的に高まる。マスタは定義情報であり、トランザクションは発生記録である。
この分離により、冗長な入力を避け、データの重複や整合性の崩壊を防ぐことができる。たとえば「商品一覧」と「売上記録」を別管理し、売上は商品IDで管理する構造にすると、拡張や集計が容易になる。
2.4 ID管理と正規化の初歩をExcelに持ち込む
Excelでも、IDによる一意管理と、カラムの役割ごとに情報を分割する正規化の考え方を導入することで、ファイルの再利用性や拡張性が大きく向上する。IDは数値や記号でもよく、重複がないことが重要である。
一方、正規化とは、1つの列に複数の意味や単位を混在させないという設計原則であり、これをExcelに持ち込むことで、関数の適用や集計のミスを防ぐことができる。
2.5 テンプレート依存から脱却し再利用性を高める
社内や業界のテンプレートに過剰に依存することは、構造設計を妨げる大きな要因である。テンプレートは参考にしてもよいが、あくまで設計の出発点であり、業務に応じた最適な構造へとカスタマイズする必要がある。
構造の明確なExcelファイルは、異なる担当者間での共有や他業務への転用が容易になり、業務の属人性を低下させる。テンプレート依存から脱却し、「自分で構造を設計する力」を育てることが、再利用性を高める鍵となる。
第3章 教育としてのExcel情報整理研修
3.1 「操作」ではなく「構造」を教える研修へ
多くのExcel研修は操作手順や関数の使い方に偏っているが、業務改善に真に必要なのは「構造の設計力」である。操作スキルだけでは属人的な利用にとどまり、再利用性やチーム運用に結びつかない。
研修の焦点を「構造」に移すことで、どのような情報を、どのように整理すれば意味あるデータになるのかを理解させることができる。これは設計思想の教育であり、長期的に業務の質を変える。
3.2 初学者に伝えるべき3原則（列＝項目、行＝記録、セル＝単一情報）
Excelを学ぶ初学者には、最初に「列＝項目」「行＝記録」「セル＝単一情報」という3つの原則を明確に伝える必要がある。これを曖昧にしたまま操作を教えても、構造的な表を作る力は身につかない。
列と行の意味が理解されていれば、複雑な操作に頼らずとも整理された情報が作れるようになる。これらの原則はRDBと共通しており、Excelからデータベース思考へとつなぐ基礎となる。
3.3 テンプレートを“崩す”演習から始める設計訓練
ありがちな表形式テンプレートを提示し、それをいったん「壊して」再設計させる演習は非常に効果的である。既存の構造を盲信するのではなく、「何が悪くて、どう改善できるか」を考えることで、受講者の設計的思考が鍛えられる。
固定観念を取り払うこの訓練により、自ら設計する力を育て、テンプレート依存から脱却するきっかけを与える。
3.4 入力者・管理者・活用者で切り分ける指導設計
Excelファイルの利用者は、単一ではなく多様な役割を持つ。入力者、管理者、活用者という三者の立場を切り分け、それぞれに必要な構造や使い方を指導することが、実務での応用力を高める。
たとえば、入力者には「構造を壊さない入力方法」、管理者には「構造の保守と変更管理」、活用者には「構造に沿った分析と抽出技法」を教えるなど、役割別の指導は不可欠である。
3.5 「構造→関数→自動化」の順序を徹底する教育構成
多くの研修では関数やマクロが先行して教えられるが、それでは本質的な再利用性や拡張性が育たない。教育構成としては「構造→関数→自動化」の順序が原則である。
まず構造を整えることが最優先であり、その上で関数を適用し、さらに自動化を実現する。この順序を守ることで、複雑な処理も破綻なく実装でき、業務への応用力が飛躍的に向上する。
第4章 再利用とチーム運用のためのExcel設計ルール
4.1 ファイル命名・範囲名・シート配置の統一原則
チームでExcelファイルを運用する際には、「構造」だけでなく「見つけやすさ」「理解しやすさ」「引き継ぎやすさ」が重要である。そのためには、ファイル名・範囲名・シート構成などの命名規則を組織として統一する必要がある。
たとえば、日付や部門名、バージョンを含む命名ルール、名前付き範囲の接頭語の統一、シートの物理配置（入力→集計→出力）の順序化などにより、誰が開いても意図が読める構成を実現できる。
4.2 バージョン管理と操作履歴の整備
ファイルが更新されるたびに差分が不明瞭なまま上書きされると、問題の追跡や復元が困難になる。これを防ぐには、バージョン管理（手動でも構わない）と操作履歴の記録が欠かせない。
ファイル名にv1.0などの形式で変更履歴を残す、または履歴専用シートを用意して日付・担当者・変更点を記録することで、透明性が高まり、他者との共同作業やレビューも円滑に進む。
4.3 コメント、注釈、説明シートによる“使い方の設計”
設計されたExcelファイルは、それ自体が一種の「ソフトウェア」としての性質を持つ。その使用方法を明示することは、設計の一部である。各セルや列に対するコメント、数式に対する注釈、そして使い方全体を記した説明シートの導入が重要となる。
これにより、初見のユーザーでもファイルの構造や目的を理解しやすくなり、利用者の拡大や属人化の防止につながる。
4.4 構造化されたExcelファイルを“情報資産”とするために
構造化されたExcelファイルは、単なる道具ではなく「資産」として位置づけるべきである。明確な設計意図を持ち、再利用と共有を前提に作られたファイルは、教育・ナレッジ蓄積・業務改善の基盤となる。
そのためには、誰が使っても壊れず、変更しても意味構造が崩れず、複数人が関与できる余地を設計段階から組み込む必要がある。「個人の道具から、組織の資産へ」という転換が、チームExcel運用の最終到達点である。
第5章 構造設計の文化を組織に定着させる
5.1 表の見た目優先文化をどう変えるか
多くの現場でExcelファイルは「美しく整った見た目」が評価されがちであり、構造の正しさや再利用性は後回しにされる。これを変えるには、「整った構造こそが業務効率を左右する」という認識を組織内に浸透させる必要がある。
見た目を整える前に、入力構造・関数適用・集計方法が明示されているかをチェックする運用に切り替えることが有効である。構造的な整備がされたファイルは後から体裁を整えやすく、結果として見た目も破綻しないという事実を周知することが第一歩となる。
5.2 全社ルールと現場の裁量を両立させる仕組み
組織としてのExcel設計方針を策定する際には、すべてを一律に定めるのではなく、「共通ルール」と「現場裁量」の二層構造で管理する必要がある。
たとえば、ファイル命名規則やID管理の有無、マスタの配置ルールなどは全社共通としつつ、帳票の見せ方や個別業務の細部は現場に任せる。ガイドラインを文書化し、例外の許容範囲を明確にすることで、秩序と柔軟性の両立が可能となる。
5.3 マスタ共有と構造連携による部門間の再設計
部門ごとに独自のExcelファイルを運用していると、同一情報が複数ファイルに分散し、更新漏れや整合性の欠如を招く。これを防ぐには、共通マスタの導入と部門間連携を前提とした構造設計が不可欠である。
たとえば、社員マスタ・商品マスタ・顧客マスタなどを中央管理し、各部門はそれを参照する構造とすることで、データの重複を排除しつつ全体最適を実現できる。これは、Excelを超えて情報資源の管理体制を整備する足掛かりにもなる。この用途にはパワークエリの全社的採用を強く推奨する。
5.4 小さく始めて広げる：成功事例から始まる文化変革
構造的なExcel設計を組織に定着させるには、小規模な成功体験の積み重ねが有効である。最初から全社導入を目指すのではなく、一部のチームやプロジェクトで構造的再設計を実施し、その成果を見える化することが重要となる。
実際に「見やすくなった」「属人性が下がった」「集計が早くなった」といった実感が共有されれば、他チームへと波及していく。教育・事例共有・社内勉強会などを通じて、構造設計の意義が組織全体に広がる流れを作ることが、文化定着の鍵である。
第6章 Excelのために学ぶSQLとRDBの基礎
6.1 Excelでは構造が壊れやすい
Excelは非常に柔軟なツールであり、どのセルにも自由に値を入力できる。しかしその自由度ゆえに、表としての「構造」が保たれにくいという根本的な問題を抱えている。たとえば、見出し行が途中で挿入されていたり、結合セルが複数行にまたがっていたり、同じ列に数値と文字列が混在している場合、それは人間には理解できても、機械や関数には正しく処理できない。
構造が壊れているとは、すなわち「1つの行が1つの記録になっていない」「1つの列が1つの項目として定義されていない」状態を指す。このような状態では、関数による集計、フィルタ、検索、さらには再利用や外部連携が極めて困難になる。
業務ファイルが属人化する主因も、このような構造の崩壊にある。見た目には整っているように見えても、構造的には壊れているケースが多く、これは“道具の問題”ではなく“設計の問題”である。
6.2 RDBとは何か──構造を保つ仕組み
RDB（リレーショナル・データベース）は、「行と列の構造を厳密に定義すること」によって、情報の一貫性と整合性を保つ仕組みである。Excelが自由に入力できるキャンバスであるのに対して、RDBでは表（テーブル）を作成する際に、列の名前、型、制約などを明示的に定義することが求められる。
その基本構造は次のようにSQL文で定義される。
CREATE TABLE 顧客 (
顧客ID INTEGER PRIMARY KEY,
氏名 TEXT NOT NULL,
メール TEXT,
登録日 DATE
);
上記の定義では、「顧客ID」が重複してはならず、かつ必須である（PRIMARY KEY）。「氏名」も必須である（NOT NULL）。このように、どの列に何が入るか、どの列をキーにするかを最初に設計することで、後から構造が壊れるのを防いでいる。
RDBは構造が崩壊しないよう「最初に設計を固定する」ことを前提とし、また、データの整合性（重複排除・一貫性保持）を内部的に保証する仕組みを備えている。
ExcelとRDBの最大の違いは、「構造の設計が先にあるかどうか」に集約される。
6.3 「列＝項目」「行＝記録」の意味とExcelとの違い
RDBでは、各列（カラム）は「項目」、各行（レコード）は「記録」を意味する。この構造を厳密に守ることで、表全体が意味のある情報集合として機能する。たとえば、次のようなテーブルを考える。
SELECT * FROM 売上;
| 売上ID | 商品ID | 数量 | 単価 | 日付 |
|--------|--------|------|------|------------|
| 1001 | A123 | 3 | 500 | 2025-06-15 |
| 1002 | B234 | 1 | 1200 | 2025-06-15 |
この表において、各列は「売上ID」「商品ID」「数量」「単価」「日付」という**意味の明確な属性（項目）**であり、各行はそれぞれの売上記録を表している。この「列＝項目」「行＝記録」という原則が守られている限り、データの分析や抽出、更新が一貫して可能である。
一方、Excelでは列や行の意味を明示的に定義する手段がないため、曖昧な列名、複数の見出し行、1セルに複数項目が混在するといった構造的崩壊が発生しやすい。例えば「日付（午前・午後）」「金額（税抜・税込）」などのように、複数の意味を1つの列に持たせる設計は、RDB的には構造違反である。
したがって、Excelをデータ処理ツールとして活用するには、この「列＝項目」「行＝記録」の原則をRDBから借りてくる必要がある。RDBの構造的原則は、Excelのファイル設計にもそのまま適用可能である。
6.4 データの粒度とセルの分解
データの「粒度」とは、どの程度の細かさで情報を分割・記録しているかを表す概念である。Excelでは、1セルに複数の情報を入れてしまいがちであり、たとえば「2025年6月15日 10:30」や「山田太郎（営業部）」などのように、1つのセルが複数の要素を含んでいると処理が困難になる。
構造的に処理するには、これらの複合情報を分解し、それぞれ「日付」「時間」「氏名」「所属部門」などに分割する必要がある。粒度を統一し、セル1つが1つの意味しか持たないように設計することで、検索、集計、フィルタ、VLOOKUPなどの関数適用が安定化する。
6.5 ハンズオン：1セル1項目の原則で表を再構成する
この演習では、次のような非構造的な表を構造的に再構成する。
元のデータ（悪い例）：
顧客情報 購入日・時間
田中一郎（営業部） 2025年6月15日 10:30
山田花子（開発部） 2025年6月15日 11:00
再構成後（良い例）：
氏名 所属 購入日 購入時間
田中一郎 営業部 2025/06/15 10:30
山田花子 開発部 2025/06/15 11:00
このように「1セル＝1項目」の原則に従って再構成することで、以降のデータ処理が容易になる。
6.6 行の意味を明確化する
行は「1つの記録」として定義される必要がある。たとえば、「2025年度売上」という1つの表が、商品ごと・月ごとの複数行にまたがっているようなケースでは、1行が1記録であるという原則が破られている。
行の意味を明確にするためには、「その行が表す実体は何か」を常に問う必要がある。売上であれば「1回の販売記録」、社員情報であれば「1人の社員」といった具合に、行の単位と現実の単位を一致させる必要がある。
6.7 ハンズオン：複数行に渡る情報を1行＝1記録に再編成
元のデータ（悪い例）：
商品名 1月売上 2月売上 3月売上
商品A 1000円 1200円 1500円
商品B 900円 800円 950円
再構成後（良い例）：
商品名 月 売上
商品A 1月 1000円
商品A 2月 1200円
商品A 3月 1500円
商品B 1月 900円
商品B 2月 800円
商品B 3月 950円
この形式では「1行＝1件の売上記録」が保証されるため、月別集計、商品別集計、フィルタやグラフなどが容易になる。
6.8 列の意味を定義する
列には明確な「項目名」と「データ型」が必要である。たとえば「担当」や「状況」といった曖昧な列名では、データの意味が理解しづらくなる。また、同じ列の中に「済」「未」「保留（理由A）」など、意味の異なる情報を混在させることも好ましくない。
列の設計時には「この列にはどんな値が入るのか」「この列は何を意味しているのか」を明確に定義し、関係者間で共有することが重要である。
6.9 ハンズオン：曖昧な列名を整理し、意味を明示する
元のデータ（悪い例）：
名前 担当 状況
鈴木一郎 A班 済
田中花子 B班 保留（理由A）
再構成後（良い例）：
氏名 担当班 ステータス 保留理由
鈴木一郎 A班 済 （空）
田中花子 B班 保留 理由A
このように、列名を具体化し、1列＝1項目に再設計することで、構造の明瞭さと拡張性が大きく向上する。
6.10 ID管理と主キーの基本
構造的なデータ設計では、「主キー（Primary Key）」によって各レコードを一意に識別する仕組みが重要である。Excelでは見落とされがちだが、名前や日付のような曖昧な情報ではなく、意図的に付与されたID（連番、コード、UUIDなど）を使って一意性を担保すべきである。
主キーは「重複しない」「空白にならない」ことが前提であり、この条件を満たさない列を主キーとして使うと、結合や検索、更新処理が破綻する。名前は重複し得るし、変更される可能性もあるため、識別子としては不適切である。
6.11 ハンズオン：名前ではなくIDで顧客を管理する表を作成
元のデータ（悪い例）：
顧客名 住所 電話番号
田中一郎 東京都渋谷区 03-1234-5678
山田花子 東京都中野区 03-9876-5432
再構成後（良い例）：
顧客ID 顧客名 住所 電話番号
C001 田中一郎 東京都渋谷区 03-1234-5678
C002 山田花子 東京都中野区 03-9876-5432
IDを導入することで、データベース的な処理（結合、集計、検索など）が安定し、名前変更などによる参照の破綻も防げる。
6.12 マスタ／トランザクションの分離
「マスタ（Master）」とは、定義情報や固定情報を格納する表である。たとえば「顧客マスタ」「商品マスタ」「部署マスタ」などが該当する。一方、「トランザクション（Transaction）」とは、日々発生する変動的な記録を意味し、たとえば「売上履歴」「受注履歴」「出勤記録」などが該当する。
両者を混在させると構造が壊れやすく、集計や更新時にミスを誘発する。マスタは更新頻度が低く、トランザクションは記録単位が小さいため、分けて管理することでExcelの処理効率と構造の透明性が高まる。
6.13 ハンズオン：商品マスタと売上トランザクション表を分離
元のデータ（悪い例）：
商品名 単価 売上日 数量
りんご 100 2025/06/10 3
みかん 120 2025/06/11 5
再構成後のマスタ表：
商品ID 商品名 単価
P001 りんご 100
P002 みかん 120
再構成後のトランザクション表：
売上ID 商品ID 売上日 数量
S001 P001 2025/06/10 3
S002 P002 2025/06/11 5
このように表を分離することで、単価の変更や商品名の修正がトランザクションに波及せず、一貫性を保った運用が可能となる。
6.14 参照の仕組みと外部キーの意味
外部キー（Foreign Key）とは、他の表の主キーを参照する列である。これにより、マスタとトランザクションの間に「構造的なつながり（リレーション）」を構築することができる。
たとえば売上表の「商品ID」が商品マスタの主キー「商品ID」を参照する場合、この接続が外部キーに該当する。Excelでは明示的な外部キー設定はできないが、運用上「主キーを他表で使う」という設計を徹底すれば、同様の構造が再現できる。
6.15 ハンズオン：売上表に外部キーとして商品IDを設定する
この演習では、前節のマスタとトランザクションの再構成結果を利用し、売上表で「商品名」ではなく「商品ID」を使って記録するように構造を変更する。
売上トランザクション表（変更前）：
売上日 商品名 数量
2025/06/10 りんご 3
2025/06/11 みかん 5
変更後（外部キーを導入）：
売上日 商品ID 数量
2025/06/10 P001 3
2025/06/11 P002 5
このように外部キーを導入することで、商品名の誤記、重複、変更といった問題に強い、堅牢なデータ構造が実現できる。
6.16 SQLの基本構文（SELECT, FROM, WHERE）
SQLの最も基本的な構文は、以下の3つの要素から成る。
SELECT：取得したい列（項目）を指定する
FROM：対象とする表（テーブル）を指定する
WHERE：条件を指定し、該当する行のみを抽出する
これにより、必要な情報だけを対象の表から取り出すことができる。たとえば、売上テーブルから「2025年6月10日」の売上だけを取得するには次のように記述する。
SELECT * FROM 売上
WHERE 売上日 = '2025-06-10';
* はすべての列を意味し、WHERE 句で日付条件を指定している。
6.17 ハンズオン：SQLiteでデータ抽出クエリを実行
以下のような売上テーブルがあるとする。
売上テーブル
+--------+----------+------------+--------+
| 売上ID | 商品ID | 売上日 | 数量 |
+--------+----------+------------+--------+
| S001 | P001 | 2025-06-10 | 3 |
| S002 | P002 | 2025-06-11 | 5 |
| S003 | P001 | 2025-06-11 | 2 |
+--------+----------+------------+--------+
このうち「商品IDがP001の売上のみ」を抽出するSQL文は以下のとおり。
SELECT 売上ID, 売上日, 数量
FROM 売上
WHERE 商品ID = 'P001';
SQLiteのツール（DB Browser for SQLite等）を使ってこのクエリを実行し、正しくデータが抽出されることを確認する。
6.18 並べ替えと抽出制限（ORDER BY, LIMIT）
抽出結果に並べ替えを加えたり、結果数を制限したりする場合には、次の構文を使う。
ORDER BY 列名 [ASC|DESC]：指定列で昇順（ASC）または降順（DESC）に並べ替え
LIMIT 数値：結果の行数を制限
たとえば、売上を数量の多い順に並べて5件だけ表示したい場合は次のようになる。
SELECT * FROM 売上
ORDER BY 数量 DESC
LIMIT 5;
6.19 ハンズオン：売上データを金額順に並べてTOP5を抽出
まず、以下のように売上データに「金額」列を仮想的に追加したとする（価格はマスタから参照済みと仮定）。
売上ビュー（結合済）
+--------+----------+--------+--------+--------+
| 売上ID | 商品名 | 単価 | 数量 | 金額 |
+--------+----------+--------+--------+--------+
| S001 | りんご | 100 | 3 | 300 |
| S002 | みかん | 120 | 5 | 600 |
| S003 | りんご | 100 | 2 | 200 |
+--------+----------+--------+--------+--------+
このデータを「金額」順に並べ、TOP5を抽出するSQLは以下のとおり。
SELECT 売上ID, 商品名, 金額
FROM 売上ビュー
ORDER BY 金額 DESC
LIMIT 5;
SQLiteで実行して並び順と件数を確認する。
6.20 計算列と演算（演算子とAS）
SQLでは列同士の演算や計算結果に名前を付けて抽出できる。これを「計算列」と呼び、以下のような構文で使う。
SELECT 数量 * 単価 AS 金額
FROM 売上;
ここで * は乗算、AS 金額 によって演算結果に「金額」という列名を与えている。他にも +, -, / などの算術演算子が使用できる。
6.21 ハンズオン：価格×数量で売上金額を算出する
以下の売上データを用いて「金額 = 単価 × 数量」を計算し、結果に列名を付けて出力する。
売上テーブル
+--------+--------+--------+
| 単価 | 数量 | |
+--------+--------+--------+
| 100 | 3 | |
| 120 | 5 | |
| 100 | 2 | |
+--------+--------+--------+
SQLクエリ：
SELECT 単価, 数量, 単価 * 数量 AS 金額
FROM 売上;
SQLiteでこのSQLを実行し、「金額」列が計算されて正しく表示されるか確認する。これにより、データの可視化と集計の自動化の一歩が実現される。
6.22 複数表の結合とJOINの考え方
リレーショナルデータベース（RDB）の大きな特徴は、複数の表を結合して1つの仮想的な表として扱える点にある。これはExcelの「VLOOKUP関数」や「XLOOKUP関数」のような機能に相当するが、JOINのほうが構造的で柔軟性が高い。
基本的な結合は JOIN 句で行われ、次のような形式で記述される。
SELECT 列名1, 列名2
FROM 表A
JOIN 表B ON 表A.列 = 表B.列;
ここで ON により結合条件（主キーと外部キーの一致）を指定する。これにより、別々の表に存在する情報を組み合わせた複合的な出力が可能となる。
6.23 ハンズオン：売上トランザクションと商品マスタをJOIN
以下の2つの表があるとする。
商品マスタ
+----------+----------+
| 商品ID | 商品名 |
+----------+----------+
| P001 | りんご |
| P002 | みかん |
+----------+----------+
売上トランザクション
+--------+----------+--------+
| 売上ID | 商品ID | 数量 |
+--------+----------+--------+
| S001 | P001 | 3 |
| S002 | P002 | 2 |
+--------+----------+--------+
この2表を「商品ID」で結合し、商品名付きの売上表を作成する。
SELECT 売上ID, 商品マスタ.商品名, 数量
FROM 売上トランザクション
JOIN 商品マスタ ON 売上トランザクション.商品ID = 商品マスタ.商品ID;
JOINの結果、売上ごとに商品名が付与された出力が得られる。SQLiteでこのクエリを実行して確認する。
6.24 INNER JOINとLEFT JOINの違い
INNER JOIN は「両方の表にデータが存在するものだけ」を結合対象とする。一方 LEFT JOIN は「左側の表（FROMで指定した側）のすべての行」を保持し、右側の表に該当データがない場合にはNULLとして出力する。
たとえば、商品マスタには存在するが売上がない商品も一覧したい場合には、LEFT JOIN を用いる。
SELECT 商品マスタ.商品ID, 商品名, 数量
FROM 商品マスタ
LEFT JOIN 売上トランザクション ON 商品マスタ.商品ID = 売上トランザクション.商品ID;
このクエリにより、売上の有無にかかわらず全商品が表示される。
6.25 ハンズオン：売上のない商品を含めて全件抽出（LEFT JOIN）
以下の表を用意する。
商品マスタ
+----------+----------+
| 商品ID | 商品名 |
+----------+----------+
| P001 | りんご |
| P002 | みかん |
| P003 | バナナ |
+----------+----------+
売上トランザクション
+--------+----------+--------+
| 売上ID | 商品ID | 数量 |
+--------+----------+--------+
| S001 | P001 | 3 |
| S002 | P002 | 2 |
+--------+----------+--------+
この状態で LEFT JOIN により、売上のない「バナナ（P003）」も含めて一覧表示する。
SELECT 商品マスタ.商品ID, 商品名, 数量
FROM 商品マスタ
LEFT JOIN 売上トランザクション
ON 商品マスタ.商品ID = 売上トランザクション.商品ID;
実行結果では、P003 の「数量」は NULL として表示される。これにより「売上のない商品」も一覧可能になる。実務では未販売商品の管理や販売促進対象の抽出に活用できる。
6.26 集計関数（COUNT, SUM, AVG）とGROUP BY
SQLでは、集計処理を行うための関数として COUNT（件数）、SUM（合計）、AVG（平均）などが提供されている。これらを GROUP BY 句と組み合わせることで、任意の項目単位で集計値を得ることができる。
基本構文は次のとおり。
SELECT グループ化する列, 集計関数(対象列)
FROM 表名
GROUP BY グループ化する列;
たとえば、月ごとの売上金額合計を集計したい場合には、日付から月を抽出し、それをキーとして SUM を適用する。
Excelでいうところの「ピボットテーブル」に近い処理であり、大量データを処理する際に極めて有効である。
6.27 ハンズオン：月別売上合計と商品別平均を集計する
以下の表を前提とする。
売上トランザクション
+--------+----------+------------+--------+--------+
| 売上ID | 商品ID | 売上日 | 単価 | 数量 |
+--------+----------+------------+--------+--------+
| S001 | P001 | 2024-01-10 | 100 | 2 |
| S002 | P002 | 2024-01-20 | 200 | 3 |
| S003 | P001 | 2024-02-05 | 100 | 1 |
+--------+----------+------------+--------+--------+
月別の売上合計を求めるには、次のようなクエリを実行する。
SELECT strftime('%Y-%m', 売上日) AS 売上月,
SUM(単価 * 数量) AS 月別売上合計
FROM 売上トランザクション
GROUP BY 売上月;
さらに、商品ごとの平均売上金額（単価×数量の平均）を求めるには次のようにする。
SELECT 商品ID,
AVG(単価 * 数量) AS 商品別平均売上
FROM 売上トランザクション
GROUP BY 商品ID;
6.28 HAVINGとフィルタリング集計
WHERE 句は集計前のデータに対する条件を指定するが、HAVING 句は GROUP BY による集計結果に対して条件を指定するために用いる。
たとえば「売上月ごとの合計金額が1万円以上の月のみ抽出したい」場合には HAVING を使用する。
SELECT 売上月, SUM(金額) AS 月合計
FROM 売上データ
GROUP BY 売上月
HAVING 月合計 >= 10000;
これは、Excelでのフィルタ後集計と似たような処理であるが、SQLでは構造的により明快に記述できる。
6.28 ハンズオン：合計金額が1万円以上の月のみ抽出
前節の 売上トランザクション 表を拡張し、次のような構造を仮定する。
+--------+----------+------------+--------+--------+
| 売上ID | 商品ID | 売上日 | 単価 | 数量 |
+--------+----------+------------+--------+--------+
月ごとの売上金額合計を集計し、その合計が1万円以上である月のみを抽出するクエリは以下の通り。
SELECT strftime('%Y-%m', 売上日) AS 売上月,
SUM(単価 * 数量) AS 月売上合計
FROM 売上トランザクション
GROUP BY 売上月
HAVING 月売上合計 >= 10000;
このように、HAVING は集計後のデータをフィルタするために必須の構文であり、分析業務では頻出の技術となる。実際にクエリを入力して、売上の多い月だけが抽出されることを確認する。
6.29 SQLで行う「並べ替え・抽出・集計」はExcelとどう違うか
SQLは「データ構造の定義」と「処理ロジックの記述」が分離されているのに対し、Excelは構造と処理が混在している。たとえば、SQLの ORDER BY は明示的に並べ替えを定義するが、Excelの並べ替えはシートに直接作用する。
また、SQLでは SELECT により列を定義し、WHERE や GROUP BY によってデータ処理の流れを一貫して記述できるが、Excelでは関数の分布や配置が視覚的である反面、処理の流れが見えにくい。
これにより、SQLは構造的な再利用や再計算が容易であり、Excelは一時的な視覚操作には強いが構造保持に弱い。
6.30 ハンズオン：Excelで同じ処理を再現し、違いを比較する
前節で用いたSQLの処理（並べ替え・条件抽出・集計）を、Excel上で再現してみる。
元データのテーブルを作成する。
並べ替え：フィルタ機能や「並べ替え」機能を使用。
抽出：オートフィルタや条件付き書式。
集計：SUMIFS関数、ピボットテーブルなど。
SQLとの違いとして、処理の再現性、範囲の明確性、構造の再利用性に注目しながら、可視的だが属人化しやすい点に注意する。
6.31 正規化と非正規化の比較と実務的バランス
正規化はデータの重複や矛盾を排除し、情報を最小単位に分割する設計手法である。非正規化は逆に、使いやすさや処理効率のために冗長性を許容する構造である。
実務においては、完全な正規化が望ましいとは限らず、読解性や運用コスト、分析目的に応じてバランスを取る必要がある。たとえば、部署別報告書などでは、非正規化による利便性を優先する場面もある。
6.32 ハンズオン：1つの表を正規化・非正規化して比較検討
例：次のような売上表を用いる。
+----------+---------+---------+---------+
| 日付 | 商品A | 商品B | 商品C |
+----------+---------+---------+---------+
| 2024/01 | 10 | 5 | 8 |
正規化：以下のように変換する。
+----------+--------+------+
| 日付 | 商品 | 数量 |
+----------+--------+------+
| 2024/01 | 商品A | 10 |
| 2024/01 | 商品B | 5 |
| 2024/01 | 商品C | 8 |
これにより、集計・抽出・JOINが容易になる。一方、非正規化の利点としては視覚的に一目で把握できることがある。両者の比較を通じて、業務目的に応じた適切な選択ができるようになる。
6.33 設計ルールをExcelに応用するポイント
SQLやRDBで得た構造的な設計知識は、Excelの以下のような場面で活用できる。
主キーの代わりにID列を明示的に導入する。
シートごとにマスタ／トランザクションを分離する。
集計や加工用のシートを別途用意する。
関数の連鎖ではなく、構造の明確化によるミスの回避を重視する。
Excelは自由度が高い分、構造の曖昧さが致命的になることが多いため、設計思想をベースにした運用が重要となる。
6.34 ハンズオン：業務表を設計原則に沿って改善提案
既存の業務用Excelファイルを一つ選び、次の手順で改善提案を作成する。
入力／加工／出力の層に分解。
主キーに相当するID列の有無を確認。
マスタ・トランザクションの分離提案。
セルの結合・空白セルの使用を見直す。
上記を踏まえて改善案を設計図として提示。
この演習により、「設計されたExcel」と「設計されていないExcel」の違いを体感できる。
6.35 構造のある表を使う文化の定着
構造を重視したExcelの使い方は、個人の習慣だけでなく、組織文化として定着させる必要がある。属人的な関数の埋め込みや、コピー＆ペーストの連続による劣化を防ぐには、「まず構造を考える」ことを前提とした文化づくりが必要である。
チームで共有するテンプレートや入力ルールを整備することで、構造の維持と品質の安定が実現できる。
6.37 ハンズオン：テンプレート表を構造的に再設計する
実際に使われているExcelテンプレートを取り上げ、以下の観点で再設計を行う。
見た目主体のレイアウトを、構造主体の設計に変更
結合セルや空白行の排除
入力範囲と出力範囲の明示的分離
マスタ・トランザクション形式への変換
再設計前後の比較を行い、読みやすさ・再利用性・誤入力防止の違いを確認する。
6.38 まとめ：SQLとRDBで得た視点をExcelで生かす方法
RDBとSQLで学んだ「構造的に情報を扱う視点」は、Excelという道具に対しても極めて有効である。
セルを情報の最小単位と考える
表をリストと見なして設計する
入力と出力を物理的に分離する
再利用・集計・検索が容易になるよう設計する
こうした視点があることで、Excelを「構造ある情報処理ツール」として活用することができ、属人的で壊れやすい表から脱却することができる。これは単なる操作テクニックではなく、情報設計の根本に関わる実践知である。