Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
スタートアップしてからの失敗の数々
tsuyoshi nakamura
March 10, 2018
Business
0
1.9k
スタートアップしてからの失敗の数々
tsuyoshi nakamura
March 10, 2018
Tweet
Share
More Decks by tsuyoshi nakamura
See All by tsuyoshi nakamura
社内の勉強会で発表した_output_一部抜粋版_.pdf
tsuyoshi
0
270
PHPを少しでも早く_条件はあるよ_.pdf
tsuyoshi
0
34
スタートアップ6年目のレビュー文化.pdf
tsuyoshi
1
1.4k
PHPを少し深堀るよ.pdf
tsuyoshi
0
230
Reactive_Manifesto.pdf
tsuyoshi
0
28
About_Resilience.pdf
tsuyoshi
1
34
エンジニアの循環ってgood_or_bad_.pdf
tsuyoshi
0
850
スタートアップエンジニアの役割
tsuyoshi
0
390
古株のvalueの出し方
tsuyoshi
0
3.8k
Other Decks in Business
See All in Business
20分で分かる人事・HR領域の学び方 / How to learn HR in 20 minutes
iwashi86
11
5.3k
SimpleForm会社説明資料
simpleform
0
1.7k
【会社紹介資料】Attack株式会社(2022年6月)
attack
0
120
Tangerine会社紹介資料/We are hiring
3yasuda
2
1.3k
Canly採用資料
canly
0
600
AniCure動物病院/株式会社 紹介資料
anicure
0
280
アルプ株式会社 会社紹介資料 / Alp, Inc. Company Deck
alpinc
0
700
継続とUnlearn〜七転八倒で向き合う組織の評価と目標設定〜
junki
0
870
DnD_Opening_Part2
omarmontoya
0
130
株式会社Beyond Cafe| Culture Book
beyondcafe1
0
580
大規模で複雑!巨大レガシーシステムをリプレイスするためにスクラムチームを立ち上げた話
ktzwystk
1
1.2k
24卒サマーインターンシップ紹介資料 / GMOペパボ
pepabo_recruit
0
250
Featured
See All Featured
Practical Orchestrator
shlominoach
178
8.6k
Ruby is Unlike a Banana
tanoku
91
9.2k
Code Review Best Practice
trishagee
43
8.9k
GitHub's CSS Performance
jonrohan
1020
420k
Learning to Love Humans: Emotional Interface Design
aarron
261
37k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
119
28k
Keith and Marios Guide to Fast Websites
keithpitt
404
21k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
349
27k
GraphQLの誤解/rethinking-graphql
sonatard
27
6.5k
Unsuck your backbone
ammeep
659
55k
The Cult of Friendly URLs
andyhume
68
4.8k
Debugging Ruby Performance
tmm1
65
10k
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をもらったとか 多くの困難に立ち向かう為の信念が大事!
ご静聴ありがとう ございました