🤔なぜ学ぶのか？
システムを使う側から見ると、画面（UI）が全てに見えます。しかし、システムの本質は、その裏側にある「データをどう保存し、どう取り出すか」という仕組みにあります。
データモデルを理解することで、システムの設計が見えるようになり、効率的で拡張性の高いプロセス自動化が実現できるようになります。
📦システムとは「データを操作する箱」である
画面（UI）はただの「皮」にすぎません。システムの本質は、データを登録・管理する仕組みそのものです。
システムの4つの基本操作（CRUD）
Create（作成）
誰が、いつ、何のために書くか
Retrieve（読取）
いつ、どのように読むか
Update（更新）
どの条件で書き換えるか
Delete（削除）
どの条件で消すか
🧩なぜエンジニアはデータを分割したがるのか？
非エンジニアにとっての「不自然さ」の正体は、物理的な「紙」の直感と、デジタルの「論理」のギャップにあります。
📄直感（Intuition）
お客様情報は一枚の紙にまとまっているのが自然
「お客様情報は、一枚の紙にまとまっているのが自然」
⚙️論理（Logic）
データは正規化し、分割して管理すべき
🧪思考実験：レシートを1行で保存してみる
もし、レシートの情報を1つのテーブル、1行で保存しようとしたら、どうなるでしょうか？
3つの問題が発生します
無限の列（Infinite Columns）
商品が増えるたびに、横に列を足さなければならない。テーブルができあがらない。
情報の重複（Data Redundancy）
別のレシートを作るたびに、同じ「店舗住所」を何度も入力する必要がある。
検索不能（Unsearchable）
「りんごが売れた日」を探すのが極めて困難。
✅正解は「3つに分解する」こと
Exploded View（分解図）
Layer 1: 店舗（Shop）
Fixed Info - 変わらない存在、帰属先
メリット：
店舗の電話番号が変わっても、修正は「店舗テーブル」の1箇所だけで完了します。
Layer 2: 売上（Sales）
Transaction Header
Layer 3: 明細（Details）
Items
データの整理方法
「お客様情報」が3つに分かれているのは、情報の寿命と粒度が違うからです。担当者（Contact）が異動しても、会社（Account）は変わりません。商談（Opportunity）が終了しても、会社との関係は続きます。
🔗「1対多」の親子関係を理解する
データモデルの核心は、「親子関係」です。1つの親に対して、複数の子が存在する関係を「1対多（One-to-Many）」と呼びます。
親子関係の例
親（Parent）: 取引先（Shop）
変わらない存在、帰属先
子（Child）: 売上（Sales）× 3
発生する出来事
ID（The Invisible Thread）
親と子をつなぐ見えない糸、それが「ID」です。
Salesforceの構造も同じ
Salesforceには、Account（取引先）、Contact（取引先責任者）、Opportunity（商談）という3つの主要オブジェクトがあります。これも同じ親子関係（1:N）の構造です。
- •担当者（Contact）が異動しても、会社（Account）は変わりません。
- •商談（Opportunity）が終了しても、会社との関係は続きます。
🔢データには「型」がある：計算できるもの、できないもの
❌ Bad Example (Human Input)
「1,000円」
↓
テキスト (Text)
✗ 計算不可 (Cannot Multiply)
✓ Good Example (System Input)
10000000
↓
数値 (Number)
✓ 計算可能 (Can Calculate)
主なデータ型
テキスト (Text)
数値 (Number)
日付 (Date)
真偽値 (Boolean)
参照 (Reference/ID)
IT Optimizerが陥りやすい「3つの罠」
⚠️罠① 「全部1シート」の罠
列が無限に増え、空白だらけのテーブルができる。
問題：
商品が増えるたびに列を追加し続けると、テーブルの管理が不可能になります。
⚠️罠② 「名前マッチ」の罠
「株式会社ABC」と「(株)ABC」が別物として扱われる。必ず「ID」で紐づけること。
解決策：
名前ではなく、一意のID（ユニークキー）でデータを結びつける。
⚠️罠③ 「見た目重視」の罠
「来週の月曜」と入力して、日付計算がエラーになる。データ型を厳守すること。
解決策：
システムが認識できる形式（データ型）でデータを保存する。
🎯「正規化」＝データの断捨離
エンジニアが言う「正規化」とは、要するに「重複をなくし、効率化すること」です。
Golden Rule（黄金律）
迷ったら、この問いを投げかけてください：
「このデータは、誰（何）に属する情報か？」
この質問に答えることで、データをどのテーブルに保存すべきかが見えてきます。
📚まとめ：システム構築のための思考法
1. System = CRUD
画面の裏でデータがどう動くかをイメージする。
2. Split & Link
情報を適切な単位に分け、IDでつなぐ。
3. Strict Types
コンピュータが計算できる「型」で保存する。
この構造が見えれば、どんなツール（Salesforce, kintone, Make）も怖くありません。
🚀次のステップ：静的な「保存」から、動的な「処理」へ
データモデル（箱）の設計が終わりました。次は、その中のデータをどう動かすか？
次のトピック：
- →プロセス説明：業務をフローチャートで表現する方法
- →プログラミングベーシック：変数・ループ・分岐の基礎
- →完璧主義からの脱却：MVP思考で段階的にリリースする方法