状態遷移とCRUD

• 日程: Day 2 / セッション 3
• 時間: [10:45-11:15]
• 形式: 座学
• ゴール: CRUDの4操作を情報モデルの状態遷移として説明できる。状態遷移から機能（新規入力・1件表示・一覧表示・更新・削除）とプレゼンテーションが抽出できる理由を、家計簿の例を使って言える
• 学習形式: 対話型解説＋デモンストレーション

前のセッションで、あなたは情報モデルを抽出しました。属性・関係・制約条件が図になったはずです。

ここで問いかけです。その情報モデル、このあとどうやって「動くシステム」にしますか？

• 「画面をたくさん考える」でしょうか
• 「機能を思いつく限り列挙する」でしょうか

どちらも、やってみると抜け漏れだらけになります。思いつきに頼るからです。

このセッションでは、まったく別の方法を紹介します。情報モデルの「状態遷移」を書くだけで、必要な機能と画面が“自動的に”出てくる方法です。

信じられないかもしれません。だからこそ、最後にデモで実際にやって見せます。これが「情報の設計」と「システムの設計」を分離できる瞬間です。

情報モデルは、静止した図ではありません。時間とともに姿を変えます。

家計簿の「支出記録」で考えてみましょう。

• 朝、コンビニでコーヒーを買う。この時点で支出記録はまだ存在しません
• 夜、家計簿に「コーヒー 150円」と入力する。支出記録が作成されます
• 翌日、レシートを見返すと本当は180円だった。記録を修正します
• 月末、間違えて二重登録していたことに気づく。片方を消します

このように、情報モデルは「未作成→作成済み→更新済み→削除済み」と姿を変えます。この姿のことを状態（State）、姿の変化を**状態遷移（State Transition）**と呼びます。

これは人間の一生のようなものです。誕生し、成長し（変化し）、いつか終わりを迎える。情報モデルにも同じように一生があります。

ここで考えてみてください。あなたが前のセッションで抽出した情報モデルには、どんな一生がありますか？

家計簿の「支出記録」の状態遷移図です。Mermaid の stateDiagram-v2 で書けます。

矢印の1本1本が「操作」です。状態を変える操作もあれば、Read のように状態を変えずに中身を見るだけの操作もあります。

• 状態遷移図に書くのは「情報の姿の変化」であって、「画面の流れ」ではない
• 「画面遷移図」と混同しやすいので注意。主語が違う（画面遷移の主語はユーザ、状態遷移の主語は情報モデル）
• 矢印には「何がきっかけで遷移するか」をラベルとして書く

状態遷移という考え方は、ソフトウェアより先に機械の世界で使われてきました。身近な例が信号機です。「青→黄→赤→青」と決まった状態を巡回し、それ以外の遷移（青からいきなり赤）は起きません。エレベーターや炊飯器も同じで、組込みソフトウェアの世界では状態遷移表を書かないと設計が始まらないと言われるほどです。「いま何の状態か」「何をしたら次の状態に移るか」を全部書き出すと、抜け漏れのない設計になる。この知恵を情報システムに持ち込んだのが、今日学ぶ手法です。

先ほどの図の矢印ラベルに、Create・Read・Update・Delete という英単語がありました。これが CRUD（クラッド） です。

重要な事実を言います。永続化される情報に対する操作は、原則この4つしかありません。

「え、検索は？」「集計は？」と思ったかもしれません。検索は「条件付きの Read」、集計は「複数件の Read の加工」です。どちらも Read の仲間であって、5つ目の操作ではありません。

逆に CRUD に該当しない例も見てみましょう。「印刷する」は情報モデルの状態を変えないので Read の一種です。しかし「支出記録を月次レポートに変換して保存する」は、月次レポートという別の情報モデルの Create です。操作が CRUD のどれかに割り切れないときは、隠れた情報モデルが潜んでいるサインです。

CRUDの4操作は、データベースのSQLとも1対1で対応します。

この対応は Day 3 で学ぶ RESTful API（POST/GET/PUT/DELETE）にもそのまま続きます。

• CRUDは「機能の分類」ではなく「情報モデルへの操作の分類」。主語は常に情報モデル
• Read だけは状態を変えない。だから状態遷移図では自己遷移（自分に戻る矢印）で書く
• CRUDに割り切れない操作が出たら、新しい情報モデルの発見のチャンス

