UX もアジャイルに行こう！

アジャイルUX 小史

　アジャイル開発と UCD（ユーザ中心設計）は別々に進化を遂げていましたが、ほぼ同時期に一躍注目を浴びるようになります。1999年にUCD の国際規格 ISO13407 が制定され、2001年にはアジャイル宣言が出されたのです。これらの手法を組み合わせて、優れたUX を迅速に開発しようという動きが現場で起きたのは自然なことでしょう。　（なお、アジャイル開発の具体的な内容についてもっと詳しく知りたい方は、ぜひ牛尾さんの連載をご覧ください。）

　ただ、最初の頃はそれらの試みはあまり上手くいきませんでした。そもそも伝統的な UCD はウォーターフォール的ですし、手法の多くはアジャイル特有の短期間のイテレーション（1～4週間）には収まりません。そのうえアジャイル開発者と UX の実務家は、お互いを全く理解していませんでした。ケント・ベックとアラン・クーパーの論争はそれを象徴するものでした。

　XP（エクストリーム・プログラミング）の考案者でアジャイル宣言の起草者であるケント・ベックと、ペルソナの"父"で UX 界の大御所であるアラン・クーパーが2002年に対談しました。この中で、クーパーが「事前に十分な設計（インタラクション設計）を行うべきだ」と主張したのに対して、ベックは「それはボトルネックになる」と強く反論しました。なお、この対立は完全に過去のもので、その後二人は共にアジャイルの発展に貢献しています。 

　そんな中で"荒野"を切り開く開拓者が現れました。ジェフ・パットン、トッド・ザキ・ウォーフェル、リン・ミラー等です。その当時、彼らは必ずしもオーソリティではありませんでしたが、実務の中でアジャイルと UCD を統合する方法を模索し、その成果を積極的に公開しました。その結果、2000年代中頃以降にアジャイルUX は急速に発展して、2008年からは Agile conference においてアジャイルUX に関する独立したステージが設けられるようになりました。

アジャイルUX の基本原理

　アジャイルUX とはこのような実務家による活動の総称であって、今のところプロセスや手法が厳密に定義されている訳ではありません。ただ、経験から導かれた基本的な原理・原則はあります。

　内から外へ――ソフトウェアでは一般に「ある製品の機能の中で、ユーザがよく利用するのは２０％に過ぎない」と言われています。そのためアジャイル開発では「余計な機能は作らない」ようにするのが鉄則です。UX に関しても、ユーザにとって最も価値の高い必須の部分から設計を始めて、徐々にオプション的な部分へと拡げていくようにします。

　平行して――開発と UX 設計をイテレーション内で同時に完了させようとしても上手くいきません。UX 設計が間に合わず開発が遅延したり、時間に追われて稚拙な UX 設計に終わったりします。成功の鍵は UX 設計を最低１イテレーション先行させること（パラレルトラック法）です。

　軽い手法で――伝統的な UCD 手法の多くは、複雑なプロセスとたくさんのドキュメントで構成される"重い"ものです。従来の手法をそのまま適用しようとしてもアジャイルのイテレーションには収まりません。各手法の本質的な価値を損ねないように十分注意したうえで、無駄をそぎ落とした軽量な手法を用います。

アジャイルUX の潮流

　アジャイルUX は特に米国で急速に発展しています。このような大きな潮流は、多少のタイムラグはあるものの日本にも到達することになるでしょう。

　背景の１つはアジャイル開発そのものの普及です。最近は RFP（提案依頼書）に「開発はアジャイルで」と書かれている例もあるというくらいに、日本でもアジャイルは広く認知されるようになりました。もしプロジェクトがアジャイルを適用すれば、UX もそれに対応せざるを得ません。実は、米国でも UX の実務家の多くは「アジャイルUX に取り組まざるを得なかった」といった方が正しいのです。

　もう１つは、日本でも『プロダクトオーナー（ユーザ側を代表して意志決定を行う役割）』の重要性が改めて認識されつつある点です。先日、日本で初めての認定スクラムプロダクトオーナー（CSPO）講習会が開催されたのですが、そこで公開された本場のプロダクトオーナーが使うテクニックの多くは UCD を基盤としたものでした。米国では、既にアジャイルUX は製品開発の総責任者であるプロダクトオーナーに必須の手法となっているのです。

　今後、読者の皆さんがアジャイルUX という言葉を目にしたり、また、実際のプロジェクトでその手法を必要とする場面が増えると思います。そんな時に、今回の連載がアジャイルUX を理解する一助となれば、とても嬉しく思います。