天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます

「Lean UX でまわす、まわるプロダクト開発」 - Forkwell Library #6に参加してきた

forkwell.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

これまで Forkwell のイベントで登壇されたエキスパートの方々は、先達が記した書籍から「気づき」を得て実践し、振り返り、再現性のある「学び」として身に付けていく中で、実績を築いてこられました。

しかし、日々限られた時間の中で知識や情報をアップデートし続けるのはそう簡単ではありません。 Forkwell Library では、著者・訳者・実践者らを登壇者として招き、そんな思いを抱えた開発者の皆さまが「学びのきっかけ」を得られる勉強会を目指します。

今回の第6回目では2022年8月29日に出版の最新版『Lean UX(第3版)』を取り上げます。監訳者である坂田 一倫 氏をお招きしてプロトタイプを使った仮説の検証、MVPの構築、さらにユーザーからのフィードバックを効率的に得る方法などをお伺いしていきます。

会の様子

基調講演〜Lean UX でまわす、まわるプロダクト開発〜

Lean UXとは?

はじめにLean UXの定義について簡単な紹介がありました。
乱暴に言ってしまうと、デザイン思考とアジャイル開発、リーンスタートアップを統合させたプロダクト開発手法だというお話でした。

リーンスタートアップの3つの特徴
  • 無駄をなくす(価値のないドキュメンテーション、いわゆる中間成果物を作成する時間を排除する)
  • 継続的に会話する(プロダクトに関わる多数のメンバーから情報を多種多様な観点から集約する。所謂COEの話)
  • 学習量を増やす(プロトタイプによる検証期間を短縮することで、不確実性の高い要素を優先的に明らかにしていくこと)

の3つが特徴として定義されていました。

Lean UXのプロセス

第三版にはあまり説明がないというLean UXのプロセスについて説明がありました。(第三版は第二版に書かれていたプロセスが組み込まれていることを前提として、よりツールの説明に踏み込んでいる)

具体的には、思い込みや仮説→デザイン→MVPの構築→リサーチと学習→思い込みや仮説→...というループを回すことが前提になっているという説明がなされていました。

Lean UX第3版の追加点

Lean UX第三版になってどのような記述が追加されたのか?というお話がありました。

  • Lean UXキャンバスの解説が細かくなった(Lean UXの導入ハードルを下げるために記述がよりロジカルになった)
  • アジャイル開発に対する言及(scrum.orgで講師をやっていることもあって知見がより溜まった)
  • OKRの解説
  • 成果主義に基づくロードマップ
Lean UXキャンバスをうまく活用する方法

続いて、Lean UXキャンバスを活用するために坂田さんが意識されているポイントの説明がありました。以下の4点が重要だということです。

  • 自分達はユーザーではないので、ユーザー視点を異なった形で捉えている可能性があることを理解する
  • Lean UXキャンバスを完璧に埋めようとは思わない。後から更新する
  • 仮説は現時点でわかっていることから始める
  • 変更を許容すること。学びを得るたびに都度見直す必要がある。
Lean UXを活用した事例紹介

事例紹介として、JR東日本アプリの「Go! by Train」の紹介がありました。*1
以下、具体的にやっていったことを時系列で書いていきます。

ユーザーの痛みの定義

  • 最短距離が上位結果に出てこない
  • 必ず発生する電車遅延について、具体的な分数がわからない(遅延していることしかわからない)

プロダクトディスカバリーフェーズ

  • プロトペルソナの作成(仮説を最小限の労力で検証できるアイデアを拡散し、ユーザの解像度を上げる。想定との差分を早めに洗い出す)
  • リスクの優先度づけ(得られた学びを記録する。必要に応じてソリューションのピボットを検討する)

プロダクトデリバリーフェーズ

  • 検証方法の洗い出し(PM, デザイナー, エンジニアなどのメンバーで最小限の労力で仮説を検証できる方法を考える)
  • 学習結果の反映(ユーザーからのフィードバックで得られた学びを確実に記録する)
Lean UXのメリット

こうしてLean UXでプロジェクトを回した結果感じられたメリットの紹介がありました。

  • ユーザー視点がチーム内で醸成される
  • 学びや成果が共有され、チームで主体性が生まれる
  • 次に検証すべき仮説が明確になり、プロセスが回る
  • 納得感を持った開発ができるので、自信につながる(エンジニア目線だと、意義があるものが作られるという確信がある)

が紹介されていました。

Lean UX第3版で重要なメッセージ

「アウトプットからアウトカム思考へ」というメッセージがLean UX第三版では一番重要なのではないか?というお話がありました。
ビジョンを実現するためにユーザーの行動がどのように変わっていくのが望ましいのか?を考えて共通言語とするのが重要だということです。

Jeff Gothelfからイベント参加者へのメッセージ

最後に、本イベントの開催に際してJeff Gothelfからイベント参加者向けにメッセージがありました。
以下、メッセージです。

We live in a world of continuous change built on top of software. The time where we could predict what to build, how to design it, and what people will do with it has passed. The tools we have today enable us to ship small ideas into the hands of our customers quickly, to sense how well those ideas meet the needs of our customers and to respond with improvements based on that learning and insight. Lean UX teaches you how to do that and how to integrate it with your software development practices.

