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
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
tsuyoshi nakamura
March 10, 2018
Business
2.5k
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
スタートアップしてからの失敗の数々
tsuyoshi nakamura
March 10, 2018
More Decks by tsuyoshi nakamura
See All by tsuyoshi nakamura
社内の勉強会で発表した_output_一部抜粋版_.pdf
tsuyoshi
0
500
PHPを少しでも早く_条件はあるよ_.pdf
tsuyoshi
0
87
スタートアップ6年目のレビュー文化.pdf
tsuyoshi
1
2k
PHPを少し深堀るよ.pdf
tsuyoshi
0
400
Reactive_Manifesto.pdf
tsuyoshi
0
90
About_Resilience.pdf
tsuyoshi
1
96
エンジニアの循環ってgood_or_bad_.pdf
tsuyoshi
0
1.3k
スタートアップエンジニアの役割
tsuyoshi
0
550
古株のvalueの出し方
tsuyoshi
0
4.2k
Other Decks in Business
See All in Business
今こそアナログスキルを磨こう
madai0517
0
140
株式会社Domuz会社紹介資料(採用)
kimpachi_d
0
59k
現実は、会話から生まれる。〜 1on1とチームの場を繋ぐ、社会構成主義的実践 〜
emi0726
1
260
株式会社ルクレ新卒向け採用ピッチ
lecre
0
270
【結果報告】Claude×Linearで会社のタスク管理をAIにまかせて1ヶ月。業務効率150%向上したが、AIネイティブカンパニーを目指すならもっと「加速への狂気」が必要
nagatsu
1
500
Decentier_Corporate Deck_2026
decentier
PRO
0
440
روشهای افزایش ممبر ایتا
maronpocar12
1
220
VISASQ: ABOUT DEV TEAM
eikohashiba
6
44k
コーポレートストーリー(新規投資家様向け会社説明資料)
gatechnologies
2
19k
エイターリンク株式会社 会社紹介資料
aeterelink
0
44k
kakaopiccoma_engineer_recruitingguide
kakaojapan
2
190
株式会社ユビレジ_採用ピッチ資料 / Ubiregi_CompanyProfile
ubiregi_saiyo
1
11k
Featured
See All Featured
Thoughts on Productivity
jonyablonski
76
5.2k
Code Reviewing Like a Champion
maltzj
528
40k
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
780
Producing Creativity
orderedlist
PRO
348
40k
Making Projects Easy
brettharned
120
6.7k
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
2.3k
コードの90%をAIが書く世界で何が待っているのか / What awaits us in a world where 90% of the code is written by AI
rkaga
62
44k
The Limits of Empathy - UXLibs8
cassininazir
1
360
Building a Scalable Design System with Sketch
lauravandoore
463
34k
AI Search: Implications for SEO and How to Move Forward - #ShenzhenSEOConference
aleyda
1
1.3k
How STYLIGHT went responsive
nonsquared
100
6.2k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
230
23k
Transcript
スタートアップしてからの失敗の数々 2018.3.10 @phperkaigi2018
- Software Engineer (CyberAgent group) - @nakamura_tsuyo4 - Makuake -
創業エンジニア (from 2013) About me
Makuakeはスタートアップ時のメイン言語として PHPを採用しています。 無い無いづくしのスタートアップですが、過去を振り返りここは妥協 せずにやっておけば良かったなどを紹介します 前段
たくさんあるので早速いきます
1 --- 過度なファイルの存在確認処理 s3に保存している画像のfile_exists(AWS SDK)処理が至る所に存在。 = インターネット経由でAPIをコールしまくってい る。performanceは引きづられる > そもそもファイルの存在確認が必要な場面を
見極める。必要な場合であっても1度file_exits した結果をストレージに置いておくべきだった
2 --- preg_matchの多用 preg_matchじゃなくても良い場面でも preg_matchを使ってた。 > そもそもpreg_matchしなくても良い設計はな いか、多くの場合はstrposで代用できて、とても 高速
3 --- ImageMagic運用 元画像から綺麗にサムネイルを作る要件に対 して自前でImageMagicをインストールしてオン デマンドに活用してた。 > Lambdaで非同期的にサムネイルを作る方法 もあるけど、そもそもサムネイル+CDN配信して くれるsaasを活用した
4 --- AWS SESの上限を使い切ってしまった メールを送信できる上限が決まってます。がそ の閾値を見逃して上限に達してしまい、メール が送れない問題 > すぐに上限緩和依頼。監視の追加
5 --- 不要になったtableがたくさん 過去使ってたけど今は使ってないテーブルが多 数。しかもめっちゃレコード持ってるDBの Aurora移行の時に見積りに影響。 > 不要になれば期限を決めてdrop tableしま しょう。とりあえずとっておくではなくて、N日まで
に使わなかったら消すとかbackupして消すが 必要
6 --- Unuse method classたくさん問題 利用されていないコードが沢山散らばっていて 可読性が悪く開発効率がみるみる落ちる > IDEなどから不要なものは念のためgrepして 消すリリースを繰り返した。total:300PR’s。
Phanも活用
7 --- Blogシステムを自前で運用 SEOに効果あるっぽいから同じサービスの domain内でblog記事を運用したい...が、効果 が未知数なものを運用していくツラさ > SEOは無視できないけど自分たちの本業の サービス開発に集中すべし。クオリティーの高 いサービスを提供することが一番のSEO対策!!
結局外部blogサービスへ引越した
8 --- ハウスキーピング意識の欠如 とりあえずログを取っておくで放置されるパター ンが後々、ログが肥大化してdiskを食いつぶし たり問題が表面化 > 無駄にログを溜め込まない。N日経って不要 となるものは積極的にpurge処理を追加
9 --- 外部API 変更を見逃しての障害 通知はだいたいメールのみ。それを忘れさら れ、或る日突然エラー > メールだけでは気づかないのでslackへの通 知や通知をメールをメーリス化で
10 --- mysqlのレコードに0とnullが同居問題 プログラムの作り上、ケアすべきことが増え、冗 長になっている > プログラムを修正して蓋をする 過去のデータを洗い替えするバッチで一気に修 正 今後はdev環境にSQLモード設定を検討
ここまでは技術的な話
組織的な話を少々
11 --- コードを書く以外の役割 少しTeamが大きくなると必然と古株にマネージ メント的要件や社内情シスのような役割を求め られるようになる。 思考と合えば良いが、今後もバリバリコードを 書いてプロダクト開発したいと思考しているとツ ライ >
PM的な役割の人を早めに採用すべし
色々と話してきましたが、何は妥協すべき でなかったのか?
❏ もっと必要最低限の機能に絞れば... (MVP) ❏ 後発サービスとしては難しい面もあるけど... ❏ 本来集中すべきコア機能などに集中 ❏ 提供するものを小さくすることで運用コストを下げる ❏
役割が変わったなと感じ、不満に思えば早めに 1 on 1 ❏ 流れに任せてなんとなくその役割を担うのはリスク
おまけ(実は)
スタートアップのエンジニアになることはそれなりの苦 労があります 遊んでいる暇などなく、ひたすら仕事します。 システム・組織のトラブルなど日常になります。 この状況を下支えするモチベーションが必要
▸ ゼロから事業を立ち上げをし たいと強く思っていた In My Case 人によるけど - CEOの思いに強く共感したとか -
Stock Optionをもらったとか 多くの困難に立ち向かう為の信念が大事!
ご静聴ありがとう ございました