（演習）情報モデルの抽出と状態遷移の定義

• 日程: Day 2 / セッション4
• 時間: 10:10-11:50（100分）
• 形式: 演習
• ゴール: 整理分類済み情報定義書から情報モデルを抽出し、draw.ioで状態遷移図を作成し、そこから機能一覧とプレゼンテーション一覧を抽出できる
• 学習形式: ハンズオン実習（AIサポートあり）

🗣️ 要約

• Day1の整理分類済み情報定義書を、コンピュータで扱える形に組み立て直す作業
• 「状態」という時間の流れを与えることで、情報が初めてシステムとして動く形になる
• 成果物は「情報モデル一覧」「状態遷移図」「機能一覧」「プレゼンテーション一覧」の4点で、Day4の実装でそのまま設計図として使う

前のセッションで、CRUD（Create・Read・Update・Delete）を使うと状態遷移から機能とプレゼンテーションが抽出できる、という話をしました。ここからは、それを実際に手を動かしてやってみます。

今日ここでやることは、Day1で作った「整理分類済み情報定義書」を、コンピュータで扱える形に組み立て直す作業です。情報は今のところ、まだ紙の上のアイデアの状態です。ここに「状態」という時間の流れを与えることで、初めてシステムとして動かせる形になります。

このセッションが終わる頃には、「情報モデル一覧」「状態遷移図」「機能一覧」「プレゼンテーション一覧」という4つの成果物が手元にできています。これはDay4の実装で、そのまま設計図として使うものです。

🗣️ 要約

• 情報モデルの抽出→状態遷移図の作成→機能・プレゼンテーションの抽出、という3段階で進む
• CRUD（Create・Read・Update・Delete）の4動詞が状態遷移の軸になる
• 状態遷移図の矢印が機能に、状態（箱）がプレゼンテーションに対応する

🗣️ 要約

• 情報モデルの抽出は、情報定義書の情報を扱いやすい単位に切り分ける作業
• ひとまとまりの属性を持つものはモデル、他のモデルに付属するものは属性として扱う
• 開発テーマの中核となる情報モデルは、通常3〜7個程度に収まる

情報モデルとは、ペルソナが価値を見出す情報を、コンピュータで処理可能な形に構造化したものでした。抽出の作業は、料理に例えると「買ってきた食材（情報定義書の情報）を、レシピに使える単位（情報モデル）に切り分ける」ようなものです。

たとえば家計簿システムというテーマなら、情報定義書には「支出」「収入」「カテゴリ」「予算」「日付」といった情報が並んでいるはずです。このうち「支出」は、金額・日付・カテゴリ・メモといった属性を持つ、ひとまとまりの情報モデルとして抽出できます。一方で「日付」単体は、支出や収入に付属する属性であり、それ自体を独立した情報モデルにする必要はありません。属性なのかモデルなのかを見分けるのが、この作業の最初のポイントです。

ここで少し考えてみてください。あなたのチームの開発テーマで、「これは独立した情報モデルだ」と言えそうなものはいくつありますか？ 3〜7個程度に収まることが多いです。多すぎる場合は、属性として吸収できないか見直してみましょう。

🗣️ 要約

• 状態遷移図は、情報モデルが新規登録・更新・削除を経てどう変化するかをCRUDの4動詞で描いたもの
• 状態遷移図の矢印はのちに機能になり、状態（箱）はプレゼンテーション（画面）のヒントになる
• 推奨ツールはdraw.ioで、先に手描きで固めてから清書してもよい

情報モデルが決まったら、それぞれの情報モデルが時間の経過とともにどう変化するかを図にします。これが状態遷移図です。

状態遷移は、いわば「情報の一生」を描くようなものです。生まれて（新規登録）、育って（更新）、時には消えていく（削除）。この一生をCRUDの4つの動詞で追いかけていきます。

先ほどの「支出」情報モデルなら、次のような状態遷移が考えられます。

この図の矢印1本1本が、後で「機能」になります。「新規入力」は新規登録機能に、「内容を確認」は一覧・詳細表示機能に、というように対応します。そして四角い箱（状態）は、それぞれ画面（プレゼンテーション）のヒントになります。「登録済み(下書き)」の状態を見せる画面、「承認済み」の状態を見せる画面、といった具合です。

推奨ツールはdraw.ioです。付箋やホワイトボードで一度手で描いてから、draw.ioで清書する進め方でも構いません。

• 状態遷移図の目的は「正確な業務フロー図」を描くことではなく、「機能とプレゼンテーションの抽出に必要な粒度」で情報モデルの変化を捉えることです
• 特に注意してほしいのは、状態を細かく描きすぎることです。「入力中」「入力エラー」「入力完了」のように画面上の一時的な状態まで全部盛り込むと、図が複雑になりすぎて機能一覧に落とし込みにくくなります。よくある間違いとして「バリデーションエラー」を状態として描いてしまうケースがありますが、これは状態ではなく機能内部の分岐として扱うのが適切です
• 逆に粗すぎる（状態が1〜2個しかない）場合は、CRUDのどれかが図に現れていない可能性があります。4つの動詞が図のどこかに出てきているか確認しましょう

状態遷移図のルーツをたどると、電気回路の設計で使われてきた「有限状態機械（Finite State Automaton）」という考え方に行き着きます。信号機が「赤→青→黄→赤」と決まった順序でしか状態を変えられないのも、実は状態遷移図で説明できる仕組みです。ソフトウェアの世界に限らず、エレベーターのボタン、自動販売機のお金の投入、ゲームのキャラクターの状態（待機・攻撃・被弾）まで、身の回りは状態遷移図だらけです。一度この見方を覚えると、駅の券売機やコンビニのレジ画面を見るたびに「これは今何ステートだろう」と考えてしまう、ちょっとした職業病になります。