Q&A

以下、寄せられていたQ&Aを常体で記載していきます。

Lean UXを組織に導入する良い方法はあるか?周囲の理解や承認を得る方法、実践する方法のそれぞれで紹介してほしい

まず4つの前提を自身で理解する必要がある。

  • 自分がなぜLean UXが良いか価値を理解できている
  • 価値が出せる、ではなく最高の価値が出せる状態を理解する
  • 自分の組織内での役割を理解する
  • 組織の成熟度を理解する

このことができた上で、プロダクトに関する理解ができていると、導入がスムーズにできるはず。

上の前提を考えるためには、自身や組織がどういうレベルにいるのか?を考えるときには、UX成熟度モデルを活用できる。

UX成熟度モデルのレベル1のような状態であれば、まずは本を読んでもらったりイベントに参加してもらうのが大事。(読書会...)
UX成熟度モデルのレベル2のような状態であれば、組織的に必要であるという理由をボトムアップで発信し、周りを巻き込んでいく動きが重要。(COEで同志を立ち上げたりクイックに実行してみる...)

また、究極の理想話になってしまうが、実践してきた人たちを経営層に組み込むことができれば最高。
経営層に組み込むことが自身の権限でできないなら、日々の課題感(例えば作っているものが使われていない...)を共有して支援をお願いすることがまずファーストアクションになるかと思う。

Lean UXを取り組む際に、PMとデザイナーはそれぞれどのような役割になるのか?本を読んでいくとPMは不要に思えた(類似質問で全員がデザイナーに思えたというお話も出ていました)

確かに役割のオーバーラップはある。

ただ、あくまでもグラデーションの話だと考えている。また、元々デザイナーだった人やPMが不要になることはないと思っている。
例えばPMならリスクの洗い出しなどは知見が豊富だし、PMがリードしていくようなことになるはず。デザイナーなら目に見える形で解決策を定義するはずだし、ユーザーリサーチやプロトタイプ作成のプランニングを主体的にファシリテーションしていくはず。エンジニアなら、実現可能性がどれくらいあるのかを考えることに責任を持つはず。

ミニウォーターフォールのように、お互いの仕事領域を決めてバケツリレーするということがないようにすることは重要。

プロダクト開発に限らず、システムインテグレーション的なシステム開発でもLean UXは活用できるのか?

会社の規約とかをわからない状態で話してしまうが、活用はできると思う。
それぞれの役割をお互いに理解できていれば、どこで決定権をお互いに持つのか?を決めつつオーバーラップすることができる

ただこの場合は、プロジェクトキックオフの重要性はめちゃくちゃ出てくる。

良いユーザーストーリーの書き方を教えてほしい(価値よりも機能を書いてしまう)

まず動詞に直してみるのが重要。また、単に「〜したい」というのではなく、検証するときにどういう状態になっているか?(=どういうアウトカムが生まれるのか)を明確に定義する必要がある。

Lean UXの第3版でも色々なユーザーストーリーの書き方が記載されているので参考にしてほしい。

Lean UXキャンバスを更新し続けるコツはあるか?

更新し続けることにフォーカスを向けるのではなく、学びが少ないのではないか?という部分に目を向けてみると良いかもしれない。
学びが多いと更新が間に合わないくらいになっていく。

学びを得るためには、やはり同じテーブルにチームメンバーが集まることが重要。

また、もし学びはすごいんだけど更新を忘れてしまうという場合、チーム全員が目に見えるような場所に貼っておくなどして、更新を定期的にしたくなるような仕組みを作ることが重要だと思っている。

プロトタイプで検証して改善のプロセスを回していって、意匠としてのデザインを適用するのはどの段階になるのか?デザイン適用が後回しになって、ワイヤーフレームのまま実装が進んでいってしまう

質問を素直に読んでいる限りだと、今のままでいいのでは?と思う。
坂田さん個人としては、早くフィードバックを得ることができているという点で、デザインがTBDで実装がどんどん進んでいるのは良いのでは?と考えている。(デザインだと、「ここはまだ触って動かすことはできないんです」みたいなノイズが入ることもある)

一緒にデザインを作り込んでいくなど、コラボレーションすることは重要。

意思決定権はどのように設計されるか?

アジャイル開発だったらWAを定義するときだったり、情報を一番持っていて良質な意思決定ができるのは誰か?という視点で考えたりすると良いと思う。

新規事業ではなく既にアジャイルに取り組んでいる既存プロダクトにはどのようにLean UXを適用できるのか?

ディスカバリーフェーズで実践するようなことや意識することに対して重点的に取り組むのが良いのではないか?と思う。

会全体を通した感想

第2版も第3版も読んだ上での参加だったのですが、第3版の発行に伴う差分が綺麗にまとまっていたり、具体的な事例紹介があったりと、学びが多い時間でした。
Jeffからのメッセージがあったのも良いサプライズでした。

基調講演でも質疑応答でも、坂田さんのものづくりに対しての熱がすごく感じられたのも非常に素敵で、非常に刺激をもらえる回でした。

*1:現在はJR東日本公式アプリに統合されている