$30 off During Our Annual Pro Sale. View Details »

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

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

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

threetreeslight

December 08, 2018
Tweet

More Decks by threetreeslight

Other Decks in Technology

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 さんにもいろいろ育てて もらいましたw)

    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