インターンとしてUXデザインを勉強している富樫です。今週から週一でUXデザインに関する記事を投稿していこうと思います。
アジケに入ってから2カ月が経ちました。全くのWEB初心者から初心者くらいにはなった気がしないでもない今日この頃。
ようやくワイヤーフレームの作り方が分かってきた私ですが、先日リクルートホールディングス主催の学生向けのイベント「【シリコンバレーから緊急来日】本場のLean UX を学ぶワークショップ」に参加してきました。折角なのでその模様と感じたことなどを書いてみようと思います。
教えてくれた人
今回ワークショップを行ってくださったのはJason Fraser氏。Lean UXという言葉の生みの親であるJanice Fraserとともに「Luxr (the Lean User Experience Residency)」を設立。現在はアジャイル開発のコンサルファーム「Pivotal Labs」の一員とのこと。この時点で凄い感じがプンプンです…。
Lean UXって？
この日は20人程度の学生が参加していましたが、「Lean Startupを知っている人？」とFraserが問いかけると、参加者の半分程度が反応。次に「Lean UXを知っている人？」と問いかけると、その数は2～3人までに減りました。日本では昨年から出回るようになった言葉のようなので、当然かもしれません。 すでに予想が付くと思いますが、Lean UXは「Lean Startup」と「UXデザイン」を併せた言葉です。
リーンスタートアップとは・・・。
リーンスタートアップとは、事業の立ち上げに関する方法論のうち、仮説の構築、製品の実装、および軌道修正、という過程を迅速に繰り返すことによって、無駄な無価値な要素を最小限に抑えつつ素早く改良を続け、成功に近づく、というビジネス開発手法である。―IT用語辞典バイナリ―
太字のところが大切だと思います。
私は今回のワークをブログで書こうと思っていたので、FraserのプレゼンをわりとEvernoteにメモしていたのですが・・・。
Fraser「（私を見ながら）Software developer, likes to do this.」
私「？？？」
一同「（笑）」
「おや、なんか急に俺、バカにされてる？」と思い傷つきました。でもよく聞いてみると、タイピングばかりしている私を従来のソフトウェア開発者に例えていたみたいです。
従来のソフトウェア開発では左図のように開発に時間をかけ、実際のユーザーからのフィードバックを得るタイミングがリソースを割いた後になり、そこからユーザーの改修するとなるとそれまでにかけた工数が無駄になります。
対して右図のリーンスタートアップ。早めに組み立て（build）、早めに世に出すことでユーザーの反応を計測し（measure）、そしてそれを学習し反映させる（learn）。このサイクルを小刻みに回すことで無駄な工数をかけません。
Fraserが言いたかったのはこのように、ユーザーの反応を見ずに、プロダクトを作り続けることは危険ということでした。無意味にバカにされたのではなくてよかったです。（？）
UXデザインについての説明はアジケのこちらの記事をご覧ください。
いよいよワークショップへ！
Lean UXに対する意識付けをしたところでワークに入りました。
1.三人一組でチームを作り、取り組むサービスを決める。
適当に3人でチームを作ってーと言われ、近くにいた人とチームを組みました。この時、3人というのがポイントらしいです。握手を例にとると、3人だと全員と握手するのに3回で済むところ、4人に増えるだけでその回数はなんと6回と倍になってしまうのです。グループワークで一人一人のコミュニケーションをなるべく最大限発揮できるようにする工夫ですね。
何気ないチーム分けですが、Lean UXの小規模、専任、同一場所という原則にのっとった作業でした。
2.前提（assumption）をポストイットに書き出し、重要/重要でないに分ける。
自分たちが題材とするサービスについて考えられる事柄を個人でポストイットに記入していきます。顧客にどのようなニーズがあるか、そのニーズはどのように解決できるかなどを5分程度で思いつく限り出していきました。
そして出た仮定を重要かそうでないかで半分にグループ化します。
3.重要でない前提の消去
折角考えたのに！と思ってしまいますが、重要でないものを考えるのは無駄なので、思い切って破きます。自分で破くのは思い入れが邪魔してしまうので、同じグループのメンバー同士で破き合います。
4.優先順位付け座標を作成し、重要だと判断した前提を貼っていく。
y軸が重要度（important）、x軸がその仮定の既知度（evidence）を表す座標を作成します。そして前の作業で重要だと判断されたポストイットを貼っていきます。これにより前提の優先度を決定していきます。
こんな座標です。
5.メンバー間で疑問点の解決
壁に貼ってあるポストイットに記載された内容を全員で吟味。今までは個人作業だったので、ここで初めてグループの作業になります。互いに「これってどういうこと？」「もっと深堀りすると？」などと意見を交換します。この段階で前提のポストイットを増やしてもOKです。
6.右上のゾーンに貼られた前提を残し、テーブルに持ち帰る。
「重要度が高く、確証度が低い」前提をLean UXでは優先していきます。グラフでいう右上のゾーンに残っているポストイットを除いて、すべて剥がします。
私のチームの右上の少なさが気になりますが、このゾーンです。
7.持ち帰った前提を仮説（hypothesis）とする。仮説が正しいかどうかを検証する際に基準とする成果（outcome）を定める。
前提を持ち帰り、さらにそれを詳しくし、実験できるようにしたものが仮説となります。
その仮説が正しいかどうかを判断します。基準とする成果は私の班の場合、就活サービスにおけるUIの分かりづらさに問題を課題感としていたため、「セミナー登録数」や「クリックまでの時間」などで判断できるのでは？？などと議論をしました。
8.効果測定方法を決定する。
そして実際に計測する方法を議論します。
また、ここでのポイントは最小限の工数で行うこと。Lean UXではMVP（Minimum Viable Product）、つまり実行可能な最小限のプロダクトでフィードバックを得ることを提唱しています。
計測するために過度の工数をかけると、Build→Measure→Learnのサイクルが速く回っていかず、結局リーンでなくなってしまうからですね。私は短絡的に「UI変えてA/Bテストすればいいんじゃね？？」などと言ったりしていましたが、「このサービスの場合それは工数かかるから」とメンバーに却下されました。
また、事前にどのくらいの成果が出ればその仮説は正しいとするのか、決めておきます。コンバージョンを調べるなら何割以上で正しいとするか、ユーザーインタビューをするのであっても評価基準を定めておかねばなりません。この成果は定量的でも定性的でも構いませんが、一番大事なポイントである「私たちはどんな成果を得たいのか？」という目的を明確にしてくれます。
9.測定方法のプレゼン
ワークは終了。チームごとに考えたサービスと測定方法を発表しました。
私のチームは測定方法を具体化する途中でタイムオーバーになってしまったのですが、発表していたチームは具体的に考えられており、感心しました。
まとめ
・とにかく早い段階でユーザーからフィードバックを得る
・確かめるべき前提を徹底的に優先度付けする
・最小限の工数で仮説を検証する
・得たい成果を事前に定めておく
今回のワークは１時間程度で行われたこともあり、Lean UXのほんの一部です。バイブル的な本にLean UX ―リーン思考によるユーザエクスペリエンス・デザイン (THE LEAN SERIES)
感想
Lean UXの原則の一つに「中間成果物中心の仕事の進め方からの脱却」というものがあります。とにかく早く形にする、早い段階でユーザーからのフィードバックを得る。今回のワークで学んだことです。
私は普段、UXを考えることに一生懸命に時間を費やしてしまいます。ペルソナがどんな人で、どういう経路でサービスを使って、どんなデザインでなどなど・・・（UXやビジネス自体の経験が少ないことがそうさせているのもありますが！）。
結論、やっぱり私は実際にユーザーを見ずに開発に没頭する、従来のソフトウェア開発者のようなマインドだったのです。
Lean UXに限らずフレームワークは一つのツールで、それぞれの組織に合った取り入れ方がされるべきで、必ずしも真似するものではないと思いますが、一つのマインドセットとして持っておくとよい考え方のでは？と感じました！！
私も成果を念頭に置いてUXを考えたいと強く心に刻んでおこうと思います。ではまた来週！
【参考書籍】
