状態遷移から機能とプレゼンテーションを抽出する

• 日程: Day 2 / セッション 4
• 時間: [11:15-12:00]
• 形式: 演習
• ゴール: 自分の開発テーマの主要な情報モデルについて（条件）、状態遷移図を作成し、そこから機能一覧とプレゼンテーション一覧を抽出できる（行動）。1つの情報モデルあたり機能5種以上を、由来した遷移とともに記述できる（基準）
• 学習形式: ハンズオン実習（AIサポートあり）

前のセッションで、家計簿の「支出記録」から機能5種と画面5枚が“自動的に”出てくるデモを見ました。

今度はあなたの番です。デモと同じ手順を、自分の開発テーマの情報モデルでやります。

始める前に1つだけ問いかけです。デモでは手順が3ステップでした。覚えていますか？

1. 状態遷移図を書く
2. 矢印を機能に変換する（Read は2つに分ける）
3. 機能に画面を割り当てる

この演習では、これに**ステップ1.5「お客様視点のレビュー」**が加わります。状態遷移図を書いた直後に、ペルソナの目で見直すのです。レビュー役はAIに演じてもらいます。設計を直すコストが一番安いのは、図の段階だからです。

手順は4ステップです。所要時間の目安も添えます。

まず「主要な情報モデル」の選び方です。ペルソナが一番頻繁に触る情報モデルを選んでください。家計簿なら「支出記録」、レシピ類推サービスなら「レシピ」、オークションなら「出品商品」です。逆に「カテゴリ」のようなマスタ的な情報モデルは、主要ではあっても遷移が単調なので、この演習の1つ目には向きません。

家計簿システム「支出記録」の完成例一式です。あなたはこれと同じ形式のものを自分のテーマで作ります。

状態遷移図

機能一覧（支出記録・5種）

プレゼンテーション一覧（支出記録・5画面）

• 3つの成果物は一本の線でつながっている。画面一覧の各行→機能→遷移、と遡れることを常に確認する
• 「由来した遷移」列が書けない機能を見つけたら、それは思いつきで足した機能。消すか、先に状態遷移図に矢印を足す
• 抽出した機能が「情報」由来であることの確認がこの演習の核心。Day 1 の情報定義書に載っていない情報を扱う機能が出てきたら、情報定義書に戻る

状態遷移で動く機械を、計算機科学では状態機械（オートマトン）と呼びます。教科書の定番例は自動販売機です。「投入額0円」の状態で100円を入れると「投入額100円」の状態に遷移し、150円のジュースのボタンはまだ反応しない。あと50円入れて初めて「購入可能」状態に遷移する。自動販売機は「今いくら入っているか」という状態を覚えているからこそ正しく動けます。実はあなたが書いている状態遷移図は、この理論の直系の子孫です。19世紀の機械にも、最新のWebサービスにも同じ理論が通用する。計算機科学の基礎理論が現場の設計図に直結している、気持ちのいい例です。

ステップ1.5のレビューが、この演習の品質を決めます。

なぜレビューが要るのでしょうか。状態遷移図を書くとき、あなたは無意識に「システムを作る人」の視点になっています。しかしDay 1で決めた通り、情報の価値を決めるのはペルソナです。「作る人には完璧に見える図」が「使う人には不便な図」であることは、よくあります。

たとえば支出記録の例で、ペルソナ「節約したい20代会社員」がこう言ったとします。「間違えて消しちゃったとき、戻せないんですか？」。この一言で「削除済み→作成済み」という復元の矢印が生まれ、復元機能とゴミ箱画面が抽出されます。逆に「支出のSNS共有機能が欲しい」という声が出ても、ペルソナの目的（節約）に照らして不要なら足しません。レビューは御用聞きではなく、価値の確認です。

AIに投げるプロンプト例です。そのままコピーして、固有名詞を自分のテーマに置き換えてください。

レビュー依頼（ステップ1.5）

あなたは家計簿システムのペルソナ「節約したい20代会社員」です。
毎日の支出をスマホで記録し、月末に使いすぎを反省するのが習慣です。

以下は「支出記録」という情報の状態遷移図です。
あなたの立場で、困ること・欲しい変化（遷移）を3つ指摘してください。
ただし「節約したい」というあなたの目的に関係ないものは挙げないでください。

[ここに状態遷移図を貼る]

機能一覧のレビュー依頼（ステップ2の後）

あなたは家計簿のペルソナ「節約したい20代会社員」です。
この機能一覧をユーザ視点でレビューしてください。
「この機能では目的を果たせない」場面があれば、具体的なシーンで指摘してください。

[ここに機能一覧を貼る]

抽出の壁打ち（詰まったとき）

「出品商品」という情報モデルの状態遷移図を作っています。
オークションなので、入札や落札で状態が変わる気がします。
CRUDだけでは足りない遷移をどう扱えばよいか、私の図を添削してください。

