リーンスタートアップで失敗する18のパターン

ローレムに提供した下記ネタの原文を自分の活動ログとしてこっちにも残しておきます。（マルチポスト的でごめんなさい） 余裕があればもっといっぱい色々書きたいことあるので追記していきます。多分。やっぱしないかも。

l-orem.com

---

リーンスタートアップで大事なことは、リスクを最小化するという価値観や考え方だ。一方Webや書籍ではどうしても教科書的な内容が多い。その様な環境において、初学者はどうしてもそこに書いてあるやり方ばかりにフォーカスしてしまう。結果「これはリーン」「これはリーンでない」というどうでもいい議論になりがちだ。本記事ではそこに一石を投じたいと思う。 リーンスタートアップを方法論として捉えてる人へ・・・うまくいきゃどうやったっていいじゃん！

本記事は4/16に開催されたリンスタ関ヶ原での発表「LEAN STARTUP アンチパターン」から抜粋した物です。

1. キャンバス依存パターン

リーンキャンバスは分かりやすい。不確実性の高い事業を進める上でのチェックポイントが羅列されているからだ。ツールとしての分かり易さは時に副作用をもたらしてしまう。それはキャンバス以外のところにもリスクがあるという事に想像力が働かないという事だ。事業/チーム/自分/会社の置かれている状況によって、リーンキャンバスには出てこない目に見えないリスクは様々だ。

リーンキャンバスには出てこないが、後々問題になる目に見えないリスクを以下に列挙する。

• 誰とはじめるか
• メンバーの熱量の差異（チームの持続可能性）
• 自分だけでその領域でやっていけるのか
• チームがその課題を解決する必然性はあるか
• チームにその課題を解決することは出来るのか
• 誰から出資をうけるべきか（ステークホルダーを誰にするか）
  社内でやるべきか、社外でやるべきか
• 誰がボトルネックになるか（決裁マラソン、上長、部下、チーム）
• 市場や技術動向の状況と、投入のタイミング
  その領域は、仮説検証を短サイクルあるいは低コストで回せるか
  （SaaSなどのクラウドを利用して検証が可能か）
• 法的、規約的、業界の慣例的なルール違反をしていないか

不確実なことを全て洗い出そう。そしてリスクが高い順に検証していけばよいのだ。

2. そもそもFounder/Market Fit、Founder/Product Fitしていないパターン

起業家の例 photo by kevin, pakutaso

Founder/Market Fitはファウンダーが対象のマーケットを良く知っている状態。Founder/Product Fitはファウンダーがそのプロダクトをよく使う層という状態を言う。起業家がマーケットにフィットしているか、プロダクトにフィットしているかは、２つの側面において重要だ。たとえば上図の起業家がそれぞれ「パーソナルコンピューターを作る」となった場合にどうなるだろうか。

スタート地点ですでに不確実性がより少ないという側面

業界を知っていれば、以下点においてスタート時点で有利である。

• 参入するドメイン出身で業界事情に明るい
• 特定領域での専門性を持っている
• その領域において人脈がある（メンター候補/アーリーアダプター候補）
• 業界慣例、文化に詳しい（今後仮説検証を進めていく上で有利）
• そのドメインに対してとても深い不を感じている

ファウンダーの持続性という側面

ファウンダーの熱量は持続性に影響し、それは成功事例を生み出す事につながる。心に問うてみてほしい。

• たまたま、そこに課題を発見しちゃったから、はじめたの？
• なぜ、それをやっているの？
• あなたがやる必然性は？
• その業界の人と同じ温度感で課題を感じているの？
• もしくは、あなたはそれを毎日つかうの？

ファウンダーに熱量がなければ新規事業は継続しない。なぜなら新規事業は大抵失敗するもので、心が折れるからだ。会社の新規事業組織から成功事例が生まれにくい理由の一つである。

企業内新規事業部門の多くは、「はい、あなたは明日からこの部署ね。そして新規事業を立ち上げて下さい。」というような人事異動により新規事業に取り組みはじめることが多いかもしれない。そのため、個人差はあれど、野生の起業家に比べ命を懸ける度合いが違う。成功するまでやり続ける力が維持しにくく、続かないのだ。新規事業は、熱量ある人がやるべきで、会社組織としては、そういった人を常に補充し続ける必要ある。

