2018-12-08-複数のスタートアップを 通して得た失敗と学び @threetreeslight on railsdm 2018 Day 4
複数のスタートアップを通して得た失敗と学び@threetreeslighton railsdm 2018 Day 41 / 48
View Slide
こんにちわ!2 / 48
whoami⾼専卒NTT系SIer (SE -> sales)⾳楽系スタートアップ CTOメディア系スタートアップ ⽴上げ国内EC⽴ち上げ越境系発送代⾏サービス 1号エンジニアRepro創業 (CTO -> VPoE)Akira Miki@threetreeslightshinjuku.rb Organizer3 / 48
よく失敗してきたスタートアップおじさん最近は社内で⼈事部⻑やイベントオーガナイザーおじさんと揶揄されます4 / 48
話すこと・話さないこと話すこと失敗談 :こうしておけばよかったなー話さないこと成功談 :こうしたらうまくいったよ5 / 48
なぜ?成功はアート、失敗はサイエンスby起業のサイエンス ⽥所雅之6 / 48
前提となるReproとは?7 / 48
Web/App MA tool8 / 48
サービスの成⻑を⽀援⽉間数千億イベントのデータを処理・分析AIでユーザーを⾃動セグメント毎⽇数億プッシュ配信などの施策実施9 / 48
⼤分伸びてきたサービスのトラフィックもだいぶあるし、売上も⼤分あがって成⻑してきた会社の規模も従業員数でいうと150名ぐらいになってきた(その過程でもちろんjokerさんにもいろいろ育ててもらいましたw)10 / 48
ちなみに...11 / 48
これやらかしたの昔の私です俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは⽌めてくれ似⾮サービスクラスの殺し⽅ / #ginzarb12 / 48
失敗をどう分類して伝えるか?会社の規模・フェーズ失敗軸13 / 48
会社の規模(本来の使い⽅とちょっと違います)0->11->10 :ここら2回ぐらいstartup死んだ10->3030->5050->100100->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 Hiringetc...44 / 48
Thanks45 / 48
Appendix46 / 48
referenceのチームビルディング項LEAN STARTUPHARD THINGS起業のサイエンスキャズム実践カスタマーサクセスブログ47 / 48
オーガナイザーおじさんの所以organize eventShinjuku.rbShinjuku MokuMoku ProgrammingRepro Tech MeetupHacking HR!hosting eventOpenQLときどきShibuya.rbwejs48 / 48