ペアプロ/モブプロを導入した体験談 - BASEプロダクトチームブログ

こんにちはProduct Dev Division所属の @cureseven です。8月にリリースしました「再入荷自動通知 App」のプロジェクトでは、ペアプロ/モブプロで開発を進めていました。今回はその体験談を書いてみたいと思います。

なぜオンラインモブプロをやろうと思ったか

「再入荷自動通知 App」プロジェクトでは、バックエンドエンジニアの過半数がフルリモート下で入社して社歴半年以内、初めてのプロジェクト開発参加という状況でした。また、「再入荷自動通知 App」プロジェクトでは、フレームワーク依存を脱却するため、DDDの実装パターンの導入を試みました。チームで輪読会を行い、DDDについて勉強しながらではあったものの、DDDの実装パターンの導入を実践するのが初めてのメンバーが多く、DDDの観点のすり合わせの意味も込めてペアプロ/モブプロを行いました。

オンラインモブプロの様子

BASEでは新型コロナウイルスの感染拡大を鑑み、現在はWFH（Work From Home）を推奨しており、オンラインでペアプロ/モブプロを実施することになります。まず、メンバー全員がPhpStormを利用しているため、Code With Meという機能を使ってペアプロ/モブプロを試みました。2021年3月時点ではベータ版であり、コピーペーストができない、反映にラグがあるなどの問題にぶつかったため、zoomで画面共有をしながら実施する方法に落ち着きました。ただCode With Meでは手元にドライバーの変更を即時反映しつつ別のファイルがどうなっているかなどを確認しながらナビゲータをすることができる、交代が楽などの利点がありました。zoomで実施した際には、細かくcommitしドライバーを交代しました。 Code With Me以外にも、VScodeのLive Shareという拡張機能を用いるなどの方法があります。チームのエディタ勢力を鑑みてツール選定していくと良さそうです。ペアプロとモブプロの違いはナビゲータが1人か複数人かです。ドメインモデリングとドメインモデルの実装は認識を揃えるためにモブプロで行いました。実装が進んでいったタイミングで、認識を合わせたい部分の実装はモブプロ、分担して行った方がいいものはペアプロと、使い分けるようになっていきました。

モブプロを通して学んだことや感じたこと

プロジェクトを終えて、ペアプロ/モブプロの開発手法がどうだったかを振り返り、以下の内容を話し合いました。

PRレビュー時間の削減とコードの品質の向上

一人でコーディングしている時よりも、考慮漏れが少なくなりました。また、色々な仕様や認識を都度合わせて進めるので、結果的にレビューコストが少なくなりました。プルリクエストを出した段階で既に複数人のチェックが終わっています。プルリクエストでは、細かい指摘が減り、より本質的な議論ができたように感じます。

調査時間の減少

既存機能の仕様や、再現方法、PHPの挙動など、ドライバー自身が知らないことで調査が必要なシーンでは、それぞれが持っている知識や観点を集約し、素早く問題を解決できました。

入社したばかりの新人がモブプロに参加して進めるのは適している

開発着手当時入社して2ヶ月しかたっていなかった私ですが、ペアプロ/モブプロを実施することで助けられた場面がとても多かったです。エディタの便利機能やデバッグ方法など、実装内容以外の部分でもアドバイスをいただき、今後の開発効率を上げることができました。また、入社してすぐはわからないことも多く手詰まりになりがちですが、タスクも進捗し、かつ毎日学びを得て満足感の高い日々を過ごしました。

ドライバーはドライバーに専念する

1週間ごとに振り返りの時間を設けて、開発の進め方の改良を重ねていきました。そこで出た議論もご紹介します。ドライバーは基本的にはナビゲータの言う通りに作業をする人になります。ドライバーに意思が芽生えてしまうと、先々進んでしまいナビゲータが置いていかれそうになります。ドライバーがどうしても意見したい場合は、ドライバーを交代し、ナビゲータとして発言するようにすることを意識するようにしました。

モブプロするべきタスクとしないタスクは分けるべき

タスクの難易度に応じてモブプロが適しているタスクとモブプロじゃなくてもよいタスクは必ず存在すると思います。例えば、文言修正や前回のモブプロ/ペアプロで共通認識が取れて、あとは直すだけ！といったような内容のものはソロ（一人）で十分です。私たちは一概にモブプロしていこう！と決めずに、細かくタスクを分割し、以下の時に絞って複数人で作業するようにしました。

ドメインモデルの実装
一旦ソロで作業したが他の観点が欲しくなった時

モブプロ・ペアプロのメリットは多々ありますが、どうしても複数名の時間を奪うことになります。「流れで」「ついでに」モブプロ/ペアプロをするのではなく、「ここからは自分でやれそうなのでやっておきます」のようなコミュニケーションができると、効率よく開発が進められました。また、モブプロ、ペアプロでタスクに着手する前に、参加者全員で「今日はこれをここまでやる！」という認識を共有しておくことも有効でした。ゴールからそれた内容は別の時間で集まるか、ソロでやってしまうかを判断します。ゴールに集中することで、疲れが見えにくいオンラインでのコミュニケーションを不必要に長引かせないように心がけました。

全員のスケジュール合わせるのが難しい

ドメインモデリングや実装方針のすり合わせは、なるべく全員で行いたいものです。特に今回はメンバーが慣れていないDDDの実装パターンを適応したため、参加していないメンバーの解釈が違った場合、手戻りが起こることがありました。極力作業に集中できるように普段のミーティングは精査しているものの、6名のエンジニアのスケジュールを合わせるのは難しかったです。毎週末の振り返りのタイミングで、来週はここでモブプロしよう、と仮でスケジュールを押さえておくことで、集まりやすくなりました。 1回あたりの作業は連続でやる場合も50分作業+10分休憩を意識してスケジューリングしました。

今後のペアプロ/モブプロとの付き合い方

チームメンバーとの交流の時間にも使えますし、オンボーディングの時や、新しいことに挑戦する時の認識合わせに有効な開発手法だなと感じました。通話をずっと繋ぎっぱなしは辛い人もいるかと思うので、人に合わせて実施検討することが大切です。また、気軽に相談できる人・環境があることも大切です。今回の場合、プロジェクトの開発に直接入っていないマネージャとの1on1の時間が毎週あるので、客観的な意見を聞くこともできました。モブプロ/ペアプロはあまりない取り組みでしたが、挑戦したことが評価される文化も安心して取り組める要因になりました。開発に詰まった時の一手段としていつでも実施できるように、普段からSpeak Openly, Be Hopefulでいたいです。