データ辞書の説明資料で解決したいのは、意味の食い違いです。すべての列が並んだ表をそのまま投影することではありません。まず、解釈が分かれている業務上の問いを示します。少数のレコードで確かめ、定義に合意し、その定義を誰が管理するのか、利用するレポートがどう変わるのかを説明します。

予約制サービスを提供する架空の事業者を考えてみましょう。ダッシュボードには「完了した予約は3件」とありますが、運用責任者は、実際にサービスを提供したのは1件だと言います。どちらも数字を作ったわけではありません。ダッシュボードはキャンセルや無断欠席を含む、処理済みの予約を数えています。ラベルのために、異なる3つの結果が同じ意味に見えているのです。以下のレコード、役割、変更内容はデータ辞書のレビューを説明するための架空例であり、顧客データやPresentiの導入事例ではありません。

チームで定義を決めたら、Presentiのテキストからプレゼン資料を作る機能で、合意した説明を編集可能なスライドにまとめられます。入力するのは選んだフィールドの定義とサンプル行であり、機密情報を含むデータベースのエクスポートではありません。正本はあくまでデータ辞書です。プレゼン資料は、判断に必要な内容を相手に合わせて抜き出したものです。

データ辞書の説明資料：項目の意味をチームでそろえる方法

食い違いの原因になった業務用語から始める

この例の参加者は、運用責任者、レポート担当アナリスト、予約データのエクスポートを担当するエンジニアです。次のレポート公開前に、「完了した予約」の意味を承認する必要があります。予約システムの全フィールドを見て回る必要はありません。

役に立つデータ辞書は、人が使う言葉と、確認できるデータをつなぎます。USGSのデータ辞書ガイドでは、名前、定義、データ型、NULLを許容するか、参照値、業務ルールなどを辞書の内容として挙げています。今回の会議では、それらを使って「この行は提供済みのサービスを表すのか、それとも今後実施されない予約を表すだけなのか」という具体的な問いに答えます。

最初のスライドで、「1拠点の日次予約スナップショット。1行が1件の予約を表す」と範囲を定めます。この例のスナップショットは2026年10月9日08:00 UTCに取得したもので、現在の最新状態ではなく、その締め時点を記録しています。取得時刻とデータ辞書のバージョンを表示してください。予約は顧客ではなく、同じ顧客が複数の予約を持つことがあります。また、スナップショットは全ステータス変更の履歴ではありません。この2点を伝えるだけでも、データ自体は正しいのに使い方を誤ることを防げます。

いずれも2026年10月8日に予定されていた、架空の予約4件
予約ID取得時点のステータス完了時刻（UTC）業務上の意味
000271completed2026-10-08T09:30:00Zサービスを提供済みとして記録している。
000272cancelled値なし予約をキャンセルした。サービス提供済みではない。
000273no_show値なし顧客が来店しなかった。サービス提供済みではない。
000274booked値なしこのスナップショットには、最終結果がまだ記録されていない。

旧ダッシュボードのルールでは、completed、cancelled、no_showをすべて処理済みとして数えるため、表示は3件になります。提案する「完了」の定義では、該当するのは000271だけです。4行目は、予定日を過ぎたからといって、黙って無断欠席として扱ってはいけません。この抽出データでは、結果が未確定です。

実際のPresenti編集画面を枠にした架空のデータ辞書例。同じ予約4件でも、処理済みは3件、サービス提供済みは1件になる。
実際のPresenti編集画面の枠に、編集部が作成した架空の事例スライドを合成した図です。Presentiが実際に生成した結果を記録した画像ではありません。 画像を拡大して見る

フィールドの形式と業務上の意味を分ける

型は値がどんな形を取れるかを示し、定義は何を表すかを示します。日付に見える値だけでは、予約を入れた日、サービスの予定日、エクスポートした日のどれかは分かりません。同様に、数字に見えるIDも、足し算や丸めをしてよい数量とは限りません。

