アークウェブ ビジネスブログ

彼の著書「コンピュータは、むずかしすぎて使えない！」(山形浩生訳、翔泳社)の中でクーパーは、ユーザーにとって使いやすいインターフェースを作成するために彼が考案した「ペルソナ法」について紹介しています。
ペルソナ法について、ネット上では「@IT: 利用者の立場を考えたペルソナ／シナリオ法による開発とは」にわかりやすい説明があります。

彼は

There’s enormous cost in writing code, but the real cost in writing code is that code never dies. If you can think this stuff through before you start pouring the concrete of code, you get significantly better results. You get significantly more efficient programming and you don’t end up with pulled teeth.

と、プログラムコードを書き始める前に画面のデザインを決めてしまうことが開発コストを抑えるために重要だと言っています。
これはウォーターフォール式のワークフローでありますが、XPに組み入れるためにいくつかの工夫をすることで、両方の恩恵を受けることができるとしています。

私自身は、Webサイト構築にあたり詳細なデザインプロトタイプを作成することで、同様の効果を得ることができないか模索中です。

現在のWebアプリケーション開発において、アジャイル開発手法はその特性に合っており、これからますます適用例が増えてくると思われます。またWeb2.0の時代、Webのフロントとバックエンドを高いレベルで融合させるスキルは、Web制作会社として必須のものなってくるのではないでしょうか。

以下は、このエントリーの著者の生徒がまとめた、「Introducing User-Centered Design to eXtreme Programming (ユーザーセンタードデザインをXP手法の中で実現するメソッドについてのレポート)」(PDFファイル)の翻訳文です。
学生たちがワークショップで実際に行った方法など、参考にできる部分は多いと思います。
非常に長いのでエントリーを2回に分けてご紹介します。

-----

Introducing User-Centered Design to eXtreme Programming
エクストリームプログラミングへのユーザーセンタードデザインの導入

Anders Toxboe
Copenhagen Business School
Department of informatics
May, 2005

1. 問題点

特定のグループユーザーに対する新しいソフトウェアを作りあげる時、ユーザーセンタードデザイン(以下UCD)ツールは、初期のアイディアをターゲットユーザーに適合させるのに役立ちます。現在まで、UCDツールはソフトウェア開発のメソッドを使って要求をまとめるのに使われてきただけです。UCDツールはソフトウェアの実装にのみ利用され、ソフトウェアを使いやすくすることはプログラマーに任されてきました。

新しいタイプのソフトウェアを作るにあたって、インターフェイスがどのようであるべきかは決まっていません。新しい機能、もしくは変更された機能要求を実装するには、旧来の開発メソッドでは、実装の一段階前に戻り、機能要求のまとめに組み込まなければいけない。XP手法はそのフェーズ分けを捨て、要求と実装をごく短い期間で行うようにする手法です。

XP手法とUCDはそれぞれ素晴らしい発想であり、お互いを補足することができます。しかしXPにはユーザーの真の姿を捉える視点が欠けていますし、UCDにはプロジェクト終了まで通用する柔軟な開発メソッドが欠けています。

ここで、この2つのメソッドを融合させたテストを行うことにします。

1.1　問題点の公示

XPは、開発者側と顧客の間で取り決めたストーリーをベースにしています。もし顧客が存在しない場合や作りたいソフトウェアの形がはっきりしていない場合にもXPの恩恵を受けたい時はどうするべきか。
この論文での問題提示は以下のとおりです。

---
XPの開発メソッドをUCDと融合させ、ストーリーではなく使う人間のことを考えたソフトウェア開発手法を作りあげる方法とは？
---

2. メソッド

2.1　理論的な範囲

ここで論じるのはXPとUCDを融合させた開発手法で、細部にわたる手法の説明をすることではなく、初期段階のアイディアと開発実装の架け橋を造り、いかにユーザーをXPのメソッドの中に取り込みデザインの決定を行うのかということです。
つまり、XPのメソッドをよりユーザー至上主義にするということになります。
ここではUCDの定義を、ニールセン(Jacob Nielsen)の言葉によるものとします。

「ユーザーセンタードデザインとは、ユーザーがそのシステムを利用する動機が何であるかを理解し、ユーザーの要求を容易に達成できるようなデザインを含んだシステムを作ること」

重要なのはデザイナーもプログラマーも、ユーザーがシステムを利用する動機について理解しなくてはならないということです。

2.2 エクストリームプログラミング

