STORES 株式会社でエンジニアリングマネージャをしている @morihirok です。
私がマネジメントをしているエンジニアチームは主に STORES ネットショップと STORES レジというふたつのプロダクトを開発しています。 私たちは2022年までフロントエンドとバックエンド、クラウドインフラで別のチームとなっていましたが、2023年に技術横断で1つの価値を作り出すフィーチャーチームへと変わりました。
この記事ではどのような課題感から組織を変えることを決めたのか、変えるためにどんなことをしたのか、変えた結果どうなったのか、についてお話しします。
技術別チームができるまで
STORES ネットショップ はもとはブラケット株式会社というベンチャーが開発・運営していたサービスでした。少数精鋭のチームですべてを開発・運営し、単体での黒字経営ができていました。
2018 年に STORES 株式会社（の前身である hey 株式会社）の1事業としてより事業拡大を目指すこととなり、システムとしても事業拡大に耐えられる体制を整えることが急務となりました。
この時解決しなければならなかった大きな課題がふたつあり、ひとつは事業拡大とシステム監査に耐えられるクラウドインフラの構築、もうひとつはレガシー化していたフロントエンドの刷新でした。
これを解決すべく、クラウドインフラを構成していくチーム、フロントエンドの刷新・開発をするチーム、バックエンドを開発するチームに分かれました。 この判断のおかげで、大きく拡大した事業規模にもシステム監査にも耐えられるクラウドインフラとその運用体制ができましたし、フロントエンドも Nuxt によって刷新されました。
組織が抱えていた課題感
一方で、技術別組織になっていることによっていくつかの課題も抱えるようになってきました。 具体的にいくつかご紹介します。
開発チーム間のコミュニケーションコストがかかる問題
例えばバックエンドシステムでファイルアップロード機能を作るために S3 バケットが必要だとなった場合に、チームが別なのでクラウドインフラのチームに依頼をして作らなければなりませんでした。クラウドインフラのチームで多くの業務を抱えているときにはすぐに対応できないこともあり、機能開発のブロッカーになってしまうこともありました。
フロントエンドとバックエンドも別のチームだったので、バックエンドの機能開発の速度がフロントエンドチームのブロッカーになってしまったり、もっと悪い状況では優先度が高い開発アイテムがバックエンドのものしかなくフロントエンドチームが暇になってしまう、ということもありました。
また、プロダクトマネージャもフロントエンドチームとバックエンドチームの責務を理解してコミュニケーションする必要がありました。 しかも、フロントエンドの課題だと思って相談しても「そこは Rails のテンプレートエンジンで配信されてる HTML なんでフロントエンドチームじゃなくてバックエンドチームですね」みたいなコミュニケーションが発生するなどし、プロダクトマネージャにとても高い認知コストをかけてしまっていました。
エンジニアひとりひとりがやりたいことをやりにくい問題
例えばとあるバックエンドエンジニアがフロントエンドを書いてみたいと思っても、チームが分かれているためやりにくいという状況になっていました。 もちろん STORES 社の全リポジトリはすべてのエンジニアが閲覧可能で、誰でも自由に Pull Request を投げて良いのですが、とはいえチームが分かれていることによる心理的なハードルがあることからチームを跨いだ積極的なやり取りは起きていませんでした。
普段触れられる技術が限られていることが、エンジニア個人の成長機会を狭めていたと思っており、メンバーとの1on1にて「本当はクラウドインフラやフロントエンドにも興味がある、だけどやる機会がない」という意見を聞くことも少なくありませんでした。
システムが局所最適に陥ってしまう問題
技術でチームが分かれていることによって、課題を解く際に自分の得意な技術領域で解決しようとしてしまうケースが多々見られました。
本当はバックエンドで計算した方が筋が良いものであっても、バックエンドに開発してもらうのを待つよりはフロントエンドで処理してしまおうということでフロントエンドに複雑な計算処理が書かれたり、AWS のフルマネージドなサービスを使えば運用コストがかからないようなものを頑張ってバックエンドで開発したり、アプリケーションのロジックとしてすぐに実装できるようなものをクラウドインフラで頑張ってしまったり、ということが起きていました。
何より、CPOの井出さんがブログで語っているように これからの STORES は複数プロダクトを連携しより複雑度の高い Web システムを提供していく事業になっていきます。 特定技術ではなく Web システムとして広い視野で開発できるエンジニアチームにしていくことは事業成長にとって非常に重要であろうと判断し、技術別チームをやめていわゆるフィーチャーチームへの変革を進めました。
フィーチャーチームにするためおこなったこと
段階的にチームをひとつにする
私たちのチームはスクラムを採用していましたが、フロントエンドチームとバックエンドチームでそれぞれスクラムをしているという状況でした。これをひとつにまとめるのが最初のステップでした。
はじめのうちはメンバーから「スプリントプランニングで突っ込んだ話をするとどうしても技術に特化した話になってしまい置いてけぼりになるメンバーが出てしまう、それが申し訳ない気持ちになる」という振り返りが出ていましたが、これは仕方ないことだとして一定我慢しながら細かいところまで踏み込んでプランニングしていこうということを話していきました。 次第に「実はこういうAPIがあったらフロントエンドの処理は楽になるんです」とか「それくらいだったらバックエンドで計算した方が早いしあるべき姿としても良いと思います」といった意見が出るようになっていき、スキーマを介したやり取りからチームとしてより素早くより良いシステムを開発するための意見が活発に出るようになってきました。
また、プランニングの場でそれぞれの技術領域の Good First Issue の話もされるようになり、これまでバックエンドを開発したことのなかったメンバーでもバックエンドのリポジトリに Pull Request を投げたり、その逆のケースも多く出てきました。
私自身は STORES ではバックエンドをメインで開発してきたのですが、フロントエンド開発までおこなうことによってこれまでよりも Web システムとしてトータルで良い体験を提供する目線が強くなった実感がありました。
ペアプロ・モブプロで難しい issue に挑戦する
もともと私たちのチームはペアプロ・モブプロを好んで使うチームではあったのですが、それはフィーチャーチームになるためにも好影響でした。
その事例のひとつとして、こんな例があります。
チームをひとつにしてから数ヶ月、ちょっとした API の開発であればだれでもできるようになり、バックエンドのリポジトリへのいろんなメンバーからのコミットは盛んになってきました。一方でフロントエンドのリポジトリへのコミットはそれほど盛んになっていないのは insight を見ても明らか、という課題も見えてきました。
私自身もフロントエンドを開発するようになった中で、こうなっている原因もいくつか推測できていました。そのうちのひとつは、私たちのフロントエンドが Nuxt2 から Nuxt3 の移行過渡期であることでした。 私たちのチームのフロントエンドは Nuxt Bridge で開発されており、絶賛 Nuxt2 から Nuxt3 への移行中です。つまり、コードベースには Nuxt3 の API と Nuxt2 のAPI が混在している状況になっており、これまで Nuxt を利用した開発をしたことがないメンバーにとっては既存のコードベースを参考にしながら開発をしても「すみません、それは Nuxt2 の API でして、Nuxt3 の API を使って書き換えて欲しいのです」というコミュニケーションが発生するなどハードルの高い状況になっていました。 また、シンプルにフロントエンドのエコシステムやツールチェインに慣れてないエンジニアも多く、いくつかの障壁があることは明らかでした。
幸い私たちのチームには Nuxt Bridge のコミッターである wattanx をはじめ Nuxt に造詣が深いメンバーが揃っているため、彼らからペアプロ・モブプロを通じてレクチャーを受けることができました。 また、スプリント内で各々が実際に Nuxt3 の API に書き換える issue を担当し、理解を深めていきました。 次第に各メンバーのフロントエンドへのコミット量も増加してきました。
このようにチームにとって難しい技術課題があったときはペアプロ・モブプロを通じて技術力の底上げを行い、それぞれの技術領域の知見が深まってきました。スプリントプランニングのタイミングで「これはちょっと難しくて面白い課題だから、知見の共有も兼ねてモブプロする issue にしよう」と言った会話も生まれるようになり、技術領域を跨いでチームの技術力が高める空気感が醸成されていきました。
よりスモールチームにする
技術別チームのときはフロントエンドとバックエンドを開発するにあたって最低4人メンバーが必要でした。1人で開発すると周りのメンバーがコンテキストに沿ったコードレビューをするのに時間がかかってしまうため、素早い開発のためには最低2人は必要、しかもそれがフロントエンドとバックエンドそれぞれに必要、という形になっており、意思決定を行う単位であるチームが大きくなりがちでした。
全員がある程度フロントエンドもバックエンドも開発できるようになってきたことで、この制約も無くなりました。3人のチーム内でも十分に素早く質の高い開発が回せるようになり、少人数の分より素早い意思決定ができるようになりました。 少人数であるが故にメンバーひとりひとりの担当領域が広がり、いろんな挑戦をしてもらうことができるようになりました。 少人数でチームが組めるようになったことで単純にチーム数が増え、取り組める課題の量も増えました。
また、この頃にクラウドインフラのチームメンバーもそれぞれアプリケーション開発のチームに合流してもらい、クラウドインフラについても専任チームを置かず各チームで必要に応じて担当することを目指す組織にしました。 とはいえ、一定の堅牢性が求められる私たちのクラウドインフラを、いきなりこれまで担当したことない人にお任せするというのも事業リスクが大きいです。そのため、クラウドインフラに関しては将来的に解散することを目的としたワーキンググループを組み、その中で将来的に各チームで担当できるようになるロードマップを組み実現していくという座組にしました。
このように、1 年かけてチームをフィーチャーチームへと変革していきました。
フィーチャーチームになってから
組織を変えてから、良い影響を実感できています。
ちょっとしたクラウドインフラの変更であれば各メンバーで Terraform を書いて変更したり、気になったことがあれば各メンバーでフロントエンドもバックエンドも改善を加えられるようになったことで、開発速度が早くなりました。
プロダクトマネージャも開発チームの都合を考えずに優先的に解きたいイシューをバックログに積めるようになり、顧客課題に向き合うことに時間を使えるようになりました。
各々のエンジニアが自分の興味をベースにやりたいことをより実現できるようになり、マネージャとしても提供できるキャリアの幅が増えました。
何より一番大きいのがチーム全体に Web システムとしてトータルで良いものを作る目線が生まれたことだと思っています。
ストアーズはECの会社、ではない｜naoko でも語られているように、STORES は複数のプロダクトを提供しており、それらの連携によって独自の価値を生み出していく会社です。
その実現には利用している言語やフレームワーク、ミドルウェアの知識はもちろんのこと、Web の知識や分散システムの知見をもとに、より Web システムとしてトータルで考慮することがエンジニアに求められます。 フィーチャーチームとして技術領域を横断して課題解決する体制にすることによって、これまでよりもより難しい課題に挑戦できている実感を持っています。
これからもより幅広い視野を持ちながら引き続き縦に技を掘り、高い技術力によって深い課題解決ができるチームにしていきたいと考えています。
私たちが解いてきた STORES の技術課題についてまだまだご紹介できていないことがたくさんあるのですが、それはまた別の機会にお話しさせてください。
今すぐ興味がある！という方はぜひカジュアルにいろいろお話しさせてください！
