オリエンテーション／モデルとは／情報モデルとは

• 日程: Day 2 / セッション1
• 時間: 9:00-9:20
• 形式: 座学
• ゴール: モデル化の4要素（分類・命名・パターン化・単純化）を使って「情報モデル」を説明できる
• 学習形式: 対話型解説

🗣️ 要約

• 整理分類済み情報定義書はまだ人間向けの形であり、コンピュータはそのままでは処理できない
• Day2は、その情報定義書をコンピュータが処理できる形に組み立て直す1日
• ゴールは「モデル」と「情報モデル」の違いを説明できるようになること

おはようございます。Day2の始まりです。

昨日1日かけて、みなさんは開発テーマの情報を洗い出し、ペルソナの視点でLATCH法やカードソーティングを使って「整理分類済み情報定義書」を完成させました。

ここで少し考えてみてください。その情報定義書は、まだ人間が読んで理解する形のものです。これをこのままコンピュータに渡しても、コンピュータは何も処理してくれません。

今日は、その情報定義書を「コンピュータが処理できる形」に組み立て直す1日です。このセッションが終わる頃には、「モデル」という言葉と「情報モデル」という言葉の違いを、自分の言葉で説明できるようになっています。

🗣️ 要約

• モデルとは、現実をある目的のために単純化した縮図であり、分類・命名・パターン化・単純化の4要素で構成される
• 情報モデルとは、モデルの考え方を情報に適用し、属性・関係・制約条件として明文化したもの
• 情報モデルは、要件（ペルソナの視点）と実装（システムの視点）を繋ぐ橋渡し役

🗣️ 要約

• モデルとは、現実をある目的のために都合よく単純化した縮図
• モデル化は分類・命名・パターン化・単純化という4つの要素で構成される
• モデル化する目的は、情報を誰でも同じように扱えるようにすること

「モデル」と聞いて、どんなイメージがありますか？ プラモデルでしょうか、ファッションモデルでしょうか、それとも数式のモデルでしょうか。

実はどれも共通点があります。モデルとは、いわば「現実を、ある目的のために都合よく単純化した縮図」のようなものです。

モデル化には、次の4つの要素が関わっています。

• 分類：似たものをグループにまとめる
• 命名：グループやものに名前をつける
• パターン化：繰り返し現れる規則を見つける
• 単純化：目的に不要な情報を削ぎ落とす

たとえば地図で考えてみましょう。日本地図は、日本列島の海岸線の細かい凹凸をすべて正確には描いていません。県ごとに色分け（分類）し、県名を書き（命名）、主要な道路や鉄道の通り方のパターンを線で表し（パターン化）、必要のない情報（土の質や標高の細かい変化など）は省いて（単純化）います。

なぜこんな面倒なことをするのでしょうか。少し考えてみてください。

答えは、「情報を誰でも同じように扱えるようにするため」です。モデル化することで、情報は特定の人の頭の中だけにあるものから、誰でも参照でき、コンピュータでも処理できるものに変わります。これが、モデリングする最大の理由です。

🗣️ 要約

• 情報モデルとは、ペルソナが価値を見出す情報を、コンピュータで処理可能な形に構造化したもの
• 情報モデルは「属性」「関係」「制約条件」の3要素で定義される
• 情報モデルは、要件（ペルソナの視点）と実装（システムの視点）を繋ぐ橋渡し役

モデルという考え方を、「情報」に対して適用したものが「情報モデル」です。

情報モデルとは、ペルソナが価値を見出す情報を、コンピュータで処理可能な形に構造化したものです。もう少し具体的に言うと、情報が持つ「属性」「関係」「制約条件」を定義したものが情報モデルです。

たとえば「本」という情報を考えると、属性は「タイトル」「著者」「価格」など、関係は「著者は複数の本を書く」、制約条件は「価格は0円以上でなければならない」といった形で定義されます。一方、「なんとなく面白そうな本」というような、頭の中にあるだけの曖昧なイメージは、属性も関係も制約も明文化されていないため、情報モデルには該当しません。

情報モデルは、「要件（ペルソナの視点）」と「実装（システムの視点）」を繋ぐ橋渡し役でもあります。ペルソナが欲しがっている情報を、エンジニアが実装できる形に翻訳する役割です。

