モブプロをやめた理由 - Feedforce Developer Blog

こんにちは、dfplus.io チームの shiro_pon です。 dfplus.io のフロントエンド開発ではモブプロを取り入れていました。しかし、諸々の経緯があり現在はモブプロをやめています。今回はモブプロをしていたことによる成果・課題点とやめるに至った経緯の話をしようと思います。本記事ではリモートワークを前提として話を進めていきます。

モブプロとは

まず、私のチームで実施していたモブプロについて簡単に説明します。モブプロ(mob programming)は、複数のエンジニアが1台の PC を共有しながら協力して開発を進める手法です。ドライバー（コーディングを担当）、ナビゲーター（指示を出す）、オブザーバー（状況を俯瞰しフィードバックを行う）といった役割を持ち、全員が同じプロジェクトに集中して作業します。

集中力を維持するためにポロモードタイマーを用いて25分作業 + 5分休憩のセットで役割をローテーションして作業を進めていました。

モブプロで得た成果

入社直後からモブプロをさせてもらったことで会社独自の開発作法や知見を効率よく得ることができました。細かい疑問点を解消しつつ開発を進められたことは非常に有り難かったと思っています。以下に具体的な成果を4つ挙げます。

1.会社独自の開発作法の習得

開発チームの作法に則ったブランチの命名や PR の作成からプロダクトマネージャーへのレビューの依頼までのプロセスを効率よく理解することができました。モブプロで同期的に助言を受けながら開発プロセスを実際に体験できたため、手探り状態が少なく、スムーズに作業に馴染むことができたと感じています。

2.同期的なコミュニケーションによる疑問や懸念点の解消

モブプロでは、リアルタイムにコミュニケーションをとりながら作業を進めるため、細かい疑問や懸念をすぐ解消できるメリットがあります。個別作業において、疑問や懸念が発生したときはどうするでしょうか。主に3つケースが考えられそうです。

zoom などのリアルタイムコミュニケーションツールで相談をする
テキストで質問を投げる
実装を進められる状態であればコメントを残して作業を進める

1 or 2では相手の作業に対して割り込みが入ることになります。相談を受けた側はコンテキストスイッチが必要になること、また調査や回答をする上の作業も必要になります。また、相手の状況によってはすぐに返答があるかもわからないでしょう。3に関しては作業の手戻りのリスクが大きいです。懸念がある状態で実装を進めると、レビューの時に実装方針の大幅な変更を余儀なくされる可能性もあります。

上記で挙げた課題をモブプロでは解消できます。同じ時間で同じ作業を一緒にしているため割り込みという概念はなく、目の前の疑問や懸念を解消することに全員が集中できます。また、メンバー全員が合意して開発を進めるためレビューのコストを削減できることも大きなメリットの一つです。

3. 作業進捗の向上

単純に作業人数が増えるため多角的な視点で実装を進めることができます。一人で作業をしている時に、実現方法の見当がつかない場合や未知のエラーに遭遇した際には解決方法を調べるなり試行錯誤する場合があります。モブプロの場合はメンバーの誰かが解決方法を知っていればそのままスムーズに開発を進めることができます。

モブプロで起きていた課題点

私がモブプロをする上で課題に感じていた点を挙げます。

作業進捗を優先する焦り

ナビゲーターとして指示を出す際に、進捗を出さなければというプレッシャーを感じることがありました。その結果、難易度の高い課題に向き合わず、比較的簡単な実装に集中してしまったり、最適ではない実装方法を選んでしまうこともありました。これが長期的には個人の成長を阻害する要因になったと感じています。

シニアエンジニアへの依存

自分がナビゲーターの時に実装難易度の低いところばかりやっていると、必然的に難易度の高い箇所を他のエンジニアに頼る形になります。チームの進捗を優先するのであればそれがベストと考えても良いかもしれません。しかし、個人の問題解決力を考えると「頼ってばかりで良いのだろうか」という葛藤はありました。

作業環境の差異

ドライバーの画面を見て指示を出すのは自分の手元でコードを書く場合に比べて難易度が高くなります。見たいファイルに辿り着くには目的を言語化してナビゲーションする必要もあります。作業の内容によっては VS Code の拡張機能「Live Share」を使用して同じエディターで作業するなどの工夫も必要です。

また、拡張機能や翻訳設定もそれぞれのため、普段自分が使い慣れている環境で作業できないもどかしさはあります。環境の差異に関しては入れたいツールの認識合わせなどする機会を設けても良かったかもしれません。

モブプロをやめたきっかけ

シニアエンジニアとの1on1で私が感じていたモブプロに対する課題点を相談させてもらったことがモブプロをやめるきっかけでした。一番大きな理由は前途した「難易度の高い実装をシニアエンジニアに頼ってばかりで良いのだろうか」という葛藤を汲んでもらった形になります。

自ら課題解決に取り組む機会を増やすこと、要件の整理からプロダクトマネージャーのレビュー通過までのプロセスを担当することが自身の成長・チーム全体のアウトプットの向上に繋がると判断しました。

モブプロをやめた結果

得た成果

自力で実装する機会が増えたことでプロダクトコードの理解が深まった
PR に細かい実装意図のコメントを残すようになった
並行して複数のタスクが進むようになった
レビューで相手のコードをじっくり読む機会が増えた
自分のペースで開発を進められる

総じてアウトプットの量は増えたと考えています。ここでいうアウトプットとは単純に PR の数だけではなく、レビューを円滑に進めるために PR に残した細かい実装意図のコメントも含まれます。また、実装後にもセルフレビューでコードと向き合う時間をつくれたことはプロダクトコード全体の品質の向上につながったと考えています。

課題

レビューコストが発生
レビューの際に手戻りが発生することがある
同期的なコミュニケーションが減る

一番の課題はレビューコストが増大したことです。モブプロではリアルタイムでメンバー全員が合意して進めていたため、レビューの工程がありませんでした。個別作業では実装意図や方針の錯誤が原因で、修正が発生する頻度が高くなりました。また、同期的なコミュニケーションがなくなることで、テキストで相談するほどでもない程度の「気軽に相談できる機会」が減ったのも個人的に課題に感じていました。

結果を踏まえて

現時点では、モブプロをやめたことは正しい選択だったと考えています。課題に対して自主的に向き合うこと、レビュー工程を経て PR をマージすることで自身のアウトプットの質の向上に繋がりました。チームとしてもフロントエンドエンジニアが1名抜けたタイミングだったので、アウトプット量を維持する点でも適切な時期だったかもしれません。

同期的なコミュニケーションが減ってしまった課題については定例の夕会を設け、細かな相談や悩みを解消できる場を作ることにしました。