アジャイル開発が過去20年以上に渡り、ソフトウェア開発の世界に旋風を巻き起こし続けてきたのにはきちんとした理由があります。反復的で拡張性のある開発、組織横断的なチーム、面倒な文書ではなくソフトウェアそのものへ着目する姿勢は急速に変化し続けるテクノロジーの世界で戦う私たちのニーズによく合っていたといえます。
しかしながらアジャイル開発への移行という面から見ると、多くの製品オーナー、開発チーム、そしてUXのプロたちが、過密なスケジュ－ルの中でいかにしてユーザー中心設計を組み入れるかということに頭をかきむしったまま置いてけぼりを食らっている状態です。
一見、アジャイル開発への移行は無謀なことに思えるかもしれません。一体どうすれば準備・実施し、そして最終的な報告にまで数ヶ月を要するようなユーザビリティテストを、スプリント毎に異なる製品を生み出し続けなければならない開発サイクルの中に組み入れられるのでしょうか。
信じられないかもしれませんが、顧客によるフィードバックをアジャイル開発プロセスに組み入れることは可能であるばかりでなく、アジャイル開発の哲学である増加し続ける変化と反復的な開発から自然に導かれる結果なのです。しかし、このフィードバックループを組み立てることは開発チームの構成や開発プロセス、そして成果物を少しばかり変化させる必要があります。
アジャイル開発チームはそれぞれにちょっと（場合によってはかなり）異なった仕事のやり方をしますので、自分のチームにあった開発プロセスを見つけるのには試行錯誤が必要でしょう。過去十年間で多くの組織がUXを開発プロセスに組み込んだ成功例またはその挑戦を報告しています。
例えば、ある有名なケーススタディとしてDesirée SyとLynn Millerによるもの、またAviva RosensteinによるBoxes and Arrowsの記事やJanet SixのUXmattersの記事等があり、双方ともアジャイル開発環境で働くUXのプロへのインタビューに基づいています。こうしたケーススタディやインタビューによって、興味深いトレンドや最良の実践方法が少しづつ明らかになってきています。
もしあなたがアジャイル開発チームの一員でUXに関する作業を現在のプロセスの中に加えたい、またはあなた自身がウォーターフォール開発チームの中でUXに関するプロフェッショナルとして働いており、アジャイル開発への移行を実現したいと考えているなら、これから挙げる秘訣やリソースはアジャイル開発プロセスへユーザー中心設計のプロセスを加える点において非常に有用でしょう。これらの秘訣は私が報告したUXに関する文章を元にしており、私自身がアジャイル開発チームの中で働いた経験から共感するものに基づいています。
1. 協力的で、組織横断的なチームをつくる
もとより新しい物事に興味があり、他人とうまく仕事ができ、フレキシブルな人々によるチームをつくるよう組織に働きかけましょう。このチーム内にはひとつのプロジェクトを遂行するのに必要なすべての人材を含んでいなくてはなりません。製品のオーナー、デベロッパー、アナリスト、検証チーム、UXのプロ、そしてデザイナーなどなど。
アジャイル開発はもとより非常に協調性を重んじた手法です。ですから、チームメンバーには自身の専門的見解をプロジェクトのあらゆる側面において喜んで提供してくれることが求められます。組織横断的なチームは多種多様なものを見方を提供することができ、それがより良いデザインソリューションとなるのです。可能ならば、メンバーを一箇所に集めると相互作用も期待できます。もし全員がひとつの場所に集まることが無理、あるいは経済的に負担がある場合は、離れていても質の高いリモートミーティングを実現することで同様にうまくいきます。
2. UXスタッフはプロジェクトの最初から迎える
UXに関する専門家とそのデザイナーは必ず最初からチームに加えておくこと。そうすれば彼らはプロダクトについて大局的な視点を確立し、これをテストすることができます。また。プロジェクトが進行にするにしたがってこうした視点からチームを助けることができます。
UXの専門家を初期メンバーとして加えることは、検証スタッフ、デザイナー、そして開発スタッフ間の協働と効率性を最大化するような作業プロセスの構築に役立ちます。更に、UXスタッフにとってもテストやデザインのプロトコルを確立し、テストの参加者リストを練りあげる時間を確保することができます。これはチームが多くのスプリントを繰り返した後では遂行するのが困難なのです。（アジャイル開発の世界では「スプリント」とはある作業が完了し、レビューができる状態にまで持っていくと決められた時間単位のことで、通常は数週間程度です）
3. 縦割り作業ではなく、協働しよう
たとえそれぞれのメンバーが従来と変わらず各々の専門領域でそれぞれの作業に責任を持っていたとしても、アジャイル開発の場では違いが出てくるものです。UXを上手にプロセスに組み込んでいるチームでは、ユーザビリティテストやデザイン作業にすべてのチームメンバーが関わっており、チーム全員に同意されたソリューションに基づいてデザインが反復されます。逆にUXスタッフはアナリストや開発スタッフと手を取り合って製品にデザインを適応していくことになります。
こうした密接なコラボレーションは製品に対してチーム全体で共有されたものの見方を醸成し、信頼を構築し、チーム作業の効率性を増すことになります。更に、開発が常にユーザーのニーズに基づいて変化していく中、デザインも開発の現状を常に反映している状態を作り出すことができます。上記で引用したAviva Rosenteinの記事、『The UX Professionals’ Guide to Working with Agile Scrum Teams』では、お互いの強みを尊敬しあい理解しあうことでチームの強い関係性をいかに構築していくかについて述べられています。
4. 実験を恐れない
Jeff Gothelfによる著作『Lean UX』で述べられているように、「失敗を許容することが試行錯誤の文化を生みます。試行錯誤や実験は創造性を育みます。創造性は、今度はイノベーティブなソリューションを生む」のです。アジャイル開発においては絶対的な答えというものは存在しません。
チームがそれぞれの開発プロセス、納品物、そしてスプリントのリズムなど試行錯誤する自由を持つことが必要です。リスクを許容し、先進的な開発手法やデリバリーを推奨できる文化をつくり上げるべきです。最初から正しい答えを探り当てられることはないでしょう。試行錯誤を続けていくうちに、徐々に正解に近づいていくものです。
例えば、アジャイル開発のUXスタッフの中には、UXに関連する作業を組み込む際に時間差のあるスプリントを設定すべきだと主張する人もいます。UXテストデザインの段階を、実際の開発よりひとつかふたつほど手前のスプリント内で実行する案です。（上記のLynn MillerやDesirée Syの記事でも言及されています）しかしJeff Gothelfは著作の中でこのアプローチに潜む不利な点を指摘し、チーム全体が同じ問題に同時に取り組むスプリントプロセスの組み方の実験を紹介しています。
皆さんのチームも、誰か他のチームのモデルを使ってUXプロセスをスプリントサイクルの中に組み入れてみるのがよいでしょう。いや、初めはおそらくそうするべきです。ただその時に、Jeffのチームのように、自分のチームやプロジェクトに最も適したやり方を発見するための実験を決して恐れないでください。
5. チームに最適のスプリント期間を見つける
持続可能なペースを保ちながら進捗できるスプリントリズムを確立することは必要不可欠です。これはスプリントにUXテストを引きこむ際には特に大切で、適切なスプリント期間を設けるということはつまり、それぞれのスコープとそれに対する有用なUX・テストとは何かを洗い出し、デザイン作業を最適単位に分解し（Desirée Syの記事がこの点について有用なアドバイスについて書いています）、適切な文献や論拠を探し、そしてそれらを期間内にやり遂げるということです。
究極的に、適切なスプリントリズムはチーム、そしてそのプロジェクトによって異なります。例えば、あるチームは2週間ごとの開発、そしてスプリントごとのUXテストが最もうまくいくと感じたとしましょう。他のチームは3または4週間のサイクルが最適かもしれません。上でも述べたように、あるチームではUXテストを毎回ではなく互い違いに組み込むほうがいいかもしれません。更に他のチームではJeff Gothelfが述べたようなモデルが適しているかもしれません。
6. UXテストの目的をはっきりさせる
アジャイル開発のタイム感で開発をするなら、UXテストのタイミングや粒度をいくらか調整する必要が出てきます。例えば下記のようなことを考えなければなりません：
・学習プロセスを効率化する
・重要なデザイン要素についての小スケールなテストを開発する
・プロトタイプを洗練するのではなく、再現率の低いモック上でテストする（モック上のテストの方が優れている点について詳しくはGarett Dwormanのブログ記事をご覧ください）
・RITEメソッド（高速反復テスト評価手法）のような手法を用い、素早いテストとデザインのイテレーションをまわす
・User Testingのような製品を用いたレスポンスの早いオンラインテスト、または内部の人間による簡易的なテストを補助的に用いる（特に初期デザインのテストの時）
・更なるユーザーテストに参加してくれるターゲット層のメンバーを速やかに確保できる方法を考えておく（適合する人々をリストアップしておくなど）
チームが必要としている情報を得るために、すべてのチームメンバーが各テストにおける質問について主体的でなくてはなりません。チーム全員で新たな発見をさらいつつ、課題に対して現実的で即効性のある解決策を示さねばなりません。
7. UXテストの素材と成果物について適切な水準を見つける
開発現場では古くから膨大かつ詳細な仕様書やドキュメントが溢れていましたが、アジャイル開発は「理解しやすい文書を元にソフトウェアを開発する」ことに重点を置いています（詳しくは『アジャイルソフトウェア開発宣言』をご覧ください）。これに加え短期間のリリースサイクルを目指すということは、基本的に長大なドキュメントを作成している暇はないということです。そんなものは書き終わる頃には無意味なものとなってしまいます。その代わり、アジャイル開発チームで働くUXスタッフはチームが前進するために必要としている物事だけを提供できるようなテスト素材やその成果物をいかに生み出すかについて創造的に取り組む必要があります。
例えば、記事の中でDesirée Syはチームのテスト結果について話し合う時、それぞれの問題についての文書とともに、口頭によるストーリ－の確認、観察された振る舞いについてのデモンストレーションを用いるべきだと論じています。
テスト結果による新たな発見はチームによって簡潔かつ優先順位が付けられておくべきです。そうすることで誰もがその発見について納得し、どの問題を一番に考えるべきなのか、またどの地点に立ち返ればいいのか等を知ることができます。JanetによるCarol Barnumへの6つのインタビューの中で、Carolは自身のチームにが毎回のテストが終わるたびに行っていた報告の様子について説明しています。上記で述べたようなことがきちんと行われた場合、仮に簡易的な報告であったとしても、それは質的に劣るわけではなく、むしろよりコミュニケーションの面に置いては効率的であることも多いのです。
