アジャイル開発プロジェクトとユーザビリティ

アジャイルメソッドは、従来の開発におけるユーザビリティの障害を克服することが目的である一方、ユーザーエクスペリエンス（UX）の質に新たな脅威をもたらしている。その一方、アジャイルのアプローチを変更することによって、苦労することなく効果が得られることを多くの企業が認識している。

Agile Development Projects and Usability
by Jakob Nielsen
on November 17, 2008

アジャイル（Agile）やスクラム（Scrum）といった Rapid Application Development (RAD) のプロセスをどのように扱うかによって、ユーザーエクスペリエンスの質が高められたり、もしくは脅かされる可能性がある。

アジャイルメソッドへの期待

アジャイルメソッドはユーザビリティ担当者を長年困らせた来た３つの問題の解決に対処している。:

50年の間、従来のウォーターフォール開発手法が結果としてユーザーエクスペリエンスの質を落とすということは、ほとんど全てのエクスペリエンスにより示されてきた。その理由は簡単である: 要求仕様書はいつも間違っている。
- 注意を払って作成された場合であっても、せいぜい、要求事項はユーザーが欲しがっている事柄を反映しているに過ぎない。しかしながら、より一般的な場合では、要求事項は、実際の作業についての詳細が分かる仕事の現場からは遠くかけ離れたところにいる、ユーザーを”代表する人たち”の要望を反映している。いずれにせよ、ユーザーが要求することと、ユーザーが必要とすることは、別々のものである。それが、ユーザーが言うことを聞くよりもむしろ、彼らの行動を観察せよということが長年ユーザビリティガイドラインの第一であり続ける理由である。
- 仮に、要求事項が書かれてから製品が納品されるまでの間に数年が経つような場合には、そのユーザーのニーズが変わってしまう可能性があり、要求事項とニーズの間により一層隔たりが出来てしまう。
- 過去25年以上に渡るユーザビリティについて行われた研究が、製品（実際に機能するもの、もしくはモックアップの画面のいずれかを使って）を取り扱っているユーザーを観察することがデザインの質を評価する上でベストな方法のうちのひとつであることを示している。繰り返すが、仮に開発者がこれを行うまでに数年経つような場合には、開発努力のほとんどが誤ったデザインに費やされることになるだろう。
文書はまた、ウォーターフォールのずっと下流においても問題を起こす。唯一、開発者達がデザイン仕様書から外れるよりも悪いことは、彼らがそのデザイン仕様書通りに実装してしまうことだ。インタラクションデザインの詳細について実装している最中にたくさんの問題が起こる; しかしデザインワークがずっと前に終えられ、ユーザーエクスペリエンス担当者が立ち去ってしまった後では、開発者達がユーザビリティを改善するやり方でこうした問題を解決することは出来ない。
1989年以降、“ディスカウントユーザビリティエンジニアリング”運動は、迅速に、かつ経費を抑えたユーザビリティメソッドが、ユーザーエクスペリエンスの質を上げる一番の方法であることを実証してきた。なぜならば、開発プロセス全般を通じて、開発者はそのユーザビリティメソッドを頻繁に使うことが出来るからだ。しかしながら、ユーザビリティの情報提供を要求するプロセスの中で、ただ一つのマイルストーンしか存在しないのであれば、これは実現しない。

アジャイルメソッドは、あらゆる方法で従来の開発手法が起こす体系的な障害に対処し、よいユーザビリティを実践する可能性を持っている。

アジャイルメソッドへの脅威

アジャイル開発におけるシステムの質に対する最大の脅威は、それがプログラマによって提案された手法であり、主にシステム開発のインプリメント側に注意を向けていることが原因である。結果として、インタラクションデザインやユーザビリティはコーディングの副作用として生じるままにされていて、しばしば見過ごされる。もちろん、このことは過去30年間において、メインフレームから PC、そしてウェブへと我々が移るにつれて、システム開発におけるユーザーエクスペリエンスの重要さが着実に増してきたという出来事の全てに矛盾する。ユーザーベースと使用事例が拡大するにつれて一流のユーザビリティへのニーズは大きくなっている。

質の高いユーザーエクスペリエンスを築くには、開発チームにインタラクションデザインとユーザビリティメソッドが必要だ。小さめのチームでは、このために専門のデザイナーとユーザビリティの担当者が必ずしも必要というわけではない。開発者がインタラクションデザインとユーザビリティに取り組むことは全く納得がいくことである。しかし、誰かがデザインやユーザビリティを主な仕事として行う場合でも、また担当するいくつかの役割の中の一つに過ぎない場合でも、チームはこれらの二つの行動を開発手法における明確な構成要素としてそれぞれ認識しなければならない。

デザインやユーザビリティを重要視するプロジェクトでは、コーディングに割り当てるのと同じ数だけデザインやユーザビリティにストーリーポイント（つまり人的資源）を割り当てる必要がある。

