「リーン」について : 「何を作るか」よりも「何を作らない」か

2013年に「リーン・スタートアップ」という書籍が出版されて、それからリーン (LEAN)　という考え方に注目が集まるようになった。LEAN とは「無駄のない」とか「ぜいにくのない」とかそういう単語らしい。

書籍リーン・スタートアップには「スタートアップやその類が新しい事業を始めるときに普通にやってるとだいたい失敗するから、潜在顧客や顧客からのフィードバックをこまめに集めて軌道修正しながらゴールを見極めるやり方が良い」とか、雑にまとめるとそういうことが書いてる。

仮説を立ててフィードバックをもらって検証するということを短いイテレーションで繰り返す･･･というのを "フィードバックループ" と呼んでいて、それを細かくやる場合、製品を作り込んでからフィードバックをもらうのでは遅いし、例えばペーパープロトタイプをするとかそういう実験的なことで欲しいフィードバックが得られるならそれが一番いい ─ そういう主張でもある。

ちなみに自分としてはリーン・スタートアップ信奉者でもなんでもない。

Peter Thiel のリーン・スタートアップ批判?

一方最近、元 PayPal の創業者である Peter Thiel が書いた「ゼロ・トゥ・ワン」という書籍を読んだ。(以下 Zero to One) この本はリーン・スタートアップ的な考え方を手厳しく批判している･･･という点で注目を浴びている。なんとなく書籍のタイトルから言わんとすることは想像できるが、実際のところは本編ではリーン的なやり方についての批判はあまり見られない。というか、アイデアを実現するにあたって細かく刻んでいって変化に適応しやすくするべき、というような観点についてはほぼリーンの考え方それに近いことを述べてる。

唯一彼がリーン・スタートアップを批判したとすれば、Peter Thiel はスケールがでかいことが好きなので「小さいプロダクト作って顧客からフィードバックループを集めるとかそんなことじゃ、例えば宇宙輸送とかテスラの電気自動車とか代替エネルギーとか、そういう未来は描けないじゃないか」というような、"ビジョン" とかその辺をどう考えるかというところである。そこに関して異論はない。

ただ、Zero to One の中で彼はリーンのことを

それはすなわち「計画しない」ことである。ビジネスの先行きは誰にもわからない。計画を立てるのは傲慢であり柔軟性に欠ける。むしろ、試行錯誤を繰り返し、先の見えない実験として起業を扱うべきだ

とそんな主張だと解釈しているようだった。これは瀧本哲史が書いている序文 (この序文ははっきり言ってひどい) にも

リーン・スタートアップでは、事前にあまり計画せずに、少しずつ改善することを重視するが、ティールはそうしたスタートアップは結局は成功しにくいと考える

と言う一文があるし、彼らはリーンは「計画をあまりしないこと」だと思っている節がある。

ここに関して、自分の実感とはちょっと違うなと思ったのでブログに書いてみようと思った次第である。前振り終わり。

リーンについて

自分が思うに、リーン・スタートアップやそれに続く「リーン何々」というのはその時のその人のおかれている状況によって結構捉え方が違うものだろうなと思っている。

大企業などでしっかりとした事業計画をを作って物事を進めなければという立場の人には「そんなに計画作りに労力を割きすぎても思った通りにはいかないから適当なところで切り上げたほうがいい」という主張に聞こえるし
スタートアップとかで無鉄砲にあれもこれも作ったりしている立場の人には「事前にコンセプトをはっきりさせるとか、仮説を立てるとかユーザーと向き合うとかそういうことにもう少し時間を使った方がいい」という主張に聞こえる

そんな感じの印象を持っている。

特に自分は、後者の、スタートアップが当初の勢いに任せてあれもこれも作りまくった結果それが原因で失敗する･･･たとえば製品が無駄に複雑になったり、余計な仕事を増やしてしまって本来やるべきことにフォーカスできなくなってしまう、そういう場面を多く見てきたし、例に漏れず自分もその罠にはまったことがある。だからリーンという考え方が "「何を作るか」よりも「何を作らないか」" という選択をするときの一つの考え方にはなるのかもな、と思っていた。

2013 年の年末頃に開催された Exciting Coding! 2013 というイベントで、Qiita を作っている Increments の id:yaotti が講演の中でまさにそういう話をしていた。

