IA, and UX

毎年春の恒例となったIAサミットが閉幕した。
今年は10回目という節目の開催ながら、不況の影響もあり参加者は昨年の600人超から400人弱へと減少、一回り小さくなった開催だった。

今年はネットイヤーの坂本くん、コンセントの河内さんと共に渡米となり、現地で西海岸に留学しているでソニーの佐藤大輔氏夫妻と合流した。

行われたセッションの内容は、より横断的な内容が増え、またIAの将来や今後のあり方を議論するようなセッションも多く開催されていた。
これまでより、パネル形式での議論が多くなり、また数人で議論を行うようなセッションもいくつか開かれていた。

通常の(概念的な)セッションとしては、メディアの変革に伴う利用者の変容、優れたユーザー体験の提供のためのポイント、段階的なサイトリニューアルのための戦略、といったようなテーマ。
また、ファセット分類検討のケースじれや、おなじみeightshapesによる、優れた納品物のためのテンプレートといったより実践的な内容も見られた。

そして、それと同時に見られたのが、IAはどのように進化すべきか、IAコミュニティの現状の課題の分析といった「IAはどうなるのか」というテーマだった。

そこでは、ちょうど先月IA Instituteも共催して開催されたIxDA(Interaction Design Association)との棲み分け、またそういった観点で話が分断されることによるIAコミュニティへの求心力の低下といったものが議論されていた。
それを象徴したのがadaptive pathを率いるJesse James Garrett氏のクロージングプレナリーだった。

そこでJJGは、もはや我々はインフォメーションアーキテクトを名乗るべきではない、我々はみなユーザーエクスペリエンスデザイナーなのだ、と宣言したのだった。

この宣言にその場は一瞬凍りつき、静まりかえった。
飛び交っていたtwitterのコメントにも動揺したコメントが多く見られた
http://search.twitter.com/search?q=%23ias09

JJGの演説では、我々が行っているのは、カスタマーの声を反映させた要件定義、それをクライアントと作り上げていくことであり、IAだのIxDだのと狭い範囲の(little IAの)議論を行うべきではない、という趣旨であった。
(スピーチの内容はIA Summit09のサイトよりポッドキャストで公開される予定)

そもそも米国で広まっているIAと名が付いている職種はInformation Architect(インフォメーションアーキテクト)と、Information Architecture(情報アーキテクチャ担当)との二通りある。
その内容としては、コンテンツ分類をしてワイヤーフレームを書く、というものから、プロジェクトの上流から人間中心設計的なプロセスを導入し、要件を定義していくといったコンサルタント的なものまで幅広い。

こういった背景から、より上流に関わる人材の呼称として、インフォメーションアーキテクトからUXデザイナーが適切だ、という指摘は理解できる。

そして実はJJGのこの主張は2002年に彼がia/reconというエッセイを書いたときからまるで変わっていない。

ia/recon
http://www.jjg.net/ia/recon/
日本語訳:IA再考
http://iainstitute.org/ja/translations/000305.html

このエッセイで彼は、組織の中で優れた情報空間(情報アーキテクチャ)を構築するために必要な作業は、コンテンツの分類やナビゲーションの設計といったいわゆる「情報アーキテクチャ」作業だけでは不足しており、その範疇外のプロジェクト自体へのコミットまで必要である矛盾を指摘している。

IA再考
(略)その結果が「小さなIA」と呼ばれる — コンテンツ構成と情報空間の構築に焦点があてられたものだ。しかしながらこの役割の定義を(領域として)実際の役割にあてはめられると、定義された「枠」によって、情報アーキテクチャの成功に本来不可欠な多くの要素が、任務の範疇外とされてしまうのではないか、という不安を生む結果となってしまう。(略)

ここでいう「情報アーキテクチャの成功に本来不可欠な多くの要素」を担当する役職としてUXデザイナーという名称が必要となるというストーリーとなる。

つまりこれまでは、

情報アーキテクチャ:問題解決のための要因
インフォメーションアーキテクト:わかりやすさの問題を解決するひと(情報アーキテクチャはその一要因)

