Featureタスクをすべてモブプロで実施したらベロシティが安定した話

この記事は「Hacobell Developers Advent Calendar」ー 9日目の記事です。

はじめに

ハコベル運送手配チームの池松と申します。

ハコベル運送手配チームでは、数ヶ月前から「機能追加開発タスク(以後、Featureタスク)はすべてモブプロで進める」という方針に切り替えました。

結果として、ベロシティは以前よりも安定し、チームとしての開発体験も良くなりました。
この記事では、モブプロ化の背景と、その変化について紹介します。

1. モブプロ導入前に感じていた課題

モブプロ導入前は、一般的な「個人開発 → レビュー → 修正」という流れで開発していました。
もちろんこれは普通の進め方なのですが、以下のような問題が徐々に気になるようになってきました。

個人ごとに実装方針が微妙にズレる

仕様の複雑化や既存コードの歴史的背景もあり、「方向性は間違っていないが、思っていた実装とは違う」といったズレが発生しやすい状態でした。

また、保守性や可読性の観点で「こうしたほうが良い」と思っても、実装後にレビューで指摘する手戻りコストが大きい場合もあり、そのまま進めてしまうこともありました。

レビュー負荷が増え、スピードが安定しない

PR が 1,000 行を超えることも珍しくなく、背景知識がないケースもあったため、レビューコストは高くなりがちでした。
それによりレビューが後回しになりやすく、スプリント内でタスクが完了しないケースがありました。

属人化が進みやすい

特定メンバーしか把握していない仕様やコードが増え、「この機能はこの人しか触れない」といった状況が少しずつ生まれていました。

2. なぜ“すべての Feature をモブプロ”にしたのか

課題感はあったものの、「モブプロを全面的に導入する」というのはやや踏み込んだ選択です。
というのも、モブプロではチーム全員が同じタスクに集中するため、本来は並行して進められる複数のタスクを同時に進められず、リソース効率が下がりそうだと懸念していました。

それでも導入を決めた理由は、次のような点にメリットを感じたからです。

認識が揃った状態で開発できる

実装の背景や仕様の細かい判断を、その場で全員が理解しながら進められます。
方向性が揃うので手戻りが発生しにくく、結果的にスピードが落ちにくいです。

コードの可読性と整合性を保ちやすい

ハコベル運送手配は約10年運用されてきたプロダクトであり、長く運用されているプロダクトほど、仕様の複雑性や既存コードとの整合性が重要になります。
複数の視点でチェックできるため、品質の担保につながりました。

属人化しない

実装中に自然と知識共有されるため、「この機能はこの人しか知らない」という状況が生まれにくくなります。

レビューコストが極めて低くなる

モブで合意しながら書くため、意図の確認や議論の必要がなくなり、PRレビューにかける時間が大幅に減りました。

3. モブプロ化の結果

これは意図していなかったのですが、すべての Feature をモブプロで進めるようにした結果、チームのベロシティは以前よりも安定しました。
これにより、開発計画も圧倒的に立てやすくなりました。

グラフを見ても、明らかに波が小さくなっています。
「なぜ安定したのか？」と振り返ると、いくつか理由が整理できます。

手戻りがほぼゼロになった

実装時に方向性が揃っているため、「やり直し」や「大幅修正」がほとんど無くなりました。
これはベロシティの安定にかなり効いたと感じています。

レビュー待ち時間が無い

合意形成がモブ中に完結するので、レビューに起因する遅延がほぼ無くなりました。
レビュー文化そのものを否定するわけではありませんが、レビュー待ちによる停滞がゼロなのは開発体験としても極めて良かったです。

進め方の迷いがなくなる

迷ったときにすぐに議論できるため、「本当にこの方向でよいのか？」という迷いで手が止まることがなくなります。
この「心理的な迷いがない」というのも、安定性に寄与していると感じます。

4. もちろん課題もある

良いことばかりではなく、課題もあると感じました。

モブ時間の確保が難しい

メンバー全員が揃う時間を確保するのは簡単ではありません。
現在は「揃っていなくても参加可能なメンバーで進める」という運用を取り、
後からキャッチアップできる状態を作っています。

知識レベル差によるスピード低下

メンバ間の理解度や技術力に差があると、効率を下げる可能性もあると感じました。
我々のチームは、技術レベルが比較的近く、またそれぞれの強みを活かして補い合える関係にあったため、違和感なく進められましたが、チームメンバ次第ではうまくいかないケースもあるのではと感じました。

特定メンバへの業務集中

現在モブは主にエンジニア3名で進めており、そのなかの1名に突発的な対応が集中して差し込まれると、キャッチアップが大変になるケースがあったり、そもそもモブを開催できないケースもありました。

これらは今後の改善ポイントとして取り組んでいく予定です。

5. モブプロに向いているチーム・向いていないチーム

今回の取り組みは「運送手配開発チームでは相性が良かった」という話であり、すべての組織に当てはまるとは限りません。

特にモブプロが向いているのは、以下のようなチームだと感じています。

• プロダクトの仕様が複雑で、認識合わせの価値が高い
• 小規模のチーム（2〜3人）
• レビュー渋滞や属人化に課題を感じている
• 遠慮なく議論できる関係性がある

まとめ

Featureタスクをすべてモブプロに切り替えたことで、チームのベロシティは以前よりも目に見えて安定しました。

その理由は、

• 認識のズレがなくなる
• 手戻りが減る
• 見積もり精度が上がる
• レビューによる停滞がない
• 迷いが少ない

といった要素が積み重なった結果だと感じています。

また心理的な面でも大きくて、一人で悩み続けて辛いと思う体験が減り、日々の開発が楽しいと思えることが増えたように思います。

課題もありますが、チームとしてはモブプロのメリットが勝っているため、今後も継続していく予定です。