Lean UX 第2版を読みました #techplaygirls #hayaoki_girls #leanux

TECHPLAY 女子部の朝活時間を利用して、年明けから「Lean UX 第2版」を読みました。

読み始めたきっかけは、朝活の雑談からでした。
前職で採用していた「デザインスタジオ」を取り入れた開発スタイルがとても気に入っていたという話をしていて、デザインスタジオのやり方などが掲載されている本書を紹介したところ、第2版が出ていることに気づきました。
第1版は手元にあったのですが、デザインスタジオのやり方の部分だけを拾い読みしただけだったので、全体を読んでみようと思い読書会のスタイルにして女子部メンバーに呼びかけました。

私が時間を作りやすいのが朝5時からの1時間のため、月水金の朝5時からZoomを利用したオンライン読書会というのを基本のスタイルとして、「朝5時はちょっと。。」という方はSlackでの非同期参加を可能にしました。
非同期参加のメンバーがいることを踏まえて、オンラインで読むときも「今からここを読みます！」とSlackに書き込んで各自黙読し、読書メモや会話メモをスレッドに残していきます。
非同期メンバーはそれを読んで、さらに自分のメモなどを残していきます。
該当日が祝日の時はスキップしたり、朝5時に起きれなかったり、ということもありつつ、約3ヶ月で読み終わりました。

本書は「リーンシリーズ」とされているうちの1冊で、「リーン・スタートアップ」を起点としてデザイン・コンテキストへの適用方法を包括的にまとめたものとされています。
はじめ「リーン・スタートアップ」を読んでいないけれど大丈夫かな？と思いましたが、私は今までいわゆるアジャイル開発と呼ばれるような環境の中で仕事をしてきたので、あまり違和感なく読み進められたと思います。
（リーン・スタートアップの思想とアジャイル開発の思想の違いについてはネットの情報をながめた程度なので、厳密には違うという理解であることをここに記しつつ、今回はこの件については深く触れません！）

まず第Ⅰ部を読み始めた時、その基本原則がものすごくわかりやすく簡潔にまとめられていて、あらためて驚きました。
たしか第1版のときも第Ⅰ部は読んだはずなのですが、簡潔に書かれすぎていてちょっと読み流してしまったように思います。
今回はそうならないように慎重に読むようにしました。
とにかく知見の塊、さまざまな場面ケースを想定され網羅されていると思います。
ただやっぱり簡潔に書かれているので、あまり読んでいてもおもしろくない部分かもしれない。。

第Ⅱ部は、基本原則を踏まえたうえで実践的な手法について書かれていて、本書の要となる「チームが共通理解をもってコラボレーションすること」「フィードバックとリサーチを継続的に行うこと」における具体的な動き方が解説されています。
私が大好きな「デザインスタジオ」がなぜ必要か、どんな成果をもたらすのか、そしてその後どのように活用していったらいいのか、ということをより深く理解できたと思います。

特に印象に残った部分をいくつか取り上げていきます。

①課題ステートメントのテンプレートが埋められない
3章の「ビジョン、フレーミング、アウトカム（成果）」ではチームの出発点としての課題ステートメントに対して、とてもわかりやすいテンプレートが提供されています。
テンプレートは既存のプロダクトおよびサービス用と、新規のプロダクトおよびサービス用にわかれています。

私が現職で開発しているサービスについて、「なんとなくわかっている」気になっているけれど、このテンプレートにのせてみてより理解を深めてみたいと思います。
さてあなたも現在開発しているサービス・プロダクトについて考えてみてください！

「（サービス名）」は、「（目標）」を達成することを目標にしている。
しかし、このサービスは「（目標）」を達成しておらず、私たちのビジネスに「（悪影響）」を生じさせている。
「（測定可能な標準）」に基づき、ユーザーの成功率を向上させるためには、どのように「（サービス名）」を改善すれば良いか？

目標？悪影響？測定可能な基準？？？

え、どれも答えられない。。（ごめんなさいごめんなさい）
復職したらここの確認からはじめたいと思います！！

そのあとに出てくる「ビジネスに関する前提」や「ユーザーに関する前提」についてワークシートもめちゃくちゃ参考になりました。
こちらも全然埋められないので、復職したら以下同文。

②プロトペルソナは更新する
ペルソナを作成する場面は多くあると思いますが、一度作成してしまうとそのままだったりしていませんか？
そもそもペルソナがチームメンバーなかで共通理解されていますか？

本書では仮説の構築と検証を継続的におこなっていくなかで、ペルソナの更新も継続的におこなっていくべきとしています。
たしかに、はじめ想定していたペルソナがあったとして、チームが学習していったり社会が変化したりサービス・プロダクトが成長していく中で、ペルソナも変化していく可能性は十分にあり得ます。
ただ、たいていの場合その変化はチームメンバーの暗黙知として流れていってしまうもので、「ペルソナが変化」していることがドキュメントとして更新されていくことがのぞましいよなぁと思いました。
ドキュメントの更新、、（また別の問題ですね）

