外部設計とは〜情報の状態遷移とCRUD

• 日程: Day 5 / セッション 1
• 時間: [9:30-10:00]
• 形式: 座学
• ゴール: 外部設計の目的（ユーザ・お客様とチームの共通認識をつくる）を説明し、情報モデルの状態遷移（CRUD: Create/Read/Update/Delete）から機能と画面を導く手順を説明できる
• 学習形式: 対話型解説、デモンストレーション

昨日までで、皆さんは「情報定義書」と「情報モデル定義書」を完成させました。
開発テーマに登場する情報を洗い出し、「会員情報」「予約情報」のような処理の単位にまとめましたね。

ここで質問です。

「情報モデルはできた。では、システムにはどんな画面が必要でしょうか？」

「えっと……トップ画面と、登録画面と……」と、思いつくままに挙げたくなりますよね。
でも、思いつきで挙げると必ず漏れが出ます。「予約をキャンセルする画面、忘れてた！」というように。

今日学ぶのは、思いつきではなく、手順で画面と機能を導き出す方法です。
その鍵が「情報の状態遷移」と「CRUD」です。

今日からの2日間（Day 5-6）は「外部設計」のフェーズです。まず外部設計とは何かから始めましょう。

外部設計は、要件定義の次に行われる開発工程です。
役割は次の2つです。

• 開発対象システムの外側とのやり取りに必要な情報を設計・定義する
• ユーザ・お客様とチームの共通認識をつくる

「外側とのやり取り」とは何でしょうか。少し考えてみてください。

システムの外側にいるのは、主にユーザ（人間）です。
ユーザはシステムの中身（プログラムやデータベース）を直接は見ません。見るのは画面です。操作するのも画面です。
だから外部設計の中心は「画面と機能の設計」になります。

これは家づくりに例えると分かりやすいです。

• 外部設計 = 間取り図や完成予想図。施主（お客様）と「こんな家になります」と合意するためのもの
• 内部設計（Day 7-8で学びます） = 柱や配線・配管の図面。大工さん（開発者）が作業するためのもの

間取り図を施主に見せずに家を建て始めたらどうなるでしょう？
完成後に「こんな家を頼んだ覚えはない！」と言われてしまいますね。
ソフトウェア開発でまったく同じ事故を防ぐのが、外部設計です。

たとえば「画面一覧」「画面遷移図」は外部設計に該当しますが、「テーブル定義書」「ER図」は該当しません。なぜなら、テーブルやER図はユーザの目に触れないシステム内部の話だからです。

• 外部設計は「ユーザから見える部分」の設計。画面・機能が中心
• 目的は共通認識づくり。チーム内だけでなく、ユーザ・お客様と認識を合わせる
• 内部設計（テーブル・ER図など）と混同しない。「ユーザの目に触れるか？」で区別する

「外部設計」「内部設計」という呼び方は日本のIT業界独特のもので、海外では Basic Design / Detailed Design や UI Specification などと呼ばれます。語源は1970年代の大型汎用機時代、システムを「外から見た仕様」と「中の作り」に分けて文書化した慣習にさかのぼります。ちなみに現場では外部設計書のことを「外設（がいせつ）」と略します。新人が「ガイセツお願い」と言われて概説資料を作ってしまった、という笑い話は今でも各地の現場で再生産されています。

では本題です。画面と機能を手順で導き出す方法を説明します。

出発点は、昨日作った情報モデルです。
情報モデルには「一生」があります。人間と同じです。

具体例で考えましょう。レストラン予約システムの「予約情報」という情報モデルを例にします。

1. お客さんが予約をすると、予約情報が生まれる
2. お客さんが「やっぱり19時に変更したい」と言うと、予約情報が変わる
3. お客さんが「今の予約内容を確認したい」と言うと、予約情報が読まれる
4. お客さんがキャンセルすると、予約情報が消える

この「生まれる・読まれる・変わる・消える」を英語にすると——

頭文字を並べて CRUD（クラッド） と呼びます。
情報モデルの状態遷移は、原則としてこの4つに分類できます。

ここで少し考えてみてください。
Readだけは仲間はずれです。なぜでしょうか？

……そうです。Create・Update・Deleteは情報の状態を変えますが、Readは見るだけで状態を変えません。
それでもReadを必ず数える理由は、後で説明する「画面」に直結するからです。見るためにも画面が必要なのです。

予約情報の状態遷移を図にすると、こうなります。

※ Readは状態を変えないため、図には現れません。ただし「どの状態でも参照できる」ことを忘れずに数えます。

