調査・解説 · 要件定義 · 2026年9月18日

データ項目の定義：意味・空欄・変更ルールを揃える

備品台帳のデータ辞書を作り、未入力と空文字、予定と実績の違いを決める。

この記事の目次

画面に「数量」「返却日」「担当者」という項目が並んでいても、その意味が揃っているとは限りません。数量は申請数なのか実際に貸した数なのか。返却日は予定なのか実績なのか。項目名に加えて、意味・値の単位・未入力・変更の扱いを決めるのが、データ定義の出発点です。

この記事は、画面やAPIに載せる情報を整理する企画・開発担当者向けです。架空の備品貸出台帳のデータ辞書を作ります。以下の項目や上限は作例で、現場の運用から確認するための案です。

先に、似た言葉を分ける

たとえば「日付」だけを作ると、画面担当は返却予定日、集計担当は実際に返却した日と解釈するかもしれません。この作例では、利用者と総務が約束する「返却予定日」と、現物を受け取った「返却日時」を別にします。

同じように「数量」は、個体を管理する機器なら単純な個数では足りません。ノートPCを2台貸す場合、どの管理番号の2台なのかが必要です。ここでは個体管理する機器を対象とし、消耗品の数量管理は扱わないと決めます。項目を定義する前に、今回の対象範囲と揃えます。

項目	意味と形式	未入力・制約	誰がいつ決めるか
備品管理番号	現物を識別する文字列。例：PC-0042	必須。同じ番号を重複登録しない	総務が備品登録時に付与
申請者ID	申請者を識別するID	必須。表示名だけで照合しない	申請時にログイン情報から設定
返却予定日	日本時間での予定日。例：2026-10-09	貸出開始日以降	申請者が入力、変更ルールは別途合意
返却日時	総務が現物の返却を確認した日時	未返却では未設定	総務が返却確定時に記録
受渡メモ	総務内の引き継ぎ情報	任意。空ならメモなし	総務が必要時に記入

番号の「0042」を数値として保存すると、先頭のゼロを表示し直す必要が出ます。計算しない識別子と、計算する数量は、見た目が数字でも同じ型にしない方針をこの例では採ります。

この表に実装名を併記しても構いませんが、まずは業務担当が「何を表す値か」を判断できることが大切です。入力画面・一覧・CSVで別名を使うなら、その対応も残します。

JSON Schemaでは、プロパティが存在することを求める required と、値の型は別に指定します。また、値が null であることと、プロパティ自体がないことも異なります。object

文字列については、空文字も文字列として有効であり、長さの制約は minLength などで表します。string

これはJSON Schemaを必ず使うという話ではありません。要件の「必須」も、同じように分解する必要があるという記事側の提案です。この台帳なら次の扱いを決めます。

更新APIでは、項目の省略を「変更しない」、空の値を「消す」と扱う設計もあります。新規登録と更新を同じ表だけで済ませず、区別して合意します。

運用開始後に返却予定日を必須にすると、過去の貸出記録に値がないかもしれません。適当な日付で埋めると、それが本当の約束だったように見えます。

この例では「未確認」の既存記録として一覧から探せるようにし、総務が本人へ確認して埋める案にします。新規登録への必須条件、過去データの補完、未確認中の表示を別々に決めます。通知や延滞集計がその値を使う場合は、未確認の記録をどう扱うかも必要です。

次の打ち合わせでは、誤解が起きそうな項目を一つ選び、意味、正常な値、空欄、境界、変更できる人、既存データの順に確認してください。「返却日」なら、日付だけか時刻も必要か、どの時点を返却とするか、未返却をどう表すかまで話せると、実装の判断が揃います。

変更する人の範囲は権限設計の確認表、既存データへの影響は要件変更の影響確認で整理できます。