Lean UXとは
「リーン、スタートアップ」以外にも「デザイン思考」と「アジャイル開発」の概念を基盤としている。
かつては、物理的なものを作るため、細部のデザインを決め切ってからでないと、瑕疵があった場合の損失が莫大になってしまっていた。
しかし、昨今ソフトウェアに、継続的デリバリーという概念が導入され、製造上の制約を受けなくなってきた。
例えば、Amazonの運営するEコマースサイトでは、毎秒何らかのコードが追加されデプロイされているという。
マーケットからのフィードバックを得て、学習したことに基づき、イテレーションを繰り返す。ユーザーとの継続的な対話となる。
これにより、ユーザーのニーズを満たしているか、期待値を上げていけてるかという結果を生み出していくことをLean UXで行う。
しかし、デザイナーがアクセシビリティから、ページロードの時間、美しいインターフェース、ワークフローを作って渡していくのでは、コミュニケーションのコストが増えてしまい、より目を向けなくてはならないようなプロダクトの戦略的決定に影響を与える情報収集に時間が割けなくなる。そこで、チームメイト同士の共通理解が重要になる。
Lean UXを取り入れることで得られる3つの効果
- UXデザインのプロセスから無駄を取り除くのに役に立つ
- デザイン、開発、プロダクト/サービス間の対話を進めるために必要な作業(デザイン、リサーチ、ライティング)のみを行う
- 対話を最小限にすることで、長時間の交渉から解放される
- それらのための、チームの学習を促進する
- 部門横断のコラボレーションを促す
- プロダクトマネージャー、QAエンジニア、マーケティング担当者などを部門横断で透明性のあるコラボレーションを促す
- デザイナー以外の人も、デザインプロセスに関与する。
- デザイナーが何をすべきかを明確にして、チーム全員の参加を促す透明性の高いプロセス。
- 実験と検証に基づく学習をすることでマインドセットを変える
- 特定の人物に頼って1つの視点から最適なソリューションを導き出そうとするのではない。
- 迅速な実験と測定によって、自分たちの作る体験に客観的な視点でとらえられるようになること。
- そんとあめ、デザイナーの役割は、単に中間生成物を作るだけではなく、デザインのファシリテーターへと進化し、他のメンバーも新たな責任を担うことになる。
受け入れるのが難しいもの
「未完成」や「醜い」状態の中間生成物を人に見せなければならないこと。
最初の設計に時間や労力を多く費やすほど、その後の柔軟な修正は難しくなる。
大切なのは、コードのデプロイではなく、顧客に与えるポジティブなインパクトである。
そのためには、学習とイテレーションの継続が大事になる。
Lean UXの基盤
元々
- インタラクションデザイン
- 情報アーキテクチャ
- グラフィックデザイン
などの多くのデザインを包含している。
しかし、その中心には、人間のニーズがあり、人間のニーズを特定するところから始まる。
人間を直接的に観察することを原動力とするイノベーション手法であり、人々が生活の中で何を必要として、特定のプロダクトやパッケージ、サポートなどの方法を好んでいるのかを観察すること。
その考え方には、ビジネスのあらゆる側面は、デザイン手法でアプローチできるというデザイン思考により、明確な立場をとっている。
そして、アジャイル開発のコアバリューと以下の面で完全に調和している。
- プロセスやツールよりも個人との対話を
- 包括的なドキュメントよりも動くソフトウェアを
- 契約交渉よりも顧客との協調を
- 計画に従うことよりも、変化への対応を
Lean UXの原則
自身とチームを正しい方向に導くための原則
- チームビルディング
- チームや組織文化の指針
- プロセスの指針
チームビルディング
- 部門横断的
- 小規模、専念、同一環境で作業する
- 10人以下のチーム
- チームは一つのプロジェクトに専念し、同じ場所で作業をする
- リモートワークだと何かを逃してしまうという考えによる
- 自己充足的で、権限を持つ
- チームが外部依存なしでプロジェクトを進められるようにする
- チームに対して以下のような権限を与える
- 直面する問題の解決方法を決定する
- ユーザーや顧客と直接関われる
- これによりチームが直接、マーケットから学ぶことができる
- 課題焦点型
- 機能の実装ではなく、ユーザー課題の解決を目標にする
- 共通理解
- チームが一緒に働きながら時間をかけて築いていく集団的な知識
プロセスの指針
- これまでと同じことを速くやるのではなく、仕事の進め方を見直す
- プロダクト開発のフェーズに注意する
- 調査フェーズ、デザインフェーズ、開発フェーズ、テストフェーズなど
- そのような「フェーズ」と名がつくときは、何かが間違っているという警告サイン
- アジャイルの中で、これらのフェーズをすべて断続的に行うべきなため
- フェーズでは、プロセスステップが完了するだけで、生成物を完成させるには、フェーズで区切るのではなく、断続的に仕事を進める方法に移行する必要がある。
- 外に出る
- かなり早い段階で見込みユーザーからのフィードバックをもらう
- ユーザーの行動と要望、その理由を理解する
- プロダクトの成否を最終的に決めるのは、チームではない。
- あなたがデザインした「購入」ボタンをクリックするのはユーザー
過去と現在のプロダクト開発フローの違い
昨今では、完成品が見えた上でプロダクトを作ることはない。
つまり、何を構築しなけっればならないかが正確に分かっていることが前提となる開発はほとんどありえない。
マーケットの変化に対する機敏な対応が求められるためだ。
しかし、現在でも要件を固めた厳密さというのは、「以前はうまくいったから」という根拠のない自信によって横行されてしまい、
要件の完全性に疑問を持つ個人やチームはトラブルメーカーとみなされてしまい、プログジェクトの納期が遅れたりスコープを超える作業が発生した時の責任が押し付けられてしまう。
ユーザーは裏切る
現在、我々は
- 一貫性
- 予測可能性
- 安定性
- 確実性
が低い現実にいる。
そのため、消費者行動の変化に対応した新たなメンタルモデルを構築していく必要がある。
例えば、Amazonでは、毎秒1回リリースが行われるというようなユーザー体験をより良いものにする機会を得ている。
その中でも消費者は、自分たちが直感的で使いやすいと思って作ったUXの期待した行動とは異なる行動で我々を裏切ってくる。
そういった結果が出た時こそ、自分たちの要件が間違っていたと証明するものになる。
どうすれば良いか？
まず我々は、要件を「権威をもって表現された単なる思い込み」であると認識すべき。
そのため、「人間の行動は予測できるものではない、そのため我々が取り組んでいるものは高リスクなことである」ということを理解する必要が出てくる。
そこで、これまではLean UX キャンバス といったものを取り入れることで、自分たちのアイディアを「検証可能な思い込み」として新たな方法で表現していた。
キャンバスの使い方
どんな時に使う？
キックオフミーティングに最適な枠組みを提供してくれる。
キャンバスには以下のメリットがある。
- 一連のストーリーを推進するようにデザインされた連続的なプロセスに統合
- 複雑な要素を一つの視覚的モデルにできる
- ファシリテーションツールとして簡単に利用できる
- ブレーンストーミングではアイディアを出すことに躊躇しがちなメンバーに、意見を提出しやすい公平な場を提供する
- 共通言語の構築
- チームの仕事の枠組み
- チームの枠を超えて広く伝えられる
これらは、それなりの大規模なプロジェクトの計画を立てる際に、使用することでプロジェクトの大きさへの感覚が研ぎ澄まされていく。
主に次のようなものに直面している時に効果を発揮する。
- 未知のもの
- 不確実なもの
- 複雑なもの
流れ
- 基本的にキャンバスの作成には、2日間や1週間かかることもある
- 参加者はチーム全員
- 全員の参加を促すための仕組み
- まず、参加者が一人、短めの時間(5分程度)を決めて直感的に浮かんだアイディアを記載したり図式化する
- 一人での作業が終わったら、テーブルや小グループでアイディアを共有
- アフィニティマッピング(9章に出る)をしても良い
- 2人1組とかになり、アイディアを練る
- ペアワークは時間がかかるので1人の時より少し時間を多めに取る
- その後、発表をしてもらい、その時にディスカッションをしても良い
- 次に、各テーブルや、サブグループのアイディアを1つのプレゼンテーションにまとめる
- 最後に、最終的にアイディアを1つにするなら、グループ全体でアイディアを絞り、練り上げる
ボックス1: ビジネスプロブレム
ビジネスの抱える問題は何か？
ソリューションではなく、課題を認識した上で表現することが大事になる。
それがビジネスプロブレム・ステートメントになる。
具体的には以下の条件が満たされるべき
- 機能ではなく、解決すべき具体的な課題の提示
- 顧客中心の視点で、顧客のシエ高が最終目標となる
- スコープの対象となるもの、対象外のものを明確にするガイドラインと制約の明記
- KPI、ターゲットオーディエンスに求める具体的な成果として表現される明確な成功の基準の明記
- ソリューションを定義しない
そして、ステートメントは以下の3つの内容により構成される
- プロダクトの現在の目標
- なぜこのプロダクトが作られたのか
- どんな課題を解決することが目的だったのか
- どんな価値提供が意図されていたのか
- プロダクトによって何が変化したか？
- 達成された目標と、未達の目標
- プロダクトの改善要求
- 改善を成果として定量化するもの
エクササイズのプロセス
プロダクトマネージャーによる、チームにコンテキストや背景情報の提供がある。
具体的には以下のようなことの質問に答える。
- 問題があると至った観察・測定結果は？
- 誰をターゲットにした機能か？
- この機能の前者的な事業の中での位置付けは？
- この問題の解決で、全社の経営にどのような影響があるか？
これらに基づいて、ペアやトリオに分かれてステートメントのドラフトを作成する。
気を付けるべきこと
ソリューションを含めないこと
「〜を解決するためのモバイルアプリはどのように実装すれば良いだろうか？」
といったソリューションにしてはいけない
具体的であるべき
例えば、以下のような文が含まれているステートメントがあった
「ショッピング体験の向上を目指し、平均注文額を上げるために直感的なUIを実装した」
しかし、これでは何が実装されたのか漠然としているので、チームはUIのどの部分を改善対象にすればいいか分からなかった。
そもそも、直感的なUIは、あえて言うものでもなく、誰もが目指すものであるので、記述に対する意味はない。
ボックス2 ビジネスの成果
ユーザーの行動に焦点を充てる。
カスタマージャーニー
チームが注目すべき、価値ある顧客行動を見つけることが目的である。
現在の顧客がどういった行動をしているかを見るところから始める。
「海賊指標(AARRR)」「メトリクスマウンテン」のようなテンプレートも使える。
ボックス3: ユーザー
デザインにおけるペルソナは重要。
しかし、かけた労力に伴い、絶対的なものとして捉えてしまう傾向がある。
また、外部のリサーチチームやベンダーがペルソナを作成することがあるが、利用側と知識のギャップが生じやすい。
開発チームのジレンマ
開発者は、ユーザーと定義されたペルソナのことを、自分達と同じ人間と思いがちになる。
そのため、自分たち好みに作ってしまうという傾向がある。
エクササイズ
ペルソナの制定のための話し合いが必要となることもある。
以下のような流れで行う。
- どんな人がターゲットになるのか、プロダクトの利用によってどう影響するのかの意見を述べるところから始まる。
- ペルソナタイプのリストを作成する
- 「大学生」「ストリーミング好き」「医療従事者」などのターゲットセグメントを決める
- 最もターゲットになりそうなペルソナを3〜4人に絞り込む
- ペルソナのテンプレートを、ニーズや役割によって区別するように作成する
- 小グループに分かれて、テンプレートに沿って各グループで1つ作成してもらう
- 結果を全体で持ち帰って検討する
ペルソナは一度決めて終わりではない
基本的にペルソナは一度定めたら終わりではない。
エクササイズを行って制定されたペルソナが正しいかどうかを確かめるフェーズが必要になる。
例えば、ペルソナとして想定した人を見つけられない場合、潜在ユーザーはいないということになる。
同じように、ペインを解決しようとしても、潜在ユーザーを集めて話を聞いてみると、課題となっていない場合もある。そうなると存在しない課題を解決しようとしていることになってしまう。
- 例
ある投資家達の、プレゼン資料やタームシートや、資本政策などをまとめるためのアプリを考えていたが、実際に話してみると年に１、２度しか投資を行わなかった。
それくらいであれば、メールやExcelで十分管理できてしまうということになり、無駄に労力をかけることを避けることができた。
ボックス4: ユーザーの成果とメリット
ユーザーの成果は役割によって異なる。
「ビジネスの成果」「顧客の成果」「ユーザーの成果」の違いについて考えてみる。
たとえば、ある会計ソフトを取り上げてみる。
顧客: 経理部門の効率を上げて、建て替えできない費用への支払いを減らし、全体的な運用コストを下げること
ユーザー: 早く経費を精算し、短時間で正しく経理データを入力すること
どちらも、行動ベースの成果だが、視点が異なる。
異なるグループの人が、異なる目標を指している。
購入者: 経理部の効率化の実現によって、上司に評価されたいという目標ができ、それを達成できるソフトを探す。
ユーザー: 面倒な手続きなしに精算できるようになることを望んでいる。
感情的な目標を達成できたかどうかになる。
しかし、感情的な目標を定量的に計ることは難しいが、かなり重要。
難しいからといって、注目しなくてもいいわけではない。
もし、適切に定量化ができれば、その定量的な測定基準において良い成果をあげることにつながるため。
エクササイズ
そのため、Lean UXキャンバスの、このセクションでは感情面に注目した議論を行う。
ペルソナが何を求め、プロダクトを探し、見つけた時に何をするのかを理解することを議論の目標にする。
注意すべきこと
機能に意識が向きすぎてしまうことがある。
それが顧客のモチベーションになると思い込んでいるから。
Apple は、競合他社が「12メガピクセルのカメラ」と機能をアピールする一方で、「外国にいる祖母に、赤ちゃんの姿を見せよう」と宣伝する。
ボックス4: ユーザーの成果とメリット
ユーザーの成果は役割によって異なる。
「ビジネスの成果」「顧客の成果」「ユーザーの成果」の違いについて考えてみる。
たとえば、ある会計ソフトを取り上げてみる。
顧客: 経理部門の効率を上げて、建て替えできない費用への支払いを減らし、全体的な運用コストを下げること
ユーザー: 早く経費を精算し、短時間で正しく経理データを入力すること
どちらも、行動ベースの成果だが、視点が異なる。
異なるグループの人が、異なる目標を指している。
購入者: 経理部の効率化の実現によって、上司に評価されたいという目標ができ、それを達成できるソフトを探す。
ユーザー: 面倒な手続きなしに精算できるようになることを望んでいる。
感情的な目標を達成できたかどうかになる。
しかし、感情的な目標を定量的に計ることは難しいが、かなり重要。
難しいからといって、注目しなくてもいいわけではない。
もし、適切に定量化ができれば、その定量的な測定基準において良い成果をあげることにつながるため。
エクササイズ
そのため、Lean UXキャンバスの、このセクションでは感情面に注目した議論を行う。
ペルソナが何を求め、プロダクトを探し、見つけた時に何をするのかを理解することを議論の目標にする。
注意すべきこと
機能に意識が向きすぎてしまうことがある。
それが顧客のモチベーションになると思い込んでいるから。
Apple は、競合他社が「12メガピクセルのカメラ」と機能をアピールする一方で、「外国にいる祖母に、赤ちゃんの姿を見せよう」と宣伝する。
ボックス5: ソリューション
ソフトウェア開発では、全てを俯瞰し、いくつかの制約を設けておく方が良い結果が得られる。
ここまで、ビジネスプロブレム・ステートメント、ビジネスの成果、ペルソナ、ユーザーの成果やメリットについて議論してきたので、制約を設けてきた。
これらの制約は、ソリューションを作り出すための空間をつくるものになる。
この段階では細かなデザイン作業は、まだ行わない。キャンバスが完成してからになる。
様々なブレーンストーミング
アフィニティマッピング
最もシンプルかつ、チームを協力させることができる方法。
一つの質問をチームにし、5分かけて各自が書き出したアイディアにつちえ議論をし、最適なのを導き出す。
質問: ペルソナが望む成果を実現するために、どのようなソリューションをデザイン・構築すれば良いか？
デザインスタジオ
5~8人のチーム
オンラインの場合、Miroなどのボードツールを使用
手順
- 課題の定義と制約やリスクの明確化
- 各メンバーによるアイディエーション(多様性)
- プレゼンテーションとフィードバック
- 2人人組でのイテレーションとアップデート(形成)
- チーム全体でのアイディエーション(集約)
課題の定義と制約条件
チーム全員で、解決しようとしているビジネスプロブレム、取り組みの成功を定義する成果、ペルソナ、ユーザーの達成しようとしているメリットを共有する。
これまでやってきているので、全員が認識を持っている状態であるが、一緒に作業していなかった人がいる場合は、説明し質疑応答をする。
各メンバーによるアイディエーション
5分ほどで行う。
6分割に罫線が引かれたテンプレートを利用する。
それぞれのボックスに、ペルソナとペインを上部に書き、それぞれの解決策のラフなスケッチを書いていく。
様々な図形などを使って表現しても良い。
プレゼンテーションとフィードバック
1人3分でプレゼンテーションをチーム全体に対して行う。
良いフィードバックには、自分の意見を述べるより、相手に質問をする方が効果的である。
質問をする方が、チームが議論しようとしていることについて議論がしやすくなる。
逆に質問ではなく、意見を述べると、議論が活性化せず、コラボレーションも起こりにくくなる。
その結果、メンバーは自己弁護的になる。
2人1組でのイテレーションとアップデート
10分ほどで行う。
ここで、できれば同じアイディアを持つメンバーを2人1組にする。
書くペアで、それぞれデザイン案の改良に取り組む。
目標は、各ペアが最もメリットのあるアイディアを選び、それを進化させ、統合することである。
何を残し、何を変え、何を捨てるかの決断は難しい。
そのため、一般的、抽象的なアイディアにしがちになるが、そうならないように注意する必要がある。
チーム全体でのアイディエーション
45分ほどで行う。
チーム全体で、有望なアイディアを絞り込む。
ここで選択されたアイディアは、次のプロセスである仮説の構築と、その後のデザインと実験の基礎になる。
選択されなかったアイディアも、一時的にためておくためのバックログを作るようにしておくと先に進みやすくなる。
注意すべきこと
参加者が平等に参加できるようにすること。
ただし、リモートセッションでは、難しいツールではなく付箋を使えば楽なところが、とても難しくなる。
チームが下流で行う機能やデザインの選択に対して、抵抗を示す可能性が出てきてしまう。
このような時、チームのデザイナーにとってデザインファシリテーションが極めて重要なスキルになる。
ボックス6: 仮説
ここでは、ペルソナであるユーザーがプロダクトを使うことでどのような利益を得られるのかということを宣言する。
ビジネスの成果を達成するのに、ユーザーの成果を達成する必要があり、どんな機能がそれを可能にする ということを信じるフェーズになる。
この場合、複数のペルソナや機能を対象にしていることに気づくことも多々ある。
そうした時、複数の機能を同時に行うのは難しいので、一つの機能のみを目指すということを目指していくようにする必要がある。
ボックス7: 最初に学習すべき最重要事項は何か？
仮説の中で、どれを最初にテストすべきかを決める必要がある。
人々はソリューションを必要としているのか？
彼らはそれを探すだろうか？
試してみるだろうか？
使うだろうか？
価値を見出すだろうか？
などに考えていく必要がある。
初期段階において、とても重要になる。
これらの質問が全て、いいえと答えられるのであれば
どのようにデザインするか、構築するかについて考える必要はなくなる。
そのため、最初に学習すべき最重要事項は何か？にフォーカスを当てる必要がある。
そこで、チームの合意が必要となるが、合意に達しないのであれば、さらなる情報が必要となる。
そのためには、どれを対象にするかについてひとまずの決定を下し、実験を行う。
この決定は、プロダクトマネージャーが下すことになるが、選ばなかった仮説や前提、リスクを完全に捨てるわけではないということに注意。
とりあえず、特定の仮説を対象にして進めるだけで、誤りと証明されれば、仮説のバックログに戻り、このプロセスを行なっていく。
ボックス8: MVPと実験
最後のステップである、ボックス8 では実験に焦点を当てる。
Lean UXキャンバスの2つの重要な質問の一つは、「次の最重要事項を学ぶために必要な最小限の作業は何か？」に対する、仮説検証のための実験である。
つまり、MVPの作成になる。
優れたMVPは、価値と学習の両方を創造する。
しかし、Lean UXではMVPは学ぶことに重点を置く。
MVPを構築するには
まず最初に必ず、「次に学ぶ必要がある、もっとも重要なことは何か？」を考える。
核心を突く
ナビゲーション、ログイン、パスワード取得フローなどは、アイディアそのものがターゲットオーディエンスにとって無価値である場合、考えても意味がないので後回しにする。
明確なCTA(コール・トゥー・アクション)を使う
サービスの選択やサインアップの機会を提供することで、ユーザーの興味の度合いや、実際に金を払ってくれるかどうかを判断しやすくなる。
行動を測定する
実際の行動を測定できるMVPを構築する。
人々の言葉で説明する自らの意図に惑わされずに、実際の行動に焦点を当てることができる。
ユーザーと話す
MVPを通して、何をしたかは分かったが、「なぜ」の部分が分からないと意味がない。
そのため、意図通りに使った人と、そうでなかった人の両方から話を聞く。
優先順位付けを重視する
優先順位が大事なので、有効であることが検証されていないアイディアを気に入ってるからという理由で固執しないように注意。
しかし、デザイナーは楽観的に物事を考える傾向があり、考案するのに5分のものも5ヶ月のものも、自分たちのソリューションはよく寝られたものだと思いがち。
実験の結果が期待に反したものであれば、その期待は間違いということを忘れないこと。
アジリティを維持する
アップデートが容易な方法やツールを用いて実験やプロジェクトを進める。
0から作ろうとしない
アイディアをテストするためのツールやシステム、仕組みはすでに多く存在している。
既存のツールを使って学習をする方法を検討する。
電子メール、携帯メール、チャットアプリ、Facebookグループ、Shopifyストアフロント、ノーコードなど
プロトタイプの種類
- ペーパープロトタイプ
- 低忠実度のオンスクリーンモックアップ
- 中〜高忠実度のオンスクリーンプロトタイプ
- ノーコードMVP
- コーデッドプロトタイプ、ライブデータ・プロトタイプ
コラボレーティブデザイン
コラボレーティブデザインを主導するのは、従来と同じく、デザイナーになる。
コラボレーティブデザインのためのミーティングを主足し、メンバー間のコミュニケーションを促す。
カジュアルな形式の会話や、
スケッチのセッション、
ホワイトボードの前でのエンジニアとの本格的な1on1のセッション
など
一般的な流れ
- チーム全体でスケッチをする
- デザインのアイディアについて議論し、チーム全体で意見をまとめる
- 成功の見込みが高いと思われるソリューションを1つに絞り込む
デザイナーは従来通りデザインを行いながら、チーム活動のファシリテーターを行う。
Lean UXとデザインスプリント
デザインスプリントとは
- チームを集め
- 質問を定義
- アイディアを出す
- 試作品を作る
- テストする
というのを5日間で行う。
ただ、デザインスプリントでは仮説やMVPといったLean UXで登場する言葉は出てこない。
そのかわり、スプリントの最終日にプロトタイピングとテストを行う。
この点は、対立しているように感じられることがある。
ジェイク・ナップのインタビュー
Lean UXは、プロダクトサイクル全体、組織全体で使える料理本のようなもの。
対して、デザインスプリントは、チームの特定のメンバーが特定の瞬間に特定のものを作るための、1つのレシピ。
実験の中の実験という形で、デザインスプリントの中でオリジナルを試しながらチームを観察し、少しずつアレンジしていく必要があると言う。
ただ、プロダクトの細部を決めるものではないので、全体の開発スケジュールを計画したりするためのものではない。
MVPの代わりにもならなければ、ゼロから立ち上げまでの道筋を提供するものにもならない。
特定の期間に最大限の効果を発揮する。
Lean UXのプロセスでのデザインスプリントの使用
Lean UXでは、作業を「構築すべきもの」ではなく、解決すべき課題として再構成することが奨励される。
Lean UXでは、課題、オーディエンス、潜在的ソリューション、成功について前提を明確にすることを推奨する。これにより、良い仮説が立てられ、デザインスプリントの構成にも役立つ。
仮説が、デザインスプリントの開始地点となる。
スプリントで行った作業を使用して、これらの前提を細かく検証し、仮説を洗練させて次のステップを明確にする。
デザインシステム
デザインシステムを利用することで、画面構造、プロセスフロー、情報設計などの決定（ホワイトボードで作成できるもの）を適切なチームメイトが担当し、色、フォントタイプ、スペーシングなどを別のチームメイトが担当することができる。
これにより以下の2点が促進される。
- デザインの高速化
- プロトタイプの高速化
組織に対しても大きな利点がある。
- 一貫性の向上
- 品質の向上
- コストの削減
リモートのコラボレーション
分散型のチームとのコラボレーション
コラボレーションを容易にできる、重要なポイントが2つある。
- 全員が同じ条件で参加できるようにすること
- 自由なコミュニケーションを促す仕組みをつくること
全員が同じ条件で参加できるようにすること
自分以外が会議室にいて、自分だけ電話でミーティングという状況とかが分かりやすい。
ホワイトボードに付箋を貼ったりとかになると、電話で参加している人は難しくなる。
そのために、使うツールを適切に選ぶこと。
例えば、MuralやMiro、共有ドキュメントなど、オンラインホワイトボードを使用するなど。
自由なコミュニケーションを促す仕組みをつくること
オンラインミーティングでは、唐突に始まり、唐突に終わる。
それもメンバーを集め、アジェンダを細かく定め、時間通りに終了するという杓子定規な方法で行われるが、実際のオフラインでは会議の前に廊下で軽く雑談をしたり、ミーティングが始まるまでの間、あれこれと話をする。
ミーティングが終わったあとも、一緒に会議室を出て、コーヒーを飲みながら感想を述べあったりする。
こういったコミュニケーションが仕事の本質とは無関係ではなく、重要な意味を持つ。
こうしたコミュニケーションを通して絆が生まれ、一緒に仕事ができている。
ワーキングアグリーメント
各スプリント後に行われるレトロスペクティブをサポートするドキュメント。
コラボレーションを進めていく上でのどんな合意がチームにあったかを記録する。
合意した内容に従って作業が進められているかどうか、新たな合意内容を追加するために更新すべきかどうか、不要な古い合意を削除するかどうかを確認する。
以下のようなことを書く。
プロセスの概要
定期的なコミュニケーション
どんなコミュニケーションスタイルか？デイリーはいつするのか？企画会議やでもを開催するのはいつか？
コミュニケーション/ツール
ドキュメント化するためにどのようなシステムを使うか？
プロジェクト管理ツールは？アセットはどこに保管しているか？
チーム文化/安全性/対立関係の解決
どのようなチーム文化が望ましいか？
安心してチームメイトと働くために、個人として何が必要か？
対立が起こったらどうするか？
意見の相違の解決方法は？
労働環境と時間
誰がどこで働く？
メンバーがオフィスにいる時間は？時差は？
要件とデザイン
要件定義、ユーザーストーリーの作成、優先順位付けをどう扱うか？
ユーザーストーリーを作成するのはいつか？
開発方法
どのようなプラクティスを採用するか？
ペアプロするか？テスティングのスタイルは？
ソース管理方法は？
開発中の制限や制約
バックログとアイスボックスのサイズは？
プロセスの各段階にどのようなWIP制限が存在するか？
デプロイ
リリースの流れは？どのようにユーザーストーリーを受け入れるするか？
その他いろいろ…。
心理的安全性
A Culture of Safety(著者アラ・ウェインバーグ) 引用
「チーム内に、ミスを認める、質問をする、新しいアイディアを提案する、などの行為が恥ずかしいことと見なされず、抜歯もしないという共通の信念があること」と定義。
フィードバックとユーザーリサーチ
Lean UX におけるユーザーリサーチは断続的である。
進行中の採掘にフィットする一口サイズのユーザーリサーチを行う。
ユーザーリサーチは、専門のリサーチャーに外注せず、チーム全体で行い、責任を分担する。
これにより、詳細な文書がなくても、意思疎通を図ることができ、学習の質も高まる。
重要なのは、チーム全体で共通理解を深めること。
ユーザーリサーチ
ユーザーリサーチによって得られた未加工のデータから、意味のある情報を取り出すのは、時間のかかるフラストレーションのたまりやすい作業。
そのため、リサーチ結果を外部に委託してしまうことがあるが、これはできれば避けるべきこと。
ユーザーリサーチが終わったら、できれば同日、少なくとも翌日に、チーム全体でレビューを行う。
ユーサーリサーチの結果
結果をまとめようとすると、データが矛盾を示すケースが出てくる。
このような時の対処法は以下。
- パターンを見つける パターンとは、特定の要素に対してユーザーの意図が繰り返し向けられていることを意味する。パターンに当てはまらない場合は、異常値であるとみなす。
- 異常値は、駐車場に置く（いったん脇に置く） 異常値を見つけた時は、無視する（またはソリューションで対処する）。 しかし、暫定的なものとしてバックログに記録しておく。 継続していくにつれ、他の異常値が見つかることで、パターンが示される場合がある。
- 他のソースを使って検証する あるチャネルから得られたフィードバックの妥当性に確信が持てない時は、他のチャネルを使ってそれを確認する。 カスタマーサポートのE mailを対象にしたユーザーリサーチの結果は、ユーザビリティのリサーチ結果と同じ懸念を示しているか？ オフィス内外のユーザーは、プロトタイプの価値について同じ意見を持っているか？ そうでなかったら、サンプルに偏りがあったと考えられる
カスタマーサービス
カスタマーサポートに連絡し、取り組んでいるプロダクトやサービスの部分について、ユーザーからどのような話を聞いているかを尋ねる。
今月、ユーザーが好んだものは何か、好まなかったものは何かを議題にする。
月末にカスタマーサービスとコミュニケーションをすることで、チームは自らの取り組みが成果を上げているかどうかを知るための明快な指標を得ることができる。
課題が上位10件のランキングにとどまっていれば、ソリューションが効果をあげていないと判断される。
オンサイトでのフィードバック
以下オプションで、フィードバックの仕組みを設ける。
- シンプルなEメールフォーム
- カスタマーサポートフォーラム
- サードパーティのコミュニティサイト
これにより以下のような目的のリサーチで使える。
- サイトの特定セクションから受信したEメールの数をカウントする。
- オンラインディスカッションに参加して仮説をテストする。
- 被験者が見つけにくい場合には、コミュニティサイトを活用して募集する。
検索ログや、サイト利用状況の分析、ABテストによって、機能の使われ方や使いやすさを調査する。
サイト利用状況には、KissmetricsやMixPanelといったサードパーティのメトリクスプロダクトを用いることができる。
ABテストには、Optimizelyなどのサードパーティツールを使うことができる。
アジャイル
Lean UX をアジャイルの仕組みにどう適合させるかについて。
アジャイルの仕組みの重要なポイント
- 短いサイクルで作業を進める。
- 各サイクルの終わりに価値を提供する。
- 毎日、簡易的なプランニングミーティング（デイリースクラム）を開く。
- 各サイクルの後にレトロスペクティブ（振り返り）を行う。
重要なことはレトロスペクティブ
スクラムをやるとした場合、最初にやらないといけないことは、最初１、2回のスプリントの後にレトロスペクティブを取り入れること。
そこでは、チームの課題について気軽に本音で議論できるレトロスペクティブにしなくてはならない。
「何がうまくいっているのか？」「何がうまくいってないのか？」「今後、何を変えて行きば良いのか？」などを検討する。
スタッガードスプリント
デザイン工程をスプリントを一つズラして行うこと。
しかし、これは小さいウォーターフォールを行っているようなもので、ウォーターフォールからアジャイルに移行する時には有効だが、最終的な目標ではない。
なぜなら、同じことに対してチーム全体で取り組んでいる訳ではないから。
部門横断的なコラボレーションのメリットが得られない。
マルチスプリントテーマ
プロダクトゴールは、一連のスプリントをつなぐために用いるマルチスプリントテーマとみなせる。
それぞれのスプリントのテーマに対して、デザインスプリントを用いる。
つまり、仮説、検証、改善を顧客の価値基準で試していく。
デザインの細部について話すわけではなく、あくまで顧客が使うか、それによって得られるメリットを念頭に置いて、スプリントを繋ぎ合わせていく。
エクスペリメントストーリー
デザインスプリントなどでカバーしきれなかったディスカバリ作業を、そのイテレーションで追加的に実施する必要がある。
それにより以下の利点がある。
- ディスカバリ作業を可視化する
- デリバリー作業への優先順位付けが必須になる
- ユーザーストーリにーに対しての優先順位を、いつするか、どれを作業しないについて議論する
プランニングには全員が参加する
全ての活動（スタンドアップミーティング、レトロスペクティブ、プランニングミーティング、ブレーンストーミング）にチーム全体が参加すべき。
それにより、共通理解が学習され、たとえ9割が自分に関係のないことだとしても、関わる1割の情報によってその後の作業の何時間かを節約できるケースがある。
ステークホルダーとリスクダッシュボード
プロダクトオーナーやステークホルダー、CEO、クライアントは状況を詳しく知りたがる。
プロジェクト計画を自らの判断で承認したがるから。
しかし、成果重視型のチームにとって、プロジェクト計画は学習した内容に応じて変化していくもの。
そのため、1回の計画で予定する作業量は多くない。せいぜい1つまたは2つ先の凍レーションを計画している程度。
しかし、マネジメントはこのような計画を「近視眼的な」ものと捉え不満を抱きがち。
そう言う中で、マネジメントに上の介入をされないようにするための方法。
事前対応的なコミュニケーション
追加した機能をリリースすることを事前に告知しておくというもの。
そのために、強力なツールとしてリスクダッシュボードを作成しておく。
これによって、ステークホルダーに次のような情報を提供できる。
- 作業の進行状況
- 次に注力すべきリスク
- 機能セットではなく、成果（目標に向かってどのように前進しているか）を重視していること
- 依存関係のある部門（カスタマーサービス、マーケティング、オペレーションなど）と、これらの部門が、今後自らに影響を及ぼし得る変化を認識しておくことの必要性
ロードマップ
これまでは、ロードマップがソフトウェア業界では使われていたが、デジタルプロダクトの開発は、直線的ではなく、イテレーション的なものなので、顧客行動を見て、どう影響を与えるかを観察し、再びイテレーションを回す。
そのため、出発点と明確かつ機能固有の終点（つまり締切）がある従来の直線的なロードマップモデルは、結果重視のデジタルビジネスの手法を反映するものであり時代遅れである。
プロダクト主導型では、成果主義を取り入れる。
そこで、成果ベースのロードマップを採用する。
エージェンシーにおけるLean UX
ここでいうエージェンシーとは、クライアントにサービスを提供する組織全般を指す。
エージェンシーにとって、クライアントとの業務では、クライアントの意向によるので、期待されることもあれば、やり方を拒絶されることもある。
そう言った場合でもLean UXは活用される重要なポイントが5つある。
どのような方式のビジネスか？
エージェンシーは、成果物ベースのビジネスをやることが多い。
これはLean UXとは合判するもの。
そのため、成果物を作るために稼働率を上げることを目的にしがちになってしまう。
そうすると、部門横断型のコラボレーションもできなくなってくる。
これらの解決しなければならない2つの課題に対するアプローチ。
従来型の成果物ビジネスから脱却すべき
タイムアンドマテリアル（工数単価）色のモデルに変えること アプリやデザインを売るのではなく、クライアントが抱える問題のソリューションを見つけるためにクライアントと共同作業をすることの対価として、報酬を得る形。 ソリューションは、プロジェクト開始段階では分からないが、それを一緒にクライアントと探す。
稼働率を高く維持するためには、少人数のチームを明確な更新基準の契約に基づき、期限付きで売り込むこと。
通常3ヶ月更新の契約で仕事をする。
そのため、短期間サイクルでの仕事の進め方を行いやすくなる。
これにより、仕事の進め方が合わないクライアントのために延々と働き続けなければならないというリスクも減らすことができる。
実験に誰もお金を払わない
クライアントは実験が嫌いで、実験にお金は絶対出したくないという考えが多い。
10万ドルの予算のうち、1万ドルを実験費として残りの9万ドルの最適な使い方を探る費用にしようと提案すると渋るだろう。
しかし、実験とはLean UXの一部ではありますが、単なる戦術である。
学習、適切な意思決定、ポジティブな成果を生み出すプロセスの一部である。
