Day 2 まとめ

• 日程: Day 2 / セッション 10
• 時間: 15:45-16:00
• 形式: 振り返り
• ゴール: 「情報モデル → 状態遷移 → 機能・プレゼンテーション」の流れを口頭で説明でき、「情報の設計」と「システムの設計」を分離する考え方を例示できる
• 学習形式: AI協働型（AIに問題を出させ、自分の言葉で答える形式）

Day 2、お疲れさまでした。今日は「身近なモデリング」から始まって、自チームの情報モデル、状態遷移、機能・画面、非機能要件、UI、モックアップまでの一気通貫を体験しました。

成果物が手元に揃っているはずです。

• 情報モデル一覧（3つ以上）
• 状態遷移図（3つ以上）
• 機能一覧（15以上）
• プレゼンテーション一覧（10以上）
• 非機能要件一覧（10以上）
• UIモックアップ（3画面以上）

たった1日でここまで形にできました。秘訣は「情報モデルが軸」だったことです。情報モデルを起点に、必要な機能・画面が機械的に導き出せることを体感したはずです。

「情報モデル → 状態遷移 → 機能・プレゼンテーション」がDay 2の背骨です。

今日学んだ最大の概念は「情報の設計とシステムの設計を分離する」ことです。

この分離ができていると、たとえばUIフレームワークをReactからVueに変えても、情報モデルや状態遷移は変えなくて済みます。長く生き残るシステムは、必ずこの分離ができています。

「情報」は10年生き、「システム」は3年で陳腐化します。情報を独立して設計しておけば、システム部分だけ作り変えれば良いのです。これがDay 1のIA（情報アーキテクチャ）が「アーキテクチャ」と呼ばれる理由でもあります。

Twitterは2006年のサービス開始以来、バックエンドの技術を何度も変えています。Ruby on Rails → Scala → 独自プラットフォーム。それでも「ツイート」「フォロー」「タイムライン」という情報モデルは20年近く変わっていません。情報モデルが安定しているから、システムは大胆に作り変えられるのです。逆の例も多くあります。情報モデルがコードに埋め込まれているシステムは、技術更新のたびに莫大な工数がかかります。

チーム内で、または個人で次の問いに答えてみましょう。

問1：今日一番「これは武器になる」と思った概念は？

問2：状態遷移を書く前と後で、自分の中で何が変わったか？

問3：Day 3に持ち越したい疑問は？

• 「Day 2で学んだ概念について、5問の確認問題を出して。私が答えるから採点して」
• 「『情報の設計とシステムの設計の分離』を、IT知識ゼロの友達に説明するには？」
• 「明日（Day 3）の設計アプローチ学習にどう繋げると効果的？」

Day 2のキーフレーズは2つ。

1. 「状態遷移を書けば、機能と画面が決まる」
2. 「情報の設計とシステムの設計を分離する」

明日（Day 3）は「どう作るか（設計アプローチ）」の世界に入ります。DOA／MDA／SOA／ROA／OOADという5つの設計アプローチ、MVC／MVVM／DDDという3つのアーキテクチャパターン、永続化（ACID）、通信（REST/JSON）、実行方式、開発手法。盛りだくさんですが、すべて今日の成果物の上に積み上げる話です。

しっかり休んで明日に備えましょう。

• 「情報モデル → 状態遷移 → 機能・プレゼンテーション」の流れを、チームメンバーに30秒で説明できますか？
• 「情報の設計」と「システムの設計」を分離する理由を1つ言えますか？
• 今日の成果物6種類のうち、最も自信のあるものはどれですか？

• 参考リンク：Day 1〜Day 2の各セッション資料、IPA システム設計の基礎
• 発展課題：Day 1の成果物と今日の成果物を1つのドキュメントにまとめて、ペルソナにレビューしてもらうイメージで読み返す