はじめに

こんにちは。 @nannanyです。

この記事はSTORES Advent Calendar 2024の12/20の記事です。

2024年の4月より、STORES 決済のバックエンド開発を離れ、STORES内の別プロダクト開発に従事してきました。

現場移行に伴ってやったこと、変えたこと、感想などを綴り、STORES で働くイメージ喚起につながればと思いこの記事を執筆しました。

経緯

STORES ではネットショップ・予約システム・キャッシュレス決済・POSレジ・ブランドアプリ・ロイヤリティ・データ分析、といった複数のプロダクトを運営しています。私自身は2021年の5月から STORES 決済のチームに在籍していました。

それが、2024年の4月から、別の現場で新プロダクトを作成することになりました。

STORES は複数のスタートアップの合併によって現在に至っています(STORES 決済は元々は Coiney で生み出されたプロダクト)。

STORES 決済と4月の現場ではそれぞれ異なったカルチャーがあると感じていました。
かなり大雑把に表現すると、STORES 決済は丁寧、新しい現場はスピーディ、という感覚でした。(新しい現場は予約、ネットショップといったRailsを利用したチームのカルチャーに近い)

また、私自身のこれまでの経験は、前職のSIerと STORES 決済でのJavaを使ったバックエンドアプリケーションの開発を主に行ってきましたが、4月からの開発はRubyまたはGoを用いることが濃厚でした(結局はメインでGoを使うことにした)。

そのため、異動を告げられた際は新しいことをやる高揚感と、異なる技術・カルチャーでうまくやっていけるかという不安が半分ずつありました。

意識していたこと

異動に際して、これまでのエンジニア経験の中で身につけたことを以て、信頼を得られるように努めました。

具体的には、

Pull Requestのレビューはなるべく早く行う
Meetingの前には意見を整理するなり、準備しておく
(Scrumの)Sprint Reviewで見せるものは一回模擬しておく

といった、やろうと思えばできるけど後回しにしたり、サボったりしがちなことは極力やるようにしました。

変えたこと

一方で、これまで行っていた行動から変えたものもありました。

Pull Request レビューのメリハリはつけるようにしました。
STORES 決済の時は本番運用していることをもあってか、コードのレビューを結構丁寧にやっていました。時にはPull Requestを自分の環境で動作確認する、といったこともしていました。
ただ、新規開発している分にはこの慎重さがPull Requestのマージを遅らせてしまうだけな感覚があったので、DBのテーブルスキーマなどのリリース後に変えにくい部分の意思決定などは時間をかけてみる、アプリの挙動部分などはサッと確認してテストが通っていればapproveをつける、といったメリハリをつけるようにしました。

また、これまではバックエンド・インフラのタスクを中心に仕事をすることが多かったですが、そういった区分けはせず、Sprint Goalを叶えることを優先しフロントエンドのタスクもやることも増えました。

感想

最後に異動してみての感想です。

まず、技術スタックの違いに関してです。これはコードを書くという点ではあまり問題なかったと感じています。Copilot を使って開発できる時代においては、大部分をAIの導きによって解決してくれます。
ただ、コードを書くということ以外の、リポジトリ全体の方針・規約を決めるといったことをする時には、該当の技術をちゃんと理解、把握しておく必要があったなと今振り返って思います。
Goのスタックトレースを出さずに開発を進める、Goの慣習に沿わない変数の命名をしてしまう(userIDではなくuserIdにしてしまう)などを犯していたので、これらは初期に整備しておくべきでした。

カルチャーの違いについては、正確に素早くアプリを市場に届けたいという心意気はどの現場でも同じで、失敗した時のリスクを鑑みてプロセスを変えているのだと考えています。そのため、本質的に目指すところは同じであり、私自身の根本的な部分を変えて取り組んだということはありませんでした。
つまり、カルチャーの違いについての不安は杞憂でした。

これはうまくやれたということではなく、もっと良いエンジニアを目指すにあたってはカルチャーの違いとは関係なく、誠実に自分の特性と向き合う必要があると感じたということです。
例えば、私は自分自身を慎重な方だと自認していますが、何か機能をリリースする時に必要以上に確認したり、無意味に時間を置いたりしてしまうことがあります。これでは慎重さというより、リリースすることへの臆病な気持ちを慎重という言葉で覆い隠してしまっています。

そのような弱さと向き合い、より良いエンジニアとなって社会に価値を届けていきたいなと思った一年でした。