という形容上の齟齬があった部分についての解決を、ここで言われていたインフォメーションアーキテクトという呼称をUXデザイナーとすることで解決する、ということとも言える。

このUXデザイナーが解決する問題としては、IxDも含まれる。
(本当はテクノロジーデザインや、グラフィックデザインも含まれるはずだが、その議論はまた別途とする)

同じような問題意識については、adaptive pathのChiaraのエントリが端的だ。

Why I am no longer calling myself an information architect. | adaptive path blog
http://www.adaptivepath.com/blog/2009/03/23/why-i-am-no-longer-calling-myself-an-information-architect/

このなかで彼女は、なにがIAに必要かを語るとき、IA以外のことを語っていた、と記している。

IA再考
そこでただひとつの解決策は、領域と役割の定義を互いから完全に切り離して考えることだ。これは一見反論理的に見えるけれども、実際うまく理にかなったやり方である。おまけに一方が他方に先んずることもない。ひとつの例として、オーケストラの指揮者は多岐に渡る創造性と管理能力を問われるが、「指揮をする」という役割ひとつをとって考えてみると、必ずしもそれは彼が抱える広義の任務を説明してはいない。

日本では、結局(幸いにも)インフォメーションアーキテクトという職種もあまり普及しておらず、またUXデザイナという名称もまだまだこれからといったところだろう(コンセントではUXアーキテクトという職種がある)。

日本では、品質担保とプロジェクトマネージメントの両方の責務を負った役職として「Webディレクター」がある。
現在、僕自身、そして日本のIAコミュニティでは、情報アーキテクチャを職能としてWebに関わるより多くの人に知ってもらうべきだと考え、活動を行っている。
JJGの今回の宣言は、日本における状況にも合ったものであると言えるだろう。

また、先日Peter Morvilleによってエントリされた、User Experience Deliverablesもこの構造を表している。

User Experience Deliverables
http://semanticstudios.com/publications/semantics/000228.php
日本語訳:ユーザーエクスペリエンスデザイン成果物リスト
http://blog.iaspectrum.net/UserExperienceDeliverables.html

JJGの1時間にわたる画面投影を伴わない演説は、今回のサミットで多く見られた危惧を一掃するものではなかったかもしれないが、セッションを統括するにはふさわしかったようにも思う。

そして、僕が肩書きを変えるかというと、やはり僕はインフォメーションアーキテクトのままでいたいと思う。

Information Architects

1.データに潜む隠れたパターンを整理し、複雑さを明快にする人
2.ユーザーが自分の知識を獲得するための道筋を見つけられるような、構造や地図を作る人
3.明快さ、理解、情報の整理に特化した、時代の要求によって生まれた21世紀の職業
Information Architects – Richard Saul Wurman
http://www.amazon.co.jp/dp/0823064557

IA, and UX」への4件のフィードバック

  1. noriyo

    > そして、僕が肩書きを変えるかというと、やはり僕はインフォメーションアーキテクトのままでいたいと思う。

    これは、私もそうなのです。理由は一言では語りきれませんが、やはり。

    なにはともあれ、貴重なフィードバックをありがとうございました!

  2. さと

    理由は一言では語りきれないのでアレですが、逆に僕はこの10年間、自分で肩書きを語るときは

     エクスペリエンスデザイナー

    です。(今の本業は同じIAでもインタラクションアーキテクトですがw)

    ユーザーだけじゃなく製品やサービスまで含めた、「経験」の設計だとおもっているので「User」は付けてません:)

  3. Atsushi 投稿作成者

    > noriyoさん,

    理由語り合いましょう 🙂

    > さとさん、

    そう、JJGの話聞きながら、まさにさとさんの肩書きを思い出してました。

    本文でもちょっと書きましたが、逆にUXって、情報アーキテクチャとIxDだけじゃないんじゃないのか?という疑問はあります(それは「インフォメーションアーキテクト」もそうだったんですが)

    > yuuさん、

    それは詳しくききたし。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です