図解で学ぶ「Lean UX」

図解で学ぶTHE LEAN SERIES

LEANUX

Lean UXは、

プロダクトデザインの進化形

最善のインタラクション・デザイン・テクニックと

科学的手法をブレンドし、

使いやすく、美しく、成功を測定できる製品を構築する

Lean UXは3つの概念で表すことができる

Lean UX

デザイナーにとってのプロセスの変化

仕事への新たな取り組みを提供するマインドセット

ソフトウェアを管理することについての考え方

Lean UX

デザイン思考

Lean UXの3つの基盤

アジャイルソフトウェア

開発

リーン・スタートアップ

Lean UXの3つの基盤：デザイン思考

デザイン思考

チーム内のさまざまな役割によるコラボレーションと、

全体的な視点でのプロダクトデザインの熟考を促す

Lean UXの3つの基盤：アジャイルソフトウェア開発

アジャイルソフトウェア

開発

1.プロセスやツールよりも、個人と相互作用

2.詳細で分厚い文書よりも、機能するソフトウェア

3.契約交渉よりも、顧客とのコラボレーション

4.計画の順守よりも、変化への対応

Lean UXの3つの基盤：リーン・スタートアップ

リーン・スタートアップ

• 「構築（build）－計測（measure）－学習（learn）」の

フィードバック・ループを用いて、プロジェクトのリス

クを減らし、開発と学習を迅速化

• チームは、できるだけ早く学習プロセスを開始するため

に、「MVP（実用最小限の製品）」を開発および出荷

Lean UXを実践するということは、

Lean UXは、コラボレーションと部門／領域横断的な手法によって、製品の本質を素早く明らかにするための実践的手法であり、これによって文書への過度な依存を減らし、デザイン中の製品の実際のプロダクト・エクスペリエンスへの共通理解を高めるものである。

製品の本質を素早く明らかにするための実践的手法

コラボレーション 部門／領域横断的な手法

デザイン中の製品の実際のプロダクト・エクスペリエンスへの共通理解を高める

文書への過度な依存を減らす

それによって

それによって

Lean UXの原則

1. 部門／領域横断的なチーム

2. 小規模、専任、同一場所

3. 進捗＝結果（アウトプット）ではな

く、成果（アウトカム）

4. 課題焦点型のチーム

5. 無駄を取り除く

6. バッチサイズは小さく

7. 継続的な発見

8. GOOBー新たなユーザ中心思考

9. 共通理解

10. アンチパターンーロックスター、

エバンジェリスト、忍者

11. 仕事の外面化

12. 分析よりも形にする

13. 成長よりも学習

14. 失敗を許容する

15. 中間成果物中心の仕事の進め方から

の脱却

Lean UXのプロセス

前提の宣言

実験の実行

MVPの作成フィードバックと

リサーチ

Lean UXのプロセス：前提の宣言

前提の宣言

実験の実行

MVPの作成フィードバックと

リサーチ

Lean UXのプロセス：前提の宣言

前提のリストの作成（優先順位付き）

Lean UXのプロセス：前提の宣言

実行する人 準備

関連するすべての部門／領域の代表者

1. 現行製品がどのように利用されているかを示す

分析レポート

2.製品の利用時における顧客の特定の行動を説明する

ユーザビリティ・レポート

3.過去の課題解決への試みとその成否に関する情報

4.当該の課題の解決が会社のパフォーマンスに及ぼす影響

についての、ビジネス・ステークホルダーによる分析

5.同じ課題に取り組む競合の動向を示す、競合分析

Lean UXのプロセス：前提の宣言

「課題ステートメント」

課題ステートメントをつくることで、

チームは明確な目的を持って仕事に取り組みやすくなる。

また、重要な制約の定義も行える。

グループで仕事を進める上では、制約が必要。制約は、チームが意図せぬ方

向に脱線せず、連携して前進できるようにするための、ガードレールの役割

を果たす。

Lean UXのプロセス：前提の宣言

3つの構成要素

課題ステートメント

課題ステートメント・テンプレート

［サービス/製品名］は、［目標］を達成する

ためにデザインされました。しかし、この

サービス/製品は、［目標］を達成しておらず、

私たちのビジネスに［悪影響］を生じさせて

