lean-ux

Lean UX フレームワーク

重い成果物を、迅速な実験、部門横断のコラボレーション、継続的な学習に置き換える、実践主導の UX アプローチです。Lean UX では、「何をデザインすべきか？」から「何を学ぶ必要があるか？」へと問いを切り替えます。

中核となる原則

アウトプットより成果を重視します。 デザインの価値は、成果物の忠実度ではなく、デザインがユーザーの行動にもたらす変化によって測られます。

基盤となる考え方： 従来の UX では、要件がウォーターフォール式にワイヤーフレーム、モックアップ、仕様書、コードへと引き継がれ、そのたびにコンテキストが失われ、未検証の前提が見えなくなります。Lean UX は、アイデアとエビデンスの距離を縮めます。前提を明示し、仮説を立て、可能な限り小さな実験を実施し、実際のユーザー行動によって議論に決着をつけます。ドキュメントの代わりに共通理解を、ピクセル単位の完璧さの代わりに学習の速度を重視します。

スコアリング

目標：10/10。 以下の 8 項目のクイック診断を使って、UX プロセス、デザイン計画、またはチームのワークフローを評価します。「はい」と答えた項目ごとに約 1.25 点を加点します（8 項目すべてが「はい」なら 10 点）。評価基準：

• 9-10 — 前提が明示され、成功基準を事前に定めた仮説があり、最も忠実度の低い実験を行い、チーム全員でデザインし、毎週リサーチを実施し、アウトプットではなく成果を指標とし、デュアルトラック・アジャイルを実践し、最近無効と判断された仮説が記録されている。
• 5-6 — 仮説はあるものの、基準が曖昧、または忠実度にこだわりすぎている。デザインとリサーチも依然として一部サイロ化している。
• <=3 — 重い成果物、未検証の前提、アウトプットの数を追う評価、実験ログなし。

現在のスコア、診断で不合格となった項目、それぞれに対する具体的な改善策を必ず示してください。

フレームワーク

1. 前提を明示する

中核となるコンセプト： あらゆるデザインは前提から始まります。Lean UX では、前提を仕様にひそかに織り込むのではなく、優先順位をつけて検証できるよう、明示します。

効果がある理由： 暗黙の前提に基づいて作業を進めると、チームは不確かな土台の上に構築し、問題に気づくのはリリース後になってしまいます。前提を早期に表面化することで、最もリスクの高いものに労力を集中でき、誤っていた場合のコストを抑えられます。

主な知見：

• ビジネス上の前提では、ビジネスの成立に必要な条件（収益モデル、市場規模、支払い意欲など）を定義します。ユーザーに関する前提では、ユーザーがどのような人々で、どのように行動するかを定義します
• リスク（誤っていた場合の損害の大きさ）と不確実性（どれだけ情報が少ないか）の 2 つの軸で優先順位をつけます
• リスクと不確実性がともに高い前提から検証します
• 前提は個人で考えるのではなく、チームで協力して書き出します

プロダクトへの応用：

コンテキスト	応用	例
新機能の立ち上げ	前提のマッピングワークショップ	「ユーザーはレポートをチームメイトと共有したいと考えている」
ロードマップの計画	前提のリスクに基づいて機能を順位づける	未検証の考えに成功が左右される機能を優先する
ステークホルダーとの合意形成	役割ごとに隠れている前提を明らかにする	PM は価格設定が機能すると想定し、エンジニアはスケールすると想定し、デザイナーはフローが適切だと想定している

倫理上の境界： 前提は、事後的な正当化ではなく、誠実な評価でなければなりません。リーダーシップがすでに方針を決定している場合は、反証可能であるかのように装うのではなく、その制約を認めてください。

前提のワークショップを実施する場合や仮説を書く場合は、references/hypothesis-canvas.md を参照してください。リスクと不確実性の優先順位づけマトリクス、ビジネス上の前提とユーザーに関する前提の区分、記入式の仮説およびサブ仮説のテンプレートが含まれています。

2. 仮説ステートメント

中核となる考え方： 仮説は、前提を検証可能な予測に置き換え、提案する変更を特定のユーザーセグメントにおける測定可能な成果と結び付けます。

効果がある理由： 仮説を立てることで、精度が高まります。「オンボーディングを改善する」といった曖昧な表現ではなく、チームは証明または否定できる予測を明確にするため、スコープの拡大を防ぎ、学習ステップの内容も明確になります。

