新システムのデータ項目はどこから決める？元情報と表示用の値を分ける方法

データ項目と元情報を、仕事の言葉で説明する

データ項目は、受付番号、顧客コード、申告日など、仕事の情報を分けて扱うための欄です。値は、その欄に入る具体的な内容です。「受付番号」という欄と「A041」という値を分けて考えると、どの受付の話をしているかを相手と合わせやすくなります。

ここでいう元情報は、その値の意味を確認でき、変更をどこで受け付けるかをたどれる元の記録です。一つのシステムにすべての答えがあるとは限りません。顧客名を管理する場所と、受付の進み具合を記録する場所が異なることもあります。どちらのシステムが全体として優れているかではなく、今扱う値をどこから取るべきかを、欄ごとに決めます。

入力・受け取りに使う値

仕事を始めるために、人が入力する、または別の仕組みから受け取る値です。人が入力することと、その人が値の管理責任を持つことは同じではありません。

表示のために付く値

コードに対応する名前や、状態を読みやすくした文字などです。表示される場所だけでは、その名前をどこで変更するかは分かりません。

計算・集計で作る値

元の記録を集め、条件や式を適用して作る値です。何件を数えるか、どの期間か、取消しを含めるかで結果が変わります。集計欄があるだけで計算条件を推測しません。

JSONは、項目名と値などを組にして、情報を文字で表す形式の一つです。JSONの仕様であるRFC 8259は、このような形式を定めています。ただし、形式が正しくても、顧客名の管理元や更新担当までは証明できません。「このJSONが正しい形で読める」と「この値を元情報として使える」は、分けて判断します。

一件の仕事を選び、入力と表示を同じ受付番号で結ぶ

まず、受付担当が設備点検の依頼を受け、担当班へ回す仕事に絞ります。「新システムで使う項目を全部集める」から始めると、使う場面のない欄まで増えやすくなります。何を受け付け、誰が次に何をするかを先に言葉にしてください。

架空の資料では、入力側の候補に受付番号「A041」、顧客コード「C12」、申告日「10月20日」があります。表示側には同じ受付番号と顧客コードに加え、顧客表示名「青空商事」、状態ラベル「受付」、担当班表示「東班」があります。A041は同じ受付を見比べるための番号であり、記事の手順名や機能名ではありません。

実務では、同じ一件について、受付時の資料、受付一覧、担当班が見る詳細などを読み合わせます。版や確認時点が異なると、入力後に変わった値を別項目と誤解することがあります。どの時点の資料かを添え、値が変わった場合は変更した操作までたどります。

資料のファイル名に「request」「response」とあっても、名前だけで実際の送信内容や正式な元情報を確定しないでください。作成者が説明用に保存した例なのか、どの機能・版のものか、実際にどの処理と対応するかを開発担当に確認します。

表示に増えた欄は、出所と更新を確認してから使い方を決める

顧客コードが分かれば、別の記録を参照して顧客名を表示する設計は考えられます。しかし、この架空資料でそう作られているとは確認できていません。状態ラベルも、保存した値そのもの、コードを文字に置き換えたもの、複数の条件から作ったものなどが考えられます。可能性を説明することと、現状を確定することは別です。

解説図を原寸で見る

この図を読んだ後の判断：追加の三欄を、そのまま新しい必須入力や連携元に指定することはできません。次は顧客表示名・状態ラベル・担当班表示を使う仕事を確かめ、出所と更新担当の回答をそろえて、必要性と取り方を別々に決めます。入力側の申告日が表示例にない理由も、保存されない・不要とは決めずに確認してください。

顧客表示名

受付で相手を見分けるために必要かを業務側で判断します。必要なら、何の記録の名前を、どの時点で表示するかを確かめます。取引先の名称変更が過去の受付にも反映されるかは、別途決める条件です。

状態ラベル

担当班が作業を始める判断に使うなら、状態の意味と変わる操作が必要です。「受付」と表示されたことを、担当への引き渡し完了や点検完了と同じ意味にしません。

担当班表示

表示を見る人と、割り当てを変更する人を分けます。「東班」が出ているだけでは、自動で決まったか、担当者が選んだか、変更できるかは分かりません。

表示だけで足りる値は、利用のたびに参照する設計も候補になります。受付時点の内容を後で説明する必要があれば、当時の値を残す設計が必要になることもあります。どちらにするかは、履歴の必要性、参照先の変更、利用できないときの扱いなどを確かめて決めます。この記事の資料だけで特定の方式を採用しません。

