自分でも何でこんなにモヤモヤしてるか分かってないのですが、最近の流れがどうにもうまく消化できず、とりあえず言葉にしてみたいと思います。

要旨としては以下を考えています。

• 「チーム」としての働きを考えよう
• 身の丈に合ったサイズ・コスト・スピードを考えよう

UXなどの言葉の話

UX/UXD/UCD/HCD/おもてなし…などなど、ユーザー体験周りの言葉が少しずつ分断されていってるのも混乱の一因だと思うのです。私は単なるプログラマなのですが、2010年度に産業技術大学院大学の履修証明プログラム「人間中心デザイン」を受講して、その履修修了生を中心に「現場で使えるHCD」をコンセプトとしたhcdvalueというコミュニティを立ち上げている関係上、ざっくり考えてみました。

ちなみに、hcdvalue有志で翻訳したUX白書は一般公開されているので読んでもらえるといいかもしれません。(原文・サマリー資料)

UX

ユーザー体験(経験)。人によってかなり意味がブレます。基本は「(あるシステムにユーザーが出会って)得られる体験」で、ユーザーの内面・心の動きを指している、と考えています。(UX白書でいう「現象としてのUX」に近い考えです

これは、システムの使いやすさなどシステム(モノ)の機能を示す「ユーザビリティ」は関連はあるものの、異なる話です。また、UI(ユーザーインタフェース)はシステムと人の境界を指す言葉だと思ってるので、ユーザビリティとも関連してUXに影響する大きな要素となりますが、UXとは異なる意味合いだと考えます。

こういった背景から、「UI/UX」「UI=UX」といった文字列を見るとかなりモヤモヤします…

UXD

「Design for UX」で、「UX(のための/に関する)デザイン」だと思います。千葉工大の安藤先生ですと、「計画」「量産」「インダストリアルデザイン」という言葉を使っていますね。(安藤先生の講演資料)

重要なのは「Design UX」「UXをデザインする」ではないということで、ユーザーの心の中をデザインする、というのはできないものだと考えます。ですので、言えるとすれば「UXのためにUI(などシステム)をデザインする」ぐらいのものかなぁと思っています。

UCD

「User Centered Design=ユーザー中心デザイン」という言葉通り、ユーザーを調査して分析したり、ユーザーに参加してもらって得られる知見を元にデザインしよう、というデザインプロセスのことだと思っています。

HCD

「Human Centered Design=人間中心デザイン」は、ISO9241-210で規格化されたプロセスを持つデザインのことかと思います。といっても基本はUCDと一緒だと考えます。同義語だと説明されるケースも多いです。

違いについては、歴史的にヨーロッパ系列かアメリカ系列かという説明がなされる場合もあります。

また、ISO9241-210では「ユーザーとは、すべてのステークホルダーを含む」と大幅な定義の拡張がなされていたりします。ちょっと無理矢理感もありますが、ユーザー中心デザインと言うと、ユーザーのことばかりに目がいってる印象を与えてしまいますが、人間中心デザインと言えば、ユーザーだけでなく、チームメンバー、経営層、サポートメンバーなどなど、プロジェクトに関わるすべての人を考慮に入れている印象が…入りませんかそうですか…

おもてなし

UXまたはUXDのことを「おもてなし」という言葉で表現するひともいますが、個人的にちょっと違和感はあります。UXDの一要素であってすべてではない、といった印象です。

おそらく、ホスピタリティといった意味合いでのUXDが語られているのではないかなぁと思います。あくまで提供側、システム開発側からの視点であって、それすなわちUXといった意見だと合わないかなぁと思います。

AgileとUXDの間の話

やっと本題…

たぶん以下でUXD/HCD/UCDを混ぜて書いてしまうかと思いますが、ご容赦ください…

アジャイルソフトウェア開発宣言を読む限り、一件アジャイルとUXDは矛盾しないかのように思います。が、実際には進んできた道が違うための溝が大きく、一歩先を行くアメリカでの先駆者が色々工夫しつつ進めてきた形かと思います。

宣言から考える

「個人と対話」「動くソフトウェア」「顧客との協調」については、HCDプロセスでも同様のことが言われていると考えます。例えば、どうやってコミュニケーションをとるか、どうやって意識を合わせるか、実際にソフトウェアを作成する以前にペーパープロトタイピングで検証するか、などです。したがって、この3点においてはアジャイルとUXD/HCDは交流するととてもいいプラクティスが産まれる気がします。

問題は「変化への対応」です。HCDプロセスでは「利用状況の把握と明示」→「ユーザーと組織の要求事項の明示」→「設計による解決策の作成」→「要求事項に対する設計の評価」という4フェーズで語られ、「評価」の結果で適切なフェーズへ戻りましょう、という形です。これに従った場合、「評価」をして戻るといった形なので、どうしても最低1サイクルは回す必要が出てしまいます。その結果、変化への対応が遅れてしまうのではないか、という考えを持ちました。

「小さな失敗」をするためには、何がポイントとなるのか、ということを別の機会にもうちょっと考えてみたいと思います。

コストから考える

現在のUCD/HCDの手法は、コストが大きいことがあると思います。といっても、単にコストを下げればいいわけではなくて、コアとなる概念は外さずにコストを小さくする必要があります。

なので、ラボで実施するユーザテストよりも手軽な機器で行うユーザテストであったり、実際にモックを作るよりもペーパープロトタイプを作成したり、そういったものがアジャイルへの布石となると考えています。ただ、ユーザテストの要がタスク設計であることや、ペーパープロトタイプの抽象度による効果の違いなど、ある程度学習しないと効果が小さくなってしまう点はあるので、ここはアジャイル側とHCD側で一緒に伸ばしていける分野かなぁと思います。

「非ウォーターフォール」

いわゆる「ウォーターフォールじゃないやつ」としてのアジャイルの文脈に違和感があり、あえて敵対するような言説には賛同しかねます。この辺りがとても残念で、ウォーターフォールで培ってきた歴史を全否定しているような言説をみかけます。ウォーターフォールだから悪いのではなく、そのプロジェクトに見合ったコスト・スピードではないから良くないのであって、何でも軽量であればいい、といったことではないかなーと思っています。

チームで仕事するということ

アジャイルの文脈でもHCDの文脈でも、「チーム」ということが重要視されています。なので、開発者であってもデザイナーであっても、これからはどう「チーム」をつくっていくか、ということがとても重要になるかと思います。

HCDの2つの視点

これまでのHCDは「ユーザビリティ」を改善する、「問題解決型」のアプローチが多かったと思います。そこに10年以上の蓄積があり、ユーザビリティの問題がUIの表層部分だけではないこと、もっと深い「戦略」といったいわゆる上流の部分に問題があることが分かってきたのだと理解しています。そして、これまで問題解決型で精度を高めてきた手法や知見が、いわゆる上流工程でも適用できることが徐々に分かり、そこで「ユーザエクスペリエンス」という部分へ踏み込んでいき、「ビジョン提案型」といわれる視点へシフトしています。

といった背景から、HCDの手技法自体もこれから「ビジョン提案型」にシフトしていく途中で、徐々に洗練されていくものだと思います。

まとめ

• これまでの歴史を無視してアジャイルやHCDを考えないようにしたい。
• 「チーム」としての働きを考えよう
• プロジェクトの身の丈に合ったサイズ・コスト・スピードを考えよう。

参考リンク

ユーザー体験とユーザー観察

AgileUX NYC 2012 Redux in Tokyoに参加してきた #AgileUXNYC_ja - Shinya’s Daily Report

(あとで追加するかも)

自分でももやもやしているので、コメント・はてブ・twitter・fbなどでご意見いただけると助かります。

久しぶりに本気でブログを書いてみようと思います。

テーマは「DLNA」についてです。

最近、ほぼ全メーカーのテレビがDLNAに対応したり、ドコモからDLNAの端末が出たり、一般への認知度が高まっているのではないかと思います。しかし、どうも「DLNA」という規格について誤解だったり、夢や妄想が広がっている気がしているので、判っている範囲で書いてみようと思います。

(そもそも公式サイトが英語メインだったり、一般向けのサイトがリンク切れだったりして、ちゃんと情報出してないのが原因だったりします(苦笑 )

DLNAって何ができるの？

「家の中」の機器間で、カンタンに画像や音楽、動画を視聴できます。

「機器」というと、大きく分けて「サーバー」と「クライアント」があります。

サーバーとクライアント

まず、画像や音楽、動画(以下、コンテンツ)の送受信で考えると、「コンテンツを送る側」と「コンテンツを受ける側」が存在します。コンテンツの送り手を「サーバー」、コンテンツの受け手を「クライアント」、と呼ぶことが多いです。蛇足ですが、最近ではクライアントの一種で「レシーバー」というものも登場しています。

もう一つ、「コンテンツ一覧を見て、どのコンテンツを再生するかを決定する」機能を持った機器があります。これは「コントローラー」と呼ばれます。一般的には、「コントローラー+レシーバー」をひとまとめで「クライアント」と呼ばれています。（ちょっと語弊がありますが、省略！）

大雑把ですが、こんな感じです。

機能はどうなっているの？

あまり正確ではないのを承知で書けば、

以下の2つの機能を合わせて「DLNA」として機能します。

• 「機器」が繋がる機能
• 「コンテンツ」が繋がる機能

「機器」が繋がる機能

繋がるためのは、まずお互いが「どこ」にいて「何」ができるのかを知る必要があります。

機器同士が勝手に繋がるために、概ね以下のような手順を踏みます。

1. 場所(ネットワーク上の場所なので、IPアドレスです)を確定させる
2. その場所の周りに、他に誰か居ないか探すor周りに自分を知らせる
3. 自身がどんな機器かをやりとりする。

(例：＼俺はサーバーだぜ！／)

(例：＼俺はレシーバーだぜ！／)

この辺りの仕組みは、「UPnP」という規格に基づいています。DLNAという規格の中身は、企業だったり、お金を払ったりしないと見れないのですが、UPnPの仕様書に関しては、一般でも手に入れることができます。興味があれば、こちらなどでどうぞ。

「コンテンツ」が繋がる機能

上記の動作をすると、各機器の役割が判明します。

上記の動作中に「コンテンツが繋がる」仕組みとして、自分がどんなコンテンツが送れるか、またはどんなコンテンツを受けることができるかをやりとりします。(ここがDLNAのキモだったりします。。。)

（例：サーバー：＼俺はMP3とMPEG2が配信できるぜ！／)

（例：レシーバー：＼俺はMP3とJPEGが再生できるぜ！／)

その後、ユーザー(人間)が操作して、以下の手順を踏みます。

1. 「コンテンツの一覧」を見る
2. 「コンテンツ」を選ぶ

コンテンツの一覧から選択する動作については、フォルダ・ディレクトリからあるファイルを選択する、という概念に非常に近いです。

とりあえず、全コンテンツを表示する、というのも手ですが、上記のキモとなるやりとりをすれば、自分と相手がどんなコンテンツを配信・再生できるかがわかるので、再生できるコンテンツのみ表示できる、といったものも可能です。

何かDLNAって繋がらないよね？

繋がらない、の段階によって、色々考えられます。

それについては、後日書いてみたいと思います。

ではでは。