Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

tsuyoshi nakamura

March 10, 2018
Tweet

More Decks by tsuyoshi nakamura

Other Decks in Business

Transcript

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

    View Slide

  2. - Software Engineer (CyberAgent group)
    - @nakamura_tsuyo4
    - Makuake
    - 創業エンジニア (from 2013)
    About me

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    今後はdev環境にSQLモード設定を検討

    View Slide

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

    View Slide

  16. 組織的な話を少々

    View Slide

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

    View Slide

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

    View Slide

  19. ❏ もっと必要最低限の機能に絞れば... (MVP)
    ❏ 後発サービスとしては難しい面もあるけど...
    ❏ 本来集中すべきコア機能などに集中
    ❏ 提供するものを小さくすることで運用コストを下げる
    ❏ 役割が変わったなと感じ、不満に思えば早めに 1
    on 1
    ❏ 流れに任せてなんとなくその役割を担うのはリスク

    View Slide

  20. おまけ(実は)

    View Slide

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

    View Slide

  22. ▸ ゼロから事業を立ち上げをし
    たいと強く思っていた
    In My Case
    人によるけど
    - CEOの思いに強く共感したとか
    - Stock Optionをもらったとか
    多くの困難に立ち向かう為の信念が大事!

    View Slide

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

    View Slide