項目の説明には、意味・形式・空欄の扱いまで書く

「顧客名」「日付」「担当者」という短い名前だけでは、開発側も同じ意味で読めるとは限りません。必要な説明は、業務で取り違えると判断が変わる部分です。項目ごとに、少なくとも次の内容を仕事に沿って具体化します。

1. 何を表すか：どの受付、どの顧客、誰の役割か。顧客の正式名称と画面上の略称、受付担当と点検担当などを区別します。
2. どこで使うか：受付時の本人確認、担当班への引き渡し、検索、月次の確認など、画面や後の作業との関係を示します。
3. 何を入れるか：文字・数値・日付などの形式、必要な桁数や単位、選択できる値を決めます。コードを数として計算しないなら、数字に見えるだけで数値と決めないでください。
4. 入っていないとき：まだ分からない、今回の対象ではない、入力漏れなどを区別します。空欄とゼロとを同じ意味にしません。
5. いつの値か：受付時点、現在時点、集計対象期間など、判断に使う時点を明らかにします。

IPAの要件定義に関する資料例では、データ項目の説明や属性、インターフェースなどを整理する観点が示されています。様式を埋めること自体を目的にせず、相手が値を同じ意味で扱える説明へ結び付けてください。

たとえば、この例の「申告日」は「10月20日」です。この文字だけでは、年を含めた日付、時刻やタイムゾーン、依頼を受けた日か顧客が申告した日かは確定しません。発注資料に使うなら、まず業務上の意味を合わせ、必要な形式を決めます。この例の空いている情報へ、現在の年や都合のよい時刻を補いません。

IPA「データ整備のポイント」も、形式をそろえるだけでなく、項目が表す役割や意味を共有する必要性を説明しています。自社の「担当者」という欄なら、誰のどの業務上の役割を指すかまで説明する、という使い方ができます。

元の記録と更新担当は、変更が表示へ届く道筋で確かめる

データの出所を確認するときは、「顧客情報はどこですか」と大きく尋ねるだけでなく、今の受付で使う一つの値を指定します。元の資料や項目説明、変更の操作を知る担当者と、開発・運用の担当者を結び付けて確認します。

回答が「顧客マスターです」だけなら、そのマスターの対象、項目、管理部署を確かめます。現場が使っている別名簿を指している可能性もあるためです。回答が「画面で直せます」なら、直した結果が元の記録へ反映されるのか、受付の表示だけ変わるのかを分けます。

すぐに実環境の値を変えて試す必要はありません。まず現行の説明書、項目定義、利用する画面の説明、変更履歴などで分かることを確認します。動作で確かめる必要がある場合は、実顧客の記録を勝手に編集せず、担当者と対象・権限・影響・安全な確認方法を決めます。

資料と担当者の説明が食い違えば、古い版か、対象機能が違うか、説明が省略されているかを調べます。最新という理由だけで一方を採用せず、同じ受付・版・時点に対応する根拠を残します。根拠がそろわなければ、確定欄へ移さず、未決の値として担当と次の確認を残してください。

顧客名の統一や重複コード全体の管理方法を決める段階になったら、マスターデータの管理と更新責任へ進みます。ここで行うのは、受付で使う値の出所を特定することです。他の顧客記録を統合したり、全社の管理場所を変更したりする判断までは含めません。

架空の受付例と月次集計例で、分かる値と未確認を分ける

以下はこの記事で使う資料の内容です。「未確認」はゼロ、不要、確認済みのいずれでもありません。入力側・表示側という呼び方は例を読み分けるためのもので、実際のAPI通信を記録した意味ではありません。

受付登録の例は、顧客表示名や状態の出所、更新担当、表示に増えた欄の必要性が未確認です。表示に値があることを理由に、その項目を受付担当の必須入力へ追加しません。

月次集計は、月末に受付件数を確認する別の仕事です。どの記録から集めるか、どの条件で数えるかは未取得です。受付番号の例が一つあるからといって、その月の件数を一件にしたり、空欄をゼロ件としたりしません。集計の結果を決める前に、対象期間と数える単位、取消し・重複・後日の変更をどう扱うかを関係者と確認します。ここに書いた確認観点は、集計ルールが決定済みという意味ではありません。

回答に応じて、必要・任意・保留と取り方を決める

出所を聞いた後に何も決めなければ、確認事項が増えただけで発注準備は進みません。仕事上の必要性と、値の取り方を別々に判断し、回答で何を変更するかを明らかにします。

