アジャイル開発に基づきプロジェクトを始めるとき、Lean UXは役立つテクニックです。伝統的なUXのテクニックは、開発スピードが速い場合はあまり機能しないでしょう。今までと同じようにしていたのでは、UXについて考える十分な時間はありません。
Lean UXを含めたUXの実践論は、素晴らしいユーザー体験を届けるという同じゴールを持っていますが、Lean UXの場合、プロジェクトへの取り組み方が少し違ってきます。どのように違っているのか見ていきましょう。
Lean UXとは？
Lean UXは、デザインによるユーザー体験を重視しており、伝統的なUXに比べると成果物はあまり重視していません。また、Lean UXでは、チーム全体とのコラボレーションが高いレベルで求められます。コアとなる目的は、できるだけ早い段階でフィードバックを得ることです。これによって、決断を素早く下すことができます。
アジャイル開発の原理は、イテレーションと呼ばれるサイクルを素早く回すことであり、Lean UXはこのサイクルを真似ることで、取得したデータを各イテレーションで改善に使うことを可能にしています。
Author/Copyright holder: Vimeo. Copyright terms and licence: Public Domain
仮定（assumption）が必要
伝統的なUXでは、要件と成果物を土台にしてプロジェクトが実行されます。プロジェクトの目的は、可能な限り詳細な成果物を作り、プロジェクトの要件に対し十分に答えることです。
一方、Lean UXは若干異なっています。詳細な成果物にはフォーカスせず、すぐに製品を改善できるような変更を行います。つまり、詳細な成果物ではなく、より良い結果につながる成果物を求めるということです。
Lean UXでは、「要件」を一旦置いておき、「課題」を明確化することが大事です。課題を明確化することで、仮説（hypothesis）を導くための仮定（assumption）を生み出すことができます。
編注：仮説（hypothesis）は調査・経験から導き出されるものであり、仮定（assumption）は感覚から導き出されるもの。
仮定は、誰もが思いつくようなアイデアの中から共通の理解を生み出すものです。
では、仮定とは何でしょうか？ 仮定は、私たちが正しいと考えていることです。そして、仮定は、誰もが思いつくようなアイデアの中から共通の理解を生み出すものです。仮定は正しくないかもしれないし、プロジェクトの途中でより正しい理解がチーム内で生まれれば変更されるかもしれません。
多くの場合、仮定はワークショップで生み出されます。チーム全員で問題を述べ、その問題を解決するために、チームでブレインストーミングをするのです。このプロセスでは、仮定の前提となった質問に対する回答を見つけ出します。
典型的な質問は:
- ユーザーは誰か？
- その製品は何のために使われるのか？
- いつ使われるのか？
- どんな状況で使われるのか？
- 機能的に１番大事なことは何か？
- 製品を届けるための１番のリスクは何か？
各質問に対して１つ以上の答えがあるかもしれません。そして、対応できる数以上の仮定が残ってしまうこともあるでしょう。そのような場合、先程の質問への回答に従って、素早く仮定の優先順位を付けることができます。
リスクによって優先順位を付けるかもしれないでしょう（仮定が間違っている場合、どのような結果になるでしょう？ 考えられる結果がシビアであるほど優先順位も高くなります）。また、問題への理解のレベルによるかもしれません（理解できていないほど優先順位が高くなる）。
Author/Copyright holder: visualpun.ch. Copyright terms and licence: CC BY-SA 2.0
仮説（hypothesis）を作る
Lean UXで作られる仮説は、仮定をテストするためのものです。Lean UXでは、仮説を素早く簡単に作れるフォーマットがあります。
仮説の例：私たちはどんなときでも作業の進捗を保存できることが、スマートフォンのユーザーにとって必要不可欠だと信じています。この機能によって、より高い登録完了率を達成できるでしょう。現在の登録完了率20%から改善されたとき、この仮説を証明することができます。
このフォーマットでは、信じていること、それが重要な理由、誰にとって重要なのかを述べます。そして、達成できると期待されることに続いていきます。最後に、自分たちが信じているものが本当だと証明するため、どんな証拠を集めればいいのか判断します。
仮説を証明する方法がないという場合は、結果がはっきりと定義されていないため、間違った方向に進んでいる可能性があります。
このように進めることの大きな利点は、「私はそれは良いアイデアだとは思わない」という考えや、内輪揉めを取り除くことができる点です。どのアイデアもテストされ、検証の基準は明確に決められます。アイデアの根拠がない場合は？ その場合は、そのアイデアをまず置いてほかのものに移るべきでしょう。
誰もが仮説と仮説をもとにした予測を理解できるなら、主観的な見解について一生懸命討論することはなくなり、その仮説が正しいかどうか検証することを楽しみにするようになるでしょう。
実用最小限の製品（MVP）
実用最小限の製品（MVP：Minimum Viable Product）はLean UXのコアとなるコンセプトです。これは、可能な限りもっとも基本的なコンセプトを反映した製品を作り、テストをして、もし価値のある結果がなければ破棄するという考え方です。価値があることを示したMVPは、デザインや開発にあまり苦労せずに組み込むことができるでしょう。
これはリソースを最大化するのにとても良い方法で、アジャイル開発でうまく機能します。思い込みに陥らずに、何度も実験をすることができるのです。
ユーザーリサーチとテスト
ユーザーリサーチとテストは、伝統的なUXで使われるのと同じ原則に基づいています。アプローチは、「Quick and Dirty」になる傾向があり、結果は次のアジャイル開発におけるスプリントが始まる前に届けられなければいけません。そのため、結果をまとめた書類を丁寧に作るのではなく、生のデータにフォーカスするべきです。
リサーチは、チーム全体で行うことが多いです。そのため、タイトなスケジュール内ですべての仕事を終わらせようとするものの、ひとつのUXデザインのリソースがボトルネックになってしまい、プロジェクトが進まないということはありません。さらに、これは開発チームがUXに関わることにも繋がり、開発チーム内でのUXへの理解を高め、彼らからのサポートを得ることができるようになります。
まとめ
この記事では、Lean UXについての概要を述べました。もちろん、Lean UXにはこの短い記事でカバーできる以上のものが多くあります。しかし、Lean UXをアジャイル開発に導入するときに、今回紹介した基本的なコンセプトがあれば正しい方向へ進んでいくことができるでしょう。