• 情報モデルには一生がある。CRUDはその一生を漏れなく追うためのチェックリスト
• Readは状態を変えないが、必ず数える（参照のための画面・機能が必要だから）
• 「この情報モデルにDeleteは本当に不要か？」と必ず自問する。「履歴として残すので削除しない」は立派な設計判断だが、検討した上での判断であることが大事

CRUDという言葉を世に広めたのは、英国のコンピュータ科学者ジェームズ・マーティンの著書『Managing the Data-base Environment』（1983年）だと言われています。40年以上前の概念が、最新のWebサービスやスマホアプリの設計でも現役で使われ続けているのは驚きです。なお発音は「クラッド」。英単語の crud には「汚れ・カス」という意味があり、ネイティブのエンジニアは「俺たちは毎日CRUD（カス）を書いてる」と自虐ネタにすることがあります。

ここが本研修の設計の核心です。一文で言い切ります。

情報を状態遷移させるのが「機能」であり、「画面」になる。

どういうことか、予約情報のCRUDで追ってみましょう（デモ）。

流れを図にするとこうです。

つまり、こういう手順になります。

1. 情報モデル定義書から情報モデルを1つ取り出す
2. その情報モデルのCRUD（状態遷移）を洗い出す → 情報の状態遷移図（本日セッション2）
3. 状態遷移1つひとつに対応する機能を挙げる → 機能一覧（本日セッション3）
4. 機能を操作するための画面を挙げる → 画面一覧（本日セッション3）

この手順のすごいところは、漏れが出にくいことです。
思いつきで画面を挙げると「キャンセル画面を忘れた」が起きますが、CRUDを順に追えば「Deleteに対応する画面は？」と機械的にチェックできます。

注意点もあります。機能と画面は必ずしも1対1ではありません。

• 「予約一覧画面」1つに、Read（一覧表示）とDelete（一覧から削除ボタン）の2機能が載ることもあります
• 逆に「予約登録機能」に、入力画面と確認画面の2画面が対応することもあります

また、CRUDから導かれない画面も少しだけあります。たとえば「ログイン画面」や「メニュー画面」です。これらは情報モデルの状態遷移ではなく、システムの入口として必要になる画面です。CRUDで土台を作った後に補う、と覚えてください。

ここで考えてみてください。皆さんのチームの情報モデルに「会員情報」があるとしたら、CRUDそれぞれに対応する機能と画面は何になりそうですか？　頭の中で予約情報の表を「会員情報」に置き換えてみましょう。

• 「情報モデル → 状態遷移（CRUD）→ 機能 → 画面」の一方通行の流れを覚える
• 機能と画面は1対1とは限らない。ただし対応関係は必ず説明できるようにする
• ログイン画面・メニュー画面など、CRUD由来でない画面は最後に補う

皆さんが普段使っているWebサービスも、ほぼCRUDの塊です。SNSは「投稿情報」をCreate（投稿）、Read（タイムライン）、Update（編集）、Delete（削除）しています。X（旧Twitter）には長らく投稿のUpdate機能がなく、「編集させてくれ」が世界中のユーザの悲願でした（2022年にようやく有料ユーザ向けに実現）。「UpdateのないCRUD」が10年以上議論を巻き起こしたわけで、CRUDの1文字が欠けるだけでユーザ体験が大きく変わる好例です。

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

• 「外部設計と内部設計の違いを、別のたとえ話で説明して」
• 「『お知らせ情報』という情報モデルのCRUDと、対応する機能・画面の例を表で示して」
• 「CRUDのうちDeleteが不要になるのはどんなケース？　論理削除と物理削除の違いも教えて」
• 「うちのチームの情報モデルは○○なんだけど、CRUDを一緒に考えて」

今回学んだことを一言でまとめると、**「情報を状態遷移させるのが機能であり、画面になる」**です。

• 外部設計は、ユーザ・お客様とチームの共通認識をつくる工程
• 情報モデルにはCRUD（Create/Read/Update/Delete）という状態遷移がある
• 状態遷移を1つずつ追えば、必要な機能と画面が漏れなく導ける

次のセッションでは、この考え方を使って、皆さんのチームの情報モデル定義書から情報の状態遷移図を実際に作成します。

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

• 外部設計の目的を「共通認識」という言葉を使って説明できますか？
• CRUDの4文字それぞれの意味を、予約情報を例に説明できますか？
• 「情報モデル → ？ → 機能 → 画面」の「？」に入る言葉は何ですか？
• Readが状態遷移図に現れないのに、必ず数える理由を説明できますか？

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

• 参考リンク: IPA「機能要件の合意形成ガイド（画面編）」（画面設計の合意形成の実務例）
• 発展課題: 普段使っているアプリを1つ選び、中心となる情報モデルを推測してCRUD対応表（状態遷移・機能・画面）を作ってみる

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