アーキテクチャとは／情報アーキテクチャの定義／情報が持つ特性

• 日程: Day 1 / セッション6
• 時間: 13:00-13:30
• 形式: 座学
• ゴール: 情報アーキテクチャを「価値」「可視性」「多義性」という3つの特性から説明できる
• 学習形式: 対話型解説

🗣️ 要約

• 情報とは、データに価値を与えたものである
• アーキテクチャと情報を掛け合わせたものが「情報アーキテクチャ」である
• 情報アーキテクチャは価値・可視性・多義性という3つの特性で理解できる

お昼休憩お疲れさまでした。午前中は「情報とは何か」を考え、開発テーマの情報をたくさん洗い出して「情報定義書」を作りましたね。

ここで少し思い出してみてください。午前の演習で、みなさんは「データに価値を与えたもの」を情報と呼ぶ、と学びました。では、その「情報」を実際にソフトウェアの形にするには、何が必要でしょうか？

実は、そこに必要なのが「アーキテクチャ」という考え方です。今日の午後は、「アーキテクチャ」と「情報」を掛け合わせた「情報アーキテクチャ」の定義にたどり着きます。このセッションが終わる頃には、IAを構成する3つの特性（価値・可視性・多義性）を使って、自分の言葉でIAを説明できるようになっています。

🗣️ 要約

• アーキテクチャ＝構造・設計、情報＝データに価値を与えたもの、という2つを掛け合わせてIAの定義を導く
• 情報の3つの特性（価値・可視性・多義性）を、具体例（こうもり問題など）とともに扱う
• すべての特性は「ペルソナの視点」で初めて適切に定義できる、という結論に接続する

🗣️ 要約

• アーキテクチャ＝ソフトウェアの構造・設計思想（建築の間取りに例えられる）
• 情報アーキテクチャ＝「誰に価値を提供するか」を決め、それを構造・設計に落とし込む手法
• その役割を担う人をInformation Architect（情報の整理をする役割）と呼ぶ

まず「アーキテクチャ」という言葉について考えてみましょう。もともとは建築用語ですが、ソフトウェアの世界では「構造」や「設計」、あるいは「設計思想」を指す言葉として使われます。

たとえば家を建てるとき、いきなり柱を立て始める人はいません。まず「どこに何の部屋を配置するか」という間取り（構造）を決めますよね。ソフトウェアも同じで、「どこにどの処理を配置するか」という構造を先に決めます。これがアーキテクチャです。

では、「情報アーキテクチャ」とは何でしょうか。午前中に学んだ「情報」の定義を思い出してください。

• 情報 ＝ データに「価値」を与えたもの
• アーキテクチャ ＝ ソフトウェアの構造・設計

この2つを掛け合わせると、情報アーキテクチャの定義が見えてきます。

情報アーキテクチャ（IA）とは、「誰に価値を提供するのか」を決定し、それをソフトウェアの構造や設計として落とし込む手法である。

この「誰に価値を提供するのかを決定する役割」を担う人のことを、Information Architect（情報の整理をする役割）と呼びます。

ここで考えてみてください。もしIAという考え方がなく、いきなりプログラムを書き始めたら、何が起きるでしょうか？ おそらく「誰のための機能か」が曖昧なまま、開発者の思い込みで画面やデータ構造が決まってしまいます。IAは、その思い込みを防ぐための「情報の設計図」なのです。

家計簿アプリを例に考えてみましょう。

• IAなしでいきなり実装：開発者が「支出」というテーブルを思いつきで作り、金額・日付だけを保存する
• IAを経て実装：「誰が」「何のためにこのアプリを使うか」（例：一人暮らしの新社会人が、無駄遣いに気づきたい）を先に定義し、そのペルソナにとって価値がある情報（カテゴリ、固定費かどうか、月ごとの比較）を洗い出してから、データ構造を決める

同じ「支出を記録するアプリ」でも、IAを経由するかどうかで、出来上がるデータ構造も画面も大きく変わります。

特に注意してほしいのは、情報アーキテクチャは「見た目のデザイン」ではないという点です。よくある誤解として「IA＝おしゃれなUIを作ること」だと思われがちですが、正しくは「情報を整理し、構造として設計すること」です。UIはその構造を人に見せるための表現の1つにすぎません。

「アーキテクチャ」という言葉が建築由来だと知ると、ソフトウェアの世界にも「グランドデザイン」「リファクタリング（改築）」「レガシー（古い建物）」といった建築用語が数多く使われていることに気づきます。実はソフトウェア工学が発展する過程で、建築の分野からたくさんの比喩を借りてきた歴史があります。エンジニアが「この設計、土台から腐ってるな」なんて言うのも、建築の比喩がそのまま定着した例です。今度エンジニア同士の会話で建築用語を見つけたら、ちょっと面白い発見として覚えておいてください。

🗣️ 要約

• 価値：情報の価値は絶対的ではなく「誰にとっての価値か」で変わる
• 可視性：暗黙知（見えない情報）を形式知（見える情報）にする「可視化」というプロセスがある
• 多義性：同じ情報でも見る人・文脈で意味が変わる（こうもり問題が象徴例）。ペルソナ視点で意味を1つに絞り込むのがIAの仕事

情報アーキテクチャを実践するうえで、情報には3つの特性があることを知っておく必要があります。

