アジャイルユーザーエクスペリエンスプロジェクト

我々は昨年、ユーザビリティ手法のアジャイル開発プロジェクトへの統合における成功事例について、調査を実施した。

通常、1年しか経ってないのに、同じ問題についての調査をわざわざする価値はない。ユーザーの行動というのはそれほど変化するものではないからだ。しかし、このプロジェクトに限っていえば、問題になっていたのはユーザーの行動ではなく、ユーザビリティを保証するための最適なアジャイルプロジェクトの運営方法であった。

この分野はまだ新しいので、我々は新たにより詳細な調査を実施し、昨年の調査を補完することにした。そこではアジャイルユーザーエクスペリエンス（UX）のより良い管理方法を発見する時間の余裕があった追加の組織を、集中的に調べることをした。

UX：ゲートキーパーの役割

アジャイルプロジェクトにおいて良好なユーザビリティを確保するための2つの主な提言の内容は、前回調査から変わっていない：

• デザインと開発を分けよう。そして、ユーザーインタフェースのチームの進行を実装チームに一歩先行させよう。そうすれば、実装時には、デザインもテストも既に終わっていることになる。（そして、そう、この2つはペーパープロトタイプや安価なユーザーテストを利用すれば1、2週間で終わらせることができる）。
• ユーザーインタフェースアーキテクチャについて一貫したビジョンを維持しよう。「スプリントゼロ」の期間中、すなわち実装が始まる前に、最初のビジョンを描こう。そして、それを1年ごとの（あるいは半年ごとの）デザインビジョンスプリントの期間中、維持しよう。個々の機能だけをデザインするようなことはしてはならない。つまり、それらは首尾一貫性のある全体に組み込まれる必要があるし、その全体自体も一貫性を持ってデザインされなければならない。ボトムアップ型のユーザーインタフェースデザインはユーザーエクスペリエンス全体を混乱させるものと考えてよい（Linux症候群）。

2回の調査共に、調査した企業の多くでこの2つの考えが有益であることが証明された。1つの修正点が2回目の調査では明らかになったが、それはPayPalの事例がきっかけだった。その内容とは、UXのチームとそれ以外のチームの全員を軌道上に乗せておくためには、両者間の要求とコミュニケーションの進展を見守るゲートキーパーを指名することが重要だということである（たとえそれらの軌道が平行して走っているものだとしても）。

Circle D Design（：米ミシガン州のウェブサイトのデザインのコンサルティング会社）が使っていたのはこのバリエーションで、各プロジェクトでのUXについてのコミュニケーションを図るために「アンカーパーソン」（：本来は、ニュース番組の総合司会者のこと）を指名していた。プロジェクトでUXの専門家が新たに必要とされると、彼らはアンカーとペアを組む。アンカー達は定期的にローテーションされるため、アンカーの代表者はチーム内のメンバー間の長期的コミュニケーションの支援もしている。

集中型のUX部門の衰退

ユーザビリティやインタラクションデザイン、テクニカルライティング、その他の専門的な領域をどのように組織図の上に配置するべきかという議論には終わりがない。主な選択肢は2つある：

• 集中型ストラクチャでは、ディシプリン（ワークフロー）を「所有し」て、それを組織中の全てのプロジェクトの開発チームに供給するチームが1つだけ設置される。例えば、集中型のユーザビリティグループが設置されれば、そこがユーザーテストやその他のユーザー調査を全て運営することになる。それが集中型のデザインチームであれば、そこがインタラクションデザインとビジュアルデザインを全て供給するし、集中型のユーザーエクスペリエンスチームであれば、そこがユーザーエクスペリエンスに関わるデザイン及び調査を全て行うことになる。その後は、個々のプロジェクトチームが集中型のチームの行ったデザインや調査結果を受け取り、実際の製品化を行う。
• 分散型ストラクチャでは、集中化を避け、その代わりに専門知識のあるスタッフを個別プロジェクトで直接働けるように配属する。このストラクチャでは各プロジェクトチームにユーザビリティの専門家やインタラクションデザイナー、ビジュアルデザイナー、インフォーメーションアーキテクト、テクニカルライター、その他ユーザーエクスペリエンスの全領域のための専門家が専属でいる。実際、大規模なプロジェクトではチーム内にそうした専門家が複数いることもある。