XPは、顧客に価値あるソフトウェアを与え満足をもたらすためのメソッドです。
短いスパンでの要件定義と素早いフィードバック、リファクタリングのようなツールや単体テストにより、要求の変化を容易に受け入れることができます。よってプロジェクトを正しい方向へ導くことができます。

XPでは以下の点に価値を置いています。
・過程とツールではなく、人とその関係性
・ドキュメントではなくきちんと動くソフトウェア
・契約の交渉ではなく顧客との協調
・計画を追うことよりも変化に応えること
つまり、スコープよりも品質を重視します。

XPでの登場人物は、大別すると顧客(意思決定者)と開発者の2者です。
顧客の要求は、ストーリーに細分化されます。
個々のストーリーは最長でも1イテレーションの中で完了し、実装する機能について2～3行の記述で済むようにします。

各イテレーションの初めに、プランニングミーティングを開きます。プライオリティを付け、実装するストーリーの特徴を把握します。ストーリーに基づく受け入れテストは実装が正しいかをチェックするためのテストです。

XPは、伝統的な開発手法の弱点を補うべく、今までの開発手法に改良を加えたものです。

2.3　ユーザーセンタードデザイン

UCDの存在場所は多岐にわたります。オブジェクト指向開発で作られたシステムでも、スタンドアロンのアプリケーションにでも同様に存在します。
UCDは「システム」ではなく「人」を中心に考えます。利用者のタスクと目標に応えることで開発とデザインを直結させます。適用範囲はソフトウェアや製品だけでなく、プロセスにも及びます。人が関与するオブジェクトであれば全てに存在します。
またUCDは、既存のシステムの評価や、ペルソナ法がよく用いられます。

UCDツールがXPと融合させるのに適切かどうか、判定基準が必要です。その基準を作る場合に、短期間の開発サイクルと同様にアジャイル開発手法のマニフェストも考える必要があります。

・ツールは、作り出すソフトウェアの品質を最優先させるために、最小限のドキュメントを作成するだけで済むようにしなければなりません。
・UCDツールを開発サイクルに組み込む場合、タイムスパンをXPのイテレーションの日数より小さくしなければなりません。
・UCDツールは開発手法の制定よりも要求の変化に対応できることが必要です。
・UCDツールはフィードバックの手段として利用されることもあります。
・ユーザーの理解を助けるために、UCDツールは、ツールを使わなかった場合よりもより詳しいフィードバックが得られるようにしなければなりません。

紙の上でのスコープ設定には限度があります。私がUCDのテクニックを多く用いない理由として、上記の基準を頭に入れてXPと合わせる必要があるからです。

上記のリストはどちらのテクニックが優れているかを順位付けするのではなく、私が考えているツールについてのアイディアを読者に理解してほしいからです。

ペルソナ法、シナリオ法、プロトタイピング技法、文化調査などUCDのテクニックは全てXPに組み込むことができます。

他には、コンセプトモデルの作成、階層的タスク分析、ユースケース図、ヒューリスティック調査などをUCDツールと見ることができます。

3. 各メソッドの評価

XPに対する批評の大部分が先に述べられた調査を排除したとしても、1つの問題が残ります。デザインプロセスにおいて、ユーザーの参加する余地があまりにも少ない、ということです。

XPはイテレーションの採用により、ウォーターフォール手法で使用されるフェーズ構造を捨ててしまいました。
実装すべき要求が集められ、クオリティを最優先するための最小限のドキュメントが作られます。

ケント・ベックがXPを考えた時、本当のエンドユーザーは心の中にいました。開発チームはエンドユーザーに対して直接責任を負うべきであると信じていました。

残念ながら、全てのXPのプロジェクトがこの考えに従ったわけではありません。
多種多様なエンドユーザーを想定した壮大な計画は、要求分析の中で1つのユーザーとしてまとめられてしまい、その結果としてエンドユーザーがXPの中で詳細を決定することができなくなるという事態を招くことになりました。
XPには数々の優位性がありますが、新たな問題が発生してきました。エンドユーザーはXPの多様性と詳細性の中で、主張することができなくなっていったのです。

XPとUCDの融合にあたって、意思決定をどこで行うのかは大きな課題です。
多くのUCDツールでは、製品の最終的な形は要求定義書の中にあるとしています。これは実際のコーディングの前に作成され、エンドユーザーの分析の元に作られています。
XPの場合は逆です。イテレーションが始まる毎に議論が行われます。XPにおいて、意思決定はプロジェクトが完成するまで続きます。要求定義も同様です。

