外部設計とは〜情報の状態遷移とCRUD
概要
- 日程: Day 5 / セッション 1
- 時間: 09:30-10:00（30分）
- 形式: 座学
- ゴール: 外部設計の目的（ユーザ・お客様とチームの共通認識をつくる）を1分以内に説明でき、情報モデルの状態遷移（CRUD）から機能と画面を導く手順を具体例で示せる
- 学習形式: 対話型解説、デモンストレーション
導入（5分）
昨日までに「ペルソナ」「カスタマージャーニーマップ」「情報モデル定義書」を作りました。今日からはいよいよ「設計」に入ります。
問いかけ: 「会員登録」という機能を作るとき、最初に決めるべきことは何ですか？画面のデザイン？それともボタンの動き？
答えは「情報がどう変わるか」です。会員登録は「未登録 → 登録済み」という情報の状態変化を起こす機能です。情報を状態遷移させるのが機能であり画面になる。これが本研修の設計の核心です。
設計フェーズ（Day5-9）の地図を先に見せます。
状態遷移・画面/機能一覧"] --> B["Day6 外部設計2
画面遷移図・画面仕様書"] B --> C["Day7 内部設計1
テーブル・ER図"] C --> D["Day8 内部設計2
CRUD図・機能設計書"] D --> E["Day9 PM
WBS・かんばん"]
今日はこの設計の入口です。
本編（20-25分）
1. 外部設計とは何か
外部設計は「要件定義の次」に行う工程です。役割は1つ。ユーザ・お客様とチームの共通認識をつくること。
たとえ話: 家を建てるとき、設計士はまず「間取り図」と「外観イメージ」を施主に見せます。柱の太さや配線の話は後回し。施主が見て「ここで暮らせるイメージ」が湧くものを先に作ります。これが外部設計です。
外部設計が扱うのは「システムの外側とのやり取り」です。
| 設計種別 | 扱う対象 | 例 |
|---|---|---|
| 外部設計 | システムの外側 | 画面、機能、画面遷移、画面仕様 |
| 内部設計 | システムの内側 | テーブル、ER図、CRUD図、機能設計 |
ここがポイント
外部設計書は「お客様と一緒に読む」ものです。だから専門用語より、画面イメージ・遷移・機能名で語ります。
コラム: なぜ「外部」と呼ぶのか
ユーザにとってシステムは「画面と操作」がすべてです。中でどうデータが動いていても、ユーザには見えません。ユーザから見える「外側」を設計するから外部設計と呼びます。逆に内部設計はユーザに見えない「内側」を設計します。
2. 必要な機能と画面を洗い出す方法
ここが今日の核です。「情報モデル定義書」から、それぞれの情報がどのように状態遷移するかを決める。状態遷移を起こす操作が「機能」となり、その操作を行う場所が「画面」となります。
(Day4の成果物)"] --> B["状態遷移図
CRUD"] B --> C["機能一覧"] B --> D["画面一覧"] C --> E["画面遷移図
画面仕様書"] D --> E
「情報を状態遷移させるのが機能であり画面になる」。この一文をチーム全員で覚えてください。
3. CRUDとは何か
CRUDは情報に対して行う基本操作の頭文字です。
| 文字 | 操作 | 例（会員情報） |
|---|---|---|
| C | Create（生成） | 会員登録する |
| R | Read（参照） | 会員情報を見る |
| U | Update（更新） | 会員情報を編集する |
| D | Delete（削除） | 退会する |
ほぼすべての情報は、このCRUDのどれかで状態が変わります。
コード例・実例: 「予約情報」のCRUD
レストラン予約システムを例にします。「予約情報」という情報モデルがあるとします。
ここから機能と画面が見えてきます。
| CRUD | 機能 | 画面 |
|---|---|---|
| C | 予約する | 予約フォーム画面 |
| R | 予約を見る | 予約一覧画面・予約詳細画面 |
| U | 予約を変更する | 予約編集画面 |
| U | 来店確認する | 店員用予約管理画面 |
| D | キャンセルする | 予約詳細画面のキャンセルボタン |
情報モデル1つから、機能と画面が芋づる式に出てきました。これがCRUDの威力です。
ここがポイント
- Rは見落としがち。「ユーザはこの情報をどこで見るか？」を必ず問う
- Dは慎重に。物理削除（消す）か論理削除（フラグ）かは後で内部設計で決める
- 同じCRUDでも「誰が」操作するかで画面が分かれることがある（ユーザ用／管理者用）
💬 AIに聞いてみよう
AIを設計レビュアーとして使いましょう。
例:
- 「予約情報のCRUDを書き出しました。漏れている状態遷移はありますか？」
- 「会員情報のDeleteは本当に必要ですか？退会後も履歴を残すべきでは？」
- 「この情報モデルで、Rが発生する画面を全部挙げて」
AIの答えを鵜呑みにせず、チームで議論する材料にしてください。
まとめ（5分）
今日学んだこと:
- 外部設計の目的は「ユーザ・お客様とチームの共通認識をつくる」こと
- 情報を状態遷移させるのが機能であり画面になる
- 情報モデル → 状態遷移（CRUD） → 機能・画面 という導出の流れ
次のセッションでは、自チームの情報モデル定義書から実際に状態遷移図を作ります。
🔄 振り返りチェック
- 外部設計の目的を1分で説明できる
- CRUDの4文字とそれぞれの意味を言える
- 「情報を状態遷移させるのが機能であり画面になる」を自分の言葉で説明できる
- 情報モデル定義書から機能・画面を導く手順を順に挙げられる
補足資料
- Day4成果物: 情報モデル定義書（次セッションの入力）
- Day3成果物: カスタマージャーニーマップ To-Be版（画面動線の確認に使う）
- Mermaid stateDiagram-v2 公式ドキュメント
学習ガイド
想定される質問と回答例
| 質問 | ヒント |
|---|---|
| CRUDのほかに何かありますか？ | 検索（Search）、印刷（Print）など。ただし大半はR（参照）の派生として扱える |
| 状態遷移図とフローチャートはどう違うのですか？ | 状態遷移図は「情報の状態」を主役にする。フローチャートは「処理の順序」を主役にする |
| ログイン機能はどの情報のCRUDですか？ | 「ユーザセッション情報」のC（生成）と考えると整理しやすい |
| 同じ画面で複数のCRUDを扱ってもいい？ | 良い。例えば一覧画面はRと削除ボタン（D）を持つことが多い |
| 状態遷移が複雑すぎて書けません | 1つの情報モデルにつき状態は3〜5個に収まることが多い。それ以上ある場合は情報モデルを分けるサイン |
つまずきやすいポイント
| つまずきポイント | ヒント |
|---|---|
| 「機能」と「画面」の区別が曖昧 | 機能は「操作」、画面は「操作する場所」。1つの画面に複数の機能があってよい |
| 状態が動詞になってしまう（例: 「予約する」） | 状態は名詞または形容詞（例: 「予約済み」「未確認」）。動詞は遷移のラベル |
| 全部の情報モデルでCRUD全部が必要だと思い込む | 不要なものは書かない。例えばマスタデータはCとRだけのことが多い |
| 情報モデル定義書を見ずに状態遷移を考える | 必ずDay4の成果物を開いて、1つずつ突き合わせる |
| 「画面」を考えるときデザインを気にしてしまう | 今は画面の「名前と目的」だけ。レイアウトはDay6で扱う |