情報モデルの抽出と状態遷移定義
概要
- 日程: Day 2 / セッション 04
- 時間: 10:40-11:25
- 形式: 実習
- ゴール: Day 1の情報定義書から自チームの情報モデルを3つ以上抽出し、それぞれの状態遷移図をdraw.io等で作成して、CRUDを網羅した上でお客様視点でレビューできる
- 学習形式: AI協働型(情報モデル候補の提案、状態遷移のたたき台生成、お客様視点のレビュー、すべてAIに依頼する)
導入(5分)
ここまでで「情報モデルとは何か」「状態遷移を書くと機能と画面が決まる」ことを学びました。いよいよ自チームの開発テーマで実践します。
Day 1で作った3つの成果物を必ず開いておきましょう。
- 開発テーマ
- 整理分類済み情報定義書
- ペルソナのプロフィール
ここから情報モデルを3つ以上抽出し、それぞれの状態遷移図を描きます。45分という時間は短いようで長いです。AIと協働で進めれば十分に終わります。
本編(5分の解説 + 35分の実習)
1. 進め方の全体像
2. ステップごとのコツ
Step 1:候補抽出(5分)
Day 1の整理分類済み情報定義書を見て、「ライフサイクルを持ちそうな名詞」をマークします。マスタデータ的なものより、変化していくもののほうが面白い題材になります。
Step 2:3つに絞る(3分)
ペルソナにとっての価値が大きい順に3つ選びます。「これがないとサービスが成立しない」という核を選ぶのがコツです。
Step 3:属性・関係・制約の定義(10分/1モデルあたり3-4分)
Session02で練習した3観点を再利用します。AIに「他に必要な属性は?」と尋ねるのが効率的です。
Step 4:状態遷移図作成(12分/1モデルあたり4分)
draw.io(https://app.diagrams.net/)を開き、状態遷移図のテンプレートから始めます。
Step 5:CRUDレビュー(3分)
各状態に対して「作る・読む・更新する・削除する」が網羅されているかチェック。
Step 6:お客様視点レビュー(2分)
Day 1で定義したペルソナの立場で「この状態遷移で困らないか」を問い直します。
ここがポイント
完璧主義を捨てること。後から何度でも直せます。45分以内に「3つそろえて、一回レビュー」をやりきるのが目標です。
コラム:draw.ioの本名は「diagrams.net」
このツール、元々は「draw.io」というドメインで提供されていました。Gliffyの代替として無料で使える図ツールが欲しいユーザーに大ヒットしました。2020年に「diagrams.net」というドメインに移行しています。理由は「.io」ドメインの政治的問題(イギリス領インド洋地域の管理権問題)を避けるためだとか。ツールの背後にも国際情勢が絡んでいる、おもしろい話です。
実習・演習(35分)
課題
自チームの開発テーマから情報モデルを3つ以上抽出し、それぞれの状態遷移図をdraw.ioで作成する。完成した3つの状態遷移図をチーム共有する。
進め方タイムスケジュール
| 時間 | 作業 |
|---|---|
| 5分 | 候補抽出と3つ選定 |
| 10分 | 属性・関係・制約の定義(3モデル分) |
| 12分 | 状態遷移図の作成(draw.io) |
| 5分 | CRUDレビュー |
| 3分 | お客様視点レビュー(ペルソナで読み直す) |
成果物
| 情報モデル名 | 主要属性 | 状態遷移図(draw.io URL) |
|---|---|---|
| 例:レシピ | レシピID、タイトル、材料、手順、… | https://app.diagrams.net/... |
| 例:投稿 | 投稿ID、本文、投稿日時、… | https://app.diagrams.net/... |
| 例:ユーザー | ユーザーID、表示名、登録日、… | https://app.diagrams.net/... |
ヒント
AIプロンプト例(情報モデル候補抽出)
私たちのチームは「家計簿アプリ」を開発しています。
ペルソナは「家計を見える化したい30代会社員」です。
Day 1で作った情報定義書の主要項目は以下の通りです:
- 収入、支出、カテゴリ、口座、月次レポート…
このテーマでライフサイクルを持つ「情報モデル」を3〜5個候補として提案してください。
それぞれに状態が何個くらい想定されるかも教えてください。
AIプロンプト例(状態遷移のたたき台生成)
情報モデル「支出記録」について状態遷移図を考えています。
想定される業務シナリオ:入力 → 確定 → カテゴリ振り分け → 月次集計対象に
編集や削除のシナリオもあります。
考えられる状態と遷移を、Mermaid記法でたたき台として出してください。
AIプロンプト例(お客様視点レビュー)
以下の状態遷移について、ペルソナ「家計を見える化したい30代会社員」の立場でレビューしてください。
「入力 → 確定 → 月次集計対象 → アーカイブ」
- 不便な点
- 使いにくい遷移
- 見逃している状態(例:誤入力の修正フローがない、など)
を指摘してください。
💬 AIに聞いてみよう
- 「この状態遷移で『戻る』フローが必要な箇所はどこ?」
- 「マスタデータ(カテゴリ等)にも状態遷移は必要?」
- 「状態数が多すぎて複雑。どう整理すれば良い?」
まとめ(5分)
3つの状態遷移図がそろうことで、明日以降の設計・実装の「設計図の核」が完成しました。今日の午後はこれを元に「機能一覧」「画面一覧」「非機能要件」「モックアップ」を一気に作っていきます。
次のセッション(Session05)はその第一弾。状態遷移図から「機能とプレゼンテーション」を抽出する実習です。
🔄 振り返りチェック
- 3つの情報モデルを抽出できましたか?
- それぞれの状態遷移図はCRUDを網羅していますか?
- お客様視点でレビューして、修正した点はありましたか?
補足資料
- 参考リンク:draw.io(https://app.diagrams.net/)、Mermaid state diagram公式ドキュメント
- 発展課題:チームメンバー間で状態遷移図を交換レビューする
学習ガイド
想定される質問と回答例
| 質問 | ヒント |
|---|---|
| 3つに絞れない、5つ作りたい | 3つに集中して質を上げる。残りはDay 3以降で追加可能 |
| 状態が多すぎる(10個以上) | 業務上の意味で粒度を上げる。「下書き種別1〜5」を「下書き」に統合など |
| 「削除」状態を含めるべき? | 物理削除なら状態には含めない。論理削除(削除済フラグ)なら含める |
つまずきやすいポイント
| つまずきポイント | ヒント |
|---|---|
| 開発者目線で状態を作る | 必ずペルソナ目線で見直す。ペルソナが使う言葉で状態名を付ける |
| 機能一覧と状態遷移を混同する | 機能は「動作」、状態は「位置」。両方必要だが別物 |
| Mermaidとdraw.ioを両方使い分けようとする | 1ツールに統一して時間節約。チームで共有しやすいdraw.ioを推奨 |