Lean UX 第2版 ―アジャイルなチームによるプロダクト開発 (THE LEAN SERIES)

著者 : ジェフ・ゴーセルフ ジョシュ・セイデン 児島修

制作 : エリック・リース 

• オライリージャパン (2017年7月4日発売)

作品紹介・あらすじ

好調な『Lean UX』の改訂版。初版出版から3年半を経てUXの役割の変化、コラボレーションなどの具体的な手法の変化を取り入れてアップデート！
2013年2月の原書初版発行以降のUX周辺の変化が取り込まれ、より実践的にした改訂です。第Ⅰ部の「原則」が大幅に加筆修正され、チーム構成や職種、Outcome（成果）をビジネスとユーザーで分けて考えるなど、「Lean UX」の原則がより明確になりました。また、旧版は概念の説明がメインだったため、事例が欲しいという要望がありましたが、今回の改訂で9章にPaypalでの事例が掲載されたことで、より具体的に検証できるようになりました。

感想・レビュー・書評

[しょたろさんの感想 · 2021年3月24日]

LEAN UX アジャイルなチームによるプロダクト開発
 
■Lean UXがもたらす価値
・ポイントは2つ
・1.1つ目は競争が激しく変化が恐ろしいほどに早いソフトウェア業界だからこそ、リスクを最小限に抑え、無駄をなくすためのマネジメントやソフトウェア開発が求められている。
・Lean UXは銀の弾丸ではない。しかし、いま現在抱えている問題、それも正しい問題に着目することによってソフトウェア開発における不確実性を可能な限り排除し、前提となる条件や仮説の検証を繰り返す「フィードバック・ループ」の基盤を構築し、確実性を積み上げていくための方法論として有効。
・2.もう1つは、UXデザインの深化が求められていること。これまでUXデザインはどうしてもその活動量の多さからコストや時間がかかる、と捉えられてきた。ユーザー理解を深めるためのユーザー調査、ペルソナやシナリオ作成、その後のデザインの検討はコストの観点からソフトウェア開発に取り入れられないケースが多く、ユーザーとの距離が遠ざかってしまいがち。結果、せっかく開発したプロダクトやサービスがユーザーに使われなくなり、なぜ使われないのか、その理由をアンケートなどで簡単に調査し、聞き出したニーズをそのまま受け入れて機能を開発し、ユーザーに結局使われないといった負のループに陥りやすくなる。結果、無駄を省いているつもりでも逆に無駄が生じてしまう。
 
■本質的な4つの問い
・1.解決したいと思っている課題は何か？誰の課題か？
・2.解決すべき課題は何か？その課題は正しいか？
・3.課題をどのように解決すべきか？
・4.課題に対して十分な解決に至っているか？
・1の「解決したいと思っていること」と「解決すべきこと」は別でとらえる必要がある。なぜなら、解決したいと思っている課題は思い込みの可能性があるため。
・推測は、プロダクト開発における最大の敵となる。
 
■Lean UXとは？
・Lean UXは、「リーンスタートアップ」以外にも、「デザイン思考」と「アジャイル開発」という2つの概念を基盤としている。
・デザイン思考は、私たちの仕事の範囲をインターフェースや中間生成物を超えた領域まで広げるのに役立つ。デザイン思考では、システム全体に注目して、デザイン・ツールを様々な問題解決に適用できる。この問題解決では、コラボレーション、イテレーション、開発、ユーザーへの共感が重要になる。
・アジャイル開発を採用することで、ソフトウェア開発は短期間のサイクル、定期的な価値提供、意義的な学習に集中できる。ユーザーに（ソフトウェアの開発を通じて発見した）アイデアを素早く提供し、そのアイデアがどう受け止められたかという感触を探りながら、随時調整を行い、新たな学習を目指していく。
・デザイナーの最も大切な仕事とは、仕様書ではなく、価値あるプロダクトやサービスをつくること。
 
