『Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)』をご恵投いただきました。ありがとうございます。

本書は『リーン・スタートアップ ―ムダのない起業プロセスでイノベーションを生みだす』でお馴染のエリック・リース氏が監修を努めるThe Lean Seriesの第一段としてオライリーより刊行された書籍(実際には原著第2版)の邦訳です。どうすればサービス開発をうまくやっていけるのかと、あれこれと思いを巡らせていた昨年末に「リーン・スタートアップ」という言葉を知り、エリック氏の本を読み、視界の開けるのを感じました。本書は、それをさらなる実践につなげるための本です。実際、僕自身この本から得たことをいろいろと実践してきたのが、この一年の仕事の大きな部分を占めるところでもあります。

スタートアップにとっての一番のリスクとは何か。それは、誰も欲しくないものを作り、そのことで時間を無駄にしてしまうことです。サービス開発において、我々は往々にして「ソリューション」から入ってしまいがちです。どんなに優れたアイディアや技術でもって素晴しい「ソリューション」を作ったところで、人々がそれを欲しなければ意味がありません。つまり、それは「人々の」「実際の」「問題」を解決するようなものでなくてはならないのです。我々はどうやってそれを知ることができるか。

Webサービスを作ることそれ自体は、ますます簡単になってきています。一方で、人々が求めるもの、問題としていることは多様化しており、簡単には見出すことができません。そこで、我々は「何を作るか」という考えから脱して「何を作るべきか」「なぜそれを作るのか」をもっと真剣に考えていく必要があります。とはいえ、だからといってそれを効率的に見つける方法は存在しません。だから、できるだけたくさんの試行錯誤を可能にすることが「リーン・スタートアップ」において最重要視されているわけです。

「下手な鉄砲も数打ちゃ当たる」。人々の多様性の前ではどんなひとでも「下手」であることからは逃れられません。あるいは、いくら「上手」であっても、競争相手だって同じぐらいには「上手」であるというのが「何を作るべきか」に問題が移った昨今の状況です。それならば、できるだけたくさんの弾を、できるだけ効率的に、短い時間で打つ方法を、我々は必要としているわけです。そのためにはどうすればいいか。著者は以下の3ステージにわけて、その方法を説明します。

1. プランAを文書化する
2. プランで最もリスクの高い部分を見つける
3. プランを体系的にテストする

本書が(1)の文書化の助けとなるものとして導入するのが「リーン・キャンバス」です。元は『ビジネスモデル・ジェネレーション ビジネスモデル設計書』で提案されたフレームワークを、著者が改良したものが「リーン・キャンバス」です。以下が、その雛形です(翻訳というか意訳は僕によるものなので、本書の訳とは異なります)。

実際にキャンバスを作成していくと、ところどころ曖昧になったり、よい文面が思い浮かばなかったりして、穴の開いたような状態になっていくでしょう。それが(2)のいうリスクです。できるだけ早い段階でリスクを見出し、それに対処しなければなりません。そして、そうして見出した「プランA」を、本書のもうひとつの核であるインタビューによる顧客開発などを通してシステマティックに検証していくのが、「リーン・スタートアップ」の実践というわけです。詳しくは、是非本書(もし読んだことがなければ『リーン・スタートアップ ―ムダのない起業プロセスでイノベーションを生みだす』もあわせて)を読んでいただきたいと思います。

「実践リーンスタートアップ」の実践

本訳書は「実践リーンスタートアップ」というサブタイトルを持ちます。僕自身、ひと足先に原著を読んで、自社でリーン・キャンバスなども取り入れたリーン・スタートアップ的な実践を行ってみたので、その話を少ししてみます。

「リーン・スタートアップ」それ自体については、エリック・リースさんの書籍を読んでもらうのが一番なのですが、そこは一冊の本なのでそれなりに長く、実践のためのメッセージとしてははっきりしないものになりがちです。そこで、以下のようなスライドを作成し、社内で数回勉強会を行いました。ひとつめが、経営者向けと思われがちな『リーン・スタートアップ』を、開発者向けの本としてエッセンスを紹介したものです。ふたつめは「リーン・キャンバス」の紹介。

勉強会で認識を共有してからは、実際にキャンバスやインセプション・デッキを各所で作成してみたり、また、さらに具体的には、早いサイクルを技術的に担保する環境をもたらすために、いろいろな取り組みを行ったりしました。そのいちいちを挙げるとキリがないので、同僚のhsbt氏のスライドを紹介しておきますので、是非お目通しください。

「リーン・スタートアップ」に対して呈されることの多い疑問として「仮説検証が大切なのはわかった。しかし、そもそも検証に足る仮説をどうやって見出せばいいのか」というものがあります。また「仮説検証サイクルの実際にどうすれば速く回していけるのか」というのもよくあげられる疑問です。確かに、本書にしても『リーン・スタートアップ』にしても、そのような疑問にはあまり答えてくれません。そこで僕らは、以下のような手法を取り入れてみたのでした。

1. そもそも検証するに値する仮説を作り出すための集団的アイディア醸成技法の実践(ブレストなど)
2. 余計なものを作り過ぎず、MVPを本当に「最小限」なものにするためのユーザストーリ収集
3. チーム間で作るものへの認識を共有し、「最小限」性を視覚的にも保証するためのペーパープロトタイピング
4. 開発速度を最大限に早め、無駄なく進めていくためにタイムボックスによるサイクルを回すためのScrum

そのあたりの事情は、以下のスライドに簡単にまとめてあります。「リーン・スタートアップ」という御題目を、実際のアクションに移していくために、何が大切なのかを忘れずに、論理的かつ実践的に開発を遂行していくのが大切であると考えます。

「リーン・スタートアップ」は、なにも新しい手法ではなく、いってみれば古典的なPDCAとそう変わるところはありません。それがなぜ大切なのかというと、上のスライドにも示したように、Webサービス開発のような不確定なものに対する、よりよい論理的筋道を与えてくれるからこそ、いまこのように広く話題になっているのだと思います。「古典的でも地道にやる」(© id:myfinder)。ここでもその言葉を噛み締めて、じっくりしっかりとやっていくのが成功への近道となるのだと信じます。