- はじめに
- 一般論: 1チームで2つのプロダクト見るってどうなの？
- 作業時間のオーバーヘッド
- 認知負荷が高まる
- コンテキストスイッチが生じる
- 結果、どうだったか
- 工夫したこと・反省点など
- ⭕工夫1: スプリントごとにどちらのプロダクトに注力するか決めた
- ⭕工夫2: スプリントゴールの達成イメージを持つようにした
- ⭕工夫3: スプリントバックログについての認識を合わせた
- 😅反省1: ペアプロ・モブプロや相談の頻度が少なかった
- 😅反省2: 問い合わせ担当をきっちり決めるべきだった
- 😅反省3: プロダクト愛の希薄化
- まとめ
はじめに
エンジニアの末次です。2024年3月現在、株式会社エンペイでは、以下の3プロダクトを提供しています。
また、エンジニアリソースの都合上、koufuri+とenpayウォレットに関しては1つの開発チームで保守・エンハンスを行っています。
一般論: 1チームで2つのプロダクト見るってどうなの？
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を参照せよと言われたが、その資料Aがどこにあるかわからずイライラする
- 課題内在的負荷: 学習対象そのものの複雑さ
- 例. 足し算引き算に比べたら、確率や行列の計算のほうが難しい
- 学習関連負荷: 学習目標の達成のための認知活動により生じる負荷
- 例. 基礎問題で得た知識を使って応用問題を解く。大変だが学びは多い
課題外在的・内在的負荷をできるだけ少なくし、学習関連負荷を適宜与えていくことで学習効率・作業効率が上がっていくと考えられますが、担当するプロダクトの数が増えるとその分メンテ対象のコード、ドキュメント、キャッチアップすべき言語、フレームワークなどの数が増加するので課題内在的負荷が高まり、学習効率、作業効率が落ちると考えられます。
コンテキストスイッチが生じる
「作業Aから作業Bに切り替えるときに、作業Aの情報を一旦どこかに退避させて、さらに作業Bの情報をどこからか引っ張ってきて、作業Bに取り掛かれる状態にすること」をコンテキストスイッチと呼んだりします。コンテキストスイッチをするたびに余計な作業が発生して時間を食いますし、作業内容の思い出しのために先述した課題外在的負荷などもかかってくるため、それによる疲労感・ストレスでさらに作業効率が落ちていくと考えられます。
同じコンテキストスイッチでも、例えば「プロダクトAのバックエンド→プロダクトBのバックエンド(同じ言語)」というコンテキストスイッチなら、「プロダクトAのバックエンド→プロダクトBのフロントエンド」というスイッチよりも負荷が低いと考えられます。逆に同じプロダクト内でも、「バックエンド開発→問い合わせ対応」のような違う性質の業務にスイッチした場合は負荷が高くなると考えられます。
結果、どうだったか
2プロダクト同時開発を始めたタイミングでチームメンバーも変わっているので単純な比較はできませんが、1つのチームで1つのプロダクトを見ていた時代と、2つのプロダクトを見ていた時代とでスプリントごとのベロシティを比べてみたいと思います。
上記を整理すると、
1プロダクト時代(5スプリント)のベロシティ平均値 | 26.7pt |
2プロダクト時代前半(5スプリント)のベロシティ平均値 | 10.5pt |
2プロダクト時代後半(5スプリント)のベロシティ平均値 | 31.3pt |
となりました。2プロダクト時代前半は開発プロセスの整備やキャッチアップなどでかなり低調なパフォーマンスでしたが、日々の改善活動や学習によって順調に開発が進むようになりました。
工夫したこと・反省点など
ここからは複数プロダクトを見ていくにあたって工夫したことや、もっとこうしておけばよかったなと思うことをまとめていこうと思います。
⭕工夫1: スプリントごとにどちらのプロダクトに注力するか決めた
それぞれのプロダクトごとにPdMがいるので、その2人でこのスプリントはどちらのプロダクトをメインで進めるか調整してもらい、それをもとにスプリントプランニングを行いました。それにより、1スプリント内で2プロダクト両方を触ったり、プロダクト間を行き来する頻度が少なくなり、コンテキストスイッチ回数を減らせました。この取り組みの効果を定量計測はできていませんが、レトロスペクティブのKPTなどでコンテキストスイッチ関連のProblemが出ることはほぼなかったので一定の効果はあったと思います。
⭕工夫2: スプリントゴールの達成イメージを持つようにした
「スプリントゴールを達成するためには、x日目の時点でここまでできてたら順調と言えるよね。そうでなかった場合は優先度が低いこの案件は無視して、スプリントゴールに関わる案件だけは全員で力を合わせて完了させよう」みたいな会話をスプリントプランニングで行って、その2週間をどう過ごすかをチームで合意するようにしました。
⭕工夫3: スプリントバックログについての認識を合わせた
当初「複数プロダクト見るのって大変だから、スプリントゴールさえ達成できればスプリントバックログのタスクを全消化できなくても仕方ないよね」という雰囲気になってしまっていたのを、「自分たちでコミットしたものだから全消化できないのは恥ずかしいことだよね」という風に捉えるようにしました。スプリントゴールを達成することはもちろん最重要ですが、パフォーマンスが低い状況が続くとプロダクトオーナー的には開発チームに多くを望めなくなってしまい(例.「本当は今スプリントでやりたいことがもっとあるけど、この開発チームじゃ無理だから後回しにして、スプリントゴールの難易度を下げよう」)、それは不健全だと思ったため、スプリントバックログに対する認識を統一できたのは良かったです。
😅反省1: ペアプロ・モブプロや相談の頻度が少なかった
フルリモートかつ各自の得意領域がはっきりしていたので、それぞれが持つタスクを単独で進めて、デイリースクラム以外は全く喋らずにその日一日が終わるようなことも多かったです。最近は毎日15時ぐらいにゆるくお互いの状況共有と困りごとの相談をする時間を設けてコミュニケーションの頻度を増やすようにしましたが、ゆくゆくはこの会を廃止してオンデマンドで相談し合えるようにはしていきたいです。
😅反省2: 問い合わせ担当をきっちり決めるべきだった
担当者を特に決めずに全員でエラーログや問い合わせを見るようにしようとした結果、こぼれ落ちていて初動の対応が遅れるケースも少しありました。ここは開発進捗の安定化のために犠牲にしてしまった部分です。
😅反省3: プロダクト愛の希薄化
1プロダクト時代は、リリースした機能の効果測定を行ったり、プロダクトディスカバリーについて書かれた書籍を輪読したりなど、「もっとプロダクトを良くしていくためにできることはないか？」という視点で色々活動していましたが、複数プロダクト時代はそういう活動をする工数的・心理的余裕はなく、社内外注チームっぽくなっていたかもしれません。
まとめ
本記事をざっくりまとめると以下のとおりです。
- 複数プロダクト開発、最初は大変。学習が進むことで無意識化でこなせる作業も増えて、ある程度はパフォーマンス上がっていく
- 一方で、バックログの案件を超えて、プロダクトを良くするための活動していこうという気持ちは薄れるかも。1つのプロダクトに時間をかけるともう1つのプロダクトがおざなりになってしまうことにもなる。その点でPdMの負荷や孤独感は増してしまうかも
- 現時点の個人的な結論: 1チームで複数プロダクトを持つことは避けれるなら避けたほうが良い。難しいができないわけではない
1チームで複数プロダクトを保守することを検討している組織の方、そのようなチームのリーダーをやることになった方に、本記事を参考してもらえると嬉しいです。