User-Centered Agile Methods
「Contextual Design」の著者で有名な Hugh Beyer 氏の資料（本も出版されているようですが）「User-Centered Agile Methods」を購入し、掻い摘んで和訳してみました。
 | User-Centered Agile Methods (Synthesis Lectures on Human-Centered Informatics) Hugh Beyer Morgan & Claypool 2010-10-30 売り上げランキング : 282039 Amazonで詳しく見る by G-Tools |
アジャイル文化の浸透とUX
アジャイル開発というアプローチは従来の開発手法よりも便利かつ信頼性のあるソフトウェアの生産性を更に早くしてくれることを約束してくれます。アジャイル開発と一概に言っても XP（eXtreme Programming：エクストリーム・プログラミング）*1や Scrum（スクラム）*2、FDD（Feature-Driven Development：ユーザー機能主導型の開発）*3など複数のアプローチが存在しますが、これらすべてのメソッドにおいて共通している要素に以下があります。
- とにかく早い
- イテレーションを繰り返してユーザ価値を提供する
- チームをコンパクトにまとめて生産性を上げる
- ドキュメンテーションはミニマムレベルに抑える
- フィードバックを定期的に行う
Agile Development と称されるだけあって、デベロッパーに注目されがちですが、最近では UX（User Experience：ユーザ経験）を向上させるための最適な手法としてユーザ・リサーチャーやUIデザイナーなどユーザビリティ関連の職種に就いている人々もアジャイルに関心を抱くようになり、Agile UX（アジャイル UX）という言葉が浸透するようになりました。
アジャイル UX は特に米国で急速に発展を遂げています。デベロッパーはもちろんのこと、マネジャーにとってプロジェクトの根底にある問題解決に通用すると認められ始めているからだと思います。そして、アジャイル文化としての価値が浸透し始めている最大の理由に、UX デザイナーとソフトウェア・デベロッパーの関係性を良好に保ち、ぐっと距離を縮めてくれることにあります。UX デザイナーはユーザニーズを抽出して定義するスキルに長けていることは確かです。だからこそ、それをシステム側に翻訳して要件に落とし込まなければいけません。UX デザイナーとデベロッパーの距離を縮められることができれば、少しでも支えになるはずです。
結果としてデザイナーやデベロッパーは早期にインターフェースや機能要件固めに参加することができます。他にもアジャイルを導入することのメリットには以下が挙げられていました。
- 様々な要因を発見・解決するまでの時間を縮めてくれる
- 最も重要な要件を最初に定義できる
- 迅速なイテレーションを可能にする
UCA（User-Centered Agile）プロセス
アジャイル開発ではデベロッパーやデザイナー問わず、プロジェクトに関わるメンバー全員はプロジェクトの上流よりアサインされるため、プロジェクトそのものの要件を固める Phase 0 から着手することが理想と言われています。BPUF（Big Picture Up Front）という発想があるように、チームのビジョンを一枚の絵図に集約させる作業を行います。確かに、仕様はからっぽのほうが夢が詰め込めます。
汎用的なアジャイル UX の開発プロセスが紹介されていました。Initial User Research や ideation が含まれるユーザ・ストーリー構築フェーズでは Contextual Inquiry（CI：ユーザシナリオ法）や Affinity Diagram（親和図法・KJ法）、Sequence Model（シーケンス図）など UCD プロセスに馴染みの深い作業が実施されています。
次に User Environment Design（UED）やペーパープロトタイピングを使い、具体的なデザインに落とし込みます。ストーリーとデザインが固まればシナリオ別にスプリント（イテレーション）が分類され、実装されていきます。ポイントとして、開発はミニマムに主要機能のみを実装し、シナリオ毎に機能を追加し、発展させていきます。
まとめ
アジャイル UX の本質は「ユーザをチームの一員として迎える」ことにあると思います。アジャイル開発を組織に浸透させるためには、この本質を先ずは理解してもらう必要があります。全てのソリューションはユーザから想定されるユーザストリーから生まれるもので、インデックスカードや付箋に記入して管理されます。最終的にはストーリーボードと呼ばれるドキュメントが完成します。これは、システムとユーザ間のインタラクションを表したもので、各タスクをどのようなストーリーでユーザが進めているのかが一目で分かる、文字通りのシナリオです。
ユーザストーリーは以下のフォーマットにあてはめられます。
One common format for writing stories is to write them in the form “As a [user role], I want [a feature] so that I can [achieve some goal].”
[役名]として、[ゴール]を達成するために[ソリューション]が必要である。
例）ネットワークマネージャーとして、ネットワーク問題を簡単に定義して管理するためにネットワークを一目で確認できる機能が必要である。
そして BPUF(Big Picture Up Front) という発想があるように、早い段階でビジョンとなる絵図をチームで描くことで Requirement Definition（要件定義）ではなく、Project Definition（プロジェクトそのものの定義）を進めていく重要性に気づきました。必要なのはソリューションではなく、ビジョン。アジャイル UX を参考に、プロジェクトそのもののシナリオの見直しを。アジャイル UX はユーザとの親しい関係を保つことができます。とても早く、かつプロブラム・フリーで。
おまけ
アジャイル開発といえば TDD（テスト駆動開発）をイメージしがちですが、アジャイル UX の場合はアジャイルと進め方が類似している ICONIX プロセス（PDF）のような DDT（設計駆動テスト）アプローチにフォーカスすべきだと思います。ICONIX プロセスの要件定義や基本設計の考え方はウォーターフォールに近いため、アジャイルとウォーワーフォール両方の良さが融合されたプロセスのように思えます。アジャイルなやり方が現実的に思えない場合は良いかもしれません。
