はじめに
「要件どおりに作ったのに、誰にも使われなかった」
設計やアーキテクチャに関わっていると、こうした経験に心当たりがある方は多いのではないでしょうか。
今回は、その原因と対処を「チームの仕事の進め方」から掘り下げた『Lean UX 第3版 ―アジャイルなチームによるプロダクト開発』(Jeff Gothelf、Josh Seiden 著／坂田一倫 監訳／児島修 訳／オライリー・ジャパン)を読みましたので、全体をまとめて紹介します。
書名に「UX」とありますが、デザイナー向けの本というより、エンジニアやプロダクトマネージャーを含めたチーム全体の「作り方」を再設計する本だと感じました。
この記事は書籍の要約と個人の感想です。図表や具体的なテンプレートの全文は掲載していません。詳細は書籍をご確認ください。
こんな方に読んでほしい記事です
- 仕様どおりに実装することと、価値を届けることのギャップに悩んでいる方
- スクラムなどのアジャイル開発を回しているのに、手応えが薄い方
- 設計やアーキテクチャの判断を「根拠のあるもの」にしたい方
1. 本書の全体像
本書は4部構成です。
| 部 | 章 | 内容 |
|---|---|---|
| 第Ⅰ部 | 1〜3章 | Lean UXの基本原則と「成果(アウトカム)」の考え方 |
| 第Ⅱ部 | 4〜13章 | Lean UXキャンバスの8つのボックスを使った実践プロセス |
| 第Ⅲ部 | 14〜16章 | コラボレーション、デザインシステム、アジャイルとの統合 |
| 第Ⅳ部 | 17〜19章 | 組織への導入、エージェンシーでの実践 |
分量としては、第Ⅱ部のキャンバス解説が中心です。
第3版ではLean UXキャンバスが新たに加わり、第2版までとは別の本と言えるほど構成が変わったと、監訳者まえがきで紹介されています。
Lean UXとは何か
著者による定義を、私なりの言葉に言い換えると次のようになります。
コラボレーティブで、部門横断的で、ユーザー中心の進め方によって、プロダクトの本質を素早く見極めるデザインアプローチ。チームの意思決定の根拠を築くために、継続的な学習を優先する。
つまり、完成度の高い成果物を作る方法ではなく、素早く学ぶための方法です。
この「学習ファースト」の視点が、本書全体を貫いています。
2. 第Ⅰ部 基本原則(1〜3章)
1章 かつてないほどに高まるLean UXの重要性
物理的な製品づくりでは、製造コストが高いため、作る前にすべてを決める必要がありました。
しかし現在は、ソフトウェアを継続的にリリースでき、サイクルタイムの短い競合も現れます。
最初にすべてを決め切るアプローチが機能しにくくなっている、というのが著者の見立てです。
2章 Lean UXの原則
Lean UXは、次の3つを土台にしています。
| 土台 | 取り入れているもの |
|---|---|
| UXデザイン(デザイン思考) | ユーザーのニーズから出発する姿勢 |
| アジャイル開発 | 短いサイクル、対話の重視、変化への対応 |
| リーン・スタートアップ | 構築─計測─学習のループ、MVP |
原則は「チーム」「文化」「プロセス」に整理されています。特に印象に残ったものを挙げます。
- 部門横断的なチームが、初日から継続的に関わる
- 機能の実装ではなく、課題の解決を目標にする
- 疑問から確信へ: 検証されるまでは、すべてが推測であると捉える
- 結果(アウトプット)ではなく**成果(アウトカム)**を重視する
- ヒーローやユニコーンに頼らず、失敗を許容する
- 「◯◯フェーズ」と名のつくものは警告サインと考える
- インクリメンタル(分割して積む)とイテレーティブ(繰り返し磨く)を混同しない
- バッチサイズを小さくし、テストされていないアイディアの「在庫」を減らす
- 議論より、まず形にする
イテレーションの定義は、開発現場でもよく混同される部分だと思います。
本書では、小さく分けて順番に作ることと、望む成果が出るまで同じ対象を作り直すことを、はっきり区別しています。
3章 成果
本章は、Lean UXの中心概念である「成果」を扱います。
| 用語 | 意味 |
|---|---|
| 結果(アウトプット) | 私たちが作るもの(機能、画面など) |
| 成果(アウトカム) | 人の行動が変わることで生まれる価値 |
| 影響(インパクト) | 収益や成長など、組織としての最上位の目標 |
著者は成果を**「人間の行動変化による価値創造」**と定義しています。
成果が「作ったモノ」ではなく「人の行動」だという点が重要です。
成果を軸にすると、機能の優先順位付けに判断の物差しが生まれます。
また、成果を測るには実際にリリースして行動の変化を観察する必要があるため、リリースがゴールではなく検証の入口になります。
3. 第Ⅱ部 Lean UXキャンバス(4〜13章)
4章 キャンバスの考え方
出発点は、要件とは、権威をもって語られた「思い込み」にすぎないという認識です。
そこで本書は、思い込みを「検証可能な前提」として明示し、順番に検証していく枠組みとして、Lean UXキャンバスを提示します。
| ボックス | 問い | 章 |
|---|---|---|
| 1 ビジネスプロブレム | 何の問題を解決するのか | 5章 |
| 2 ビジネスの成果 | うまくいくと、人の行動はどう変わるのか | 6章 |
| 3 ユーザー | 誰のためのものか | 7章 |
| 4 ユーザーの成果とメリット | その人は何を得たいのか | 8章 |
| 5 ソリューション | 何を作る(やる)のか | 9章 |
| 6 仮説 | 何が成り立つと信じているのか | 10章 |
| 7 最初に学習すべき最重要事項 | 最大のリスクは何か | 11章 |
| 8 MVPと実験 | 最小限の作業で何を試すのか | 12章 |
ポイントは、ソリューション(ボックス5)がかなり後ろに置かれていることです。
先に課題、成果、ユーザーという制約を置くことで、焦点の定まった解決策を考えられるようにしています。
キャンバスは全員参加が前提で、「1人 → 2人 → 4人 → 全員」と人数を広げていく手法(1-2-4-All)が紹介されています。
分からないことは脇に置いて先へ進み、分析麻痺に陥らないことも注意点です。
5章 ボックス1: ビジネスプロブレム
注意点は3つです。
- ソリューションを決めつけない(「アプリを作るにはどうするか」は不可)
- チームが裁量を持てる適切なレベルの問題を扱う
- 「直感的なUI」のような曖昧な表現を避け、具体的な指標を入れる
例として、パスワード再設定機能が取り上げられています。
再設定を自力で完了できない利用者が多い状況に対し、完了率や問い合わせの削減率を成功基準に置く内容です。
6章 ボックス2: ビジネスの成果
経営層が見るインパクト指標を、チームが扱える**先行指標(顧客の行動)**に落とし込みます。
使われるフレームワークは次のとおりです。
- 海賊指標(AARRR): 獲得、活性化、継続、収益、紹介の5段階
- メトリクスマウンテン: ファネルの代わりに「山」で表現するモデル
- アウトカム・トゥ・インパクトマッピング: インパクト指標と顧客行動の関係を可視化する
大事なのは、指標なら何でも成果になるわけではないという注意です。
「自動化されたタスクの割合」は数値ではあっても顧客行動ではなく、プロダクト側の決定にすぎません。
7章 ボックス3: ユーザー
ペルソナを、時間をかけた調査の成果物ではなく、**プロトペルソナ(現時点での最善の推測)**として短時間で作り、リサーチで検証し続けます。
早い段階で、その人たちが本当に存在するか、想定した課題を抱えているか、解決策に価値を見出すか、を確認できます。
エンジェル投資家向けの管理ツールの例が印象的です。
対象者も課題も存在しましたが、大半は年に1〜2回しか投資せず、既存のメールや表計算で足りていました。
課題があることと、新しいソリューションが選ばれることは別だという教訓です。
8章 ボックス4: ユーザーの成果とメリット
ビジネス、顧客(購入者)、ユーザーでは、求める成果が異なります。
ここでは機能ではなく、「ユーザーは何を達成し、どんな気持ちになりたいか」を考えます。
9章 ボックス5: ソリューション
アイディア出しには、アフィニティマッピングや、より体系的なデザインスタジオを使います。
流れは、課題の確認(15分)、各自のスケッチ(10分)、発表とフィードバック(1人3分)、2人1組での統合(10分)、全体での絞り込み(45分)です。
フィードバックは意見ではなく質問の形で行うのがコツとされています。
10章 ボックス6: 仮説
ここまでのボックスの内容を1つの文にまとめたものが仮説です。
ビジネスの成果 を達成できると信じている。
ペルソナ が、
ユーザーの成果・ベネフィット を、
機能・ソリューション で獲得するなら。
ユーザーストーリーでは「目標」が「機能」に置き換わりやすく、受け入れ基準も「意図どおり動くか」になりがちです。
一方、仮説の成功はユーザー行動の変化で定義されます。
機能のリリースは、仮説検証の終わりではなく始まりです。
仮説が多すぎる場合は、仮説優先順位付けキャンバスで整理します。
横軸がリスク、縦軸が知覚価値の2×2マトリクスで、価値もリスクも高いものを優先して検証します。
11章 ボックス7: 最初に学習すべき最重要事項
ライフサイクルの初期では、最大のリスクは技術ではなく価値です。
人々がそれを必要とし、探し、試し、使い、価値を感じるのか。
ここが「いいえ」なら、実装方法を考える必要はありません。
技術的課題やスケーラビリティは、価値が確認されてから検討するリスクになります。
12章 ボックス8: MVPと実験
本書でのMVPは、「小さく早くリリースしたもの」ではなく、何かを学ぶための小さく素早い方法です。
コードを書かないMVPも多くあります。
| 種類 | 概要 |
|---|---|
| ランディングページ | 価値提案とCTAを置き、需要を測る |
| 機能フェイク | 存在しない機能のボタンを置き、クリック率で関心を測る |
| オズの魔法使い | 裏で人が手動処理し、サービスの仕組みを学ぶ |
| プロトタイプ | 紙から高忠実度まで、目的に応じて選ぶ |
| ノーコードMVP | 既存ツールを組み合わせて機能を提供する |
ボランティアのマッチングサイトの事例では、システムが動いているように見せつつ、裏ではメールを手動で送っていました。
数カ月の運用で業務を見直し、確信を得てから、本物のバックエンドを作っています。
いきなり作らず、まず最も安く学べる手段を選ぶという姿勢は、設計判断にもそのまま応用できると感じました。
4. 第Ⅲ部 コラボレーション(14〜16章)
14章 コラボレーティブデザイン
デザインは、デザイナー1人の仕事ではなく、チーム全体で行うものとされます。
成果物は、意図的に低忠実度のスケッチやワイヤーフレームに留めます。誰でも貢献でき、軌道修正もしやすくなるためです。
デザインスプリントについては、競合するものではなく併用できるものとして扱われます。
Lean UXを「プロダクトサイクル全体に使える料理本」、デザインスプリントを「特定の瞬間に使う1つのレシピ」にたとえているのが分かりやすいです。
デザインシステムは、画面構造の検討と見た目の実装を並行でき、一貫性や品質の面でメリットがあります。
一方で、使いやすいためにラフスケッチを飛ばして高忠実度のモックを作ってしまう問題があり、フィードバックが色やフォントなどの細部に偏りがちです。
また、デザインシステムのチームも社内向けプロダクトを作るプロダクトチームであり、成功の指標は導入率だという指摘がありました。
社内向けライブラリや共通基盤を作る立場の方には身近な話だと思います。
15章 フィードバックとユーザーリサーチ
継続的でコラボレーティブなユーザーリサーチの進め方が扱われます。
この記事では細部を割愛しますが、2章の「継続的な発見」を実践に落とした内容です。
16章 Lean UXとアジャイル開発の融合
本書の実務的な見どころが、この章だと感じました。
「完了」の再定義
スクラムの「完成の定義」や受け入れ基準は、ソフトウェアが意図したとおりに動くことを保証しますが、価値を生んだかどうかは分かりません。
パスワード認証フローを例に、次のような捉え直しが提案されています。
| 従来の基準 | 捉え直した基準 |
|---|---|
| 入力欄がある、エラーが出る、3回失敗でロックされる | 初回認証の成功率、復旧の試行回数、コールセンターへの依頼割合を改善する |
従来の基準は引き続き必要ですが、顧客に成果が出て初めて完了という考え方です。
スタッガードスプリントからデュアルトラックへ
デザインを開発の1スプリント先に走らせる「スタッガードスプリント」は、運用を誤るとミニ・ウォーターフォールになります。
ハンドオフとドキュメントが増え、共通理解が失われるためです。
そこで推奨されるのがデュアルトラックアジャイルで、ディスカバリーとデリバリーを1つのチームが1つのプロセスで行います。
- 専任のデザイナーをチームに置く
- バックログは1つにして、開発・デザイン・リサーチを同じ扱いにする
- ベロシティだけでなく、学習の量も見る
その他の実践的なアイディア
- エクスペリメントストーリー: 実験をユーザーストーリーと同じ形式でバックログに載せる
- エクスポージャーアワー: 各メンバーが一定期間ごとに、ユーザーと直接接する時間を確保する
- リスクダッシュボード: 主要なリスクと対応状況を、ステークホルダーに共有する
- 成果ベースのロードマップ: 戦略テーマ、四半期のOKR、仮説で構成し、先になるほど確度の低い推測として扱う
なお、大規模アジャイルフレームワークのSAFeについて、著者はLean UXとは両立しにくいという強い立場を取っています。
著者の見解であり、賛否が分かれる部分だと思いますので、自分の組織で検証する前提で受け取るのが良さそうです。
5. 第Ⅳ部 組織への導入(17〜19章)
17章 組織に求められる変革
Lean UXは、デザイン手法であると同時に運営・マネジメントの手法でもあるとされます。
変えるべき対象は、文化、チーム編成、プロセスの3つです。
エンジニアとして特に興味深かった項目を挙げます。
アジャイルフォールへの警戒
デザインをウォーターフォール的に確定させ、受け取ったチームがアジャイルで開発する進め方を、著者はアジャイルフォールと呼びます。
協働が失われ、詳細なドキュメントや長い交渉が必要になる、形を変えたBDUF(Big Design Up Front)だという指摘です。
UXの負債
技術的負債と同じように、ユーザー体験の改善作業を**「UXの負債」としてバックログで追跡する**という提案です。
ある事例では、リワークを負債として示すだけで、反対意見がなくなり、優先度も付くようになったとされています。
ベンダーとの関係とドキュメント
外部ベンダーを使う場合は、学習に応じて計画が変わる前提で、工数単価型の契約が適しているとされています。
規制などで厳格なドキュメントが必要な場合は、仮説が固まるまでは非公式に進め、その後で必要な形式に整えるという折衷案も示されています。
18章はエージェンシー(受託側)でのLean UX、19章は締めくくりの章です。この記事では詳細を割愛しています。
6. エンジニアとしての所感
ここからは、本書の内容ではなく、私自身の感想です。
仮説は「テスト可能な設計判断」に近い
仮説は、「誰が」「何のために」「どの機能で」「どんな行動変化が起きたら成功か」を、検証可能な形で書き切るものです。
成功条件を先に言語化するという点では、受け入れテストを書く姿勢の延長にあると感じました。
「作らない」ことも設計の一部
MVPの考え方は、「最小限の実装で最大の学びを得る」ことです。
アーキテクチャの意思決定でも、最初から拡張性を作り込む前に、最も不確実な点を安く検証することは有効です。
価値のリスクと技術のリスクを分けて考える視点は、設計レビューでもそのまま使えると思います。
負債という共通言語
技術的負債という言葉が優先度の議論を助けてきたのと同じように、見えにくいものに名前を付けることが合意形成につながります。
UXの負債は、開発側と非開発側の対話に使いやすい発想です。
読むときの注意点
- 事例の多くは、チームに裁量がある環境のものです。裁量が小さい環境では、そのまま適用できない場面があります
- 第Ⅱ部のキャンバスは一気に全部やろうとせず、必要なボックスだけ使うのが現実的です
7. まとめ
本書の主張を、5つのポイントに絞ります。
- 要件は「権威付きの思い込み」であり、検証できる仮説として扱う
- 目指すのは機能(アウトプット)ではなく、行動の変化(アウトカム)
- MVPは「小さなリリース」ではなく、学ぶための最小の手段
- 「完了」は、動作することではなく、顧客に成果が出たこと
- 最後に変えるべきなのは、手法ではなくマインドセットと組織
手順をなぞるだけでは効果は出にくいですが、「まず前提を疑い、小さく試して学ぶ」という姿勢は、設計やアーキテクチャの現場でも持ち帰れる考え方だと感じました。
アジャイルを実践しているのに、どこか手応えが薄い。
そう感じている方は、一度手に取ってみてはいかがでしょうか。
参考
- Jeff Gothelf、Josh Seiden 著、坂田一倫 監訳、児島修 訳『Lean UX 第3版 ―アジャイルなチームによるプロダクト開発』オライリー・ジャパン
- 書籍紹介ページ(オライリー・ジャパン)
- Lean UXキャンバス V2(Jeff Gothelf氏のブログ)