こんにちは、UPSIDERで請求関連の機能の開発を担当しているチームです。
この記事では、新規チームとして私たちが「なぜ」モブプログラミング（以下、モブプロ）を採用したのか、その実践にまつわる試行錯誤、そして感じた手応えを余すことなくお届けします。
1. 勢いだけでは乗り切れない---立ち上げフェーズのリアル
勢いでガッと開発して「あれ？これ誰が書いた？」「この仕様なんでこうなってるんだっけ？」と立ち止まった経験、きっとあなたにもあるはずです🙋♂️
新規プロダクトの立ち上げフェーズでは、どうしてもスピード感が優先されがちです。ところがその裏側では知識の属人化や学習の非効率といった課題が静かに積もっていきます。
私たちUPSIDER請求チームも、まさにそんなタイミングで「スピード」と「チーム全体の学習」を両立する方法を模索していた結果、行き着いたのがモブプロでした。
モブプロは1台のPCをチーム全員で操作しながら実装する手法。ペアプロの拡張版と考えるとイメージしやすいでしょう。提唱者であるWoody Zuill氏は「全員の知識をリアルタイムでコードに反映し、素早いフィードバックと学習を生む」と語っています。
詳しくはWoody Zuill氏のサイトへ
2. モブプロがもたらす3つの価値
リソース効率 vs フロー効率
聞き覚えのある方もいるかもしれませんが、モブプロのメリットを考える際に最初に出てくるのが”リソース効率”と”フロー効率”の考え方です。前者は「各人が100%稼働していること」を良しとし、後者は「市場に価値が届く速さ」に最適化します。私たちが目指したのはもちろん後者です。
「リソース効率」は一見効率的に見えますが、実際は待ち行列や手戻りが増え、リードタイムを悪化させる要因になります。一方「フロー効率」は、並列度を絞ってバッチサイズを小さくし、価値の出荷速度を上げる考え方。モブプロはこのフロー効率に大きく寄与する実践手法と言えます。
※「リソース効率の罠」はこちらの動画がわかりやすく、稼働率とスループットの逆相関をわかりやすく示していたので興味がある方は見てください
メリット1: 知識の属人化を防ぐ
モブプロでは1つの画面で同期的に開発することによって、1人の知識やスキルに依存する場面をなくし、チーム全員が設計意図や業務知識を共有した状態を作れます。これにより、属人化による待ち時間が少なくなり、タスクの取り回しもスムーズになります。
メリット2: リアルタイムレビュー
普段開発しているとPRレビュー時間に時間や労力を取られることが多々あると思いますが、モブプロではPRレビューを別枠で行う必要がなく、実装とレビューが同時進行します。これはフロー効率の最大化に大きく貢献する特徴と言えます。
メリット3: その場での学習と意思決定
モブプロでは、実装中に出てきた仕様や設計の疑問もその場で議論して即座に意思決定できるという特性もあります。それにより質問待ちの時間や後戻りなどが減り、学習サイクルが圧倒的に早くなります。
3. 私たちのモブプロ運用
モブプロ運用の基本系
私たち請求チームは「エンジニア3名＋テックリード1名」というメンバーで構成されています。私たちは今年に入ったあたりに発足しモブプロを行っていましたが、3月あたりから本格的に時間をとりモブプロを導入しました。
初めのうちは毎日11:00〜 12:00、 お昼を挟んで13:00〜 14:00の2コマが基本。Google Meet上で「ドライバー1人 + ナビゲーター2〜3人」という構成で進めています。最初の数分でこのモブで何をどこまで進めるかを再確認してから実装に取り掛かります。
ドライバーは手を動かす役、ナビゲーターは設計や仕様を口頭で誘導する役です。ドライバーは運転手、ナビゲーターは助手席でGoogle Mapを開いて道筋を教えてくれるお友達だと思ってください🚙
スクラムイベントは火曜リファインメント、水曜にレトロスペクティブとプランニングを実施。プランニングではまずスプリントゴールを決め、その達成に必須のタスクを洗い出します。この時点で、このタスクはモブ向きか非同期向きかを決めラベリングを行います。ちなみにスプリントは1週間で回してます。
モブプロタスクの選定基準
プランニングの時点でどのタスクをモブプロで行うかを選定しますが、以下のような特徴で振り分けていることが多いなという印象です。
1. モブプロ向き
スプリントゴールに直結するもの / ドメイン知識の共有が必須なもの / アーキテクチャの判断が絡むもの
2. 非同期向き
小粒で完結 / ナレッジ共有の必要が薄い / AIエージェント(Devin等)に任せられる
AIとの共進化
Cursor = 自動運転の車
Cursorは今や多くのエンジニアにとって欠かせないツールになっているかと思います。モブプロにおいてもそれは同様で、モブプロドライバーは自動運転の車に乗っているようなもので、新人がモブプロドライバーになっても操作に困ることはありません。
Devin = 夜勤エンジニア
昼間のモブで洗い出したタスクをLinearに登録 -> Devinが夜間に自動でPRを作成してくれます。
これらのAI活用は話出すとキリがないですが本記事の本筋ではないので別のブログで詳しくお話しできたらと思います。モブプロとAIも相性抜群です。
4. モブプロの実感値
モブを続けていく中で明確に見えてきた効果があります。特に私たちが感じていた実際のチームの変化はこれらです。
- レビュー時間が激減する
- 属人化がなくなった
- キャリアの成長につながる
- こまめにアーキテクチャ変更ができる
まず、みんなで実装するのでレビューはほぼ必要ない状態になりました。非同期でタスクを行っている場合はレビューの時間やコンテキストスイッチに悩まされることが多かったのでこれはとても良いと感じています。また、属人化がなくなることも大きな点です。メンバーによって得意分野が異なりますが、属人化することなく知見分散ができるので個々のキャリアの成長にも繋がっているなと感じています。
これは当社はあまり予想していなかったのですが、実装中でのアーキテクチャの違和感などを常に話合えるので、こまめにアーキテクチャの変更やあるべき姿への同意、変更ができるというのも感じています。
5. モブプロの課題
モブプロによって様々なメリットを感じつつ、一方で幾つかの課題も見えてきました。まずチーム全体のSP消化が下がっていったことです。以下のグラフは「消化SP/稼働人日」、つまり「1人日あった場合私たちのチームはどれだけのタスクをこなせるか」を表した数値になります。グラフを見ると本格的にモブを導入した3月から右肩下がりに下がっていることがわかります。モブプロは並行でタスクをこなしていたものを直列で行うようなものなのでタスク消化が減るというのは1つの直感的にわかるデメリットとして挙げられると思います。もちろん、開発の目的として「価値あるものを提供すること」が最優先なのでSP消化が全てではないですが生産性の指標の1つとして捉えることができます。
また、消化SPを上げようとモブプロ時間を増やした結果チームメンバーの疲労がたまるという2次被害も発生しました。
モブプロをしていて、「あと少しだけ・・・」が連続し、気づけば1時間オーバーなんてこともよくありました。😙
6. レトロスペクティブから得た気づきと打開策
私たちは1週間スプリントを回しているので毎週のレトロスペクティブで良かったこと、課題や次のスプリントで実践するネクストアクションを決めます。手法は「KPT」「Fun, Done, Learn」「Ceil Boat」など色々試していますがもっとも多いのがKPTです。
このような感じで付箋を貼ってそれをみんなで話し合います。
毎週のネクストアクションの中で効果が出たものをいくつか抜粋すると：
| Date | Next Action |
|---|---|
| 4/30 | 非同期でタスク一個doneにまで持っていく |
| 5/14 | CursorでLinearチケットの質を上げる |
| 6/18 | モブプロをきっちり時間で区切るチャレンジをやるぞ！ |
| 7/2 | モブプロの時間割を変えて効率化 |
まず最初はチーム全体の消化SPをあげるべく、非同期でのタスクを完了させることを実施していきました。リファインメントの時点で非同期でやりやすいタスクをラベリングしたり、Devinに非同期でやらせるタスクを作ったりと工夫しました。
「CursorでLinearのチケットの質をあげる」というネクストアクションは、Refinementの段階でCursorにCodeを読ませながら、Linaer MCPに繋ぎ、チケットに実装詳細まで書いた状態まで持っていくというものです。この施策のおかげでモブプロでの実装時間が大幅に短縮できたのですが「AIを活用したRefinement」は別のブログでお話しできたらと思います📕
6月に入ってからはモブプロの時間をオーバーしない、つまり時間がきたらどれだけ盛り上がっていても強制的にMeetを解散するということを行いました。多少力技に思えますが、これにより非同期の計画が立てやすくなったり、メンバーの疲労も回復していったように思います。また、終わりの時間が明確なのでモブプロの最初と最後に方針立てたりする時間を5分取ることができるようになりました。 7月の頭にはモブプロの時間割を変えました。これはモブプロとモブプロの間に非同期な時間を入れるように変更しました。これにより
- 午前のモブプロでタスクを分解し、非同期で進め、午後のモブプロで結合させる
- 午前のモブで出た疑問を個人で深掘り → 午後に答え合わせがでる
私たちのチームではこのやり方でかなり効率が上がったように感じています。
これらの施策により5〜7月の2ヶ月は消化SP/稼働人日が回復し、価値提供のサイクルも安定してきました。
7. モブで始まり、モブを進化させていく
私たちは今も毎週モブプロの運用を見直し、少しずつ改善を重ねています。
モブプロは知識共有の核であり、チーム学習の場です。AIはその支援役として、余計な思考コストを削減してくれます。また、モブプロのタイムボックスと非同期の使い分けで、フロー効率を最大化することができると考えています。
もしあなたのチームが「スピードは欲しいけど、属人化や設計の負債が怖い」と感じているなら、モブプロはその解決策になり得るかもしれません。もちろんモブプロにもデメリットはありますが勢いと学習、どちらも欲張る選択肢として、ぜひ一度試してみてください。
以上UPSIDER請求チームが実践している「モブプログラミングのすゝめ」でした！最後までお読みいただきありがとうございました🎉
請求チームはAI与信審査から債権回収まで全プロセスを一気通貫で提供するカード基盤の、重要な請求・債権回収を支えるチームです。
請求チームでは、価値を早く届けたいエンジニア大募集中です！
