$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

    View Slide

  2. こんにちわ!
    2 / 48

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  7. 前提となる
    Repro
    とは?
    7 / 48

    View Slide

  8. Web/App MA tool
    8 / 48

    View Slide

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

    View Slide

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

    View Slide

  11. ちなみに...
    11 / 48

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  16. いきます
    16 / 48

    View Slide

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

    View Slide

  18. 失敗
    作れなかったら終わり
    プログラミングはほぼ独学でやっていきていたの

    プロダクト作りの作法を本とweb
    でしか知らな

    スケーラブルでロバストなサービスの開発や⼤
    規模開発に触れたことがない
    アーキテクチャは本とweb
    でしか知らない
    そして相談先がない
    18 / 48

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    22 / 48

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  30. 学び:
    技術
    PMF
    のとにかく機能開発フェーズにおいて、DB

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  35. 学び:
    組織
    35 / 48

    View Slide

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

    View Slide

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

    View Slide

  38. 学び
    Corporate Operation Engineer(
    社内SE)
    を専任化す

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

    View Slide

  39. まとめ
    39 / 48

    View Slide

  40. 会社っぽく、組織っぽくする
    属⼈化してナレッジをため、最適化して再分散す

    それをお願いできる仲間と信頼関係を作る
    40 / 48

    View Slide

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

    View Slide

  42. そんなRepro
    がサバイブ出来たの

    背中を任せられるチームメンバーに助けられ続けた
    から
    42 / 48

    View Slide

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

    View Slide

  44. We Are Hiring
    etc...
    44 / 48

    View Slide

  45. Thanks
    45 / 48

    View Slide

  46. Appendix
    46 / 48

    View Slide

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

    View Slide

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

    View Slide