『リーンUX』を読んだ個人的まとめ

サイロごとには先進的
なのに会社全体では絶望的

リーンにプロジェクトを進める
最後にはデザイナーの分厚い資料のプレゼン
失敗

責任は？
おしゃれなデザイン会社
エンジニア
経営幹部
システム全体にある

サイロを壊す
ユーザーが喜ぶことを原点にまとまる

—-

なぜリーンUXか？
需要があるか
それは事実か
わからない
仮説検証サイクルで進むしかない
フィードバック・ループ
（真っ暗で何が置いてあるかわからない部屋から脱出）

健全なプロダクト開発
マラソン
459回やれば失敗する可能性は1%
「早く失敗して成功を早める」

—-

リーンスタートアップ
「最大の価値を持つアイデアに最大のリソースを投じるための手法」

リーンUX
アジャイル開発しながらデザインニーズにも応える

ピクセル単位の仕様書
拍手喝采
日の目を見ない

未完成や醜い状態で見せる恐怖
克服する

大切なのはコラボレーション
学習とイテレーションの継続

—-


##【Lean UXへのイントロダクションと基本原則】

人間中心デザイン
UX
デザイン思考
「人間を直接観察することを原動力とする」

アジャイル
　プロセスやツールより対話を
　ドキュメントより動くソフトウェアを
　交渉よりユーザーとの協調を
　計画に従うよりも変化への対応

リーンスタートアップ
　構築、計測、学習
　MVP


Lean UXの原則
チームビルディングの原則
　部門横断的チーム
　　エンジニア、PM、デザイン、マーケ、QA
　小規模同一場所のチーム
　　10人以下
　　コミュニケーション、集中、連帯感
　自己充足的で権限持つチーム
　　外部との依存関係なし
　　ユーザーや顧客と直接関われる
　課題焦点型のチーム
　　機能実装ではない
　　課題解決が目的
　　　当事者意識の芽生え
　　　独自の解決策
チームや組織文化となる原則
　疑問から確信へ
　　全ては推測や仮定
　　機能ではなくユーザー行動の変化を重視する
　無駄を取り除く
　　フォーカスする
　共通理解を生み出す
　　集団的な知識
　ユニコーン、エバンジェリスト、ヒーローは不要
　　チームワークの方が大事
　失敗を許容する
　　実験は失敗がつきもの
　　　創造性が高まる
　　　陶器の例
　　　自転車の例
プロセスの指針となる原則
　バッチサイズを小さくしてリスクを減らす
　継続的に発見する
　　使い方、なぜかをチームで定期的に調査する
　GOOB : 新たなユーザー中心思考を使う
　　Getting out the building
　　建物から出る
　　購入するのはユーザー
　仕事を外面化する
　　付箋など
　分析よりも形にする
　　何かをつくって建物を出る
　中間生成物中心から脱却
　　ドキュメントでなくプロトタイプ



##【Lean UXのプロセス】

機能でなくユーザー行動の変化
機能でなく検証の継続

仮説とTDD

前提仮説
デザインと開発
MVP構築
実施と学習

機能でなく仮説から
課題にフォーカスするようになる

会社全体のKPI
マーブルチョコで投票

海賊指標
獲得
活性
継続
紹介
収益

「ユーザーが特定の機能を欲していることは滅多にない」
バナナスライサーの例

デザインシステムをつくる
Wikiベースでもよい

スプレッドシートでアイデア出し
一列目は名前
8人でやった
2枚目でテーマ分け

レトロスペクティブ
　週末の集まり

MVP
一つ目の考え
　学習を主目的とする
　　マーケットに価値を提供ではなく
　　マーケットが何を求めているか明らかにする
もう一つ
　できるだけ早く価値を提供する
　　小さなバージョンを作る

ニュースレターを出すべき？という例
ニュースレターを読みたい人がいるか
MVPとしてまずはフォームを作る
　どれだけの人が求めているか
求められていることがわかる
内容のMVP

仮説
その仮説で最初に学ぶべきものは何か
最小限の労力でそれを学ぶ方法は何か
リーン