■デザインは常に進化している
・リリースを早期かつ頻繁に行い、マーケットからのフィードバックを得て、学習したことに基づいてイテレーションを繰り返し、ユーザーとの継続的なインタラクションを生み出している。
・つまり、プロダクトやサービスを「提供」すると同時に、「発見」している。
 
■プロダクトやサービスを「提供」すると同時に、「発見」するメリット
・プロダクトやサービスがユーザーのニーズを満たしているかどうかを、継続的かつ頻繁に学習できること。
・プロダクトやサービスの質、フィードバックへの対応の面でユーザーの期待値を上げられること。
 
■Lean UXは、プロダクトデザインとコラボレーションの進化を体現したもの
・Lean UXでは、コラボレーションや部門横断的な仕事の進め方が極めて重要であるため、デザイナーやプロダクトマネージャー、ソフトウェアエンジニアが、それぞれ孤立して仕事を進めることは許されない。ウォーターフォール型でプロジェクトを進める時代は終わった。他のメンバーの仕事が終わるのを待っている余裕も、チームを待たせている余裕もない。
・効果的に仕事を進めるためには、チームメンバー全員が、日々、継続的に関わっていかなければならない。この継続的なエンゲージメントでは、チームメイトとの「共通理解」を深めるために、情報伝達のための膨大な資料（とそれを作成する時間）を不要にする。私たちはもっと価値のある活動、例えばプロダクトに関する戦略的な決定に影響する情報収集などに多くの時間を費やすことができる。
・私たちは、これからつくる機能やドキュメンテーションについてではなく、ユーザーや顧客にとって何が効果的かに焦点を当てて話すようになる。今回紹介する内容を取り入れることによって、マーケットからのフィードバックにかつてないほど多くアクセスできるようになる。このフィードバックによって、私たちは客観的なビジネスゴールを念頭に置きながら、その枠組みの中でデザインについて議論ができるようになる。何が機能しているかを把握し、学び、調整をしながら、デザインを進められるようになる。
 
■Lean UXの原則
・Lean UXのベースなる考え方は、ユーザエクスペリエンス・デザインとなる。Lean UXの本質的な価値とは、ユーザエクスペリエンス・デザインを実践する方法に他ならない。実践の中心にあるのは、システムのユーザニーズである人間のニーズを特定することから始まる。
・Lean UXにとってデザイン思考は重要。なぜならデザイン思考は、「ビジネスにおける全ての側面に対して、デザイン手法でアプローチすることができる」という、はっきりとした立場をとっているため。デザイナーは従来の役割に制限されることなく、組織内の境界線を超えて仕事ができるようになる。デザイナー以外の人も、それぞれが直面する問題を解決するために、デザイン手法を用いることが奨励される。
 
■Lean UXでは、アジャイル開発は4つのコアバリューをプロダクトデザインに適用する
・1.プロセスやツールよりも対人コミュニケーションを。
・2.包括的なドキュメントよりも動くソフトウェアを。
・3.交渉よりもユーザーとの協調を。
・4.計画に従うことよりも、変化への対応を。
 
■Lean UXの定義とは？
●Lean UXの原則
・これらの原則は、「チームビルディング」「チームや組織文化の指針」「プロセスの指針」に関する3つのグループに分けられる。
●「チームビルディング」に関する原則
・部門横断的なチーム
・小規模で同一の場所にいるチーム
・自己充足的で、権限を持つチーム
・課題焦点型のチーム
●「チームや組織文化の指針」に関する原則
・疑問から始めて確信へ移動していく
・結果（アウトプット）ではなく、成果（アウトカム）を重視する
・無駄を省く
・共通理解を生み出す
・ユニコーン、エバンジェリストやヒーローは不要
・失敗を許容する
●「プロセスの指針」に関する原則
・バッチサイズを小さくしてリスクを減らす（仕事を「バッチ」と呼ばれる小さな単位に分割する方法も、Lean UXがリーン生産方式から取り入れることのできる原則の1つ）
・継続的に発見する
・GOOB（建物から出る）：新たなユーザー中心思考を用いる
・仕事を外面化する
・分析よりも形にする
・中間生成物中心の仕事の進め方から脱却する
 
