開発テーマ決定と情報定義書の作成

• 日程: Day 1 / セッション 4
• 時間: [11:00-12:00]
• 形式: 演習
• ゴール: 情報処理を伴う開発テーマを1つ決定し、そのテーマに登場する情報を20個以上洗い出した「情報定義書」を作成できる
• 学習形式: AIブレスト

前のセッションで、情報とは「データに誰かにとっての価値を与えたもの」だと学びました。ここからは、その考え方を自分のプロジェクトで使っていきます。

このセッションで作る「情報定義書」は、この4日間で作るすべての成果物の出発点です。明日はここから情報モデルを作り、明後日は設計に落とし、最終日には動くソフトウェアにします。家づくりでいえば、今日は「この家にどんな部屋や設備が要るか」を全部書き出す日です。

進め方はシンプルです。まずAIブレストで発散（とにかく数を出す）、次に清書で収束（表に整える）。1時間後、あなたの手元には「開発テーマ」と「情報を20個以上並べた情報定義書」が残ります。

さっそく始める前に一つ質問です。あなたが日常で「これ、システム化したら便利なのに」と思ったことは何ですか？ その答えが、開発テーマの種になるかもしれません。

開発テーマの条件はたった一つ。情報処理を伴うことです。情報を登録し、探し、見返す場面があるなら何でも構いません。

候補リストを挙げます。ピンとくるものがなければ、これをたたき台にAIとブレストしましょう。

• 家計簿システム（支出・収入を記録して振り返る。この教材のサンプルもこれを使います）
• レシピ類推サービス（冷蔵庫の食材から作れる料理を提案する）
• オークションシステム（出品・入札・落札を管理する）
• 読書記録アプリ（読んだ本・感想・積読を管理する）
• トレーニング記録アプリ（筋トレやランニングの記録と推移）
• 旅行計画ツール（行きたい場所・予算・日程を整理する）
• ゲームの攻略メモ共有（アイテム・攻略手順・マップ情報）
• 推し活管理（イベント・グッズ・遠征予算の管理）

選ぶときの基準は3つです。

1. 自分が受け手（ユーザー）を想像できること。自分自身がユーザーでも良い
2. 登場する情報が20個以上ありそうなこと。シンプルすぎるテーマ（例: サイコロを振るだけ）は情報が足りません
3. 4日間つき合えること。少しでも「好き」が入っているテーマは強い

逆に、「AIで株価を完全予測するシステム」のような実現性が主題になるテーマは避けましょう。この研修の主役は予測アルゴリズムではなく情報の設計です。テーマ選びで5分以上迷ったら、家計簿システムを選んで先に進んで構いません。テーマの優劣より、この後の設計の質が成果を決めます。

迷ったらAIに相談しましょう。コピーして使えるプロンプト例です。

情報処理を伴う開発テーマを決めたいです。私の興味は「（例: 料理、ゲーム、旅行）」です。
この興味に関連する開発テーマの候補を5つ挙げて、それぞれ
「登場しそうな情報の例」を3つずつ添えてください。

「読書記録アプリ」と「トレーニング記録アプリ」で迷っています。
4日間の研修で情報設計→モデル化→実装まで行う題材として、
それぞれの良い点・大変そうな点を比較してください。

• 条件は「情報処理を伴う」ことだけ。凝ったテーマより、情報を想像しやすいテーマが良い
• テーマ選びは10分以内に切り上げる。迷ったら家計簿システム
• ここで決めたテーマはDay 4の実装まで使い続ける。ただし情報定義をやり直したくなったら、それは失敗ではなく学びの証拠

日本の家計簿の歴史は意外に古く、1904年（明治37年）にジャーナリストの羽仁もと子が考案した「羽仁もと子案家計簿」が最初とされます。特徴は、使った額を記録するだけでなく先に費目ごとの予算を立てるという設計思想。120年前にすでに「支出金額」「費目」「予算」という情報構造を定義していたわけで、羽仁もと子は日本最初期のInformation Architectだったと言えるかもしれません。この家計簿、現在も毎年出版され続けているロングセラーです。

テーマが決まったら、そこに登場する情報を洗い出します。使う手法はブレインストーミングです。

ブレストには守るべきルールがあります。

• 批判禁止: 出たアイデアを「それは違う」と否定しない。評価は後
• 量重視: 質より量。10個の良案より100個の玉石混交
• 便乗歓迎: 他人（AI）のアイデアに乗っかって膨らませるのは大歓迎
• 自由奔放: 突飛なものほど歓迎。「レシートの撮影画像」も「後悔の度合い」も情報になり得る

