ユーザビリティとチームワークに関する著書を持つコンサルタントのLarry Constantine氏 は最近、エクスペリエンスのデザインとアジャイル開発の“異宗婚“についての記事をふたつ書いた。最初の記事はここで、ふたつ目の記事はここでそれぞれ読める。
氏はUXとアジャイルのそれぞれのコミュニティがそれぞれの実践の熱烈に支持していること、そしてこのふたつの熱烈な支持の結婚がどのようにして困難と緊張を孕む悲惨なものになりうるかについて議論している。 氏が言うには、
このふたつが出会うとき、エクスペリエンスのデザインがアジャイル開発と結婚するとき、その結果は両者にとって信仰の危機になり得ます。
氏はふたつのアジャイルの方法について分析する。XPは“オンサイト顧客”に着目するが、これは実際のユーザではないかもしれない。“顧客はほとんどの場合、ユーザと同じではありません。そして顧客のロールはユーザビリティよりも機能に注目します。” 氏は続けて、
ユーザを軽視すると、アジャイルの手法はほとんどの他のソフトウエア開発の手法と似ます。これらの手法はユーザやユーザインターフェイス、ユーザビリティ扱ってきた長い歴史がありますが、良くても補助的な扱いに過ぎず、悪ければ全く扱いません。私自身はこの点についてやましい気持ちがあります。決して少なくないユーザを今や古くなった構造化設計の技法の中から閉め出したままにしてしまったのです。このことについては私は悔やみました。そして、Lucy Lockwood氏とともにユーザ中心デザインという名で知られる技法を開発することで罪を償いました。
氏はアジャイルとUXのコミュニティから来ている専門家がふたつの視点を同時にもたらしていることについて話す。
このふたつの世界の間の狭い通路の両側と関わっている専門家—Jeff Patton氏、Scott Ambler氏、Ron Jeffries氏、Thomas Memmel氏、Don Norman氏、Jakob Nielsen氏、そして他の多くの専門家—は仲介者として熱心に働き、エクスペリエンスのデザイナとアジャイル開発者の間を積極的に取り持ったりや関係を改善したりしました。この仕事はとても長期に渡っています。私は世紀が変わる頃からユーザインタラクション設計とアジャイルの手法について書いてきました(今は2000年紀の2番目の10年でいいのでしょうか)。また、Jeff Patton氏のアジャイルユーザビリティフォーラム(アジャイルユーザビリティのYahooグループ)は2004年に始まります。
氏は、UXとアジャイルの支持者の間で公に行われた議論や論争について、そして、これらの議論がいかに一方的であったかについて話を続ける。
この対話の興味深い側面のひとつは、ほとんどがUXのデザイナがアジャイルの手法やスケジュールに従うことについての発言だということです。開発者がデザイナの計画や実践に合わせるということについて書かれたり話されたりすることはほとんどありません。短いスタンドアップミーティング、テスト駆動開発、突然現れる要求、フロント側からの分析や設計の回避、再設計を伴う迅速で漸進的な開発、ユーザストーリーを持つ顧客の役割—これらのアジャイルの実践や道具立ては自明で既に決まったものと仮定される傾向にありますが、一方でUX設計の実践や作業方法は、導入された特定のアジャイルの手法に適合するように大幅に変更されます。
UX設計とアジャイルの間には本質的な非互換性が多数あります。アジャイルの手法は短い漸進的な開発サイクルの中で迅速で反復的に改善を行います。肝心なのは実行可能なコードを生み出し、各反復で素早く新しい機能を追加することです。BDUF(Big Design Up-Front、事前に大規模な設計を行うこと)はどうしても避けなければならない呪いです。このような開発をするための最も重要なひとつの条件は、テストファースト開発の手法に具体化されています。それは、完成に向けて漸進的にコードを拡張し、正しい結果を生み出すために正確に作業することです。しかし、ユーザビリティの結果やエンドユーザがこの結果に触れる方法についてはこの手法はなにも言及しません。テストファースト開発はユーザテストについてはなにも扱いません。扱うべきか、扱えるかどうかについては議論の余地があります。一方、ユーザエクスペリエンスデザインは初期段階に力を入れる作業になりがちです。たいていの場合、実地研究とユーザの操作の観察、ユーザの要求の分析、ユーザのモデリング、プロトタイピング、表現とインタラクションの設計などのためにかなり長い下準備を行います。ユーザのテストはかなり時間と労働力が必要な活動になることが多く、プロトタイピングと一緒に作業する場合もあります。しかし、この作業はほとんどの場合、ベータバージョンやその後のバージョンが利用できるようなる、最も忙しいプロジェクトの後半に行います。一般的にUXのデザインはプロトタイピング以上のものができる前にかなり細かい部分まで完成されると思われています。というのは、ユーザエクスペリエンスは微妙な細部とそれらの正確な繋がりとともに全体の構成や組織によって整形されるからです。
ふたつ目の記事ではアジャイルとUXの関係がうまくいくようにするために必要な4つの要素を紹介するガイドラインを提供する。
- 尊敬
- 平等
- 知識
- 独立
尊敬
私たちはプロフェッショナルです。しかし、開発者はUXのデザイナを、頭が混乱した、感情的でソフトサイエンスに基づく印象や根拠のない意見に基づいて作業をすると見なします。また、正直に言うと、デザイナも開発者を視野が狭く、コードにくっついた社会的に不適格な技術オタクと見なしています。プログラマもデザイナも、もっと上手に互いの専門技術を認め、尊重することを学ばなければなりません。両方のコミュニティのメンバはひとつのチームで働いているという姿勢を取り、互いの専門性や知識に敬意を払う必要がある。開発者はソフトウエア製品の最良の作り方を理解し、UXの専門家は人間とシステムやソフトウエアの相互作用について理解する。議論の俎上に乗った技術について互いに認め合い、尊敬し合うことで顧客を喜ばせる製品が生み出されるだろう。
平等
デザイナと開発者は開発過程では平等であるべきです。この点について、個人的には次のように考えるようになりました。すなわち、ほとんどの場合、最良の成功を納めるには、UXの設計が開発プロセスを駆動するべきであり、UXの課題は実装上の課題より重要な場合がほとんどだ、ということです。開発者の立場や意見とデザイナの開発者の意見や立場があるとき、ほとんどの場合は最良のデザインになる方向に進んだ方がより結果になります。しかし実際には、実現可能な折衷案は、開発者とその関心事とデザイナとその関心事を等しく重要だと考えることです。チームメンバ間の意見や視点の違いが解決できない場合は、裁定者が必要だ。裁定者は顧客と話し、開発中の製品のいくつかの側面について最終的な結論を下す役割を果たす。スクラムではこの役割はプロダクトオーナとして知られ、しっかりと定義されている。プロダクトオーナは製品に対して長期にわたる関心を持ち、組織の文脈の中で製品についての戦略的な方針と技術的な方針を示す。
知識
互いが平等で、尊敬し合えるようにする最も効率的な方法のひとつは知識を利用することだ。
氏はUXの開発者がソフトウエア開発の手法と原則を理解し、ソフトウエア開発者がユーザビリティデザインの原則と主要な側面についての知識を得ることが必要だとしている。“我々はユーザではない”ということを念頭に置き、本当の顧客のインタラクションを理解することで製品は大幅に改善されるだろう。
互いの技術を広めることが必要あるもうひとつの理由は、画面やインタラクションを通じたデザインのほとんどが最も詳細な部分まで網羅していないし、網羅することができず、画面やインタラクションの課題を予期するのに常に失敗するからです。この場合、実際にはプログラマが多くのユーザインターフェイス上の決定を急いで行います。予期しないエラーのためのメッセージを表示するためにあるコンポーネントを配置するかどうかから、グリッドのヘッダの表示はソートができるような表示にするべきかどうかまでプログラマが決めます。したがって、インタラクションデザインの基礎を知ることはデザイナとのチームワークをより強化し、より良い協力体制を作り出すことに貢献するだけでなく、アジャイルの手法を浸透させる、バランスのとれた柔軟な技術という価値観とも調和します。独立良い結婚はどんなものでも、互いの考えや活動が独立して行えることを考慮しますが、これはユーザエクスペリエンスのデザイナの仕事とソフトウエア開発者の仕事がうまく噛み合ない問題が生まれる可能性があります。デザイナと開発者の世界以外では、すぐに生産的な活動に着手したいという衝動は理解できるものです。デザイナは最初のミーティングで画面のレイアウトや製品のデザインをスケッチし始めます。プログラマはキーボードに手を置いたらすぐにコードを書き始めます。そしてマネジメントが最初から目に見える成果を要求することで事態が悪化します。氏はUXのデザインと開発を分離することについて議論する。氏の考えは“一歩進んだスプリント”モードを使うことだ。つまり、UXのデザインが開発よりも少し進んで作業を行い、その結果をジャストインタイムで開発側に提供する。
また、氏はシステムの機能やコンテンツを3つのグループに分けることによっていわゆる事前のデザインを引き受ける必要があると言う。インターフェイス: この部分はユーザエクスペリエンスに対して相当な影響を直接与えます。インターフェイスの部品はアップフロントで設計し、画面のレイアウトや情報の表示、メニューの構成、ナビゲーションの設計などのプレゼンテーションレイヤの部品も設計する必要があります。内部: システムの内部はインタラクションのデザインと独立していて、ユーザエクスペリエンスへの影響はほとんどありません。これらの部分はUXのデザインの結果を待たずに幅広く作業を進められます。例えば、データベースの構築や実装、計算に関する課題、通信プロトコルなどです。相互依存: インターフェイスと内部の設計を合わせるのに必要な部分です。すなわちその時点では、重なり合う部分がどこに属するのかについての知識が不足している部分です。氏曰く、もちろん、インターフェイスと内部と相互依存の3つを本当にきれいに分けるのは難しいです。しかし、私の経験ではこの区分けをすることで、ユーザインタラクションの設計を伴うソフトウエア開発において相当量の平行作業を実現できます。そして、この3つの分割が不完全であっても、リスクや後の変更に対する制限を管理できるくらい最小限に押さえることもできます。氏は開発者とUXのデザイナに対して、幸せで繁栄している状態で互いに密に作業することを呼びかけ、記事を締めくくっている。
もうひとりの発言者であるAustin Govella氏はUXのチームのメンバ宛に同じような助言をしている。“よりアジャイルに作業するための6つの方法とユーザエクスペリエンスと情報構造をアジャイル開発チームと統合するためのより良い方法”
- UXと開発の同期 – 開発よりもUXがスプリントひとつ分だけ進んでいる状態にします。
- モデリングとデザインの分離 – デザインに必要な視点や観点を理解するにはこの抽象的な考えが必要です。抽象的なモデリングが事前に済み、モデルについてチーム全体が一貫した理解をしているのであれば、デザインは素早くできます。
- デザインに関する教養 – チームのメンバは全員、UXデザインの原則と基本を理解する必要があります。
- 協力的なデザイン – UXデザインのすべての側面についてチーム全体で協力して作業するべきです。
- 厳密さを減じる – 厳密なデザイン文書を作成するために時間を費やすより、ワイヤフレームとシンプルなツールを利用する。
- 時間を記録する - イテレーションの中でUXについての作業にどのくらいの時間が必要かをチームの他のメンバに周知しておくことです。そして他のメンバがUXについての作業を引き受けるときにはしっかりとしたコミュニケーションをします。
ユーザエクスペリエンスのデザインとアジャイル開発の効果的で生産的な協力体制を作るために、あなたならどんな助言ができるだろうか。
アジャイル開発とユーザビリティについてのInfoQの他の記事はこことここで見つかる。