■Lean UXのプロセス
●ビジョン、フレーミング、アウトカム（成果）
・機能ではなく、創出したい価値に焦点を当て、価値を提供するソリューションが見つかるまで検証を続ける方が効果的。
●前提となる推測や仮定：4つのタイプ
・1.ビジネスの成果
・2.ユーザー
・3.ユーザーの成果
・4.機能
●課題ステートメントの概要
・チームには、出発点が必要。効果的なのは、課題ステートメントから始めること。
・課題ステートメントは、主要なステークホルダーがビジネスにおける戦略的なビジョンに取り組み始める前に作成する。
・課題ステートメントを作ることで、チームは明確な目的を持って仕事に取り組みやすくなる。
・また、重要となる制約も明示する。制約は、チームが意図せぬ方向に脱線せず、連携して前進できるようにするための、ガードレールの役割を果たす。創造性は、制約の中でこそ花開く。
●既存のプロダクトやサービスの課題は3要素で構成されている
・1.プロダクトやサービス、またはシステムの目標
・2.ビジネス・ステークホルダーが解決を求めている課題（すなわち、目標が達成されていない箇所）
・3.特定のソリューションが指定されていない、明示的な改善要求
●課題ステートメントのテンプレート（既存のプロダクトやサービス向け）
[サービス/プロダクト名]は、[この目標]を達成することを目標にしている。
しかし、このサービス/プロダクトは、[その目標]を達成しておらず、私たちのビジネスに[このような悪影響]を生じさせている。
[測定可能な標準]に基づき、ユーザーの成功率を向上させるためには、どのように[サービス/プロダクト]を改善すれば良いか？
→この課題ステートメントは、チームが解決すべき明確な課題を設定している。懸念事項を考えるための材料にもなり、会社のビジネスとその最終的な成功にどれくらいの影響が生じ得るかという感覚をつかむことができる。また、チームが特定の機能の開発ではなく、成果やユーザーの行動の変化の達成を目指してプロジェクトを進めるべきであることの明確なガイドラインにもなる。
●新規のプロダクトやサービスの課題も3要素で構成されている
・1.マーケットの現状
・2.ビジネスが活用したい機会（すなわち、現在のソリューションが失敗しているところ）
・3.マーケットのギャップに対処するためのプロダクトやサービスに関する戦略的ビジョン
●課題ステートメントのテンプレート（新規のプロダクトやサービス向け）
・現状、[ドメイン]は主に[ユーザーセグメント、ユーザーのペイン（不満点）など]を重視している。
・既存のプロダクトやサービスは、[マーケットのギャップ]に対処できていない。
・当社のプロダクトやサービスは、[ビジョン/戦略]でこのギャップに対処する。
・当社は第一に重視するのは、[ユーザーセグメント、ユーザーのペイン（不満点）など]である。
→開発中のプロダクトやサービスやタイプや、誰がそれを開発しているかに関わらず、課題ステートメントにも推測や仮定が多く含まれている。チームの仕事は、課題ステートメントを核となる推測や仮定に分解すること。
●ビジネスにおける推測や仮定に関するエクササイズ
・ステップ1：推測や仮定に関するエクササイズを各人が行う
・ステップ2：回答を共有する
・ステップ3：収集、整理、優先順位付け
 
