Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

こんにちわ！ 2 / 48

Slide 3

Slide 3 text

whoami ⾼専卒 NTT 系SIer (SE -> sales) ⾳楽系スタートアップ CTO メディア系スタートアップ ⽴上げ 国内EC ⽴ち上げ 越境系発送代⾏サービス 1 号エン ジニア Repro 創業 (CTO -> VPoE) Akira Miki @threetreeslight shinjuku.rb Organizer 3 / 48

Slide 4

Slide 4 text

よく失敗してきたスタートアップおじさん 最近は社内で⼈事部⻑やイベントオーガナイザー おじさんと揶揄されます 4 / 48

Slide 5

Slide 5 text

話すこと・話さないこと 話すこと 失敗談 : こうしておけばよかったなー 話さないこと 成功談 : こうしたらうまくいったよ 5 / 48

Slide 6

Slide 6 text

なぜ？ 成功はアート、失敗はサイエンス by 起業のサイエンス ⽥所雅之 6 / 48

Slide 7

Slide 7 text

前提となる Repro とは？ 7 / 48

Slide 8

Slide 8 text

Web/App MA tool 8 / 48

Slide 9

Slide 9 text

サービスの成⻑を⽀援 ⽉間数千億イベントのデータを処理・分析 AI でユーザーを⾃動セグメント 毎⽇数億プッシュ配信などの施策実施 9 / 48

Slide 10

Slide 10 text

⼤分伸びてきた サービスのトラフィックもだいぶあるし、売上も ⼤分あがって成⻑してきた 会社の規模も従業員数でいうと150 名ぐらいになっ てきた ( その過程でもちろんjoker さんにもいろいろ育てて もらいましたｗ) 10 / 48

Slide 11

Slide 11 text

ちなみに... 11 / 48

Slide 12

Slide 12 text

これやらかしたの昔の私です 俺が悪かった。素直に間違いを認めるから、もう サービスクラスとか作るのは⽌めてくれ 似⾮サービスクラスの殺し⽅ / #ginzarb 12 / 48

Slide 13

Slide 13 text

失敗をどう分類して伝えるか？ 会社の規模・フェーズ 失敗軸 13 / 48

Slide 14

Slide 14 text

会社の規模 ( 本来の使い⽅とちょっと違います) 0->1 1->10 : ここら2 回ぐらいstartup 死んだ 10->30 30->50 50->100 100->300 <-Repro はイマココ 300~ <- 全くワカラン 14 / 48

Slide 15

Slide 15 text

失敗軸 話したい技術ネタいっぱいあるけど、以下を軸に致 死性の失敗にフォーカス プロダクト 組織 採⽤ 技術 15 / 48

Slide 16

Slide 16 text

いきます 16 / 48

Slide 17

Slide 17 text

0->1 猫もびっくりなぐらいまっしぐら 17 / 48

Slide 18

Slide 18 text

失敗 作れなかったら終わり プログラミングはほぼ独学でやっていきていたの で プロダクト作りの作法を本とweb でしか知らな い スケーラブルでロバストなサービスの開発や⼤ 規模開発に触れたことがない アーキテクチャは本とweb でしか知らない そして相談先がない 18 / 48

Slide 19

Slide 19 text

学び なければ学んだほうが良いので、ほんと⼤⼿テッ ク系企業に所属ないしフリーランスでお⼿伝いし てたらよかったかも To-Be( あるべき像) 、ぶつかる課題、組織で⾏わ れていることを事前に少しでも知っておくこと は価値にある ちょっと強くて強くてニューゲーム 19 / 48

Slide 20

Slide 20 text

1->10 起業してる感半端ない 20 / 48

Slide 21

Slide 21 text

失敗 友達が⼿伝ってくれてワイワイ楽しい でもお⾦ないのでドメインのリセラーとか、サー バーとか変なふうにケチる 無いお⾦はプロダクトを作るエンジニアに投資さ れるので、なんかエンジニア偉い感出る 21 / 48

Slide 22

Slide 22 text

学び やっていることはビジネスである 友達は⼊ったら友達ではない。特にCTO はマネー ジャーとしてしっかり振る舞う。 エンジニアは常にビジネスサイドに⼤して謙虚で なくてはいけない 変なところでケチると後でしっぺ返しが来るの で、システム・ツール投資はケチらず保守性を意 識 22 / 48

Slide 23

Slide 23 text

10->30 売れなくて死ぬほど不安 23 / 48

Slide 24

Slide 24 text

失敗 地獄のPMF 。有料顧客が欲しがるものやいいと思 うことをとにかく実装 テクニカルサポートをみんなでやる 採⽤に理想を追い求めてバンバン落とす 採⽤は⽚⼿間でやる 24 / 48

Slide 25

Slide 25 text

