アジャイル世界でのUXの実践：
ケーススタディでの発見
アジャイルチームはアジャイル開発プロセスの実行という点では非常に優れている。しかし、時間に追われるために、ユーザー調査をあきらめたり、結果としてユーザーエクスペリエンスの質を下げてしまうこともある。
アジャイル開発プロセスがプログラマーの間で人気だ。そこで、迅速なプログラミングを追求しつつ、ユーザビリティもあきらめない素晴らしいプロダクトを作るには、どのようにアジャイルメソッドとユーザーエクスペリエンスの手法を融合させると一番良いかをここ数年、調べてきた。以前の調査では幅広い視点について考察した。そこで、今回は少数のプロジェクトを掘り下げ、より深い知見を新コースの「リーンUXとアジャイル」のために集めることにした。
先日、インタビューしたのはアジャイル環境で働く8人の専門家である。聞いたのは彼らのこれまでの道のりと成功と失敗についてだ。インタビュー対象者はユーザーエクスペリエンス（UX）デザイナーから、開発者、プロダクトオーナーまで様々で、全員、最低2年間、アジャイル環境で働いた経験がある。
アジャイルは定着している
もう後戻りすることはないだろう。私がインタビューした全員がこのプロセスが常にスムーズにいくわけではないことは認めてはいた。しかし、数年前に初めて実施したときに比べ現在の状況はかなり良くなっているという。この2年間だけでみてもいいことばかりではなかった、と打ち明けた人もいた。しかし、以前よりは相当に良くなってはいる。そして、ウォーターフォール手法のような従来型の開発プロセスに戻りたがっていた人は1人もいなかった。
このフレームワークが透明性を促すということではどのアジャイルチームはおおむね一致している。早い時期に課題の特定ができるようになり、短期間で機能を実現できるからである。開発者やデザイナーが何か月も費やして、プロジェクトを開始し、別々に作業したら、最後になってやっと課題が特定された、という時代は過ぎ去った。アジャイルでは最終段階での予期せぬ事態を最小限に抑えられるので、開発者はより効率的にスケジュールを予測できるようになる。
「我々は以前より要領よく仕事をしています。1ヶ月を通してみても、1日14時間働くことはもうありません。我々はチームとしての一体感があり、以前よりもリリースの回数も増えています…。というのも、より小さな単位で作業していて、融通が利くので、巨大な、たとえば作業に9か月かかるようなものよりも予測がしやすいのです。進行が早くなったことに皆が気づいています」 ソフトウェアエンジニア Victor談。
「アジャイル以前は順調に進めるのがたいへんでした。今は説明責任が増えました。そして透明性が増しています」 ソフトウェアエンジニア Anca談。
習うより慣れろ
数年間の試行錯誤の期間を終え、アジャイルチームはコツをつかみつつある。メンバーはタイムボックス、つまり作業の制限時間の設定が上手になってきた。かつては30分以上かかっていた毎日のスタンドアップミーティングも、今ではほぼ15分になりつつある。要点を押さえて、議題に忠実であることにチームメンバーが慣れてきたのだ。「ルール」やプロセスから生まれるメリットについての理解や認識が進んだからである。
時間の見積もりも正確になってきている。当初はスプリント（時間の単位）に対して自分たちで対処できる以上の作業を引き受けていたというチームもあったが、今ではこうしたことは以前ほどは課題になっていない。スプリントに対する妥当な作業量というのがわかってきたからである。
「無理がなくなってきています。妙な呼び名や新しいやり方に慣れる必要はありましたが」 UIデザイナー Michelle談。
コミュニケーションが成功の鍵
チームメンバーにとってのアジャイル利用の最大のメリットはコミュニケーションである。スクラム手法ではクロスファンクショナルなチームメンバーがアイデアを出し、責任分担をして、プロセス自体を皆で改善するためのストラクチャが提供されているからである。
「アジャイルの最大のメリットは振り返りにあります。それによって、自分がうまくいってないことを公にしたり、改善したり、違うことに挑戦したりすることができるようになるからです…。最初はアジャイルのルールに従うことを非常に重視していましたが。いろいろなスクラムチームと作業してみて、チームのために作業しなければならないということを学びました…。今はボキャブラリーも共有できているし、理解も共有されています」 プロダクトマネージャー Jeff談。
「スクラムの価値は対話にあります。すべてのルールを守ろうとして自分を責めすぎる必要はありません。できるところまででいいのです」 プロダクトオーナー Cathy談。
組織でのアジャイルの課題
多くの人にとっては、アジャイルの道のりはまだ困難なものであり、全社的な支援を得るための苦しい闘いは続いている。開発チームは熱心に作業して、アジャイルの価値を否定派に示し、彼らにぬるま湯に浸かった状態から出てきてもらう必要がある。
経営陣による支援の欠如
アジャイルの主要な課題の1つが、上層部の支援を得ることである。私がインタビューした人の中には、経営者側の関与がないことに対するいら立ちを表明する人もいた。経営陣の後押しがないと、開発チームは経費や時間を節約せざるをえず、有効な対応ができなくなる。アジャイルプロセスに対する誤解は、コミュニケーションの断絶と一貫性のない計画を生むことになる。
「アジャイルチーム外の利害関係者がスプリント計画に干渉してくるのです」 UXデザイナー Julia談。
「計画に入ってないことについて作業しなければならなかったこともありました」 プロダクトオーナー Cathy談。
「我々のグループはアジャイルを支持していますが、組織全体でみるとまだそうではありません。我々にはアジャイルコーチが2人いましたが、コーチたちは経営幹部を動かすのはうまくありませんでした。彼らには経営幹部を味方に引き入れるほどの影響力がなかったのです」 シニアプログラマーアナリスト Mandy談。
不十分なリソース
経営陣の支援がなければ、通常、リソースは減ることになる。私がインタビューした専門家たちはスクラムのようなアジャイルやリーン手法にメリットがあることでは一致している。スクラムの各要素はプロセス上のニーズに応えるように構成されている。最も成功したいくつかのプロジェクトはチームが方法論にまで関与できた場合に生じている。しかしながら、私がインタビューしたほとんど全員がそうしたやり方を取れていなかったり、ショートカットせざるを得なくなっていた。その主な理由こそがリソース不足である。
ユーザー調査とユーザビリティテストの欠如
我々のアジャイルパネラーたちはデザインを検証することの重要性に関しては一致している。しかし、残念ながら、ほとんどのチームはユーザーリサーチを継続的には実施していない。実施自体はしていても、だ。納期の厳しさや人員不足が、ユーザー中心の活動が減る理由として挙げられていた。しかしながら、ディスカウントユーザビリティ手法なら必要に応じて、短いスケジュールへの対応は可能である。
ユーザー調査の省略は非常にリスキーだ。最高のデザインアイデアも単なる仮定にすぎないからである。天才デザイナーにも限界はある。ユーザー調査によって我々は仮定をテストできるようになり、認知バイアスが優位になったり、自分たちが道に迷ったりするのを防ぐことができる。
「社内で課されたデッドラインに追われているため、テストなしでアウトプットを出さなければならないこともありますが、こうしたプロダクトはユーザーにとっては最適なものではないでしょう」 UXデザイナー Julia談。
「ユーザビリティテストを実行するのは非常にたいへんです。人は不足しているし、チームには主要な調査担当者もいないからです。マーケティング部門から人を借りたこともあるのですが、そういう人はプロダクトについての知識が十分でなかったり、『ユーザーが大好きです』という我々の哲学に従わなかったりします」 UXデザイナー Julia談。
「ユーザーテストをする時間がありません」 ソフトウェアエンジニア Victor談。
良い知らせもある。スケッチやワイヤーフレーム、ペーパープロトタイプのようリーンなUXテクニックが支持を得てきていることである。そこではデザイナーがアイデアを明確に示し、分厚い文書を減らす方法として、忠実度の高くないプロトタイプの作成が推奨されている。その反面、多くの組織ではターゲットユーザーでそれをテストしていない。
「なんとかリーンであろうとがんばっています。ワイヤーフレームを使わずに、思い切ってスケッチに取り組むように上司からはずっと勧められていますが。切り替えは難しいものでした。ワイヤーフレーム中毒とからかわれます。ですが、スケッチのおかげで皆が考えているアイデアを理解できるようになりました」 UXデザイナー Julia談。
「我々はこれまでずっとクイック＆ダーティペーパープロトタイプを作り、モックアップを描いて、開発との連携を強化してきました」 シニアプログラマーアナリスト Mandy談。
UXアジャイルチームの円滑な運営のためのヒント
チームの一貫性を保とう
正しい判断を素早く下せる専門知識を持った良質で結束力のあるチームを作るのは時間がかかる。アジャイルチームごとに作業の仕方が異なったり、チームを動かす原動力が独特だったりする可能性もある。そうしたシステムを混乱させると、スピードが大きく阻害される。知識や期待値を再構築しなければならなくなるからである。
「チームとしての一貫性が鍵です。組織の再編成やメンバーのたらい回しはやめなければいけません。チームは一緒にいて、一緒に学べば、どんどん良くなるし、スピードも増していきます」 調査リーダー＆UXデザイナー Derek談。
「それは私にとってはチャレンジです。専用のリソースがないからです。ある週はこの人ですが、次の週は別の人が来るのです。アジャイルコーチを現場に確保はしましたが、全員がトレーニングを受けたり、必要な時間だけプロジェクトに専念するのでないと、新しい人が来るたびに最初からやり直さなければなりません…。メンバーをアジャイルとウォーターフォールの間で行ったり来たりさせてはならないのです」 UIデザイナー Michelle談。
状況に応じるのではなく、自ら動こう
もし長い期間、「目立たないように」仕事をしてきたのなら、仕事のスタイルを変える必要がある。さもなければ時代遅れになる危険性があるだろう。連携がプロダクト開発を成功させる鍵である。クロスファンクショナルチームのメンバーが関与することで透明性は高まり、課題の特定も早くなる。計画立案を含む、デザインプロセスのあらゆる側面に関わろう。自分のアイデアを伝えて、取り組んでいる内容を提示し、議論に貢献できるように準備しよう。
「コミュニケーションを良くすることに皆が積極的である必要があります。チームと、自分が現在作成中のものに注力しなければなりません。借家人ではなく、主人であれ（Be an owner, not a renter）、ということです」 UXデザイナー Julia談。
「開発者は注文を受けるだけではなく、質問をする必要があります。チームとしての作業に皆が興味を持たなくてはなりません」 UXデザイナー Julia談。
特に開始時には、専任のスクラムマスターを置こう
アジャイルでいくことについて検討中だったり、アジャイルを開始したばかりなら、スクラムマスターのための予算を必ず確保しよう。この人物のおかげでプロセスがスムーズにいくようになるからである。熟練したコーディネーターなしには、物事がうまくいかない可能性は高い。そうなると、メンバーがプロセスに不満を抱いたままになる。
「専任のスクラムマスターを必ず置くべきです。それができない場合は、役割分担をはっきりさせておかねばなりません」 シニアプログラマーアナリスト Mandy談。
「スクラムマスターは牧羊犬であり、ブルドーザーであり、コーチでもあります。彼らは課題を確実に解決するように仕向けて、チームにやる気を出させます。スクラムマスターがいないと、プロセスが混乱していると皆が感じてしまう危険性があります」 プロダクトオーナー Jeff談。
UXの作業は、該当スプリントの最低1ステップ先を行く必要がある
アジャイルは開発に馴染む。しかし、だからといってUXによる影響が減るわけではない。結果を出すUX専門家は、バックロググルーミングから印刷物の計画立案、ワイヤーフレーム、ユーザー調査に至るまで、積極的にアイデアを出し、自らがアジャイルプロセスの一部となる。UXデザイナーはスプリントが発生する前に活動を計画する必要がある。それはつまり、先回りして、想定したものをテストし、残りのチームメンバーより先にデザインに取り組むということである。彼らはスプリントの前に「show and tell」活動を行い、ユーザーやチームメンバーにコンセプトを紹介する。そうすれば、開発を始める準備が整ったときには、必要なUXデザインがチームには揃っている。（訳注： “show and tell”の本来の意味は、学校の課題として、子どもに何かを持ってこさせ、クラスメートにそれについて説明すること）
「UXデザイナーは進行中のスプリントの最低1ステップ先にいなければなりません。それはつまり、現時点のスプリントの外で調査し、デザインをするということです。私がしなければならないのは、チームのために線路を敷き続けることだからです」 調査リーダー＆UXデザイナー Derek談。
「UX関係者はモックアップのあるスプリントの先を進むべきです」 UIデザイナー Michelle談。
「開発に少しだけ先んじて、UXのデザインはしなければなりません。そうすることで開発がやりやすくなるからです。曖昧なコンセプトは要らないのです」 プロダクトオーナー Jeff談。
結論
アジャイルの躍進は続くだろう。組織がそのメリットに気づくからだ。UXの専門家はアジャイルやリーンなUXプロセスに対応する必要がある。そうしたプロセスでは透明性や連携、応答性が重視される。さもなければ取り残される危険性がある。
アジャイルのユーザーエクスペリエンスプロセスではデザイナーは思慮深いだけでは足りない。まず、ユーザーを知り、そして、自分の想定が正しいかを継続的にテストしていく必要がある。アジャイルプロセスで時間に追われた中でも、ユーザー調査から逃げてはならない。オフィスを出て、ユーザーから学ぼう。UXのリーンなテクニックをアジャイル開発プロセスに組み込むことは可能だ。たとえば、オンラインユーザーテストのような手法なら、数分でフィードバックは得られる。
固定されたスケジュールの中で優れたユーザーエクスペリエンスを作り出したいと思わないか？ もしそうなら、Nielsen Norman Groupの「リーンなUXとアジャイル」についての1日トレーニングコースに参加してほしい。そうすればさらに深いアドバイスを得ることができるだろう。