ここまでで、モデルと情報モデルの違いについて、イメージはできましたか？ 「モデル」は一般的な単純化の考え方、「情報モデル」はそれを情報に適用し、属性・関係・制約として明文化したもの、という関係になります。

情報モデルを定義するには、オブジェクト指向分析設計やデータベース設計の知識が役立ちます。これらは後のセッションで少しずつ扱っていきます。

情報モデルは、最終的には次のような形で表現されます（詳しくは次のセッションで扱う「状態遷移」とあわせて完成させます）。

情報モデル: 本
  属性: タイトル(文字列), 著者(文字列), 価格(数値)
  関係: 1人の著者は複数の本を書く
  制約: 価格は0円以上

特に注意してほしいのは、情報モデルは「システムの都合」ではなく「ペルソナが価値を見出す情報」から出発するという点です。よくある間違いとして、いきなりデータベースのテーブル設計から考え始めてしまうケースがありますが、正しくは、まず情報モデルを定義し、そこから実装（テーブルやプログラム）に落とし込みます。順番を間違えると、ペルソナにとって不要な項目だらけのシステムができあがってしまいます。

世界で最も有名な「単純化されたモデル」の1つに、ロンドン地下鉄の路線図があります。1933年、電気技師のハリー・ベックが作ったこの路線図は、実際の地理的な距離や角度をほとんど無視し、駅と駅のつながり（トポロジー）だけを重視して描かれました。

実際の地図に忠実ではないのに、乗り換えのわかりやすさでは実際の地図をはるかに上回り、今も世界中の鉄道路線図のお手本になっています。「正確さ」よりも「目的に合った単純化」の方が価値を生む、というモデリングの本質を教えてくれる、痛快なエピソードです。

🗣️ 要約

• モデルと情報モデルの違い、情報モデルとテーブル設計の違い、実務での作成タイミングなどをAIに質問できる

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：

• 「モデルと情報モデルの違いを、別の例で説明して」
• 「情報モデルとデータベースのテーブル設計は何が違うの？」
• 「実務では情報モデルをどんなタイミングで作るの？」

🗣️ 要約

• 情報モデルとは、ペルソナの価値をコンピュータが扱える形（属性・関係・制約）に構造化したもの
• 次回は情報モデルに「状態遷移」を加え、必要な機能・プレゼンテーションを導き出す

今回学んだことを一言でまとめると、「情報モデルとは、ペルソナの価値をコンピュータが扱える形（属性・関係・制約）に構造化したもの」です。

次回は、この情報モデルに「状態遷移」という考え方を加え、そこからどんな機能や画面（プレゼンテーション）が必要になるかを導き出す方法を学びます。今回の「属性・関係・制約」の知識が土台になるので、しっかり押さえておきましょう。

🗣️ 要約

• モデル化の4要素（分類・命名・パターン化・単純化）
• 情報モデルを属性・関係・制約という言葉で説明できるか

以下の問いに答えられるか確認してみましょう：

• モデル化の4要素（分類・命名・パターン化・単純化）を挙げられますか？
• 「情報モデル」を、属性・関係・制約という言葉を使って説明できますか？

答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。

🗣️ 要約

• 参考資料は「The Elements of User Experience」（Jesse James Garrett）
• 発展課題は、開発テーマに登場する情報の属性・関係・制約を仮に書き出すこと

• 参考リンク: 「The Elements of User Experience」（Jesse James Garrett）
• 発展課題: 自分のチームの開発テーマに登場する情報を1つ選び、属性・関係・制約を仮に書き出してみましょう

🗣️ 要約

• 受講者からよく出る質問への回答例と、つまずきやすいポイントへの対処法をまとめている

このセクションは、受講者が理解を深めることをサポートする参考情報です。

🗣️ 要約

• モデルは一般概念、情報モデルは情報を対象にしたモデルという包含関係
• 制約はない場合もあるが、属性と関係は最低限言語化する必要がある
• オブジェクト指向分析設計やデータベース設計の知識は、情報モデルを実装に落とし込む際の型として役立つ

🗣️ 要約

• いきなりテーブル設計から考え始めてしまいやすい
• 情報モデルと機能を混同してしまいやすい