データ定義書

これは何か

データ定義書は、新しいシステムで扱うデータの項目1つずつについて、「何を表すか・どんな形で入るか・どんな値を取りうるか・誰が決めたか」を定める成果物です。

同じ項目を、画面を作る人、ほかのシステムとの連携を作る人、帳票を作る人、業務でその値を読む人が、それぞれ別の思い込みで扱うと、どこかで値の食い違いが起きます。定義書は、その全員が見る「項目の辞書」です。

なぜ作るか

• 画面・連携・帳票・分析で、同じ項目を同じ意味・同じ形で扱う
• 入力のチェック（桁・必須・取りうる値）の根拠をはっきりさせる
• データ移行で、移行先の項目の条件を示す（DAT-004 データ移行対応表 の移行先の側）

誰が使うか・いつ作るか

• 作る人：データの設計の担当。業務の意味の欄は、業務の担当と一緒に書く
• 確かめる人：その項目を業務で使う担当、連携の相手のシステムの担当
• 使う人：画面・連携・帳票・移行を作る人、テストの担当
• 一般的には、要件がまとまり全体の設計が進んだ段階で作り始め、設計・開発の中で詳しくし、変更のたびに更新します
• 誰が定義を決め、誰が承認するかは、プロジェクトによって異なります

アステリア案件のデータ定義書の中身（項目・形式・取りうる値）と、定義を決めた人・承認した人は、正本に記載がありません。未確定

主な項目（列）

1つの項目について、一般的には次を書きます。

1. 項目の名前：画面や帳票に出る名前と、システムの中の名前
2. 意味：業務の言葉で、この項目が何を表すか。名前の言い換えではなく、業務の担当が読んで「そういうことか」と分かる説明
3. 形式：文字・数字・日付など。日付なら何時点の日付か
4. 桁：文字数・数字の桁数・小数の扱い
5. 必須かどうか：空を許すか。許すなら、空は何を意味するか
6. 取りうる値：決まった値だけを取るなら、その一覧（コード表）と、それぞれの意味
7. 単位：時間なら「時間」か「分」か、数量なら何を数えるか
8. 持ち主：その定義を決め、変えるときに判断する人（役割）。データの種類ごとの責任者は DAT-001 とそろえる
9. 使われている場所：どの画面・連携・帳票で使うか
10. 変更の履歴：いつ、誰が、何を、なぜ変えたか

読み方

1. 「意味」が、名前の言い換えで終わっていないか（「案件コード：案件のコード」では意味にならない）
2. 日付・時間・数量に、何時点か・どの単位かが書かれているか
3. 取りうる値が一覧になり、それぞれの意味が書かれているか
4. 必須でない項目で、空が何を意味するかが書かれているか
5. 持ち主と、最後の変更の理由が書かれているか

書き方

1. 要件と業務の流れから、必要な項目を洗い出す
2. 業務の担当と一緒に、項目ごとの意味を業務の言葉で書く
3. 形式・桁・必須・取りうる値・単位を決める
4. 持ち主を決め、DAT-001 の責任者と食い違わないかを確かめる
5. 使われている場所（画面・連携・帳票）を書き、連携の相手の担当にも確かめてもらう
6. 変えるときは、変更の履歴に理由と承認者を残し、使われている場所の担当に知らせる

何を書いてはいけないか

• 確かめていない意味を、名前から推測して書くこと
• 取りうる値に「その他」だけを置き、何が入るか分からないままにすること
• 変更の履歴を残さずに、定義を上書きすること

ほかの成果物との違い

• DAT-001 データ一覧・管理責任表：データの種類ごとに、正本と責任者を決める。定義書はその中の項目ごとの意味と形を決める
• DAT-004 データ移行対応表：古い項目を新しい項目にどう入れるか。定義書は、その「新しい項目」の側の決まり（対応づけの考え方は 11-03 のテーマです）
• ARC-004 システム連携一覧：どのシステムからどのシステムへ何を渡すか。受け渡す項目の意味と形は、定義書とそろえる

よくある失敗

• システムの中の名前と形式だけを書き、業務の担当が読めない定義書になる
• 開発の途中で定義を変えたが、定義書を直さず、画面と連携で扱いがずれる

関係するUnit・成果物・危機演習

• Unit：11-03 古い項目と新しい項目を対応させる、05-02 どのシステムが何を担当するのか
• 成果物：DAT-001 データ一覧・管理責任表、DAT-004 データ移行対応表、DAT-005 データ品質・クレンジング一覧、ARC-004 システム連携一覧
• 危機演習：この成果物を直接の題材にする危機演習はありません

いつ使うか

この教材では STAGE 05｜全体設計を作る の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。