情報定義書の作成

• 日程: Day 1 / セッション 04
• 時間: [10:40-11:25]
• 形式: 実習（最初の成功体験）
• ゴール: チームの開発テーマで登場する情報を15個以上洗い出し、情報定義書（初版）を1枚の表形式で作成できる
• 学習形式: ハンズオン実習（AIブレストあり）

前のセッションで、IAは「誰に、何の価値を提供するかを構造化する」技術だと学びました。ここからは手を動かす時間です。皆さんのチームの開発テーマで「実際にどんな情報が登場するか」を洗い出します。

これがDay 1の最初の「動いた！」を体感する瞬間です。45分後、皆さんは「情報定義書」という具体的な成果物を手にしています。これは、Day 1の最後、Day 2、Day 3、Day 4まで、すべての作業の土台になる重要な一枚です。

ここで考えてみてください。家計簿アプリを作るとしたら、登場する情報は何個ぐらいあると思いますか？「収入」「支出」だけ？それとも100個以上？ヒントは「ペルソナの一日の中で、画面に現れる可能性のあるものすべて」です。

情報定義書は「このアプリで扱う情報を、すべて表に書き出したもの」です。形式はシンプルで、3〜5列の表です。

最小構成は次の3列です。

これだけです。難しくありません。しかし、これが後の全工程の土台になります。

「情報定義書 = アプリで扱うすべての情報の目録」と覚えてください。料理で例えると、レシピの「材料リスト」です。材料が揃わないと料理は始まりません。同様に、情報定義書がないと設計は始まりません。

最初は「機能」と「情報」を混同しがちです。「ログインする」は機能、「ユーザー名」は情報。「グラフを表示する」は機能、「月別集計」は情報。動詞っぽいものは機能、名詞っぽいものは情報、と覚えると整理しやすいです。

情報定義書は、データベース設計の「エンティティ抽出」と似ています。しかし、IAの情報定義書はDB設計より広い範囲を扱います。「画面に表示する情報」「ユーザーが入力する情報」「内部で計算する情報」すべてが対象です。データベースに保存しない情報（例: 「現在時刻」「セッションID」）も含めます。

情報定義書の作り方は2段階です。第1段階はブレスト（とにかく出す）、第2段階は清書（整理する）。今回はまずブレストです。

ブレストの鉄則は3つあります。

1つ目は「質より量」。15個目標、目指せ30個。少ないほど後で困ります。
2つ目は「批判しない」。「これは違うかも」を一旦保留。後で消せばOK。
3つ目は「他人のアイデアに乗る」。「収入」が出たら「収入の出所」「収入の振込日」と派生させる。

ブレストの進め方の例（家計簿の場合）：

「家計簿を開く」と何が画面に出る？→ 「今月の残額」「支出グラフ」「最近の取引一覧」
「収入を入力する」時、何を入れる？→ 「金額」「日付」「出所」「メモ」
「支出を入力する」時、何を入れる？→ 「金額」「日付」「カテゴリ」「店名」「メモ」「写真（レシート）」
「過去を振り返る」時、何が見たい？→ 「月別集計」「カテゴリ別グラフ」「前月比」「予算達成率」

これだけで15個を超えます。

15個出すのが難しい場合、AIに手伝ってもらいましょう。

良い聞き方：「私たちは家計簿アプリを作ります。ペルソナは『1人暮らしの新社会人』です。このアプリで扱う情報を20個ブレストしてください。情報名と1行の説明だけでOKです。」

良い聞き方（続き）：「他に、見落としがちな情報を5個追加してください。たとえば『予算』『定期支出』『通知設定』など、運用に必要なものも含めて。」

AIから20個出てきたら、チームで「これは入れる」「これは外す」と取捨選択してください。AIの出力を鵜呑みにしないこと。チームの判断が最優先です。

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

• 「私のチームのテーマは〜です。扱う情報を20個提案して」
• 「『機能』と『情報』の区別が曖昧です。例で説明して」
• 「情報定義書とER図は何が違いますか？」

1. ブレストフェーズ（15分）

   • チームで、自分のテーマで扱う情報をホワイトボード（または共有メモ、Miro/FigJam等）に書き出す
   • AIにも10個以上提案してもらう
   • 重複を消さず、とにかく多く出す（目標30個以上）

2. 清書フェーズ（15分）

   • 出した情報を、表形式（番号、情報名、説明）に整理する
   • 重複を統合し、明らかに不要なものを削除する
   • 最終的に15個以上残るようにする

「情報定義書 v1」と題した表。Markdownの表形式でOK。最低15行、各行が1つの情報を表す。

例（家計簿の場合）：

| 番号 | 情報名 | 説明 |
|------|--------|------|
| 1 | ユーザー | アプリを使う本人。名前・年齢などを持つ |
| 2 | 収入 | 受け取ったお金。金額・日付・出所 |
| 3 | 支出 | 使ったお金。金額・日付・カテゴリ・店名 |
| 4 | カテゴリ | 支出の分類。食費・交通費・娯楽費など |
| 5 | 予算 | 月ごと・カテゴリごとの上限額 |
| ... | ... | ... |

15個出ない場合のチェックポイント：

• 「ユーザー自身」を情報として入れていますか？
• 「設定」「履歴」「通知」など、補助的な情報を入れていますか？
• 「集計」「グラフ」「ランキング」など、加工された情報を入れていますか？

エラーが出たら（うまくいかない場合）：「私たちのテーマは〜で、今〜個出ています。あと〜個、見落としがちな情報を提案してください」とAIに聞くと突破口になります。

「機能」が混じってしまった時：「ログイン」「保存」「削除」など動詞は外す。「ログインユーザー」「保存履歴」「削除済みアイテム」のように名詞化できるものは情報として残してOK。

今回はチームの開発テーマで「扱う情報」を15個以上洗い出し、情報定義書（初版）を作りました。これがDay 1〜Day 4のすべての作業の土台になります。

ここで重要な気づきは「情報を出すだけでも、こんなに考えることがある」ということ。実際の開発では、この洗い出しが甘いと「あとから情報が増えて設計を作り直し」という悲劇が起きます。

次のセッションでは「情報の特性」を学びます。今出した情報の中には「価値があるもの」「見えにくいもの」「複数の意味を持つもの」が混ざっています。それを意識する目を養います。

• 自分のチームの情報定義書は15個以上ありますか？
• 「機能」が混ざっていませんか？すべて名詞ですか？
• 説明列に「誰の・何の・どんな」が書かれていますか？

• 参考リンク: ER図、DOA（データ中心アプローチ）、ドメイン駆動設計の「ユビキタス言語」
• 発展課題: 1番似ている既存サービスの情報定義書を推測して作ってみる