います。［測定可能な標準］に基づき、顧客

の成功率を向上させるためには、どのように

［サービス/製品］を改善すれば良いでしょう

か？

1. 製品／システムの現行の目標

2.ビジネス・ステークホルダーが解決を求めて

いる課題

（すなわち、目標が達成されていない箇所）

3.特定の解決策が指定されていない、明示的な

改善要求

Lean UXのプロセス：前提の宣言

課題ステートメントには多くの前提が内在する。

チームには、課題ステートメントを吟味し、核となる前提を導き出すことが

求められる。

この作業には「ビジネス前提ワークシート」が活用できる。

Lean UXのプロセス：前提の宣言

ビジネス前提ワークシート（ビジネス）

1. 私たちは、顧客には＿＿＿のニーズがあると考えています。

2. これらのニーズは、＿＿＿によって解決できます。

3. 最初の顧客（予定を含む）は＿＿＿です。

4. 顧客が私たちのサービスから一番得たいと思っている価値は＿＿＿です。

5. 顧客は、＿＿＿などのメリットも得られます。

6. 私たちは、多くの顧客を＿＿＿を通じて獲得する予定です。

7. 収益は＿＿＿を通じて得る予定です。

8. 当該市場での最大の競合は＿＿＿になると予測されます。

9. 競合には、＿＿＿によって打ち勝つ予定です。

10. 私たちの最大のリスクは＿＿＿になると予測されます。

11. このリスクは＿＿＿を通じて解決する予定です。

12. 他の前提のうち、偽であると証明された場合にビジネス／プロジェクトに悪影響を及ぼす要因になるもの

として、＿＿＿が挙げられます。

Lean UXのプロセス：前提の宣言

ビジネス前提ワークシート（ユーザ）

1. ユーザは誰ですか？

2. 私たちの製品はユーザの仕事や生活のどの部分にフィットしますか？

3. 私たちの製品が解決する課題は何ですか？

4. 私たちの製品は、いつ、どのように使われますか？

5. どの機能が重要ですか？

6. 私たちの製品の外観と振る舞いはどのようなものですか？

Lean UXのプロセス：前提の宣言

前提のリストの作成（優先順位付き）

前提の評価各前提ステートメントを、評価しやすい形式、すなわち「仮説ステートメント」に変換

私たちは、［このステートメントが真であること］と考えています。

私たちは、市場からの以下のフィードバックを得たときに、自分たちが［正しい／間

違っている］ことを判断することができます、

［定性的なフィードバック］、［定量的なフィードバック］、［主要業績指標の変化］。

Lean UXのプロセス：前提の宣言

前提のリストの作成（優先順位付き）

前提の評価

仮説ステートメントの作成

基本的要素を組み立てるところから始まる

• 実現を目指している成果のリスト

• サービスの対象としたいペルソナの定義

• これらの状況において効果的だと思われる機能

Lean UXのプロセス：前提の宣言

前提のリストの作成（優先順位付き）

前提の評価

仮説ステートメントの作成

コラボレーション・デザイン

「デザインスタジオ」

部門／領域横断的なチームが集まり、デザインの課題への解決策を一緒に検討するための方法チームメイトが組織的な壁を乗り越え、意見を自由に述べ合うフォーラムの役割を果たす

他のメリットチームが正式なセッションだけでなく、非公式の個別のコレボレーションを頻繁に行うために不可欠な信頼が、メンバー間に形成させるようになる

Lean UXのプロセス：前提の宣言

「デザインスタジオ」

プロセス

1. 課題の定義と制約の明確化→15～45分間

2. 個別のアイディアの創出（多様性）→10分間

3. プレゼンテーションと批評→1人当たり3分間

4. イテレーションと洗練（形成）→5～10分間

5. チーム全体でのアイディアの創出（集約）→45分間

用意するもの

• 鉛筆• ペン• 油性ペン（複数色／太字）• ハイライトマーカー（複数色）• スケッチ用のテンプレート（1個/6個のボックスが印刷済のテンプレート、または11×17インチ[約28×43cm]の空白の用紙を6個のボックスができるよう折り曲げたもの）

• 25×30.5インチ（約65×80センチ）のイーゼルパッド（ノリ付き）

