Laurence McCahill、Spook Studio というイギリスに拠点を置くデザイン・エージェントのデザイン・リード兼創設者が書いた「An Introduction to Lean」という記事が LeanUX/Startup について良くサマライズされています。
Lean コンセプトの背景やメリット、適応方法などが分かりやすく書いてあり、正にイントロダクションに相応しい内容になっています。私個人の知見も交え、当記事を日本語に翻訳したので公開します。
もし日本において1つ長けているものがあるとすれば、それは紛れもなく車の効率的な生産だと思います。そして Lean の発想が生まれたのも、トヨタが自社製品の開発においてより効率的な車の生産方式を模索していたときのことでした。
トヨタの生産方式がベースとなった幾つかの原則が Lean を象り、今では様々なビジネスに応用されています。そのコアにあるのが、不確実性が招くリスクと不必要な無駄を最小限に止めて新たな価値を創出するという概念です。最近では Eric Ries 氏の執筆などの活動を通じてスタートアップにも応用されるようになりました。
リーン・スタートアップ ―ムダのない起業プロセスでイノベーションを生みだす エリック・リース 伊藤 穣一(MITメディアラボ所長) 日経BP社 2012-04-16 売り上げランキング : 353 Amazonで詳しく見る by G-Tools |
リーン・スタートアップは既にあるカスタマー・デベロップメントやアジャイル・ソフトウェア開発で網羅されている教訓をモデリングしており、革新的なプロダクト(ウェブサイトやアプリ、サービス問わず)を開発するための科学的な技法として注目を浴びています。
ここ数年ではありがたいことに Janice Fraser 氏や Jeff Gothelf 氏の働きにより、個々のデザイン・コミュニティ上でも Lean UX の動きが活発になってきています。
(Lean は柔軟なアスリートになることであって、スケルトンになることではない。)
では何を持って Lean を Lean と称すのか?
- 成果物ではなく、エクスペリエンスをデザインすることに重きを置く。結果としてプロジェクト・サイクルの時間を削減することができる。
- ソリューションではなく今抱えている問題に着目することによって不確実性を排除する。前提条件や仮説を検証、テストする。
- 証拠ありきの意識決定を迅速に行う。直観を避け、ファクトに注目する。
- プロダクトやサービスをデザインするために共同で作業をするアプローチを取る。メンバー間のコンフリクトを押さえ、クライアントをエンパワーする。
- イテレーションを繰り返すことによって、より精度の高い結果を導く。無駄を最小限に止め、成功するプロダクトを創出し続ける。
なぜ今なのか?
クライアントからの依頼や相談はすべて「わかりきった」問題であることが多く、どのようなソリューションを提案するかはあなた次第であることが多かったと思います。結果、通常は以下のようなプロセスで流れていきます。
- クライアントが依頼するエージェンシー(発注先)を決める
- エージェンシー(発注先)がスコープを定めて予算を提出する。
- エージェンシー(発注先)が画面設計やデザインを起こす。
- クライアントが意思決定をし、開発の準備に進む。
- エージェンシー(発注先)がプロトタイプを開発し、テストの準備をする。
- クライアントがプロトタイプを確認する。
- ユーザビリティ・テスト。
- 修正、そしてローンチ。
このプロセスはビジネス・モデルやカスタマーなどのファクトに対して不確実性が極めて低い場合のプロジェクトに対して有効だと言えます。一方で、非常にレアなケースであるとも言えます。前提条件や仮説が未検証のまま、ついついクライアントと自分が多くを求めてしまって解決しなければいけない問題への理解が乏しくなってしまいがちです。
そのたまには見込み客から「何をするのか」ではなく、「何をしようとしているのか」をプロジェクトの早期ステージから学ばなければなりません。スタートアップが真っ先にこの重要性に気づき、早期から学ぼう、学ぼうとする姿勢を保つようになりました。結果的に何十億も稼ぐビジネスへと成長していっています。
より安価に、より早く、そしてより良く
クラウド・コンピューティングや SaasS などの技術的な発展によって、これらのサードパーティはリッチなサービスをより早く開発することを可能にし、スタートアップも一流企業と同じ土俵で戦うことが可能になりました。これは何を物語っているのか。それは、顧客のニーズの変化に伴いより早く、よりクイックに動けるようになったということです。
ここまでは分かった、ではどう応用すればいいのか?
1. 顧客について学ぶ
不確実性が比較的高いプロジェクトに Lean は最も適しています。より検証する仮説や前提条件が多いほど、成功する機会も増えるということです。
Lean のコアとなっているカスタマー・デベロップメントはプロダクトやサービスのマーケット・フィットを模索するための最適なソリューションであり、あなたがこれから提供しようとしているプロダクトやサービスを愛してやまない人々を発見することができます。最も効果的な方法は、将来的な見込み顧客に対して(できればフェイス・トゥー・フェイスで)インタビューをすることです。他にもアンケートを実施したりやメールアドレスの入力フォームを設けたランディング・ページやデモを用意することで、ビジネス・モデルの様々な性質をテストすることができます。(価格やマーケットにおけるポジショニング、セグメントなど)
(私はあなたがどれだけ頭が良かろうと気にしない、なぜならあなたが提供するすべてのデザインはすべて仮説となるのだから。)
2. 見せる何かを作る
先ず、あなたの担当するプロダクトやサービスのバージョン1となる「Minimum Viable Product(自分の作るプロダクトにニーズがあるかどうか検証するための必要最小限の機能を備えたプロダクト)」を作ることから始めましょう。ユーザテストを実施し、イテレーションを繰り返すごとに改善を繰り返してみてください。完璧に近い状態ではなく、最低限のレベルで稼働するプロトタイプを、です。作ったものに価値を見出せない場合は、リスクが小さい内に軌道修正を試みる好機です。ただ、必要最小限になり過ぎないように気を付けましょう。必要最小限のボーダーラインはターゲットとなるユーザが対象のプロダクトやサービスに対して魅力的だと感じるまでのレベルのことです。ベースラインのデザインやユーザビリティをある程度担保するために先ずは小さく進めてみてください。
3. レスポンスを測る
本当に測定しなければいけない指標にフォーカスしてみましょう。例えば、会員獲得のコンバージョンやリピート率、支払い画面のドロップ率などです。PV の合計などの指標はあなたのプロダクトやサービスの改善に必要な指標としては満たしていないと言えるでしょう。
Eric Ries 氏も言っていますが、このような指標は確かに我々に達成感を与えてくれますが、次のステップへのガイダンスは示してくれません。
4. 磨いて繰り返す
学び続ける、作り続ける、測り続ける。このフィードバック・ループやあなたが辿り着きたいところへと確実に導いてくれます。
Lean なプロジェクトを廻すための使えるツールはいろいろあります。
(Lean は:賢い、軽い、早い、見える、協力的、目を瞠る、チャレンジング、クリエイティブ、貴重、競争優位。Lean ではない:簡単、安い、スタートアップのみ、クリエイティビティの代案、儲かることを約束された技法、ゲリラUX、ロシアン・ルーレット。)
Lean が上手くいかないとき
- ソリューションが FIX したとき
- 周囲の環境に適応せず、プロセスそのものに固着しすぎたとき
- 意思決定者が不透明なとき
- プロダクト、デザイン、開発間で十分のコミュニケーションが約束されないとき
- プロジェクトがエゴや政治であふれているとき
まとめ
(1回だけではイテレーションとは言いません。)
- よく学び、早く失敗して早くビルから出ること!
- 作る前に偽物だと偽れ。
- 始めは小さく、そして徐々にスケールを上げること。
- イテレーションしつづけること。
- ビジョンを見失わないこと。
- MVP:ミニマムであること=未完成ではないということ。
- ウェブはあなたの実験場であるということ。テストし続け、測ること。
あとはあなた次第…。