ottijp blog

LEAN UXを読んだメモ

ジェフ・ゴーセルフ著「LEAN UX」を読んだメモです.

cf. Lean UX 第2版 ―アジャイルなチームによるプロダクト開発 (THE LEAN SERIES) | ジェフ・ゴーセルフ, ジョシュ・セイデン, 坂田 一倫, エリック・リース, 児島 修 |本 | 通販 | Amazon

ざっくり言うと, エリック・リースによる”前書き”にあるように,「局所的にLeanを実践しているが,組織全体として最適化されていない」問題はよくある話で,それを解決する方法論としてUXに視点を置いて組織改革を行う,という手法です.

読む前に知りたいと思った質問

  • リーンスタートアップや他のLEANシリーズとLEAN UXとの違いや関係
  • アジャイル開発とLEAN UXをどう結合させるか
  • 組織にリーンのマインドを定着させるためにはどのような戦術があるか

全体所感

  • LEAN UX=デザイン思考+アジャイル開発+リーンスタートアップ
    • リーンスタートアップとUXベースのデザインを組み合わせ,共生的に共存させるもの
    • デザイナ以外の人もデザインプロセスに関与する
  • 重要なマインドセット
    • 透明性の維持
    • コラボレーティブ(全員参加)
    • イテレーティブ
  • BMLループを回すことや,小さく失敗し早く成功する価値観はリーンスタートアップと同様に感じた
  • ユーザ価値やビジネスゴールと実現方法(機能)を紐つけて,ビジョンから顧客へ提供するものまでを一貫するという点でIMPACT MAPPINGとの共通点を強く感じた
  • デザイナ以外の人もデザインプロセスに関与するための方法論が途中まで読んでもイメージが沸かなかったが,デザインスタジオの説明を読んで少し理解できた
  • アジャイル開発との共存については具体例があるものの,あまりうまくイメージできなかったので実務の中で試行してみる必要性があると感じた
  • デザイナが活動をリードするのが望ましいが,現実的にチームの中でデザイナがその立場で動けるかどうかは組織の文化が強く障壁になりそうだし,難しい組織が多いように感じた.アジャイル開発と同様,いきなりプロセスを適用するのが難しい場合は,LEAN UXのプラクティスを組織課題の解決として小さく適用するところから始めるのが良さそうに感じた.

1章 かつてないほどに高まるLean UXの重要性

  • Amazonは平均して11.6秒に一度の割合で本番環境に新たなコードを追加している
  • 継続的にデリバリし学習するのがよい
  • 機能やドキュメントではなく顧客価値や”効果”(outcome, not output)に焦点を合わせる
  • チーム全員がコラボレートし続ける継続的エンゲージメントでは情報伝達のための膨大な資料は不要(アジャイル開発の価値観と同じ)

2章 Lean UXの原則

  • LEAN UX
    • =デザイン思考+アジャイル開発+リーンスタートアップ
      • デザイン思考:人間を直接的に観察することを原動力とするイノベーション手法
    • コラボレーティブかつ部門横断的
    • チームの共通理解
    • デリバリよりも学習
  • 原則の要約
    • チームが一体となり,情報が透明性をもって共有され,共通理解されている状況を作る
    • 機能ではなくユーザ中心とした課題解決・顧客価値・アウトカムに焦点を当てる
    • 早く多く失敗し,未検証で顧客価値の無い中間成果物といった無駄を最小限にする
    • 繰り返し形にし,学習を続ける

3章 ビジョン、フレーミング、アウトカム(成果)

  • 検証すべき仮説を効果的に正しく設計する方法の話
  • 成果に焦点を当てるために,検証ステートメントとして宣言する
    • 課題ステートメントやワークシート(リーンキャンバス,リーンダイアグラムでよさそう)から推測・仮定のリストをつくる
    • 仮説ステートメントに変換する(仮説検証キャンバスでもよさそう)
  • 仮説の分類して考える(ビジネスの成果,ユーザ,ユーザの成果,機能)
  • ペルソナ作成はイテレーティブに行う(一回作って終わりではない)
  • ペルソナの効果
    • 共通理解(「犬」と聞いて誰もが同じ概念を想像しないのと同じ)
    • 自分たちがユーザであるという錯覚の排除
  • ビジネスゴールを達成するために起こさせるユーザの行動と,そのために提供する機能,という考え方がIMPACT MAPPINGと共通項が多いように感じた

4章 コラボレーティブ・デザイン

  • 仮説定義における実際のプラクティスの話
  • コラボレーティブ
    • ≠ヒーローベース
    • 共通理解と当事者意識を促進
    • ドキュメントの量は減る
  • デザインスタジオ
    • メンバによるインフォーマルなコラボレーションセッションを補うもの
    • 解決策のブレスト
    • 1-2-4でアイデアの集合知化を行う
    • 結果は常に参照可能な場所に置く
  • デザインシステム
    • ビジュアルデザインのフレームワーク(パターン)
    • AppleのHIGが代表的な例
    • (特にプロトタイプにおいては,)一からデザインを考えるのは悪手
    • ソフトェア開発でパターンやフレームワークを使うのと同様

5章 MVPとプロトタイプ

  • 実際のMVP構築における留意点の話
  • 行動を測定できるMVPを作る
  • 学習目標と,そのために必要な計測を意識する(BMLのLから思考する)
  • MVP構築と学習効果のROIを考慮する
  • 嘘の機能(つながらないボタン)の手法は,必要な際に思い出せるようにしておきたい(ユーザの印象が悪くなることもあるので,用法用量は守る必要あり)

6章 フィードバックとリサーチ

  • MVPを評価する話
  • コラボレーティブにイテレーティブにリサーチする
    • 「一口サイズ」のリサーチを繰り返す
    • リサーチを専門家に丸投げしない
  • 矛盾するフィードバックの対処
    • 異常値は一旦置いておき,次回以降のイテレーションでパターンに沿うかどうか見てゆく
    • 他のソースを使って検証する

7章 Lean UXとアジャイル開発の共存

  • 全員が参加し,デザインプロセスをチームメンバ全員で共有する
  • プロセス
    • インタラクションデザインとデベロップメントを並行させるスタッガードスプリント
    • ディスカバリとデリバリを並行させるデュアルトラックアジャイル
    • スタッガードスプリントでもデュアルトラックアジャイルでも,人をユニットに分けるのは悪手で,全員がすべてのプロセスに関わるのがよい
    • スプリント計画などのタイミングに合わせてデザインプロセスを設定する方法が考えられる
  • デザイナはアジャイル開発プロセスのすべての活動に参加すべきである
  • なんとなくわかるが,実際の活動がどうなるのかイメージがつきにくいので,実務で試す必要がありそう

8章 Lean UXの実践に際して組織に求められる変革

  • 結果より成果を重視する
  • 役割を超える
  • 部門横断的
  • ワークスペースの設置(同じ場所,中間成果物の掲示)
  • BDUP(Big Design Up Front),アジャイルフォールを避ける
  • speed first, aesthetics

second - 継続的改善,UXの負債の追跡

9章 ケーススタディ

  • LEAN UXやその適用系による成功事例の話
  • コラボレーティブなデザインプロセスへの変革
  • ペルソナとユーザインタビューと共感マップによる認識の補正イテーレーション
  • サービスデザインの適用

ottijp
都内でアプリケーションエンジニアをしています
© 2024, ottijp