[ここに自分の図を貼る]

• プロンプトには必ず「ペルソナの目的」を書く。目的がないと、AIは何でも「あったら便利」と答えてしまう
• レビュー結果を全部採用しない。採用・不採用を自分で決め、理由を一言添える（Day 1 の「価値の確認」と同じPDCA）
• レビューで図を直したら、機能一覧・プレゼンテーション一覧も連動して直す。これが「要件と実装の連動」の練習

状態遷移図には有名な弱点があります。状態が増えると矢印が爆発して読めなくなるのです。この問題に挑んだのがイスラエルの計算機科学者デイビッド・ハーレルで、1987年に「ステートチャート」を発表しました。状態の中に状態を入れ子にできる（例:「作成済み」の中に「下書き」と「確定」がある）画期的な記法で、のちにUMLの状態マシン図として標準化されました。ハーレルがこの記法を考えたきっかけは、イスラエル航空機工業の戦闘機アビオニクスの仕様書作りだったそうです。戦闘機の状態遷移を紙の仕様書で管理しようとして破綻しかけた現場から、世界標準の記法が生まれました。あなたの図が複雑になってきたら、入れ子にできないか考えてみてください。

• 「私の開発テーマは〇〇です。ペルソナが一番頻繁に触る情報モデルはどれだと思いますか？　候補と理由を挙げてください」
• 「この状態遷移図から機能一覧を抽出しました。遷移と機能の対応に漏れや重複がないかチェックしてください」
• 「『承認待ち』や『公開中』のようなCRUD以外の状態を持つ情報モデルの場合、機能一覧はどう増えますか？　例で示してください」

自分の開発テーマについて、次の4ステップを実施してください。

1. 状態遷移図の作成（10分）: 主要な情報モデルを1つ選び、状態遷移図を draw.io または Mermaid（stateDiagram-v2）で書く。Read の自己遷移を忘れないこと
2. お客様視点のレビューと再定義（10分）: AIに自分のペルソナを演じさせ、図をレビューしてもらう。指摘の採用・不採用を理由付きで決め、図を再定義する
3. 機能一覧の抽出（10分）: 遷移を1本ずつ機能に変換する。Read は「1件表示」と「一覧表示」に分ける。「由来した遷移」列を必ず書く。5種以上になることを確認する
4. プレゼンテーション一覧の抽出（10分）: 各機能にペルソナが使う画面を割り当て、主な表示・入力項目を一言添える

時間が余ったら、2つ目の情報モデルで同じ手順を繰り返してください。

• 情報モデルの状態遷移図（主要モデル1つ以上、レビュー後の再定義版）
• 機能一覧（1モデルあたり5種以上、「由来した遷移」列つき）
• プレゼンテーション一覧（機能との対応つき）

• 何から書けばいいか迷ったら、完成例（支出記録）の状態名をそのまま借りて始める。「未作成→作成済み→更新済み→削除済み」は大半の情報モデルに通用する
• 「入札済み」「公開中」のようなテーマ固有の状態が欲しくなったら、遠慮なく足す。ただしその状態に入る矢印と出る矢印を必ず両方書く
• 機能が5種に届かないときは、Read を分け忘れていないか、復元・確定などの矢印を足せないかを確認する
• 逆に機能が10種を超えたら、複数の情報モデルを1枚の図に混ぜていないか疑う。1枚の状態遷移図の主語は1つの情報モデル
• 本編のプロンプト例をコピーし、ペルソナ名・目的・情報モデル名を自分のものに置き換えて使う

今回学んだことを一言でまとめると、**「機能一覧と画面一覧は、状態遷移図から導出し、ペルソナの目で磨く」**です。

• 状態遷移図→機能一覧→プレゼンテーション一覧が一本の線でつながった
• レビューはAIにペルソナを演じさせ、目的に照らして採用・不採用を自分で決めた
• すべての機能が「情報」由来であることを確認した

あなたの手元には、いま3つの成果物があります。午後のセッションでは、この成果物が開発工程（要件・仕様・設計・実装・テスト）のどこに位置するのかを学び、非機能要件を定義します。そして夕方のセッション8で、今日作ったプレゼンテーション一覧がワイヤーフレームになります。

• 自分の機能一覧のすべての行について、「由来した遷移」を指させますか？
• ペルソナレビューで採用した指摘と不採用にした指摘を、理由付きで1つずつ言えますか？
• 「この機能は情報由来である」とはどういう意味か、自分の成果物を例に説明できますか？

• 参考リンク: draw.io（https://app.diagrams.net/）ステンシル「UML > State Machine」
• 参考リンク: Mermaid 公式ドキュメント stateDiagram-v2（https://mermaid.js.org/syntax/stateDiagram.html）
• 発展課題: 主要な情報モデルに「復元」「確定」などCRUD以外の遷移を1本足し、機能一覧とプレゼンテーション一覧がどう連動して増えるかを確かめる