LEAN UXを読んだメモ（第2章）

LEAN UXを読んだメモ（第1章）

LEAN UXのプロセス

1. 前提の整理、仮説の設定、成果を得る
2. デザインと開発
3. MVPの構築
4. リサーチの実施と学習
これら４つのLEAN UXのサイクルをどのように実施するかが第2章の概要です。

1. 前提の整理、仮説の設定、成果を得る

前提の整理をまず行う。これは関連する全ての部門と領域の人間で決めると良い。決める前提は以下４つ。
・ビジネスの成果とは
・ユーザとは
・ユーザの成果とは
・機能とは

ビジネスの成果を決める際にはアウトプットイメージでなく、アウトカムイメージを持って決めると良い。
「いついつまでにこのプロダクトを作る」
みたいなものはNG。
「マーケットのAs-isはこれ。hogehogeペインがあるので、解決するためにはこのプロダクトが必要になる（そのためhogehogeリスクを排除するためにはどうすれば良いか）」
みたいに、解決すべき明確な課題を設定すると良い。

ユーザイメージを持つにはプロトペルソナを作り、ユーザの共通イメージをチーム全員で持つことは重要。プロトペルソナは状況によって常にアップデートする必要あり。

ユーザの成果として、ユーザが求めるものを宣言することでソリューションの重要ポイントを見つけることに役立たせる事ができる。
整理するためには付箋やホワイトボードに書き出しながらブレインストーミング・プロセスを行うと良い。

機能について考える際も同様ブレインストーミング・プロセスを行うと良い。
ここではユーザのペイン・ニーズを解決するための検討を行う。その機能リストを作成し、テーマ別に分類する。

上記４つが揃ったのち、関連するアイディアを１行ずつまとめる作業をする。
関連が低いなどギャップが出てきたら外すか別の言葉に書き直すかする。
そうすることで、チームの共通理解が得られる。
リスト（７行から１０行程度が理想）ができたら、優先順位づけを行う。

（自社でできているできていないをメモする）
・ディスカッションを重要視している社風のため、ビジネスの成果をイメージすることは全員ができている
・ペルソナは良く作られている
・ユーザの行動を並べ、それに伴うペインや対処する機能を一覧化している
・４つそれぞれを並べて評価するということはしていないように思う

2. デザインと開発

エンジニア、非エンジニア全員がデザインに関わるコラボレーティブなデザインを行うと良い。それは対人コミュニケーションが最強のツールとなる。

デザインを一人で考えるより、例えばフロントエンドエンジニアに来てもらい、インフォーマルに話し合うだけでも共通理解を得て最速で作業できる。

デザインスタジオという正式なセッションを用いた方法もある。ここで出てきたアウトプットは次のステップに活用できる。
３時間ほどメンバー全員を集めて行う。プロセスは以下の通り。
1. 課題の定義と制約やリスクの明確化
　・このセッションで解決する問題、前提、ユーザなどを全員が理解する
2. 各メンバーによるアイディエーション
　・メンバー全員が個々に紙などにアイディアを書き込む
　・難しい場合はペルソナとペインを書き込み、その解決策を書くという順序も良い
3. プレゼンテーショントフィードバック
　・１人３分で上記をプレゼン
　・聞く側は好き嫌いではなく、理解に務める
4. ２人１組でイテレーションとアップデート
　・２人１組に分けて修正し合う
　・進化・統合させるとより良い
5. チーム全体でのアイディエーション
　・チーム全体で有望なアイディアを絞り込む

実際にどんな画面をアウトプットするかについて、０ベースで構築するような余計な手間を省くためにデザインシステムを用いる方法も近年注目されている。
デザインシステムの価値は一貫性、品質の向上、コスト削減にある。
実用的で誰でも見やすいものとなることが求められる。

組織で難解と感じられる分野間コラボレーションを実現するために、レトロスペクティブとチームワーキングアグリーメントは良い解決方法。
・レトロスペクティブ：
　各スプリントの終わりに開催される振り返り
・チームワークアグリーメント：
　コラボレーションを進めていくにあたり合意したかの記録。ルールブックのようなもの。
　合意内容はアップデートされていく。

・ディスカバリーとデリバリーがインフォーマルに話すことは時々だがある。最近少しずつできているかも・・・？
・デザインスタジオ？なにそれ美味しいの？状態だった。やってるのか知らない
・レトロはやっている。
・チームワーキングアグリーメントはやっていない。やってもいいかも

3. MVPの構築

ビジネスの課題解決を知るための資源を得るため、必要最低限の労力で学ぶためのモノをMVPと言ったりする。
何を学習したいかを明確にし、プロトタイプを作成する日数との兼ね合いを見ながら構築することが良い。（これがかなり難しい）

プロトタイプ構築には主要なワークフローに焦点を合わせることが重要。
プロトタイプには主に以下４つがある。下に行くほど再現レベルの高いものになる。
1. ペーパープロトタイプ
　・紙とペンなどで感覚的に表現する
　・最も低コストで作れる
　・限定的なオーディエンスだし、実際のイメージとはだいぶ異なる
2. 低忠実度のオンスクリーンモックアップ
　・クリック可能なワイヤーフレームなどのこと
　・実際のイメージが掴みやすい
　・実際に作成することなく、迅速に用意ができる
　・ラベルなどの配慮がされないといけなく、これを操作できる人はある程度限定される
3. 中〜高忠実度のオンスクリーンプロトタイプ
　・実際にプロダクトなどで動作するワイヤーフレームを作る
　・実物に近いので、より多くの人に高い再現度によるフィードバックがもらえる
　・実データではないので、シミューレーションできるインタラクトには偏りが生じる
　・作成、メンテナンスに時間がかかる
4. コーデッドプロトタイプとライブデータプロトタイプ
　・仮装データや実データを用いた必要最低限の動作をする機能をプロダクトに入れ込む
　・最もリアルなシミュレーションを実現できる
　・エンジニアよ、完璧に作っちゃだめだぞ

・MVPは適切に作っている気がする。
・ただ、無駄にレベルの高いモックやプロトを作ってしまっている可能性

4. リサーチの実施と学習

MVPの評価をするフェーズ。前提から妥当性かどうかを確認していく作業。
採取的な目標はチーム全体での共通理解を深めること。

コラボレーデティブ・ディスカバリはチームで協力しながらアイディアをテストするプロセス。全員で外に出てユーザに直接話を聞く。
この工程の全てをリサーチャーなど外部に任せるのはNG。ファシリテーションをしてもらい、一緒に行くのはGood。

ラボを設置し、定期的にユーザをオフィスに連れてくることで継続的な学習もできる。ただし、その場合はユーザ・オフィスの作業員どちらにも不快にならないよう場所については考えておく。

リサーチ結果は多くの未加工データとなる。ここから意味のあるデータを取り出す作業を行う。（これが辛いらしい）
中には矛盾するデータが含まれるが、これは放棄せず、異常値として一度横に置く。後に意味のあるパターンが見つかる可能性もある。

カスタマーサービスはユーザと日常的に話す人物なので、その知見を生かす。
オンサイトでフィードバックアンケート調査を行う手法もある。
ログやA/Bテストも効果的。

・リサーチ会社なんて使ってたっけ？うちにはいらないのかな？
・ラボがある。オフィスに近いが別の場所に設置している。
・うまくリサーチを回しているかは微妙なところ。MVPが必要とならなっていないからか、そこまでやる時間がないのか。

（第２部長かった・・・）