MVP構築手順
核となるベネフィットと提示方法を考える
明確なCTAを使う
優先順位付けを重視する
　アイデアに固執しない
学習をすばやく繰り返す
ゼロから作ろうとしない
行動を測定する
ユーザーと話す
　なぜ？を特定する

MVPの難しさ
フォーカスは容易でない
　機能と課題を混ぜてしまう
学習目標を明確にする
小さく進める
コードがいらない場合もある
学習曲線を意識する

MVPの例
まずLPだけをつくる
どこにも繋がらないボタン
　Flickrのスクリーンセーバーとして使うボタン
オズの魔法使い
　Amazonエコーの例

体験のプロトタイプ
　ペーパープロトタイプ
　ワイヤーフレームモックアップ
　中から高忠実度のモックアップ
　コーデッドプロトタイプ

「仮説の妥当性を学習するために用意する実用最小限の製品」
MVPのポイントは学習である



顧客開発は継続的
リサーチャーはファシリテーター

フィールドワーク
インタビュー
最後に他に有益なフィードバックを提供してくれそうな人を紹介してもらう

ターゲットかどうか確認
仮説確認
インタビュー後にモックアップを触ってもらう

3-12-1
3人のユーザー
12時
週に1度

パターンを探る

カスタマーサポートと連携する




##【Lean UXの実践】

アジャイル開発のUXへの適用

スクラム
　時間区切りのサイクル
ユーザーストーリー
　ベネフィット
バックログ
　ユーザーストーリーのリストと優先順位
スプリント
　動くソフトウェアをつくる
　スクラムでは2週間
スタンドアップ
　日次定例
　自分が何をしているか
　どういう壁に直面しているか
レトロスペクティブ
　スプリントの最後の定例
　良かった点
　問題点
　チームとして改善すべきこと
　プロセスの最適化
イテレーション・プランニング・ミーティング
　バックログの優先度を決定
プロダクト・ディスカバリ
　学習活動
　何を提供するか
スプリント・ゼロ
　プロダクト・ディスカバリの時間
デザイン・スプリント
　アイデアからプロトタイプへ
デュアルトラック・アジャイル
　2つのバックログ
　ディスカバリ
　デリバリー



デュアルトラックアジャイル

プロダクト・ディスカバリ
　仮説アイデアをつくっていく
　ディスカバリ・バックログにまとめる
デリバリー
　検証されたアイデアを開発していく
　デリバリー・バックログにまとめる

ディスカバリとデリバリーを分けてはいけない
小さなウォーターフォールになる
あくまでチーム
顧客開発にできるだけ同席
　ドキュメントで即共有
　Google form
　スプレッドシート

デリバリーで得た検証結果
ディスカバリ・バックログにフィードバックする
段階で分かれているわけではない

最初はデザインスプリント
　1日から1週間
IPM
　デザインスプリントを成果物を使う
　ユーザーストーリーをつくり優先順位をつける
　1日
実験計画をたてておく
　仮説
　検証方法
　担当者とコスト
ユーザーフィードバックを計画しておく
　5営業日に１回　　
スプリント開始
全員が参加する
　エンジニアだけではない

「デザインはチームスポーツである」




ビジョンの共有
仕事の質を高める
　重要な機能は何か
　何を最初にすべきか
　ビジョンの共有の不足の現れ

「これが起きたらどうする？」
私は正しくあなたは間違っている
から
課題をどう解決するかに変える


社内ステークホルダーとうまくやるために
　イシューに対するロードマップを管理する
　事前に連絡する
　彼らに知らせる
　　進捗
　　実験と学んだこと
　　次の実験
　　リスクと対処方法
　成果にフォーカスしてコミュニケーションする
　影響がありそうな変更を伝える
　対処する時間を十分に取れるようにする

LeanUXとはマインドセットである

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

システムの主要機能
使い方によって分かってくる
　Twitterのハッシュタグ

デザイナーをファシリテーターにする
全員が同じレベルでコラボレーションする
ピザ2枚分のチーム

ヒーローは不要
美しいデザインがもたらすバイアス
デザインヒーローはいらない

PayPalの例
チームビルディング
　PM、デザイナー、エンジニア
「ピカソを台無しにする」のは避けたい
　ピクセル単位のデザイン
　実装可不可を答えるだけ