モデルとは 情報モデルとは

• 日程: Day 2 / セッション 1
• 時間: [9:00-9:30]
• 形式: 座学
• ゴール: モデリングの4要素（分類・名前付け・パターン・単純化）を暗記に頼らず自分の言葉で列挙し（行動）、家計簿システムなど身近な例を挙げながら（条件）、情報モデルが「要件と実装の橋渡し役」である理由を1分以内で説明できる（基準）
• 学習形式: 対話型解説

Day 1 お疲れさまでした。昨日のあなたの手元には「整理分類済み情報定義書」があります。
ペルソナの視点で整理・分類された、価値ある情報のリストです。

でも、ここで一つ問題があります。
その情報定義書、コンピュータはまだ1ミリも扱えません。

「支出」「カテゴリ」「予算」……人間には意味が通じます。
しかしコンピュータには、それが何でできていて、互いにどう繋がるのかが定義されていません。

今日のDay 2のミッションは、この情報定義書を「コンピュータで扱える形」に変換することです。
その変換の道具が「モデル」です。

ここで少し考えてみてください。
「モデル」と聞いて、何を思い浮かべますか？　プラモデル？　ファッションモデル？　気象モデル？
実はどれも共通点があります。本物そのものではなく、目的に合わせて本物の特徴を抜き出したものという点です。

このセッションでは「モデルとは何か」「情報モデルとは何か」を押さえます。
次のセッション2では、実際に自分の情報定義書から情報モデルを抽出します。

モデリングとは、対象の特徴を抜き出して扱いやすい形にする活動です。
モデリングは次の4つの要素でできています。

• 分類: 似たものをまとめる（Day 1のカードソーティングそのものです）
• 名前付け: まとめたものに名前を与える（Day 1の「見出し」がこれです）
• パターン: 繰り返し現れる構造を見つける（「支出には必ず日付と金額がある」等）
• 単純化: 目的に不要な詳細を捨てる（Day 1の「整理」に対応します）

気づきましたか？　4要素のうち3つは、昨日すでにやっています。
モデリングは特別な儀式ではなく、Day 1の延長線上にあります。

では、なぜモデリングするのでしょうか。理由は2つです。

• 情報を普遍的に利用可能にするため（誰が見ても同じ構造として扱える）
• 情報をコンピュータで扱えるようにするため（プログラムとデータベースに落とせる）

「家計簿システム」でモデリングの4要素を当てはめてみます。

逆の例も見てみましょう。「昨日のランチは高かったなあ」という感想はモデルになりません。
なぜなら、分類も名前付けもされておらず、繰り返し使える構造（パターン）を持たないからです。
一方「支出記録＝日付・金額・カテゴリの組」はモデルです。どのランチにも、どの家賃にも同じ構造が使えます。

• モデリングの4要素は「分類・名前付け・パターン・単純化」。Day 1の整理・分類・見出しと地続き
• 単純化は「手抜き」ではなく「目的に合わせた選択」。何を捨てるかはペルソナが決める
• 「全部を正確に写す」のはモデルではない。原寸大の地図が地図として役に立たないのと同じ

ハリー・ベックの地下鉄路線図 世界一有名な「単純化」

1931年、ロンドン地下鉄の技師ハリー・ベックは、当時の地理的に正確な路線図を捨てて、駅の間隔を均等にし、線を水平・垂直・45度だけで描いた路線図を提案しました。地理的には「嘘」だらけの図です。しかし乗客が知りたいのは「どの駅で乗り換えるか」であって「駅間の正確な距離」ではありませんでした。ペルソナ（乗客）に不要な情報を大胆に捨てたこの路線図は大成功し、現在の世界中の路線図の原型になりました。ちなみにベックの提案は当初「過激すぎる」と一度却下されています。良いモデルは、最初は疑われるものなのかもしれません。

情報モデルとは、ペルソナが価値を見出す情報を、コンピュータで処理可能な形に構造化したものです。
具体的には、次の3点を定義したものです。

• 属性: その情報が持つ項目（支出記録なら「日付」「金額」「メモ」）
• 関係: 情報同士のつながり（「支出記録」は1つの「カテゴリ」に属する）
• 制約条件: 値やつながりに課すルール（「金額は0以上」「日付は必須」）

料理に例えると、情報定義書は「冷蔵庫の食材リスト」です。
情報モデルは「レシピの材料表」に相当します。
材料表には分量（属性）、材料同士の組み合わせ（関係）、「卵は必ずMサイズ」のような条件（制約）が書かれています。
材料表があるから、誰が作っても同じ料理が再現できます。

そして重要なのが、情報モデルの立ち位置です。

• 要件はペルソナの視点で書かれています（「節約したい佐藤さんは支出を振り返りたい」）
• 実装はシステムの視点で書かれています（テーブル定義、API、画面）

この2つは言葉も関心事も違います。直接は繋がりません。
その間に立って両者を繋ぐのが情報モデルです。要件（ペルソナの視点）と実装（システムの視点）を繋ぐ橋渡し役です。

この図は4日間の地図でもあります。あなたは今、左端から真ん中への移動を始めたところです。

家計簿システムの「支出記録」を情報モデルとして書いてみます。

