情報モデル定義書の作成
概要
- 日程: Day 4 / セッション 4
- 時間: [11:30-12:40]
- 形式: 実習
- ゴール: 情報定義書を元に、開発テーマの情報モデルを漏れなく洗い出し、情報モデル定義書を時間内に作成できる
- 学習形式: ハンズオン実習(AIサポートあり)
導入(5分)
前のセッションで、情報モデルとは「情報を処理する単位のまとまり」だと学びました。いよいよDay 4の総仕上げ、情報モデル定義書の作成です。
このセッションの成果物は、明日の外部設計の入力になります。明日は情報モデル1つひとつについて「状態遷移(CRUD)」を考え、そこから画面と機能を導きます。つまり、今日ここで情報モデルが1つ漏れると、明日は画面が丸ごと1セット漏れます。
逆に言えば、今日のチェックポイントは明確です。「この情報モデル一覧で、To-Be版CJMの体験がすべて実現できるか?」——リレーのバトンパスと同じで、渡す前にバトンをしっかり握り直しましょう。
本編(10分)
1. 情報モデル定義書の作り方
情報モデル定義書とは、情報モデルの一覧と、各モデルに含まれる情報(属性)・処理の例をまとめた文書です。
作成手順は4ステップです。
情報定義書のカテゴリを並べる"] --> B["Step2 処理の単位で再点検
分割・統合する"] B --> C["Step3 属性と処理の例を記入
定義書フォーマットに清書"] C --> D["Step4 漏れチェック
CJM突き合わせ + AIレビュー"]
- Step1: 情報定義書のカテゴリをそのまま情報モデルの候補として並べる
- Step2: 各候補に「処理の例(登録・参照・変更・削除など)」が書けるか確認する。書けなければ分割・統合する
- Step3: 各情報モデルに、含まれる情報(属性)と処理の例を記入する
- Step4: To-Be版CJMと突き合わせ、体験の各場面を支える情報モデルが揃っているか確認する。最後にAIレビュー
Step2の「分割・統合」の判断例を見てみましょう。
- カテゴリ「お店と予約の情報」に、店舗の登録と予約の登録という別系統の処理が混ざっている → 「店舗情報」と「予約情報」に分割
- カテゴリ「会員の基本情報」と「会員の連絡先」が、常に一緒に登録・変更される → 「会員情報」に統合
判断基準は一貫して「処理の単位」です。意味が似ているかではなく、一緒に処理されるかで決めます。
コード例・実例
情報モデル定義書のフォーマット例です(題材: 飲食店予約システム)。
| No. | 情報モデル名 | 説明 | 含まれる情報(属性) | 処理の例 |
|---|---|---|---|---|
| 1 | 会員情報 | サービスを利用する会員のまとまり | 会員名、メールアドレス、電話番号、アレルギー情報 | 会員登録、会員情報変更、退会 |
| 2 | 店舗情報 | 予約対象となる店舗のまとまり | 店名、営業時間、席数、住所 | 店舗登録、店舗情報更新、閉店処理 |
| 3 | 予約情報 | 会員が店舗に行う予約のまとまり | 予約日時、予約人数、予約者(会員)、対象店舗、状態 | 予約登録、予約変更、キャンセル、予約照会 |
| 4 | 通知情報 | 会員へ送る通知のまとまり | 送信先(会員)、送信日時、通知内容、既読状態 | 通知作成、通知送信、既読化 |
注目ポイントが2つあります。
- 予約情報の属性に「予約者(会員)」「対象店舗」がある——情報モデル同士は参照し合うことがあります。この関係は来週のER図で本格的に扱うので、今日は「関係がある」とメモしておけば十分です
- 「通知情報」は画面の主役ではありませんが、処理の単位として独立しています。こういう裏方のモデルが漏れやすいので要注意です
ここがポイント
- カテゴリ→情報モデルの変換は「処理の例が書けるか」が合格基準
- 情報定義書のすべての情報が、どれかの情報モデルに収容されているか確認する。宙に浮いた情報は漏れのサイン
- よくある間違い: 履歴・通知・お知らせなど「画面の主役にならないモデル」の見落とし。To-Be版CJMの「システムからの働きかけ」の場面を見直すと発見できる
コラム
情報モデルの「漏れ」で世界的に有名な失敗談があります。2000年問題(Y2K)です。1960〜70年代のシステムは記憶装置が高価だったため、年を「99」と下2桁だけで持つ設計が主流でした。「西暦の上2桁」という情報をモデルから削った結果、2000年が「1900年」と区別できなくなり、世紀末の数年間、世界中で数千億ドル規模の改修騒ぎになりました。設計時には合理的だった「捨てる判断」が、30年後に牙をむいた例です。整理(捨てる)は大切ですが、「将来この情報が必要になる処理はないか?」という問いも同じくらい大切——両方を天秤にかけるのが設計者の仕事です。
2. 漏れの見つけ方〜CJM突き合わせとAIレビュー
「漏れなく洗い出す」のが今日のゴールです。漏れの発見には2つの武器を使います。
武器1: To-Be版CJMとの突き合わせ
CJMの段階を左から右へたどり、各場面でこう問います。
- 「この場面でシステムが扱う情報は、どの情報モデルに入っている?」
1場面でも「対応するモデルがない…」となれば漏れ発見です。たとえば「健太さんはリマインド通知を見て安心する」という場面があるのに「通知情報」モデルがなければ、その体験は実現できません。
武器2: AIレビュー
完成した情報モデル定義書をAIに見せて、抜けを指摘してもらいます。依頼文の例です。
飲食店予約システムの情報モデル定義書を作成しました。
ペルソナ: (要約を貼る)
To-Be版CJM: (要約を貼る)
情報モデル定義書: (表を貼る)
このシステムに必要な情報モデルで、抜けている可能性があるものを
理由付きで指摘してください。また、各情報モデルの属性の過不足も
あれば指摘してください。
AIの指摘は鵜呑みにせず、1件ずつ「うちのペルソナの体験に必要か?」で採否を判断します。AIは一般的なシステムの常識から指摘するので、「一般にはあるが、うちのテーマでは不要」というケースも多いのです。捨てる判断も立派な設計です。
ここがポイント
- 漏れチェックは「CJM突き合わせ(自力)→AIレビュー(補完)」の2段構え。順番を守る
- AIの指摘の採否基準は「ペルソナの体験(To-Be版CJM)に必要か」。採用したら情報定義書にも情報をさかのぼって追記する(成果物間の整合性)
- よくある間違い: AIレビューだけで済ませる。CJM突き合わせを飛ばすと「自分たちのテーマ固有のモデル」の漏れは見つからない
コラム
「レビューで他人の目を入れると欠陥発見率が劇的に上がる」ことは古くから知られていて、ソフトウェアレビューの古典的研究では、作成者本人が見つけられる欠陥は全体の半分程度とも言われます。人間は自分の書いたものを「書いたつもりの内容」で読んでしまうからです(校正の世界では「脳内補完」と呼ばれます。「これはは読めますか?」の「はは」に気づかないアレです)。AIレビューの良いところは、24時間文句を言わず、何度でも、人間関係を気にせず指摘してくれること。ただしAIも「あなたが書いたつもりの内容」までは読んでくれません。文脈(ペルソナ・CJM)を渡すのを忘れずに。
💬 AIに聞いてみよう
実習を始める前に、疑問があればAIに質問してみましょう。たとえば:
- 「情報モデルの分割と統合で迷っている。『〜』というカテゴリはどう判断すべき?」
- 「情報モデル同士の参照関係(予約情報が会員情報を参照する等)は、今日どこまで書けばいい?」
- 「予約システムでよく見落とされる情報モデルの例を教えて」
実習・演習
課題
情報定義書を元に、情報モデル定義書を作成してください。
- (10分)Step1-2 候補出しと再点検: 情報定義書のカテゴリを情報モデル候補として並べ、各候補に処理の例が書けるか確認する。処理の単位で分割・統合する
- (20分)Step3 定義書の作成: フォーマット(No.・情報モデル名・説明・含まれる情報・処理の例)に従って清書する。情報定義書のすべての情報がどれかのモデルに収容されているか確認する
- (15分)Step4 漏れチェック: To-Be版CJMの段階を1つずつたどり、各場面を支える情報モデルが揃っているか突き合わせる。その後、AIに定義書とペルソナ・CJMの要約を渡してレビューを依頼し、指摘の採否をチームで判断する
- (10分)最終確認と宣言: 採用した修正を反映し、必要なら情報定義書にもさかのぼって追記する。最後にチーム全員で「この情報モデルで明日の外部設計に進める」ことを確認し合う(話す&行う)
成果物
「情報モデル定義書」
- 情報モデルの一覧(名前・説明・含まれる情報・処理の例)が揃っている
- 情報定義書のすべての情報がいずれかの情報モデルに対応している
- To-Be版CJMの全場面が、いずれかの情報モデルで支えられている
- AIレビューを受け、指摘の採否をチームで判断した記録がある
ヒント
- 処理の例が書けない候補は、AIに「『〜』というまとまりに対する処理を挙げて」と聞くと、分割すべきか統合すべきかのヒントが得られます
- 属性の置き場所に迷ったら(例: 「キャンセル理由」は予約情報?通知情報?)、「その情報は何と一緒に登録・更新されるか」で決めましょう
- AIレビューで指摘が多すぎて混乱したら、「この中で、ペルソナの体験の実現に必須なものだけ3つに絞って」と追加で頼みましょう
- 残り時間が少なくなったら、Step4のCJM突き合わせを最優先に。漏れの発見こそ今日の核心です
- 「状態」(予約済み・キャンセル済み等)という属性を入れておくと、明日の状態遷移図がスムーズに描けます
まとめ(5分)
今回学んだことを一言でまとめると「情報定義書のカテゴリを処理の単位で再点検し、漏れのない情報モデル一覧に仕上げる」です。
- カテゴリ→情報モデルの合格基準は「処理の例が書けるか」
- 漏れチェックは、CJM突き合わせ(自力)とAIレビュー(補完)の2段構え
- 採用した修正は情報定義書にもさかのぼって反映する(成果物間の整合性)
これでDay 4の成果物(情報定義書・情報モデル定義書)が揃い、情報設計が完了しました。課題→テーマ→ペルソナ→CJM→情報定義→情報モデル、と一本の線がつながったことを確認してください。
次回Day 5からは外部設計です。今日の情報モデル1つひとつが状態遷移(CRUD)し、画面と機能に化けていきます。お楽しみに。
🔄 振り返りチェック
以下の問いに答えられるか確認してみましょう:
- 自チームの情報モデルを、資料を見ずにすべて挙げられますか?
- 各情報モデルの「処理の例」を1つずつ言えますか?
- 漏れチェックの2つの方法(CJM突き合わせ・AIレビュー)と、その順番の理由を説明できますか?
- 明日の外部設計で情報モデルがどう使われるか、予想を言えますか?
答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。
補足資料
- 参考リンク: Day4_Session02成果物(情報定義書)、Day4_Session03資料(情報モデルとは)
- 発展課題: 完成した情報モデル定義書の各モデルについて、「登録→利用→終了」のライフサイクルを口頭で語ってみましょう。語れないモデルは明日の状態遷移図で苦労するかもしれません。AIと一緒に予習を
学習ガイド
このセクションは、受講者が理解を深めることをサポートする参考情報です。
想定される質問と回答例
| 質問 | ヒント |
|---|---|
| 情報モデルが3個しかないが大丈夫? | 数より網羅性。To-Be版CJMの全場面を支えられているなら3個でもよい。支えられない場面があれば漏れ |
| 情報モデル同士の関係はどう書く? | 今日は属性に「予約者(会員)」のように参照をメモする程度でよい。本格的な関係定義はER図(Day 7)で行う |
| AIの指摘をどこまで採用すべき? | 「ペルソナの体験に必要か」が基準。一般論としては正しくても、自分たちのテーマに不要なら捨ててよい。捨てた理由をメモに残すと振り返りに役立つ |
| 情報定義書に戻って直してもいい? | むしろ直すべき。後工程の気づきを前工程の成果物に反映するのは健全な進め方。ただし変更はチームに報告して合意してから(Day 1のルール) |
つまずきやすいポイント
| つまずきポイント | ヒント |
|---|---|
| カテゴリ名をそのまま全部情報モデルにして終わる | 必ず「処理の例」を書く。書けたか書けなかったかが再点検した証拠になる |
| 裏方モデル(通知・履歴)の見落とし | CJMで「システムから働きかける場面」「後から振り返る場面」を探す。AIに「裏方の情報モデルの見落としは?」と聞くのも有効 |
| 属性の収容先が決まらず議論が長引く | 「何と一緒に登録・更新されるか」で仮決めして先へ進む。Day 7の正規化で再整理される |
| AIレビューの指摘を全部入れてモデルが膨張する | 採否基準(ペルソナの体験に必要か)に立ち返る。膨張は実装期間(実働8日)を圧迫することを思い出す |