■ワークシート
●ビジネスに関する前提
・1.ユーザーには____のニーズがあると考えている。
・2.これらのニーズは、____によって解決できる。
・3.最初のユーザー（予定含む）は____だ。
・4.ユーザーが私たちのサービスから一番得たいと思っている価値は____だ。
・5.ユーザーは、____などのメリットも得られる。
・6.多くのユーザーを____を通じて獲得する予定だ。
・7.収益は____を通じて得る予定だ。
・8.想定しているマーケットでの最大の競合は____になると予測される。
・9.競合には、____によって優位になる予定だ。
・10.私たちのプロダクトやサービスの最大のリスクは____だと予測される。
・11.このリスクは____を通じて解決する予定だ。
・12.他の推測や仮定のうち、偽であると証明された場合にビジネスやプロジェクトに悪影響を及ぼす要因になるものとして、____が挙げられる。
●ユーザーに関する前提
・1.ユーザーは誰か？
・2.私たちのプロダクトやサービスはユーザーの仕事や生活のどの部分にフィットする？
・3.私たちのプロダクトやサービスが解決する課題は何か？
・4.私たちのプロダクトやサービスは、いつ、どのように使われるか？
・5.どの機能が重要か？
・6.私たちのプロダクトやサービスの外観と振る舞いはどのようなものか？
 
■仮説の構築
・前提となる推測や仮定のリストをつくったら、次のステップは「仮説の構築」だ。
・まずは、各前提を、評価しやすい形式、すなわち「仮説ステートメント」に変換する。
●仮説ステートメントには次の形式を用いる
私たちは、[このステートメントは正しい]と考えている。
そして、マーケットから以下のフィードバックを得たとき、それが[正しい/間違っている]かどうかを判断できる。
[定性的なフィードバック]、[定量的なフィードバック]、[主要業績指標の変化]。
 
●機能的仮説ステートメントのテンプレート
我々の[ビジネスの成果]は、[ユーザー]が[ユーザーの成果]を[このソリューションや機能]で実現できれば、達成できるはずだ。
 
■課題ステートメントから仮説の構築へ
●プロトペルソナ
・自分たちはユーザーではないことを自覚する。
・ユーザーは存在するか？を判断する。
・ユーザーはチームが想定しているニーズやペインを持っているか？を判断する。
・ユーザー課題を解決してくれるソリューションを評価するか？を判断する。
・プロトペルソナは、現在の状況に合わせて絶えず更新していくべきユーザーの情報だと考えるようにする。
●ユーザーにおける成果
・チームはユーザーが求めているものをユーザー成果という形の前提として宣言する。
・ユーザーは何を達成しようとしているか？
┗例：新しい携帯電話を買いたい。
・このプロセスの最中と後に、ユーザーはどのようなことを考えるか、または感じるか？
┗例：欲しい携帯電話を手頃な価格で手に入れたい。最新テクノロジーを周りに遅れずに使ってみたい（かっこいい気分を味わいたい）。
・このプロダクトやサービスは、どのような方法でユーザーを目標や夢に近づけるか？
┗例：新しいテクノロジーを使いこなしたい、そのことによって人から一目置かれたい。
 
■MVPとプロトタイプ
・Lean UXは、MVPの概念をとても大切にしている。MVPは、前提となっている推測や仮定から導き出された仮説の評価（例：「このアプローチは、望ましい成果をもたらすか？」）に役立つと同時に、確実性が証明されていないアイデアに投じる労力を最小限に抑えることができる。
●そもそも、MVPとは何か？
・MVPは2つの方法で用いられている。
・1.1つは、学習を主目的としてMVPを構築する方法。この場合、チームはマーケットに価値を提供することではなく、マーケットが何を求めているかを知ることを重視する。
・2.もう1つは、できるだけ速くマーケットに価値を届けようとして、製品や機能の小さなバージョンをつくるというもの。このケースでも、MVPのデザインや実装を適切に行うことで、それが主目的ではなくても、チームはその結果から多くを学ぶことが可能となる。
 
●MVPの構築で価値を探る（MVPのガイドライン）
・核心をつく
・明確なCTA（コール・トゥー・アクション）を使用する
・優先順位付けを重視する
・アジリティを維持する
・ゼロからつくろうとしない
・行動を測定する
・ユーザーと話す
 
●プロトタイプ
・MVPを構築するにあたって極めて効果的な方法は、体験のプロトタイプをつくること。
・プロトタイプとは、実際の体験に近しいものをつくって、プロダクトやサービスの利用をシミュレーションすること。
・プロトタイプの対象となるオーディエンスを指定することは重要。オーディエンスから有益なフィードバックを得るための必要最小限のプロトタイプが何かを判断できるようになる。