架空の判断に必要なフィールド
フィールド型と許容値定義防ぎたい誤用
appointment_id必須の文字列。スナップショット内で一意。000271など、1件の予約を識別する安定したID。数値に変換して先頭のゼロを消さない。顧客IDではない。
service_date必須の日付。形式はYYYY-MM-DD。拠点のタイムゾーンEurope/Londonでの、サービス提供予定日。予約作成日や、UTCのタイムスタンプを途中で切った日付で代用しない。
status必須の文字列。booked、completed、cancelled、no_showのいずれか。スナップショット取得時点で記録されている予約状態。closedをcompletedの同義語にしない。closedは別途導出するグループである。
completed_atUTCのタイムスタンプ、または値なし。記録されたサービス提供完了時刻。値なしは、午前0時、所要時間ゼロ、無断欠席の確定を意味しない。

W3Cの表形式データ用メタデータ語彙では、列の型、必須値、キーなどの制約を機械可読なメタデータで記述できます。そうした検証は、不正な形式や欠損の検出に役立ちます。ただし、キャンセルした予約を完了として数えるべきかという業務判断まではできません。技術的な制約と業務上の合意は一緒に管理しつつ、混同しないようにします。

業務担当者には、データベース用語をすべて説明してから始めるのではなく、フィールドの横に1行の例と起こりうる誤用を示します。000271の先頭のゼロを見せれば、文字列型にする理由がすぐ分かります。予定日と完了時刻の違いも、タイムゾーンが単なる技術的な注記ではなく、話し合うべき条件だと伝わります。

欠損と矛盾する値を明示する

4行の抽出データでは、同じ「完了時刻なし」が3種類のステータスに現れます。キャンセルなら自然です。無断欠席でも自然ですが、理由は異なります。結果未確定の予約では、完了が記録されていないことしか分かりません。3つとも「未完了」に置き換えると、ある計算には便利でも、業務を進めるために必要な区別が失われます。

会議では、5件目の架空のレコードを加えます。このレコードは例外です。statusがcompletedなのに、完了時刻がありません。運用責任者は実際にサービスを提供したと知っていても、アナリストはこの行から時刻を推測できません。今回の提案は、定義上の例外に分類して調査し、除外した例外件数を完了件数の隣に示すことです。レポートの数を合わせるために、元のステータスを書き換えてはいけません。

これは重要な選択ですが、共通の正解ではありません。別の事業では、ステータスだけで完了の証拠として認めることもできます。その場合は方針を明文化し、いつタイムスタンプを必須にするかを決めます。危険なのは、2人のレポート作成者が違う方針を選んでいるのに、その違いが見えないことです。

他の用語にも使える定義カードを、この例で埋めたもの
カードの項目承認会議に出す内容
業務用語完了した予約。
意味サービス提供済みと記録され、完了時刻も記録されている予約。
含めるレコードstatusがcompletedで、completed_atに値がある。
含めないレコードcancelled、no_show、booked。completedでも必須の完了時刻がないものは、例外として別に報告する。
単位と範囲顧客の重複排除数ではなく、異なるappointment_idの数。1拠点、取得日が明確な1つのスナップショット。
時刻の扱い報告期間にはEurope/Londonのservice_dateを使い、completed_atはUTCのまま保持する。
元データとの対応日次予約スナップショットのappointment_id、service_date、status、completed_at。
承認権限とバージョン意味は運用責任者が承認し、カードはレポート担当アナリストが管理する。提案する辞書はv2.0。
既知の限界現在のスナップショットだけでは、過去の報告締め時点の状態を再現できない。

別の用語を検討するときは左側の項目を再利用できますが、右側はすべてその用語に合わせて書き換えます。「アクティブ顧客」「解決済みチケット」「計上済み収益」では、含める条件も承認者も異なります。名前だけの置き換えでは有効な定義になりません。

意味、データ対応、変更周知の責任を分ける

「担当：データチーム」とだけ書くと、3つの問いが隠れがちです。意味を承認できるのは誰か、元データとの対応を直せるのは誰か、意味が変わったことをレポート利用者に知らせるのは誰か。この架空のチームでは、次のように分担します。

  • 運用責任者：提供済みのサービスに完了時刻を必須とするかを承認し、運用上の例外を判断する。
  • 予約システムのエンジニア：ステータスや時刻がエクスポートに届く仕組みを、遅延や修正時の動作も含めて確認する。
  • レポート担当アナリスト：辞書の項目を保守し、影響するレポートを特定し、承認されたバージョンを記録する。
  • ダッシュボードの担当者：ラベルと計算式を変更し、業務責任者が受け入れを確認できる例を示す。

