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

Day2まとめ

概要

  • 日程: Day 2 / セッション10
  • 時間: [16:30-16:40]
  • 形式: 座学
  • ゴール: 「情報モデル→状態遷移→機能/プレゼンテーション抽出」の流れを図解して説明できる
  • 学習形式: 対話型解説

導入(2分)

🗣️ 要約

  • Day2で行った情報モデル抽出・状態遷移図・非機能要件定義・UI設計・モックアップ作成は、実は1本の線でつながっている

今日1日、いろいろな作業をしてきました。情報モデルを抽出し、状態遷移図を描き、非機能要件を定義し、UIを考え、モックアップまで作りました。

ここで一度立ち止まって、今日やったことが「1本の線」でつながっていることを確認しましょう。バラバラの作業に見えたものが、実は一直線に並んでいたと気づくはずです。

本編(6分)

🗣️ 要約

  • Day2の作業順序は「情報モデル→状態遷移(CRUD)→機能一覧/プレゼンテーション一覧→非機能要件/UIモックアップ」
  • 情報の設計(情報モデル)を先に決めることで、機能もUIも迷わず作れる
  • 「形態は機能に従う」という建築の考え方と同じ順序である

1. 今日1日の流れを1枚の図にする

🗣️ 要約

  • Day1〜Day2の成果物は、情報定義書→情報モデル→状態遷移図→機能一覧/プレゼンテーション一覧→非機能要件/UIモックアップの順に流れる
  • 情報の設計(情報モデル)が先、システムの設計(機能・UI)は後、という順序が到達目標No.4そのもの
  • 「形態は機能に従う」という建築の考え方が、ソフトウェア設計にも当てはまる

今日の最初のセッションで、「なぜモデリングするのか」という問いから始めました。答えは「情報を普遍的に利用可能にし、コンピュータで扱えるようにするため」でしたね。

その答えを実際にたどってきたのが、今日という1日です。順番を思い出してみましょう。

  • 整理分類済み情報定義書(Day1の成果物)を、情報モデルという形に構造化した
  • 情報モデルに状態遷移(CRUD)を定義した
  • 状態遷移から、機能一覧とプレゼンテーション一覧を抽出した
  • 機能一覧をもとに非機能要件を定義した
  • プレゼンテーション一覧をもとに、UIを設計しモックアップにした

図にすると、次のようになります。

flowchart LR A["整理分類済み情報定義書 (Day1の成果物)"] --> B["情報モデル一覧"] B --> C["状態遷移図 (CRUD)"] C --> D["機能一覧"] C --> E["プレゼンテーション一覧"] D --> F["非機能要件一覧書"] E --> G["UIモックアップ"]

ここで少し考えてみてください。もし「情報モデル」を作らずに、いきなり画面のモックアップから作り始めていたら、何が起きたでしょうか。おそらく、途中で「あれ、この項目はどこに保存すればいいんだっけ」と迷子になっていたはずです。情報モデルという地図があったから、機能もUIも迷わず作れたのです。

ここがポイント

今日の学びを一言でまとめると、「情報の設計(情報モデル)が先、システムの設計(機能・UI)は後」です。これは到達目標No.4「情報の設計とシステムの設計を分離して開発を進められる」そのものです。

順番を逆にしてしまう、つまり画面から先に作ってしまうのはよくある失敗です。画面は直感的に作りやすいので、つい手を出したくなりますが、後で「この項目、どのデータと紐づくんだっけ」と手戻りが発生しやすくなります。

コラム

建築の世界には「形態は機能に従う(Form follows function)」という有名な言葉があります。建物の見た目より先に、その建物が何のために使われるかを決めるべきだ、という考え方です。

今日皆さんがやったことも、まさにこれと同じでした。画面の見た目(プレゼンテーション)より先に、情報の構造(情報モデル)を決めたのです。100年以上前に建築家が言っていたことが、ソフトウェア設計にもそのまま当てはまるというのは、なんだか面白い話だと思いませんか。

💬 AIに聞いてみよう

🗣️ 要約

  • 情報モデルを作らずに開発を始めた場合に起きる問題や、自分たちの情報モデルと明日の設計との関係をAIに質問できる

今日の内容を振り返って、疑問があればAIに聞いてみましょう。たとえば:

  • 「情報モデルを作らずに開発を始めると、具体的にどんな問題が起きる?」
  • 「自分たちの開発テーマの情報モデルは、明日の設計にどう関係する?」

まとめ(2分)

🗣️ 要約

  • 情報モデルという地図があるから、機能もUIも迷わず設計できる
  • 明日Day3では、今日の機能一覧・プレゼンテーション一覧をDOA/MDA/SOA/ROA/OOADなどの設計アプローチやMVC/MVVM/DDDといった多層アーキテクチャに落とし込む

今日学んだことを一言でまとめると、「情報モデルという地図があるから、機能もUIも迷わず設計できる」です。

明日(Day3)は、今日抽出した機能一覧とプレゼンテーション一覧を、実際にどんな「型」(アーキテクチャ)に落とし込むかを学びます。DOA、MDA、SOA、ROA、OOADといった設計アプローチや、MVC・MVVM・DDDといった多層アーキテクチャが登場します。今日の情報モデルの知識が、そのまま土台になりますので、情報モデル一覧と状態遷移図は手元に残しておいてください。

🔄 振り返りチェック

🗣️ 要約

  • 情報モデルから機能一覧・プレゼンテーション一覧を抽出した手順を説明できるか
  • 画面より先に情報モデルを作るべき理由を説明できるか

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

  • 情報モデルから機能一覧・プレゼンテーション一覧をどうやって抽出したか、順を追って説明できますか?
  • なぜ画面(プレゼンテーション)より先に情報モデルを作るべきなのか、理由を説明できますか?

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

補足資料

🗣️ 要約

  • 参考リンクは「Form follows function」(建築のモダニズム運動の標語)
  • 発展課題は、自分たちの情報モデル一覧に状態遷移が未定義のものがないか確認すること
  • 参考リンク: 「Form follows function」(建築におけるモダニズム運動の標語)
  • 発展課題: 自分たちの情報モデル一覧を見返し、まだ状態遷移が定義できていない情報モデルがないか確認してみましょう

学習ガイド

🗣️ 要約

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

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

想定される質問と回答例

🗣️ 要約

  • 情報モデルとデータベースのテーブルは似ているが同じではなく、情報モデルはペルソナ視点、テーブルはシステム視点の構造
  • 情報モデルは実装を進める中で修正・再定義してよい
質問 ヒント
情報モデルとデータベースのテーブルは同じもの? 似ているが同じではない。情報モデルはペルソナ視点の「情報の構造」で、テーブルはシステム視点の「保存の構造」。この違いはDay3の「永続化」「インピーダンス・ミスマッチ」で詳しく扱う
今日作ったものを明日以降修正してもいい? むしろ推奨する。実装を進める中で情報モデルの過不足に気づくのは自然なこと。「再定義」も含めて情報モデルの一部

つまずきやすいポイント

🗣️ 要約

  • 今日1日の作業がバラバラの単発作業に感じられ、つながりが見えにくいことがある
つまずきポイント ヒント
今日1日の作業がバラバラの単発作業に感じられ、つながりが見えない 本セッションの流れ図(情報定義書→情報モデル→状態遷移→機能/プレゼンテーション)を見ながら、自分たちが作った成果物を実際に並べてみると、つながりが実感しやすい
読み上げを開始します...

AIに質問する