その値がないと、担当班が受付を見分けられない

業務上必要な候補にします。ただし、必要なのが顧客を識別する値か、画面に読む名前かは分けます。元の記録から受け取れるなら受け取り条件を、現場入力が必要なら入力担当・時点・確認方法を決めます。「必要だから全員に手入力させる」とは飛躍させません。

他の確かな値で仕事ができ、表示は補助になる

省いても誰がどの作業を続けられるかを確かめたうえで、任意表示や後からの追加を検討します。開発側の都合だけで任意にせず、検索や引き継ぎへの影響も業務側が確認します。

元記録は分かるが、更新が届く時点が分からない

必要性を維持したまま、更新条件を未決として残します。古い値で判断してよい仕事か、受付時点を残す必要があるかで、参照方法や保存の条件を見直します。

出所・意味・更新担当のいずれかが確かめられない

取り方を確定せず保留にします。誰に何を聞けば決まるか、発注範囲や見積もりのどこへ影響するかを明示します。保留は不要という意味ではなく、根拠を欠いたまま実装条件へ変えないための状態です。

回答した担当者と、実際に変更できる担当者が異なる

説明を受けた相手をそのまま更新責任者にしません。業務判断をする人、記録を変更する人、仕組みを運用する人の分担を合わせ、引き継ぎや変更依頼の窓口を決めます。

これらは回答後の判断の例であり、架空の会社で既に確認した結果ではありません。今回の資料の出所・更新担当は、引き続き未確認のままです。

「表示する項目はすべて必要」を、確かめられる要件へ書き直す

この説明では、利用しない欄まで取り込むのか、どこを更新するのか、名前の変更を過去にも反映するのかが分かりません。「全部」という量だけでは、仕事ができる条件になりません。

次に、回答を受けた内容だけを確定します。たとえば、ある表示値を元記録から受け取ることが確認できた場合は、項目名、対応するコード、参照する時点、取れなかった場合の扱いを説明へ加えます。入力が必要と分かった場合は、誰がいつ何を入力するか、入力できる値と未入力時の扱いを加えます。

回答と現物が合わない場合は、「確認済み」の一言で閉じず、対象資料の版や値の対応を見直します。表示に使う値が変わったなら、受付側の説明だけでなく、その値を使う後の仕事への影響も確かめます。正式に決まった内容と、今後確かめる内容を同じ文に混ぜないことが大切です。

この作業で作るのは、要件を説明するための根拠と条件です。保存先の製品選定、APIの設計、開発費用、実装や試験の合格まで決まったことにはしません。

項目が決まった後の移行・接続・受入確認へつなぐ

元の記録が分かり、使う意味と更新条件を説明できたら、その情報を必要な後工程へ渡します。全部を一枚の項目一覧だけで終わらせず、解くべき問題に応じて確認を分けます。

• どの仕組みがどこへ情報を渡すか：出所の候補だけでは接続は確定しません。現行の資料と担当者の説明を対応付ける方法は、古いシステム構成図の接続を確かめる手順で扱っています。
• 旧システムの値を新システムへ移せたか：項目の意味を合わせた後、対象範囲や時点、件数や関連を照合します。データ移行の照合方法は、この移した結果を確かめる段階の説明です。
• 依頼した仕事を実際に行えるか：どの役割が、どの入力で、何を確認できるかを受入条件にします。要件定義の受入条件を具体化する方法へつなぎます。

値の出所を決める作業と、移行や動作の合格は同じではありません。項目説明がそろっただけで実データの正しさを保証せず、後工程ではその対象に必要な確認を行ってください。

まとめ：一件の受付で、必要な値の意味と出所を確かめる

新システムのデータ項目は、ファイルに載っている量から決めるのではなく、仕事で使う意味から選びます。同じ受付を対応付けて、入力する値、表示のために付く値、計算で作る値を分け、元の記録と更新担当を確認してください。

名前や状態の欄が表示側にあるだけでは、元情報とは決まりません。必要性が分かっても取り方が不明なら、その部分を未決に残します。回答が得られたら、形式、反映時点、空欄や取得できない場合の扱いを具体化し、発注時の説明を更新します。

最初の一歩は、現在の受付一件と、その担当班が見る資料を並べることです。受付番号で同じ仕事と分かることを確かめ、まず受付番号・顧客コード・顧客表示名について、誰が何に使い、どの記録から取り、誰が更新するかを読み合わせてください。分からない欄は推測で埋めず、確認する相手と、回答で決める内容を添えて残します。