自分でも何でこんなにモヤモヤしてるか分かってないのですが、最近の流れがどうにもうまく消化できず、とりあえず言葉にしてみたいと思います。
要旨としては以下を考えています。
- 「チーム」としての働きを考えよう
- 身の丈に合ったサイズ・コスト・スピードを考えよう
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などでご意見いただけると助かります。
コメント