インフォーメーションアーキテクトとは、ウェブサイトのコンテンツをいかに整理整頓するかという重大な任務を担う、ウェブ開発チームに不可欠なメンバーの一員である。今回は、情報アーキテクチャに関する誤解を解くとともに、ウェブサイト開発における情報アーキテクチャの役割とは何かを明らかにしていきたい。
ずばり情報アーキテクチャとは何か？情報デザインと同じか？つまりはデザインなのか？情報アーキテクチャと銘打たれ た仕事のいくつかを見てみると、どうもインフォメーションアーキテクトは、データベース設計からヴィジュアルデザイナー 、テクニカルライターにいたるまで、何にでもあてはめられてしまうようだ。
インフォメーションアーキテクトは、サイト上のコンテンツを、その種類（通常のファイルなのか、マルチメディアタイ プなのか、データベースに属するのか）に関係なく、それらをうまく整理整頓するための土台を築く。複雑なウェブサイトや ポータルサイトにおいては、インフォメーションアーキテクトは、作業が悪夢に陥るのをあらかじめ防いでくれるのだ。
今回は、ここで述べた疑問を明らかにすると同時に、言葉につきまとう混迷を晴らし、さらに深い知識を得るためのいく つかの参考資料を提供しよう。
インフォメーションアーキテクトとデザイナーの違いを考える上で一番よいのは、建物の建築家と、インテリアデザイナ の違いを考えてみることである。
建築家は、何よりもまず建物の構造とその流れ、配電や配管といった根幹部分を第一に考える。もし建築家が仕事をしな ければ、その建物はいずれ崩れるか、そこを使ったり住んだりする人々のニーズを満たせないだろう。例えばベッドルームが 足りなかった、などだ。
一方でインテリアデザイナーは、色や配置、備品のスタイルや手触り、外観など、感覚に訴えるものに気を配る。彼らは きっと地中海風やらスパニッシュ風やらの部屋の外観を決めようとするだろうし、建物全体で配色やスタイルなどの基調がそ ろっているかに注力を払う。
どちらの仕事がやさしいとか難しいとかいうのではない。これらはただ単に違う仕事なのである。互いに多少かぶってい
るところがあるのは確かだが（例えば、建築家も見た目に気を配るし、デザイナーも建物内の流れやアクセスを念頭に置く）
、たいていこの二つの仕事は互いに他を補い合っている。誰もインテリアデザイナーに家を建ててほしいとは言わないだろう
し、建築家にリビングの壁紙の配色について意見を求めたりしないだろう。
そのままウェブに話を戻そう。インフォメーションアーキテクトは概してデザインや配色、レイアウト、ヴィジュアル・コミ
ュニケーションの形式などについてそれほど知識があるわけではない。それらはデザイナーの専門分野だ。しかしながら、イ
ンフォメーションアーキテクトは決まって、構造の分類や、XMLや、コンテンツ生成や整理、インタラクションデザイン、そ
してナビゲーションデザインなどの背景的知識や経験を携えている。彼らの専門性は情報の組み立てにある。続いては、その
専門知識がいつ、どこで、どうやって生かされるのか、について説明していこう。
インフォメーションアーキテクトが活用するのに最も適した場面とは、ウェブ開発のもっとも始めの段階である。ぐらつ く壁に屋根をのっけようとするときに建築家を現場に呼んでも仕方がないように、ウェブサイトでトラブルにぶつかる前に専 門家みてもらうのは、いつだって賢明だ。
インフォメーションアーキテクトに見てもらうタイミングに関係なく彼らが知りたがるのは、プロジェクトの下記の要素 である。
ユーザーの目的とニーズを理解することは、この記事を読んでいるユーザビリティ関連の仕事をしている人にとっては何 も新鮮なことではない。しかしながら、いくつかの他の項目は、ヤコブ・ニールセンのお決まりの要素に比べて多少目新しい だろう。インフォメーションアーキテクトの第一の関心は、ユーザーが簡単に理解し、利用できるような情報構造を設計する ことである。それを実現するために、彼らはまずユーザーの目的と企業の目的を調整し、同時に、そのプロジェクトごとに設 けられた様々な制約（締め切り、リソース、予算など）、また技術的な問題（開発言語の選択、データベースなど）、さらに コンテンツ制作（スタッフの割り当て、どの割合で社員／フリーランスを使うのかなど）などの枠の中で作業を進めるように しないといけない。
例えば、ひとつ以上の言語での表示を選択したとしたら、コンテンツの入り口での処理が違ってきて、ユーザーとコンテ ンツ間のインタラクションに違いが出てくるだろう。もっと言えば、そのコンテンツは、いくつかの短いページに分けられる のでなく、1ページに長々とまとめないといけなくなるかもしれない。また、コンテンツにおける制約があるよい例としては 、ライターの絶対数が少なく、さらに彼らがそのサイトでカバーされる分野に全く専門知識をもっていなかったりする場合な どだ。そういった制約は、サイトの主題にあった中身を編集でカバーするために労力が費やされ、サイトの目的などは全く無 視されてしまう結果をもたらすかもしれない。その場合、企業側はライターの数を増やしたり、フリーランスの予算を上げた りする方策をとるだろう。
これらの問題は、表面的には、どのようにコンテンツが整理されてサイトに配置されるのかといった課題に対してそれほ ど関係がないように見えるが、実際はユーザーのコンテンツに対する基本的なインタラクションに大きく影響を与えうる。
ウェブサイトのコンテンツは決して静的なものではない。それは組み立ての段階やプロジェクトの遂行の中で変化しうる だけでなく、日ごとにも変化してゆくものだ。コンテンツ戦略やサイトの目的の調整に対して常に気を配るのが、情報アーキ テクチャの成功の秘訣であるといえる。
情報アーキテクチャが関わる仕事は、たいてい二つのステップに分けられる。まずトップダウン方式を用いたアプローチ 、次にボトムアップ方式でのアプローチだ。
通常、最初はトップダウン型の情報アーキテクチャでの検証が行われる。その名前の通り、この方法では、インフ ォメーションアーキテクトはまず情報の大きな見取り図を描き、次に完成時の詳細やページの流れ、コンテンツ構造などに焦 点をしぼっていく。
ユーザとその組織の目的を理解することは、トップダウン方式の初めの作業のひとつだ。両者の目的は、サイトのコンテ ンツの全体像を表していないといけない。例えば、開発中のサイトがスキー用品販売のポータルだとしよう。その場合、イン フォメーションアーキテクトは、実際の商品のバイヤーと消費者がそのサイトを見てどう思うのかを知る必要がある。言い換 えれば、インフォメーションアーキテクトはユーザの概念空間を理解していないといけない。先の例で言えば、スノーボード とスキーは違う製品としてカテゴリ分けされるであろう。またスキーは、クロスカントリースキーやダウンヒルスキーなど、 いくつかのサブカテゴリに分けられるかもしれない。このようなトップダウン方式でのサイトの組み立てにより、いっそうナ ビゲートしやすいコンテンツ設計が可能になるといえるだろう。
次に続くのがボトムアップでの検証だ。この過程でインフォメーションアーキテクトは、すべてをうまく動かすた めに欠かせない隠れた断片情報、すなわちメタデータとメタデータに関するものの理解に努める。つまり、メタデータが何を し、どこに蓄えられ、どのように生かされ、どのように異なるメタデータが作用しあうのか、ということについてだ。
メタデータが、サーチエンジンからパーソナライゼーション、コンテンツの整理まで、サイト上でのあらゆる動きの要と なることは、想像に難くないだろう。ではここで言うメタデータとは何か？メタデータとは、すなわち「データについてのデ ータ」のことだ。たとえば私たちが話す際、口から発せられる言葉はデータとして目で見ることができる。声の音色、ボディ ランゲージ、リスナーの特徴や態度まで、それらは全てメタデータとして扱われる。そしてそのメタデータは、元のデータの 理解を促す役目をはたす。
スキー用品サイトの例で話を続けよう。例えば、サイトの管理者が、ダウンヒルスキーの記事を読むユーザに対し、その サイトのオンラインストアで扱われる関連商品をサイドバーに表示させたいとしよう。このひとつのやり方として、メタデー タを体系化して分類してやればいい。つまり、サイトのコンテンツと実際の商品、双方に関連した言葉と概念の分類だ。例え ば、スキー用品のサイトの一部は以下のように分けられるだろう。
スノーボード スキー ダウンヒルスキー クロスカントリースキー スラロームスキー スキー用シューズ その他
中枢部における言葉の分類が進めば、もうコンテンツと商品の関連性をあてずっぽうで考えるといった手間が発生するこ とはない。もし全てのコンテンツと商品が正しく分類されていれば、ダウンヒルスキーとラベリングされた記事を読むユーザ ーは、サイドバーに、同じくダウンヒルスキーとラベリングされた関連商品を目にすることになる。
さらに、一年後にサイト管理者がパーソナライゼーションの機能を付加したいと考えたとすると、その際にはまた同じ分 類が生かされることになる。ユーザーは、ログインした後、自分にあったコンテンツと商品のカテゴリを、リストから選ぶよ う求められる。パーソナライゼーションと商品とコンテンツには同じ分類が用いられるのだから、筋違いなことにはならない 。パーソナライゼーションでスノーボードを選択し、それに関連した最新のコンテンツと商品を見たいユーザーは、そのよう にラベリングされた全ての情報を手にいれることができるというわけだ。
インフォメーションアーキテクトは、限られた時間の中で、以下のような手法を用いて膨大な情報を集めなければならな い。
例：ビルはフォーチュン誌でトップ100企業にランキングされるソフトウェア開発会社のマネージャーだ。彼は 部署内に30人の部下をもち、プログラミング言語の最新情報を必要とする。彼はテクノロジーそのもののというより、テクノ ロジーの選択が現場のビジネスへ与える影響、特にその市場における有効性について興味がある。
その他の興味深い方法としては、カードソートがある。（最後の参考資料を参照）これは参 加者に、似たコンセプトどうしのカード（カードには１枚づつ違うコンセプトが書かれている）をグループ化してもらうとい うものだ。結果は大まかな構造の格のようなものになる。すべてをまとめると、サイトのインフォメーションアーキテクトの プロトタイプの基盤となる結果が得られるだろう。
1対1のテストの際は、バイアスがかからないようにすることが重要である。インフォメーションアーキテクトは、参加者 の行動に関して口をはさんではいけない。また参加者の行為を正したり、助け船を出したりしてもいけない。ただ台本に従う ことが求められる。しかし、参加者にはテスト中、声を出して考えていることを話してもらうようにする。それは、彼らがど のように独自の概念空間をナビゲートしているのかについてのまたとない情報元となる。
インフォメーションアーキテクトの仕事は情報を集めるだけではないのは明らかだ。インフォメーションアーキテクトは その情報を分析して、統合して、取捨選択して、特定のものだけに焦点をあてる。そしてまた、多くの推測を重ねないといけ ない。これは決して厳密で科学的なガイドラインによりルール化された領域の仕事ではないのだ。有名なインフォメーション アーキテクトであるJesse James Garretは次のように述べている。自分の仕事の成功の鍵は、すぐれた推論を重ねる ことだ、と。
インフォメーションアーキテクトはあくまで過程であり、最終成果ではない。数多くのサイトが、とりあえずの情報アー キテクチャを備えて立ち上げられるが、それらはあくまで今現在の段階での「十分な」レベルだ。たとえ完璧な構造のサイト が生み出されても、6ヶ月ももたないだろう。なぜならその間に何か（ユーザーのニーズ、ビジネス目的など）が変わってし まい、概念的にもろいものになってしまうからだ。
インフォメーションアーキテクトがもたらす最も大事なツールはオープンマインドである。インフォメーションアーキテ クトは、機械のパーツのように容易に解決できる仕事を扱うのではない。その仕事の領域は、何かもっと機知に富んで入り組 んだもの -- 概念空間 -- なのだ。つまりそれは、そこで扱われるのは、心理学、コミュニケーション、そして言語（意味的 かつ実用的レベル）の領域であることを意味している。さらに言えば、作業の多くがコンテンツ指向に根ざしており、コンテ ンツを見つけて、創り出して、精錬して、制作して、さらに維持する、といった規定不可能な要素も含まれる。
インフォメーションアーキテクトは、上記の領域を把握しているため、洞察的なアイデアを提供し、思考のリーダーとな ることが期待される。問題解決とアイデアの提供は、技術的な開発にだけでなく、オンラインビジネスのあり方にも大きく影 響を与える。もしユーザーが必要としている情報を見つけられなかったり、そのサイトを分かりにくいと感じたとしたら、も う二度とサイトに戻ってはきてくれない。こうなると、その企業の収入に直接影響するだろうし、さらに企業の市場での格が 下がるという結果を招くだろう。
多くのソフトウェアが、インフォメーションアーキテクトの仕事にふさわしい多くの機能（全てでないにしても）を備え ているとうたっている。（ここでいう仕事とはつまり、コンテンツと、それがどのようにカテゴライズされ、パブリッシュさ れ、管理されているかの把握だ。）しかしながらほとんどのツールは、正直なところ非常に初歩的な機能しか備えておらず、 こちらの望んでいる（または宣伝文句にふさわしい）機能は期待できない。そしてこれはインフォメーションアーキテクトの 仕事の内容に起因するといえる。すなわち、人間の言語（そして概念空間）を扱うのは非常に困難で、それを再利用可能なシ ステムやプロセスに落とし込むのはさらに困難な作業だということだ。
個々のツールやソフトウェアについて論じるスペースはここにはないので省略するが、以下のリストが何らかの手引きに なるであろう。
コンテンツ・マネージメント・ツールは、コンテンツの管理をより簡単にすることをうたっている。コンテンツ・ クリエイターのチームは、それにより通常のファイルとデータベース、両方のコンテンツのパブリッシュと管理をより容易に 行うことが可能になるだろう。しかしながらこれらのツールの多くは、個々のコンテンツのライフサイクルに対し、非常に表 面的な見方しか提供できていない。（これはたぶんシステムのデザイナーがコンテンツの職人に、彼らの仕事がどんなものな のかを聞くのをためらったためだろう。）
ほとんどのコンテンツ管理システムは、コンテンツの一部を生成して、それをワークフローの中で自由に配置できる。ワ ークフローを生成して、それを実際の個々の部門ごとのワークフローに従わせるようにするのが難しかったり簡単だったりす るのは、そのシステムによるところが大きい。最も優れたコンテンツ管理システムでさえ、コンテンツ生成の根幹であるリサ ーチやドラフト、素材集めなどの過程に関してはあまり考慮にいれてくれない。もしくは、コンテンツのパブリッシュ管理に 関してもあまり期待はもてない。
しかしながらコンテンツ管理ソフトのベンダーの数からいって、各社の競争がゆくゆくは使える価値のあるツールを生み 出す可能性はあるだろう。これまでのところ、私の経験でいうと、オープンソース技術に明るいある特定の人々に向けて構築 されたカスタムアプリケーションは、パッケージソフトウェアを毎回打ち負かしてきた。
同様に、オートマティック・カテゴライゼーション（自動分類）ツールはファイルの膨大な量のコンテンツ、例え ばファイルリポジトリやデータベーステーブル、Eメールアーカイブなどの煩雑な分類作業を補助することをうたっている。 そういったツールのいくつかは、マルチメディアファイルや画像ファイル、ましてやVisioのフローチャートなどの複雑なド キュメントの扱いにはあまり長けていない。そして未だに言葉の意味を把握してくれない -- 動詞のduckと名詞の duckの区別もできないし、ジャワ島のJavaと、コーヒーのJavaと、プログラミング言語のJavaについて書かれたドキ ュメントを分けて分類することができないのだ。
優れた自動分類ツールとは、扱う人間が手を入れて判断を下すことが可能なものだ。私がデザインに関わったあるカスタ ムツールは、潜在的なカテゴリーのリストをアップし、それに対して人の手による入力に基づいて個々のコンテンツを当ては めることができた。リストからふさわしいカテゴリを選ぶのは人の手にまかされていて、もしふさわしいカテゴリがなかった としたら、全体のリストの中から選ぶことができた。
もうひとつのアプローチは、類義語を生成し管理するツールを創り出すことだ。シソーラスは、ライターが使う手 軽なリファランスに近い情報検索ツールである。リスト内の各単語に対し、分類体系の観点から単語間の親子関係を明らかに し、代替の単語として同義語を、またその単語と似た意味をもつ関連した単語を示してくれる。よくできたシソーラスは、情 報検索の際の多大な不満を解消する手助けとなるだろう。
例えば、あなたが洋服を販売するeコマースサイトを構築していたとしよう。そこでユーザーが、システムの中で「ジャケ ット」と呼ばれているものに対して「ブレザー」で検索をかける度に、シソーラスはユーザーがイラつくのを防いでくれる。 シソーラスを用いれば、「ブレザー」を「ジャケット」の同義語としてみなすことができるため、どちらでもふさわしい検索 結果が表示されるというわけだ。同じように、シソーラスの関連単語の機能を用い、ユーザーがある特定のジャケットを見て いる際、サイドバーにそのジャケットに合ったパンツを表示することも可能だ。
多くのシソーラスのツールは成功している。なぜなら人間とコンピューターの両者が巧く結びついて作用しているからだ 。まず、人間の強力な脳と戦略的な知識を用いて、人の手でできる限りのことができる。またコンピューターも、膨大な計算 を伴うリソースにより、すばやく、かつ人の手でこなしきれない量の作業をこなすという、限定された機能が最大限生かされ ている。
Thomas Myerは作家であり、マルチメディアデベロッパー、ウェブデベロッパー、そしてインフォメーションアーキテク トです。彼が執筆やインタラクティブプロジェクトの設計を行なった顧客にはシスコシステムズやヴィネットなどがあります 。現在はコンサルタント兼作家として活動しています。Thomasの連絡先はtom@myerman.comです。