• 製図用のドットシール（または他の小さなステッカー）

Lean UXのプロセス： MVPの作成、実験の実行

前提の宣言

実験の実行

MVPの作成フィードバックと

リサーチ

Lean UXのプロセス： MVPの作成、実験の実行

まずは「何を学ぼうとしているか」を検討する

3つの基本的な質問

1. デザインの対象となっている解決策には、そもそもニーズがあるか？

2. 提供しようとしている解決策と機能には、価値があるか？

3. この解決策は、使いやすいか？

Lean UXのプロセス： MVPの作成、実験の実行

ガイドライン：学習を重視する場合

• 明確かつ簡潔であること• 優先順位付けを重視する• アジャイルを維持する• 行動を測定する• CTA（コール・トゥー・アクション）を使用する

ガイドライン：顧客への価値提供を重視する場合

• 機能的である• 既存の分析との統合• アプリケーションの他の部分との一貫性の維持

Lean UXのプロセス： MVPの作成、実験の実行

MVPをつくる最も効果的な方法の1つは、体験のプロトタイプをつくること

プロトタイピングとは、体験に近似したものを作成して、製品／サービス利用をシミュレーションすること

「プロトタイプ」

Lean UXのプロセス： MVPの作成、実験の実行

長所• 速ければ1時間程度で作成できる。• 配置とその変更が容易。• 低コスト。• オフィスにある材料を使って組み立てられる。• 多くの人が楽しめる面白い活動になる。

短所• プロトタイプの短時間でのイテレーションと複製に時間と労力がかかる場合がある。

• 実際のインプットメカニズム（マウス、トラックパッド、キーボード、タッチスクリーンなど）を使っていないために、シミュレーションが極めて人工的である。

• フィードバックがフローと製品の概要レベルに限定される。

「ラフなプロトタイプ：ペーパー」

Lean UXのプロセス： MVPの作成、実験の実行

長所• ワークフローの長さを再現しやすくなる。• 基本的なタスクを行う上での大きな障害を明らかにしやすい。• コア要素の検索性を評価できる。• 新しいものを作成することなく、既存の資産を活用して学習するために、「クリック可能な何か」を迅速に作成できる。

短所• これらの資産を使って操作ができる人のほとんどは、もともと未完成の製品をイメージできるたけの製品知識を持っている。

• 通常より多くの配慮がラベル付けや複製に求められる。

「ラフなプロトタイプ：クリック可能なワイヤーフレーム」

Lean UXのプロセス： MVPの作成、実験の実行

長所• 高品質の、実物に近いプロトタイプを作成できる。• ビジュアル・デザインとブランド要素を評価できる。• ワークフローとユーザインターフェース・インタラクションを評価できる。

短所• 完全なネイティブ・プロトタイプに比べると、双方向性が限定されている。• ユーザは通常、実データを使えないため、シミュレーションできる製品内のインタラクションには限りがある。

• ツールによっては、これらのプロトタイプの作成とメンテナンスには時間がかかる。高度なプロトタイプをメンテナンスし、実製品に対して同期させるためには、しばしば作業の重複が生じてしまう。

「高度なプロトタイプ」

Lean UXのプロセス： MVPの作成、実験の実行

長所• 本番環境のコードとして再利用できる場合がある。• 最もリアルなシミュレーションを実現。• 既存のコード資産からの生成が可能。

短所• プロトタイプの細かい点を議論する必要があるため、チーム内の話し合いが難航する場合がある。

• 望ましい体験を提供する、実動作するコードを作成しなければならないため、時間がかかる。

• 顧客に公開するために、コードを完璧なものにしたいという誘惑にかられやすい。

• 更新とイテレーションに時間がかかる場合がある。

「コーデッド・プロトタイプ」

Lean UXのプロセス： MVPの作成、実験の実行

非プロトタイプの計画時に考える質問

1. 何を学ぼうとしているか？2. 仮説を実証するために必要な、市場からの主要なシグナルは何か？3. 主要シグナルの指標となる、他の評価対象のシグナルはあるか？4. この情報を見つけるための最速の方法は何か？

非プロトタイプMVPの種類

• Eメール

• Google Ad Words• ランディングページ• 無効なボタン