1つ目は「価値」です。 情報の価値は、絶対的なものではありません。「誰にとっての価値か」「何を提供する価値か」によって変わります。たとえば「昨日の降水確率80%」というデータは、傘を持たずに出かける人にとっては価値の高い情報ですが、在宅勤務の人にとってはそれほど重要ではないかもしれません。

2つ目は「可視性」です。 情報には、見える情報と見えない情報があります。これは午前中に少し触れたSECIモデルの「暗黙知」と「形式知」の話ともつながっています。ベテラン社員の頭の中にしかないノウハウ（暗黙知）は見えない情報であり、それをマニュアル化（形式知化）することで初めて見える情報になります。この「見えない情報を見える形にする」プロセスを「可視化」と呼びます。

3つ目は「多義性」です。 同じ情報でも、見る人や文脈によって意味が変わることがあります。ここで少し考えてみてください。1つの数字、たとえば「体重60kg」という情報は、ダイエット中の人にとっては「気にする数値」ですが、格闘家にとっては「試合に出られるかどうかの基準値」かもしれません。同じ数値なのに、意味づけが全く違いますね。これが情報の多義性です。

そして、この多義性を象徴する有名な例が「こうもり問題」です。こうもりは、空を飛ぶので鳥のように見えますが、哺乳類でもあります。「鳥」というカテゴリに分類するべきか、「獣（哺乳類）」というカテゴリに分類するべきか——これは、分類する目的（誰が、何のために分類するか）が決まらない限り、答えが出ません。

つまり、情報の「価値」「可視性」「多義性」は、すべて「ペルソナの視点」で検討することで、はじめて適切に定義できるのです。午前中に洗い出した情報定義書も、まだ「誰にとっての価値か」が定まっていない、いわば宙ぶらりんな状態です。次のセッションで作るペルソナが、その宙ぶらりんな情報に「意味」を与えてくれます。

開発テーマが「オークションシステム」だとしましょう。「出品からの経過時間」という情報は、

• 出品者にとっては「早く売れてほしい」という焦りに関わる情報（価値）
• 落札を狙う人にとっては「残り時間が少ないから今入札しよう」という行動のきっかけになる情報（価値）
• システム管理者にとっては「そろそろオークションを自動終了する処理を走らせるタイミング」という情報（価値）

同じ「経過時間」というデータでも、誰の視点かによって意味も価値も変わることが分かります。

特に注意してほしいのは、「情報の多義性＝悪いこと」ではないという点です。よくある誤解として、多義性は排除すべき曖昧さだと思われがちですが、正しくは「多義性があることを前提に、ペルソナを決めて意味を1つに絞り込む」のがIAの仕事です。多義性そのものをなくすことはできません。

🗣️ 要約

• IAの定義や3特性を、自分たちの開発テーマに当てはめてAIに質問できる

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

• 「情報の価値・可視性・多義性を、自分たちの開発テーマの例で説明して」
• 「こうもり問題みたいな『分類に迷う情報』は、自分たちのテーマにもある？」
• 「実務でInformation Architectという職種は、どんな仕事をするの？」

🗣️ 要約

• IAとは「誰に価値を提供するかを決め、構造に落とし込む手法」である
• 判断のよりどころは価値・可視性・多義性の3特性
• 次は「誰にとっての価値か」を具体化する「ペルソナの定義」に進む

今回学んだことを一言でまとめると、「情報アーキテクチャとは、誰に価値を提供するかを決めて、それを構造に落とし込む手法である」ということです。そして、その判断のよりどころになるのが、情報の「価値」「可視性」「多義性」という3つの特性でした。

次回は「ペルソナの定義」の演習に入ります。今回の「誰にとっての価値か」という視点が、そのままペルソナを作る土台になるので、しっかり押さえておきましょう。

🗣️ 要約

• IAの定義を「価値」という言葉を使って説明できるか
• こうもり問題のような分類に迷う情報にどう対処すればよいか

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

• 情報アーキテクチャの定義を、「価値」という言葉を使って説明できますか？
• こうもり問題のような「分類に迷う情報」に出会ったとき、何を決めれば分類できますか？

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

🗣️ 要約

• 発展的な参考資料は「The Elements of User Experience」
• 発展課題は、自分たちの開発テーマの中から「こうもり問題」を探すこと

• 参考リンク: 「The Elements of User Experience」（Jesse James Garrett）で示されるUXの5階層とIAの位置づけ
• 発展課題: 自分たちの開発テーマにおける「こうもり問題」（分類に迷う情報）を1つ探してみる

🗣️ 要約

• 受講者からよく出る質問への回答例と、つまずきやすいポイントへの対処法をまとめている

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

🗣️ 要約

• アーキテクチャと設計の違いはDay3で詳しく扱うが、ここでは簡潔に区別できればよい
• 情報の価値を決めるのは開発者ではなくペルソナ（利用者）
• 可視化はSECIモデルの暗黙知→形式知の変換とつながっている

🗣️ 要約

• IAをUIデザインと混同しやすい（構造が先、見た目は後）
• こうもり問題に「唯一の正解」を求めてしまいやすいが、分類は目的次第で変わる
• 抽象論のままで終わり、自分たちの開発テーマの具体例に当てはめられないことがある