複数のスタートアップを 通して得た失敗と学び

2018-12-08-複数のスタートアップを 通して得た失敗と学び @threetreeslight on railsdm 2018 Day 4

Transcript

1. 複数のスタートアップを 通して得た失敗と学び @threetreeslight on railsdm 2018 Day 4 1 / 48
2. こんにちわ！ 2 / 48
3. whoami ⾼専卒 NTT 系SIer (SE -> sales) ⾳楽系スタートアップ CTO メディア系スタートアップ ⽴上げ 国内EC ⽴ち上げ 越境系発送代⾏サービス 1 号エン ジニア Repro 創業 (CTO -> VPoE) Akira Miki @threetreeslight shinjuku.rb Organizer 3 / 48
4. よく失敗してきたスタートアップおじさん 最近は社内で⼈事部⻑やイベントオーガナイザー おじさんと揶揄されます 4 / 48
5. 話すこと・話さないこと 話すこと 失敗談 : こうしておけばよかったなー 話さないこと 成功談 : こうしたらうまくいったよ 5 / 48
6. なぜ？ 成功はアート、失敗はサイエンス by 起業のサイエンス ⽥所雅之 6 / 48
7. 前提となる Repro とは？ 7 / 48
8. Web/App MA tool 8 / 48
9. サービスの成⻑を⽀援 ⽉間数千億イベントのデータを処理・分析 AI でユーザーを⾃動セグメント 毎⽇数億プッシュ配信などの施策実施 9 / 48
10. ⼤分伸びてきた サービスのトラフィックもだいぶあるし、売上も ⼤分あがって成⻑してきた 会社の規模も従業員数でいうと150 名ぐらいになっ てきた ( その過程でもちろんjoker さんにもいろいろ育てて もらいましたｗ) 10 / 48
11. ちなみに... 11 / 48
12. これやらかしたの昔の私です 俺が悪かった。素直に間違いを認めるから、もう サービスクラスとか作るのは⽌めてくれ 似⾮サービスクラスの殺し⽅ / #ginzarb 12 / 48
13. 失敗をどう分類して伝えるか？ 会社の規模・フェーズ 失敗軸 13 / 48
14. 会社の規模 ( 本来の使い⽅とちょっと違います) 0->1 1->10 : ここら2 回ぐらいstartup 死んだ 10->30 30->50 50->100 100->300 <-Repro はイマココ 300~ <- 全くワカラン 14 / 48
15. 失敗軸 話したい技術ネタいっぱいあるけど、以下を軸に致 死性の失敗にフォーカス プロダクト 組織 採⽤ 技術 15 / 48
16. いきます 16 / 48
17. 0->1 猫もびっくりなぐらいまっしぐら 17 / 48
18. 失敗 作れなかったら終わり プログラミングはほぼ独学でやっていきていたの で プロダクト作りの作法を本とweb でしか知らな い スケーラブルでロバストなサービスの開発や⼤ 規模開発に触れたことがない アーキテクチャは本とweb でしか知らない そして相談先がない 18 / 48
19. 学び なければ学んだほうが良いので、ほんと⼤⼿テッ ク系企業に所属ないしフリーランスでお⼿伝いし てたらよかったかも To-Be( あるべき像) 、ぶつかる課題、組織で⾏わ れていることを事前に少しでも知っておくこと は価値にある ちょっと強くて強くてニューゲーム 19 / 48
20. 1->10 起業してる感半端ない 20 / 48
21. 失敗 友達が⼿伝ってくれてワイワイ楽しい でもお⾦ないのでドメインのリセラーとか、サー バーとか変なふうにケチる 無いお⾦はプロダクトを作るエンジニアに投資さ れるので、なんかエンジニア偉い感出る 21 / 48
22. 学び やっていることはビジネスである 友達は⼊ったら友達ではない。特にCTO はマネー ジャーとしてしっかり振る舞う。 エンジニアは常にビジネスサイドに⼤して謙虚で なくてはいけない 変なところでケチると後でしっぺ返しが来るの で、システム・ツール投資はケチらず保守性を意 識 22 / 48
23. 10->30 売れなくて死ぬほど不安 23 / 48
24. 失敗 地獄のPMF 。有料顧客が欲しがるものやいいと思 うことをとにかく実装 テクニカルサポートをみんなでやる 採⽤に理想を追い求めてバンバン落とす 採⽤は⽚⼿間でやる 24 / 48
25. 学び: プロダクト 顧客の声だけではなく、市場の声( 予算) があるとこ ろから取る ⾃分たちが⽣きていけるだけのお⾦払って使い たいと思われないものはクソ みんなでやっているテクニカルサポートなどさっ さと専任化する 属⼈化して熟練させた上での最適化でないと、 誤った最適化になる 25 / 48
26. 学び: 採⽤ 初期CTO かいずれかのエンジニアはエンジニア採 ⽤に専任する ⾃分よりできる⼈をCTO として雇⽤するぐらい の勢いが必要 採⽤はみんなの平均以上であれば基本採⽤した⽅ が良い エンジニアが⽣きるポジションはプロダクト開 発だけではない 26 / 48
27. 30->50 あっ死の⾕こちらですか？ 27 / 48
28. 失敗 顧客いっぱい要望いっぱい、からの⽅向性のブ レ。ロードマップとは？ PMF するためにやった雑な設計・実装が元凶でス ケール限界やコストと戦うことに すると開発者みんなも不安になってくる なんとかするために採⽤ストップして全⼒投⼊ 28 / 48
29. 学び: プロダクト みんな必死で眼の前のことしか⾒えなくなりがち なので、俯瞰して交通整理(PM) する⼈をエンジニ アから早めに⽴てる PM とサポートに移ったエンジニアを含め、会社 全体で顧客の信頼をつなぎとめる事ができる 29 / 48
30. 学び: 技術 PMF のとにかく機能開発フェーズにおいて、DB だ けでもいいのでクソ設計する前に技術顧問や副業 の優秀な⼈に設計レビューを依頼する ただし、スタートアップへの理解( 開発の速度感 を維持できる設計度合い) した⾊気の出しすぎな い堅牢で柔軟な素直な設計ができる⼈ まじjoker さんには感謝しかない 30 / 48
31. 学び: 技術 コスト考えたら広⼤な⼟地を持つリージョン(AWS, GCP ならN. Virginia, Oregon) を利⽤するべき 電⼒が安くなる余地があればサーバー代が安く なる 通信レイテンシーはlast one mile がほとんど。 プロキシーパターンを使えばだいたい⼤丈夫 新しいManaged service が使える 31 / 48
32. 学び: 組織・採⽤ ガンガン開発している前のフェーズで1on1 などの ⾵⼟を作っておくと、不安に効く お互いに余裕ないときに始めても、なんで？っ てなる メンバーが⾃分たちの会社に⼤して不安を覚える 最⼤の要素は、⻑期に渡って⼈が⼊らないこと 採⽤は絶対⽌めてはならない 32 / 48
33. 50->100 とにかく売れる 33 / 48
34. 失敗 リリースすると軽微なバグあったりする 創業メンバとして開発という業務に携わっていた いと思うエゴ そしてマネジメント限界きて仕事中に涙出てた 34 / 48
35. 学び: 組織 35 / 48
36. 100->300 めちゃ売れるのだけど？ 36 / 48
37. 失敗 プライバシー保護やISMS がなくて売り難い 他組織(Sales Marketing Corporate HR) の作業が労 働集約的になる 37 / 48
38. 学び Corporate Operation Engineer( 社内SE) を専任化す る エンジニア組織が開発で逼迫し続けていると、 他組織の⽣産性向上の⽀援やバックオフィスの 最適化が疎かになる それを責務とするチームがなければいけない 38 / 48
39. まとめ 39 / 48
40. 会社っぽく、組織っぽくする 属⼈化してナレッジをため、最適化して再分散す る それをお願いできる仲間と信頼関係を作る 40 / 48
41. 何よりも「できること」に逃げな い。「やるべきこと」に向かう 41 / 48
42. そんなRepro がサバイブ出来たの は 背中を任せられるチームメンバーに助けられ続けた から 42 / 48
43. グローバルで とりあえずRepro いれとこ を⼀緒に⽬指せる仲間 43 / 48
44. We Are Hiring etc... 44 / 48
45. Thanks 45 / 48
46. Appendix 46 / 48
47. reference のチームビルディ ング項 LEAN STARTUP HARD THINGS 起業のサイエンス キャズム 実践カスタマーサクセスブログ 47 / 48
48. オーガナイザーおじさんの所以 organize event Shinjuku.rb Shinjuku MokuMoku Programming Repro Tech Meetup Hacking HR! hosting event OpenQL ときどき Shibuya.rb wejs 48 / 48