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
510
PHPを少しでも早く_条件はあるよ_.pdf
tsuyoshi
0
87
スタートアップ6年目のレビュー文化.pdf
tsuyoshi
1
2k
PHPを少し深堀るよ.pdf
tsuyoshi
0
400
Reactive_Manifesto.pdf
tsuyoshi
0
92
About_Resilience.pdf
tsuyoshi
1
99
エンジニアの循環ってgood_or_bad_.pdf
tsuyoshi
0
1.3k
スタートアップエンジニアの役割
tsuyoshi
0
550
古株のvalueの出し方
tsuyoshi
0
4.2k
Other Decks in Business
See All in Business
[2026.07] カルチャーデック|株式会社サイバーリンクス
cyberlinks
0
160
人生初のマネージャーというロールを 経験して得たもの・失ったもの / Reflections on My First Manager Role
mackey0225
0
760
スマサテでの日々 -Sumasate Tour Deck-
sumasate
0
1.4k
Advanced:マルチエージェントの設計と運用(Claude Code)
forest8810
1
310
GOドライブ会社紹介資料
go_drive_corp
0
4.5k
透明性レポート(2026年上半期)
mercari_inc
0
12k
サステナブルな成長を支えるセルフマネジメントの技術/Self Management skill for growth
ikuodanaka
1
680
マルチエージェント入門:チームで動くAIと非エンジニアのための設計(Claude Code)
forest8810
0
460
マルチプロダクト時代のPMM-Discoveryから0→1、Expansionまで フェーズで変わる期待役割とアサインの設計図
sasaguchi
0
430
スマサテ 会社紹介資料
sumasate
0
1.6k
Fable5との実践から生まれた非エンジニア組織のループエンジニアリング
nagatsu
1
840
malna-recruiting-pitch
malna
0
24k
Featured
See All Featured
State of Search Keynote: SEO is Dead Long Live SEO
ryanjones
0
240
Designing Dashboards & Data Visualisations in Web Apps
destraynor
232
55k
エンジニアに許された特別な時間の終わり
watany
108
250k
New Earth Scene 8
popppiees
3
2.5k
A Guide to Academic Writing Using Generative AI - A Workshop
ks91
PRO
1
360
Information Architects: The Missing Link in Design Systems
soysaucechin
0
1.1k
Max Prin - Stacking Signals: How International SEO Comes Together (And Falls Apart)
techseoconnect
PRO
0
360
svc-hook: hooking system calls on ARM64 by binary rewriting
retrage
2
450
WCS-LA-2024
lcolladotor
0
790
Impact Scores and Hybrid Strategies: The future of link building
tamaranovitovic
0
370
Joys of Absence: A Defence of Solitary Play
codingconduct
1
430
Design in an AI World
tapps
1
280
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をもらったとか 多くの困難に立ち向かう為の信念が大事!
ご静聴ありがとう ございました