主な知見：

• 標準的な形式：「[ペルソナ]が[機能]を使って[アクション]を達成すれば、[成果]が起きると考えます」
• すべての仮説で、ペルソナ、アクション、成果、測定可能な指標を明確にします
• サブ仮説に分けることで、大きな賭けを個別に検証可能な要素に分解できます
• 実験を実施する前に、「検証済み」と「否定された」がどのような状態かを合意しておきます

プロダクトへの適用例：

コンテキスト	適用方法	例
機能設計	ワイヤーフレーム作成前に仮説を書く	「新規ユーザーがガイド付きセットアップウィザードを完了すれば、トライアルから有料プランへのコンバージョン率が10％上昇すると考えます」
A/Bテスト	テストの根拠を明確にする	「CTAをファーストビュー内に移動すれば、クリック率が15％上昇すると考えます」
スプリント計画	各ストーリーに仮説を付ける	ストーリー：「日付で絞り込む」。仮説：「タスク完了時間が30％短縮する」

倫理上の境界： 仮説を検証済みと宣言するために、事後的に都合のよい指標だけを選んではいけません。成功基準は事前に確定してください。

仮説の測定可能な指標を選ぶときや、チームの成功を定義するときは、references/outcome-metrics.md を参照してください。成果とアウトプットの違い、先行指標と遅行指標の組み合わせ、UX OKR、避けるべき虚栄の指標について説明しています。

3. MVPと実験

中核となる考え方： Lean UXにおけるMVPとは、実際のユーザーを対象に仮説を検証できる最小のデザイン成果物です。これは学習のためのツールであり、プロダクトのローンチではありません。

効果がある理由： 5人のユーザーを対象に廊下で紙のプロトタイプをテストすれば、本来ならエンジニアリングのスプリントを丸ごと費やす仮説を否定できる場合があります。実験の忠実度を前提のリスクに合わせることで、労力あたりの学習効果を最大化できます。

主な知見：

• 実験には、低忠実度（紙のプロトタイプ、コンシェルジュテスト）から高忠実度（コードを使ったA/Bテスト、ウィザード・オブ・オズ）まであります
• 質問に答えられる範囲で、最も忠実度の低い実験を選びます
• 優れた実験には、明確な仮説、定義された対象者、測定可能な指標、期間の上限があります
• スピードが重要な場合は、完全なリサーチの代わりにプロトペルソナを使えますが、後で検証する必要があります

プロダクトへの適用例：

コンテキスト	適用方法	例
初期コンセプトの検証	紙のプロトタイプまたはクリック可能なモックアップ	3つのコンセプトをスケッチし、同じ日に5人のユーザーでテストする
需要の検証	ランディングページのスモークテスト	「早期アクセスに登録する」で実際の関心を測定する
ユーザビリティの検証	クリック可能なプロトタイプのテスト	Figmaのプロトタイプを5～8人のユーザーでテストする
価格設定の検証	ペイントドアテスト	料金ページを表示し、課金機能を構築する前にクリック率を測定する

倫理上の境界： スモークテストやフェイクドアによって、実在しないプロダクトがあるとユーザーに誤解させてはいけません。テスト中であることを開示し、参加しない選択肢を用意してください。

実験を選ぶときや設計するときは、references/experiment-patterns.md を参照してください。実験タイプの全カタログと、実施する場合・実施しない場合についての注記、実験選択マトリクスと忠実度の段階表、デザインテンプレートを掲載しています。

4. 共同デザイン

中核となる考え方： デザインはチームで取り組むものです。リーンUXでは、デザイナーが単独で作業してから引き渡すモデルに代わり、開発者、PM、デザイナーが一緒に解決策をスケッチする、部門横断型のセッションを行います。

効果がある理由： 解決策のスケッチに参加した開発者は、実装に40ページの仕様書を必要としません。共有された理解がドキュメントに取って代わり、多様な視点からより創造的な解決策が生まれ、引き継ぎによる無駄が大幅に減ります。

主な知見：