アジャイルにおけるもう一つの問題はプロダクト開発が一度に一つずつ完成される小さなパーツに分解されることである。そのようなアプローチには統合的な全体としてのユーザーエクスペリエンス、つまり異なる機能が一貫性を持って動作し、ユーザーがそのシステムの首尾一貫した概念モデルを築き理解するのを助けるという点を損なうリスクがある。最悪の場合、そのユーザーインタフェースはパッチワークのようなものになってしまうかもしれない。

このことに対処するために、チームはユーザーインタフェースのアーキテクチャを組み込んだストーリーボードとプロトタイプをデザインし、それらのツールを個々の機能をデザインする際のリファレンスポイントとして使ってはどうだろう。先行してあまりに多くの時間を費やすのを避けるためには、チームはコーディングを要しない忠実度の低いプロトタイプ－ペーパープロトタイプなど－をデザインしてはどうだろう。まさに我々がいつも推奨しているように。

一般的に、アジャイルチームは通常３週間程度の極めて短いスプリントと言う期間内で数々の機能をインプリメントする。そのような厳しい期限内で、テストを行ったり他のユーザー調査をする時間はないと考え、開発者はユーザビリティをバイパスするかもしれない。

この問題への解決策は以下の 3部から構成される:

ユーザーテストなどユーザビリティの取り組みを数日で行う。有効な方法の一つは、何がテスト可能になるかが確実に分かる前にテストの計画をすることだ。週一でテストを行うことは全く実現可能なことであるし、最も短いスプリント内においても数ラウンドのユーザーフィードバックをまとめる確実な方法を提供する。
- 我々は、チームが自分たちのプロジェクトを使って実際にテストしながら学ぶ、１ラウンドのユーザーテストの初めから終わりまでの実践法について３日間のコースを提供している。この手の迅速なテストは一日で行うことが出来る。そして、テストの準備と結果の分析の両方が、一日足らずで出来てしまう。
最も成功しているチームは、ユーザーエクスペリエンスに関する作業をインプリメンテーションの作業よりも常に１ステップ先立って行うというパラレルトラックアプローチを採用している。すなわち、そのチームがある機能の開発を始める時点では、それに関する最初のユーザーエクスペリエンスの作業は既に完了している。
最後に、機能開発の領域を超えた土台となるユーザーリサーチが我々には必要だ。理想を言えば、組織は開発作業が始まる前でさえこの作業に取り掛かるべきだ。また、更に大きな企業であれば、数年間に渡って多くのプロジェクトで使えるように、個々のプロジェクト外で、ユーザーのワークフロー、ペルソナやユーザビリティガイドラインに関する基礎的な知識を所有するべきだ。

アジャイルとユーザビリティで成功する

ユーザビリティとアジャイル開発の手法が共に上手く機能し、ユーザーエクスペリエンスの質を向上させると考えるもっともな理由は以下の通り:

アジャイルは、従来の開発手法で長らくユーザビリティの妨げとなっていた問題の数々を乗り越える多くの機会を提供する。
アジャイルに狭い視点でアプローチする、つまりシステム開発手法というよりはむしろプログラミング手法としてアプローチすると、ユーザビリティと開発を統合する上での過去 10年間における前進を損なう恐れがある。しかしながら、先に説明したように、こうした恐れの各々を避ける方法がある。そうした恐れを明らかな問題としてチームが認識している限り彼らが必ずしも製品の質に悪影響を及ぼすことはない。
最後に、我々が行った調査から企業の多くは順調に物事を上手く進めていったことが分かった－いったん彼らがアジャイルメソッドを質を重視したシステム開発に適合させれば。

機会と脅威、そして何が上手くいくかという体験的な事実に関するこの評価結果は２度の調査に基づいている:

105人のデザインや開発の専門家に対するサーベイ。
12社におけるアジャイルプロジェクトについての詳細なケーススタディ。

そのデータはたくさんの可能性を示しているが、その一方で残念な結果をもたらしたケースもいくつか見られ、アジャイルとユーザビリティを統合するために企業は系統立てた手順で取り組む必要があることを強調している。

アジャイルチームをサポートするユーザーエクスペリエンスの実践者にとって一番主な変化はマインドセットにある。アジャイルチームの異なった目的に合うように従来のデザインや評価方法を如何に変えるべきなのか、優れたユーザーエクスペリエンスの知識一般は、あなたがそれを理解する助けとなる。しかしながら最終的には、成功したいと思うのであれば、あなた自身を信じ、かつアジャイル開発の概念を受け入れることの両方が必要である。

仮に自身の実践方法を変え、責任を持って取り組む準備があなたに出来ているとしたら、サポートしているチームに対しあなたが与える効果とインパクトをさらに向上させるすばらしい機会が存在するのだ。