分散型ストラクチャの明らかな欠点は、各チームの個別領域に1人以上任命するのに足りるだけの専門家がその企業にいない可能性もあるということである。したがって、複数のチームで1人の専門家を共有したり、専門家がいないまま進んでいかなければならないチームが出てくることもありうる。

集中型ストラクチャでは専門スタッフに「家」を提供するが、それによって彼らは同じ領域の同僚と親しくなれるため、喜ばれることが多い。このことは専門スタッフの管理や昇進をより容易にする。例えば、集中型ユーザビリティグループのマネージャーは通常、ユーザビリティの専門家であり、集中型デザイングループのマネージャーはシニアデザイナー、UX部門の取締役もシニアデザイナーかユーザビリティ系の人間である。こうしたマネージャー達は自分のスタッフのタスクやニーズをよくわかっている。（反対に、ユーザビリティの専門家が開発マネージャーを上司に持つと、ある調査がうまくいくものなのかどうか、そのマネージャーには全くわからないということがよくあるだろう）。

集中型の部門では個々の開発プロジェクトを横断する戦略的イニシアチブを支援することも可能である。例としては、ユーザーインタフェースの基準やガイドラインの執筆及びメンテナンス、ユーザビリティラボの建設、UXの長期間、あるいは比較用の数的指標の収集、さらには、戦略的なUXの課題を上層部とやり取りし、ユーザビリティにさらに投資するよう彼らを説得して、組織の成長を促すことも含まれる。

こうしたことは全て非常にうまくいくが、アジャイル開発チームにユーザビリティや良好なUXを統合しようとしたとたんに問題が出る。我々がケーススタディで見た全ての事例から、UX関係者が開発者や他のプロジェクトメンバーと同じ場所にいる必要性があることは明らかである。実際のところ、UXはプロジェクトチームの一部分であると見なすべきで、外部の部門と考えるべきではない。

自分のところのUXの人員を他所に配置するからといって、集中型の専門家グループが持つ利益の全てを放棄することにはならない。マトリックス構造にすれば双方の長所が使えることも多く、UXの専門家を個別プロジェクトに日常的に組み入れつつ、全社規模の調整をすることも可能である。

アジャイルUXは良いものだが、さらに良くなりうる

今年度の調査では、自分たちのプロジェクトにどのくらいの範囲でUXを統合したのか、そして特定の開発方法を使ったプロジェクトで働いていた時の満足度はどうだったか、を参加者に質問した。そこでの答は5段階尺度で示され、5を統合度あるいは満足度における最高値とした：

アジャイル型が旧式のウォーターフォール型よりも大幅に優れていると見なされていることは明らかである。あんなものが無くなってせいせいしているというところか。しかしながら、最新の調査では、専門家達はアジャイル型よりも反復型の方が現時点でも少しばかり優れていると思っているようだった。アジャイルプロジェクトをよりユーザー主導にするにはまだまだやらなければならないことがある。

さらに良いニュースとして、新しい方の調査データからは、UX関係者が「連中と我々」の壁を越えようと動いているという証拠が出てきた。全体的に見て、開発者の方がUX関係者よりも2つの重要なUX評価指標において楽観的だった。

開発者は成果物の品質に対するユーザーエクスペリエンスの影響度を4.3と評価したが、UX関係者はそれを4.0とした（ここでも5段階尺度で5が最高）。開発者はUXの関与によって生産性が幾分向上したという見解だったが（3.3）、この点についてのUX関係者の評点はそれよりわずかに高く、3.4だった。開発者もUXの専門家もプロジェクト内にさらにUXを取り込みたいと強く要望している。ユーザビリティとアジャイルをなんとかして融合させようとしている企業では、まだ完全とは言えないまでも、物事は既にかなりうまくいっていた。

さらに詳しく

119ページからなるアジャイル開発プロジェクトにおけるユーザーエクスペリエンスのための成功事例に関する調査レポートがダウンロード可能である。

オリジナル記事公開日: 2009 年 11 月 04 日