[ikuodanakaさんの感想 · 2020年2月12日]

価値探索とチームでの協働に重きをおいている、というのがよくわかる。それくらい、繰り返し仮説はあくまで仮説であること、様々な場面で全員同席が望ましいことに触れられている。

考え方や姿勢に重きをおいているからなのか、Whyについては伝えつつもHowとWhatについての解説が軽量で、どういうアクションなのかであるとかどのような効果がもたらされるのかがイメージしづらいケースがあった(デュアルトラックアジャイルなどは特にそう感じた)。
そこのプラクティスは現場で揉め、ということなのだろう。

[ma1979さんの感想 · 2019年5月25日]

しきりにチーム全員で、が強調されているように感じた。コラボレーティブデザイン

[cmano8さんの感想 · 2023年11月5日]

- とにもかくにも共通理解。心理的安全性のような超基本レベルではなく、高い水準での非言語コミュニケーションが仲良さ問わず当たり前に生まれている状態、本当の意味での一心同体でなければ成り立たない、というメッセージを強く感じた。
- コミュニケーションも1つのツールとしたときに、これを使いこなせるかは超大事なスキルだ。
- ≒どんなタイプの人間ともわかりあって進められる力。発言やドキュメンテーションの精度なども含まれる。
- 不確実性を受け入れる、や、失敗や振り返りから発見と新しい取り組みを定める、など、VUCA時代の基礎スキル。しばらくPdMブームあったが、職種問わず、ビジネス基礎力としての、前に進める力としての本と捉えた方が良さそう。

[kinocoboyさんの感想 · 2023年8月14日]

コラボレーションに関する気づきを得ることができた。

[toshi591989さんの感想 · 2023年2月26日]

これからアジャイル開発やる人は読む

[bebit_libraryさんの感想 · 2022年4月26日]

【進藤さんオススメ：連休中に読みたい本】

[akio yoshihashiさんの感想 · 2021年12月30日]

読んでよかった。アジャイル本を数冊続けて読んだ流れでちゃんと押さえておくべきかなと思って。
ウォーターフォール型の開発とアジャイル開発では開発プロセスそのものが異なるので、「UX」の理念や目標は同じでも現場で取り組む具体的な内容・手法は当然違ったものになる。IT企業で必要とされるのは重厚なUXプロセスではなくて、こちらLean UXの方だろう。

「ヒーロー」的なデザイナーに絶対的な価値を置いてその輩出を全力で目指しているこれまでのデザイン教育との相性の悪さもまた明らか。

以下、LeanUXにおける「デザイン」に言及している部分からいくつか抜粋。
4.1 コラボレーティブなデザイン
チームはコラボレーティブ・デザインを通じて協業しながらデザインをつくりあげていく。主導するデザイナーはコラボレーティブ・デザインのための場を開き、メンバー間のコミュニケーションを促す。
8.1.3.9 組織に求められる変革：ヒーローは不要
「LeanUXの考え方に抵抗するデザイナーは少なくない。多くのデザイナーがヒーローになりたがっているが、仮説としてのデザインという考え方そのものがヒロイズムを否定。LeanUXのデザイナーは失敗をプロセスの一部として歓迎すべき。

8.1.3.12 組織に求められる変革：課題解決に価値を置く
組織が今後もこれまでと同じように、美しさや洗練度、細部への配慮に価値を置かなくてはならないことに変わりはないが、デザインの他の側面も同じくらい重要。ビジネス上の問題のコンテキストを理解し、素早く思考し、共通理解をつくりあげる能力を、これまで以上に高く評価しなければならない。

[2319chanさんの感想 · 2021年6月19日]

LEANとUXのお勉強。

■LeanUXのキーワード
　コラボレーション、イテレーション、透明性の維持、必要最小限のドキュメンテーション、最小限の中間生成物、動くソフトウェア、マーケットからのフィードバックの重視

