先月の Agile 2011 Conference の報告のシリーズを EnterpriseZine で連載させていただきました。この日記では Agile UX 番外編として２つほど紹介してみます。
UXを用いた製品の要件定義に関するセッションを２つ紹介
アジャイル開発では、顧客や利用者との頻繁なコミュニケーションを重視します。実際に動くソフトウェアやプロトタイプをなるべく早い段階で提供し、手遅れになる前に見当違いを修正し、潜在的なニーズを少しでも汲み取ることを目指します
Agile 2011 Conferenceでは、利用者を観察し彼らとの共同作業を学ぶための場として「User Experience＆Interaction Design（ユーザエクスペリエンス＆インタラクションデザイン）」と「Working with Customers（顧客との協同作業）」の2つのトラックが用意され、実践的ワークショップが行われました。本記事では「アジャイルUX（ユーザエクスペリエンス）」に関連するセッションを2つ紹介します。
前回はジェフ・パットン氏のセッションを紹介しました。今回はデヴィッド・ハスマンさんとティム・マッコイさんのセッションを紹介します。
最新のリーンUXプロセスを体感するチュートリアル
次に紹介するのは、インタラクションデザイナー Tim McCoy氏と アジャイルコーチ David Hussman氏による、デザイナーとシステム開発者が一緒になって製品を開発する手法を教えるチュートリアルです。セッションの概要には以下のように書かれています。
このセッションでは、インタラクションデザイナー Tim McCoy と アジャイルコーチ David Hussman が新しい仕事のやり方を紹介する。Integrated Product Design は、デザインスキルとアジャイルなデリバリーを結合する。企業での実体験に基づき、イテレーティブに本質的価値とコンテキストを描き出す、密に統合されたプロセスだ。ゴール駆動のデザイン思考は、イテレーティブな開発の前工程や開発期間中に役立つ。リッチなユーザエクスペリエンスをもつ製品を開発し、タイムリーに提供するためのツールについて紹介する。参加者の要望があれば立ち止まって、さらに詳細に説明する
リーンスタートアップのキーワード「ピボット」
このセッションで行うことは主に3つ。顧客やニーズを発見する「デザイン」、顧客に価値を届ける「ビルド」、顧客からの反応／フィードバックを得て学習し方向を修正する「ピボット」です。
ピボットとは、最近話題になっている「リーンスタートアップ」という概念で提唱されているもので、顧客や市場のフィードバックを得て、当初の目標や思惑よりももっとよい市場を見つけた場合は、ゴールを修正しよう、という概念です。バスケットボールのピボットターンからきています。
例えば、Twitterを開発したOdeo社は、当初、全く別の事業（Podcast）をしているスタートアップ企業でした。Twitterは社員の発案で作られ、まず自分たち自身が熱狂的な利用者になりました。おそらく始めから大規模なユーザを想定してなかったため、急速な利用者集の拡大にシステム対応ついて行けない時期もありましたが、現在は社会的インフラの一つ、といってもいいほど普及しています。当初のPodcastビジネスに執着していたら、現在の成功は難しかったでしょう。
リーンUXは、リーンスタートアップに対応した軽量版UX手法群
リーンスタートアップに適応したユーザエクスペリエンス(UX)の手法群の組み合わせを「リーンUX」と呼びます。利用されている各手法は、UXがユーザ中心設計(UCD)と呼ばれていた頃から、大きくは変化していませんが、利用できる時間や人的資源が小さくなったことに対応して、極限まで手法を絞っているのが特徴です。
基本的な手順は以下の通りです。
- 手順1: 製品憲章で、「何を作るべきか」を見える化する
- 手順2: プラグマティック・ペルソナ法で、「顧客像」を見える化する
- 手順3: ユーザーストーリーマップで、「製品像」を見える化する
- 手順4: バックログで、「開発の優先順位」を見える化する
- 手順5: 顧客のフィードバックを受けて、方向転換の必要性を見極める
この手順ごとに、セッションは進んでいきます。
手順1. 開発者とデザイナの混成チームで、製品憲章を作る
この工程は、開発者とデザイナが同居する小規模チームを想定しています。そのチームで、まず「なにを作るべきか」を議論し、製品憲章を作ります。 製品憲章では、考えられる制約事項を確認します。
今回のチュートリアルで用意された例題プロジェクトでは、宇宙旅行のチケット支援システムはまだ宇宙船ができていないことが問題ですし、医療システムでは、対象となる医療機器がまだ完成しておらず、テストはエミュレーションで行う必要がある、ということが制約事項でした。（なんでそんな状況なのに製品を作ろうとするのか、ちょっと理解に苦しむところですが、実際に筆者の属していたチームでは宇宙旅行のケースを選択していました。）
手順2. プラグマティック・ペルソナ法で、利用者の具体的なストーリーを引き出す
ペルソナ法はアラン・クーパー氏が「コンピュータは難しすぎて使えない！」「About Face 3」という著作で業界に広めたものです（ちなみに Tim氏は最近までクーパー氏の会社Cooper Inc.で働いていました。）
人々の物語を語る「ストーリーテリング」という手法が注目されています。どういう人が使うのか、どうして使いたいのか、ストーリーを口語体で語ることで、生々しい利用者像を共有し、製品を作る際にチームメンバー自身の中で発生する膨大で細かな意思決定を行いやすくし、チームメンバー間での判断の食い違いや議論のすれ違いの発生を防ぐことを狙っています。
ペルソナは、膨大な利用者データを解析して作成する「データ駆動ペルソナ」が主流でしたが、「プラグマティック・ペルソナ」はデータの代わりに、チームメンバー自身の利用者理解に基づいて作成するのが特徴です。データを用いないので、チームメンバーの利用者理解が不足していると、実際の利用者との乖離が発生する不確実性がありますが、そのかわり大きなコストを使わず合意を視覚化できることがメリットです。
プラグマティック・ペルソナは以下の4つの項目を書き出します。
- 名前
- 肖像
- 説明
- 価値
名前は、業種などからダジャレで作成すると覚えやすいです。この例では「キャッシャー担当のキャシー」という名前をつけました。肖像は、手書きでその人を表す絵を描きます。絵が上手である必要はありません。説明は、その人がどのような状況で働いていて、何に困っているか。価値は、どういうことができたらうれしいと感じるか、を列挙していきます。
手順3. ユーザーストーリーマッピングで製品の全体像を明らかにする
次は Jeff Pattonさん のセッションでも紹介されたユーザーストーリーマッピングを作っていきます。ストーリーの形式（テンプレート）は前述の通りです。
○○○として（ As ○○○ ）
○○○をしたい（ I want ○○○ ）
その結果、○○○になる。（ So that ○○○ ）
いきなりこのユーザーストーリーのテンプレートに従って書き始めると、コンテキストを無視したさみだれ式のユーザーストーリー群が出来上がってしまうため、そのまえにシナリオや物語の描き出しを行います。
まず、ある一つの利用者ペルソナの短期的な目標と行動を表す「シナリオ」を書き、そのシナリオを取り囲む一日の行動を確認していきます。そこまで具体化した後で、他の可能性や他のペルソナについても議論するようにします。人の視点と鳥の視点と往復するような感じです。
一度に両方の視点でごちゃごちゃに議論するのではなく、丁寧に視点を切り替えて描き出していくことが大事です。
次に、利用者ペルソナごとのシナリオを分割し、そのワークフローに従ってストーリーを書き、2次元のストーリーマップを作っていきます。
ここまでで、開発に入る準備がほぼ完了です。 もちろん、開発に入るにあたっては、リリースのためのデリバリー機構など、技術的なチェックリストを明らかにし、準備をする必要があります。
手順4. 開発工程は2つのタスクボードで管理して、優先度順にリリース
開発に入ったら、ユーザストーリマップに加え、タスクボードを用いて進捗を管理します。
タスクボードは開発タスクを4つの状態遷移で管理します。
ユーザーストーリーマップのうちの最優先のストーリーのいくつかをタスクボード（=バックログ）に転記し、アジャイルなプロセスで開発を行っていきます。タスクボード上で完了したストーリーは、ユーザーストーリーマップ上でもシールを貼って「完了」を表します。
完了の基準のなかに、ユーザーストーリーに書かれた内容を実現できているかを確認する「ストーリーテスト」を行うこともお勧めされていました。
手順5. フィードバックを受けて、方向を転換する「ピボット」
アジャイル開発によって製品がリリースできたら、利用者のフィードバックを受けて、製品の有効性や市場を分析し、必要であればゴールを修正し方向性を転換します。これがピボットです。
製品に関するアイデアというのはいわば仮説ですので、実際に開発された製品を使ってそれを実証実験することが可能になります。その結果を受けて、さらに仮説を修正し、よりよい製品をめざしていくわけです。
以上、ここまでで180分のチュートリアルが終了です。全てをお伝えするのは難しいですが、雰囲気とエッセンスが皆さんに伝われば幸いです。なお、アジャイルUXの基本概念については樽本徹也さんと共著の記事「アジャイルUXの潮流〜米国発アジャイル開発の新しい波、只今日本に接近中!」で解説していますので、ぜひご参照ください。
