Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
複数のスタートアップを 通して得た失敗と学び
Search
threetreeslight
December 08, 2018
Technology
0
58
複数のスタートアップを 通して得た失敗と学び
2018-12-08-複数のスタートアップを 通して得た失敗と学び @threetreeslight on railsdm 2018 Day 4
threetreeslight
December 08, 2018
Tweet
Share
More Decks by threetreeslight
See All by threetreeslight
Bottleneck is You
threetreeslight
0
77
Japan Office Society オフィスはスタートアップの成長を助長するのか?阻害するのか?
threetreeslight
0
91
スタートアップは見極められたくない
threetreeslight
0
27
VPoEの責務とは
threetreeslight
0
53
CiecleCIでもくもく会を支える技術
threetreeslight
0
41
Ego vs higher self
threetreeslight
0
33
Performance Hack 101
threetreeslight
0
72
How to probe prometheus & grafana. What is helm
threetreeslight
0
26
Istio Traffic Management
threetreeslight
0
28
Other Decks in Technology
See All in Technology
OSTという文化を組織に根付かせてみた
sansantech
PRO
2
390
自作Cコンパイラ 8時間の奮闘
soukouki
0
850
プロダクトエンジニアを支えるための開発生産性向上施策
tsukakei
0
140
エンジニア視点で見る、 組織で運用されるデザインシステムにするには
shunya078
1
310
AIを活用した柔軟かつ効率的な社内リソース検索への取り組み
cygames
0
180
ロリポップ! for Gamersを支えるインフラ/lolipop for gamers infrastructure
takumakume
0
130
不動産 x AIことはじめ~データの真価を拓くために
estie
0
110
Mocking in Rust Applications
taiki45
2
410
PDF Viewer作成の今までとこれから
hunachi
0
470
Cloud Run と GitHub Template Repository による軽量なアプリケーションプラットフォーム/ #nikkei_tech_talk
nikkei_engineer_recruiting
0
110
Oracle Autonomous Database:サービス概要のご紹介
oracle4engineer
PRO
1
7.1k
サプライチェーン攻撃に備える
ryunen344
0
290
Featured
See All Featured
Java REST API Framework Comparison - PWX 2021
mraible
PRO
27
7.4k
A Philosophy of Restraint
colly
202
16k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
29
2.6k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
502
140k
Building Applications with DynamoDB
mza
90
6k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
45
4.8k
Unsuck your backbone
ammeep
667
57k
How GitHub (no longer) Works
holman
310
140k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
Design by the Numbers
sachag
277
19k
Building a Scalable Design System with Sketch
lauravandoore
459
32k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
246
1.3M
Transcript
複数のスタートアップを 通して得た失敗と学び @threetreeslight on railsdm 2018 Day 4 1 /
48
こんにちわ! 2 / 48
whoami ⾼専卒 NTT 系SIer (SE -> sales) ⾳楽系スタートアップ CTO メディア系スタートアップ
⽴上げ 国内EC ⽴ち上げ 越境系発送代⾏サービス 1 号エン ジニア Repro 創業 (CTO -> VPoE) Akira Miki @threetreeslight shinjuku.rb Organizer 3 / 48
よく失敗してきたスタートアップおじさん 最近は社内で⼈事部⻑やイベントオーガナイザー おじさんと揶揄されます 4 / 48
話すこと・話さないこと 話すこと 失敗談 : こうしておけばよかったなー 話さないこと 成功談 : こうしたらうまくいったよ 5
/ 48
なぜ? 成功はアート、失敗はサイエンス by 起業のサイエンス ⽥所雅之 6 / 48
前提となる Repro とは? 7 / 48
Web/App MA tool 8 / 48
サービスの成⻑を⽀援 ⽉間数千億イベントのデータを処理・分析 AI でユーザーを⾃動セグメント 毎⽇数億プッシュ配信などの施策実施 9 / 48
⼤分伸びてきた サービスのトラフィックもだいぶあるし、売上も ⼤分あがって成⻑してきた 会社の規模も従業員数でいうと150 名ぐらいになっ てきた ( その過程でもちろんjoker さんにもいろいろ育てて もらいましたw)
10 / 48
ちなみに... 11 / 48
これやらかしたの昔の私です 俺が悪かった。素直に間違いを認めるから、もう サービスクラスとか作るのは⽌めてくれ 似⾮サービスクラスの殺し⽅ / #ginzarb 12 / 48
失敗をどう分類して伝えるか? 会社の規模・フェーズ 失敗軸 13 / 48
会社の規模 ( 本来の使い⽅とちょっと違います) 0->1 1->10 : ここら2 回ぐらいstartup 死んだ 10->30
30->50 50->100 100->300 <-Repro はイマココ 300~ <- 全くワカラン 14 / 48
失敗軸 話したい技術ネタいっぱいあるけど、以下を軸に致 死性の失敗にフォーカス プロダクト 組織 採⽤ 技術 15 / 48
いきます 16 / 48
0->1 猫もびっくりなぐらいまっしぐら 17 / 48
失敗 作れなかったら終わり プログラミングはほぼ独学でやっていきていたの で プロダクト作りの作法を本とweb でしか知らな い スケーラブルでロバストなサービスの開発や⼤ 規模開発に触れたことがない アーキテクチャは本とweb
でしか知らない そして相談先がない 18 / 48
学び なければ学んだほうが良いので、ほんと⼤⼿テッ ク系企業に所属ないしフリーランスでお⼿伝いし てたらよかったかも To-Be( あるべき像) 、ぶつかる課題、組織で⾏わ れていることを事前に少しでも知っておくこと は価値にある ちょっと強くて強くてニューゲーム
19 / 48
1->10 起業してる感半端ない 20 / 48
失敗 友達が⼿伝ってくれてワイワイ楽しい でもお⾦ないのでドメインのリセラーとか、サー バーとか変なふうにケチる 無いお⾦はプロダクトを作るエンジニアに投資さ れるので、なんかエンジニア偉い感出る 21 / 48
学び やっていることはビジネスである 友達は⼊ったら友達ではない。特にCTO はマネー ジャーとしてしっかり振る舞う。 エンジニアは常にビジネスサイドに⼤して謙虚で なくてはいけない 変なところでケチると後でしっぺ返しが来るの で、システム・ツール投資はケチらず保守性を意 識
22 / 48
10->30 売れなくて死ぬほど不安 23 / 48
失敗 地獄のPMF 。有料顧客が欲しがるものやいいと思 うことをとにかく実装 テクニカルサポートをみんなでやる 採⽤に理想を追い求めてバンバン落とす 採⽤は⽚⼿間でやる 24 / 48
学び: プロダクト 顧客の声だけではなく、市場の声( 予算) があるとこ ろから取る ⾃分たちが⽣きていけるだけのお⾦払って使い たいと思われないものはクソ みんなでやっているテクニカルサポートなどさっ さと専任化する
属⼈化して熟練させた上での最適化でないと、 誤った最適化になる 25 / 48
学び: 採⽤ 初期CTO かいずれかのエンジニアはエンジニア採 ⽤に専任する ⾃分よりできる⼈をCTO として雇⽤するぐらい の勢いが必要 採⽤はみんなの平均以上であれば基本採⽤した⽅ が良い
エンジニアが⽣きるポジションはプロダクト開 発だけではない 26 / 48
30->50 あっ死の⾕こちらですか? 27 / 48
失敗 顧客いっぱい要望いっぱい、からの⽅向性のブ レ。ロードマップとは? PMF するためにやった雑な設計・実装が元凶でス ケール限界やコストと戦うことに すると開発者みんなも不安になってくる なんとかするために採⽤ストップして全⼒投⼊ 28 /
48
学び: プロダクト みんな必死で眼の前のことしか⾒えなくなりがち なので、俯瞰して交通整理(PM) する⼈をエンジニ アから早めに⽴てる PM とサポートに移ったエンジニアを含め、会社 全体で顧客の信頼をつなぎとめる事ができる 29
/ 48
学び: 技術 PMF のとにかく機能開発フェーズにおいて、DB だ けでもいいのでクソ設計する前に技術顧問や副業 の優秀な⼈に設計レビューを依頼する ただし、スタートアップへの理解( 開発の速度感 を維持できる設計度合い)
した⾊気の出しすぎな い堅牢で柔軟な素直な設計ができる⼈ まじjoker さんには感謝しかない 30 / 48
学び: 技術 コスト考えたら広⼤な⼟地を持つリージョン(AWS, GCP ならN. Virginia, Oregon) を利⽤するべき 電⼒が安くなる余地があればサーバー代が安く なる
通信レイテンシーはlast one mile がほとんど。 プロキシーパターンを使えばだいたい⼤丈夫 新しいManaged service が使える 31 / 48
学び: 組織・採⽤ ガンガン開発している前のフェーズで1on1 などの ⾵⼟を作っておくと、不安に効く お互いに余裕ないときに始めても、なんで?っ てなる メンバーが⾃分たちの会社に⼤して不安を覚える 最⼤の要素は、⻑期に渡って⼈が⼊らないこと 採⽤は絶対⽌めてはならない
32 / 48
50->100 とにかく売れる 33 / 48
失敗 リリースすると軽微なバグあったりする 創業メンバとして開発という業務に携わっていた いと思うエゴ そしてマネジメント限界きて仕事中に涙出てた 34 / 48
学び: 組織 35 / 48
100->300 めちゃ売れるのだけど? 36 / 48
失敗 プライバシー保護やISMS がなくて売り難い 他組織(Sales Marketing Corporate HR) の作業が労 働集約的になる 37
/ 48
学び Corporate Operation Engineer( 社内SE) を専任化す る エンジニア組織が開発で逼迫し続けていると、 他組織の⽣産性向上の⽀援やバックオフィスの 最適化が疎かになる
それを責務とするチームがなければいけない 38 / 48
まとめ 39 / 48
会社っぽく、組織っぽくする 属⼈化してナレッジをため、最適化して再分散す る それをお願いできる仲間と信頼関係を作る 40 / 48
何よりも「できること」に逃げな い。「やるべきこと」に向かう 41 / 48
そんなRepro がサバイブ出来たの は 背中を任せられるチームメンバーに助けられ続けた から 42 / 48
グローバルで とりあえずRepro いれとこ を⼀緒に⽬指せる仲間 43 / 48
We Are Hiring etc... 44 / 48
Thanks 45 / 48
Appendix 46 / 48
reference のチームビルディ ング項 LEAN STARTUP HARD THINGS 起業のサイエンス キャズム 実践カスタマーサクセスブログ
47 / 48
オーガナイザーおじさんの所以 organize event Shinjuku.rb Shinjuku MokuMoku Programming Repro Tech Meetup
Hacking HR! hosting event OpenQL ときどき Shibuya.rb wejs 48 / 48