データエンジニアのためのGlossary最小プレイブック
データエンジニアのためのGlossary最小プレイブック
本記事は、データエンジニアだけでなく、SIer やユーザー側の担当者など、プロジェクトに関わる人全般に向けて、“すぐ動ける状態” をつくるための最小プレイブックを紹介します。
RDB の DDL は存在するものの「意味の定義が足りない」── そんな現場で役立つ内容です。
なぜ Glossary が必要か
RDB のテーブル定義（DDL）は、テーブル名・カラム名・型といった「構造情報」は詳しく書かれています。
しかし、そのデータが 業務上どんな意味を持つのか まではほとんど記録されていないことが多いです。
典型的な困りごと：
- 新規参画者は「この列って何を表すんですか？」から作業を始めざるを得ない
- SIer と顧客で同じカラムを指していても、業務上の意味がズレて認識齟齬が起きる
- AI に DDL を読み込ませても「名前から推測するに…」レベルに留まり、精度が上がらない
この「意味の空白」を埋めるのが Glossary（用語集） です。
Glossary があれば：
- 新規参画者が用語を調べるだけですぐ作業できる
- 顧客・SIer・社内チームの認識が揃う
- AI に読み込ませても精度が向上する
つまり Glossary は、人と AI の両方を動かすための最小限のインフラ となります。
最小プレイブックの効能
このプレイブックを実践すると、現場に以下の効能が生まれます：
-
新規参画者がすぐに動ける
→ 用語と定義を見れば、コードや SQL に迷いなく入れる -
AI アシスタントの精度が向上する
→ 意味情報が与えられることで、生成結果のブレが減る -
顧客・SIer・社内チームで用語が揃う
→ 「予約」と「契約」が混同される、といった事故を防げる -
プロジェクト開始条件（DoR）として利用可能
→ Glossary v0.8 が揃った時点を「スタートライン」にできる
最小プレイブック（3 ステップ）
1. カタログ抽出
まずは、RDB が内部的に保持している カタログ情報 を整理します。
RDB は「テーブル」「カラム」「制約」といったメタ情報を管理しており、これを取り出すだけで DDL と同等の情報が抽出できます。
抽出対象と、Glossary 化のヒント：
- テーブル一覧
- テーブル名 / 所属スキーマ / コメント（備考）
- コメントに「業務的な名称」が記録されていることがある
- 例：M_PLAN のコメントに「宿泊プランマスタ」など
- この業務的名称は Glossary の PreferredTerm 候補になる
- カラム一覧
- カラム名 / データ型 / NULL 許可 / デフォルト値 / コメント
- コメントがあれば、そのまま Definition のたたき台にできる
- 主キー定義
- 対象テーブル・カラム / 制約名
- 主キーは業務的な識別子を表すことが多く、Glossary 定義に反映しやすい
- 主キーが代理キーの場合、本来の自然キーが UNIQUE 制約で表現されているケースがあるので注意
- 外部キー定義
- 参照元テーブル・カラム → 参照先テーブル・カラム
- 業務的な関係性を理解する出発点になり、Glossary の Context に活用できる
- 制約（任意）
- UNIQUE, CHECK などは値域や業務ルールを示すヒント
- CHECK 制約は「値ドメイン定義」を考える材料になる
抽出のポイント：
- まずは物理情報を抜き出すだけで OK（意味付けは次のステップ）
- コメント欄は必ずチェック（意味情報が残っている場合がある）
- SQL スクリプトを一度書いて自動化すると、差分管理にも役立つ
👉 こうして得られたカタログ情報が、次のステップ「Glossary ドラフト化」で“意味”に変換されます。
2. Glossary ドラフト化
抽出した構造情報をもとに、Glossary（用語集）のドラフト版 を作成します。
目指すのは「テーブルやカラムを業務の言葉で説明する最小限のリスト」です。
Glossary に書くべき項目（最小版）
Glossary は「テーブルやカラムの意味を業務の言葉で表す辞書」です。
最低限、次の項目を埋めておけば、新人も AI も使える“意味の地図” になります。
-
PreferredTerm（正準名）
- 業務で一番正式に使いたい用語。
- 例：宿泊プラン、請求明細、顧客
-
Definition（定義）
- 1〜3 文程度で、その用語が「何を含み、何を含まないか」を明記する。
- 例：「販売単位。食事条件・在庫・価格規則を含む。ただしキャンペーンは含まない」
-
Context / Scope（文脈・領域）
- どの業務やシステム領域で使われる用語か。
- 例：販売、在庫、請求
-
Owner（責任者）
- この定義を承認する責任者（部門や担当者）。
- 例：商品管理部門、経理チーム
オプション項目（入れられるとさらに良い）
-
Synonyms / Aliases（別名・略語）
- 略称や部署ごとの呼び方。 → シノニム整理の布石になる。
-
ForbiddenLabels（禁止ラベル）
- 混乱を招くため使わない言葉を明示する。
- 例：「プラン商品」「キャンペーン商品」は禁止。
-
UsageNote（利用ノート）
- データ利用上の注意点（検索で使う、集計で使う、更新しない、など）。
以下にサンプルを示します。
| PreferredTerm | Definition | Context | Owner | Synonyms / Aliases | ForbiddenLabels | UsageNote |
|---|---|---|---|---|---|---|
| 宿泊プラン | 販売単位。食事条件・在庫・価格規則を含む。ただしキャンペーンは含まない。 | 販売 | 商品管理部門 | プラン | (なし) | 集計・検索で利用可。更新は商品管理のみ。 |
| 顧客 | 実際に予約・宿泊した人を指す。見込み客は含まない。 | 販売・請求 | 営業部 | お客様, クライアント | (なし) | 個人・法人どちらも含む。 |
| 請求明細 | 請求書を構成する明細行。宿泊プラン・人数・料金を含む。 | 請求 | 経理チーム | 明細 | (なし) | 集計対象。更新は不可。 |
| 予約 | 宿泊プランの事前確保。キャンセルされる可能性を含む。 | 販売・在庫 | 営業部 | ブッキング | (なし) | 状態フラグ（仮押さえ／確定）を区別する必要あり。 |
ドラフト作成の手順
-
テーブル・カラム名を並べる
物理名を論理名に変換。コメントに業務的名称があれば優先利用。 -
AI に初稿をつくらせる（任意）
例：「plan_cd → 宿泊プランを識別するコード」
→ ただし表現は推測レベルに留まる。 -
CSV にまとめる
新人や業務担当がレビューしやすい一覧形式に。これが Glossary v0.x になる。
注意点：AI はドラフト係にすぎない
AI で定義文を自動生成すると、確かに作業スピードは上がります。
しかし、Glossary において最も重要なのは 境界の判断（何を含むか／含まないか） です。
- 「予約」は仮押さえを含むか？
- 「顧客」は見込み客を含むか？
- 「売上」は返品や割引をどう扱うか？
これらは業務知識を持つ人間が決めるべき領域です。
3. レビュー & v0.8 確定
Glossary は最初から完璧を目指す必要はありません。
“8 割の完成度（v0.8）”を目標に、DoR(Definition of Ready)として確定するのが実用的です。
ここでいう v0.8 とは、「誰もが作業に着手できる最低限の完成度」を指します。
完璧さではなく「動ける状態」であることが重要です。
プロジェクトのルールとして「Glossary v0.8 が揃わない限り開発チケットを開始しない」と明文化しておくと効果的です。
レビューの進め方
- 参加者：業務担当者、責任者、データエンジニア
- 対象：主要エンティティとキー属性
- 時間設計：1 回 30 分程度、短いサイクルで繰り返す
- 形式：Glossary CSV を画面共有しながらその場で修正
チェックポイント
- 定義の境界線（「含む／含まない」を明示できているか）
- Null 値・Default 値の意味（「値なし」と「未登録」を区別できるか）
- 禁止語・シノニム（同じものを別名で呼んでいないか）
バージョン付け
- Glossary v0.8 として日付とレビュー完了者を記録
- 完全版を目指さず「動ける最低限」を確定する
- 以後はプロジェクト進行中に随時アップデート
まとめ
- DB カタログを抽出する
- Glossary ドラフトをつくる（AI 補助は任意）
- 人間が責任を持って v0.8 を確定する
これだけで、新規参画者も AI も “すぐ働ける状態” が整います。
まずは既存 DB からカタログを抽出し、Glossary v0.1 をつくってみてください。
30 分あれば “意味の地図” の最初の一歩を踏み出せます。
著作と再利用に関する方針
本記事は著者 sisiodos の視点に基づき構成されたものであり、執筆の一部において ChatGPT-5 を補助的に活用しています。
構造設計・章立て・概念整理・表現方針の統一は sisiodos が担い、ChatGPT-5 は草稿生成や文体整形、例示の補助を行いました。
本記事は「人 × AI の共著モデル」を実験的に実践した成果のひとつです。
再利用について
- 本記事の構造・用語・説明の多くは MITライセンスに準じて再利用可能 です（注記がある場合を除く）。
- 再利用・引用・派生作品作成の際は、以下のように出典を明記していただけると望ましいです。
クレジット例
『データエンジニアのための Glossary 最小プレイブック』（sisiodos著）より
または、部分的な引用であれば：
出典：sisiodos『データエンジニアのための Glossary 最小プレイブック』より
このように出典を明示いただくことで、知識の構造と文脈が未来に正しく継承されることを期待しています。
Discussion