• デザインスタジオの手法：発散（個人でのスケッチ）、発表、批評、収束（スケッチの改善）、反復
• 目指すのは合意形成ではなく、情報に基づくコミットメントです。チームが合意するのは何をテストするかであり、何が「正しい」かではありません
• 部門横断型には、エンジニア、QA、データアナリスト、ステークホルダーも含まれ、全員がスケッチします
• スタイルガイドやパターンライブラリは常に更新されるドキュメントです。成果物は、共有された理解に必要な最小限のもの（多くの場合、ホワイトボードの写真）に絞ります

プロダクトへの応用：

コンテキスト	応用方法	例
スプリント開始時	デザインスタジオのセッション（90分）	チーム全員で、スプリントの仮説に対する解決策をスケッチします
機能の検討	共同スケッチのワークショップ	6アップスケッチ：各自が5分で6つのアイデアを描きます
リモートチーム	バーチャルホワイトボードセッション	FigJam または Miro のボードを使い、時間を区切ってスケッチを繰り返します

倫理的な境界線： 共同作業を委員会方式のデザインにしてはいけません。指定されたデザイナーが意見をまとめ、チームでピクセル単位の投票は行いません。

デザインスタジオの進行時には、references/collaborative-design.md を参照してください。手順に沿ったワークショップの進め方（所要時間、資料、リモートでの実施方法）と、スタイルガイドを常に更新されるドキュメントとして維持する方法が記載されています。

5. フィードバックとリサーチ

中核となる考え方： 大規模な一斉実施型のユーザビリティ調査に代えて、継続的で手軽なリサーチを行います。四半期ごとのレポートではなく、各スプリントに小規模なリサーチ活動を組み込みます。

効果がある理由： 調査結果が意思決定を変えられるのは、まだ低コストで方針を変更できる間だけです。そのため、リサーチの価値は、知見を得てからその知見が影響する意思決定までのスプリント数に応じて低下します。週ごとの小規模な調査なら、その間隔をほぼゼロに保てますが、四半期ごとのレポートでは実現できません。

主な知見：

• リサーチの種類：ユーザビリティテスト、顧客インタビュー、A/Bテスト、アナリティクスのレビュー、アンケート、日記調査
• 5人のユーザーで、ユーザビリティ上の問題の約85％を発見できます（Nielsen）
• 継続的なサイクル：毎週リクルートし、毎週テストし、毎週知見をまとめます
• 共感を育むため、チーム全員が少なくとも一部のセッションを観察します
• プロトペルソナは精緻化され、最終的にはエビデンスに基づくペルソナに置き換えられます

プロダクトへの応用：

コンテキスト	応用方法	例
毎週のユーザビリティテスト	毎週木曜日に3～5人のユーザーでプロトタイプをテストします	進行役を交代する「テスト木曜日」の習慣
リリース後の学習	アナリティクスを確認し、追加で3件のインタビューを実施します	離脱箇所を見つけ、離脱したユーザーにインタビューします
ペルソナの検証	プロトペルソナの仮説をインタビューデータと照らし合わせます	「パワーユーザーはマーケターだと想定していましたが、データによると運用マネージャーです」

倫理的な境界線： 十分な説明に基づく同意を得てリサーチを実施します。参加者は、データの利用方法を理解し、いつでも自由に参加を取りやめられる必要があります。

6. アジャイルとの統合

中核となる概念： リーン UX は、デュアルトラック開発を通じてアジャイルの中で機能します。ディスカバリー（何を作るかを学ぶこと）とデリバリー（それを作ること）を並行して進めます。

効果がある理由： デザイン作業はデリバリースプリントにきれいには収まりません。ディスカバリーを1スプリント先行させることで、デザインがいつまでも後れを取るのではなく、デリバリースプリントの開始時に検証済みのデザインを用意できます。

主なポイント：

• ディスカバリートラック（リサーチ＋デザイン）からデリバリートラック（エンジニアリング＋QA）へ成果を引き継ぎ、1スプリント先行させます
• ユーザーストーリーには、受け入れ基準に加えて仮説と成功指標を設定します
• UX の「完了の定義」には、ピクセルをリリースしたことだけでなく、検証済みの学びも含まれます
• 無効と判定された仮説に基づくバックログ項目は、先送りせず削除します

プロダクトへの適用例：

コンテキスト	適用方法	例
スプリント計画	スプリントの目標に仮説の検証を含めます	「スプリントの目標：インライン編集によってタスク時間が20％短縮されることを検証する」
バックログのリファインメント	ストーリーに実験結果を添付します	仮説の検証後に初めて、ストーリーをデリバリーへ進めます
レトロスペクティブ	デリバリーの速度と併せて学習の速度を振り返ります	「今スプリントでは、4つの仮説を検証し、2つを無効と判定しました」

