Slide 1
Slide 1 text
スタートアップしてからの失敗の数々
2018.3.10 @phperkaigi2018
Slide 2
Slide 2 text
- Software Engineer (CyberAgent group)
- @nakamura_tsuyo4
- Makuake
- 創業エンジニア (from 2013)
About me
Slide 3
Slide 3 text
Makuakeはスタートアップ時のメイン言語として
PHPを採用しています。
無い無いづくしのスタートアップですが、過去を振り返りここは妥協
せずにやっておけば良かったなどを紹介します
前段
Slide 4
Slide 4 text
たくさんあるので早速いきます
Slide 5
Slide 5 text
1
---
過度なファイルの存在確認処理
s3に保存している画像のfile_exists(AWS
SDK)処理が至る所に存在。
= インターネット経由でAPIをコールしまくってい
る。performanceは引きづられる
> そもそもファイルの存在確認が必要な場面を
見極める。必要な場合であっても1度file_exits
した結果をストレージに置いておくべきだった
Slide 6
Slide 6 text
2
---
preg_matchの多用
preg_matchじゃなくても良い場面でも
preg_matchを使ってた。
> そもそもpreg_matchしなくても良い設計はな
いか、多くの場合はstrposで代用できて、とても
高速
Slide 7
Slide 7 text
3
---
ImageMagic運用
元画像から綺麗にサムネイルを作る要件に対
して自前でImageMagicをインストールしてオン
デマンドに活用してた。
> Lambdaで非同期的にサムネイルを作る方法
もあるけど、そもそもサムネイル+CDN配信して
くれるsaasを活用した
Slide 8
Slide 8 text
4
---
AWS SESの上限を使い切ってしまった
メールを送信できる上限が決まってます。がそ
の閾値を見逃して上限に達してしまい、メール
が送れない問題
> すぐに上限緩和依頼。監視の追加
Slide 9
Slide 9 text
5
---
不要になったtableがたくさん
過去使ってたけど今は使ってないテーブルが多
数。しかもめっちゃレコード持ってるDBの
Aurora移行の時に見積りに影響。
> 不要になれば期限を決めてdrop tableしま
しょう。とりあえずとっておくではなくて、N日まで
に使わなかったら消すとかbackupして消すが
必要
Slide 10
Slide 10 text
6
---
Unuse method classたくさん問題
利用されていないコードが沢山散らばっていて
可読性が悪く開発効率がみるみる落ちる
> IDEなどから不要なものは念のためgrepして
消すリリースを繰り返した。total:300PR’s。
Phanも活用
Slide 11
Slide 11 text
7
---
Blogシステムを自前で運用
SEOに効果あるっぽいから同じサービスの
domain内でblog記事を運用したい...が、効果
が未知数なものを運用していくツラさ
> SEOは無視できないけど自分たちの本業の
サービス開発に集中すべし。クオリティーの高
いサービスを提供することが一番のSEO対策!!
結局外部blogサービスへ引越した
Slide 12
Slide 12 text
8
---
ハウスキーピング意識の欠如
とりあえずログを取っておくで放置されるパター
ンが後々、ログが肥大化してdiskを食いつぶし
たり問題が表面化
> 無駄にログを溜め込まない。N日経って不要
となるものは積極的にpurge処理を追加
Slide 13
Slide 13 text
9
---
外部API 変更を見逃しての障害
通知はだいたいメールのみ。それを忘れさら
れ、或る日突然エラー
> メールだけでは気づかないのでslackへの通
知や通知をメールをメーリス化で
Slide 14
Slide 14 text
10
---
mysqlのレコードに0とnullが同居問題
プログラムの作り上、ケアすべきことが増え、冗
長になっている
> プログラムを修正して蓋をする
過去のデータを洗い替えするバッチで一気に修
正
今後はdev環境にSQLモード設定を検討
Slide 15
Slide 15 text
ここまでは技術的な話
Slide 16
Slide 16 text
組織的な話を少々
Slide 17
Slide 17 text
11
---
コードを書く以外の役割
少しTeamが大きくなると必然と古株にマネージ
メント的要件や社内情シスのような役割を求め
られるようになる。
思考と合えば良いが、今後もバリバリコードを
書いてプロダクト開発したいと思考しているとツ
ライ
> PM的な役割の人を早めに採用すべし
Slide 18
Slide 18 text
色々と話してきましたが、何は妥協すべき
でなかったのか？
Slide 19
Slide 19 text
❏ もっと必要最低限の機能に絞れば... (MVP)
❏ 後発サービスとしては難しい面もあるけど...
❏ 本来集中すべきコア機能などに集中
❏ 提供するものを小さくすることで運用コストを下げる
❏ 役割が変わったなと感じ、不満に思えば早めに 1
on 1
❏ 流れに任せてなんとなくその役割を担うのはリスク
Slide 20
Slide 20 text
おまけ（実は）
Slide 21
Slide 21 text
スタートアップのエンジニアになることはそれなりの苦
労があります
遊んでいる暇などなく、ひたすら仕事します。
システム・組織のトラブルなど日常になります。
この状況を下支えするモチベーションが必要
Slide 22
Slide 22 text
▸ ゼロから事業を立ち上げをし
たいと強く思っていた
In My Case
人によるけど
- CEOの思いに強く共感したとか
- Stock Optionをもらったとか
多くの困難に立ち向かう為の信念が大事!
Slide 23
Slide 23 text
ご静聴ありがとう
ございました