2013が開催された。Bryanが主催を務めている。初回となる今回は、約200人の参加者が集まり、2日間に渡るシングルトラックのセッションと、その前日に午前と午後に分けられたいくつかのワークショップとで会は構成された。以下、会のトピック的なセッションを紹介しながら、問題意識と今後の展望を述べる。HCDコメントを残す昨日はHCD-Netの賛助会員向けイベント「サービスとHCD」。充実した、示唆深い内容であったので内容を記しておきます。いいが、賛助会員向けイベントってタイトルはださいですね。このイベントは、毎年HCD-Netが開催している、賛助会員を優先的にご招待するイベントでHCD-Net会員社もしくは、理事等からの推薦により、実際の企業の現場のお話しをうかがう、というある意味HCD-Netのイベントのなかで最も実際的に意義深いイベント。通常、いろいろな方とお話しをしていても、みなさん事例を知りたいとか、他社の動向を知りたいというお話しが多く、そこに応える会なのですが、なにぶんきちんと広報できていないため、実はちゃんとそのメッセージが届いていないと思っています(イベント名もそうです)。今回は、これまでご要望も多かった、Webサービス系の企業にお集まりいただきました。mixi、楽天証券、Naver(LINE)、クウジットと、それぞれ知名度も高い、これからのサービス企業。実際にお話を伺うと、それぞれのお話しごとに学ぶべきことが多くありました。mixiの馬場さんによる、mixi内でのHCD活動の推進について。お話自体は、mixi内でのHCDプロセスの実施例、およびその反響の声。馬場さんを始めとする社内のスタッフがHCDプロセスをどのように普及させていったかというストーリーとして大変参考になりました。・理論(社内研修)+実践(実務の実施)の両輪で理解が深まる、体系的な理解を助ける施策と実務と結びつけるための施策と、両方が必要という点が今後の企業内でのHCD活動の普及のポイントとなるという指摘が響きました。次は楽天証券の水田さんによる、これまた奥深い事例のお話し。単なる(と言っては失礼ですが)楽天証券サイトのUI改善のお話しと思わせて、実はご本人の前職などの経験をふまえて、「一般投資家にとって投資とはなんなのか、証券会社の提供すべき価値はなんなのか」を考察する、というサービスデザインの文脈のお話しでした。・オンライン投資=自分で探索、理解からしなければならないと箇条書きにしてしまうと単純化されてしまいますが、この裏側に潜む期待価値はオンライン証券のみならず、今後のWebサービス全体に適用できる枠組みと感じました。・大きな改修はユーザーの負担となり、クレームも増える・ユーザーが新しいUIに習熟するまで半年はかかる・移行措置として短期的なユーザビリティを下げたとしても、UIの共存を実施という、現在のWebサービス事業者が抱える共通の課題に対してのひとつの示唆を示していただきました。Summit等でAmazonのUI移行のステップのケーススタディなどを聞いていて、うちのコンセントでも企業サイトリニューアルの際に、基本的にはフルリニューアルせずにマイナー改修を繰り返す、というプロジェクト方針をとっていますが、「共存」というのはサービス事業としてのひとつのリアリティと感じました。3人目はいまをときめくLINEについて、Naverの本田さん。Naver(NHN)は以前からUTルームの充実など、UX改善には力を入れられていますが、今回のお話しでは、まず、オンラインサービス開発の考え方とHCDプロセスとの齟齬のお話しから始まりました。具体的には以下の2点が既存のHCDプロセスが合わないところ:・Deploy(リリース)前後の区別が曖昧LINEはマイナー改修(平均4週に一度のリリース)とリニューアルもわかれている・日常的な利用状況把握と深い利用状況把握を区別したいリニューアルのためには深い調査が別途走るこのため、Naverでは、HCDプロセスを独自にカスタマイズした、開発ライフサイクルプロセスを定義しています。コンセントは基本的にはエージェンシーなので、プロジェクトにかかわる際には上記で言うところのリニューアルの大型案件に関わることが多いのですが、HCDの本質は実はマイナー改修の室にあるということもあり、自分達のプロジェクトプランをちょっと考え直してみようかと思っています。最後はクウジットの末吉さん。前の三方がサービス事業者なのに対して、技術ソリューション提供の会社ですが、QRや位置情報など、これからのUXを支える技術を提供している会社ですので、特にそのユーザーへの提供のさせかたに興味を持ちました。クウジットでは、いつも「技術をそのまま提供したのではユーザーに理解されない/利用のインセンティブを感じてもらえない」という課題を持っていらっしゃるとのことで、そのためユーザーの目線に合わせたメタファーやベネフィット提示をどうするか、に尽力されているとのこと。この「技術のユーザー目線への変換」がHCDアプローチの中でのビジョニングやデザインのフェーズで求められることであり、ここを越えていない解決案しか出せないと単なるユーザビリティエンジニアリングの域にとどまってしまいます。その意味でこれも新しいHCD/UXDのフレームワークを意識させるようなセッションでした。明日は奥沢UXクリスマス会というものがあるので、その場でUXプリンスにも意見を聞いてみようと思います。Atsushiユーザーエクスペリエンスデザイン2件の返信ユーザーエクスペリエンスデザインという言葉も多く聞かれるようになってきた。ユーザーインターフェイスやらユーザビリティと「ユーザー」が似ているので、議論になったりもしているが、根本的にユーザーエクスペリエンスはブランドといっしょで、結果的に得られるものであり、個別の施策ひとつひとつは構成要素ではあるけれどだからといってそれがユーザーエクスペリエンスかというと、あるケースではそうかもしれないが、普遍的観点で言えばちがうことになる。それは、ブランドが品質によって支えられていることもあれば、接客によって支えられていることもあれば、テレビCMに出てくるタレントによって支えられていることもあれば、あるいはそれらすべての組み合わせであることもあるようなもので、仕掛け側が意図しているものと、実際に顧客が感じている部分とがずれていることも含めてブランドとユーザーエクスペリエンスデザインは近いものだ。ユーザーエクスペリエンスデザインの難しいところは、それが横断的なものであることに起因している。製品自体だけで実現できるものではなく、プロモーションやアフターサービス、説明書など、なにと相関しているかは結果論でしかわからない。Webデザインの界隈から流行りだしたのは、それがWebチャネルで完結するサービスデザインの分野において実現が容易だったからであって、決して次世代Webデザインがユーザーエクスペリエンスデザイナなわけではない。ユーザーエクスペリエンスを考える際には、少なくとも企業内ではすべての部署を横断した、タブーなき議論が必要となる。知られているようで知られていないユーザーエクスペリエンスデザインの起源、ドン・ノーマンの設立したAppleのユーザーエクスペリエンスラボはまさにこの横断的組織の走りであった。企業がある程度の規模になると、どうしても縦割りになることは規模の経済を実現するためには当然の帰結であるが、その横断的な問題解決のベクトルが「顧客の利用体験」に向いていたというのがユーザーエクスペリエンスデザインの本質である。この意味でも、ブランディングと近いことがわかると思う。ユーザーインターフェイスで解決しようが、プロモーションで解決しようが、その手段自体は結果でしかない。ポイントは問題を解決しようと考えている人が、その問題解決のフレームをできる限り大きくとることができるかどうかであって、その観点が持てるかどうかがデザイナーとしての閾値となる。ユーザーエクスペリエンスデザインにおいて、問題・解決策の発見と、その実現とは、まったく別の問題といっていいほど異なっている。問題の発見は、どちらかというと観点の問題であり、センスの問題ではないが、その体験にどれだけ興味があるかどうかに依存しているという意味で、身を置いてみないとまず発見はできない。問題を認識できた時点で、その解決はわりと自明であり、あとはどうやってやるか、他の解決策との共存をどうするか、というテクニカルな問題に焦点は移る。僕は車がわりと好きな方で、もちろん運転も好きだが、車内の情報システムも興味範囲であるので、昔から自分への投資と言い訳をしてさまざまなナビを試したり、実験を繰り返してきた。いった仕事をしていることもあり、ある程度テクノロジーリテラシーもあるので、実はどういったインターフェイスでもそこそこ使いこなして、問題がない状態にしてしまう。一般に多少使いにくいカーナビであっても、極論を言えばGPSで現在地がわかる機能に問題がなければあとはこちらの工夫次第でなんとかなってしまう。その際には、そのシステムが持っている処理体系の構造をはやいところ把握してしまい、機器の持っているクセをこちらが吸収する、というテクニックが必要となるが、まあこれはいわゆるITリテラシーがそこそこある、と言われている人が持っている技術といえる。このように、そこそこ使いこなせてしまうと、逆に言えば問題がそこにはないので、問題の発見ができないことになる。禅問答のような話であるが、そういう理由で世の多くの「使いにくい」やら「ひどい体験」は放置され、そもそも問題と認識されていないため、企業側からクレームと認識されてしまっている。これは相対的な問題であり、まあそもそもデザインというのは問題解決なので相対的でしかあり得ないのだが、世の期待値に対して、2歩先ではなく、0.5歩先を行った解決策が一番効くゆえんでもある。僕は昔から自分エスノグラフィーと称してやったことのない体験の感想や、新しい観点を持てた瞬間を記録するようにしている。これは「初めて知る」という貴重な瞬間は二度とやってこないので、Evernoteだろうとメモ帳だろうとなんでもよいので残しておくとかなり役に立つ。余談になるが、6年くらいつけていた自動車内のメモはカーナビのアーキテクチャデザインを行う際にものすごく役に立った。最近やり始めたことに、「ユーザーエクスペリエンスプロトタイピング」がある。これは、自分に新しいユーザーエクスペリエンスを体験させてみて、どう思うかを自分で理解するもので、IDEOメソッドカードでも確か似たようなものがあった。直近で効果を実感したプロトタイピングはカーナビの目的地設定。僕の車のナビは、まあ最近の機種ではあるのだが、基本的にはスタンドアローンで、クラウド上にアカウントがあったり、PCから目的設定できたりということはできない。いったあたりは、単に企業側がその部分にコストをかけた場合の回収が見込めていないからやっていないだけの話なので、そのうち実現されるだろうと思っているので危惧していないのだが、問題は「実現されたそれらの技術をどうやって使うか」については、実現されていない技術故に試してみたり、評価したり、ましてや改善したりができないところにある。自分で「あったらいい機能」を勝手に実現して、改善を図り、来るべき時代(でそういった設計を依頼される事態)に備えておく必要がある。一般的には、カーナビの目的地設定は、車に乗車して、かちかちと設定を行う。目的地設定をして、高速を使うべきかどうか、どっちのルートが渋滞しているか、などを確認し、移動を行う事態が週に数回はある。車に乗り込む際に目的地は正確にわかっている必要があるので、スケジューラに住所まで入れておいたり、携帯に住所や電話番号を転送したり、ということをよくやっていた。これを、車を降りる際に次に乗ったときに行く目的地を設定する、というやりかたに変えてみた。これは、「車に乗った瞬間にナビは目的地を目指している」という状況をシミュレーションするためにやっていることで、自分で降りる際にちまちまと入力している行為は裏方作業なので忘れておくかなかったことにしておく。車に乗り込んで、エンジンをかけて、目的地へ向かうときはたいてい急いでいて、かつプロジェクトのメンバーといっしょだったりすると、プロジェクトの話をしたり、ぎりぎりまで議論をしたりと忙しい。僕の会社は恵比寿にあるが、目的地までのルートによって恵比寿駅側に向かおうか、ガーデンプレイス側に向かおうかと、向きがまったく逆になるので、ナビが設定されていないと、最初の角を曲がれなくなってしまう(そこまでの状況はまれだけど)。この状況の中で目的地が設定されていて、さすがにVICSの渋滞情報はエンジンをかけてから取得するからすぐには反映されないのだが(これもわりと致命的な仕様だとは思うが)、到着時間やルートが即座に出てくると大変快適であり、そして数回その状況になれてしまうと、もうそうでないときにはいらっとしてしまうまでになってしまった。これ自体は他愛ないことであり、もう実現できていることなのかもしれないが、ポイントは「その状況になれてしまった自分」がどう変わっているかを観察できるところになる。こればかりは実現されていることを知っただけではなかなか想像することが難しい。難しい故にプロトタイピングが必要なのだが、しかしながらプロトタイピングを発動しようと考えるためには、問題の存在を想像しなければならない。これはiPodが音質ではなく、CDからのリッピングという「連携」を問題の本質ととらえたこととにも言える。結局のところ、優れたユーザーエクスペリエンスは創造力の問題なのだ。問題のフレームを自分で設定し、その問題が解決できることを有意義と見なす感覚を持てること、このことがデザイナの本質であり、その観点を持ちたいが故に個別の技術の習熟をめざす必要がある。