Lean UXでは、機能をリリースしたこと自体を成功とみなす前に、その機能によって何が変わるのかを明確にすることがチームに求められます。たとえば、ダッシュボードが完成したとしても、顧客が求めていた意思決定を実際に行えるようになったかどうかはわかりません。それを知るには、課題の解像度を上げ、ユーザー体験についての確かな材料を集める必要があります。

Jeff GothelfとJosh Seidenが提唱するこのアプローチは、デザイン、リサーチ、プロダクト、エンジニアリングを巻き込み、チーム全員で学びを深めていくプロセスです。GothelfのLean UX Canvasは、ビジネス課題や前提条件を仮説や実験へと落とし込みます。その実践的な意義は、これから取ろうとしている行動が本当に正しいのか、客観的に検証できるようにする点にあります。

意思決定を左右する前提条件を見つけ出す

たとえば、経費の自動分類機能を計画しているチームを考えてみましょう。このチームは、「手動での分類が大きな負担になっている」「提案される分類の精度が十分である」「従業員がその提案を信頼する」と思い込んでいるかもしれません。しかし、これらは性質の異なる不確実性であり、それぞれ別の検証方法が必要です。

ユーザーインタビューを行えば、直近の経費精算の手続きやそれに伴う作業の実態を探ることができます。プロトタイプを使えば、提示された分類をユーザーが理解できるか、必要に応じて修正できるかを確かめられます。また、分類自体の精度を評価するには技術的な検証が欠かせません。これら3つをすべて「検証（バリデーション）」とひと括りにしてしまうと、何をテストできていて、何がまだ不確実なままなのかが見えなくなってしまいます。

次のアクションを決める際は、「仮説が外れた際のリスクの大きさ」と「すでに手元にある材料の確からしさ」の両方を考慮してください。核心となる前提条件に手をつけないまま、些細なポイントについて手軽なテストを重ねても、ほとんど意味はありません。

役立つ範囲で最小限のテストを組み立てる

「小さいテスト」とは、決して手抜きをしていいという意味ではありません。プロトタイプテストであっても、適切な対象者の選定、リアリティのあるコンテンツ、そして答えを誘導しないタスク設計が欠かせません。完了率の変化を測定する実験なら、筋の通った比較対象と、判断に足る十分なサンプル数が必要です。

結果を見る前に、「どうなったら継続し、見直し、あるいは断念するのか」という基準をあらかじめ言語化しておきましょう。その基準は定性的なものでも定量的なものでも構いません。プロダクトの仮説だからといって、必ずしも統計的な有意差検定が必要なわけではないのです。Ballparkのコンセプトテストを活用すれば、実際に動くプロダクトを開発する前であっても、想定している体験をすばやく検証できます。

チーム全体で学びを共有・蓄積する

Lean UXは無駄なドキュメント作成を減らしますが、価値のある記録まで省くわけではありません。将来加わるメンバーのためにも、どのバージョンをテストしたのか、誰が参加したのか、何が観察され、なぜその次のステップを選んだのかを残しておく必要があります。簡潔な意思決定ログがあれば、毎回大がかりなレポートを作成しなくても、十分に必要な情報を残せます。

また、このアプローチが機能するかどうかは、検証結果に応じて方向転換できる余地があるかにかかっています。リサーチの結果にかかわらず機能や納期が完全に固定されているなら、リサーチが成果に貢献することはほぼありません。テストそのものを設計することと同じくらい、結果を受けて計画をどう見直すかをチームで合意しておくことも大切な仕事です。