③コラボレーティブなデザインでチーム全体のプロダクトIQとデザインIQがあがる
ここほんとうに大好きなところなんですけど、
デザイナー職のメンバーがつくった成果物を開発者が実装する、という流れはよくあると思うのですが、
そのときに、そのデザイナーさんのつくった成果物がどういう背景でどういう思考を経てそうなったのか、あまり理解しないで実装することもあると思います。
Lean UXでは、それだとチーム全体で共通理解ができていない、チーム全体が当事者意識をもっていない、としています。
当事者意識はひとまず置いておいて、共通理解という点は大いに共感します。
とくにデザインスタジオだったり、デザイナーさんがデザイン案を起こす前に機能要件についてデザイナーさんと開発者で話をする機会があると実感するのですが、
メンバー全員で課題を理解して仮説をたて、アイデアを提案しあうことができるので、いざデザイン案を作成するときや開発に着手するときのコミュニケーションが減らせたりスムーズだったり、ドキュメントの作成が不要になったり、いいことが多いと感じます。
本書ではその状態を「チーム全体のプロダクトIQが高まりデザインIQが高まる」としています。

職能ごとに分業することで効率化をはかることもできると思いますが、既存プロダクトに新たな機能を追加したいときなどは、チーム全体でコラボレーションすることでよりよいものが作れるのではないかなぁと思います。
（私はそんな開発がしたい！）

④MVPで得られるものの大きさ
MVP（Minimum Viable Product）は実用最小限の製品と訳され、確実性が証明されていないアイデアに投じる労力を最小限に抑えながら、アイデアの取捨選択に大いに役立ちます。
わりとなんでも作りたがるのがエンジニアのサガですが、ここはグッとこらえて、その仮説を最小限の労力で検証するためにはどうしたらいいか？を考えます。

今回この本を読んでいる間に、個人的にはじめたサービスでそれを実体験しました。

私は以前より煎茶道をたしなんでおり、お茶会を開いたりお点前を教えたりしていました。
今回、茶道具とお菓子とオンラインレッスンをセットにしたサービスを考えたのですが、そのリリース方法を悩んで足踏みをしていました。
当初考えていたのは、ECサイトを構築できるプラットフォームを利用して、セットを販売することでした。
プラットフォームを利用するとさまざまな恩恵が受けられるうえに、見た目もよいと思ったからです。
しかしそのプラットフォームを利用するまでの準備が大変に感じてしまい、かつ私が考えていた、セットの販売からオンラインレッスンまでのフローがそのサービスだけでは簡潔しないため、いろいろ思案しているうちに億劫になってしまったり、進捗がよくありませんでした。
そこで本書でMVPを項目を読み始めたときに、ふと自分のサービスについて立ち返りました。
「そもそも、このサービス利用してくれる人がいるかわからないのに、こんなに準備に手間取っているのは時間の無駄では？」
「まずはこのセットを購入しようとしてくれる人がいるのか検証したほうがいい！」
そう思い、まずは私がササッと作成できるサービスを利用してセット販売をできる部分だけ用意して、リリースしました。
（具体的には、ペライチをesaで作成して、申し込みをGoogleフォーム、連絡手段はEmailとしました）
するとリリースからひと晩で数件の申し込みがあり、このセットの需要があることが確認できたのです！
その後は、まずはその数件の申し込みからオンラインレッスンまでの流れを構築しつつ、仮説検証しながら、フローができあがりました。
次は、よりよい申し込み体験をつくるべく、新しい課題を見出しています。（続く！）

本書では「MVPを構築するには？」という項にこのあたりの重要ポイントがきれいにまとまっています。
ほんとうにほんとうに参考になる箇所なので、個人サービスなど作っている人やプロダクトオーナーは絶対読んだ方がいいよ！と言いたいです。（いやもうみんなすでに読んでいるのかもしれないけど）

実装例として笑ったのは、「嘘の機能」というどこにもつながらないボタンを設置してその需要を確かめる例で、そんなの遭遇したらイヤだ！と思いました。
あと「オズの魔法使い」の例として、（これは本書にあった例ではなくて人に聞いた話ですが）プロトタイプのAlexaは中の人が本当のヒトだったとか。。

でも実際に動くものが触れると、体験できると、そこから得られる情報は量も質も確かなものになりますね。

第Ⅲ部は、実際の組織の中でLean UXを実践していくにはどういった問題に直面するか、その問題とどう折り合いをつけるか、著者の実体験などにもとづいたTipsが丁寧に書かれていて、とても参考になりました。
アジャイル開発との共存方法や最後のケーススタディから学べることはたくさんありましたが、おそらくLean UXをこれからはじめていこう！という時には、第8章にある「組織に求められる変革」という項目がより参考になるのではないかと思われます。
この部分は読んでいて著者の熱が感じられたので、さまざまなクライアントと接するなかで得られた知見なのだろうと容易に推測できます。

全体を読み終えて、あらためて感じたのは、、

「サービスおよびプロダクトについて、チーム全体で共通理解をして、協働（コラボレーション）して、学習し続ける」
そんな環境で開発するの、めっちゃ楽しそう〜！！

私もこれまで以上に、当事者意識をもって、時には部門も横断して、チームみんなでいいモノを作っていきたいな！！と思いました。
4月からの復職前にこの本を読むことができてよかったです。

（ちなみにこの本は現在所属している会社の福利厚生で購入しました！）
（育休中でも福利厚生は利用できるよ！）
（え？どの会社？と思ったかたはこちらをみてね！ https://www.bm-sms.co.jp/recruit/ ）