エクセル雑感
情報システムとは：業務ルールでデータを処理する仕組みです。

システム開発は、多くの場合チームで行われます。
もし、チーム内でデータの「言葉の定義」がズレていたらどうなるでしょうか。
例えば、ある開発者は「顧客」を"一度でも商品を買った人"と考え、別の開発者は「顧客」を"会員登録しただけの人"と考えてプログラムを組んでしまったとします。これでは、売上レポートの数字と会員数の数字が食い違い、システムは信頼を失います。
【これを防ぐのが「ER図」と「エンティティ定義書」】

• ER図は、システムに登場するデータたちの関係性を示した「共通の地図」です。
  この地図があることで、チーム全員が「顧客と注文はこう繋がっているんだな」という全体像を共有できます。
  
  
  
• エンティティ定義書は、「顧客とは、氏名・住所・登録日で構成される」といった詳細な「プロフィール帳」です。
  これにより、「顧客」という言葉の定義がブレることを防ぎます。（なお、この「エンティティ定義書」は、その物理的な設計として「テーブル定義書」で代替えされる場合もあります。これらを広い意味で「項目定義書」と呼ぶこともあります。役割はどれも実質的に同じです。）
  
  
  

これらの設計書は、単なる書類ではありません。
チーム全員が同じ言葉で会話し、同じゴールに向かうための「共通言語」そのものなのです。
この言語がなければ、各々が違う設計思想で部品を作り、最終的に組み合わせることのできない、ちぐはぐなシステムが生まれてしまいます。
データの言葉や構造をチームで正しく共有できたとしても、それだけでは十分ではありません。
次に問題となるのは、「そのデータをどう扱うか」という判断基準の明確さです。

システムは、人間の代わりに「判断」を自動で行う機械です。その判断基準が曖昧であってはなりません。
例えば、「注文ステータス」というデータがあったとします。これを「1=受付、2=発送、3=完了、9=キャンセル」と明確に決めておかないとどうなるでしょう。
ある開発者は「キャンセルは0番にしよう」と勝手に実装し、別の開発者は「キャンセルは9番のはずだ」と実装するかもしれません。
その結果、「キャンセルしたはずの注文が出荷されてしまう」といった致命的なバグが発生します。
【これを防ぐのが「コード定義書」】

• コード定義書は、こうしたシステム内の状態や分類を定義する「辞書」の役割を果たします。
  この辞書があることで、「ステータス9は、誰が見ても、プログラムのどこで使われても『キャンセル』を意味する」という絶対的なルールが生まれます。
  
  
  

この「辞書」作りを怠ることが、システムの信頼性を内側から破壊する「曖昧さ」という病気を蔓延させる原因となります。
データ設計とは、こうした曖昧さを徹底的に排除し、コンピュータが迷いなく判断できる絶対的な基準を与える行為なのです。
こうして判断基準を明確に定め、システムの「現在」の正しさを担保したとしましょう。
しかし、優れた設計は、現在だけでなく「未来」も見据えなければなりません。

ビジネスは常に変化します。データ設計とは、この「未来の変化」を予測し、備える行為でもあります。
例えば、今は国内の顧客しかいないからと、住所を「都道府県」から入力する前提で設計したとします。
しかし、2年後に海外への販売が決まったらどうなるでしょうか。住所の持ち方という根本的な設計が対応できず、システムの大規模な改修が必要になったり、最悪の場合は作り直しになったりします。
【これを防ぐのが「設計プロセス」そのもの】

• ER図やエンティティ定義書を作成するプロセスは、チームに「このデータは将来どう変化しうるか？」という問いを強制的に投げかけます。
  
  
  
• 「今は電話番号は一つでいいが、将来的に複数持つ可能性はないか？」「今は担当者は一人だが、主担当・副担当と分かれる可能性はないか？」といった議論を通じて、システムの拡張性（スケール）をあらかじめ設計に織り込むことができるのです。
  
  
  

目先の要件だけを見て作られたシステムは、変化の波に耐えられず、あっという間に「使えない」ものになってしまいます。
データ設計とは、システムの寿命を決定づける、未来への投資なのです。

ER図は、専用のツールで描画するのが一般的ですが、その本質は「箱（エンティティ）」と「線（関係性）」です。
ここでは、その関係性を文章で表現してみます。
※描画されたER図のサンプルはWEB検索すれば簡単に見つかりますので探して確認してください。。
１．登場人物（エンティティ）

ER図で描いた箱（エンティティ）の「中身」を定義するドキュメントです。
ここでは、上記ER図の顧客（Customer）エンティティの定義書サンプルです。
エンティティ名：顧客 (Customer)

このように各項目（属性）のデータ型やルール（制約）を細かく定義することで、「メールアドレスの重複登録を防ぐ」「登録日時を自動で記録する」といったシステムの挙動を明確にし、データの品質を担保します。
※上記では、一般的なRDBとして記載していますが、Excelのテーブルでも考え方は同じです。