「LEAN UX」でチームのマインドチェンジと、行動変容が起きた話
株式会社スマートショッピングでデザイナーをしています、にーのです。
施策の要件定義やユーザーの体験設計などを、チームで採択していくのって、超難しいですよね。。。
弊社プロダクトチームでも、アジャイル開発が始まってまもなく。開発と施策の動かし方に齟齬が生まれていました。
今回は、「LEAN UX」と出会って、チームが変わっていった話を書きます。
プロダクトチームで起きていた課題
弊社のプロダクトチームは、PdMが3名おり、そのそれぞれがエンジニアを抱えている3つのユニットからなっています。
どのユニットにも共通して起こっていたことは下記の6つ。
施策はPdMが作って、デザイナーやエンジニアに渡すウォーターフォールになっている
PdMが作る”施策待ち”が発生してしまう
要件定義のドキュメントが巻物になりがちで、読み解く&取り出しにくい
なんだかんだでチームに内容がちゃんと伝わっていない（説明されたことを何度も聞いてしまう）
無駄に機能が多いものを作りがち
リリースまで時間がかかっている
その施策がうまくいったのか手応えがない
KPTでも何度か議題に上がったりしていましたが、なかなか良い打ち手がなく、改善に繋げられないでいました。
そんな時、たまたま読んだ記事と、参加した勉強会で「LEAN UX」という言葉を知りました。
「LEAN UX」との出会い
これを見た時に私は、これだーーー！となったのをよく覚えています。
「LEAN UX」は超雑にいうと、リーンスタートアップ＋デザイン思想＋アジャイル開発の３つから成り立つもの。
詳しくはもっと良い記事がたくさんあるので、ぜひそちらを参照してください。
https://note.com/hiroko_nozawa/n/n87bd423491a1
特にぶっ刺さったのは、「LEAN UX」で定めていた ”アジャイルじゃないこと”。
👿 詳細なワイヤー・仕様を決めて詳細にドキュメント化
👿 作成されたドキュメントを厳しくレビュー
👿 レビューで承認されたものを、エンジニアがドキュメントを見ながら決められた仕様通りに実装する
👿 この先やることを一度決めたら、ずっとその優先順位を変えずに進める
読んだとき、うわ、私たちこれをやってるじゃん・・・と震えたのをよく覚えています。
また、「LEAN UX」にはアジャイルと同じで原則となるものがあります。特に共感したのはこの４つ。
✅ 疑問から確信へ
検証されるまでは、すべてが推測や思い込みであるという前提に立つ。プロジェクトを進め検証すると、疑問から確信へ移動していくことになる。
✅ 結果（アウトプット）ではなく、成果（アウトカム）を重視する
機能やサービスは結果（アウトプット）である。機能やサービスで達成を目指すのが成果（アウトカム）。チームはなによりも「価値を生み出すユーザー行動における、測定可能な変化」を目指す。
✅ ユニコーン、エバンジェリストやヒーローは不要
個人のパフォーマンスではなく、チームの連帯感やコラボレーションを重視する
✅ 中間生成物中心の仕事の進め方から脱却する
デザインプロセスの焦点を、ドキュメントの作成から、目的とする成果を実現することへとシフトさせます。部門横断的なコラボレーションが進むことで、話の中心は、何を開発するかではなく、どのような成果を達成すべきかに移っていきます。
当たり前と言えば当たり前の話なんですが、これを施策に持ち込むのが難しい。小手先だけではなく、マインドから変えていく必要があると感じました。
「LEAN UX」をベースに、チームでのベストプラクティスを深ぼった
早速チームに、今の課題と解決策として「LEAN UX」を共有しました。
まず最初にやったことは、今の施策のドキュメントとの照らし合わせでした。当時使っていた施策のドキュメントにも、テンプレートがあります。
それと「LEAN UX」を見比べて足りないところを比較しました。
弊社の施策ドキュメントで、特に足りないと感じていたのは、「ビジネスのインパクト」と、「仮説検証」でした。
施策ドキュメントには、ユーザーへのニーズやメリットなどは詳細に書かれていましたが、なぜ今この施策をやるのか、この施策をやるとどんなビジネスインパクトが生まれるのか？の背景的な説明が少ないと感じていました。
チームは上から出されるロードマップに従って行動しているだけに過ぎず、なぜそのロードマップがそうなっているかの話をきちんと把握できていませんでした。（その発想もなかった）
また、仮説検証の部分は特にすっぽり抜け落ちてしまっている部分であり、この施策はどうなったら成功と言えるのか？そのために何を検証するのか。ここがないままに機能を作っているので、達成感がないことにつながっていることも大きな問題と感じていました。
これに合わせてユーザーの体験設計も行ってはいましたが、PdMから提示された解決策に従ってのベストを考えていたため、根本からの問題定義をし始めると、大きく時間をロスしてしまうという課題もありました。そのようなことが起きると、要件定義のやり直しで時間がかかり、ムダが多く発生してしまいます。
さらには、PdMが作ったものをデザイナーがジャッジし、その後にエンジニアのジャッジという完全なるウォーターフォールだったので、エンジニアの部分で実装が難しいとなると、デザインも作り直すという…今思うと本当に良くないサイクルでした。
振り返ると問題だらけですが（笑）、こういう問題って、単純にチームとしてまとまっていなかったということなんだろうなぁと改めて。
最後にデザイナーとしてジレンマがあったことは、デリバリーを早くすることを優先したあまり、削ぎ落とされるおもてなしのUI…。
そこがないと一般的でなくなったり、ある一方方向からしか操作出来なくなってしまう…などユーザーの操作感を犠牲にして泣く泣くなくされた機能がありました。
結局そこを捨てていくことは、ユーザー体験を捨てていることと同義であり、使いにくいものが誕生していくだけでは？そして、「いつかやる」は来ないジャン！？と悩んでいた時期があったりもしました。
その使われるかわからないフィルターの代わりに、こっちを優先してくれよと思ったこともありますが、「あったらいい」を切り崩すのは至難の技です。
チェンジマインドと施策の流れの変更
「LEAN UX」の話をしてから大きくチェンジマインドしたのは、何を検証するのかを意識しだしたことでした。
チームビルディングの一環としての合宿で、自分たちがいろいろなものをすっ飛ばして機能の話ばかりしている、というのも大きな発見でした。
今では試作の流れは、下記のような手順で行なっています。
施策のドキュメントを作成
ビジネス背景（なぜやるのか、どういうインパクトを与えるのか）
ターゲットユーザー
ざっくりとしたAs is Tobe（理想的なアウトカム）
具体的な今の姿と、ユーザーフローの書き起こし（As is Tobeの詳細化）
検証項目と、MVPの設定
ユーザーストーリーマッピングを作成し、機能の取捨選択
プロダクトバックログ化
モブデザインで詳細化
UIデザインに起こす
ポイントは、
✅ 1の時には、機能の話はしない。ユーザーのアウトカムに着目し、どのような価値なのかを見極める
✅ 2の段階で、できるだけ生々しくリアルなフローを作り、チームでつっこみまくる
この二つをチームでしっかり共有&議論ができると、その後が非常にスムーズです。
具体的に変わったこと
PdMの資料作りにかかる時間を大きくカット
チームメンバーを早いうちに巻き込むので、PdM待ちもゼロに
ユーザーの今と未来から語ることで、チームメンバーが深く理解でき、議論も活発に
価値を提供することは、必ずしも機能がゴールではないことに気がつけた
結果、施策のリリースまで早く行えるようになった
特に大きく変わったなと感じているのは、検証やMVPに伴って最低限の機能に削ぎ落とすこと、削ぎ落とそうとすることがチームに根付いてきたことです。
そしてその削った機能の工数は、ユーザーのアクセシビリティや、体験設計へ注力することができるようになってきました。
また、モブデザインを導入してみたのですが、これもよかった。チーム全員でUIの話ができるのが嬉しい。もっとこうした方がいいんじゃない？みたいなものはいろんな人から出るべきで。
ここまで盛りだくさんで書きましたが、まだこのサイクルは完璧ではありません。中間生成物がなくなった反面、決定事項が残りにくいなど問題もあります。
ですが、確実にチームの結束が深まり、レベルアップしている感覚があるので、引き続き色々試していきたいなぁと感じる今日この頃。
やっぱり、本質の話をチームでできるのって楽しい。このサイクルに変えて「楽しい」という声をメンバーから聞けて本当に嬉しかったです。
今後は、プロダクトチームがもっとユーザーの一次情報に触れられるように、チーム一丸となって行動をし始める予定です。様々な立場の人が、たくさんのアイディアを出せるような場作りに注力していきます！
最後まで読んでいただきありがとうございました！
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
（宣伝）スマートショッピングでは、プロダクトやチームビルディングをどんどん変化させていきたい、デザイナー・PdM・エンジニア歓迎します！
カジュアル面談もやっていますので、ぜひお気軽にDMください。
この記事が気に入ったらサポートをしてみませんか？