情報モデル名: 支出記録
属性:
  - 日付（日付型・必須）
  - 金額（整数型・必須・0以上）
  - メモ（文字列型・任意・100文字まで）
関係:
  - 支出記録は、1つのカテゴリに属する
制約条件:
  - 金額は0以上の整数
  - 日付のない支出記録は存在できない

「支出記録」は情報モデルになりますが、「支出を登録する」は情報モデルにはなりません。
「登録する」は機能（操作）だからです。Day 1と同じく、ここでも主役は「情報」です。機能は明日ではなく今日の午後、状態遷移から抽出します。

• 情報モデル＝属性・関係・制約条件の3点セット。1つでも欠けると実装で必ず手戻りが出る
• 情報モデルは要件と実装の「橋」。橋が壊れていると、ペルソナの要望と実装が食い違う
• 「〜する」と書きたくなったら要注意。それは機能であって情報ではない

「すべてのモデルは間違っている」

統計学者ジョージ・ボックスの有名な言葉に「すべてのモデルは間違っている。しかし、いくつかは役に立つ」があります。モデルは単純化の産物なので、現実を完全には写せません。完璧な情報モデルを目指して固まってしまうより、「今のペルソナに役立つか」で判断して、PDCAで直し続ける方が健全です。Day 1で約束した「小さく沢山回す」は、モデリングの世界でも鉄則です。

情報モデルを定義するには、2つのスキルが土台になります。

• オブジェクト指向分析設計（OOAD）: 世界を「モノ（オブジェクト）とその関係」で捉える技法。分類・名前付け・関係の定義が中心
• データベース設計: 情報を「表と列と制約」で表す技法。属性の型や制約条件の定義が中心

どう思いますか？　「両方とも授業で聞いたことがある」という人が多いはずです。
情報モデリングは、この2つの知識を「ペルソナの価値」という軸で使い直す活動です。
新しい呪文を覚えるのではなく、持っている道具の使いどころが変わるだけです。

ただし注意があります。データベース設計の正規化は「コンピュータの都合」に最適化する技法です。
情報モデルは「ペルソナの都合」で作ります。この違いはDay 3で正面から扱うので、頭の片隅に置いておいてください。

同じ「支出記録」を2つのスキルで見た場合の違いです。

• OOADの目: 「支出記録クラスは、カテゴリクラスへの参照を持つ」
• データベース設計の目: 「expense テーブルの amount 列は INTEGER NOT NULL、category_id は外部キー」

視点は違いますが、どちらも属性・関係・制約条件を言い当てています。情報モデルはこの2つの共通部分に立ちます。

• 必要スキルはOOADとデータベース設計の2つ。どちらもDay 2以降で実際に手を動かして使う
• 正規化（システム都合）と情報モデル（ペルソナ都合）は目的が違う。混ぜない

UMLは「言語戦争」の停戦協定

1990年代前半、オブジェクト指向の表記法はBooch法、OMT、OOSEなど乱立し、「メソッド戦争」と呼ばれる状態でした。矢印の向き一つで流派が分かれ、図が読めない・伝わらないという本末転倒が起きていました。そこで三巨頭（ブーチ、ランボー、ヤコブソン）が合流して統一したのがUML（統一モデリング言語）です。「名前付け」と「パターン」を業界全体で揃えた、モデリングのモデリングとも言える出来事でした。

• 「モデリングの4要素（分類・名前付け・パターン・単純化）を、地図を例にして説明してください」
• 「家計簿システムの『予算』という情報の属性・関係・制約条件の例を挙げてください。なぜそれが必要かも添えてください」
• 「情報モデルがないままいきなり実装を始めると、どんな失敗が起きますか？　具体的なシナリオで教えてください」

今回学んだことを一言でまとめると「情報モデルは、ペルソナの情報をコンピュータで扱える形にする橋渡し役で、属性・関係・制約条件の3点で定義する」です。

• モデリングの4要素は、分類・名前付け・パターン・単純化。Day 1の活動と地続き
• モデリングの目的は、情報を普遍的に利用可能にし、コンピュータで扱えるようにすること
• 情報モデル＝属性・関係・制約条件。要件（ペルソナ視点）と実装（システム視点）を繋ぐ
• 土台のスキルはOOADとデータベース設計

次のセッション2では、いよいよ自分の整理分類済み情報定義書から情報モデルを3個以上抽出します。
「見出し」がモデル名の候補になる、と覚えておいてください。橋を、自分の手で架けにいきましょう。

• モデリングの4要素を、何も見ずに列挙できますか？
• 情報モデルが定義する3つのもの（属性・関係・制約条件）を、家計簿システムの例つきで言えますか？
• 「情報モデルは要件と実装の橋渡し役」の理由を、ペルソナとシステムという言葉を使って1分で説明できますか？

• 参考リンク:

  • UML（統一モデリング言語）の概要: https://www.omg.org/spec/UML/
  • ロンドン地下鉄路線図の歴史（Transport for London）: https://www.ltmuseum.co.uk/
• 発展課題:

  • 身の回りの「優れたモデル」（路線図・天気図・楽譜など）を1つ選び、何を捨てて何を残しているかを4要素で分析してみましょう
  • 自分の開発テーマの情報1つについて、OOADの目とデータベース設計の目の両方で属性を書き比べてみましょう