$30 off During Our Annual Pro Sale. View Details »

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

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

tsuyoshi nakamura

March 10, 2018
Tweet

More Decks by tsuyoshi nakamura

Other Decks in Business

Transcript

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

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

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

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

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

    見極める。必要な場合であっても1度file_exits した結果をストレージに置いておくべきだった
  6. 2 --- preg_matchの多用 preg_matchじゃなくても良い場面でも preg_matchを使ってた。 > そもそもpreg_matchしなくても良い設計はな いか、多くの場合はstrposで代用できて、とても 高速

  7. 3 --- ImageMagic運用 元画像から綺麗にサムネイルを作る要件に対 して自前でImageMagicをインストールしてオン デマンドに活用してた。 > Lambdaで非同期的にサムネイルを作る方法 もあるけど、そもそもサムネイル+CDN配信して くれるsaasを活用した

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

  9. 5 --- 不要になったtableがたくさん 過去使ってたけど今は使ってないテーブルが多 数。しかもめっちゃレコード持ってるDBの Aurora移行の時に見積りに影響。 > 不要になれば期限を決めてdrop tableしま しょう。とりあえずとっておくではなくて、N日まで

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

    Phanも活用
  11. 7 --- Blogシステムを自前で運用 SEOに効果あるっぽいから同じサービスの domain内でblog記事を運用したい...が、効果 が未知数なものを運用していくツラさ > SEOは無視できないけど自分たちの本業の サービス開発に集中すべし。クオリティーの高 いサービスを提供することが一番のSEO対策!!

    結局外部blogサービスへ引越した
  12. 8 --- ハウスキーピング意識の欠如 とりあえずログを取っておくで放置されるパター ンが後々、ログが肥大化してdiskを食いつぶし たり問題が表面化 > 無駄にログを溜め込まない。N日経って不要 となるものは積極的にpurge処理を追加

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

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

  15. ここまでは技術的な話

  16. 組織的な話を少々

  17. 11 --- コードを書く以外の役割 少しTeamが大きくなると必然と古株にマネージ メント的要件や社内情シスのような役割を求め られるようになる。 思考と合えば良いが、今後もバリバリコードを 書いてプロダクト開発したいと思考しているとツ ライ >

    PM的な役割の人を早めに採用すべし
  18. 色々と話してきましたが、何は妥協すべき でなかったのか?

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

    役割が変わったなと感じ、不満に思えば早めに 1 on 1 ❏ 流れに任せてなんとなくその役割を担うのはリスク
  20. おまけ(実は)

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

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

    Stock Optionをもらったとか 多くの困難に立ち向かう為の信念が大事!
  23. ご静聴ありがとう ございました