■ヒューマン・インターフェース・ガイドライン
　Appleのオペレーティングシステムの全コンポーネントの説明、その使用規則の規定と適切な使用例を記述した包括的なドキュメント

　Lean UXをアジャイル開発で機能させるためには、チーム全体がすべての活動（スタンドアップ、レトロスペクティブ、IPM、ブレインストーミング）に参加すべきです。これらのセッションを成功させるためには、全員の参加が不可欠です。部門横断的なメンバーの参加によって、特定の機能の複雑度をどう開発すべきかについてチーム内で交渉しやすくなるのに加え、デザイナーとエンジニアはバックログの優先順位をより効果的に付けられるようになります。

■knowsyでのケーススタディ
・チームは３～７人の小規模なもの
・プロジェクトは、アジャイルな枠組みで実施する（ユーザーへのフォーカス、継続的な取り組み、チームは同じ場所で作業する、必要最低限のドキュメント、チーム全体が決定権を持つ、スタンドアップやレトロスペクティブなどの共通の儀式を行う）
・チームは、様々な技能を持つ人材で構成する（フロント及びバックエンド開発、ユーザエクスペリエンス、情報アーキテクチャ、プロダクトマネジメント、マーケティング、グラフィックデザイン、コピーライティング）
・チームのメンバーは、基本的には自らの専門性や強みのあるエリアでパフォーマンスを発揮するが、他のスペシャリストをサポートし、新たな技能の習得にも意欲的である。

■プロセスを変える
・結果（アウトプット）から成果（アウトカム）へ
・完璧なデザインを事前に求めない
・スピードが第一、美しさはその次であること
・UXの負債を受け入れること
・ドキュメント化する基準を管理する
・日々の問題に対処する

　
　私たちが取り扱っているのはソフトウェアであり、そのプロダクトやサービスは複雑で予測不可能なものです。しかし、ソフトウェアには最終形態はありません。デジタルなプロダクトやサービスのデザイン、開発、運用、最適化は、経済的な合理性がある限り継続できます。もっとも厄介なのは、ユーザーが私たちの想像もできない方法でデジタル・サービスを利用する可能性があることです。システムの主要機能はたいてい、人々がシステムを利用するにつれて明らかになっていきます（その典型例がTwitterのハッシュタグです。この機能はユーザーが使い方を発明した後に、Twitterが追加で実装したものです。）

■UXデザイナーの新たな技能
・デザイナーがデザイン・プロセスをリードする
　個人ではなく、チーム全体がプロダクトデザインに責任を持ちます。デザイナーはパソコンに向かいっぱなしで仕事をするのではなく、チームをデザイン・プロセスに関与させ、インプットを求め、そこで得た知見をデザインに活用しなければなりません。これによって、サイロの壁が取り除かれ、部門横断的なコラボレーション戦術を活かし、創造的かつ実践的でなければなりません。つまりチームのニーズを満たし、コミュニケーションを促進し、チーム全体の能力とプロジェクトのタイムラインを現実的にとらえることのできる方法を、求めなければならないのです。
・デザイナーがチーム内でリーダーの役割を担う
　チームのメンバーは、デザイナーが作成したデザインについて意見を述べることに慣れていますが、デザイナーと共にデザインを作成することには慣れていません。デザインスタジオのようなグループでのブレインストーミング活動においてデザイナーがリーダーとファシリテーターの役割を担うことで、チーム全体がプロダクトやサービスを概念化したり、デザインチーム全体が能力を示したりするための、安全な意見交換の場をつくることができます。

[j-okさんの感想 · 2021年2月2日]

UX寄りの内容を期待していたが、冒頭のLean UXの原則として”チームや組織文化”に触れている通り、デザインのタスクをチームとしてどのようにリーンのプロセスに組み入れていくかがが話の中心。全体を通じて機能横断的、全員参加ということが繰り返し述べられている。
実践パートのデザイン・学習と開発（アジャイル開発）を並行で走らせていく進め方が参考になった。