ここで考えてみてください。なぜ「批判禁止」なのでしょうか？ 批判が入ると、脳が「出す」モードから「守る」モードに切り替わり、アイデアの流れが止まるからです。発散と収束は別工程に分ける——これはブレストに限らず、設計作業全般のコツです。

AI協働型のブレストでは、あなたとAIの役割分担が鍵になります。

1. まず自分で5分間書き出す（AIに頼る前に。自分の頭から出た情報には「自分が価値を感じた」という根拠がある）
2. AIに大量に出させる（30個単位で遠慮なく）
3. AIの案に便乗して膨らませる（「その方向でもっと」と依頼する）
4. 抜けている観点をAIに探させる（自分の視野の外を照らしてもらう）

コピーして使えるプロンプト例です。テーマ名は自分のものに置き換えてください。

家計簿システムに登場する情報を30個ブレストしてください。
機能ではなく情報（名詞）で挙げてください。
例: 「支出金額」「支出日」「費目」はOK、「支出を登録する」はNGです。

この一覧に抜けている情報の観点はありますか？
「お金そのもの以外」（人、時間、場所、感情、目標など）の観点で
さらに10個追加してください。

（ここに現在の一覧を貼り付ける）

「費目」という情報に便乗して、費目に関連する情報を10個挙げてください。
例: 費目の名前、費目の色分け、費目ごとの予算…のような方向で。

私は「節約したい一人暮らしの社会人」を受け手として想定しています。
この受け手にとって価値がありそうな情報を、いまの一覧に10個追加してください。

発散のフェーズでは、出てきた情報の重複や粒度のばらつきは気にしないでください。刈り込みは次の清書と、午後のセッション8（整理・分類）で行います。

• ブレストの4原則: 批判禁止・量重視・便乗歓迎・自由奔放
• 発散と収束を混ぜない。出しながら削らない
• AIに頼る前に、まず自分で5分書く。順序が学習効果を決める
• AIへの依頼は「個数」と「形式（名詞で）」を指定すると精度が上がる

ブレインストーミングの生みの親は、米国の広告代理店BBDOの創業者の一人、アレックス・オズボーンです。1930年代末、会議で若手が委縮して発言しないことに悩んだ彼は、「批判禁止・自由奔放・量重視・便乗歓迎」のルールを考案しました。名前の由来は「脳（brain）で問題に嵐（storm）のように突撃する」から。ちなみにオズボーンはアイデア発想のチェックリスト「オズボーンの9つのチェックリスト」も残しており、これは後のSCAMPER法の原型になりました。90年前の広告マンの発明を、あなたは今日AI相手に実践するわけです。

発散した情報を、情報定義書という表に清書します。列は3つだけです。

• 情報名: 情報の名前（名詞で短く）
• 説明: その情報が何を表すか（一文で言い切る）
• 誰にとっての情報か: その情報に価値を感じる受け手

家計簿システムのサンプルを示します。

ここで最重要の注意です。書くのは「情報」であって「機能」ではありません。

• 「支出を登録する」は動詞で終わる機能なので、情報定義書には書きません
• 「支出金額」「支出日」「費目」は名詞の情報なので、書きます

見分け方は簡単です。「〜する」で終わったら機能、「〜」という名詞で止まったら情報。迷ったら「それは登録したり表示したりする対象か？」と自問してください。対象なら情報です。

なぜこの区別にこだわるのでしょうか。少し考えてみてください。……理由は研修の根幹に関わります。機能は情報より移ろいやすいのです。「支出をレシート撮影で登録する」か「手入力で登録する」かは実装手段の話で、後からいくらでも変わります。しかし「支出金額」という情報の価値は変わりません。情報の設計とシステムの設計を分離する——この研修で体得する最大のプラクティスが、もうここから始まっています。

なお、「誰にとっての情報か」の列は現時点では粗くて構いません。「利用者」だけでなく「家族」「税理士」など複数の受け手が見えたら、それも書いておきましょう。午後のペルソナ定義（セッション6）で精緻化します。

このセッションの流れを図で確認します。

清書とセルフレビューにもAIが使えます。

以下のブレスト結果を、「No. | 情報名 | 説明 | 誰にとっての情報か」の
Markdown表に清書してください。重複はまとめ、説明は一文で。

（ここにブレスト結果を貼り付ける）

この情報定義書の中に「情報」ではなく「機能」が混ざっていたら指摘してください。
指摘した項目は、そこから抽出できる「情報」に言い換える案も添えてください。

（ここに情報定義書を貼り付ける）

• 情報定義書の列は「情報名・説明・誰にとっての情報か」の3つ
• 「〜する」は機能、名詞は情報。情報定義書に機能を書かない
• 情報は変わりにくく、機能は変わりやすい。だから情報から先に設計する
• 完璧を目指さない。午後の整理・分類で必ず作り直す。ここでは量と網羅性

