約半年間、毎日モブプロをやってみて感じたこと。モブプロは手段なので目的がなければ恩恵を感じづらいかも。

私が所属するチームでは去年の6月頃からモブプロを取り入れ、約半年が経ちました。総括的にはモブプロをやってよかったというポジティブな感想になりますが、最初から上手くいっていた訳ではなく、途中でモブプロをやめた時期もありました。
モブプロを取り入れるか検討していたとき、私自身はそんなに前向きではありませんでした。それがなぜ今はモブプロをやってよかったと感じるのか、この半年間を振り返ってみようと思います。

この記事はモブプロのやりかたをレクチャーする内容ではありません。モブプロのメリット・デメリットはいろんなところで紹介されてるけど実際どうなの、という方の参考になれば幸いです。

どんなチームでモブプロをやっているか

1. 人数
   5人。チームに所属するエンジニア全員がモブプロに参加している。
2. チームメンバーの背景
   全員フルリモート勤務。全員バックエンドとフロントエンドの両方とも実装できるけど、得意な領域や経験年数は人それぞれ。プロジェクトの初期頃から携わっているメンバーもいれば入社後数ヶ月のメンバーもいる。

どのようにモブプロをしているか

1. 時間
   毎朝10:30~12:00の約1時間半。毎日朝会をやっているので、朝会が終了したらモブプロという流れ。
2. 題材
   現在はフロントエンドのコンポーネントテストの実装とリファクタリング。以前はスクレイピング実装やバックエンドのテスト実装
3. モブプロのやり方
   ドライバー役はJetBrainsのCode With MeやVS CodeのLive Shareでコードを共有する。ドライバー役のディスプレイをGatherで画面共有し、コンポーネントテストの挙動などを全員が見られるようにしておく。
   一般的なモブプロ手法のドライバー役とナビゲーター役のように完全に役割が分かれている訳ではない。ドライバー役は自分の意思でコードを書いたり、ドライバー役以外もコードを書いたり、リファクタリングなどで複数のコード変更が生じる場合は全員でコードを書き換えることもある。ドライバーやナビゲーターといった役割は特に意識せず、疑問や質問、提案があればその場で発言する。
   ドライバー役は日替わりで交代する。

モブプロでコンポーネントテストを扱った理由

モブプロ対象のプロジェクトは立ち上げから1年ほど経過しているのですが、当初は技術的調査の面もありテストを書かずに実装をすすめてきました。サービスの品質を安定させるためにもテストを書いていきましょうと方針が決まったとき、フロントエンドのテストを書いたことがない人が多かったので、モブプロでテストを書いていくことになりました。

実感1: わからないことをすぐに質問できる/説明が正しく伝わったか確認できる

私はこのプロジェクトで初めてフロントエンド実装に携わったので、E2Eテストとコンポーネントテストの違いがよくわかっていない状態でした。E2Eテストとの違い・どんなテストケースが必要か・何をテストしたらいいのかなど、わからないことがあればその場で質問してコードに反映させることができるので、なんとなく理解したような気になる（が実際は理解してない）・説明したことが伝わってないなどの状況に陥ることが防げていると思います。

実感2: 個人で調べながら実装するよりも早い

全く初めて触るライブラリや詳しくない技術などは個人で調べながら実装するよりも、そのライブラリや技術を使ったことがある人に教えてもらうほうが圧倒的に早いです（当たり前かもしれない）。期待した通りに動かないときやエラーが発生したときに一人で試行錯誤するよりも皆であれこれ言いながら試したほうが早く解決したり、場合によってはフロントエンド知識よりも業務知識が求められることがあるので、いろんなバックグラウンドを持ったメンバーでモブプロすることのメリットだと感じます。

実感3: 合意をとりながら実装をすすめていくことができる

テストを書く前に依存関係の解消など設計上の問題を解決する必要があり、構造変更など既存コードの大規模なリファクタリングが発生しました。フロントエンド領域に詳しいエンジニアばかりではないので、依存関係を解消するにはどのように書くのがいいか・どのようにコンポーネントやロジックを分離させていくのがいいか、全員が理解して共通認識を持った状態で実装を進めることができました。
モブプロのメリットとしてよく挙げられることですが、モブプロ中にコードレビューを行っている状態なので、プルリクエストで大量の指摘点をもらったり指摘と修正の繰り返しで疲弊してしまうことが防げていると思います。

実感4: 特定のメンバーしか扱えないコードが減る

以前はスクレイピング機能をモブプロ開発していました。当時スクレイピング実装経験があるメンバーがいなかったため、技術調査から実装まで全てモブプロで開発していきました。設計からロジックまでチーム内で共有できているので、バグの修正やソースコードの変更は誰でも行える状態になりました。

実感5: モププロの恩恵を実感するためには題材選びがとても重要

実感1~4は全てモブプロのメリットです。一方でモブプロをやってみるとデメリットにも気づきます。
エンジニア全員がその領域について十分理解していて、議論や相談がほとんど発生しない状況になってしまうと暇な人が発生します。モブプロでスクレイピング機能を開発していたとき（メンバー離脱により途中からペアプロでしたが）、開発後半になると技術的な問題で詰まるケースやコードの書き方で相談する回数が減り、モブプロの恩恵はほとんど感じませんでした。
実感3で触れた通りモブプロのメリットとしてコードレビューが不要という点がありますが、例えばモブプロ中にほとんど会話が発生しないような状態であれば、モブプロせずに個人で実装したほうが効率的な気がします。

実感6: モブプロのルールは状況に応じて柔軟に変えていくのがいい

一般的なモブプロではドライバー役とナビゲーター役で役割を分けて数十分ごとに交代するそうですが、どのようにモブプロをしているかで書いた通り、私達のチームでは少しルールを変えています。ただ、半年間ずっとこのルールでやってきたわけではなく、今はこのルールで上手くいっているというだけです。以前は丸一日モブプロやっていましたし、ドライバー役とナビゲーター役をはっきり分けてみたこともありました。チーム内にモブプロ経験者がいなかったこともあり、どうすればストレスなくモブプロをすすめることができるのか、初期の頃はかなり試行錯誤しました。
このチームはこのやり方でモブプロを進める、というよりもチームメンバーの習熟度や扱う題材に合わせて柔軟にルールを変更していくのがいいんじゃないかと感じます。

さいごに

個人的には、今まで書いたことがないコンポーネントテストを書き、テストが書けるように依存関係を解消するためのリファクタリングを行い、フロントエンド技術について理解を深めていく手段としてモブプロはピッタリの開発方法だったと感じています。逆にスクレイピング機能の開発後半はモブプロでなくても良かったかなと思います。
モブプロが良いらしいから取り入れてみよう、は勿論素晴らしい取り組みですが、何のためにモブプロするのかは事前に共通認識を持っておいたほうがいいと思います。