多くのケースにおいて、インタラクションデザインはUCDと同義に扱われます。アラン・クーパーとの議論の中で、ケント・ベックはインタラクションデザイナーがボトルネックになることを指摘しました。早期の要件収集とデザイン段階をXPに加えるかわりに、XPのプラクティスを利用することで、インタラクションデザインはよりパワフルになるであろうと考えました。

ニールセンは、ペルソナ法を利用する時の主な弊害として、コードを書くにはあまりにもペルソナの設定が貧弱であることを発表しました。

アンティ・ハチネン(Antti J. Ha¨tinen)は、ユーザーの目標設定をXPのユーザーストーリーの中に組み込んでしまうということを提案しました。これは「GO-XPメソッド」と呼ばれます。これは「GUIDe(Goal Oriented User Interface Design)」とXPを融合させようと試みるメソッドです。後に、この方法はうまくいかないことがわかりました。ユーザーの目標をデザイン上の問題としてプログラマーに提示するにあたって、ユーザーインターフェースとソフトウェアの構造に衝突が起こるようになってきたのです。プログラマーはインターフェースの問題とソフトウェア構造の問題を分けて理解することができませんでした。
このことは私が早期に提示していた、XPとHTAのタスクを融合させることを諦める理由となりえました。ハチネンは、ユーザーインターフェースとスケッチはXPのイテレーション計画が廻り始める前に完成するべきであると述べています。

4.　XPとUCDの協和と不協和

両者の類似点を無理に探さなくても、類似点はいくつか存在します。
その類似性によって、XPとUCDを1つにまとめることができるでしょう。UCDツールがXPに最適であることを理解するために、メリットおよびデメリットを比較してみましょう。

4.1　使用範囲

UCDが組織化された情報システムのデザイン作成を焦点にしているのに対し、XPは開発するプログラムそのものを焦点にしています。
2つのメソッドの組み合わせは、XPの視野をより拡げ、顧客の考えることが正しいという以上の結果を与えてくれるでしょう。

XPとUCDは、特定のデザインタスクを実行するための道具です。双方ともに特定のタスクを遂行する道筋を持っています。
XPにはそれらに加えて、従うべきルールまでもが設定されています。UCDはその名前のとおり、デザインのみを焦点にしており、一方でXPは、デザインとタスク計画に集中しています。
UCDツールはそれゆえXPに組み込むのに適しています。

4.2　ドキュメンテーション

XPは、包括的なドキュメントよりも実際に動作するソフトウェアを重要視します。それゆえXPでは、機能要求が変わったからといって大量のドキュメントがアップデートされ続けるのを嫌います。UCDツールは機能要求をまとめるために使われ、結果としてドキュメントができ上がります。

XPをアジャイルな開発手法であり続けさせるためには、実装が始まる前の予備タスクにかかる時間をできるだけ短くすることが重要です。よってXPの進捗サイクルの中でのUCDツールの役割は、機能要求の変更毎にドキュメントの山を築くことではなく、意思決定をガイドすることです。

XPの中に組み込まれるUCDツールは、どれだけのドキュメントを生成することができるか、頻繁に更新できるかと同様に、ユーザーの情報をどれだけ多く集めることができるかという能力を元に選定されるべきです。

ドキュメントを最小限に留めるということはドキュメントが要らないという意味ではなく、別の形態で作成するということでもありません。ドキュメントは主にクライアント用のものです。
クライアントは、XP開発チームと合流する前に、開発するシステムが何をするものなのか、開発に100万ドルをかける必要のあるものなのかを決めておかなければなりません。
XPは、インプリメンテーションと呼ばれるフェーズからスタートします。開発がスタートする前に、クライアント側で行うべき予備調査のことです。

これまでのシステム開発のメソッドに反して、XPはクライアントのアイディアをカード以外のものに書き留めることを拒絶します。紙のドキュメントをコレクションする代わりに、クライアントはゲームに巻き込まれ、生きたドキュメントとして振る舞うようになります。
クライアントの知識こそがドキュメントなのであり、意思決定を下す人でもあるのです。

4.3 プロトタイピング

XPのバックボーンは、短いイテレーションの中で有用なソフトウェアの形を膨らませて作ることです。
このアプローチ方法の強みは、将来の開発に対する素早いフィードバックが可能なことです。これはデザインに反映させる点でプロトタイピングにおいても対象になります。

