前回から約半年。
今回は4期生の方々を対象に MOVIDA Japan 様主催もと、LeanUX Workshop（リーン・ユーザエクスペリエンス・ワークショップ）を開催しました。第2回目となる今回は前回の約2倍、計20社から50名以上の方にご参加いただきました。
前回はユーザエクスペリエンスや人間中心設計のコンセプトを基軸にワークショップを展開していきましたが、今回は Lean Startup（リーンスタートアップ）の根底にある考え方をベースにデザイン思考とアジャイル開発という2つの概念を基盤とした LeanUX を4つのステップにまとめてワークショップを進めました。
LeanUX の3つの基本原則
- Collaborative, Transparent, and Demystify （コラボレーション、透明性、そして解明）
LeanUX ではコラボレーションと部門や領域横断的な仕事の進め方が極めて重要です。デザイナーやエンジニアはもうチームから独立して働く贅沢は許されなくなります。すべてを決めるまで、またはすべてが出来上がるまで、チームを待たせておくこともできません。効果的に仕事を進めるためにはチームと日々、継続的に関わることが重要だと考えます。結果として情報伝達のための膨大な資料づくりを不要にします。
- Documents don't solve customer solutions（ドキュメントは何も解決しない）
ドキュメントは思考ではありません。思考の結果として記録されるものであり、かつ思考を共有するためのものです。LeanUX では何を創るか（機能や文書、機能など）ではなく、何が効果的かにフォーカスして議論する機会を増やします。結果として客観的なビジネスゴールを念頭に置きながら、その枠組のなかでデザインについて議論ができるようになります。何が機能しているかを把握し、学び、調整をしながら、デザインを進められるようになるので議論の無駄を省きます。
- Building the right 'it' before build 'it' right（正しくモノをつくるよりも正しいモノをつくる）
ワークショップの形式上、どうしてもステップごとの進行になってしまいますが、プロセス依存は避けるべきです。LeanUX を極めることではなく、よりよりサービスやプロダクトを創ることが本来の目的だと思います。LeanUX はどの会社でも、サービスでも上手く行く保証はありません。これらの LeanUX の基本原則は所詮ツールです。ただ、より良いサービスやプロダクトを創る上で参考となるツールとして、引き出しに閉まっておいてください。
LeanUX を実践する4つのステップ
- Vision, Framing, Outcome（ビジョンと構想）
プロジェクトのあらゆる側面に注意を向け、前提（課題とユーザ定義）を明らかにすること。LeanUX では優先順位付けを徹底的に行います。すべての前提を評価することは物理的に困難であると認識した上で、最初に評価すべき項目や指標を決めるには前提リストをマッピングし、リクスのレベル（つまり、もしその認識が間違っていた場合、どれほどの悪影響が生じるか）と、課題についてのチームの理解度に基づき、前提に優先度をつけます。
- Collaborative Design（共創）
全員からユーザと利用ストーリーに関する前提を得られるようにすること。LeanUX では、ペルソナ作成の順番を変えています。まず前提を明らかにすることから始め、次にその前提を実証するためにリサーチを行います。現場で何ヶ月もかけて人々にインタビューする代わりに、ペルソナの原型である「プロトペルソナ」と利用ストーリーを描いて「ストーリーボード」を1時間程度で作成します。
- MVPs and Experiement（MVP の実験）
前提を評価し、投資する価値のある機能を早期段階で明らかにすること。LeanUX では MVP の概念を頻繁に使用します。MVP は、前提の評価に役立つと同時に、証明されていないアイディアに投じる労力を最小限に抑えます。優先順位をつけた仮説のリストから、探索すべきいくつかの経路を導き、有効性を判断するために最小限実用性のあるサービスやプロダクトを作成します。
- Feedback and Research（フィードバックと調査）
ユーザと共同で行うリサーチは、UX デザインアプローチの核心です。しかし、あまりにも多くの会社が専門的なリサーチ・チームにリサーチを外注しています。そして、あまりにも多くのリサーチ活動は、プロジェクトの開始時か終了時に、希に実施されるだけです。LeanUX は、継続的かつコラボレーティブにリサーチを行うことで、このようなアプローチから生じる問題を解決します。今回は時間の関係上、リサーチと評価までは進めなかったのですが、プロトタイピング・メソッドやリサーチ手法をご紹介しました。
丸々1日を費やしたワークショップの最後には、数チームに前提の課題と想定するユーザ、そして利用シーン及びストーリーマッピングから得られたユーザ要求を参考に特定した自社サービスないしはプロダクトの MVP を発表してもらいました。正しい・間違っているなどの批評はしません。それを判断するのはユーザであり、詳細であれば良い、というわけでもありません。抽象的であればあるほど、探求できる余地が存在しているので、むしろチャンスだと思います。悩む時間が無駄だと感じたら、ぜひユーザに問いかけてみてください。
最後に、LeanUX Workshop で最も伝えたかったこと。
- スケールしないものへの投資
サービスのすべてを外に明かすことに戸惑いを感じている人は多いと思います。新しくローンチした新機能や追加機能のお知らせなど、自身のサービスの「今」を発信しているケースが多く見られますが、果たしてそれは顧客にとって有益な情報でしょうか？機能に魅力を感じてもらうことはスケーラビリティ上大切なことではありますが、初期段階においてはサービス・ビジョンのようなスケールしないサービスの側面に共感を覚えてもらうことが重要だと考えます。一時的なユーザよりも長期的にサービスの未来を共に形成していける潜在的なユーザこそ、自社サービスないしはプロダクトに有益な情報を与えてくれると思います。 - 問題解決よりも問題発見
仕事の大部分は問題解決だと思いますが、問題の発見を忘れてはいけないと思います。良い問いはよい答えよりも重要なときがあります。なぜ、ユーザはこの機能を求めているのか？この問いを確認することなくソリューション・ドリブンで問題解決に走ってしまうことがあると思いますが、時には特定の機能を開発することなく問題を解決することもできます。 - データ解析はチームの仕事
定量、定性問わずユーザからのフィードバックにチーム全員がアクセスすることはできますでしょうか？データは顧客満足度を図る一種のメカニズムではなく、ビジネスをドライブさせるためのエンジンです。リサーチャーやアナリストなどの専門職にすべてを任せるのではなく、それぞれの観点からデータを解析して人数分得られた洞察を交換することで新たな発見が生まれます。
再掲しますが、ワークショップの形式上、どうしてもステップごとの進行になってしまいましたが、プロセス依存は避けるべきです。LeanUX を極めることではなく、よりよりサービスやプロダクトを創ることが本来の目的だと思います。LeanUX はどの会社でも、サービスでも上手く行く保証はありません。これらの LeanUX の基本原則は所詮ツールです。ただ、より良いサービスやプロダクトを創る上で参考となるツールとして、引き出しに閉まっておいていただけると嬉しいです。
「使いやすい」サービスよりも「使える」サービスへ。
Useful first, Usable later.
関連記事：
