『リーンスタートアップのためのUX』（2013年）は、製品やサービスのリサーチとデザインに、革新的でコスト効率の高いアプローチを提供します。スタートアップや、スタートアップのように俊敏に動きたい企業を対象に、時間と費用を最小限に抑えながら、顧客に優れたユーザーエクスペリエンスを届ける方法を示しています。
この本から学べること：お金をかけずに優れたユーザーエクスペリエンスを生み出す方法
スタートアップで働いている人も、これから創業しようとしている人も、「自分には良いアイデアがある」と信じているでしょう。しかし、これまで存在したほとんどのスタートアップにも「良いアイデア」はありました。そして、その大半は失敗しています。なぜでしょうか？ 成功と失敗を分けるのは、多くの場合、顧客に優れたユーザーエクスペリエンス（UX）を提供できるかどうかにかかっています。
ナビゲーションがしやすいからと、つい引き込まれたウェブサイトを思い浮かべてください。次に、使いづらくてすぐに離脱したサイトを思い浮かべてください。その違いこそが、良いUXと悪いUXです。残念ながら、UXを適切に設計するには多くの時間とお金がかかり、スタートアップではそのどちらも不足しがちです。
そこで登場するのが「リーンUX」です。これは、新しいプロダクトやサービス、機能を、できるだけ素早く効率的に開発することに焦点を当てたUXリサーチとデザインの手法です。本書では、以下のことを学びます。
- ランディングページを使って未来をのぞく方法
- アイデアをテストするのに「オズの魔法使い」が教えてくれること
- 従来のUXアプローチがほとんどすべてを間違えている理由
リーンUXは、仮説を立てて検証し、意思決定に活かすことを重視する
あなたが、オンラインでガジェットを販売するEC企業に勤めていると想像してください。ある日の会議で、誰かが「サイトの各商品の下にコメント欄を追加しよう」と提案します。そうすれば顧客からフィードバックをもらえる、と。全員が素晴らしいアイデアだと思い、すぐに開発に取りかかります。
プロダクトマネージャーが仕様を書き、デザイナーがデザインを考案し、エンジニアがコードを組みます。2カ月後、ついに機能がリリースされ、見た目は完璧です。しかし、ひとつだけ小さな問題がありました。顧客の誰もその機能を使いたがらなかったのです。すべての作業が無駄になってしまいました。
何が間違っていたのでしょうか？ ここでのポイントは、リーンUXでは仮説を立てて検証し、意思決定に活かすことを重視するということです。このやり方は、リーンUXと従来の新機能・製品・サービス設計アプローチとの核心的な違いのひとつを際立たせます。すべては「思い込み」と「仮説」の違いに帰着します。その違いを理解するために、失敗したコメント欄に話を戻しましょう。リーンUXを使えば、このアイデアにどう取り組んだでしょうか？
まず何より、「予備調査に基づき、コメント欄をサイトに追加すれば、顧客エンゲージメントが高まり、売上が向上するだろう」といった仮説を立てます。この仮説によって、アイデアが検証可能な命題に変わることに注目してください。顧客エンゲージメントと売上は測定できるものです。数字が上がれば仮説は正しく、上がらなければ間違いだったとわかります。あとはどちらなのかを確かめるだけです。
リーンUXの言葉では、このプロセスを検証と呼びます。なぜなら、新しい製品やサービス、機能に対する自分の信念を、正しいか正しくないか検証しようとしているからです。一方、従来のアプローチの弱い点は、アイデアをそのまま突き進み、うまくいくことを祈るだけであることです。これでは、自分のアイデアについて根拠のない「思い込み」をいくつも積み重ねているにすぎません。コメント欄の例で言えば、何の実際の証拠もなしに、顧客エンゲージメントが高まり、ひいては売上も伸びるだろうと思い込んでいるわけです。それはリスクの高い賭けです。結局のところ、思い込みが間違っていれば、何カ月もの時間とお金が無駄になる可能性があるのです。
リーンUXは、このような運命を避けることこそが目的です。どうやって？ 悪いアイデアをできるだけ早期に「無効化」することによって、です。
製品、サービス、機能のアイデアは、設計する前に検証する
ちょっと待ってください。あなたは預言者ではありません。では、どうすれば自分のアイデアが良いか悪いかを知ることができるのでしょうか？ 実際に形にして、顧客の反応を見なければわからないのでは？ 幸い、水晶玉は必要ありません。
必要なのは、仮説を検証するためのいくつかの賢いアプローチです。新しい製品、サービス、機能を、設計するどころか、作る前でさえもテストする必要があります。これはほぼ不可能に思えるかもしれませんが、実際はリーンUXの哲学を行動に移しているにすぎません。ここでのポイントは、製品、サービス、機能のアイデアは、設計する前に検証するということです。プードルやおしゃれな犬向けのプレミアム・デイスパ、「プードル・ペディキュア」という会社を始めたいと思ったとしましょう。なんてワクワクする話でしょう！
さて、犬用のサロンチェアや高価な機材を買うために時間とお金を投資する前に、ちょっと立ち止まってください。これが勝てるビジネスアイデアだという仮説を検証する、はるかに安上がりな方法があります。いいえ、小さな移動式の犬のグルーミングステーションから始めるのではありません。単にランディングページを作ればいいのです。これは、検索エンジンからたどり着いた人々が「着地」するウェブページです。そのページに、まだ存在しない製品やサービスを「予約」「先行注文」できる目立つボタンを設置します。もし多数の予約や先行注文が入れば、素晴らしい。勝ち筋があるかもしれません。
しかし、ボタンがほとんどクリックされなければ、振り出しに戻る時だとわかります。アイデアを事前にテストするもう1つの方法は、機能スタブを作ることです。これは基本的に、将来実装するかもしれないもののプレースホルダーです。たとえば、これまで無料だったデジタルプラットフォームにプレミアム機能を追加しようと考えているとします。決済システムを考え、機能を作り込む代わりに、事前にウェブサイトで告知してみてください。
「アップグレード」と書かれたボタンを設置し、クリックすると価格と機能の一覧が表示されるページに飛ぶようにします。そして、誰かが実際に関心を示すかどうかを見極めてから、アイデアを前に進めるのです。これらは、多くの時間とお金を投資せずにアイデアの検証を始めるための、2つの方法にすぎません。次は、さらにいくつかの方法を見ていきます。
最終的な製品、サービス、機能に作り込む前に、アイデアをテストする
「オズの魔法使い」を覚えていますか？ 古典映画ではなく、そのタイトルの元になった「魔法使い」というキャラクターのことです。おさらいすると、このキャラクターはちょっとしたペテン師でした。彼は巧妙な手品の数々を使い、まるで本物の魔法の力を持っているかのように見せかけていました。
実際には、カーテンの後ろにいるただの人間にすぎません。同じようなイリュージョンを、「オズの魔法使い機能」と呼ばれるもので実現できます。大量の時間とお金をかけて設計することなく、自分のアイデアが正しい方向に向かっているかを確かめるもう一つの方法です。それは、全体を作り上げなくても、そのアイデアが人々に通用するかどうかを確認できるからです。ここでのポイントは、最終的な製品、サービス、機能に作り込む前に、アイデアをテストするということです。
実世界の例として、著者は「Food on the Table」という会社でコンサルタントとして働いていました。このアメリカのスタートアップは、近隣の食料品店の特売品を基に、食事の計画を立てる手助けをするサービスを提供したいと考えていました。
著者は、これが非常に難しいアイデアだとわかっていました。全米の何千もの食料品店からデータを収集し処理する必要があったからです。もし会社がこれだけの作業をしたのに、アイデアが失敗に終わったらどうなるでしょう？ 事前にテストするために、その会社は「オズの魔法使い」を実行しました。つまり、自動化されたシステムを構築する代わりに、何人かの見込み客を見つけ、すべての作業を手作業で行ったのです。彼らは食料品店へ行き、セールのチラシを集め、自分たちで食事プランを考えました。結果、人々はそのサービスを気に入ったので、会社は開発に本格的に乗り出しました。
同様の効果を得る、より一般的な、しかし効果に劣らない方法は、製品の「インタラクティブプロトタイプ」を作ることです。これは、あなたが考えている製品の、使えるけれど限定的で、飾り気のないバージョンです。たとえば、オンラインショッピングプラットフォームのインタラクティブプロトタイプは、ユーザーに商品を購入しているかのように感じさせつつ、実際の支払い処理や発送は行いません。こうすれば、そういったことを可能にするバックエンドシステムを構築する必要がありません。また、製品の美しく細部まで作り込まれたビジュアルデザインに多くの時間を費やすことも避けられます。この段階では、単に核となるアイデアに関心があるかどうかを見極めようとしているだけなので、ラフで間に合わせのデザインで十分なのです。
定性的リサーチを使ってアイデアを検証する
製品のインタラクティブプロトタイプを作ったとしましょう。素晴らしい。でも、それからどうするのでしょう？ 誰も触ってくれないのであれば、プロトタイプを作る意味がありません。
そして、人々が触ってくれたとしても、その体験について話を聞かなければ意味がありません。ここでの目的は、あなたのアイデアについて見込み客がどう考えているかを知ることです。プロトタイプは、アイデアが動いている様子を具体的に見せる手段にすぎません。今度は、それについて彼らがどう思うかを知る必要があります。ここでのポイントは、定性的リサーチを使ってアイデアを検証するということです。ここで言う定性的リサーチとは、単に人を観察し、話を聞くことによって情報を得ることを意味します。
インタラクティブプロトタイプでは、これがユーザビリティテストの形をとることがあります。たとえば、アプリのプロトタイプを構築したと想像してください。5人の潜在ユーザーを集め、プロトタイプを使って一連の基本的なタスクを実行してもらうことで、ユーザビリティテストができます。そして、どのように操作するかを観察します。タスクは問題なく完了できるか？ あなたからの指導や介入なしにできるか？
介入や手助けをしたい気持ちを抑えてください。あなたが見たいのは、彼らが実際の顧客として実世界でアプリを使ったら、それをどう楽しむかです。その後、彼らの体験について話を聞きます。質問やフィードバックの中に、最終製品で解消すべき問題点を示すものがあれば、それを見つけます。ユーザビリティテストをさらに一歩進めるには、参加者に複数のプロトタイプを渡し、どれが一番気に入ったかを尋ねてみましょう。あるいは、プロトタイプを一切使わずにユーザビリティテストを行うこともできます。競合製品を使うのです。
オンライン広告をいくつか出し、既存の製品を普段から使っている人を5人集めます。近くに住んでいるなら訪問し、遠方なら画面共有アプリを使います。そして、普段通りのやり方で製品を使ってもらい、何が起きるか、何かパターンが現れないか観察します。最後に、いくつかの自由回答形式の質問をします。製品の何が好きか？ 何が嫌いか？ 何が足りないと思うか？
価値ある情報を集めながら、観察し、耳を傾け、学びましょう。その情報が、あなたとあなたのデザイン上の意思決定を導いてくれます。
定量的リサーチは、定性的リサーチとは異なる方法でアイデア検証に役立つ
情報を得る様々な方法について話すとき、私たちは通常それを「定性的リサーチ」と「定量的リサーチ」という2つの大きなカテゴリーに分けます。UXデザインの文脈で定性的リサーチがどのようなものか、ユーザビリティテストで人を観察したりインタビューしたりすることは既に見てきました。では、数値データを扱う「定量的リサーチ」はどうでしょうか？ どちらのタイプのリサーチも、検証プロセスにおいてそれぞれの役割があります。
リーンUXの重要な側面は、それぞれをいつ、どこで展開するかを知ることです。ここでのポイントは、定量的リサーチは定性的リサーチとは異なる方法でアイデア検証に役立つということです。定性的リサーチは、問題が「なぜ」起きているのかを理解したいときに役立ちます。潜在顧客がアプリのプロトタイプを操作する様子を見て、どこでつまずいたかを観察し、なぜ混乱したのかを尋ねることができます。対照的に、定量的リサーチでは、問題の規模や、その解決策として考えたものの効果を「測定」できます。
たとえば、ウェブページのサインアップボタンがどれだけうまく機能しているかを調べるには、何人の人がそれをクリックしているかを測定すればよいのです。数字が低ければ、「ボタンをもっとページの上部に置いたら、クリックする人が増えるだろうか？」といったデザイン上の疑問につながるかもしれません。これを解明するには、古典的なA/Bテストが必要でしょう。この場合、A/Bテストとは、異なるユーザーに異なるボタン配置を見せ、どちらが最もパフォーマンスが良いかを確認することを意味します。ボタンをどこに置くかといった、製品のほんの小さな変数を変更するだけのデザイン決定について、定性的リサーチはできるでしょうか？ もちろん、本当にやりたければ、何人かのユーザーを集めてボタンの配置についてインタビューすることもできます。しかし、彼らの答えはおそらく「さあ？」と肩をすくめる程度でしょう。普通の人は、普段このようなことを意識レベルで考えたりしません。たとえある選択肢に好みを示したとしても、5人の意見を得たところで統計的に有意なサンプルサイズにはなりません。インタビューは強力ですが、定性的な情報を集めるには時間がかかります。それに比べて、A/Bテストは素早く簡単に定量的データを得られます。それだけで十分なら、そちらを選びましょう。
十分に深刻な問題に対する、十分に優れた解決策となり、十分な人が購入するアイデアかを確認する
ここまでで、検証がどのように機能し、実際にどのようなものか、おおよそ理解できたことでしょう。他にも多くのやり方があり、テストする製品、サービス、機能によって詳細は大きく異なりますが、これくらいにしておきます。ここで少し視野を広げ、全体像を見てみましょう。そもそもなぜ検証するのでしょうか？
これだけの作業をして何を見つけ出そうとしているのでしょうか？ そして、それが成功したかどうかをどう判断するのでしょうか？ 恐らく、最終的にはお金を稼ぎたいはずです。つまり、アイデアの商業的な実現可能性を考慮しなければなりません。その1つの方法は、作り出そうとしている製品やサービスを、問題に対する潜在的な解決策として捉えることです。ここでのポイントは、十分に深刻な問題に対する、十分に優れた解決策となり、十分な人が購入するアイデアかを確認することです。
すべての成功した製品やサービスは、何らかの問題を解決します。GPSは地点Aから地点Bへの移動という問題を解決し、ワードプロセッサは既に書いた文章を編集する問題を解決し、アングリーバードは退屈という問題を解決しました。最初に考えるべきは、あなたのアイデアが解決する「実際の問題」が存在するかどうかです。それとも、単にクールに思えるだけで、実用的な応用が何もないことをするだけではないですか？ 人々は問題を自覚していないかもしれない、ということも覚えておいてください。
例えば、インターネットが普及する前は、人々は概して電話とFAXでのコミュニケーションに満足していました。一度にたくさんの人に電子メッセージを送れないことを嘆き悲しんだりはしていなかったのです。しかし、やがてEメールが登場し、自分たちが抱えているとほとんど気づいていなかったこの問題を解決しました。あとはご存じの通りです。さて、製品が解決を意図する「真の問題」を特定できたとしましょう。次の2つの質問があります。その製品は、その問題に対する解決策を実際に提供できるか？
そして、その解決策に対して、十分な数の人々が、製品が利益を生むのに十分な金額を支払ってくれるか？ 言い換えれば、実行可能な製品と市場があるかどうかです。それはいくつかの要因にかかっています。製品はどれだけうまく機能するか？
人々は使うのを楽しめるか？ そして、あなたが提供する解決策にお金を払いたくなるほど、問題は十分に大きいか？ 問題がそれほど気にならないなら、製品がどれほどうまく機能しようと、人々はおそらくお金を払おうとはしないでしょう。
顧客の「痛み」を理解し、それを和らげる製品、サービス、機能を設計する
リーンUXのデザインとリサーチのアプローチを簡単に覚える方法はないでしょうか？ ここに一つあります。自分を医者だと考えてください。なぜか？ あなたが顧客にしたい人たちは、生活の中で何かしらの「痛み」を抱えていて、問題はこれです：あなたのアイデアはその治療法を提供しますか？
そして、その痛みは十分にひどく、治療法は人々がお金を払うほどに十分優れているでしょうか？ 著者はこの考え方をペイン・ドリブン・デザイン（PDD）と呼んでいます。これは、新しい製品、サービス、機能を設計するリーンUXのアプローチを説明するのに便利な比喩です。そして、ここで次のトピックに移ります。デザインです。あなたのアイデアを検証し、それが良いものだとわかったと仮定して、次のステップは作りたいものを設計し始めることです。ここでのポイントは、顧客の「痛み」を理解し、それを和らげる製品、サービス、機能を設計するということです。
既に製品があるとしましょう。どんなに素晴らしい製品でも、あなたが作るものが完璧であることは決してなく、常に改善の余地があります。PDDの言葉で言えば、あなたの製品の何かが、おそらく人々に「痛み」を与えているのです。そして、それを改善するには、どうすればその痛みを和らげられるかを解明する必要があります。ここで再び定性的リサーチが役立ちます。人々が製品を使っているところを観察し、彼らの体験について話を聞いてください。
何が難しく、混乱させ、イライラさせているのか？ これらの質問に答えることで、最も重要な人々、つまり顧客の目から見て、製品を実際に改善する新機能を設計できます。問題は小さいこともあり、解決策も同じくらい小さくて済む場合があります。低コストの食事プラン作成を支援する「Food on the Table」を覚えていますか？ サービスが軌道に乗った後、ウェブサイトにユーザーを大いに悩ませる技術的問題が発生しました。問題は、食事プランをクリックしてからショッピングカートに表示されるまでの、2秒ほどのタイムラグでした。
ユーザーは、このラグをウェブサイトが選択を認識しなかったのだと思い、プランを何度もクリックし、結果としてカートに同じものが複数回追加されてしまいました。さて、この問題を解決する複雑な方法はたくさんありますが、著者と彼女のチームは、うまくいくシンプルなものを考え出しました。「食事プランを追加」ボタンをクリックされた後は無効化し、代わりにウェブサイトが選択を処理中であることをユーザーに知らせる回転する輪を表示したのです。厄介な問題に対するリーンな解決策を探すとき、それがいかにシンプルで済むかに驚くかもしれません！
リーンUXは反復的なデザインアプローチを採用し、実用最小限の製品を生み出すことに集中する
UXデザインと聞いて、何を思い浮かべますか？ 信じられないほど複雑なのに、なぜか機能的に成立しているAmazonのオンラインストアのレイアウトかもしれません。あるいは、Googleの検索ページのエレガントなミニマリズムかもしれません。おそらく、前に検討したあの間に合わせの解決策、つまりラグが発生したときにウェブサイトのユーザーにもう少し我慢してもらうための回転する輪などではないでしょう。
しかし、素晴らしいものは、1つずつ新しい改善を積み重ねることで設計され、創り出されるのです。ローマは一日にして成らず、あなたの製品やサービスも同様です。ここでのポイントは、リーンUXは反復的なデザインアプローチを採用し、実用最小限の製品（MVP）を生み出すことに集中するということです。
実用最小限の製品（MVP）という考え方から始めましょう。この用語は多くの定義があり議論もありますが、ここでは、最小限の時間、労力、お金で仕事を成し遂げるものを作ることを意味します。アクロニムの「P」は製品を指しますが、MVPは必ずしも製品である必要はありません。
「プードル・ペディキュア」事業に人々が関心を持っているかを教えてくれるランディングページかもしれません。あなたのアプリを人々がどう気に入るかを見られるインタラクティブなプロトタイプかもしれません。「食事を追加」ボタンを人々がクリックするのをやめさせる回転する輪かもしれません。リーンUXの言葉では、これらすべては何かを成し遂げるための最も低コストで最も効率的な方法である限り、MVPになり得るのです。より一般的な用法では、MVPは一般向けにリリースできる、最も基本的で簡素化されたバージョンの製品を指すこともあります。中核機能を果たし、余分な装飾のないバージョンです。
例えば、あなたの安全なファイル共有プラットフォームは、最初からFacebookと互換性がある必要が本当にあるでしょうか？ いいえ、そしてそれは追加するのが難しく、時間のかかる機能でしょう。ならば、今すぐ中核製品をリリースして、Facebook経由でファイルを共有する実際の需要があるかどうかを見てみてはどうですか？ 新機能は常に将来の反復で追加できます。
Amazonでさえ、最初は本だけを販売し、残りの製品やサービスを少しずつ追加していったのです！ そしてGoogleは、かつてリンクの色としてどれが最も効果的かを見るために、41種類の異なる青の色合いをテストしました。小さなことの積み重ねが大きなものになり、巨人でさえ小さくスタートするのです。
本書の要点
適切なリサーチといくつかの賢い実験により、時間、お金、労力を大量に注ぎ込まずとも、新しい製品、サービス、機能のアイデアの妥当性をテストすることができます。また、顧客が本当に望むものを見つけ出し、それを届けるユーザーエクスペリエンスをデザインできます。
実用的なアドバイス：進み続けましょう。
製品やサービスをリリースした後も、検証と反復の作業は終わりません。例えば、ウェブサイトの新バージョンを完成させたら、古いバージョンとのA/Bテストを行いましょう。それは、あなたが改善したいと望んでいたことを実際に改善していますか？ 製品、サービス、目的に応じて、継続率、収益、登録数など、見るべき指標は数多くあります。何がうまくいき、何がうまくいかないかを確認してください。反復を続け、検証を続け、改善を続けましょう。UXデザインの仕事に、本当の終わりは決してないのです。
次に読むべきは：ジェフ・ゴットヘルフ著『リーンUX』
リーンスタートアップの哲学をUXデザインとリサーチに適用する、さらに多くの方法を学びたいですか？ それなら、『リーンUX』の要約をチェックしてみてください。アジャイルソフトウェア開発から、よりオープンで協調的、効果的なデザインプロセスの創出まで、あらゆることが学べます。また、多くのリソースを投入する前にアイデアをテストする、さらに多くの方法についても知ることができるでしょう。