学び: プロダクト 顧客の声だけではなく、市場の声( 予算) があるとこ ろから取る ⾃分たちが⽣きていけるだけのお⾦払って使い たいと思われないものはクソ みんなでやっているテクニカルサポートなどさっ さと専任化する 属⼈化して熟練させた上での最適化でないと、 誤った最適化になる 25 / 48

Slide 26

Slide 26 text

学び: 採⽤ 初期CTO かいずれかのエンジニアはエンジニア採 ⽤に専任する ⾃分よりできる⼈をCTO として雇⽤するぐらい の勢いが必要 採⽤はみんなの平均以上であれば基本採⽤した⽅ が良い エンジニアが⽣きるポジションはプロダクト開 発だけではない 26 / 48

Slide 27

Slide 27 text

30->50 あっ死の⾕こちらですか？ 27 / 48

Slide 28

Slide 28 text

失敗 顧客いっぱい要望いっぱい、からの⽅向性のブ レ。ロードマップとは？ PMF するためにやった雑な設計・実装が元凶でス ケール限界やコストと戦うことに すると開発者みんなも不安になってくる なんとかするために採⽤ストップして全⼒投⼊ 28 / 48

Slide 29

Slide 29 text

学び: プロダクト みんな必死で眼の前のことしか⾒えなくなりがち なので、俯瞰して交通整理(PM) する⼈をエンジニ アから早めに⽴てる PM とサポートに移ったエンジニアを含め、会社 全体で顧客の信頼をつなぎとめる事ができる 29 / 48

Slide 30

Slide 30 text

学び: 技術 PMF のとにかく機能開発フェーズにおいて、DB だ けでもいいのでクソ設計する前に技術顧問や副業 の優秀な⼈に設計レビューを依頼する ただし、スタートアップへの理解( 開発の速度感 を維持できる設計度合い) した⾊気の出しすぎな い堅牢で柔軟な素直な設計ができる⼈ まじjoker さんには感謝しかない 30 / 48

Slide 31

Slide 31 text

学び: 技術 コスト考えたら広⼤な⼟地を持つリージョン(AWS, GCP ならN. Virginia, Oregon) を利⽤するべき 電⼒が安くなる余地があればサーバー代が安く なる 通信レイテンシーはlast one mile がほとんど。 プロキシーパターンを使えばだいたい⼤丈夫 新しいManaged service が使える 31 / 48

Slide 32

Slide 32 text

学び: 組織・採⽤ ガンガン開発している前のフェーズで1on1 などの ⾵⼟を作っておくと、不安に効く お互いに余裕ないときに始めても、なんで？っ てなる メンバーが⾃分たちの会社に⼤して不安を覚える 最⼤の要素は、⻑期に渡って⼈が⼊らないこと 採⽤は絶対⽌めてはならない 32 / 48

Slide 33

Slide 33 text

50->100 とにかく売れる 33 / 48

Slide 34

Slide 34 text

失敗 リリースすると軽微なバグあったりする 創業メンバとして開発という業務に携わっていた いと思うエゴ そしてマネジメント限界きて仕事中に涙出てた 34 / 48

Slide 35

Slide 35 text

学び: 組織 35 / 48

Slide 36

Slide 36 text

100->300 めちゃ売れるのだけど？ 36 / 48

Slide 37

Slide 37 text

失敗 プライバシー保護やISMS がなくて売り難い 他組織(Sales Marketing Corporate HR) の作業が労 働集約的になる 37 / 48

Slide 38

Slide 38 text

学び Corporate Operation Engineer( 社内SE) を専任化す る エンジニア組織が開発で逼迫し続けていると、 他組織の⽣産性向上の⽀援やバックオフィスの 最適化が疎かになる それを責務とするチームがなければいけない 38 / 48

Slide 39

Slide 39 text

まとめ 39 / 48

Slide 40

Slide 40 text

会社っぽく、組織っぽくする 属⼈化してナレッジをため、最適化して再分散す る それをお願いできる仲間と信頼関係を作る 40 / 48

Slide 41

Slide 41 text

何よりも「できること」に逃げな い。「やるべきこと」に向かう 41 / 48

Slide 42

Slide 42 text

そんなRepro がサバイブ出来たの は 背中を任せられるチームメンバーに助けられ続けた から 42 / 48

Slide 43

Slide 43 text

グローバルで とりあえずRepro いれとこ を⼀緒に⽬指せる仲間 43 / 48

Slide 44

Slide 44 text

We Are Hiring etc... 44 / 48

Slide 45

Slide 45 text

Thanks 45 / 48

Slide 46

Slide 46 text

Appendix 46 / 48

Slide 47

Slide 47 text

reference のチームビルディ ング項 LEAN STARTUP HARD THINGS 起業のサイエンス キャズム 実践カスタマーサクセスブログ 47 / 48

Slide 48

Slide 48 text

オーガナイザーおじさんの所以 organize event Shinjuku.rb Shinjuku MokuMoku Programming Repro Tech Meetup Hacking HR! hosting event OpenQL ときどき Shibuya.rb wejs 48 / 48