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

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

1. 1. LEANSTARTUP アンチパターン RECRUIT Technologies Co., Ltd. Itsuki KURODA @i2key
2. 2. 黒田　樹　(@i2key) <= Follow me :-) SIer 官公庁系大規模システムのアーキテクト Recruit スマホアプリ(iOS/Server)のエンジニアやプロダクトオーナー Recruit Holdings 数年、累計1400万DL規模アプリシリーズ( https://cameran.in )の開発 責任者。開発、採用、プロセス策定、組織設計等のCTOぽい仕事。 昨年、99designs ( https://99designs.jp ) の日本展開支援。 Recruit Technologies 今年からは、エンジニア育成やエンジニア組織・文化づくりみたいなこ とに挑戦します。 その他活動 社内外でリーンスタートアップとかアジャイルとかについて話をしたり、 社内の新規事業コンテストでの企画の壁打ち役/メンターをずっとやって きました。
3. 3. http://www.slideshare.net/i2key/bp-leanstartup/42 99designsの日本展開(マーケ)を リーン・スタートアップスタイルでやった 事例はこちら
4. 4. 僕とリーンスタートアップ エンジニアが救われている開発現場にしたい 使われないモノ、必要ない何かに対する開発で エンジニアが疲弊する現場は健全ではない http://www.slideshare.net/i2key/45-developers-summit-2015-devsumi-devsumib http://www.slideshare.net/i2key/devsumi-natsumic7 ※各種スライドの再演は必要であれば、お声がけください（色んな会社へあそびいきたいだけ）
5. 5. リーンスタートアップで新規事業をたちあげるときに発生する よくあるアンチパターン/あるあるについてお話します。 （※場合によってはアンチじゃないケースもあります） あるある～と笑うもよし。 反省するもよし。 図星なのを隠して笑うもよし。 会社のSlackに投げてざわつかせるもよし。 みなさんの事業の不確実性を少しでも減らすことに ご利用していただければ幸いです。
6. 6. みなさん リーンキャンバス 使ってますか！！！？
7. 7. 顧客は誰？課題は何？ 解決策は？ 価値は何？ 圧倒的優位性は何？ コスト構造は？ 売り上げは？ 顧客にリーチするための チャネルは 何を測る？
8. 8. キャンバス依存パターン
9. 9. リーンキャンバスは分かりやすく不確実性の 観点が列挙されている。 しかし、それだけにフォーカスすると事故る。 その事業/チーム/自分/会社の置かれている状 況によって、リーンキャンバスには出てこな い目に見えないリスクが介在していることを どうしても忘れてしまう。
10. 10. ・誰とはじめるか。 ・メンバーの熱量の差異。（チームの持続可能性） ・あなただけでそのドメインでやっていけるのか。 ・そのチームがその課題を解決する必然性はあるか。 ・そのチームにその課題を解決することは出来るのか。 ・誰から出資をうけるか（ステークホルダーを誰にするか） 　社内でやるべきなのか、社外でやるべきなのか ・誰でボトルネックになるのか（決裁マラソン、上長、部下、チーム） ・市場や技術動向の状況と、投入のタイミング 　その領域は、仮説検証を短サイクルでできるか（クラウド等） 　その領域は、低コストでも仮説検証まわせるか（クラウド等） ・法的、規約的、業界の慣例的なルール違反をしていないか などなど リーンキャンバスに出てこないけど あとで問題になるリスク
11. 11. 不確実なことを全て洗い出して、 リスク高い順に検証していく
12. 12. そもそも Founder/Market Fit Founder/Product Fit していないパターン
13. 13. パーソナルコンピューターを作る！ http://i.gzn.jp/img/2014/01/20/steve-jobs-and-wozniak-truth/8203977390_f42ee0b5a1_o.jpg https://www.pakutaso.com/20150911258post-6047.html
14. 14. カレとふたりきりのチャット作る http://i.gzn.jp/img/2014/01/20/steve-jobs-and-wozniak-truth/8203977390_f42ee0b5a1_o.jpg https://www.pakutaso.com/20150911258post-6047.html
15. 15. 参入するドメイン出身で業界事情に明るい 特定領域での専門性を持っている 参入ドメイン内の人脈がある （メンター候補/アーリーアダプター候補） 業界慣例、文化に詳しい等 今後仮説検証を進めていく上で有利 または、そのドメインに対して とても深い不を個人的に抱えていたりする場合 スタート地点、不確実性がより少ないという側面
16. 16. たまたま、そこに課題を発見しちゃったから、はじめたの？ なぜ、それをやっているの？あなたがやる必然性は？ その業界の人と同じ温度感で課題を感じているの？ もしくは、あなたはそれを毎日つかうの？ 熱量があること。新規事業は大抵失敗するから心がおれる。 会社の新規事業組織から成功事例が生まれにくい理由のひとつ はそれ。その部門の人は別にそれに命かけてるわけではないの で、成功するまでやり続ける力が維持しにくい。続かない。 熱量ある人がやるべき。会社の新規事業組織の場合は、そうい う人を常に補充し続ける必要あり。 ファウンダーの持続性という側面
17. 17. 例）会社の新規事業組織 熱量のある人を常に補充し続ける仕組み http://www.slideshare.net/i2key/bp-leanstartup/100
18. 18. MVPでシンプルにやら なきゃだめだよ！だって、 ネットの記事にそうかい てあるしパターン
19. 19. MVPで、シンプルにやらないとダメという風潮。 本やネット上の記事のキラキラした事例に洗脳されている。 最初は、シンプルでよいと思う。 しかし、実際の現場では競合が現れる。 物事を伝えるときはあえて極論をいってシャープにする方法を とられることが多い。現実はそうはいかない。 本に書いてあるような綺麗なMVP参考例の型に当てはめよう として、それを目的化しないこと。 あくまで目的は仮説を検証すること。
20. 20. 充足 不充足 満足 不満足 顧客の満足感 物理的な充足度 魅力品質 本来MVPで検証したいこと 当たり前品質 アーリーアダプターには ここ弱めにするか。とか マネタイズ検証時には 必要だね。とか Minimum Sellable Product 性能品質 魅力品質 性能品質 当たり前品質 不充足でも不満には思わないが、 充足されれば満足 <例> ハイレゾ音源（あれば良いが、なくても 不満ではない）、曲面液晶など 不充足だと不満、充足されると満足 <例> バッテリーの持ち（稼働時間が長ければ 満足、短いと不満）、重量など 不充足だと不満、充足されて当たり前 <例> 通話音声（音が良くて当たり前、聞き 取りづらいと不満） 狩野モデル 10
21. 21. 石橋叩きすぎパターン
22. 22. 小さい仮説検証ばかりで先にすすまない 検証して100%の確証を得るまで動けない。 （サイエンスの度がすぎる。アート20％、サイエンス80%。） 常に顧客を向いてフィードバックをもらい続けていれば、 都度、ゴールに向かって軌道修正すれば良い。 良くある例 インタビューを永遠につづける。 いつまでインタビューすればいいのですか？
23. 23. シングルタスクパターン
24. 24. なぜか一個づつやる。 1つずつ仮説検証しなくてはいけないと刷り込まれている。 幾つかの仮説を同時に走らせておいたほうが、 それがダメだったときに、いっきに巻き戻らなくてすむ。 リスクを最小化するという価値観で考えると 仮説検証失敗による巻き戻りのリスクを最小化する。 それが出来るのがチームの良い所。 ロジック的に依存性がなく 並列化可能なら同時に仮説検証していくことも候補にする。
25. 25. 誰そのペルソナ、本当に いるのパターン
26. 26. ペルソナなんかよりもむしろ課題をもっていて、 解決してあげたいひとの氏名をかくほうが効果的。 最初の誰を救うか。 具体的に氏名まで。 ペルソナは存在するかわからないけど、 氏名ならば1人は存在する。 デモグラでキレるようなセグメントの課題なんて 既に大抵解決されている。
27. 27. その人お金払わないよね パターン
28. 28. カスタマーを誰に置くのか。 誰からお金をもらうのか。 お金をもらう人を軸にしないと。 ボランティアじゃないので。 事業を作っているので。 誰からお金を取るかを考えて始めないと、 最終的にマネタイズが出来なくて終わるパターンになる。 （なった経験がある） 課題を解決するために、 お金を払う人をカスタマーセグメントにまずは書いて考えるべ し。
29. 29. 何か言っているようで 何も言っていないパター ン
30. 30. トートロジー トートロジー（英語：tautology, ギリシャ語： ταυτολογία）とは、ある事柄を述べるのに、同義語ま たは類語または同語を反復させる修辞技法のこと。 同 義語反復、類語反復、同語反復等と訳される。 関連し た概念に冗語があり、しばしば同じ意味で使われるこ ともある。 また、撞着語法はトートロジーの反対の技 法である。
31. 31. http://www.slideshare.net/i2key/bp-leanstartup/61
32. 32. http://www.slideshare.net/i2key/bp-leanstartup/66
33. 33. キャバクラでの我々パターン
34. 34. 潜在ニーズを調査するようなインタビューで こちらは事実だけを吸い上げたいのにも関わらず、 インタビューの仕方をミスって 回答者側が気分を良くして、 自分の（想像による）意見を言い出して 止められない状況。ドヤァ。 あくまで想像による発言なので仮説検証に使いにくい。 なので、どうにかして流れを変えること。 未来の話をききすぎ。過去の話を集約して、それを横断的に分 析して共通項を抜き出すというやりかたにせい。
35. 35. リーンスタートアップ、 僕、好きじゃないので パターン
36. 36. 新しい何かを組織にインストールするのにはつきものですが、 組織でリーンスタートアップなやりかたを初めてやろうとなると、 何と戦ってるのかわからないような人が出てくるケースがたまにある。 個人的には、別にサービスが上手く行けばなんでもいいので、 リーンこだわるひつようないのだけど、 全てのものを別物として認識しているひとたちは危険。本質が見えていない ので。 好きとか、嫌いとかそういう話じゃないと思うけど・・
37. 37. 課題 一つの課題に対して、光の当て方が違うだけ LEANSTARTUP 制約理論 AARRR 狩野モデル Agile 顧客開発モデル Feature Toggle Design Thinking Design Sprint 20
38. 38. Acquisition 獲得 Retention 継続 Churn 解約 Referral 紹介 Activation 活性化 Revenue 収益 ※ChurnはAARRRには 無いけど勝手に付け足しました 大事 AARRRからみたリーンスタートアップ
39. 39. 継続して利用してくれているということは 顧客の課題を解決していること （それが想定していない課題を解決してることもあるけど） ユーザーがプロダクトに 価値を感じている状態 エンゲージしている状態 Problem Solution Fit AARRRからみたリーンスタートアップ
40. 40. 最もスループットの低い部分が、 全体のスループットを決める （鎖の強度は、最も強度の弱い 輪が全体の強度になる） 最もリスクの高い部分から、 検証していく 制約理論からみたリーンスタートアップ
41. 41. 顧客は誰？課題は何？ 解決策は？ 価値は何？ 圧倒的優位性は何？ コスト構造は？ 売り上げは？ 顧客にリーチするための チャネルは 何を測る？ リスク高 リスク中リスク中 リスク中 リスク中 リスク中 リスク中 リスク中 制約理論からみたリーンスタートアップ
42. 42. 制約理論からみたリーンスタートアップ ① ② ② ② ③ ⑩ ⑤ ⑩ ⑫ ② ⑩ ⑩ 鎖の強度が弱い
43. 43. 充足 不充足 満足 不満足 顧客の満足感 物理的な充足度 魅力品質=UVP 当たり前品質 P/S検証時はどう最小化すべきか マネタイズ検証時はどう最大化するか 性能品質 魅力品質 性能品質 当たり前品質 不充足でも不満には思わないが、 充足されれば満足 <例> ハイレゾ音源（あれば良いが、なくても 不満ではない）、曲面液晶など 不充足だと不満、充足されると満足 <例> バッテリーの持ち（稼働時間が長ければ 満足、短いと不満）、重量など 不充足だと不満、充足されて当たり前 <例> 通話音声（音が良くて当たり前、聞き 取りづらいと不満） 狩野モデルからみたリーンスタートアップ
44. 44. Permission : ROLE_ADMINPermission : ROLE_USER Feature Toggleからみたリーンスタートアップ
45. 45. 小さく失敗して効率よく学ぶインフラ 仮説検証のためのMVP（機能）を 例えば、最初は開発チームだけに公開。 次に、全体の5%のユーザだけに公開しテストなどを行う 仮説検証を本番環境でユーザーに対して実施する。 大きくリリースして大きく失敗するリスクを最小化。
46. 46. 自分が欲しいものを作れ ポール・グレアム
47. 47. エンジニアが上手くフィッ トしないパターン
48. 48. 作ることのみにコミットしているエンジニアが この仮説検証のやりかたについてこれないパターン。 はやく検証したいのに、豪華な何か、高品質な何かを創りだしてしまい、 検証が思いの外、回らないケース。 エンジニアには、QCD-ScopeでQ抑えめでD重視と伝えるとか、 エンジニアに刷り込まれている昔ながらの価値観、優先順位を壊すことが 必要。（必要に応じて権力のある人、責任のある人に言ってもらう。） 状況におうじてQCDとスコープの優先順位がかわることを伝える。 その上で、この働きかたについてこれるエンジニアとやる。
49. 49. 対峙しているサービスのフェーズにより、エンジニアに求められるコミットが変 わってくる。アーリーステージであればあるほど、ロールの枠を超えた働き方が求 められる。
50. 50. 検証を設計する （実証条件/実証方法/etc） 効果を計測する KPI（数値目標）を設定する リリースする ユーザがコンバージョンする 仮説をたてる 仕様にする 設計する ユーザーに届く ユーザーが使う ユーザーが気づく KPI（数値目標）達成 指標：ベロシティ/デプロイ回数/性能値/品質/コスト/etc エンジニアのコミットと目標 データから学ぶ （仮説を修正する 　　打ち手を変える） エンジニアが直接結果を コントロール出来る範囲 （コードのみに対峙してる） エンジニアが直接結果を コントロール出来ない範囲 （ユーザーの判断という不確実性が介在） テストする 実装する 指標：MAU/継続率/○○率/売上/etc
51. 51. 検証を設計する （実証条件/実証方法/etc） 効果を計測する KPI（数値目標）を設定する リリースする ユーザがコンバージョンする 仮説をたてる 仕様にする 設計する ユーザーに届く ユーザーが使う ユーザーが気づく KPI（数値目標）達成 指標：ベロシティ/デプロイ回数/性能値/品質/コスト/etc エンジニアのコミットと目標 データから学ぶ （仮説を修正する 　　打ち手を変える） エンジニアが直接結果を コントロール出来る範囲 （コードのみに対峙してる） エンジニアが直接結果を コントロール出来ない範囲 （ユーザーの判断という不確実性が介在） テストする 実装する アーリーステージは 特に視野を広げる 指標：MAU/継続率/○○率/売上/etc
52. 52. http://www.slideshare.net/keisuketsukagoshi/ss-59705472/58 エンジニアもユーザーに会いに行こう
53. 53. https://speakerdeck.com/htomine/qiita-teamfalsekai-fa-wotong-sitejian-tuketekita-incrementsfalsewen-hua-wozuo-rufang-fa エンジニアもデザイナもヒアリングする
54. 54. 割り込みガァーパターン
55. 55. 一概に割り込みがダメというのではなく、今おかれているフェーズおよび、 チームとしての最重要なことは何かを考えてみることが大事。 それは果たして、Buildの高速化のみを考えていないか。 仮説検証サイクルのボトルネックがBuildにあるならそれでよいが、 他にネックがあるなら、Build最適する必要はないのでは。 個別最適？ 全体最適？ 30
56. 56. いくつも打ち合わせガァ パターン
57. 57. 一概に打ち合わせだらけになることが悪いというのではなく、 今おかれているフェーズおよび、チームとしての最重要なことは 何かを考えてみることが大事。 それは果たして、Buildの高速化のみを考えていないか。 仮説検証サイクルのボトルネックがBuildにあるならそれでよいが、 他にネックがあるなら、Build最適する必要はないのでは。 個別最適？ 全体最適？
58. 58. リモートワークガァー パターン
59. 59. リモートワークがダメというのではなく、今おかれているフェーズおよび、 チームとしての最重要なことは何かを考えてみることが大事。 それは果たして、Buildの高速化のみを考えていないか。 仮説検証サイクルのボトルネックがBuildにあるならそれでよいが、 他にネックがあるなら、Build最適する必要はないのでは。 個別最適？ 全体最適？
60. 60. UVPを見つけに行ってる はずなのに、顧客の声を聞 いた挙句、既にある何かに たどり着いちゃった、あー あ・・・パターン
61. 61. ある病気の患者は宣告を受けてから自分の治療法を決めるまで に時間がなく、つてもなく、お金もなく、落ち着いてもいない ので、セカンドオピニオンサービスが必要なはずだ、、 ヒアリングの結果、セカンドオピニオンまでははいらなくて、 「みんなは」同じような境遇の人、同じ病状、同じフェーズの 人が今何をしているか知りたい、繋がりたい、と思っている。 じゃあそういうSNSを作ろう。 →UVPなくなりました以上
62. 62. 性能競争パターン
63. 63. 既存製品で、この機能がない、この性能が悪い、みたいなもの に対して、足りない機能を実装したり、 性能を改善したりするだけのこと その既存製品がそれをやったらどうするの？ フォロワー戦略は参入コスト高すぎる 性能競争で勝つなら、圧倒的な差をつけること。 テクノロジーで100かかってたのが1になるとか。 数万円だったものを無料にするとか。 UVPが存在しないパターン。
64. 64. 解決策アリキーパターン
65. 65. 省略
66. 66. ○○がそれやったらどー んのパターン
67. 67. プラットフォーマーと言われている会社が 同じ領域を、大量の資金でもって上書きしにきたときに どうするのか。これに答えられない。 戦わないですむような戦略 市場の再セグメント化 戦うけど優位な状況で戦う ゲリラ戦 相手が参入出来ないスペースを狙う 法的にグレーなゾーン プラットフォーマーが自己矛盾起こすような戦略 先にユーザを掴んで売る 先行者優位な市場であればユーザ掴んで、 プラットフォーマーに事業を売り抜ける。 ： ：
68. 68. ご静聴ありがとうございました