フロイド(FLOYD)はプロトタイピングを大きく3つに分けました。
・調査のためのプロトタイピング
・実験のためのプロトタイピング
・進化のためのプロトタイピング
後者の特徴は、ウォーターフォール式の開発手法で分けられていたパーツを、フィードバックに優先順位を付け、検討し、変わりゆく機能要求をうまくやりくりしながら、開発サイクルに再配置することです。
先進的なプロトタイピングにおいては、実際に動くソフトウェアが作られ、バージョンで区別されます。フロイド(FLOYD)はどんな形態のプロトタイピングであれ「システム開発全体の中で他の機能と結びつく1つの手続きとなるべきである」と論じています。

XPは先進的なプロトタイピングを使用する開発メソッドですが、他の作業とも結びつきます。開発サイクルの中でXPは調査用のプロトタイプを「スパイク」と呼びます。スパイクは技術上、デザイン上の問題の解決法を調査するのに使われます。

XPが向き合わなければいけない問題点は「リスク」です。プロトタイプを使用することは、実装前に解決法を発見しリスクをコントロールするために非常に有効です。
プロトタイピングがXP開発のルールの中にある限りは、開発サイクルの中の適切な場所において利用することを強く薦めます。

4.4 ペルソナ

ペルソナ法は、XPの中でユーザーを代表する手法として利用できます。
システムの特徴についてどうあるべきかを決めたり、実装機能の優先順位を決めたりするのに役立ちます。
XPのストーリーには特徴が書かれており、ペルソナとXPの協調の効果は明らかです。

プログラマーと意思決定者は、ペルソナが起こす行動を理解するために協力します。これがXPメソッドの持つユーザー視点の欠如を埋めるのに役立つのです。

ペルソナ法では、ターゲットユーザーグループのフィールドスタディを利用します。
フィールドスタディは、完璧にやるとXPの1イテレーション以上の時間がかかってしまいます。よってXPのイテレーションの中に含めるべきではなく、事前に行うべきです。

ペルソナは、ユーザーについての初期フィールドスタディの結果生まれるドキュメントです。
アジャイル開発では大量のドキュメントを嫌いますが、これはドキュメントを最新の状態にするのに大量の時間と労力を必要とするからです。
よって、アジャイル開発で生まれるペルソナもまた、多くの時間をかけるべきではありません。1つの解決法としては、想定されたペルソナからランダムに架空のメールをプログラマーに送ったりすることがあげられます。
ペルソナは架空の人物であり、リアルなフィードバックとはなり得ませんので注意が必要です。

4.5　シナリオ

シナリオ法、はペルソナと同様にストーリー上の基礎として利用され、ペルソナが何を重要と考えているかを発見するのに役立ちます。

シナリオによって導き出された特徴は、ペルソナ法にが導き出した特徴のうち、本当に重要なものが何かを考えるヒントになります。

シナリオ法には様々なタイプがあり、異なる目的のために用いられます。あるタイプでは、既に作られたペルソナをもとにして、そのペルソナ人格がシステムとどのように接触していくのかを述べます。
このタイプでは、必要な要件を集め、ペルソナにとってより良いシステムをデザインするようにするために用いられます。

XPの一部として用いられる別のタイプのシナリオ法としては、ソフトウェアが既に要求をかなえているものとしてテストを行う方法があります。
これら2つのシナリオ法は完全に違うものとして作られています。UCDとXPを用いたシナリオ法を融合させる時、この定義の違いがもたらすデメリットについて注意する必要があります。

4.6　文化調査

プロジェクトについて初期の包括的なアイディアを持っていない場合、文化調査法はインスピレーションを得るのに役立ちます。
このメソッドは、新しいアイディアのインスピレーションを得るための予備的な調査だといえます。

他の手段として、文化調査法は、新しいイテレーションがスタートする時に、ユーザーの新しい情報を集める際にも使われます。

文化調査法は、調査と分析のために多くの時間がかかります。よってXPのイテレーションの中に含めるべきではありません。文化調査法はターゲットユーザーグループのインスピレーションを調査するのに用いられ、それによって、ペルソナを作りあげるためのフィールドスタディの一部として有効に働くのです。

文化調査法は、新しいリリースがスタートする時に、ユーザーについての情報を集めインスピレーションを得るのに使われますが、ソフトウェアの開発中に文化調査を行えば、より直接的な質問事項を作り、良い解決策を導くことができます。
この点から、文化調査は1フェーズとして存在するのではなく、必要に応じて行われるツールとして考えた方がよいでしょう。

3つ目の方法として、開発が始まる前に、文化調査の成果物をできたものから送る方法があります。まとまった成果物でなくても、新しい情報を入手したその場から小さなインスピレーションを得ることができるのです。

(※次回エントリーに続く)