この週末、8年越しにある人に初めて会った。このダイアリーを始めるきっかけになった人だ。私はidを一度捨てたから、もうその記録はないけど。会うきっかけは、まぁ思い立ったということなんだけど、「必要な縁は、いつかきっと繋がる」が私の行動原則なのです。話してみて、その人は「捨てない」人なんだと感じた。その人は捨てられないとネガティブに捉えてる気がするけど、そうじゃなくて、捨てないという強めの意思があるんだな、と思った。開発やデザインを勉強したり仕事してると、無自覚にどう捨てるかを議論したりしてるんじゃないか。それはまた別の人に言われてた訳だけど、そう、効率性の悪魔に囁かれたような。他人の痛みに自覚的であること。瞬間的ではなくある意味累積的な痛みである「捨てる」ことに伴う慢性的な痛みに自覚的であること。自分にはできるでしょうか。きTweet2012年04月03日AgileとUXデザインに関するもやもやについて自分でも何でこんなにモヤモヤしてるか分かってないのですが、最近の流れがどうにもうまく消化できず、とりあえず言葉にしてみたいと思います。要旨としては以下を考えています。「チーム」としての働きを考えよう身の丈に合ったサイズ・コスト・スピードを考えようUXなどの言葉の話UX/UXD/UCD/HCD/おもてなし...などなど、ユーザー体験周りの言葉が少しずつ分断されていってるのも混乱の一因だと思うのです。履修証明プログラム「人間中心デザイン」を受講して、その履修修了生を中心に「現場で使えるHCD」をコンセプトとしたhcdvalueというコミュニティを立ち上げている関係上、ざっくり考えてみました。ちなみに、hcdvalue有志で翻訳したUX白書は一般公開されているので読んでもらえるといいかもしれません。(原文・サマリー資料)UXユーザー体験(経験)。人によってかなり意味がブレます。基本は「(あるシステムにユーザーが出会って)得られる体験」で、ユーザーの内面・心の動きを指している、と考えています。(UX白書でいう「現象としてのUX」に近い考えですこれは、システムの使いやすさなどシステム(モノ)の機能を示す「ユーザビリティ」は関連はあるものの、異なる話です。UI(ユーザーインタフェース)はシステムと人の境界を指す言葉だと思ってるので、ユーザビリティとも関連してUXに影響する大きな要素となりますが、UXとは異なる意味合いだと考えます。UX」で、「UX(のための/に関する)デザイン」だと思います。インダストリアルデザイン」という言葉を使っていますね。UX」「UXをデザインする」ではないということで、ユーザーの心の中をデザインする、というのはできないものだと考えます。言えるとすれば「UXのためにUI(などシステム)をデザインする」ぐらいのものかなぁと思っています。Design=ユーザー中心デザイン」という言葉通り、ユーザーを調査して分析したり、ユーザーに参加してもらって得られる知見を元にデザインしよう、というデザインプロセスのことだと思っています。Design=人間中心デザイン」は、ISO9241-210で規格化されたプロセスを持つデザインのことかと思います。いっても基本はUCDと一緒だと考えます。同義語だと説明されるケースも多いです。違いについては、歴史的にヨーロッパ系列かアメリカ系列かという説明がなされる場合もあります。ISO9241-210では「ユーザーとは、すべてのステークホルダーを含む」と大幅な定義の拡張がなされていたりします。感もありますが、ユーザー中心デザインと言うと、ユーザーのことばかりに目がいってる印象を与えてしまいますが、人間中心デザインと言えば、ユーザーだけでなく、チームメンバー、経営層、サポートメンバーなどなど、プロジェクトに関わるすべての人を考慮に入れている印象が...入りませんかそうですか...おもてなしUXまたはUXDのことを「おもてなし」という言葉で表現するひともいますが、個人的にちょっと違和感はあります。UXDの一要素であってすべてではない、といった印象です。ホスピタリティといった意味合いでのUXDが語られているのではないかなぁと思います。提供側、システム開発側からの視点であって、それすなわちUXといった意見だと合わないかなぁと思います。AgileとUXDの間の話やっと本題...たぶん以下でUXD/HCD/UCDを混ぜて書いてしまうかと思いますが、ご容赦ください...アジャイルソフトウェア開発宣言を読む限り、一件アジャイルとUXDは矛盾しないかのように思います。実際には進んできた道が違うための溝が大きく、一歩先を行くアメリカでの先駆者が色々工夫しつつ進めてきた形かと思います。宣言から考える「個人と対話」「動くソフトウェア」「顧客との協調」については、HCDプロセスでも同様のことが言われていると考えます。やってコミュニケーションをとるか、どうやって意識を合わせるか、実際にソフトウェアを作成する以前にペーパープロトタイピングで検証するか、などです。したがって、この3点においてはアジャイルとUXD/HCDは交流するととてもいいプラクティスが産まれる気がします。問題は「変化への対応」です。対する設計の評価」という4フェーズで語られ、「評価」の結果で適切なフェーズへ戻りましょう、という形です。これに従った場合、「評価」をして戻るといった形なので、どうしても最低1サイクルは回す必要が出てしまいます。その結果、変化への対応が遅れてしまうのではないか、という考えを持ちました。「小さな失敗」をするためには、何がポイントとなるのか、ということを別の機会にもうちょっと考えてみたいと思います。コストから考える現在のUCD/HCDの手法は、コストが大きいことがあると思います。いっても、単にコストを下げればいいわけではなくて、コアとなる概念は外さずにコストを小さくする必要があります。ラボで実施するユーザテストよりも手軽な機器で行うユーザテストであったり、実際にモックを作るよりもペーパープロトタイプを作成したり、そういったものがアジャイルへの布石となると考えています。ユーザテストの要がタスク設計であることや、ペーパープロトタイプの抽象度による効果の違いなど、ある程度学習しないと効果が小さくなってしまう点はあるので、ここはアジャイル側とHCD側で一緒に伸ばしていける分野かなぁと思います。「非ウォーターフォール」いわゆる「ウォーターフォールじゃないやつ」としてのアジャイルの文脈に違和感があり、あえて敵対するような言説には賛同しかねます。この辺りがとても残念で、ウォーターフォールで培ってきた歴史を全否定しているような言説をみかけます。ウォーターフォールだから悪いのではなく、そのプロジェクトに見合ったコスト・スピードではないから良くないのであって、何でも軽量であればいい、といったことではないかなーと思っています。チームで仕事するということアジャイルの文脈でもHCDの文脈でも、「チーム」ということが重要視されています。開発者であってもデザイナーであっても、これからはどう「チーム」をつくっていくか、ということがとても重要になるかと思います。HCDの2つの視点これまでのHCDは「ユーザビリティ」を改善する、「問題解決型」のアプローチが多かったと思います。そこに10年以上の蓄積があり、ユーザビリティの問題がUIの表層部分だけではないこと、もっと深い「戦略」といったいわゆる上流の部分に問題があることが分かってきたのだと理解しています。これまで問題解決型で精度を高めてきた手法や知見が、いわゆる上流工程でも適用できることが徐々に分かり、そこで「ユーザエクスペリエンス」という部分へ踏み込んでいき、「ビジョン提案型」といわれる視点へシフトしています。いった背景から、HCDの手技法自体もこれから「ビジョン提案型」にシフトしていく途中で、徐々に洗練されていくものだと思います。まとめこれまでの歴史を無視してアジャイルやHCDを考えないようにしたい。「チーム」としての働きを考えようプロジェクトの身の丈に合ったサイズ・コスト・スピードを考えよう。Report(あとで追加するかも)自分でももやもやしているので、コメント・はてブ・twitter・fbなどでご意見いただけると助かります。きTweet書いてる人ちゃちゃき。デザイン」に関わって得たもの。(1)「Amazonライブリンク」は提供を終了しました。