『リーンUX』（2013年）は、インタラクティブデザインの現場にリーン原則を適用するためのガイドです。本書では、リーンUXのテクニックを解説し、それを企業のデザインプロセスに最適に統合する方法を紹介します。緊密なコラボレーションと顧客フィードバックの重要性、そしてデザインを絶えず改善する方法を学べます。
本書から得られること：リーン原則をデザインに応用する
ビジネス戦略に関心があれば、「リーン」という言葉を聞いたことがあるでしょう。 リーンとは、トヨタ自動車での実践で最も有名なビジネス手法で、無駄や非効率を削減しながら、企業が柔軟性、革新性、顧客志向を保つことを可能にするものです。
リーンは、スタートアップから大企業まで、また会議から製品開発まで、さまざまなビジネスや領域に適用されてきました。 本書では、そのリーンの原則をデザインの世界に適用します。 デザインへのアプローチをより効率的に、そしてより創造的にしたいなら、読み進めてください。 本書でわかること：
- なぜ最初にデザインを紙に描くべきなのか
- なぜ優れたデザインチームにはデザイナー以外のメンバーがいるのか
- 成功したければ、テストを繰り返すことこそが重要である理由
リーンUXの3つの基本原則：デザイン思考、アジャイルソフトウェア開発、リーンスタートアップ
あなたの会社で働くデザイナーを実際に見かけることはありますか？ 多くの企業と同様に、デザインチームを他の部署から分離し、彼らが自分たちだけの小さな世界で働いているというケースが多いでしょう。 幸いなことに、これを克服する方法があります。 それがリーンUXです。リーンUXはデザイナーを、チーム全員がデザインに貢献する大きな協働プロセスにつなげます。
基本的にリーンUXは、デザイン思考、アジャイルソフトウェア開発、リーンスタートアップを組み合わせたものです。 では、これらの用語はそれぞれ何を意味するのでしょうか。 まず、デザイン思考とは、ビジネスのあらゆる側面をデザインという視点からアプローチできるという考え方です。 例えば、企業が問題に直面したとき、デザイナーがそうするように解決できるのです。 この戦略の鍵は、ブレインストーミングに多くの人を参加させ、より多くの潜在的な解決策を生み出すことです。 次に、アジャイルソフトウェア開発は、協働的な製品開発プロセスに全員を参加させることで、製品サイクルの時間を短縮しながら、顧客により大きな価値を提供することを可能にします。
つまり、仕事を部署ごとに分割する従来のアプローチではなく、アジャイル開発では最初から全員が一緒に働くのです。 この戦略の主な利点は2つあります。人手が多ければ作業が軽くなること、そしてコラボレーションがチームスピリットを築きながら創造性を育むことです。 リーンUXの3つ目の要素は、リーンスタートアップの手法を製品デザインに適用することです。これは、テンポの速い実験と検証を意味する戦略です。 それは次のように機能します。市場の仮説を早期にテストするために、プロトタイプをできるだけ早く作り出すのです。
この早期テストにより、フィードバックをほぼ即座に得られ、何が機能し何が機能しないかがわかります。 こうすることで、不正確な仮説や弱いアイデアをほとんど影響なく捨て去り、リソースを最良のアイデアのために解放できます。 リーンUXの基本を学んだところで、次はリーンUXサイクルの4つのステップを探っていきましょう。
望む成果、理想の顧客、提供する機能を定義してビジネスのアイデアを伝え、テストする
では、リーンUXをどのように実践すればよいのでしょうか。 このプロセスには4つのシンプルな要素があり、最初のステップは仮説を立てることです。 しかし、これは具体的に何を意味するのでしょうか。 仮説とは、まだ言語化されていないアイデアや信念を文章で表現したものです。
例えば、人材紹介会社を考えてみましょう。彼らの仮説の1つは、顧客（この場合は雇用主）が潜在的な従業員とやり取りするために自社のサービスを利用するだろう、というものかもしれません。 しかし、会社のほとんどの従業員がそう想定していても、想定だけでは十分ではありません。 この仮説はテストされる必要があり、そこでプロセスの残りの部分が役立ちます。 仮説ができたら、次のタスクは「成果」「ペルソナ」「機能」という残りの3つの要素を使って、テスト可能な仮説ステートメントに変換することです。 まず、成果を定義することから始めます。成果とは、製品やサービスがユーザーにもたらすことを望む結果のことです。 例えば、人材紹介会社の成果は、より多くの求職者にサービスに登録してもらうことかもしれません。
成果を決めたら、ペルソナを設計します。ペルソナとは、モデルユーザーのスケッチです。 まず、名前と年齢を添えた小さな絵を描きましょう。例えば、キャスリーン、32歳といった具合です。 次に、ペルソナの行動特性や人口統計学的情報をリストアップします。 キャスリーンの場合、既婚で3人の子どもがいて、コンサルタントとして働いているといった情報が含まれるでしょう。 次に、ペルソナの困難やニーズを書き出します。おそらく彼女は子どもの教育と仕事の両立に苦労しており、在宅勤務のポジションに興味があるかもしれません。 問題に対する潜在的な解決策を追加することで、ペルソナを完成させます。
キャスリーンには、自分のスキルを潜在的な雇用主にアピールし、新しい仕事を見つけるためのプラットフォームが必要かもしれません。 最後のステップは機能を追加することです。機能とは、ペルソナに対して望む成果を達成する可能性のある実際の製品やサービスのことです。例えば、雇用主と潜在的な従業員を簡単につなぐサービスなどが該当します。 これができたら、4つの要素をすべて統合して、ペルソナに提供する機能を説明しつつ、望む成果を明確にした仮説ステートメントを書くことができます。
最初から製品チーム全体にデザインプロセスを開放する
デザインはデザイナーに任せる、というのが企業では一般的です。 何しろ、彼らの仕事ではないのに、なぜ他の人が関わる必要があるでしょうか。 リーンUXはこの慣行を覆します。それには十分な理由があります。製品チームの全メンバーを最初からデザインプロセスに参加させることで、開発が速くなり、会社により適したデザインが生まれるのです。 なぜなら、通常のデザインプロセスでは、デザインチームが他者からブリーフィングを受け、その又聞きの情報に基づいて製品を作るからです。
デザインがうまくいかなければ、やり直しのために差し戻され、そのプロセスが永遠に続くこともあります。 リーンUXは、デザイナーを他の従業員とすぐに一緒に働かせることでこの問題を回避します。チームが問題を即座に修正し、プロセスを前進させられるのです。 ダッシュボードをデザインするために、デザイナーと開発者がカジュアルな対話を繰り返す様子を想像してみてください。 何枚かのスケッチと調整を経て、彼らはすぐにデザインについて合意します。 その後、デザイナーは細部を詰めることに専念でき、開発者はインフラストラクチャのコードを書くことができます。 しかし、協働デザインの導入にもっと正式なアプローチを望む場合もあるでしょう。
それには「デザインスタジオ」が最適です。これは、異なるチームメンバーを同じ部屋に集め、あらゆる問題に対するデザインソリューションを開発する戦略です。 デザインスタジオが機能するのは、プロダクトマネージャー、ビジネスアナリスト、ソフトウェア開発者、デザイナーが1つの問題について協働することで、スキル、視点、専門知識の多様性が生まれ、プロセスが円滑かつ効率的に進むからです。 さて、仮説と仮説ステートメントが準備でき、チームも協働の準備が整いました。 次は、仮説をテストするための実験を開発することに取り掛かる準備ができています。
コミットする前に製品をテストして、どのアイデアが機能するかを見極める
リーンUXプロセスが実際に「リーン」たるゆえんは何なのか、疑問に思うかもしれません。 実のところ、それは製品アイデアを最も効率的な方法でテストし、どれが時間をかける価値があるかを判断することにかかっています。 そうすることで無駄を削ぎ落とし、実際に機能する製品により多くのリソースを投じることができるのです。 製品アイデアをテストするための最良の戦略は、「実用最小限の製品（Minimum Viable Product）」、つまりMVPを使用することです。
仕組みはこうです。 MVPとは基本的に、製品の妥当性をテストするために作れる最小のもの、または取れる最小のアクションのことです。 例えば、ニュースレターを始めたいとします。これは時間もコストもかかる事業です。 まず、ニュースレターというアイデアそのものに疑問を投げかけます。「ニュースレターは必要か？ 作る価値はあるか？」と自問するのです。 これをテストするにはMVPが必要です。この場合、ウェブサイト上のサインアップバーが顧客の需要を測るMVPになり得ます。 サインアップする人が少なすぎれば、関心がないことがわかるので、追加のリソースを無駄にすることなくアイデアを捨てることができます。 しかし、MVPは製品やサービスに完全にコミットする前に実験するプロトタイプである場合もあります。
そのようなプロトタイプをデザインするには、2つのアプローチがあります。 1つ目はペーパープロトタイピングです。これは最短1時間で完了できる低忠実度のプロセスで、フラップ（折り返し）を使ってページ上の異なる情報を隠したり表示したりすることで、ユーザーの画面上での体験を模倣します。 この手法の欠点は、非常に人工的で、最終製品の実際の体験を十分に模倣できないシミュレーションになることがあることです。 中忠実度または高忠実度のオプションは、デザインのより進んだ段階にある製品に適した選択肢です。 これらのオプションは視覚的・インタラクティブな品質を誇り、最終製品にほぼ完璧に一致させることができますが、欠点は制作と保守に時間がかかることです。
定期的かつ協働的なリサーチを通じて、顧客フィードバックを継続的に求める
MVPは仮説をテストする優れたツールですが、このテストを効果的に実施するにはどうすればよいでしょうか。 まず、顧客を通じた継続的な製品テストへのコミットメントがリーンUXの中核であることを知ることが重要です。 そうすることで、継続的な市場フィードバックが得られ、仮説を迅速に証明または修正するのに役立ちます。 例えば、リーンUXの一般的な戦略として、MVPを週に1回、3人の異なる顧客でテストするというものがあります。
この戦略を実践する典型的な1週間は、次のようなものになるでしょう。 月曜日には、何をテストするか、どの顧客にアプローチするかを決めます。 火曜日には、MVPを微調整し、デザインがテストしたい内容を明確に伝えられるようにします。 水曜日には、MVPの仕上げを行い、モデレーターが参加者に実施するためのテストスクリプトを書きます。 木曜日には、実際に顧客とMVPをテストします。テストは1時間以内に抑え、その後結果をレビューします。 金曜日には、収集した情報を使って、仮説を検証してデザインの次の段階に進むか、仮説を修正して翌週に再テストするかを決めます。 しかし、リーンUXはすべてコラボレーションが中心であり、リサーチ段階も例外ではありません。
ですから、タスクを外部の専門家1人に任せるのではなく、チーム全体をプロセスに参加させましょう。 リサーチを外部委託することは、外部バイアスが加わるため、実は良くない戦略です。 チームに専門のリサーチャーを1人加えつつ、グループでリサーチを実施する方が良いでしょう。 例えば、テストする側面を決める際には、開発者とデザイナーの両方を巻き込んで、バランスの取れたテストを実施できるようにしましょう。 リーンUXが何であり、どのように機能するかを理解したところで、次はこの実践をあなたの組織に最適に統合する方法を学びましょう。
シンプルな変更で職場の協働可能性を高め、リーンUXを効果的に導入する
すでにご存知のとおり、リーンUXは単なる一連のプロセスではありません。それはマインドセットであり、経営理念であり、成功裡に統合するには組織的な変革が必要です。 チームメンバーに自分の役割を超えて考えるよう促すことが不可欠です。そうすることが協働環境の醸成に役立つからです。 例えば、「普通の」企業では、従業員は自分の役職や職務記述に従う傾向があります。 そのため、自分の責任範囲を超えることを躊躇しがちです。
これの問題点は、従業員のスキルの全範囲が活用されないことにつながる点です。 つまり、各人にはデザイン、リサーチ、開発などの主要な能力がありますが、チームメンバー全員が二次的なスキルや関心を活かして他の分野にも貢献できるのです。 例えば、創造的な思考を持つソフトウェア開発者がデザインにも関わることができます。 その結果、コラボレーションの増加に伴い、より積極的で友好的な雰囲気が生まれ、サイロ思考を避け、チーム全体が結果に対して責任を持つための適切な環境が生まれます。 では、このような環境をより良く促進するにはどうすればよいでしょうか。 チーム間のコラボレーションと対話を促進するオープンなワークスペースを作りましょう。
これを実現するにはいくつかの方法があります。 1つは、コラボレーションに対する物理的な障害を取り除くことが不可欠です。 パーティションが従業員を互いに隔離しているかもしれませんし、オフィスのフロアプランが部署の分離を強いているかもしれません。 もう1つの生産的な変更は、ペルソナやプロトタイプなどをスケッチでき、チームメンバーがフィードバックやサポートを残せるホワイトボードのための十分なスペースを確保することです。 しかし、チーム全体が1つのスペースを共有することが不可能な場合もあります。 このような場合、最善の選択肢は、Skypeなどのツールや定期的な集まりを活用してコラボレーションを促進することです。
まとめ
本書の重要なメッセージ： ソフトウェアベースの製品に支配される今日のウェブ駆動型経済では、ソフトウェアの継続的な性質が迅速な製品アップデートを不可欠にしたため、製品ライフサイクルはますます短くなっています。 時代の先を行くには、ユーザーフィードバックを求めながら絶えず実験することが鍵です。リーンUXは、その協働的で対話的なアプローチを通じて、これらのタスクに完璧に適しています。 さらなる読書の提案： マーティ・ケーガン著『インスパイアード』 『インスパイアード』は、成功するソフトウェア製品を生み出すためのベストプラクティスを説明し、最も一般的な落とし穴とその回避方法を解説しています。 その教訓は、駆け出しのスタートアップから大企業まで、さまざまな製品環境に適用できます。