リクルートの新規事業組織の例。熱量のある人を補充し続ける仕組み

リクルートの新規事業では、新規事業部門の人間が新規事業を行うのではない。全社的に新規事業に意欲のある人間が自ら起案し、採択された案だけが新規事業としてスタートを切る仕組みをとっている。

3. MVPでシンプルにやらなきゃだめだよ！だって、ネットの記事にそうかいてあるしパターン

シンプルなMVPでやらないとダメという風潮がある。本やネットの記事によるキラキラした事例に洗脳されている。もちろんこうした例がダメなわけではない。最初はシンプルでよいと思う。しかし競合がいる、あるいは現れた時、シンプルなMVPで仮説検証できるだろうか。物事を伝えるときはあえて極論から、こうした事例で説明される事が多いが、現実はそうはいかない。本に書いてあるような綺麗なMVPを目的化してしまう事がある。あくまで目的は仮説を検証することだ。

ソリューションの一部やニーズの確認さえできればよい場合、シンプルなMVPで足りるかもしれない。しかし競合がいる場合や、マネタイズの検証を行いたい場合は慎重な検証が必要になるだろう。シンプルなMVPではプロダクトの本来の姿を被験者に想像力で補ってもらう部分が不確実性として残ってしまう。こういったフェイズでは競合や代替手段の「当たり前品質」をしっかり満たした上での検証が時には必要になる。MVPならぬMSP（Minimum Sellable Product：お金を稼げる最小限のプロダクト）という概念で考えると分かり易いだろう。

4. 石橋叩きすぎパターン

小さい仮説検証ばかりで先に進めないパターン。仮説検証で100%の確証を得ようと考えていないだろうか？

「いつまでインタビューをすればいいのですか？」

この様な質問を受けるが、答えは「なんとなくわかるまで」だ。100%の理解はサイエンスの度が過ぎる。アート20%、サイエンス80%を意識するのがよい。常に顧客を向いてフィードバックを得れていれば、間違った時の軌道修正も素早くできるはずだし、そもそも素早く仮説検証し失敗を重ねるのがリーンだ。

80%の肌感についてもう少し触れると、10人ぐらいインタビュー続けると次の人の言うことが想像できる様になってくる。そしたら80%来た、と思ってよいだろう。

5. シングルタスクパターン

なぜか一個づつやるパターン。1つずつ仮説検証しなくてはいけないと刷り込まれていないだろうか。幾つかの仮説を同時に走らせておいた方が、１つがダメだった時のリスクヘッジになる。チームであればそれが出来る。ロジック的に依存性がなく並列検証可能なら、同時に仮説検証することも検討する。

6. 誰そのペルソナ、本当にいるのパターン

ペルソナなんかよりもむしろ、課題をもっていて解決してあげたい実在する人の氏名を書くほうが効果的。最初の救う誰かを具体的に氏名で決める。ペルソナは存在しない可能性があるが、実在する人間なら少なくとも1人のユーザーが存在する事になる。

デモグラで切れるようなセグメントの課題なんて既に大抵解決されているし、その様なペルソナに陥るのはソリューションありきだから。ソリューションから逆算して「当てはまる人誰かな〜」と考えた結果、ありもしないペルソナが出来上がるのだ。

7. その人お金払わないよねパターン

カスタマーを誰に置くのか。誰からお金をもらうのか。当たり前だがお金をもらう人を軸にしないと事業は継続しない。成功する前に終わってしまう。

事実私自身、誰からお金を取るかを考えずに始め、最終的にマネタイズが出来なくて終わった経験がある。お金を払う人をカスタマーセグメントに置いて考えた事がなければ、今すぐ考えた方がよい。

8. 何か言っているようで何も言っていないパターン

トートロジー（英語：tautology, ギリシャ語：ταυτολογία）とは、ある事柄を述べるのに、同義語[1]または類語[2]または同語[3]を反復させる修辞技法のこと。同義語反復、類語反復、同語反復等と訳される。関連した概念に冗語があり、しばしば同じ意味で使われることもある。また、撞着語法はトートロジーの反対の技法である。 — wikipedia