倫理上の境界： リーン UX を、アクセシビリティ、セキュリティ、コンプライアンスを省略する口実にしてはいけません。これらは、検証する仮説ではなく、譲れない品質基準です。

ディスカバリーをデリバリーのペースに組み込む方法については、references/agile-integration.md を参照してください。スプリントを1つずらして進めるデュアルトラックの仕組み、仮説をストーリーに含める方法、UX の完了の定義について説明しています。

プロジェクトの進め方を検討するために、一連の流れを示す例が必要な場合は、references/case-studies.md を参照してください。4つの複合シナリオ（エンタープライズ、スタートアップ、エージェンシー、社内ツール）を通じて、前提、実験、実施前後の成果指標を紹介しています。

よくある間違い

間違い	うまくいかない理由	対処法
MVP をローンチとみなす	MVP と最初のリリースを混同し、作り込みすぎてしまいます	捉え方を改めます。MVP は学習のためのツールであり、プロダクトのローンチではありません
前提の明示を省略する	隠れた前提が、コストのかかる不意打ちになります	キックオフで30分間の前提整理セッションを実施します
成功基準のない仮説	実験が成功したかどうかを判断できません	指標、しきい値、サンプルサイズを事前に決めます
デザイナーだけで進めるデザイン	引き継ぎの無駄、認識のずれ、反復の遅れが生じます	チーム全員でデザインスタジオのセッションを実施します
リサーチを一つのフェーズとして扱う	フィードバックが遅れ、役に立たなくなります	軽量なリサーチをすべてのスプリントに組み込みます
無効と判定された仮説を無視する	テストで失敗した機能を作ってしまいます	無効と判定された項目をバックログから削除し、方向転換するか取りやめます
協働する代わりに文書を作成する	誰も読まない40ページの仕様書ができます	仕様書を、共同デザインによる共通認識に置き換えます
成果ではなくアウトプットを測定する	行動を変えない機能をリリースしてしまいます	成功を、デリバリーではなく行動の変化として定義します

クイック診断

UX プロセスやデザイン計画を監査します。

質問	いいえの場合	対応
前提が明示されていますか？	隠れた前提が意思決定を左右します	前提のマッピングワークショップを実施します
検証可能な仮説がありますか？	意見をもとに構築しています	デザインを始める前に、標準形式で仮説を記述します
実験は、問いに答えられる範囲で最も忠実度の低いものですか？	学びを得る前に過剰な投資をしています	紙のプロトタイプやスモークテストに切り替えます
チーム全体がデザインに参加していますか？	引き継ぎによる無駄や認識のずれが生じます	デザインスタジオのセッションを予定します
毎スプリント、リサーチを実施していますか？	フィードバックのループが遅すぎます	毎週テストを実施する体制を整えます
アウトプットだけでなく、成果も追跡していますか？	学びを得ないままリリースしています	機能ごとに行動変容の指標を定義します
UX の作業はアジャイルに円滑に組み込まれていますか？	デザインがボトルネックになっている、またはスプリント 0 の罠に陥っています	スプリントの開始時期をずらしたデュアルトラックアジャイルを導入します
最近、誤りだと判明した仮説を挙げられますか？	学んでおらず、確証バイアスに陥っています	実験ログを見直し、方向転換を称えます

参考資料

方法論、リサーチ、事例について詳しくは、以下をご覧ください。

• "Lean UX: Designing Great Products with Agile Teams" Jeff Gothelf と Josh Seiden 著
• "Sense and Respond" Jeff Gothelf と Josh Seiden 著（成果重視の考え方を組織全体に広げる方法）

著者について

Jeff Gothelf は組織デザイナー、コーチ、著者です。TheLadders や Neo Innovation などの企業で 15 年以上 UX チームを率いてきました。検証されていない成果物にチームが何か月も費やす様子を目の当たりにしたことから、Lean UX を生み出しました。Josh Seiden はデザイナー兼プロダクトストラテジストで、25 年以上の経験を持ちます。Cooper でインタラクションデザインの実践を共同で立ち上げ、Neo Innovation ではマネージングディレクターを務めました。2 人は共著で Lean UX と Sense and Respond を執筆しました。