LEANSTARTUPアンチパターン #devlove #leanstartup

LEANSTARTUP アンチパターン

RECRUIT Technologies Co., Ltd. Itsuki KURODA @i2key

黒田　樹　(@i2key) <= Follow me :-) SIer 官公庁系大規模システムのアーキテクト

Recruit スマホアプリ(iOS/Server)のエンジニアやプロダクトオーナー

Recruit Holdings 数年、累計1400万DL規模アプリシリーズ( https://cameran.in )の開発責任者。開発、採用、プロセス策定、組織設計等のCTOぽい仕事。昨年、99designs ( https://99designs.jp ) の日本展開支援。

Recruit Technologies 今年からは、エンジニア育成やエンジニア組織・文化づくりみたいなことに挑戦します。

その他活動社内外でリーンスタートアップとかアジャイルとかについて話をしたり、社内の新規事業コンテストでの企画の壁打ち役/メンターをずっとやってきました。

http://www.slideshare.net/i2key/bp-leanstartup/42

99designsの日本展開(マーケ)をリーン・スタートアップスタイルでやった

事例はこちら

僕とリーンスタートアップエンジニアが救われている開発現場にしたい

使われないモノ、必要ない何かに対する開発でエンジニアが疲弊する現場は健全ではない

http://www.slideshare.net/i2key/45-developers-summit-2015-devsumi-devsumib http://www.slideshare.net/i2key/devsumi-natsumic7

※各種スライドの再演は必要であれば、お声がけください（色んな会社へあそびいきたいだけ）

リーンスタートアップで新規事業をたちあげるときに発生するよくあるアンチパターン/あるあるについてお話します。（※場合によってはアンチじゃないケースもあります）

あるある～と笑うもよし。

反省するもよし。

図星なのを隠して笑うもよし。会社のSlackに投げてざわつかせるもよし。

みなさんの事業の不確実性を少しでも減らすことにご利用していただければ幸いです。

みなさんリーンキャンバス

使ってますか！！！？

顧客は誰？課題は何？解決策は？

価値は何？圧倒的優位性は何？

コスト構造は？売り上げは？

顧客にリーチするためのチャネルは何を測る？

キャンバス依存パターン

リーンキャンバスは分かりやすく不確実性の観点が列挙されている。しかし、それだけにフォーカスすると事故る。

その事業/チーム/自分/会社の置かれている状況によって、リーンキャンバスには出てこない目に見えないリスクが介在していることをどうしても忘れてしまう。

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

リーンキャンバスに出てこないけどあとで問題になるリスク

不確実なことを全て洗い出して、リスク高い順に検証していく

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

パーソナルコンピューターを作る！http://i.gzn.jp/img/2014/01/20/steve-jobs-and-wozniak-truth/8203977390_f42ee0b5a1_o.jpg

https://www.pakutaso.com/20150911258post-6047.html

カレとふたりきりのチャット作るhttp://i.gzn.jp/img/2014/01/20/steve-jobs-and-wozniak-truth/8203977390_f42ee0b5a1_o.jpg

https://www.pakutaso.com/20150911258post-6047.html

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

または、そのドメインに対してとても深い不を個人的に抱えていたりする場合

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

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

熱量があること。新規事業は大抵失敗するから心がおれる。会社の新規事業組織から成功事例が生まれにくい理由のひとつはそれ。その部門の人は別にそれに命かけてるわけではないので、成功するまでやり続ける力が維持しにくい。続かない。熱量ある人がやるべき。会社の新規事業組織の場合は、そういう人を常に補充し続ける必要あり。

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

例）会社の新規事業組織熱量のある人を常に補充し続ける仕組み


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

MVPで、シンプルにやらないとダメという風潮。本やネット上の記事のキラキラした事例に洗脳されている。最初は、シンプルでよいと思う。しかし、実際の現場では競合が現れる。物事を伝えるときはあえて極論をいってシャープにする方法をとられることが多い。現実はそうはいかない。本に書いてあるような綺麗なMVP参考例の型に当てはめようとして、それを目的化しないこと。あくまで目的は仮説を検証すること。

充足不充足

満足

不満足

顧客の満足感

物理的な充足度

魅力品質本来MVPで検証したいこと

当たり前品質アーリーアダプターにはここ弱めにするか。とかマネタイズ検証時には

必要だね。とか Minimum Sellable Product

性能品質

魅力品質

性能品質

当たり前品質

不充足でも不満には思わないが、充足されれば満足 <例> ハイレゾ音源（あれば良いが、なくても不満ではない）、曲面液晶など

不充足だと不満、充足されると満足 <例> バッテリーの持ち（稼働時間が長ければ満足、短いと不満）、重量など

不充足だと不満、充足されて当たり前 <例> 通話音声（音が良くて当たり前、聞き取りづらいと不満）

狩野モデル

10

石橋叩きすぎパターン

小さい仮説検証ばかりで先にすすまない検証して100%の確証を得るまで動けない。

（サイエンスの度がすぎる。アート20％、サイエンス80%。）常に顧客を向いてフィードバックをもらい続けていれば、

都度、ゴールに向かって軌道修正すれば良い。

良くある例インタビューを永遠につづける。

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

シングルタスクパターン

なぜか一個づつやる。 1つずつ仮説検証しなくてはいけないと刷り込まれている。

幾つかの仮説を同時に走らせておいたほうが、それがダメだったときに、いっきに巻き戻らなくてすむ。

リスクを最小化するという価値観で考えると仮説検証失敗による巻き戻りのリスクを最小化する。

それが出来るのがチームの良い所。

ロジック的に依存性がなく並列化可能なら同時に仮説検証していくことも候補にする。

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

ペルソナなんかよりもむしろ課題をもっていて、解決してあげたいひとの氏名をかくほうが効果的。

最初の誰を救うか。

具体的に氏名まで。ペルソナは存在するかわからないけど、

氏名ならば1人は存在する。

デモグラでキレるようなセグメントの課題なんて既に大抵解決されている。

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

カスタマーを誰に置くのか。誰からお金をもらうのか。

お金をもらう人を軸にしないと。ボランティアじゃないので。

事業を作っているので。

誰からお金を取るかを考えて始めないと、最終的にマネタイズが出来なくて終わるパターンになる。

（なった経験がある）

課題を解決するために、お金を払う人をカスタマーセグメントにまずは書いて考えるべ

し。

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

トートロジー

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



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

潜在ニーズを調査するようなインタビューでこちらは事実だけを吸い上げたいのにも関わらず、

インタビューの仕方をミスって回答者側が気分を良くして、

自分の（想像による）意見を言い出して止められない状況。ドヤァ。

あくまで想像による発言なので仮説検証に使いにくい。

なので、どうにかして流れを変えること。

未来の話をききすぎ。過去の話を集約して、それを横断的に分析して共通項を抜き出すというやりかたにせい。

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

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

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

課題

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

LEANSTARTUP制約理論

AARRR狩野モデル

Agile

顧客開発モデル

Feature Toggle

Design ThinkingDesign Sprint

20

Acquisition

獲得 Retention

継続Churn

解約

Referral

紹介

Activation

活性化Revenue

収益※ChurnはAARRRには

無いけど勝手に付け足しました

大事

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

継続して利用してくれているということは顧客の課題を解決していること

（それが想定していない課題を解決してることもあるけど）

ユーザーがプロダクトに価値を感じている状態

エンゲージしている状態

Problem Solution Fit

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

最もスループットの低い部分が、全体のスループットを決める（鎖の強度は、最も強度の弱い輪が全体の強度になる）

最もリスクの高い部分から、検証していく

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

顧客は誰？課題は何？解決策は？

価値は何？圧倒的優位性は何？

コスト構造は？売り上げは？

顧客にリーチするためのチャネルは何を測る？

リスク高リスク中リスク中

リスク中

リスク中リスク中

リスク中

リスク中



①②

②②

③⑩

⑤

⑩

⑫ ②

⑩

⑩

鎖の強度が弱い

充足不充足

満足

不満足

顧客の満足感

物理的な充足度

魅力品質=UVP

当たり前品質 P/S検証時はどう最小化すべきか

マネタイズ検証時はどう最大化するか

性能品質

魅力品質

性能品質

当たり前品質

不充足でも不満には思わないが、充足されれば満足 <例> ハイレゾ音源（あれば良いが、なくても不満ではない）、曲面液晶など

不充足だと不満、充足されると満足 <例> バッテリーの持ち（稼働時間が長ければ満足、短いと不満）、重量など

不充足だと不満、充足されて当たり前 <例> 通話音声（音が良くて当たり前、聞き取りづらいと不満）

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

Permission : ROLE_ADMINPermission : ROLE_USER

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

小さく失敗して効率よく学ぶインフラ仮説検証のためのMVP（機能）を

例えば、最初は開発チームだけに公開。次に、全体の5%のユーザだけに公開しテストなどを行う

仮説検証を本番環境でユーザーに対して実施する。大きくリリースして大きく失敗するリスクを最小化。

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

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

作ることのみにコミットしているエンジニアがこの仮説検証のやりかたについてこれないパターン。はやく検証したいのに、豪華な何か、高品質な何かを創りだしてしまい、検証が思いの外、回らないケース。

エンジニアには、QCD-ScopeでQ抑えめでD重視と伝えるとか、エンジニアに刷り込まれている昔ながらの価値観、優先順位を壊すことが必要。（必要に応じて権力のある人、責任のある人に言ってもらう。）

状況におうじてQCDとスコープの優先順位がかわることを伝える。

その上で、この働きかたについてこれるエンジニアとやる。

対峙しているサービスのフェーズにより、エンジニアに求められるコミットが変わってくる。アーリーステージであればあるほど、ロールの枠を超えた働き方が求められる。

検証を設計する（実証条件/実証方法/etc）

効果を計測する

KPI（数値目標）を設定する

リリースする

ユーザがコンバージョンする

仮説をたてる

仕様にする

設計する

ユーザーに届く

ユーザーが使う

ユーザーが気づく

KPI（数値目標）達成

指標：ベロシティ/デプロイ回数/性能値/品質/コスト/etc

エンジニアのコミットと目標

データから学ぶ（仮説を修正する

　　打ち手を変える）

エンジニアが直接結果をコントロール出来る範囲

（コードのみに対峙してる）エンジニアが直接結果を

コントロール出来ない範囲（ユーザーの判断という不確実性が介在）

テストする

実装する

指標：MAU/継続率/○○率/売上/etc

検証を設計する（実証条件/実証方法/etc）

効果を計測する

KPI（数値目標）を設定する

リリースする

ユーザがコンバージョンする

仮説をたてる

仕様にする

設計する

ユーザーに届く

ユーザーが使う

ユーザーが気づく

KPI（数値目標）達成

指標：ベロシティ/デプロイ回数/性能値/品質/コスト/etc

エンジニアのコミットと目標

データから学ぶ（仮説を修正する

　　打ち手を変える）

エンジニアが直接結果をコントロール出来る範囲

（コードのみに対峙してる）エンジニアが直接結果を

コントロール出来ない範囲（ユーザーの判断という不確実性が介在）

テストする

実装する

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

指標：MAU/継続率/○○率/売上/etc

http://www.slideshare.net/keisuketsukagoshi/ss-59705472/58

エンジニアもユーザーに会いに行こう

https://speakerdeck.com/htomine/qiita-teamfalsekai-fa-wotong-sitejian-tuketekita-incrementsfalsewen-hua-wozuo-rufang-fa

エンジニアもデザイナもヒアリングする

割り込みガァーパターン

一概に割り込みがダメというのではなく、今おかれているフェーズおよび、チームとしての最重要なことは何かを考えてみることが大事。それは果たして、Buildの高速化のみを考えていないか。仮説検証サイクルのボトルネックがBuildにあるならそれでよいが、他にネックがあるなら、Build最適する必要はないのでは。

個別最適？全体最適？

30

いくつも打ち合わせガァパターン

一概に打ち合わせだらけになることが悪いというのではなく、今おかれているフェーズおよび、チームとしての最重要なことは何かを考えてみることが大事。それは果たして、Buildの高速化のみを考えていないか。仮説検証サイクルのボトルネックがBuildにあるならそれでよいが、他にネックがあるなら、Build最適する必要はないのでは。


リモートワークガァーパターン

リモートワークがダメというのではなく、今おかれているフェーズおよび、チームとしての最重要なことは何かを考えてみることが大事。それは果たして、Buildの高速化のみを考えていないか。仮説検証サイクルのボトルネックがBuildにあるならそれでよいが、他にネックがあるなら、Build最適する必要はないのでは。


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

ある病気の患者は宣告を受けてから自分の治療法を決めるまでに時間がなく、つてもなく、お金もなく、落ち着いてもいないので、セカンドオピニオンサービスが必要なはずだ、、

ヒアリングの結果、セカンドオピニオンまでははいらなくて、「みんなは」同じような境遇の人、同じ病状、同じフェーズの人が今何をしているか知りたい、繋がりたい、と思っている。じゃあそういうSNSを作ろう。 →UVPなくなりました以上

性能競争パターン

既存製品で、この機能がない、この性能が悪い、みたいなものに対して、足りない機能を実装したり、

性能を改善したりするだけのこと

その既存製品がそれをやったらどうするの？フォロワー戦略は参入コスト高すぎる

性能競争で勝つなら、圧倒的な差をつけること。テクノロジーで100かかってたのが1になるとか。

数万円だったものを無料にするとか。 UVPが存在しないパターン。

解決策アリキーパターン

省略

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

プラットフォーマーと言われている会社が同じ領域を、大量の資金でもって上書きしにきたときに

どうするのか。これに答えられない。戦わないですむような戦略

市場の再セグメント化戦うけど優位な状況で戦う

ゲリラ戦相手が参入出来ないスペースを狙う

法的にグレーなゾーンプラットフォーマーが自己矛盾起こすような戦略

先にユーザを掴んで売る先行者優位な市場であればユーザ掴んで、プラットフォーマーに事業を売り抜ける。

：：

ご静聴ありがとうございました

Small Business & Entrepreneurship

LEANSTARTUPアンチパターン #devlove #leanstartup