STORES Product Blog

こだわりを持ったお商売を支える「STORES」のテクノロジー部門のメンバーによるブログです。

STORESで異動した話

STORESで異動した話
* 本記事は STORES Advent Calendar 2023 25日目の記事です

こんにちは、STORES でバックエンドエンジニアをやっている id:ahogappa です。

今年の10月からブランドアプリチームからネットショップチームへ異動したのですが、同じ STORES でもこんなに違うのか!となったのでその記事を書いてみようと思います。

はじめに

STORES では現在、プロダクトごとに部門が分かれており、部門によってプロダクトの大きさも違えば開発組織の大きさも違います。 他にもいくつかプロダクトごとに部門はありますが、今回私が所属した二つの組織について、実感した違いについて様々な角度で比較してみたいと思います。

規模

ブランドアプリチームではモバイルエンジニアも含めたチーム全員で5人ほどの規模で開発をしていました。

ネットショップチームでは多くのエンジニアが在籍しているので、ラインと呼ばれる単位で人員が分かれて異なる機能開発などを行います。それぞれのラインには5~7人ほどのエンジニアがいます。ライン自体も5ライン存在しています。

イベント

ブランドアプリチームは、スクラムを採用していました。スクラムに沿ったイベントとして、

  • 朝会
  • リファイメント
  • 計画

これら三つのイベントを実施していました。また基本的にオンラインでの仕事ですが、計画は二週間に一回オフラインで集まって行う形でした。

ネットショップチームのイベント内容はラインごとに異なりますが、私の所属するラインはスクラムではなくなり、

  • 昼会
  • 振り返り

を一週間の間に繰り返しています。

またネットショップ部門では毎週各ラインから1名選出された担当者が、日々のサービス運用に関わるissueに対応する仕組みがあります。運用担当になればその週は毎日、運用朝会に参加して、その日は運用をメインに仕事をしていくことになります。 さらに大改善デーと称して、事業目標以外で日々改善していきたいコードをリファクタリングするイベントも開催されています。 勤務形態もほぼオンラインのみとなり、オフラインで集まったのは数回しかありません。

デプロイ

ブランドアプリチームとネットショップチームではそもそもブランチの戦略が異なり、以下のような違いがありました。

イベント ブランドアプリチーム ネットショップチーム
戦略 git flow github flow
デプロイ マージ後自動的にデプロイ マージ後すぐに手動デプロイ

ブランドアプリチームではgit flowを採用しており、releaseブランチへのマージは朝会のイベントとして行なっていました。releaseブランチにマージされると自動的にデプロイされる仕組みになっています。朝会で行う関係上デプロイの頻度は1日1回(もちろん緊急時はその限りではない)でした。

デプロイは日替わりのメンバーで、デプロイ前にマージされているPRの内容を確認して、Staging環境で動作確認をして問題なければデプロイという流れです。またブランドアプリはモバイルアプリとの連携があるため、実際にスマホを操作しながらチェックしていました。特にPush通知回りの変更があった時は入念にチェックしていました。 朝会でマージされたコードの内容を把握できるため、知らないコードが入っていることがあまりありませんでした。

ネットショップチームではgithub flowを採用しており、PRをマージしたらすぐに手動デプロイする開発ルールで行っています。デプロイはSlackのスラッシュコマンドで行うことができ、マージ後すぐに本番環境に反映されてます。多い日だと1日に十数回デプロイされています。 エンジニアの対応から本番への反映がとても早く、新機能や不具合の修正が素早く適用されています。

コミュニケーション

ブランドアプリチームでは基本的にはmeetやSlack ハドルミーティングでやりとりすることが多かったです。またスクラムの計画で集まる時にはランチを食べに行ったりしてコミュニケーションを取っていました。

ネットショップチームではいくつかのラインでDiscordを使っています。 基本的にはオンラインでの仕事ですが、Discordには常に誰かがいるので偶然の会話が発生したり、コードについてさっと聞ける環境があります。

アーキテクチャ

サーバはRails、インフラはAWSとほとんど同じでしたが、大きく異なるのはDBがMySQLからMongoDBになったことでしょうか。 データの構造や特性も異なるほか、ORM(Mongoid)の使い勝手も違うので、異動後で一番苦労した(している)部分です。

特にORMの使い方自体が異なることに苦労していて、(例えば最近だと、User.where(created_at: ..Time.current)みたいな範囲指定ができなくて困った。)毎回「この書き方できるんだっけ...?」というのを調べながらやっています。

まとめ

STORES 社内でも開発体制や文化が様々で、異動した直後はまるで別の会社に転職したかのような気分でした。 STORES には様々なバックグラウンドの方がいらっしゃるので、それを反映しているかのような振れ幅で非常に刺激的でした。