「名詞を洗い出す」という手法には由緒があります。オブジェクト指向分析の古典的テクニックに「名詞抽出法」があり、要件文書の名詞に下線を引いてクラス候補を見つける方法として1980年代から使われてきました。提唱者の一人ラッセル・アボットは1983年の論文で「プログラム設計は自然言語の記述から始められる」と論じています。今日あなたが書く情報定義書の「情報名」は、明日そのまま情報モデルの候補になります。40年前の設計者たちの知恵を、AIブレストという最新の道具でなぞっているのです。

• 「『支出を検索する』『検索履歴』『検索条件』のうち、情報定義書に書いてよいものはどれ？ 理由つきで判定して」
• 「私の情報定義書を見て、受け手（誰にとっての情報か）が1種類に偏っていないかレビューして。別の受け手の候補も3人挙げて」
• 「情報定義書の項目数が20個で止まりました。発想を広げるための質問を、私に5つ投げかけて」

1. 開発テーマを1つ決定する（目安10分）

   • 候補リストから選ぶか、AIとブレストして自分のテーマを決める
   • 「テーマ名＋一文の説明＋主な受け手」をメモする
2. 情報をブレストで発散する（目安25分）

   • まず自分だけで5分間、思いつく情報を書き出す
   • 続いてAIブレストで30個以上に増やす（本編のプロンプト例を活用）
   • 「抜けている観点は？」の問いかけを最低1回行う
3. 情報定義書に清書する（目安20分）

   • 「No. | 情報名 | 説明 | 誰にとっての情報か」の表形式に整える
   • 機能（「〜する」）が混ざっていないかセルフレビューし、AIにもレビューさせる
   • 20個以上になっていることを確認する

• 開発テーマ（テーマ名・一文の説明・主な受け手）
• 情報定義書（情報名・説明・誰にとっての情報か、の表。20個以上）

この2つは午後のセッション5〜8、そしてDay 2以降のすべての演習で使います。ファイルとして保存し、いつでも開ける場所に置いてください。

• 20個に届かないときは、観点を変えて眺める: 人（誰が関わる？）、時間（いつの話？）、場所（どこで起きる？）、モノ（何が登場する？）、目標（何のため？）
• 「1つの情報を分解する」のも有効。「支出」は「支出金額」「支出日」「費目」「支払い方法」に分けられる
• AIの出力を鵜呑みにしない。1つ1つ「これは私のテーマの受け手に価値があるか？」と自問して採否を決める。捨てる判断も設計の一部
• 逆に、価値があるか判断できない情報は残しておく。捨てるのは午後の「整理」の仕事
• 時間が余ったら、各行の「誰にとっての情報か」を具体化してみる（「利用者」→「毎月赤字気味の一人暮らし社会人」など）

今回学んだことを一言でまとめると、**「開発はコードではなく、情報の洗い出しから始まる」**ということです。

• 開発テーマの条件は「情報処理を伴う」ことだけ。受け手を想像できるテーマを選んだ
• ブレストの4原則（批判禁止・量重視・便乗歓迎・自由奔放）で発散し、表形式に清書して収束した
• 情報定義書に書くのは名詞の「情報」。「〜する」の機能は書かない
• 手元に「開発テーマ」と「20個以上の情報定義書」が揃った。これが4日間の全成果物の出発点

昼休憩をはさんで、午後のセッション5では情報が持つ3つの特性「価値・可視性・多義性」を学びます。実は、あなたが今作った情報定義書の中に「人によって意味が変わる危険な情報」が潜んでいます。午後、それを一緒に探しましょう。

1. 「支出を登録する」が情報定義書に書けない理由を、機能と情報の違いで説明できますか？
2. 自分の情報定義書から、受け手が異なる情報を2つ選んで「誰にとっての情報か」を言えますか？
3. ブレストの4原則を挙げ、なぜ発散と収束を分けるのかを一文で言えますか？

• 参考リンク:

  • アレックス・F・オズボーン『創造力を生かす』（創元社）— ブレインストーミングの原典
  • Louis Rosenfeld, Peter Morville『情報アーキテクチャ』（オライリー・ジャパン）第2部「情報アーキテクチャの基本原理」
  • 羽仁もと子案家計簿（婦人之友社）— 120年続く情報設計の実例
• 発展課題:

  • 自分の情報定義書の各行に「この情報はどこから来るか（入力元）」の列を試しに追加してみましょう。書きにくい行があるはず——その理由をAIと議論すると、Day 2の情報モデルの予習になります
  • 同じテーマで「受け手」を変えたら（例: 家計簿の受け手を本人→ファイナンシャルプランナーに）、情報定義書がどう変わるかAIに書かせて、自分の版と比較してみましょう