🐯

メガベンチャーからスタートアップに転職して3ヶ月が経過した|Offers Tech Blog

2022/07/21に公開

こんにちは!🐯
プロダクト開発人材の副業転職プラットフォーム Offers を運営する株式会社 overflow のエンジニア(主にバックエンドメイン)の Taiga です。

別会社でエンジニアとして 2 年程勤めたのち、2022 年の 4 月にoverflowへ転職して、3 ヶ月経過しました。

今回はメガベンチャーからスタートアップへ転職する人向けに何か参考になればと思い記事を書いてみました。(とはいっても半分はポエムですが...)
なお転職理由や自身の紹介など興味のある方は下記記事にて御覧ください。[1]
https://note.com/taiga_1227/n/na75f09dcb315#fa04b198-a629-4063-8e90-55778d00991e

3ヶ月で何をやっていたか

入社してから 2~3 週間は、ドメイン知識のキャッチアップのため、軽微な修正や既存機能の追加/改修等を実装しておりました。その後、既存機能をフルスクラッチ[2]で改変し作り直すといったタスクを任して頂き、現在はOffers及び、別の新規 PJ のタスクをこなす日々です。

ちなみに、既存機能のリニューアルについては先日リリースされておりまして、一言で説明すると 友達招待機能[3]です。

招待プログラムTop

入社してからのタスクとしては一番大きい粒度だったため最初は進め方に不安もありましたが、社員の皆さんの支えあってリリースできました。

上記の友達招待機能を実装するにあたり、気付きがあったのでまとめておきます。

働き方等の違い Before/After

overflowと前職の Before/After は下記です。


前職

  • エンジニア : 約 25 名
  • サービス : 8 つ
  • スプリント : 1 週間
  • デイリー : 毎日
  • 大きなタスク : 分割しメンバー全員
  • ドキュメント : DocBase
  • タスク管理 : Zenhub
  • 働き方 : フルリモート

overflow

  • エンジニア : 7 名[4]
  • サービス : 3 つ
  • スプリント : 2 週間単位
  • デイリー : 月曜 and 金曜
  • 大きなタスク : 基本的に 1 人 1 機能
  • ドキュメント : Notion
  • タスク管理 : Jira
  • 働き方 : フルリモート

エンジニア組織に関する変化や気づきは下記です。(組織全般については Note に書きました)

  • デイリーが毎日ないので実装時間確保しやすい
  • 大きな機能を 1 人 1 機能担当
  • Notion や Jira により、仕様や要件、過去の実装がドキュメント化されており情報が負いやすい
  • テスト(RSpec)が本当に大切(再認識)

いくつか詳細を記載します。

大きな機能を1人1機能担当

前職は過去 1 週間のスプリントのベロシティを振り返りつつ、ストーリーポイント総数を決定し、
デイリースクラムで進捗確認を行っていましたが、overflowでは記述の通りデイリーがないので
性善説で詰まった時や確認の時に随時 MTG を入れるスタイルです。(2022 年 7 月現在)

前職として比較して最も驚いたのは、大きめな機能に関しては基本的に 1 人[5]で実装を進行していく点です。前職では大きな機能を

  1. 細かく分割
  2. 見積もりをつける
  3. メンバーにアサイン
  4. 実装

といった流れでしたので、当初、上記の友達招待機能を任せてもらったときは不安半分ワクワク半分でした。

1 人 1 機能のメリットとしては、カニバったり、分割でタスクをブロックされることがないので進行しやすい
デメリットとしては、ドメイン知識が他メンバーに共有されづらい(そこは Notion や JIRA 等でカバー)

があるのかなと個人的には考えています。

Notion や Jiraにより、仕様や要件、過去の実装がドキュメント化されており助かる

前述した note にも少し記載しておりますが、overflowはドキュメントがとても豊富で、情報の透明性が高いです。(前職だと見られないドキュメントがあったり、SlackやPRがドキュメント化していました...)

エンジニアに関しては、大きな機能の開発する際には、TechSpec[6]を作成し、
要件をどう満たすかの詳細設計を詳しく記載します。ドキュメントがなく、コードがドキュメントになっているといったケースはよくあるケースかもしれませんが、過去の実装や要件が TechSpec にまとまっており、Notion を検索すればコードの経緯が汲み取ることも多かったです。

今回は既存機能をリニューアルするということもあり、as is/to be を理解する上で TechSpec は大いに役立ちました。

コード変更に応じてドキュメントを更新するのはコスト大なので、あくまで大枠の意図を抑えておくのが better かと個人的には解釈しています。将来、自分含め誰かが見た時に経緯をわかるように書いておくことが大事ですね。

テスト(RSpec)が本当に大切

テストが大事なのは言わずもがなですが、今回の様にドメイン知識がない中での既存機能をリニューアルとなると、テストの重要性を再認識しました。

実装後、仕様変更により、機能は随時変化していくものですが、
今回実装した友達招待機能も同様に、細かいところで TechSpec とはズレが生じている部分がありました。
そのため、まずはこけているテストから機能の Diff を読み解き、着実に機能追加をしていきました。

1 変更が、おもわぬ他のコードの破壊につながることもありますが
変更後に単体テストが通っているのでロジックとしては正[7] といった解釈が出来るのはありがたいですよね。

まずはテストを書いていき、機能を拡充させる TDD を行っていきたいです。

まとめ

メガベンチャーからスタートアップに転職して 3 ヶ月経過しましたが、これから組織が大きくなっていくタイミングで join し、日々刺激を受けつつ仕事が出来るのは楽しい限りです!

関連記事

https://zenn.dev/offers/articles/20220421-rspec-merit-and-demerit-and-tips
https://zenn.dev/offers/articles/20220526-rspec-tips-description

脚注
  1. なぜ転職したかについてがメインです。 ↩︎

  2. とはいったものの、同じような機能やページは流用もしておりますが... ↩︎

  3. もし、このリンクから Offers にご登録頂いたとしても、筆者にはアフィリエイトは発生しませんので、ご安心ください ↩︎

  4. 副業メンバーは除いておりますが多数いらっしゃいます ↩︎

  5. 語弊がないように補足すると、デザイン、仕様、コードレビューなど実装するにあたり他メンバーと協力しあって実装していますよ!! ↩︎

  6. 技術的仕様書(Technical Specifications) ↩︎

  7. もちろんそれ以外も確認しますが ↩︎

Offers Tech Blog

Discussion