スタートアップしてからの失敗の数々

スタートアップしてからの失敗の数々 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をもらったとか多くの困難に立ち向かう為の信念が大事!

ご静聴ありがとうございました

スタートアップしてからの失敗の数々

スタートアップしてからの失敗の数々

tsuyoshi nakamura

More Decks by tsuyoshi nakamura

Other Decks in Business

Featured

Transcript

スタートアップしてからの失敗の数々 2018.3.10 @phperkaigi2018

- Software Engineer (CyberAgent group) - @nakamura_tsuyo4 - Makuake -

Makuakeはスタートアップ時のメイン言語として PHPを採用しています。無い無いづくしのスタートアップですが、過去を振り返りここは妥協せずにやっておけば良かったなどを紹介します前段

たくさんあるので早速いきます

1 --- 過度なファイルの存在確認処理 s3に保存している画像のfile_exists(AWS SDK)処理が至る所に存在。 = インターネット経由でAPIをコールしまくっている。performanceは引きづられる > そもそもファイルの存在確認が必要な場面を

2 --- preg_matchの多用 preg_matchじゃなくても良い場面でも preg_matchを使ってた。 > そもそもpreg_matchしなくても良い設計はないか、多くの場合はstrposで代用できて、とても高速

4 --- AWS SESの上限を使い切ってしまったメールを送信できる上限が決まってます。がその閾値を見逃して上限に達してしまい、メールが送れない問題 > すぐに上限緩和依頼。監視の追加

6 --- Unuse method classたくさん問題利用されていないコードが沢山散らばっていて可読性が悪く開発効率がみるみる落ちる > IDEなどから不要なものは念のためgrepして消すリリースを繰り返した。total:300PR’s。

9 --- 外部API 変更を見逃しての障害通知はだいたいメールのみ。それを忘れさられ、或る日突然エラー > メールだけでは気づかないのでslackへの通知や通知をメールをメーリス化で

10 --- mysqlのレコードに0とnullが同居問題プログラムの作り上、ケアすべきことが増え、冗長になっている > プログラムを修正して蓋をする過去のデータを洗い替えするバッチで一気に修正今後はdev環境にSQLモード設定を検討

ここまでは技術的な話

組織的な話を少々

色々と話してきましたが、何は妥協すべきでなかったのか？

❏ もっと必要最低限の機能に絞れば... (MVP) ❏ 後発サービスとしては難しい面もあるけど... ❏ 本来集中すべきコア機能などに集中 ❏ 提供するものを小さくすることで運用コストを下げる ❏

おまけ（実は）

スタートアップのエンジニアになることはそれなりの苦労があります遊んでいる暇などなく、ひたすら仕事します。システム・組織のトラブルなど日常になります。この状況を下支えするモチベーションが必要

▸ ゼロから事業を立ち上げをしたいと強く思っていた In My Case 人によるけど - CEOの思いに強く共感したとか -

ご静聴ありがとうございました