はじめに
はじめまして。
私はちょうど１年前に大手SIerから実務未経験でWebサービス（SaaS）を運営する少人数ベンチャーに転職しました。
１年経ったので、どんな感じだったか、少し細かめに振り返りを書いていこうと思います。
前提
この記事の意図
今後の自分のために整理しておきたく、自分の中だけにとどめておくのも勿体ないので、
少しでも誰かの参考になれたらと、アウトプットしておこうと思ったのが背景です。
あと、私が所属しているのはメガベンチャーのような恵まれた環境でなく、創業期の少人数ベンチャーで結構変わった環境です。
このような環境から発信されている情報は少ないと思うので、同じような環境にジョインを検討しているような、
特に未経験の方の参考になればと思っています。
どんな環境？立場？
- サービス開始から10年、創業は5年ほどの少人数ベンチャー
- toB＆toCの両機能がある自社開発のSaaSを展開
- エンジニアチームは計5〜7名、内訳は以下
- 代表取締役（エンジニアマネージャーも兼ねる）
- 私（エンジニア：最近はシステム運用面のマネージャーも兼ねつつ開発も担当）
- 学生インターンのエンジニア3~5名（フロントエンドとバックエンドの開発担当、インフラは担当外）
やったこと（経験）
サマリ
担当した範囲
仕様検討、設計、実装、テスト（自動・手動）、デプロイ、PjM（ディレクション）、システム運用チームマネージャー（施策提案・管理など）、バグ管理・修正、サーバ構築・運用、インターン生のコードレビュー
技術要素
Rails、JS(ES6)、SCSS、React、TypeScript、AWS（EC2, RDS, IAM, SSM, CloudWatch, Lambda, SNSなど）、Linux（yum, npm, logrotateなど）、BigQuery、Fluentd、外部API（AWS SDK, Stripe, mailgun, mauticなど）、ElasticSearch(chewy)、CloudOneなど
時期別（長いので折りたたみました）
〜入社1ヶ月まで
範囲
実装
内容
- UI変更（入力フォームをテーブル形式からスライダー形式に変更）
- Capistranoデプロイの成功・失敗時にslack通知を追加
- 機能追加
技術要素
- Rails（view・サービスクラス）、ES6（スライダー含む）、SCSS、Capistrano
1〜3ヶ月
範囲
実装中心に設計（どんなクラス・テーブルを作るか等）も担当
内容
- 既存画面に似た新画面開発（既存機能とどう共通化するかも含む）
- 簡単なバグ調査・修正
- 外部APIが絡む新機能開発
技術要素
- Rails（RDBテーブル・ルーティング・MVCの設計・実装・自動テスト）
- JS非同期処理の実装
- メール系外部APIのラッパークラス等の設計・実装
3〜6ヶ月
範囲
- 主に設計から実装・テストまで（一部、要件のみ決まってる段階から仕様検討）
- AWS
- PjMも一部担当
内容
- 新たなサブシステム（既存と似たシステム）全体の開発
- 新機能開発
- AWS EC2のサーバ移行（t3からt4gへの移行、移行前のサーバにインストールされているLinuxパッケージは特に管理されていなかったので現状整理するところから実施）
- EC2へウイルススキャン（OSS）を導入（Linuxパッケージインストール＆Lambdaで定期実行・ウイルス検知時のslack通知実装）
- 既存機能のクローズPJや社内管理用機能開発におけるPjM（実装は別のエンジニアだが、スケジュールや進め方の方針決め、コードレビュー、相談受けなど担当）
- 機能クローズに伴ってのユーザへの案内メールの文面作成
- エンジニア採用手伝い（スカウト候補者ピックアップなど）
技術要素：
- Rails（ルーティング・MVC設計・実装・テスト、Devise認証、Formオブジェクト、AWS SDK、認証・認可、Rakeタスク）
- JS、CSS、React（少しだけ）
- AWS（EC2、RDS、S3、Lambda、IAM、SSM、SNSなど）
- Linux（yumやrpmの環境構築）
6ヶ月〜1年
範囲
- 主にPjMとして、要件のみ決まっている段階から仕様検討〜設計〜実装〜テストまで（セールスなどビジネス側からの要件を直接受け付けし、仕様を相談する役割から）
- PJによっては他のエンジニアに実装・テストを依頼しつつコードレビューも実施
- インフラ・運用面のチームマネージャーを担当
内容
- 新機能開発
- リファクタリング施策実施（技術負債返済）
- 不具合管理・修正判断・修正、不具合管理ツールの移行
- AWS運用（監視、セキュリティ関連の仕組み導入・セキュリティ製品ベンダーとの打ち合わせ、EC2のスペック変更・移行など）
- システム運用のチームマネージャーとして施策の提案や検討、運用ドキュメント整備
- ロギング周り（logrotate導入、RailsログをBigQueryで検索できる仕組み導入など）
- エンジニアメンバー用のドキュメント整備（自動テストの実装方針、新メンバー向けドキュメントなど）
- ビジネス側担当用の機能の操作マニュアル整備
- ユーザ問い合わせ対応（オペレーターからエンジニアへエスカレーションされてきた分の回答）
技術要素
- Rails（ルーティング、RDBテーブル、MVC、キャッシュ戦略周り、SAML認証など）
- 外部APIの利用
- ElasticSearch（chewy）
- JS、CSS、React/TypeScript（少しだけ）
- AWS（EC2、S3、IAM、SSM、セキュリティ系サービスなど）
- BigQuery、fluentd
転職前のスペック
前職
- 新卒入社した大手SIer
- コーディングには関わらず、PJ管理・顧客折衝（提案書やPJ計画書作成、打合せ進行など）・開発委託先管理・手動テストなど担当。
- 基本情報技術者、応用情報技術者、データベーススペシャリスト、ITIL（Foundation）などは保持していました。
大学時代
文系：プログラミング経験なし
学習経験
Railsの学習開始からちょうど1年後くらいに現職に内定（実務未経験として入社）
現在（どんなエンジニア？）：領域、スキルレベル
ここは言語化が難しいのでざっくりですが、、
- Railsは一人称での設計・開発はある程度できるが、設計時点でリーダーからのレビューは受けたほうが良いようなレベル
- AWSは基本は調べつつ一人称で作業可能（EC2構築、IAM権限作成など）
生活・働き方（学習・労働時間・私生活の変化とか）
プライベートでの学習内容
主に実務で使う内容のキャッチアップやレベルアップのための学習が中心。また、AWS SAA取得のために学習していた時期もあります。
労働時間
残業は平均すると月に2桁いかないくらい
（途中に休憩や外出・ジム通いなど挟むので、平日はほとんど朝から晩まで仕事しているイメージ）
私生活の変化（週末の過ごし方）
転職前
転職前は平日でかなり気力を使い果たしていたので、予定がない場合は土曜の夕方くらいまで気力回復のためにダラダラしてるような感じでした。
転職後
気力を使い果たすような場面は少ないので、土曜の朝からわりと元気に動けるようになりました笑
転職前の想像とのギャップ
※一般的なバックエンドエンジニア（？）が抱く感想とは異なると思いますが、自分自身としての感想を書きます。
思っていた通りのこと
総じて楽しい
基本地味な仕事が続いて上手くいかないことが多いですが、やはり開発は楽しく、難しいことが徐々に理解できていく感じも、知的好奇心が満たされて良いです。
（もちろん、Fun的な楽しさでなく、interesting的な楽しさ）
納得して働けている
会社のビジョンや事業の方向性・解決したい社会の課題意識に非常に共感しているので、「なんのためにこんな頑張っているのだろう、、」と思うことがないです。
自分がミッションドリブンな性格だからということもありますし、会社の方たちのお陰も大きいです。
仕事を選べない
これは想定通りでした。Railsでの実装以外にも本当に色々なタスクがあります。
Railsの技術力は他社での経験1年分より劣ると思いますが、その分、フロント・インフラ・ディレクション・チームマネジメントなど色々な面から事業を見れて面白いなとは感じます。
思っていたのと違ったこと
設計が思ったより難しく奥が深い
命名やディレクトリの設計、クラスの分け方など、社内でノウハウはあまりない状態のため、なかなか根拠のある論理的な設計が難しいなと感じました。
理解がなかなか追かないので、下記の本で勉強中です。
ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ
運用面で未整備な部分が多い
サーバ運用や不具合管理が非常に属人的だったり、サーバ構成図がなくインフラの全体像が未だに全部わからない、メトリクスや指標があまり活用されていないなどです。
整っていないからこそ、自分が整備していく余地も多いので頑張っていきたいです。
システム運用アンチパターン ―エンジニアがDevOpsで解決する組織・自動化・コミュニケーション
今後やりたいこと
Railsの技術力を上げる（特に設計面）
下記で語られているようなアーキテクチャの知見をしっかり理解した上で実装できるようにしたいです。
texta.fm カテゴリーの記事一覧 - てくすた
Next.js
時が経つにつれてレガシーなRailsアプリ構成にはなってくると思うので、例えばNext.jsを導入などしてモダンな環境で開発スピードを上げるなど、今後も仮説検証を素早く回せるようにしたいです。（まずはプライベートで学習して身につけたいです）
RailsエンジニアのためのNext.js入門 / Kazuhito Hokamura
足りてないと思うこと
開発スピード
技術力が足りてないこともあって開発スピードが遅いことが多いなと感じます。ただし、質を落としてスピードを上げるのはアンチパターンなようなので模索中です。
社内にない仕組みを取り入れたり提案をすること
ベテランエンジニアがいない少人数ベンチャーなので、良い仕組みを社外から積極的に取り入れることが重要ですが、まだまだできていないと感じます。
大事と思ったこと
何に時間を使うかが大事
「価値の少ない仕事に時間を多く費やすのはNG」、「完璧さを無駄に追い求めない」といったことを意識して意思決定などしています。
例：バグ修正において「重要度が低い機能＆大したことのないバグであれば、その修正に時間をかけず、特には放置する」といったことも必要になるなど。（放置により技術的負債が貯まることも考慮必要ですが）
（前職だと大企業の業務システムで、「とにかくバグは全部潰す」、「資料は完璧に作り込む」という考え方だったのでギャップはありました）
保守性
要件や要望に対して、むやみに機能を追加したりすると保守性の低下に繋がります。
要望に対しても「本当にその機能は追加必要なのか？」、「別の手段で目的を達成する方法はないか？」など考えつつ、保守性も考慮して設計・実装に取り組むことが大事と感じました。
リーンに取り組む
特に現職だとマルチタスクになりがちな状態ですが、できるだけ一つ一つに集中して終わらせてから次のタスクに取り組むことを大事にしています。
複数タスクを並行して取り組むと、俗に言う「コンテキストスイッチの切り替え」が頻繁に発生してしまい非効率です。
（別のタスクを再開する度に毎回最初に「この仕事って何だっけな？」と考える時間が発生し、工数が当初より膨らんでしまう等）
This is Lean 「リソース」にとらわれずチームを変える新時代のリーン・マネジメント
特に良いと思った記事・書籍
仕事全般
ベンチャー転職1年目の教科書 | Goodfind Career
入社前に読みましたが「依頼される仕事の粒度は抽象的で複雑」、「素直さを武装する」など、ベンチャーで仕事に取り組むにおいて、今見返しても大事だなと思う内容が多いです。
プログラミング全般
プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則
「設計やるならまず読んでおかないと、、」的な本だと感じます。
入社1ヶ月後に読みましたが、経験を積んでから読んでも学ぶことは多い気がするので、定期的に読み返したい本です。
Rails設計
texta.fm：Apple Podcast内の7. Fat Controllers and Models
ついついFat Controllerを作ってしまいがちなのは実感するところですが、「具体的になぜダメなのか」「どうモデルなどに処理を寄せていくのか」がわかりやすかったです。
Rails実装
マネーフォワード社内PRに見られるRubyの書き方について - (1) 配列の生成 | Money Forward Engineers' Blog
ついやってしまいがちなアンチパターンの実装が多く書かれているので、一通り読んでおくとコードレビューでの指摘が少なくなったり、逆に自分がコードレビューする際にしっかり指摘できるようになったりして良いです。
Ruby競プロTips(基本・罠・高速化108 2.7x2.7)
こちらは速度面を中心に、どういった書き方が早いのかがまとまっているので、一通り読んでおくと速度が遅い実装をしてしまうのを防げます。
情報収集
はてなブックマーク、TechFeed、Qiita、Zennがメインです。網羅的な情報収集はあまり積極的にできてないかもです。
最後に
- 情報発信、今まで全然やってなかったですが大変ですね、、（10時間くらいかかりました、、）
- でも楽しいです。書きながら本当に頭が整理されますし、足りない点も色々出てきます。
- 品質が低いので、経験を積んで質を上げたいです。