VP（バリュープロポジション）とCS（カスタマーセグメント）の例。次の様な書き方をしているケースは驚くほど多い。

もう１段踏み込んで考えるとこうなる。

9. キャバクラでの我々パターン

インタビューでよくあるパターンだが、話を盛り上げようとし過ぎて回答者が気分を良くし、自分の（想像による）意見を言い出し、かつそれが止められない状況。潜在ニーズを調査するようなインタビューの場合、事実だけを吸い上げたいはずだ。想像による発言では仮説検証には使いにくい。場合によっては誤った判断材料となってしまうだろう。 そうなる前に、どうにかして流れを変えるしかない。未来の話はいらない。過去の事実を集約し、それを横断的に分析、共通項を抜き出すというやり方を意識するのだ。

10. リーンスタートアップ、僕、好きじゃないのでパターン

好きとか、嫌いとかそういう話じゃないと思うけど・・

新しい何かを組織にインストールする際には付き物だが、組織でリーンスタートアップを初めてやろうとすると、何と戦ってるのか分からないような人がしばしば出てくる。個人的には、サービスが上手く行けばなんでも良いので、別にリーンこだわる必要は無いと思っているが、全てを別物として捉えている人たちは本質が見えていないので危険である。

一つの課題に対して、光の当て方が違うだけ

AARRRからみたリーンスタートアップ

１人でも継続して利用してくれているということが大事。継続して利用してくれているということは、顧客の課題を解決していることだ（想定していない課題を解決してることもあるが）。AARRRで言うRetentionは、ユーザーがプロダクトに価値を感じている状態、つまりエンゲージしている状態でP/S Fitの指標となる。

制約理論からみたリーンスタートアップ

鎖全体の強度とは、最も弱い輪っかの強度と同等である。最も弱い輪っかを見定め、そこを直せば鎖全体の強度が高まる。その概念と同じで、最もリスクの高い部分を割り出し、検証していく。１つ不安要素を潰したら、次に高いリスクを割り出し検証する、というのを続ける。

リスクの高い部分が鎖の強度が弱い箇所となる

狩野モデルからみたリーンスタートアップ

魅力品質 : UVPであり、他に真似されない部分。

性能品質 : あればあるだけあった方がよい部分。

当たり前品質 : P/S Fit時にはいかに小さくできるか考え（コストの削減）、マネタイズ検証時にはいかに最大化できるかを考える。

Feature Toggleからみたリーンスタートアップ

Feature Toggleは、いろんな実験的な機能を、部分的にサービスにリリースするボタンの様なもので、今や多くの巨大なサービスでは当たり前の様に使われている。これは１つ１つの実験的機能がMVPに値し、最初は開発チームだけに公開。次に、全体の5%のユーザだけに公開、さらに次は10%といった具合に、仮説検証を本番環境でユーザーに対して実施する手法。大きくリリースして大きく失敗してしまうリスクを最小化できる。

ポール・グレアムの言葉からみたリーンスタートアップ

自分が欲しいものを作れ — ポール・グレアム

自分が欲しいものを作れば、自分がまずは使い始めるはずである。少なくとも課題を持ったユーザーが１人はいる状態からスタートするのだから、F/P Fitであり、失敗しにくくなる。

11. エンジニアが上手くフィットしないパターン

エンジニアが作ることのみにコミットしている場合、仮説検証のやり方についてこれない場合がある。素早く検証したいのに、豪華な何か、高品質な何かを創りだしてしまい、検証が思いのほか回らなくなる。エンジニアには「QCD-ScopeでQ抑えめでD重視」と伝えたり、エンジニアに刷り込まれている昔ながらの価値観、優先順位を壊すことが必要。さらに必要に応じて権力・責任のある人に言ってもらうなどが必要だろう。 状況に応じてQCDとスコープの優先順位が変わることを伝え、その上で、この働き方についてこれるエンジニアとやる。

サービスのフェーズによって変わる、エンジニアに求められるコミット

アーリーステージは特に視野を広げる

参考 :

