ガチスタートアップ1人目のバックエンドエンジニアのリアルな戦略と奮闘 #railsdm2019 #railsdm2019b @sinamon129

ガチスタートアップ1人目のバックエンドエンジニアのリアルな戦略と奮闘 #railsdm2019 #railsdm2019b @sinamon129

2018年7月に1人目のバックエンドエンジニアとして入社し、WordPressで動いていた既存システムをRuby・Ruby on Rails・GCP(GKE)でフルリニューアルしました。その際の技術選択の戦略・システム構成と、リニューアル後のメリットデメリット・同僚がjoinして改善された部分をメインに、その後の職域を超えてのスタートアップでのリアルな奮闘もお話できればと思います。

RailsDeveloperMeetup2019 Day2

Fda25022237b4e795fee7a9996ffc4bf?s=128

sinamon129

March 23, 2019
Tweet

Transcript

  1. None
  2. ⾃⼰紹介 RiLi, inc. 取締役 CTO RailsGirls Tokyo 5-11th coach         

    7th organizer ͠ͳ΋Μ(ยࢁ ைඒ) @sinamon129
  3. None
  4. None
  5. None
  6. RiLi,inc.について • 「⾃分らしいスタイルを叶える選択肢」を提案する、メディアお よびコミュニティを運営する会社です • 趣味・趣向が近いユーザーが集まるコミュニティをベースとする ことで、最適なコンテンツを提供する、新しいメディアの形を⽬ 指しています

  7. 2018年7⽉⼊社

  8. 私が⼊った時の状態 • Super Crowds inc.(デザイン会社)から⽣まれた会社 • モノのデザイン・動くフロント強い • Wordpress・スプレッドシートでのシステム構築等はできる •

    バックエンドエンジニア不在 • クリエイター集団+編集部メンバーで計8名程 • (ちなみに⼊った時は取締役じゃなかったよ!)
  9. なんで⼊ったの? • 社⻑といつか⼀緒に仕事がしたいと思っていた • 会社の⼈たちが作るものが好き! • ビジョンへの共感 • ⼤学時代からファッションに近い領域のサービスを作りたかった •

    「1通りどうにかなるかな」ぐらいは⾊々経験してきた
  10. 今⽇の話 • ガチスタートアップの技術選択の⼀例 • 同僚マジでありがたい • プログラミングから⼿を引くときの⼼境 • スタートアップ興味あるけど怖そうで踏み出せない⼈へ

  11. 作ってきたシステム

  12. ⼊社前〜 • SpreadSheetでステータス管理していたものをRailsで管理画⾯化 • 「仕事を⼀緒にやってみる」お試し • 働くことが想像つかなかったりする • まず副業とかでやってみるとお互い安⼼ •

    0から作るリハビリ
  13. 既存のメディアのフルリニューアル • ⼊社直後からはじめたプロジェクト • WordPressで動いていたメディアサイト • メインはデザインリニューアル • 10⽉のポップアップストアを⾒据えて •

    (物販だけど)プロモーションもできるといいね • 将来的な機能追加を視野に⼊れて
  14. フルリニューアルの 技術選択と実装

  15. ざっくりどう⾔うものを作ったか

  16. 主な構成 • Ruby • Ruby on Rails • ActiveStorageを利⽤ •

    webpack (not webpacker) / vue.js / sass / slim / browser-sync • GCP
  17. Static Storage
 Cloud Storage Database Server
 Cloud SQL Kubernetes cluster

    -# *OHSFTT $POUSPMMFS .FEJB 4FSWJDF "ENJO 4FSWJDF 1PE 1PE 1PE 1PE -# *OHSFTT $POUSPMMFS $SPO+PC
  18. 縛り • 技術⾯での縛りは特になし • 「⾃由に決めて」と⾔われた • ⼀緒に作る⼈とお互い作りやすいようにしたい • 10⽉までにシステムの切り替えが完了している必要あり

  19. 考えていたこと • エンジニアを集めづらいサービスなので後のち登壇ネタに • 0から作るので⾃分がやったことないことにチャレンジしたい • スピードもいるので、やったことないことだらけにすると⾟そう • 「現実的な」構成

  20. 技術選択をする前に決めたこと • 開発のスコープ • 必要ページの内容とpath • 各ページの構成要素 • 上記を踏まえたワイヤー(プロトタイピングツールで画⾯遷移) •

    DBのテーブル設計(ER図ざっと引く)
  21. ⾃分の状態 • Rails Application 4年弱やってた • すでにあるアプリケーションを機能追加・運⽤が多め • Rails newからインフラ設定までやったのは2016年が最後…?

    • 興味の強さ度合い • サービスや組織を作る・運⽤する >> 新しい技術とか
  22. どう⾔う順番で決めていったか? • ⾔語・フレームワーク • Ruby, Ruby on Railsが⼀番好き(なのでそれ以外考えず) • 開発環境の構築(docker-compose

    でmysql・本番と同⼀imageのweb) • フロントエンド周りの整備 • 管理画⾯どうするか • インフラ
  23. ⼀緒に開発したメンバー • フロントエンドエンジニア(1⼈) • ワイヤー引く / 全般のHTML・CSS・JS周りの実装 • デザインはデザイナーが作ってくれる •

    Vue.jsを別件で使った経験あり • Railsプロジェクト経験もある(頻繁ではない)
  24. ⼀緒に作る上で話し合ったこと • 開発する上で欲しいと⾔われたもの • ES6 buildできる/SASS/Jadeもしくはそれに類するもの/ライブ リロード • SPAはお互いやったことがないのでMPAで⾏こう •

    スピード重視・01フェーズなのでまだ旨みがなさそう? • VueはいけるとのことだったのでReactじゃなくてVueで進める
  25. webpack(not webpacker) (1) • 初めてのモダンフロントエンド • 調査・噂を聞くにwebpackerは⼀癖ありそう • webpackも初だったので世に多く知⾒があるwebpackから •

    webpack -> webpackerは後でいけそう • ⼀旦sprocketsと共存しておく
  26. webpack(not webpacker) (2) • js,css • /frontend/src以下に置く • webpackでjsはES6 build・SASSをcssにコンパイルしてそれぞれ別ファイル

    でapp/assets以下に • image, font • app/asset以下に配置(js,cssでのpath指定はasset_pathで指定) • ↑でbuildされてassets以下に配置されたファイルをasset compileする
  27. みてください、この画像の枚数〜〜 • 画像がもりもりしている • 1ページ80枚以上ある • ぜんぶめっちゃかわいいので、動 作検証で開くとうっかり⾒すぎて 時間を吸われる

  28. ActiveStorage • 昔、画像系gemはpaper clipを愛⽤していたが… • deplicateになってActive Storageを使えと書いてあった • 素直にActiveStorageを使うのかー!と思う(素直すぎる) •

    導⼊はめちゃくちゃ簡単だった • しかし…
  29. ざっくりActiveStorageの仕組み • viewで⽣成されたURLは画像のある場所ではない • RepresentationsController#show • ここで指定したストレージの画像URLにredirect • variantの指定で動的にリサイズできるが、そのタイミングで 画像のアップロードが⾛る

  30. 問題 • 画像のアクセス時に絶対にRails層を通る • 画像数が多いので、アクセスが同時に来ると詰まりがち • variantを指定した場合、Rails層で動的にリサイズが⾛るので、 新規画像が追加された後のアクセスで詰まりがち • CDNをはさみづらい仕組み

    • 公式でない(はず)
  31. ちょっと遅い 後々やばそう

  32. 解決策 • のちに⼊社した同僚⽒がやってくれた • アップロード・モデルに紐づける部分 • ActiveStorageをそのまま使う • 画像加⼯・表⽰ •

    CDN(Imgix)を利⽤
  33. 具体的にいうと • ApplicationhelperにCDNのパスを返すhelperを追加 (production時
 
 
 
 
 
 画像のpath指定をurl_for(variant)からservice_url_for(variant)に

  34. よかった・うまくいったこと • フロントエンドエンジニアとの協業 • 開発着⼿できる状態を整えるのを第⼀優先で進めた • 開発環境構築にほぼ詰まらず • 開発⽤データ投⼊バッチ •

    Kubernetes • スケールしやすい状態に作れた
  35. うまくいかなかったところ • ActiveStorageに⼤分悩まされた • おかげでめっちゃRailsのissueやPR・コードを読むことになっ た(から勉強になった) • ちゃんと調べてから使おう • 初GKE(初Kubernetes)だったので、試⾏錯誤に時間かかった

    • いい学習コストだった思おう…
  36. 2018年11⽉ エンジニアjoin! (@gomachan)

  37. よかったこと(1) • ⾃分よりレベルが⾼くて尊敬できる⼈だから安⼼して背中を任せ られる • 隣で相談できるって素晴らしい! • 1⼈で考えて⾎迷った選択をしなくなった • 「属⼈化」からの早期脱出できた…!

  38. よかったこと(2) • ⼊社前に現状の事業周りを取り巻く情報と相談事項をまとめた • 「コードを読んでもわからないこと」をメインに • システム周りでいうと、「これは上⼿に実装できなくてこう なってる」を⼀緒に考えて解決できた • 遠慮したりカッコつけないで相談しまくる

  39. ⼊社してすぐやってくれてよかったこと • 定期⾃動gem updatePR⽣成 • rubocop/onkcopの導⼊ • CircleCIの整備 • ActiveStorageのCDN対応

    • 頻出コマンドをmakeファイルにまとめて、`make`って打ったらhelpが出る • めっちゃドキュメントレスになる・迷わない・最⾼ • その他私が志半ば・トチ狂って実装してたものをキレイキレイ
  40. よかったこと(3) • 私がエンジニアリングからある程度⼿を離す選択肢が取れた • 同僚⽒:エンジニアリング全般ゴリゴリやりたいマン • 私:開発が関係する仕様周り・組織的に回ってないところやる マン

  41. プログラミングするの 減ったの⾟くないの?

  42. ⼿を離せるようになったので • とりあえず回ってない・⾜りてない部分を補うように動き出した • 会社を整えていく部分 • 今後やりたいことをできるようにするための意思決定を進める • 社⻑に「キャリアとしてエンジニア極めたいとかあれば無理にと はいわないけど、⼀緒に経営やらない?」って⾔われる

  43. 是⾮と返事したが、同時に考え始めた • 現状、⾃分が職域を超えて動く⽅が将来的にいいものが作れる会 社を作れそうだからやりたい • エンジニアリング以外の仕事は過去に同僚がやっているのを⾒た ことがあることも多いけど、やったことはほぼない • 経営するとはなんだ •

    「組織最適化」を極めて動いた先に私はどうするんだ
  44. プログラマとしての葛藤・不安 • コードを書くことにこだわりが無いと思っていだけども • プログラム書かない仕事はしたくないとかはないが • システム設計・実装・システムと⼀緒の時は楽しい • たとえバグが出ようが障害が起きようが •

    技術的に置いていかれてる感
  45. なんか漠然と不安に襲われたので • いろんな⼈に相談してみる • なんで不安なのか考えてみる • そもそも何がやりたかったんだっけ?

  46. 相談してみる • 例えば • 今後やるであろう仕事をやってる⼈ • エンジニアだけど⼀時的に職域外の仕事をしてた⼈ • 同じような境遇にいそうな⼈ •

    (余談)⾎迷ってると「⾃分どうしたらいいんですかね?」とか 相談してしまって、「何がしたいの?」って聞かれたりするw
  47. そもそもなぜ不安になるのか考えた • キャリアとして、これまで想像の範囲内だったところから完全に 外れた • 「これまで解決してきた問題」の派⽣から外れている • 意思決定のスコープが広がった • 「終わりが分かりやすい仕事」ではないことが多い

    • -> 想像できない・わからない・進んでない感が不安材料
  48. 私結局何がやりたかったんだっけ…? • 「素敵だな」って思えるものにみんなが出会える世界にしたい • 私の個⼈的欲望としては「(⾃分が)かわいいと思うもの」の情 報に溺れながら、これだ!っていうものを⾃分の周りに置きたい • IT系からもファッション系からも納得できるものを作りたい • ファッションに関するデータがもっと活⽤できるような基盤を作り

    たい
  49. 考えた結果 • まずは会社を整えていくところに全⼒投⼊する • 「全体が⼀歩前進」を意識して⾏動する(迷いは⽌まる) • 「進んでるぞ!」って思えるように分解作業をする • 全員が「得意・やりたいこと」に専念できる組織を⽬指す •

    整えて強み・やりたいことに戻る!
  50. (余談)最近の私 • 経営周り • 採⽤・広報(5⽉から引き継げる!) • 労務・情シス周り⼀部 • (コンテンツ周り以外の)プロダクトオーナー •

    社外連絡担当 • (たまに)gem update・bug fix・ちょっとだけ開発
  51. スタートアップ興味ある けど 怖そうで踏み出せない⼈へ

  52. (多分⼀般的な)⾒え⽅ • 出来上がっている会社 • すでに整っている • (割と)安定している • ⼩規模スタートアップ •

    整ってない • 何が起こるかわからない
  53. 整っていないといいこと • ⾃分が⼊ることにより何か変わるのが「わかりやすい」 • ふつうのことがふつうにできることが重宝される • 超スーパーすごいエキスパートにならなくても • ちょっとの頑張りで⼤分変わる •

    ⾃分の本当にできること・できないことが⾒えやすい
  54. 整っていないといいこと • 意思決定の当事者になりやすい • これまでこうだといいと思っていたことを反映できる • 整っていることへの尊敬の念で溢れる • 制度等がなんのためにあるのか理解できる •

    それを実現するまでの道のりが当事者になって⼤変さに気づく
  55. 検討材料として⼤事そうなこと • 純粋に⼈として合いそうかどうか • メンバーの得意分野・不得意分野の把握 • パズルがいい感じにハマると気持ちいい • ⽬指している世界に対して共感ができるか •

    今あるプロダクトがというより、どうしていきたいか
  56. 気をつけてること • ⾃分のモチベーションとメンタルは⾃分でコントロール • 他⼈の問題を解決している余裕がある⼈がいるとは限らない • 精神的に⼤丈夫な状態をできるだけ作る • (⾃⼰肯定感と健康のため)パーソナルトレーニングに通い始めました •

    健康 • 死んだら終わるので、休める⽇は休む
  57. スタートアップは楽しいぞ! • 素敵な世界を作ろうとしている会社は沢⼭ある • これまでのいろんな知⾒を注⼊するチャンス • 新しい⽂化が⽣まれる瞬間に作り⼿として⽴ち会えるかも • (やらざるを得ないから)できることが増える •

    毎⽇が⽂化祭前 • うまくいかなくてもそれは⼀つの貴重な経験
  58. まとめ

  59. 今⽇話した話のまとめ • スタートアップの技術選択 • 同僚マジでありがたい • プログラミングから⼿を引くときの思考 • スタートアップはいいぞ!