これは役割分担の例であり、4つの職種を新設するという意味ではありません。小さなチームでは兼任しても構いませんが、決定記録には責任を持つ人の名前と連絡先が必要です。エンジニアが業務上の定義を考え出すことも、業務責任者が未検証のデータ対応を承認することも避けます。

未合意の範囲は、今回の承認から外します。このチームは、無断欠席の手数料をレポートの収益に含めるか、まだ決めていません。予約の定義を整理しただけで、収益認識、返金、税務上の扱いまで決まったように見せてはいけません。それぞれ元の記録や判断責任者が異なる、別の用語です。

定義変更が過去の数値に与える影響を示す

提案するv2.0では、「処理済みの予約」と「完了した予約」を分けます。以前の「完了」というラベルは、より広い処理済みのルールを指していました。ラベルか計算式の片方だけを変えると、利用者は意味の違う数字を比べることになります。

同じ架空の4行に、定義変更を適用した結果
レポートの版表示する用語ルール件数
v1.0：旧ダッシュボード完了completed、cancelled、no_show3
v2.0：明確化したグループ処理済みcompleted、cancelled、no_show3
v2.0：新しい運用指標完了completedで、完了時刻が記録されている1

3件から1件への変化は、サービスの成績が悪化した証拠ではありません。レコードは同じで、定義が変わっただけです。公開時点をまたぐ時系列グラフを見せる前に、この対応関係を示します。

架空の導入案では、2026年11月2日に始まる報告週からv2.0を適用します。v1.0の辞書とエクスポート済みレポートは残します。保存済みスナップショットに必要なフィールドがある場合は、別途再計算した履歴を作り、v2.0と表示します。必要なフィールドがない場合は、系列を分けて不連続点を示します。現在の状態を出力したデータから、過去のすべての報告締め時点を確実に再現することはできません。

変更記録には、旧ルール、新ルール、適用する報告期間、承認者、影響するレポート、履歴の扱いを記載します。元のエクスポート自体を変えるのか、レポートでの解釈だけを変えるのかも明示してください。この例ではエクスポートは同じで、業務定義、ダッシュボードのラベル、計算をまとめて変更します。この区別があれば、意味の変更をスキーマ移行と取り違えずに、技術側が作業量を見積もれます。

定義の承認を5枚のスライドで進める

業務レビューには、裏付けとしての辞書が必要です。辞書全体を画面に出す必要はありません。この例なら、次の5枚を使います。

  1. 「処理済み3件は、サービス提供済み3件ではない」。問題になったダッシュボードのラベルを、運用側の問いと並べます。
  2. 「同じ4行から、2つの合計が生まれている」。小さなレコード表を示し、completed、cancelled、no_show、結果未確定のbookedを区別します。
  3. 「この『完了』の意味を承認する」。定義カードを示し、包含条件、例外、時刻の扱いに絞って確認します。
  4. 「v2.0は出来事ではなく、比較の意味を変える」。3件から1件への対応、適用期間、履歴の再計算でできないことを示します。
  5. 「定義を承認し、レポート変更の担当を決める」。定義の決定者、データ対応の確認者、レポート担当を明示し、収益の問題は今回の承認に含めません。

辞書全体と変更記録を資料に添え、会議後も承認した詳細を参照できるようにします。これらのメモからスライドを下書きする場合は、フィールド名をそのまま保持し、「架空」という説明を残してください。見出しを短くして、処理済みと完了の違いを消してはいけません。メモをスライドに変えることは、データベースの自動スキャンやカタログ同期を意味しません。

提案する結論は明確です。サービス提供済みで完了時刻が記録された予約を「完了」として承認する。「処理済み」は別のグループとして残す。v2.0のレポート定義は、履歴の不連続を明示するか、再計算した系列を別ラベルで示して公開する。これで、各自が違う意味に解釈する用語集ではなく、実装できる合意が得られます。