• エンジニアもユーザーに会いに行こう 小さく始める大規模スクラム
• エンジニアもデザイナもヒアリングする Incrementsの文化を作る方法

12. 割り込みが・・・パターン
13. いくつも打ち合わせが・・・パターン
14. リモートワークが・・・パターン

割り込みや打ち合わせ、一概に「ダメ」と言ったり、逆にリモートワークさせろと言いはるのは独り善がりだ。今チームがおかれているフェーズおよび、最重要なことは何かを考えてみて、それが必要ならそうすれば良い。例えば頻繁な割り込み・打ち合わせがあったとして、それがそもそものアイデアの種を良くするのであれば、聞く耳を持たなくてはならない。これは全体最適か個別最適かの話で、Buildの高速化のみを考えているのはよくある事だ。仮説検証サイクルのボトルネックがBuildにあるならそれでよいが、他にネックがあるならその時Buildを最適化する必要はない。

15. UVPを見つけに行ってるはずなのに、顧客の声を聞いた挙句、既にある何かにたどり着いちゃったパターン

ある病気の患者は医師に宣告を受けてから自分の治療法を決めるまでに時間が無く、ツテも無く、お金も無く、落ち着いてもいないので、セカンドオピニオンサービスが必要なはずだ、という仮説を持った。しかしヒアリングの結果、セカンドオピニオンまでははいらなくて、「みんなは」同じような境遇の人、同じ病状、同じフェーズの人が今何をしているか知りたい、繋がりたい、という事実が得られた。あーあ、じゃあSNSでいいじゃん。となり、UVPが無くなってしまう。 こうなる原因は２つある。アイデアがくそだったパターンと、あーあ、で終わり、次が探れなかったパターンだ。

16. 性能競争パターン

既に世に出ているとある製品に対し「ここが悪い」と思った部分を改善したり「ここが足りない」といった機能を追加で実装するだけで新たな製品を世に送り出すこと。もう少し広義にとらえると、コンテンツのラインナップかもしれないし、パフォーマンスかもしれない。

しかし、その既存製品が改善してきたらどうするのだろうか？ 緩やかな性能競争は体力勝負となるため、フォロワー戦略は参入コストが高すぎるのである。

性能競争で勝ちを狙うなら、圧倒的な差をつけるに限る。テクノロジーによって100かかってた労力や時間が1にできたり、数万円だった価格を無料にできる場合などだ。

17. 解決策ありきパターン

ソリューションありきでの考えは全てにおいて失敗しかない。誰の何を解決するのか？がすっとばされた状態だからだ。これはただひらめいただけで、そのまま事業化しよう物なら失敗しかしない。 一方でソリューションが優れている場合もある。研究施設などから発見される発明などだ。その場合は誰の何を解決するのかをしっかり紐付けたい。

18. ○○がそれやったらどーすんのパターン

プラットフォーマーと呼ばれている企業が、同じ領域を、大量の資金でもって上書きしにきたらどうするのか。それに対抗できる状況を作らねばならない。

戦わないですむような戦略 : 市場の再セグメント化を行い、生きる道を探る。

戦うけど優位な状況で戦う : ゲリラ戦。例えばニッチな市場を強力に抑えてしまう。

相手が参入出来ないスペースを狙う : 法的にグレーなゾーンを狙い、プラットフォーマーが自己矛盾起こすような戦略。

先にユーザを掴んで売る : 先行者優位な市場であればユーザ掴んで、プラットフォーマーに事業を売り抜ける。これも選択肢の一つだろう。

まとめ

リーンスタートアップの不確実性やリスクという表現を制約理論からみるとボトルネックと捉えることができる。リーンスタートアップとは事業を進める上でのボトルネックを消して行き、事業のスループットを最大化する、という基本的な話だ。その意味では、リーンキャンバスの項目は、ほんの一部でしかなくて、各種ステークホルダーの意思決定がネックならそこを動かすこともスコープに入れないとならないし、メンバーの熱量がネックならそこも上げないとならない。自分がコミットする範囲やスコープをどれだけ広げるか、といった少し面倒に見えることも、根本を正せばボトルネックを見極め、消していく、というたった１つの事である。