「非プロトタイプMVP」

Lean UXのプロセス：フィードバックとリサーチ

前提の宣言

実験の実行

MVPの作成フィードバックと

リサーチ

Lean UXのプロセス：フィードバックとリサーチ

コラボレーティブ

Lean UXリサーチは、

継続的

Lean UXのプロセス：フィードバックとリサーチ

• チームとして、質問、前提、仮説、MVPをレビューする。チームとして何を学ぶ必要があるかを決定する。

• チーム全体で協議し、学習目標の達成のために、誰に話をすべきかを決定する。

• 会話の指針となるインタビューガイドを作成する

• チームを、インタビュー用のペアに分ける。各ペアでは、様々な役割や領域を組み合わせるようにする。

• 各ペアに、MVPのバージョンを1つ割り当てる。

• 各チームは、顧客／ユーザと会うために外へ出かける。

• 1人がインタビューを担当し、もう1人がメモをとる。

• 質問を開始し、対話と観察を行う。

• セッションの後半でMVPを実演し、顧客にそれを使ってもらう。

• 顧客のフィードバックをメモする。

• インタビュー担当者のインタビューが終わった後、メモ担当者にもフォローアップの質問をするチャンスを与える。

• インタビューの最後に、他に有益なフィードバックを提供してくれそうな人を紹介してほしいと顧客に依頼する。

チームとしてアイディアを市場で評価すること

「コラボレーティブ・ディスカバリ」

Lean UXのプロセス：フィードバックとリサーチ

例：3-12-1（3人のユーザ、正午12時、週に1度）の活動カレンダー

月曜日 火曜日 水曜日 木曜日 金曜日

参加者のリクルーティング・プロセスを開始

評価対象の決定

評価対象の洗練 評価対象の洗練

評価シナリオを作成

参加者のリクルーティング・プロセスの完了

評価実施日

チーム全体での所見のレビュー

所見に基づいて次のステップを計画

「継続的ディスカバリ」

Lean UXのプロセス：フィードバックとリサーチ

• カスタマー・サポートに連絡し、現在あなたが取り組んでいる製品の部分について、顧

客から何を聞いているかを尋ねる。

• カスタマー・サポートとの月次の定例ミーティングを催し、傾向を理解する。「今月、

顧客が好んだものは何か、好まなかったものは何か」などを議題にする。

• カスタマー・サポートの豊富な製品知識を活用し、あなたのチームが取り組んでいる課

題を、彼らならどのように解決するかを学ぶ。カスタマー・サポートに、デザイン・

セッションやデザイン・レビューに参加してもらう。

• あなたの仮説を、カスタマー・サポートのコールスクリプト（通話台本）に取り込む。

アイディアを評価する最も低コストの方法は、当該の課題に関連する苦情について電話

をしてきた顧客に、その修正案としてアイディアを提示してみること。

「カスタマー・サービス」

Lean UXのプロセス：フィードバックとリサーチ

• シンプルなEメール・フォーム

• カスタマー・サポート・フォーラム

• サードパーティーのコミュニティサイト

• サイトの特定のセクションから、いくつかのインバウンドEメールの受信数をカウント

する。

• オンライン・ディスカッションに参加して、仮説を提案する。

• 評価参加者が見つけにくい場合には、コミュニティサイトから募集する。

「オンサイトでのフィードバック・アンケート調査」

組織にLean UXを取り入れるために行う必要がある移行

• 結果（アウトプット）から成果（アウトカム）への移行

• 限定的な役割から、コラボレーティブパフォーマンスへ

• UXデザイナーの新たな技能の受け入れ

• 部門／領域横断的なチームの構築

• 小さなチームの構築

• オープンで、コラボレーティブなワークスペースの構築

• ヒーローに依存しない

• 「事前の大規模なデザイン」の排除

• スピードが第一、美しさはその次

• 課題解決に価値を置く

• UXの負債を受け入れる

• エージェンシー文化への移行

• サードパーティー・ベンダーとの連携

• 文書化基準の管理

• 状況の現実的な理解

• 問題への対処

Lean UXの核心は、

マインドセットである

参考

岡田 勝人｜Katsuhito Okada

P r o d u c e d b y