「情報アーキテクチャ」記事の一覧
例えばAという機能の説明を作成する必要があるとしましょう。そのためにまず必要なのは、形として表れてくるUIの外部仕様を知ることではなく、機能全体を理解すること、そして機能訴求ポイントや訴求方針を押さえることです。そういった面を全部想像してライティングするよりも、当該設計／実装に至った経緯を記した検討資料や各種仕様書（いわゆる「ドキュメント」）を入手して、エンドユーザー向けにコンテクスト変換した上でブラッシュアップ、必要に合わせて不足情報の追加というフローで作業した方が、正確で重要なポイントを押さえた成果物につながるわけです。それも効率良く。
なのですが、どうもこのドキュメントを要求する行為を甘えと取る人がそれなりにいるようで、なんだかなあという感じです。資料開示すればすぐに問題が解決するにも関わらず、どうして開示を嫌がって原稿作成工程に無用の負荷を掛けたがるのか、理由がまったく謎です。新規テキストをスクラッチでイチから起こすことと、エンドユーザーの利益（ひいては製品やサービスの提供側の利益）と、重要なのはどちらでしょうか。いろいろ見聞きしている範囲ではありますが、何を優先するべきか？の判断基準がズレてきてるなあ...と感じることが増えた今日この頃です。
この種の問題のありがちな原因として、開示できるレベルのドキュメントを残していない（から開示できない）というのであれば、それはそれで大問題ですよね。開発＆コアグループだけで検討や情報共有が完結するならば、整理されたドキュメントなしでも（当座は）良いのでしょうが、デザインにせよテキストにせよ、あとから外部発注作業を入れることが前提であるならば、絶対に何らかのドキュメントを残す必要があります。それに運用フェーズや人事異動でメンバー変動が発生することを考慮に入れれば、「開発＆コアグループだけだからドキュメントは不要」という弁解が通るはずがないのは自明だと思うのですがね。
ところで、エンドユーザー向け外部説明（各種ガイドやヘルプ、FAQ）の構成検討は、製品・サービス仕様検討と並行して進めるべきというのは、一体いつになったら一般化するんでしょう。仕様検討の段階で「これは仕様で対応、これはUI上のテキストラベル他で対応、これはヘルプなど外部説明で対応」のようにしっかり考えておかないと、最後になって「マニュアル（ヘルプ）に書いておけばいいや」のお約束が発動することになります。エンドユーザー向けのFAQを検討するなかで、仕様検討から漏れている観点も拾うことができるという効用も、いまいち理解されていないようです。ただコストダウン圧力の余波で最近はお疲れ気味とはいえ、メーカー系はなんだかんだでまだしっかりしてる印象です。Web屋さんはHCDとか言うのであればもっと頑（ｒｙ
ということで、「ドキュメント出して」「ドキュメント作って」「ドキュメント観点も大事」というまとまりがないようなあるような怪しい三本立て（何）でお送りしました。
本来であれば2ヶ月半前に公開予定だった研究発表「コンテクスト変換という幻想（DITAを巡る話題）」、ようやく公開です。TCシンポジウム前（それも東京開催前）に公開する予定だったのに、テキストエディタが落ちて編集中のデータが飛んだり様々な不調に祟られたり、ようやく...です。
TCシンポジウムやDESIGN IT!でDITA（Darwin Information Type Architecture）が話題になっていたようですが、反応を見る限りでは、相変わらず変な誤解が（特にWeb制作業界やSI業界に）あるようです。何らかの形で「シングルソース化」に携わった経験のある、TC系の人達の冷たい（または生暖かい）視線とは対照的なのが何だかなあ、という感じで（笑）
気になったのはこの辺の記事ですかねー。
良い機会なので、シングルソース化の限界と絡めてこれまで考えていたことをまとめてみました。以前のエントリ「情報大工的CMS導入のポイント」と同様、なんか実体験の反省が入っているとかいないとか...。ああ、やっぱり胸の奥が痛い。
前から書こうと思ってストックしていたネタだったのですが、多忙にかまけて失念していたことをDITA騒ぎの最中に思い出したという（汗）
えーと、CMSの導入が当然のような流れに世の中ではなっているようなのですが、遅まきながら気になることを書き連ねておきたいと思います。なんか実体験の反省が入っているとかいないとか...。ああ、胸の奥が痛い。
まあ、CMS屋さん的には当然のこととして行われている、当たり前の話ばかりですよね。ですよね？？？というのは、「"DITA"と"CMS"- DESIGN IT! Forum 2009 参加レポート」を読んで、何とも言えない不安感に襲われたからなんですけど（汗）
やはり上記のポイントのうち、最後の項目については忘れられていることが多いようですね。そもそも部品粒度を下げること（＝情報の枠組を詳細に作り込むこと）の効果は、部品（情報）単位での抜け・漏れおよび部品内の記載内容のブレの防止、による品質向上にあると思うんですよね。で、その辺をサポートできる存在という意味で、CMS屋さんはドキュメント屋さんと組むといろいろと良いことがありそうなものなんですが、いかがでしょう（笑）
以前某所に書いたことを、清書・増補する形でこちらにも。
ここ数年の仕事で、改めて痛感したことがあります。マニュアル制作の場合、これまでも説明対象（製品とかサービス）がどんどん専門化・高度化・複雑化している印象はありましたが、ここ数年の製品は特に危険なレベル（謎）に突入しているように感じます。
というのは、新しい概念や機能をユーザーに説明する以前に、それらをまず自分で理解するために必要な前提知識の範囲が拡がり過ぎているように思えるからです。最新機能を理解するには、機能そのものを表面的に理解するだけではダメで、周辺技術やレガシー技術を含む、技術的な経緯に対する理解という土台が必要なことが多いのです。特に「以前と比較して〜です」ということを説明する必要がある場合などは、目も当てられません（笑）
製品理解という問題に対しては、例えば以下のような枠組み
- 基本的な操作フローの概念
- 各機能の内容とコンテクスト
- 各機能の相互関係／制約事項
- 個別コントロール／オブジェクトの挙動
を利用することもできますが、これだけでは表面的な操作手順説明書を仕上げるので精一杯です。もう一歩踏み込んで理解できないと、製品情報をユーザーの視点で組み替えて提供する、というところまで到達できません。
マニュアル制作に関連する「最新情報についていけなくて大変だ」という話題は、制作ツールのバージョンアップに伴うソフトウェアの使いこなしに代表されるように、制作技術や制作プロセスの問題に収束しがちです。ですが、説明対象の専門化・高度化・複雑化そのものについても、改めて目を向けて行く必要があると感じています。
さてここでいきなり話は変わりますが、この辺の問題についてWeb屋さんはどう感じているのか、非常に興味があります。
コンテンツの制作に当たっては、制作技術の問題以外に、説明対象をどう理解するのかという問題にブチ当たるはずです（例えば、金融商品系のコンテンツなど大変そうです）。通常のいわゆる情報設計／IAと呼ばれるプロセスでも、この辺の問題を避けて通ることはできません。何故なら対象をしっかり理解することなしに、情報設計などできるはずがないからです。分野は違いますが、業務システムを開発されるエンジニアの方は、対象業務について一生懸命勉強されますよね（たぶん）。
もちろんこの辺の地道な問題に対して真摯に取り組んでいる方も多いとは思うのですが、コンテンツ（情報）そのものにどう向き合っていくか？という話がWeb屋さんの議論には全然出てこないように見えるのです。「先方支給」の一言では済ますことのできない世界だと思うんですが、どうなっているものやら、不思議に感じる今日この頃です。
Web 2.0では「ユーザー体験の品質向上」ということが良く言われるんですが、サポート情報は蚊帳の外という感があります。
まず、Webの世界におけるマニュアルやヘルプそのものの質が上がっていないと感じます。コンテクストを意識したAJAXによるユーザビリティ改善という発想があるなら、ヘルプに関してもコンテクストを踏まえて欲しいものです。商用アプリケーションでは（画面単位レベルが多いですが）コンテクストを意識したヘルプトピック呼び出しは常識ですが、Webサイトではこの辺イマイチですね。いまだにヘルプのトップページへのリンクのみというのは、ちょっと。商用アプリケーションとWebサイトでは、開発者のコミュニティが分断されているのが原因なんでしょうか。ユーザビリティテストでも、サポートドキュメントに対するチェックはやってなさそうですしね...。
製品情報を扱うWebサイトにおける、サポート情報の扱いも酷いものです。個別の製品情報を表示しているページで、サポート情報へのリンクがグローバルナビゲーションにのみ存在する（つまりサポート情報のトップページへのリンクしか存在しない）というのはどういうことでしょうか。個別製品のページを閲覧しているのであれば、当該製品のサポート情報をそのまま閲覧できる経路を用意するのが当然だと思うんですが...。サポート情報を閲覧してから購入するかどうか判断する商品もあるでしょうし、制作者側がもっとユーザーの心理を考えるべきです。
ここで無理矢理Web 2.0的な方向に話を持っていくならば（笑）、まずは製品ごとのサポート情報URLを固定することが必要でしょう。で、サポート情報は継続的にRSS配信するようにして、購入した機種に関連するサポート情報をユーザーが簡単にいつでもチェックできるようにする、と。ただRSSの購読登録などは一般ユーザーにはまだまだ厳しいでしょうから、その辺の仕組みはうまく隠蔽する必要があります。例えば、製品ごとにユニークなIDを割り当てておいて、WebサイトでそのIDとメールアドレスを入力すれば詳細登録方法の案内メールが届くのでも十分ですし、携帯ユーザー向けには、マニュアルの表紙に登録用URLのQRコードを用意するといった手もアリです。そもそも、更新情報ならメール通知だけでも十分かもしれませんし。
この辺の仕組みや挙動については、できれば家電メーカーで統一するというか共通の枠組みを用意して、Web 2.0的に（笑）利用できるようにすれば良さそうに思えます（これなら海外メーカーから非関税障壁だと文句も言われないでしょうし）。リコールまではいかない不具合通知とか、単に各社がそれぞれWebサイトの「お知らせ」コーナーに掲載するだけの今の方法よりも、よっぽど効果がありそうです。特に白物家電を始めとする各種生活家電など、情報家電以外の長寿命製品には効果的でしょう。（最近の製品トラブル続出に伴う）購入ユーザーへの情報伝達の難しさを見ても、サポート情報の伝達方法を再考する良い機会ではないかと思います。
いままでユーザー登録というと、顧客囲い込みの一環という発想しかなかったように思われます。しかし、新製品のお知らせなど、メーカー側の商魂丸出しの情報を送ってもらうために、ユーザーはユーザー登録をする訳じゃないんです。それよりも、部品保有期限が切れそうな時期に「そろそろ修理用の部品がなくなるので、調子が悪い個所があれば早めに修理依頼を」というお知らせを出してくれるとか、そういう気配りこそユーザーがユーザー登録という仕組みに求めるもののはずです。情報の取捨選択の主導権がユーザー側に移行している以上、ユーザー保護の観点を重視しつつ、あえて囲い込まないアプローチも模索する価値があると考えますが、いかがでしょうか。
気分的に（笑）先のエントリからの続きになります。
今年の講義（諸事情で今年は前期開講）ではレポート課題の他に講義中のミニ課題を課したのですが、そこで気付いたことがあります。表現すべき情報の枠組みをある程度細かく指示するとしっかり書けるのですが、（意図的に）枠組みをぼかすとアウトプットが途端に怪しくなる、という傾向があるのです。これは要するに表現能力ではなく、コンテクストを踏まえて枠組みを設計する能力の不足が問題の原因、ということなのでしょう。
学生の名誉のために一応断っておくと、どうもこの問題は学生だけの問題ではないようです。以下はJAGAT（日本印刷技術協会）のクロスメディアエキスパート試験の講評の一部ですが、
試験には意図があって問題が作られ、与件があるのだから、それを理解して解答していかないと、解決策は出てこない。その基本的なところが慣れていないようである。
この講評を見ると、社会人も同じような問題を抱えていることがわかります。また、この講評を見るまでもなく、マニュアルの品質低下の問題を扱った先のエントリ中の
「閲覧コンテクストを想定した上で、どのような情報をどのように提供すべきなのか？を正しく判断する」という、マニュアル制作のプロセスで一番重要なところができていない
も、問題の構造としては同じものと言えるでしょう。
ということは、この問題をどうにかする教育方法を考案できれば、情報設計の品質の底上げにつながるのではないか？ということになります。単なる分類ではなく、コンテクストを踏まえて枠組みそのものを設計することにこそ、情報設計の醍醐味がある訳ですから
具体的な解決策はまだ明確になっていないのですが、「料理レシピの枠組みを挙げる」という課題を課したときは、いろいろな枠組み（和食とか煮物とかさっぱりとか）を挙げることができた学生が多かった、という事実が突破口になりそうな気がします。「ある程度の具体的な料理を知っていて、ある程度の枠組みも知っている」という条件であれば、「具体的な料理から枠組みを想像できるし、想像した枠組みから他の欠けた枠組みも補うことができる」訳です。これはある意味当たり前の話ですね。
そうするとやはり、枠組みを創造することができないのではなく、枠組みを創造するための想像が及ばないという問題をどうするか？という話に収斂します。したがって、枠組みに含まれる情報と枠組みそのもの関係、そして両者を規定していく情報設計プロセスの考えかた、といったあたりが課題になってくるのではないかと思っています。まだまだ漠然としていますが...。
で、この辺の課題意識と情報設計一般プロセスについてですが、来る9/21にJAGATのセミナー「受け取る側の立場に立った『情報デザイン』とは？」の一部としてお話させていただく予定となっております。セミナー用に出し惜しみしているように見えるかもしれませんが、それは気のせいで実はこれから詳しく考えるところなのでお気になさらず（汗）
極端な多忙という訳ではないのですが、なぜかバタバタしており更新が停滞気味で申し訳ありません。更新が停滞していると「お忙しいんですね」と言われて困ってしまいますが、そういう訳でもなかったりしますので、お気になさらぬよう（謎）
さて、Webサイトやインターネットを利用したサービスにおけるユーザー体験ということは良く言われたりするんですが、普通に生活を送っていると「ユーザー体験的にこれってどうなのよ」と思うことは多々ありますよね。
ユーザー体験を通して形作られる企業に対するイメージというものは、（言うまでもないことですが）Webサイトそのものだけではありません。実店舗のサービスの質もそうですし、ユーザーに対するすべてのコミュニケーションのチャンネルが関わってくるものです。その意味でハードウェア製品そのもののデザインや使い勝手だけでなく、付属する各種マニュアル／ヘルプも立派なコミュニケーションチャンネルの1つです。
従って、マニュアルの表紙が本体デザインを意識したデザインになっていて、「さすがau design project製品だ、購入した甲斐があった」と思ったら中身のデザインがボロボロで「上っ面だけのデザイン統一かよ」とがっかりしたneonのような事例では困る訳です。もちろんこれも私怨です（笑） その点、Appleはさすがにこの辺徹底していますよね。
上記のような問題が頻発していることを踏まえると、どうもこのすべてのチャンネルを統括してコミュニケーション戦略やユーザー体験を設計する機能（組織／人）が不在のまま、放置されているように思えます。単に放置されているだけならまだマシで、この種の機能の重要性が未だに認識されていないのではないかという気すらします。ブランドマネジメント担当部門が存在する以上、この種の部門もあるべきだと思うんですけどね。
Web 2.0の議論で散見されますが、個別の技術論とか実装論なども確かに重要です。とは言え、やはり専門化された個別チャンネルが高度に統合される時代にあっては、（全体を俯瞰しつつ）個々のユーザーにどのような体験を提供したいのか？ということこそ最重要視すべきです（もちろんボトムアップを単純に否定する訳ではありません）。顧客満足の観点から個別チャンネルが有機的に連係していくようなサービス設計を行わないと、違和感や不快感の残るユーザー体験はいつまで経っても減らないことでしょう。
昨年から自分なりにいろいろ考えていたことがあるので、（車輪の再発明的な話ばかりで申し訳ありませんが）とりあえずまとめてみました。各種オフ会などで友人には話したことがあるのですが、そういうものは完成度度外視でとっとと公開しろ（Web 2.0精神...）と随分言われましたので。
まずWeb 2.0でデータ中心という話が出てくる前提ですが、
という流れがあったかと思います。もちろん知的財産の共有という大目的あればこそ、ですが。
ただ、大元のデータに関しては、やはりblogとか写真だけだといまいちつまらない（笑）訳です。商業ベースで制作・流通されているコンテンツ（映画とか音楽とかに限らず、広義のコンテンツ）を利用したいというのが、ユーザーの偽らない心境でしょう。
そうなると、
ということになります。Web 2.0のポイントはデータの利用価値にあるというのも、このコンテクストで考えるべきです。
ここで問題となるのは、「公開した方がメリットがある」という主張が妥当かどうかです。確かにamazon.comのように、最終的にコンテンツ（＝データ）が物販の入り口に直結しているような場合は妥当でしょう。公開することによって自らのビジネスの機会が明示的に増大するからです。しかし地図コンテンツ（特に道路や建物がベクター化されているような手の込んだもの）が良い例ですが、コンテンツベンダ自身（地図データであれば地図作成会社）が無償で公開する動機付けに欠けるケースも多いのではないでしょうか。
ここで地図データを例にして考えてみましょう。この分野でのWeb 2.0的なサービスとしてはGoogleローカルがあり、Googleローカルはゼンリンにお金を払ってベクター形式の地図データの提供を受けているようです（衛星写真モードの話は置いときます）。この投資をどのように回収するかですが、ローカル検索上で地図とPOI（Point of Interest）を組み合わせて、地図コンテンツに投資した費用をGoogleがクライアントの広告費用という形で間接的に回収するという形になると思われます。
この場合、最終的なコンテンツ提供者（ゼンリン）のビジネスというよりはむしろ、それを組み合わせて売りにできるシステム提供者（Google）のビジネスになっているわけです。Web2.0絡みでよく言われているリミックスやマッシュアップというのはこういうことで、Web 2.0的なビジネスをしようと思うのであれば、「公開した方がメリットがある」というスキームをシステム提供者が設計できるかどうか（Web 2.0的なコンテンツ公開をコンテンツ提供者とユーザーに納得させられる絵を描けるかどうか）が一番重要なポイントになります。
逆に言えば、コンテンツ提供者側がこの絵を描けないようだと、たとえシステム提供者のサービスがコンテンツに依存するものであっても、サービスのイニシアチブを自ら取ることは永遠にできないということになってしまいます。地図データなしにサービスが成立しないにも関わらず、ビジネスの主体はGoogleになっているGoogleローカルの存在がその代表例です。コンテンツ生成にコストがかかる上に、公開という手段がビジネスに直結しにくいニュース記事や地図などのコンテンツの場合、この辺が悩みどころでしょう。個人的には、ビジネスになりにくい種類のコンテンツが軽視される世界は好ましくないと思っていますので、現場の方の発想に期待したいところです。
まあそんなこんなで、Web 2.0時代ではデータがモノを言うのは確かなんですが、そのデータでビジネスができるかどうかこそ問題だという点にももっと注目が集まって欲しいところです。また、単にデータでビジネスをするだけならGoogleやYahoo、MSN（Microsoft）などのすでに巨大なデータベースを持つシステム提供者の総取りビジネス、強者必勝の世界になってしまうでしょうから、その流れにアイディアでどう対抗していくのか？が今後の見所ではないかと考えています。
という訳で専修大学ネットワーク情報学部で半期の講義を持たせていただいた訳ですが、（講義資料を突貫で作りながらも）どうにか無事に終了しました。冷静に振り返ってみるに、最低限伝えなければならないことは伝えられたと思いつつも、反省すべき点も多かったというのが正直なところです。
やはり興味を持ってもらおうと対象領域を広げ過ぎたのが大反省もので（そっち系のネタが受けていた面もありますが）、もう少し課題を絡めた情報設計プロセスの反復実践をしなければならなかったかなと。その分の埋め合わせとして、レポートのフィードバックは（ある程度ですが）しっかりするように心掛けましたが...。企業内研修でも同じことだと思いますが、やはり講義と課題のバランス、課題のタスク設定が問題でしょうか。課題に対するフィードバックを行うのも、かなりの時間を要しますので。
おかげさまで来期も継続ということになりましたので、今期の反省を踏まえて講義設計を行いたいと思います。「講義資料を公開しろ」という声もいくつか頂いておりますので、来期は胸を張って講義資料を公開できるようしっかり頑張りたいところです。
さて専修大ネットワーク情報学部では、2年次のCD総合演習（→「情報の積み木」展）や3年次のプロジェクト（→プロジェクト発表会）で、グループワーク形式の実践課題を課しています。今年度の発表会を見学しての感想ですが、（教員側の試行錯誤もあるなかで）学生が結構頑張ってるなという印象を受けました（上平先生の感想）。ちなみにこれらの成果物ですが、学生有志がコウサ展という形で発表会を行っているようです。今年は2/4〜2/5に開催されるとのことで、活きの良い学生を物色したい企業の方（笑）、情報デザイン教育などその方面（謎）に興味のある方など、ぜひ足をお運びください。
あ、次回から車輪の再発明シリーズ（汗）と題して、Web 2.0の話とかフォークソノミーの話とかすると思います...。業務多忙は完全に脱したので、いまのうちに社会復帰できるよう頑張ります。
cybozu.nite 2.0の感想（遅い）とかエントリしようと思っているのですが、ちょっと燃え尽き気味で停滞しております（業務負荷は大幅に下がってはいるのですが...）。そんなこんなで停滞しているなかでF's Garageのf-shinさんから情報収集のための11の質問が回ってきたので、リハビリがてら答えてみようかと。
方法というよりもむしろ態度に関わることでしょうが...。
情報としてパッケージングされたものには、最近あまり関心が向かないような気がしています。それを情報源と言うべきかどうかはともかくとして、注意深く見るようにしているものとしてですが。
ちょっとした縁がありまして、専修大学 ネットワーク情報学部の講義で、ゲストスピーカーとして情報設計についてお話させて頂きました（上平様はじめ、皆様ありがとうございました）。
目的としては、
というあたりを狙いました。学生の皆様にうまく伝わっていれば良いのですが。まあ、すぐに直接役立つ場面がなくとも、心の奥底でひっかかっていてもらえれば十分に目的は達成できたのではないかという気もします。
このような学際的な領域を意識して取り組む大学が増えてきたように感じていますが、やはり現場ではどのように課程を設計するか、難しい面もあるようです。学際的な領域というのは基本的な体力（大局的なものの見方や論理思考力、ベースとなる広範な知識など）がモノをいう世界だと思うのですが、最近では即戦力志向ということでどうしても基本的な体力づくりにじっくり時間を割けない、ということに主な問題があるようです。
即戦力としての能力（＝技能）の向上を目指した取り組みをして行く中で、基本的な体力を向上させて行くような課程が同時に求められている訳で、実際に設計しようとすると、バランスの取りかたも含めてなかなか難しいものがあります（就職活動の早期化も、設計を難しくしている理由です）。いずれにしても、情報設計のような学際的な領域で活動するものとして、このような領域に関しても注目していくべきであると強く感じました。
さて、話は変わって更新が途絶えがちな理由です（申し訳ありません）。
夏前からとある業務システムの要件定義・設計支援（というかお手伝いというか）業務が本格的に動いています。ということで、他の案件もこなして行く関係上、ここ数ヶ月かなり多忙な状態が継続しています（それでも得るものが非常に多いこともあり、感謝しております）。今後も業務手順書の設計など、システムを利用した業務運用に必要な環境整備なども行わなければならないため、更新は当面かな〜り飛び飛びになってしまう可能性がありますが、あらかじめご了承頂ければ幸いです。
検索エンジンを自社のマーケティングに活用することを目的とした、SEO（検索エンジン最適化）と呼ばれるWebサイトの再構築が流行ってるようですが、以前からちょっと気になっていることがあります。
SEOのプロセスを詳細まで熟知している訳ではないので外している可能性もありますが、検索に使用されるキーワードを意識して情報を構成するという考えかたそのものに、漠然とした不信感があるのです。例えば、Googleでは見出しやリンク部分に含まれる文字列が検索結果に大きく影響する、つまりキーワードの配置場所として効果が高いと言われていますので、その辺を中心に文字情報をコントロールすることがまず重視されることになります。
ですが、そのような文字情報のコントロールによって、Webサイト内を回遊するユーザーへのわかりやすさが損なわれる可能性があります。つまり、キーワードが一般名詞として完全に認知されていない場合は、Webサイト内の情報カテゴリ名やナビゲーションのタイトルにキーワードを使用すると、使い勝手の面で問題が発生する可能性がある、ということです。これは何故かというと、キーワードのような特殊な名称よりも、一般的な言い回しの方が表現としてわかりやすいためです。
また、キーワード重視の姿勢がWebサイト全体の情報設計に影響を及ぼす可能性も出てきます。極端な例ですが、キーワードを元にした情報分類が強制されることで、ユーザーの動機を中心とした情報設計に影響が出る（ユーザーの利益と相反する）ことも考えられます。これらの問題を引き起こさないためにも、「SES（サーチエンジンスペシャリスト）に求められる素質」でも触れられているように、
WebページをSEO施策で改善する際にも、SEO施策後のページが、 ユーザーが見て違和感を感じないページなのか、ユーザビリティの観点からはどうかなど配慮し、SEOのためのSEOにならないようにしなければならない。
ことが非常に重要となってくる訳です。
検索エンジン経由のユーザーが多いというのは、確かにその通りです。ですが、検索エンジンへの最適化が（訪問後の）Webサイト内回遊への足かせになってしまうようでは、目先の訪問者数が増えたところで、総合的に見て得策とは言えないでしょう。そこまで承知の上で検索エンジンへの最適化を優先するのであれば良いのですが、果たしてどこまで理解されているのかは疑問です。現状の検索エンジンからの訪問者を増やすためには仕方がないとはいえ、本末転倒は避けて欲しいところです。
Yahooがページ検索をGoogleから独自エンジンYST（Yahoo Search Technology）に切り替えたことがニュースになりましたが、検索技術の仕組みはほとんど変わっていないようです。これはつまり、本末転倒の最適化が存在する余地がまだまだあるということです。このような問題を解消するためにも、Webサイトの情報設計がユーザーに最適化された状態でも、必要な情報を過不足なくスムーズに入手できる（＝表面的な言葉の設定で検索結果が左右されない）検索技術が、一刻も早く登場して欲しいものです。
先日開催された、ソシオメディア（株）主催のメタデータに関するセミナーに行ってきました。
パネリストのメンバー選定の勝利（笑）でしょうけれども、特にパネルディスカッションが充実した素晴らしいセミナーでした（これで参加無料というのも、すごい話です）。ダブリン・コア策定に従事されている両氏の発表内容は近日掲載されるであろう公式レポートに任せるとして、ここではダブリン・コアとメタデータに関しての感想を、一参加者の視点から箇条書きで。
少しネガティブ色が強くなってしまいましたが、「使える」知識ネットワークの基盤として機能することを期待したいところです。いろいろと考えることの多い、非常に有意義なセミナーを主催されたソシオメディア（株）と発表者＆パネリストの皆様、本当にどうもありがとうございました。
「セマンティック・ウェブが目指さないもの」（The Web KANZAKI）を読んで、思ったことをつらつらと。
セマンティックWebというのは「セマンティック」という言葉に惑わされるとやはりダメで、情報に対する単なる形式属性を記述するための規定と捉えるべきではないかと（気付くの遅い？まだ誤解してる？）。WindowsのエクスプローラとかMacOSのFinderでファイルを扱う際に表示できる、ファイルの名前や変更時間、ファイル容量などの各種プロパティみたいな感じで。
ただ「ファイル」ではなく、個々の「情報」が持つ属性を記述するための規定だという点が根本的に異なるわけです。情報をネットワーク上にファイルとして置いたときに、ファイルとしての属性と情報そのものの性は当然異なります。ですから両者を分離して、情報の属性を中心として扱うための仕組みを整備する、という意味合いが大きい、と。
この辺は「blog系サイトのlast-modefiedを見るとコメント追加によるリビルドまで拾っちゃうから、RSSのdc:dateを見るようにした方が良い」といった、アンテナ界隈で耳にする話と関連するかもしれません。
さて話を元に戻すと、ここで「情報が持つ属性」という部分が、セマンティックWebが誤解される大元のような気がします。
「情報が持つ属性」と表現すると、情報（コンテンツ）の内容を表現する属性と想像されがち（「セマンティック」だし）ですが、実際には著者や作成日時を始めとした、情報の形式属性（外部属性とでも言いますか）を規定することに主目的があるように見えます（先に「単なる形式属性を記述するための規定」と書いたのは、こういう意味です）。その意味で、セマンティックWebという用語はやはり良くないような気がします。誤解するのが悪いというよりも、誤解してくれといわんばかりの用語選定がちょっとアレかなあと。
ところで、セマンティックWebという言葉で（我々一般人によって）誤解されがちな方面では、Googleの動きが気になります。検索エンジンやSEOを主に扱うサイトの情報から判断すると、Googleが情報の重み付けを行うにあたって、どうもコンテンツの内容を見る方向でアルゴリズムを整備しつつあるようなのです。GoogleはAI（人工知能）を目指している訳ではないでしょうから、内容そのものを理解するのではなく、あくまでリンク構造や各種マークアップを中心とした形式構造から、コンテンツの内容の意味判断や重み付けを行うつもりでしょう。
個人的にこのようなボトムアップの問題解決方法には限界があると考えているのですが、このアプローチでどこまで行けるのかには興味がありますし、今後の動きに注目したいと思います。しかしこの辺の話はLonghornのWinFXが先行するものとばかり思っていたんですが（過去記事）、やはりネットワークの世界の方が動きは速いようです...。
「おのひろきおんらいん」経由で、「ちょっとだけFOAF」という気になる記事を発見。
自分の知人、友達の情報を記述する（逆に友達じゃない人は記述しない）ということは、自分の人間関係をデジタルに（1or0、yes or no）で二分するということを行い、それを公開するということにもなるのではないかと思ってしまったのである。
FOAFの話はともかくとして、「デジタルに（1or0、yes or no）で二分する」というところがこの記事の重要なポイントでしょう。ノードをリンクで結ぶような構造に顕著ですが、構造化一般に付随する「デジタルな境界」という問題はなぜか見過ごされがちです。同じような問題を以前から考えていましたので、同志を発見してちょっと安心してたりするんですけど。
で、実はこの辺の問題をテーマとして、某誌の原稿を昨年からこつこつと書いていたりします。vivisimoをはじめとする検索結果のクラスタ化の話題がこの年末年始でまとめて出てきましたが（WIRED NEWS記事、SEMリサーチ記事）、その辺の話にも関連することになります（内容的にはもっとメタ領域な話になりますが）。
内容が大袈裟（謎）なこともあり、たかだか10ページの原稿に時間かかりまくり＆泣き入りまくりですが、今回はwelle designの坂野さんに図版作成で協力を頂いたりと、いつも以上に気合いが入っております。当該書籍発売時にはこのコーナーでご紹介いたしますので、乞うご期待。
縁側*ccで何度か取り上げられている（その1、その2 他）「ファセット分類（Facet Classification）」なんですが、いまいち本質が掴めずに、いろいろと考えあぐねていました。
Googleで検索してみても、情報アーキテクチャ的な意味以外での使用法もあるようですし、「Web情報アーキテクチャ」中の説明もピンと来ません。ただ、図書館情報学に携わっている方がファセット分類の効用を主張されている節もあるようで、この辺にヒントがあると考えること幾星霜（嘘）、ファセット分類の本質は非MECE（mutually exclusive, collectively exhaustive、 互いに重ならず、すべてを網羅する ）にあることに、やっと思い至りました。
一般的には、「ファセット分類はディレクトリ型分類とは違って、属性中心の分類である」と表現されがちですが、カテゴリを中心にディレクトリ型のツリー構造を構築することもできますので、これでは適切な規定とはいえません。「Web情報アーキテクチャ」の記述にも、この混乱が見られるようです。正しく規定するのであれば、ファセット分類とは「1つの情報実体はツリー構造のうちの1つの位置だけを占めることができる」（MECEの考えかたそのもの）のではなく、「実体に付随する様々な属性を中心として情報構造を規定しているため、同じ情報実体が全体構造中に何度も出現できる」情報構造であると規定することが適当でしょう（pha::diary 2003年2月23日分も参考になります）。
ここでiPodを例にして考えてみましょう。iPodは据置型プレーヤーに対する携帯型プレーヤーと分類できますが、CDプレーヤーに対するMP3（AAC他）プレーヤー、再生専用機に対する録再機と分類することもできる訳で、これを無理に1つの分類だけに押し込んでしまうと、ユーザーの閲覧コンテクストによっては検索性に問題が出る可能性が高くなります。したがって、無理にディレクトリ型分類にこだわるのではなく、重複にとらわれずにユーザーの考える属性中心に情報を構成する必要が出てきます（この辺の問題については、「分類タグとは」の解説もわかりやすいと思います）。実際には重複情報を管理することは困難になるので、データベースを導入して情報を管理するケースの方が多いとは思いますけど。
さて、ここまで考えてきたところで、妙な符合に気付きました。
以前「MECE的マニュアルの限界」という記事を起こしたように、マニュアル制作の分野ではMECEの弊害が目立つようになっています。（今更ではありますが）ファセット分類が話題になるということは、情報アーキテクチャの分野でもMECEの弊害が強く意識されるようになってきたことに他なりません。
実際のWebサイトでは、データベースを利用した動的なコンテンツ管理やショートカット、関連情報という形でMECEの弊害への対策を行っているケースが多いように見受けられますが、まだまだ付け焼き刃な感がぬぐえません。したがって、情報設計の脱MECE化を当然の前提とした上で、どれだけユーザーの注目する属性中心の設計・表現ができるかどうかが、今後の情報設計・表現の鍵となってくるのではないでしょうか。
「東日本とにかくわかりやすいマップ普及推進委員会」の話がいくつかのサイトで取り上げられていたのですが、わかりやすい地図の書き（描き）かたとして今まで見た中で最もすばらしいものは、「分かりやすい地図の作り方」ではないかと思っています。
特に「目的地を上にして描く」ことが忘れられているので、地図を進行方向にあわせて見て文字が読めなくなったりするケースって、結構ありますよね。他にも重要なポイントが指摘されていますので、多くの方にご覧頂きたいところです。しかしどんなに良いことが書いてあっても、やはり地味系だとデザイナーの人達にはウケが悪いんでしょうかね（川村さんごめんなさい）。こうしたサイトこそ、じっくり読んでいただきたいところなんですけれども。
で、ちょっと気になって「わかりやすい 地図」でGoogle検索したところ、「東日本とにかくわかりやすいマップ普及推進委員会」は上位に表示されるものの、「分かりやすい地図の作り方」は全然表示されないのですよ。逆に「分かりやすい 地図」でGoogle検索すると、今度は「分かりやすい地図の作り方」は上位に表示され、「東日本とにかくわかりやすいマップ普及推進委員会」は全然表示されないという...。Google使えね〜。
そこで思い出したのが、独自日本語フロントエンドを実装してgoogleエンジンを利用する、12/1に刷新されたばかりの新しいgooですよ。「goo、Google 採用の新検索サービスを開始」での実例紹介を見ても、適切な補正を期待せずにはいられません。
それでは早速「わかりやすい 地図」をgooで検索...。ダメじゃん（泣）
過去記事「gooはファインダビリティを改善できるか」でも触れたように、フロントエンド側でユーザーが指定した語句を「そのまま」使用しないことに関しては、やはり不安があることも事実です。その辺の不安や不信感に対する配慮なのか、確実なキーワードから補正をかけることで少しずつ信頼性を向上させようという、長期計画を踏まえた船出なのかもしれません。それでもこの程度の表記揺れであれば、無条件で対応して欲しいところですけれども。
やはり検索エンジンもビジネスなので、お金が生まれやすいキーワードに対しての補正には熱心でも、それ以外のキーワードに対しては冷淡なのかもしれません。でも検索エンジンはネットワーク上の知識を活用するためのインフラ的な役割も担っている訳で、もう少し何とかして欲しいなあと思わずにはいられません。ということで、対処よろしくです ＞ goo （聞いてないってば）
「いわゆるアンテナ（＝情報感度）が高いと呼ばれている人は、特別な情報ソースを押さえている」という誤解があるような気がします。
もちろん本当に特別な情報（内部情報とか）を入手する機会というのもあるでしょうけれども、実は特別な情報なんてほとんどない（必要ない）ような気がします。「特別な情報を知っている＝情報感度が高い」ではないわけですし。量の絶対的な多寡はあるのかもしれませんが、基本的にはみんな同じ情報、またはその気になれば誰もが得られる情報を見ていると思うのです。日本語ソースだけでも、そこそこいけるはずです。
言うまでもないことですが、情報感度が高いというのは「有名どころの誰々が何と言っている」情報を押さえていることではないですし、「たくさんの情報を集めている」や「とにかく早く情報をつかむ」ことでもありません（それはそれで必要な能力だと思いますが）。同じソースから何をつかむ能力こそ、情報感度の高さに密接に関係があるのではないでしょうか。
そのためには、
といったプロセスが必要とされるのでしょうけれども、ここを意識的／無意識的にできるかどうかが鍵となりそうです。まあ類似があると思い込んで失敗することもあるでしょうし、共通部分と独特の部分を正しく切り分けるのは難しかったりしますが。あ、もちろん「自分ができてるか？ってことはとりあえず棚上げ状態」で語っていますので、ご了承くださいませ（苦笑）
さて、このような知的活動をシステム的に支援できるようになれば、ITも一人前ではないかと最近は考えています。以前は入手できる情報量が増えて単純に喜んでいましたが、最近は情報量が増えすぎて手に負えないという問題ばかりが目立っています。しかし言うまでもないことですが、知的創造や意思決定の支援材料としては、より多くの情報を利用できるに越したことはないわけです（もちろん単純に情報を積み上げるよりも、利用する情報の質こそ問題ということは重々承知しています）。
データマイニングなどの技術も進展しているようですが、こうした知的活動を支援するための概念枠組みを考えることは、情報アーキテクチャの周辺課題にも間違いなく入っているのではないかと思います。できる範囲ではありますが、こうした問題についてはこれからも考えていきたいところです。
11/14に開催された、W3C Dayに行ってきました。
いろいろと思うことはありますがまだ頭の整理がついていないので、11/17に開催されたセマンティックwebコンファレンスとあわせて、関連情報をとりあえずクリップしておきます。なお、当日の会場で使用されたスライド資料は、「W3C Day Japan 2003 プログラム」からダウンロードできます。
メタデータ周辺の話題がここ数日でまとめて動いた感じもするので、そっち系の記事もまとめてクリップ。
クリップ逃げみたいで申し訳ありませんが、メモ代わりということでご容赦くださいませ。
ファインダビリティとは「見つけやすさ」のことで、大量の情報から目的の情報を適切に探し出せることを意味します。
素直に「見つけやすさ」という言葉を使わなかったのは、新たなキーワード商売を目論んでいるからではなく（笑）、SEO（サーチエンジン最適化）の実験のためです。あらかじめご了承ください。
なお、ファインダビリティに関しては、AIfIA（アシロマ情報アーキテクチャ研究所）の「ファインダビリティ（見つけやすさ）の時代 」もあわせてご覧頂ければと思います。
さて、国産検索エンジンとして長く親しまれて来たgooがGoogleのエンジンを導入するということで、関連する記事やコメントも数多く出てきました。国産の独自エンジンが第一線から消えることを嘆く声も多い一方で、国産の国語解析能力がGoogleの検索パワーと組み合わされることに期待する声も聞こえます（「SEMリサーチ」の記事がよくまとまっています）。
その一方で、フロントエンド側でユーザーが指定した語句を「そのまま」使用しないことに対して、次のような不安の声も出ています。
キーワードの自動修正は余計なお世話のような気がします。もし検索時にGoogleのスペルチェックのような修正候補の提示なしで、意図しないキーワードへの自動置き換えをするのであれば不要な混乱を招くことになりそうです。
これはもっともな不安で、確かにこのような処理を行うことで、どうしても検索語の適合範囲は広がってしまい、その結果として無駄ヒットが増えることにもつながりかねません。
ですが、日本語には同じ言葉を指しているにも関わらず、送り仮名や音引き、外来語の表記法、全角英数字と1バイト英数字（いわゆる半角英数字）などで表記のバリエーションが多くなりがちで、それによって検索効率が低下している部分も大きいのです。このサイトでなじみの深い用語では、インターフェースとインターフェイスとインタフェースといった用語がまさにこの例に当てはまります（この例では、Googleはある程度同じものと見なしてくれているようですが）。
これらの用語はどれが正解ということでもなく、会社や組織などによって固有の使用用語が規定されているのが問題です。つまり、ユーザーはその会社なり組織なりでの用語の使用法など事前にわかるわけがありませんから、ユーザーが想定した情報が存在するにも関わらず、用語表記のブレのために情報を見つけることができないということにつながるのです。
この辺の検索エンジンと検索用語の事前検討によるファインダビリティ（見つけやすさ）の改善については、つい先日第二版が発行された「Web情報アーキテクチャ」でも重要な要素として取り上げられています。興味のある方はこちらも参照してみると良いでしょう。また、(株)ソシオメディアの上野氏によるフォーラム（後述）発表でも、この種の問題を解決することが、Webサイト内の情報アーキテクチャを改善するポイントの1つであると指摘されています。このように、検索エンジンのフロントエンド側での対策は、単に検索エンジンの改善だけに留まらず、Webサイト内（ネットワーク内）の情報の利用効率を改善するために重要な役割を持っているのです。
ところで「Web情報アーキテクチャ」関連の話ですが、著者の一人であるルイス・ローゼンフェルド氏が先日来日され、(株)ソシオメディア主催のフォーラムで講演されました。縁あって聴衆の一人として参加させて頂きましたが、その後の発表やパネルディスカッション、そして交流会（笑）すべてに密度の高いものでした（フォーラムのレポート）。ルイス・ローゼンフェルド氏および発表者の方々、主催された(株)ソシオメディア、そして会場でお会いしたすべての方々に感謝です。
内容的に前回の続きになりますが、何かについての情報や知識をネットワーク経由で入手するためには、「散逸した関連情報をどうやって結びつけるのか」「それらの情報の関係を巨視的に把握できる仕組みをどのように用意するか」ということが、今後は（それだけでなくこの瞬間も）主要な問題となってくるはずです。検索エンジンの能力も上がってきているとはいえ、「検索結果にもっと精度が欲しい」「複数の検索結果の関連性を事前に確認できれば」と思うようなケースが実感として増えてきています。
つまり、ネットワークを知識ネットワークとして捉えると、まだまだ力不足な面が大きいのです。現状のシステム・考えかたは前述のような点がもともと弱い上に、対象となる情報量は増加する一方なのですから、これはある意味当然のことです。情報アーキテクチャの課題ではWebサイト単体（とそのサイトが関わるコミュニケーション全体）で完結する話が多いのですが、知識ネットワークを構築しようとするのであれば、ネットワーク内のリソース全体を見渡して考える必要が出てきます。この辺の課題に関してはセマンティックWebというアプローチがあることは重々承知していますが、コンセプト自体をいまいち信用できないこともあり、別の方向から少し考えてみることにします。
「TrackBackがうまく機能すれば、個人による情報発信が分散ベースの巨大メディアとして浮かび上がる可能性が大きくなる」と前回書きましたが、これは別にすべてのコンテンツがblogツールベースに移行するべきであるとか、このような世界はblogツールベースでしか実現できないということとは異なります。現在利用されている通常コンテンツでTrackBackのようなシステムをサポートする方法でも、それなりの効果を期待できるからです（その意味で、blogツールとTrackBackというシステムは分けて考えるべきであり、blogというツール／システムそのものに過剰な期待はしていません）。
ただし、これではTrackBackの使われかたがある一定の流儀に沿っていないと、あとから適切な形で関連性を切り取ることが困難になります。例えば「特定記事そのものに関する言及」をTrackBackと捉えるのか、それとも「特定記事が対象としている領域についての言及」をTrackBackと捉えるのかでは、対象となる情報の範囲がまったく変わってしまいます。他にもディープリンクですら紛糾する（苦笑）こともある以上、TrackBackを中心に置いて情報（知識）のネットワークを生成することは難しい面もありそうです。そうなると、コンテンツを置いている個別サーバー側で関連情報をやり取り・管理するTrackBackよりも、コンテンツ内のアンカー要素を抽出したメタ情報を集約して利用するようなアプリケーションの方が、情報の関連性を示す目的には効果的なのかもしれません。
とは言うものの、それじゃあ今までの検索エンジンと同じで、情報を集中管理していることに変わりがないのでは？とも思えます。確かにこのような方式では、優れた知識を分散系で持ちつつ、一体の知識として利用するというメリットが薄れてしまうケースが出てくる可能性もありそうです。そうすると、閲覧したWebページのキャッシュデータからメタ情報を生成して、その情報をP2Pで共有→何らかのアプリケーションからそのデータを利用する、というような方向が本命になるのでしょうか？（う〜ん）
まあこの話はそんなに簡単に結論の出るようなものではありませんので、これからも機会をみて取り上げていきたいと考えています。
ターゲットユーザーごとに情報を分類したいという場合に、安易に性別や年齢階層、職業などといった、いわゆるデモグラフィック特性による分類に頼ることが多くありませんか？ しかし実のところ、教職員・学生向けに限定して販売されるソフトウェアのアカデミックパック製品のようなものを例外とすると、実はこの種の分類が有効に機能する場面は少ないのではないでしょうか。
こうした分類は、本来「〜したい」というユーザーのニーズや欲求をベースとして行われるべきです。確かに、それらの層を代表するようなステレオタイプのデモグラフィック特性（30歳の男性会社員など）を提示することで、人に対して説明しやすくなる場合もあるでしょう。しかし、分類された情報を不特定多数のユーザーが選ぶという場面を想像するならば、やはりデモグラフィック特性による分類には無理があるのです。
例えば、Aという製品または情報が欲しいというユーザーに、たまたまBという属性の人が比較的多いとしましょう。この理由だけを持って、Webサイト上でAに対するリンクを「Bの方へ」というタイトルで誘導しようとしてしまうと、それが代表的なステレオタイプを提示する意図であったとしても、B以外のユーザーを暗黙のうちに排除してしまうことにつながりかねません。「特定のデモグラフィック特性が、想定される欲求やニーズを持つユーザー層とほとんど完全に一致する」というよほどの自信（笑）でもない限り、Aに対する欲求を持つユーザー全体に対して訴求できる情報分類のタイトル（＝ラベル）を用意するべきでしょう。
そういう意味で、Webサイトのトップページに「〜の方は」という、ニーズや欲求をベースとしないデモグラフィック分類をそのまま提示しているところ（例：SOHO事業者の方はこちら）を見ると、何だかなあと思ってしまいます。この辺りの基準選定については、現場レベルで理解が進んでいても、実際の決定権を持っているレベルではなかなか理解してもらえないケースが多いのではないかと想像していますが、早く状況が好転することを期待したいものです。
ところで朝日新聞の新土曜版の記事、「マニュアル不要」をうたってWebブラウザの「お気に入り」整理方法を載せていますが、その記事自体がマニュアルであるという自家撞着はいかにして解決なさるおつもりか。マニュアル批判は毎度のことではありますが、それにしても呆れて物も言えませんがな。
たまたま同じような問題を続けて見る機会があったせいで気付いたのですが、どうも条件分岐をうまく扱えていない例が増えているようです。例えば、操作手順が1〜4まであって、途中でA、B、Cの条件で分岐して、それぞれの条件の中でさらに複数の手順やらご注意やらがあって、そのあとに大元の手順の5〜に戻って . . . みたいなものですね。
もちろん条件分岐の数や、それぞれの条件の内容の分量にもよるのですが、条件ごとに必要な説明や手順がそれなりの長さになったりしてしまうのは、かなり問題があります。酷いものになると、大元の操作中の条件分岐の説明だけで、数ページを費やすものもある始末です。つまり先ほどの例でいくと、手順4のあとに条件分岐の説明が数ページに渡ってだらだら続いて、そのあとにようやく手順5が出てくるという訳です。これでは、ユーザーは自分がいま何をしているのか？操作のどの部分にいるのか？を操作中に把握することが困難になってしまいます。操作目的よりも操作そのものを意識せざるを得ない状況が続くことは、決して好ましいこととはいえないでしょう。
条件分岐による説明が増えるのであれば、ユーザーが操作目的とするであろう条件分岐を見出し化するなどして、見出し（条件＝操作目的）単位で情報を分割する必要が出てきます。あらかじめ見出し単位で分割しておくことで、操作説明が始まってからの混乱を予防できますし、構成をあらかじめ見渡せることで、必要な情報に最初から直接到達できる機会が増えることにもなります。製品の機能が増大するに従って条件分岐は増える一方なのですから、マニュアル制作者はこのように情報を適切に構造化する訓練を積まなければなりません。その場しのぎの条件分岐を積み重ねることは、ユーザーを条件分岐というアリ地獄に突き落としているだけということを自覚する必要があるでしょう。
もちろん各種の条件分岐による適切な構造化ということは、マニュアル制作だけの問題ではありません。特にこの種の問題の帰結である「ユーザーは自分がいま何をしているのか？操作のどの部分にいるのか？を操作中に把握することが困難になる」ということは、そのままWebサイト構築の世界でも通用する事例になりますよね。
ラプラス取説研究所のWebサイトのこのコーナーにタイトルがつきました。本日より「情報大工（インフォメーション・アーキテクト）のひとりごと」となります。今後ともよろしくお願いいたします。
インフォーメーション・アーキテクトという名称の由来ですが、当研究所はマニュアル作成だけを行うわけではありません。最終的には誰にどういった情報をどのように提供するのかをデザインするようになりたいと、日々考えています。現状の業務であるマニュアル作成やインターフェース研究といった操作情報のデザインも、あくまでその一環です。
現在のマニュアル作成業界には、情報をデザインするという視点が欠落しているとまではいかないものの、この視点をあまり重視していないように思われます。どちらかというと、実際のライティングやビジュアルの作成といった、あまりに目先の対象（オブジェクト）にとらわれる傾向があるようです。確かに個々のオブジェクトは重要でしょうしかし、マニュアルがソフトウェアのインターフェースと統合されたり、ハイパーリンクを特徴とする電子マニュアルが主体となってくるこの時代に一番大事なのは、情報の基本的な構造や構成をどうデザインするか、ということであると当研究所は考えます。
そこで当研究所としては、自らの職種をテクニカルライターやデザイナーといった個々のオブジェクトの専門家を意味する名称ではなく、情報を自らの哲学によって構築する者すなわちインフォメーション・アーキテクト、という名称で定義したいと思います。インフォーメーション・アーキテクトとは、そのまま読めば情報建築家ということになりますが、日本語としてはあまりしっくりきませんね。そこで、語感的に妙にしっくりくる情報大工という言葉を採用しました。
情報大工のひとりごと