起業当時に作ったプログラミングの Q&A サイトが Qiita に変わっていくまでの過程、ある意味失敗を通じて彼はやはり「何を作らないか」が大事だという考え方に至って、そのためにリーン・スタートアップの文脈で言うところの MVP (Minimum Viable Product) によってアイデアを作る前に検証できたらそれが一番良いかもしれない･･･と述べていた。起業のプロセスを通じてこういう考え方に至るまでの実体験を淡々と話す彼の様子を見ていて感銘を受けたのをよく覚えている。

このあたりのコンテキストが自分にはあったので、リーンが「計画をあまりしないこと」というのは自分の実感とはだいぶかけ離れている。むしろある程度計画を立てることによって「やらないこと」をはっきりさせるための方法論という風にも見えている。

問題をどう解決するかよりも、何が問題かを見極める

ところでまた最近別に「イシューからはじめよ」という本も読んだ。(後半の方法論の所は自分にはちょっと眠たかったけれども) なかなか良いことが書いてた。曰く価値の高い仕事 ─ 著者はそれをバリューの高い仕事と呼んでる ─ を成し遂げたかったら「どんな風にその仕事をこなすか」ということよりも「どんな問題 (イシュー) を解決するか」ということ、つまり問題の見極めこそがとても重要だということを論じている。

これ、言われてみれば当たり前のことなんだけれども、人間なぜか問題の見極めよりも、プロセスにばかりやたらと拘ってしまうところがある。このブログを読んでいただいている方の文脈で言えば、たとえばスクラムとか、テスト駆動開発とか Github で云々とか、そういうプロセス、道具を良くしていけば優れたソフトウェアが作れるとか、そんな風に勘違いしてしまったことが一度は誰でもあるんじゃないだろうか。自分もあった。

でも実際には、優れた製品を作るにはその製品がちゃんとユーザーの問題を解決しているかどうか、それを知るということが最も重要であり、どんなにプロセスばかりを良くしたってその領域には到達できない。(もちろん、良いプロセスは大事なので両方できるのが一番良い)

例えば、ソフトウェア開発の組織においてこの図でいうところの横軸には気を遣わず、タテ軸ばかりを頑張ったとする。すると、ユーザーの問題は全然解決されないけどやたらと物を作る速度ははやい、そんなチームができあがる。

みんな一度は触ったことがあるはず。やたらと機能がてんこもりでカタログスペック上は何でもできる魔法の製品だが、いざ触って見るとこれっぽっちも問題を解決してくれない･･･そんなプロダクト。具体名を書くといろいろ燃えそうなので、まあそれはモザイクにした。その逆をうまくできれば Qiita とか Slack とか、我々が好きなソフトウェアがちゃんと作れる。

で、ソフトウェア開発の方法論とこのイシュー云々の話を結びつけるなら、スクラム、継続デリバリー、Github 云々といった最近の開発手法の話は「イシューからはじめよ」の絵でいうところのタテ軸を伸ばす方法論で、リーンは横軸をどう考えるかというための処方箋であるという風に捉えられる･･･と思った。

起業もそうだしソフトウェア開発もそうだし、いや、仕事延いては人生など諸全般において、問題を正しく見極めるということはとても重要なことである。その時に闇雲に物事を進めるよりは「何をやらないか」というコンセプト決めとかそういうことを少しやるだけで物事はずっとよくなるし、逆にそればっかりをやっているなら、もう少し柔軟にやってみたら? というのがリーン的な考え方だろうと、自分は思っている。

ビジョンも必要だよ

一方、途中に書いた Peter Thiel が述べているような「どうせやるなら大きく賭けろ」みたいな話もそれはその通りかもなとも思ってて(それは最近読んだ Erik Shmidt が書いた「How Google Works 」にも同じことが書かれてた)、なんだかんだでユーザーがびっくりするような物を作るにはそういうビジョンというか思い込みみたいなものに賭けるという側面も絶対になければならないと思ってる。

それらをすべて机の上に載せると、情熱とかビジョンとかそういうものに突き動かされて未来思考で物を作るということと、現実的にはここまでに述べたような問題を正しく見極めること、どちらか一方じゃなくてバランス良くそれをやってくのが最善である。

･･･以上、幾つか本を読んだ割には月並みな結論に達してしまった、という話であった。終わり。