エンジニアの末次です。2024年3月現在、株式会社エンペイでは、以下の3プロダクトを提供しています。

また、エンジニアリソースの都合上、koufuri+とenpayウォレットに関しては1つの開発チームで保守・エンハンスを行っています。

1チームで1つのプロダクトを作る場合のパフォーマンスを100としたとき、1チームで2つのプロダクトを作る場合のパフォーマンスは50:50になるのでしょうか？

おそらくそうはならず、より悪化すると考えられます。理由は以下3つです。

1スプリント(弊チームでは2週間)あたりの業務時間を80時間とすると、デイリースクラム(15分×10日=150分)、バックログリファインメント、スプリントプランニング、レトロスペクティブ(各60分=180分)で合計330分(=5.5時間)は少なくとも会議を行っているので、実際の開発時間は74.5時間となります。(実際には突発的なレビューなどもっと多くの会議を行っているでしょう)

2プロダクトを担当する場合、1プロダクトあたりの開発時間は単純計算で40時間・40時間となり、それぞれに対して5.5時間の会議が行われるとすると、開発に使える時間は34.5時間ずつとなり、74.5時間→33.5時間ということで53.9%(半分以上)減っています。

それぞれの会議を2プロダクト合同で行えば作業時間の減少を抑えられますが、1プロダクトにかける議論の量が減ることとトレードオフとなります。

「認知負荷」とは、何か作業をしたり学習したりするときの人間の脳に対する負荷(ストレス)で、以下3つの種類があると言われています。

課題外在的・内在的負荷をできるだけ少なくし、学習関連負荷を適宜与えていくことで学習効率・作業効率が上がっていくと考えられますが、担当するプロダクトの数が増えるとその分メンテ対象のコード、ドキュメント、キャッチアップすべき言語、フレームワークなどの数が増加するので課題内在的負荷が高まり、学習効率、作業効率が落ちると考えられます。

「作業Aから作業Bに切り替えるときに、作業Aの情報を一旦どこかに退避させて、さらに作業Bの情報をどこからか引っ張ってきて、作業Bに取り掛かれる状態にすること」をコンテキストスイッチと呼んだりします。コンテキストスイッチをするたびに余計な作業が発生して時間を食いますし、作業内容の思い出しのために先述した課題外在的負荷などもかかってくるため、それによる疲労感・ストレスでさらに作業効率が落ちていくと考えられます。

同じコンテキストスイッチでも、例えば「プロダクトAのバックエンド→プロダクトBのバックエンド(同じ言語)」というコンテキストスイッチなら、「プロダクトAのバックエンド→プロダクトBのフロントエンド」というスイッチよりも負荷が低いと考えられます。逆に同じプロダクト内でも、「バックエンド開発→問い合わせ対応」のような違う性質の業務にスイッチした場合は負荷が高くなると考えられます。

2プロダクト同時開発を始めたタイミングでチームメンバーも変わっているので単純な比較はできませんが、1つのチームで1つのプロダクトを見ていた時代と、2つのプロダクトを見ていた時代とでスプリントごとのベロシティを比べてみたいと思います。

上記を整理すると、

となりました。2プロダクト時代前半は開発プロセスの整備やキャッチアップなどでかなり低調なパフォーマンスでしたが、日々の改善活動や学習によって順調に開発が進むようになりました。

ここからは複数プロダクトを見ていくにあたって工夫したことや、もっとこうしておけばよかったなと思うことをまとめていこうと思います。

それぞれのプロダクトごとにPdMがいるので、その2人でこのスプリントはどちらのプロダクトをメインで進めるか調整してもらい、それをもとにスプリントプランニングを行いました。それにより、1スプリント内で2プロダクト両方を触ったり、プロダクト間を行き来する頻度が少なくなり、コンテキストスイッチ回数を減らせました。この取り組みの効果を定量計測はできていませんが、レトロスペクティブのKPTなどでコンテキストスイッチ関連のProblemが出ることはほぼなかったので一定の効果はあったと思います。

「スプリントゴールを達成するためには、x日目の時点でここまでできてたら順調と言えるよね。そうでなかった場合は優先度が低いこの案件は無視して、スプリントゴールに関わる案件だけは全員で力を合わせて完了させよう」みたいな会話をスプリントプランニングで行って、その2週間をどう過ごすかをチームで合意するようにしました。

当初「複数プロダクト見るのって大変だから、スプリントゴールさえ達成できればスプリントバックログのタスクを全消化できなくても仕方ないよね」という雰囲気になってしまっていたのを、「自分たちでコミットしたものだから全消化できないのは恥ずかしいことだよね」という風に捉えるようにしました。スプリントゴールを達成することはもちろん最重要ですが、パフォーマンスが低い状況が続くとプロダクトオーナー的には開発チームに多くを望めなくなってしまい(例.「本当は今スプリントでやりたいことがもっとあるけど、この開発チームじゃ無理だから後回しにして、スプリントゴールの難易度を下げよう」)、それは不健全だと思ったため、スプリントバックログに対する認識を統一できたのは良かったです。

フルリモートかつ各自の得意領域がはっきりしていたので、それぞれが持つタスクを単独で進めて、デイリースクラム以外は全く喋らずにその日一日が終わるようなことも多かったです。最近は毎日15時ぐらいにゆるくお互いの状況共有と困りごとの相談をする時間を設けてコミュニケーションの頻度を増やすようにしましたが、ゆくゆくはこの会を廃止してオンデマンドで相談し合えるようにはしていきたいです。

担当者を特に決めずに全員でエラーログや問い合わせを見るようにしようとした結果、こぼれ落ちていて初動の対応が遅れるケースも少しありました。ここは開発進捗の安定化のために犠牲にしてしまった部分です。

1プロダクト時代は、リリースした機能の効果測定を行ったり、プロダクトディスカバリーについて書かれた書籍を輪読したりなど、「もっとプロダクトを良くしていくためにできることはないか？」という視点で色々活動していましたが、複数プロダクト時代はそういう活動をする工数的・心理的余裕はなく、社内外注チームっぽくなっていたかもしれません。

本記事をざっくりまとめると以下のとおりです。

1チームで複数プロダクトを保守することを検討している組織の方、そのようなチームのリーダーをやることになった方に、本記事を参考してもらえると嬉しいです。