CRUDという語を広めたのは、イギリスの情報工学者ジェームズ・マーティンです。1983年の著書 "Managing the Data-base Environment" でこの4分類を示しました。40年以上前の概念が、SQLにもRESTにも現役で生きています。ちなみに英単語の crud は「こびりついた汚れ・カス」という意味のスラングです。データベース設計者が「うちのシステムはCRUDだらけだ」と言うと、英語圏では二重の意味に聞こえて笑いが起きることがあります。名付けたのがマーティン本人の狙いかは不明ですが、覚えやすさには確実に貢献しています。

ここからがこのセッションの山場です。家計簿システムの「支出記録」を使って、状態遷移図から機能一覧と画面一覧を抽出して見せます。

手順は機械的です。

1. 状態遷移図の矢印（遷移）を1本ずつ機能に変換する
2. Read だけは「1件見る」と「まとめて見る」の2つに分ける
3. 各機能に対して「その機能をペルソナが使うための画面」を割り当てる

やってみます。

ステップ1・2: 矢印→機能

矢印を全部なぞっただけで、機能が5種類出ました。思いつきは一切使っていません。

ステップ3: 機能→プレゼンテーション

機能5種に対応して、画面も5枚出ました。入力画面・詳細画面・一覧画面・編集画面・削除確認画面。世の中のWebサービスの管理画面がだいたいこの5枚構成なのは、偶然ではありません。全部この手順で作られているからです。

ここで少し考えてみてください。もし情報モデルが「支出記録」「予算」「カテゴリ」の3つあったら、機能と画面はいくつになるでしょうか？　そう、機械的に約15機能・約15画面です。見積りまでできてしまいます。

抽出結果を成果物の形式でまとめると、こうなります。次のセッションであなたが作るものの完成イメージです。

機能一覧（支出記録）

• 機能一覧の各行は、必ず状態遷移図の矢印まで遡れる（トレーサビリティ）
• 「要件と実装の連動」とはこのこと。ペルソナの要件が変わる→情報モデルが変わる→状態遷移が変わる→機能と画面が変わる、と一本の線でつながる
• 逆方向も使える。「この画面、なぜあるの？」に「この遷移のためです」と答えられないなら、その画面は不要かもしれない

「削除済み」という状態を図に残すことには、実は実務上の深い意味があります。多くの業務システムでは、Delete しても本当にデータを消さず「削除済みフラグ」を立てるだけにします。これを論理削除と呼びます。PCのゴミ箱と同じ発想です。なぜか。ユーザは必ず「間違えて消しました、戻してください」と言ってくるからです。状態遷移図に「削除済み→作成済み（復元）」という矢印を1本足せば、「復元機能」と「ゴミ箱画面」が抽出されます。矢印1本が機能1個。要件の議論が図の上でできるのが、この手法の強さです。

• 「家計簿の『予算』という情報モデルの状態遷移図を stateDiagram-v2 で書いてください。そこから機能を抽出する過程も見せてください」
• 「CRUDに当てはまらないように見える操作（例: 承認する、公開する、キャンセルする）は、状態遷移としてどう扱えばよいですか？」
• 「状態遷移図と画面遷移図の違いを、家計簿システムを例に対比して説明してください」

今回学んだことを一言でまとめると、**「情報モデルの状態遷移を書けば、機能一覧と画面一覧は思いつきではなく“導出”できる」**です。

• 情報モデルには一生（状態遷移）がある
• 永続化される情報への操作は CRUD の4つに集約される
• 遷移の矢印を1本ずつなぞれば機能5種（新規入力・1件表示・一覧表示・更新・削除）が出る
• 機能に画面を割り当てればプレゼンテーション一覧が出る

これが「情報の設計」から「システムの設計」が導かれる瞬間です。次のセッションでは、この手順をあなたの開発テーマで実際にやります。デモで見た家計簿と同じことを、自分の情報モデルでやるだけです。

• CRUDの4操作を、支出記録の状態遷移（未作成・作成済み・更新済み・削除済み）と対応づけて言えますか？
• Read から機能が2つ（1件表示・一覧表示）出るのはなぜですか？
• 「状態遷移を書けば機能一覧が自動的に出てくる」と言える理由を、一文で説明できますか？

• 参考リンク: Mermaid 公式ドキュメント stateDiagram-v2（https://mermaid.js.org/syntax/stateDiagram.html）
• 参考リンク: IPA「情報処理技術者試験」の状態遷移図・状態遷移表の解説記事
• 発展課題: 「下書き→公開→非公開」の状態を持つブログ記事の状態遷移図を書き、CRUD以外の遷移から抽出される機能（公開・非公開化）を考えてみる