📖 テーマ設定
🔊 音声設定
1.2
1.0
1.0
▶️ 再生コントロール
🎵 BGM設定
0.3
🔔 効果音設定
0.3

Day 2 イントロ・モデルとは

概要

  • 日程: Day 2 / セッション 01
  • 時間: 9:00-9:30
  • 形式: 座学
  • ゴール: 「モデル」「モデリング」の意味を身近な具体例(地図・家系図・路線図など)を用いて説明できる
  • 学習形式: AI協働型(疑問はAIに即座に質問しながら理解を深める)

導入(5分)

Day 1では「情報とは何か」「ペルソナにとっての価値は何か」を考え、情報を洗い出して整理・分類しました。情報定義書・ペルソナ・整理分類済み情報定義書という3つの成果物が手元にあるはずです。

しかし、このままではまだ「コンピュータに渡せる形」ではありません。コンピュータは「ペルソナの気持ち」を理解できないからです。コンピュータが理解できるように、情報を構造化された形に翻訳する作業が必要です。

その翻訳作業を「モデリング」と呼びます。今日は1日かけて、Day 1で集めた情報を「情報モデル」へと変換し、そこから「機能」と「画面」を導き出すまでを体験します。

Day 2の最初のセッションは、その出発点となる「モデルとは何か」を身近な例で腹落ちさせる時間です。

本編(20分)

1. モデルとは何か:地図の話から始める

「東京駅から渋谷駅まで」と聞いて何を思い浮かべますか?多くの人は山手線の路線図を思い浮かべるはずです。

実は、あの路線図は実物の鉄道とはぜんぜん違います。線路は本当はカーブしていて、駅と駅の間隔も均等ではありません。それでも「乗換に必要な情報」だけが残っているから、誰でも迷わずに使えます。

これがモデルです。

モデル = 現実の中から「目的に必要な要素だけ」を取り出して表現したもの

身近な例をいくつか挙げます。

現実 モデル 残した情報 捨てた情報
地形 地図 道・建物の位置 建物の色・におい
家族 家系図 血縁・続柄 性格・職業
鉄道 路線図 駅・乗換 線路の実形状
人体 解剖図 臓器の配置 体温・声

ここがポイント

モデルの本質は「何を捨てるかを決めること」です。情報を増やすのではなく、必要なものだけを残して単純化します。「何を残し、何を捨てるか」の判断は、誰のために作るか(=ペルソナ)で変わります。

コラム:ロンドン地下鉄図の革命

1933年、ハリー・ベックという製図工が、ロンドン地下鉄の「実際の地理を完全に無視した」路線図を提案しました。当時の上層部は「地理的に正確でない地図など使い物にならない」と猛反対したそうです。ところが試験運用すると乗客から大絶賛。なぜか?乗客にとって必要なのは「どこで乗り換えればいいか」だけで、地下何メートルを線路が走っているかなど興味がなかったのです。このベック式図は今も世界中の地下鉄図のひな型になっています。「ペルソナにとって必要な情報だけを残す」がいかに強力かを示した歴史的事件です。

2. モデリングの4つの行為

モデルを作ること(モデリング)は、4つの行為の組み合わせです。

flowchart LR A["現実の混沌"] --> B["分類"] B --> C["名前付け"] C --> D["パターン化"] D --> E["単純化"] E --> F["モデル"]
  • 分類:似たものをまとめる(例:果物 / 野菜)
  • 名前付け:まとめたものに識別できる名前を付ける(例:「リンゴ」「ミカン」)
  • パターン化:共通の構造を見つける(例:果物は「名前・色・産地」を持つ)
  • 単純化:目的に不要なものを捨てる(例:果物の重さは要らない、なら捨てる)

たとえばコンビニのおにぎり棚を思い出してください。「ツナマヨ」「鮭」「梅」が並んでいます。これらは「おにぎり」というカテゴリで分類され、それぞれに名前が付き、すべて「具材・価格・賞味期限」という共通のパターンを持ち、「製造工場の社員数」のような不要な情報は省かれています。すでに立派なモデリングの成果です。

ここがポイント

日常生活の中で、私たちは無意識にモデリングを行っています。意識的にこの4つを使えるようになれば、どんな業務でも「コンピュータに渡せる形」へ翻訳できます。

コラム:「すべての地図は嘘である」

地図学者の有名な格言です。地球は丸いのに、地図は平面。どんなに正確に書いても必ず歪みます。「メルカトル図法」のグリーンランドは異常に大きく見えますが、実際はオーストラリアの方が3倍大きい。「正確さ」と「使いやすさ」は両立しないことが多く、目的に応じて何を犠牲にするかを決めるのがモデリングの本質です。

3. なぜモデリングするのか

理由は3つに集約できます。

  1. コンピュータで扱えるようにするため:曖昧な現実は処理できない。属性と関係に分解する必要がある
  2. チームで共有するため:頭の中のイメージだけでは伝わらない。図や表にして合意する
  3. 再利用するため:「顧客」「商品」「注文」のような典型パターンは、業務が違っても使い回せる
flowchart TB R["現実世界"] --> M["モデル"] M --> C["コンピュータで処理"] M --> T["チームで合意"] M --> P["他案件で再利用"]

ここがポイント

モデリングはコードを書く前の最も重要な作業です。「設計図なしで家を建てる」ことはしません。同じく「モデルなしでシステムを作る」と必ず手戻りが発生します。

コラム:UMLが生まれた理由

1990年代、世界中の研究者がそれぞれ独自の「モデリング記法」を発明していました。Booch法、OMT法、OOSE法など群雄割拠の時代です。「同業者なのにお互いの図が読めない」という問題が深刻になり、3人の研究者(通称「3人組」)が標準を作りました。それがUML(Unified Modeling Language)です。モデリングが「みんなで共有するため」の道具であることを、業界全体で再認識した出来事でした。

💬 AIに聞いてみよう

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

  • 「モデルと設計図は同じですか?」
  • 「身近で『悪いモデル』の例を教えて」
  • 「データとモデルの違いは何ですか?」

まとめ(5分)

今日学んだことは1つに集約できます。モデルとは「目的のために、必要な情報だけを残して単純化した表現」。モデリングは「分類・名前付け・パターン化・単純化」という4つの行為で成り立っています。

次のセッション(Session02)では、いきなり身の回りの物(コンビニ・図書館・電車など)からモデルを取り出す実習をやります。頭で理解したことを、手で確かめる時間です。

🔄 振り返りチェック

  • モデルの定義を、地図を例にして1分で説明できますか?
  • モデリングの4つの行為を順番に言えますか?
  • 「モデル」と「現実」が違う理由を、誰かに説明できますか?

補足資料

  • 参考リンク:『データモデリング入門』(梅田弘之)、ハリー・ベックのロンドン地下鉄路線図の歴史
  • 発展課題:自宅の冷蔵庫の中身を「モデル化」してみる。何を捨てる?何を残す?

学習ガイド

想定される質問と回答例

質問 ヒント
モデルを精緻に作ると良いのでは? 精緻すぎると現実そのものになり、単純化のメリットが消える
モデルに正解はありますか? ない。目的とペルソナによって最適解が変わる
「データ」と「モデル」は何が違う? データは個別の事実、モデルは事実の構造を示す

つまずきやすいポイント

つまずきポイント ヒント
「現実をそのまま再現する」と考える モデルの本質は「捨てること」
モデリングをコードと無関係に感じる モデルがあるからコードが書ける。設計図なしで家は建たない
「うちの業務は特殊だから既存モデルは使えない」 共通パターンは必ず存在する。完全にゼロから作ることは稀
読み上げを開始します...

AIに質問する