🗣️ 要約

• 情報モデルか属性かの判断、状態が多すぎる場合の整理、CRUDの見落としの確認などをAIに相談できる

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

• 「（開発テーマ）の『〇〇』という情報は、独立した情報モデルにすべき？それとも属性にすべき？」
• 「この状態遷移図、状態が多すぎる気がするけど、どう整理すればいい？」
• 「CRUDのうち、この図にはUpdateが出てきていない気がする。見落としがないか一緒に確認して」

🗣️ 要約

• 情報モデルの抽出→状態遷移の定義→レビューと再定義→機能・プレゼンテーションの抽出、という4段階の演習

🗣️ 要約

• 情報モデルを3〜7個洗い出し、中核となる1〜2個についてdraw.ioで状態遷移図を作成する
• 作成した状態遷移図をチーム内でレビューし、最低1回は修正・再定義する
• 状態遷移図の矢印から機能一覧を、状態（箱）からプレゼンテーション一覧を抽出する

チームで次の4段階を順番に進めてください。

1. 情報モデルの抽出：整理分類済み情報定義書を見ながら、独立した情報モデルを3〜7個洗い出す
2. 状態遷移の定義：抽出した情報モデルのうち、開発テーマの中核となるもの（1〜2個）について、draw.ioで状態遷移図を作成する。CRUDの4つの動詞が図のどこかに含まれているか確認する
3. お客様視点のレビューと再定義：作った状態遷移図をチーム内で交換し、「自分がペルソナだったら、この状態遷移で困らないか」をレビューする。レビューを受けて、状態遷移図を最低1回は修正・再定義する
4. 機能・プレゼンテーションの抽出：状態遷移図の矢印（CRUD操作）から機能一覧を、状態（箱）からプレゼンテーション一覧を書き出す

🗣️ 要約

• 情報モデル一覧、情報モデルの状態遷移図（draw.io）、機能一覧、プレゼンテーション一覧の4点

• 情報モデル一覧
• 情報モデルの状態遷移図（draw.io）
• 機能一覧
• プレゼンテーション一覧

🗣️ 要約

• レビューと再定義の工程は、1人では気づけない抜け漏れを見つけるため省略しない
• 機能一覧作成に詰まったら、矢印を1本ずつ指でなぞりながら機能を言語化するとよい
• 情報モデルの個数が3個未満・8個以上になった場合は、AIに粒度が適切か相談できる

• 手順3の「レビューと再定義」は面倒に感じても省略しないでください。1人で作った図には必ず抜け漏れがあります。他の人の目が入って初めて気づく状態遷移が必ず出てきます
• draw.ioの操作で迷ったら、AIに「draw.ioで状態遷移図を描くときの基本的な図形の使い方を教えて」と聞いてみましょう
• 機能一覧を書くときに手が止まったら、状態遷移図の矢印を1本ずつ指でなぞりながら「この矢印は何をする機能か」を声に出してみると整理しやすくなります
• うまく情報モデルが3個未満、あるいは8個以上になってしまう場合は、無理に個数を合わせようとせず、AIに「このモデル一覧の粒度は適切か」と相談してみてください

🗣️ 要約

• 状態遷移図は、情報モデルと機能・プレゼンテーションをつなぐ翻訳機である
• 情報モデル（名詞）にCRUD（動詞）で時間の流れを与えることで、画面と機能という具体的な形が見えてくる
• 次回は「開発モデル」を学び、情報の設計とシステムの設計の役割分担を扱う

今回学んだことを一言でまとめると、「状態遷移図は、情報モデルと機能・プレゼンテーションをつなぐ翻訳機である」ということです。情報モデルという名詞に、CRUDという動詞で時間の流れを与えることで、初めて画面と機能という具体的な形が見えてきました。

次回は「開発モデル」を学びます。今日作った機能一覧・プレゼンテーション一覧を、どういう手順・体制で作っていくかを考えるのが開発モデルです。今日の「情報の設計」と、次回以降の「システムの設計」がどう役割分担するのかを意識しながら聞いてみてください。

🗣️ 要約

• 情報モデルとその属性の違いを、開発テーマの例で説明できるか
• 状態遷移図の矢印と箱が、それぞれ機能・プレゼンテーションに対応することを説明できるか

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

• 情報モデルと、その属性の違いを、開発テーマの例を使って説明できますか？
• 状態遷移図の矢印と箱が、それぞれ何に対応するか説明できますか？

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

🗣️ 要約

• 参考リンクはdraw.io公式サイト
• 発展課題は、抽出した情報モデル同士の関係（1対多、多対多など）を図に追加すること

• 参考リンク: draw.io公式サイト（オンライン版はインストール不要で利用可能）
• 発展課題: 抽出した情報モデル同士の関係（1対多、多対多など）を、簡単な図に追加で描いてみましょう

🗣️ 要約

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

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

🗣️ 要約

• 情報モデルの個数に決まった正解はなく、中核となる名詞を数えると3〜7個程度に収まりやすい
• 「削除済み」状態の必要性は、物理削除か論理削除かによって変わる
• 機能は「システムが行う処理」（矢印＝CRUD操作）、プレゼンテーションは「利用者が見る画面」（箱＝状態）に対応する

🗣️ 要約

• 状態遷移図に画面上の一時的な状態（入力中、エラー中など）を書き込みすぎて複雑になりやすい
• 情報モデルと機能を混同し、状態遷移図の前に機能一覧を作ろうとしてしまいやすい
• draw.ioでの作図に時間がかかりすぎることがある