データ定義書の作り方

データ定義書とは

データ定義書とは、データベースの列、スプレッドシートの列、SaaSの入力項目など、データの項目一つひとつについて、その意味とルールを書き残した文書です。

システム開発では、テーブル定義書や項目定義書として作られることが多い文書ですが、ここで扱うのはもう少し業務に寄ったものです。「この列には何が入るのか」「この数字はいつ時点のものか」を、システムの担当者だけでなく、入力する人や数字を使う人が読める言葉で書きます。

なぜデータ定義書が必要なのか

データが合わない原因は、入力ミスより、同じ言葉を違う意味で使っていることにある場合が少なくありません。

• 営業の「売上」は受注した金額、経理の「売上」は計上した金額、というように、同じ名前で別のものを数えている。
• 「顧客」が契約中の会社だけを指すのか、見込み客も含むのかが、人によって違う。
• 日付の列に、受付日を入れる人と対応日を入れる人がいる。
• 担当者が変わると、項目の使い方も変わってしまう。

上の例は、よくあるパターンを示した説明用の例です。こうしたズレは、データを一つの場所に集めても、ツールを連携しても解消しません。データのサイロ化には、保存場所の切れ目のほかに「意味の切れ目」があります。データ定義書は、この意味の切れ目をつなぐための文書です。

AIにデータを渡して集計や回答をさせる場合にも、項目の意味が書かれていなければ、AIは列の名前から推測するしかありません。

データ定義書に書く項目

項目一つにつき、次の内容を書きます。最初からすべてを埋める必要はありませんが、意味・形式・入力者・正の置き場所の四つは優先して書きます。

• 項目名：画面やファイル上の列名。別名や略称があれば併記する。
• 意味：何を表すのか。含むもの・含まないもの、いつ時点の値かを書く。
• 形式と例：日付・数値・文字・選択肢など。入力の例と、選択肢ならその一覧を書く。
• 発生と入力：その値がどの業務で発生し、誰が、いつ入力するか。
• 正の置き場所：同じ項目が複数の場所にあるとき、どこの値を正とするか。
• 計算式・ルール：ほかの項目から計算する場合の式、空欄や例外の扱い。
• 使われ方：どの帳票・会議・判断で使われているか。
• 管理者と変更履歴：定義を変えるときに決める人と、いつ何を変えたか。

作り方：5つの手順

データ定義書は、全項目を網羅しようとすると途中で止まります。止まっている判断を起点に、小さく作ります。

• 手順1　対象の判断を決める：数字が合わない会議資料や、毎回確認が発生している帳票など、困っている場面を一つ選びます。
• 手順2　その判断に使う項目を挙げる：資料の数字が、どの列から、どんな計算で作られているかを辿り、使われている項目を洗い出します。
• 手順3　現物のデータを見る：各項目に実際に入っている値を確かめます。空欄、表記の揺れ、想定外の値が、定義が決まっていない箇所の手がかりになります。
• 手順4　関係者で意味を決める：入力する人と使う人が同じ場にいる状態で、意味と例外の扱いを決めます。
• 手順5　置き場所と変更のルールを決める：定義書を誰でも見られる場所に置き、変更するときの手順と、入力画面や集計への反映のしかたを決めます。

手順4で、一つの項目に意味が二つあると分かることがあります。その場合は、どちらかに統一するより、項目を分けて名前を変えるほうがうまくいくことがあります。

意味が二つあるなら、名前を分ける

「売上」が営業では受注した金額、経理では計上した金額を指しているとき、どちらかに合わせようとすると、もう一方の業務が困ります。どちらの数字も、それぞれの業務にとっては正しいからです。

この場合は「受注金額」「計上金額」のように項目を分け、それぞれの意味と集計の基準日を定義書に書きます。会議では、どちらの数字の話をしているのかを名前で区別できるようになります。部署間で数字が食い違う問題は、関連記事「会議の数字が合わない・部門で数字が食い違う」でも扱っています。

記入例：「最終接点日」（仮想例）

営業の案件管理で使う「最終接点日」という項目を例に、定義を書いてみます。

• 項目名：最終接点日（別名：最終コンタクト日）
• 意味：顧客と双方向のやり取り（面談・電話・メールの返信）があった最後の日。こちらからの一方的な送信だけの日は含まない。
• 形式と例：日付（YYYY-MM-DD）
• 発生と入力：接点があった当日中に、案件の担当者が案件管理の画面で更新する。
• 正の置き場所：案件管理の画面。週次の会議資料はここから出力し、手で打ち直さない。
• 使われ方：週次の営業会議で、一定期間接点のない案件を抽出してフォローを決める。
• 管理者：営業責任者。定義を変えるときは営業会議で決め、変更日を記録する。

「一方的な送信を含むか」を決めておかないと、メールを一通送っただけで、案件が止まっていないように見えてしまいます。この一文があるかどうかで、会議で抽出される案件が変わります。データ定義書の価値は、こうした境界の扱いを言葉にしておくところにあります。

データ定義書が続かない理由と対策

作ったのに使われなくなる定義書には、共通点があります。

• 置き場所が分からない：入力する画面や集計のシートから、定義書へのリンクを張ります。
• 書いた人しか更新しない：項目ごとに管理者を決め、変更は管理者を通す流れにします。
• 入力画面と食い違う：選択肢や入力ルールは、定義書と入力画面の両方を同時に直します。
• 全部を書こうとする：判断に使う項目から書き、使われていない項目は「未定義」のまま残しておきます。
• システムの言葉で書く：入力する人が読んで分かる言葉で書き、技術的な型や制約は別の欄に分けます。

AIやBIにデータを渡す前に

AIにデータを読ませて回答や集計をさせる、BIツールでダッシュボードを作る。どちらの場合も、項目の意味が決まっていないと、もっともらしいのに意図と違う数字が出てきます。

• 判断に使う項目には、すべて意味が書かれている。
• 含むもの・含まないもの、いつ時点の値かが書かれている。
• 入力する人とタイミングが決まっている。
• 同じ項目が複数の場所にあるとき、正の置き場所が決まっている。
• 定義を変えるときに決める人と手順が決まっている。

上のチェックを満たしていれば、定義書の内容をAIへの指示に含めたり、ダッシュボードの指標の説明として表示したりできます。逆に、意味を決められない項目があれば、それはAIやダッシュボードの前に、業務の側で決めるべきことが残っているというサインです。指標レベルの定義のズレについては、関連記事「KPI定義が部署でズレる」で詳しく扱っています。