先日モブプロMeetupが開催されました。モブプロに関する知見や悩みが共有されて、モブプロの楽しさや難しさを再認識できる良い時間でした。

ところで、このイベントでは参加者から質問を集める機会があったのですが、どれも身近に感じる質問だったので、自分の思考整理のために私の目線で答えて見ようと思います。現場の実例共有も兼ねて。

有識者が参加していない場合、コードレビューをどうしていますか？

参加者に合わせてモブプロのゴールを調整しています。
私のチームのモブプロでは有識者が参加しているケースが多いので、「GitHub上でのコードレビューなく即Mergeできる状態」を目指すことが多いです。とはいえ欠席が重なり有識者がいない場合もあるので、その際は「参加者の中では合意の取れた状態」を目指し、あとで有識者にレビューしてもらったりしています。急ぎでない場合は別の案件に取り組む、できる部分だけやる、といった選択をとることもあります。

暴走しがちな人がいる場合にどう対処しますか？

私のチームでは、ナビゲーターの一人だけが発言しまくるといった暴走よりも、ドライバーが一人でコードを書き進めちゃう暴走のほうが起きがちです。私もやりがちなのですが、コードを書いているうちに脳内で先読みが捗ってしまうんですよね。そして場を置き去りにしてひとりで書き進めちゃうんですよね…。

このとき「ちょっと待って」「声に出してから書いてみて」とブレーキをかけるのもナビゲーターの役目だと思っています。ナビゲーターの一人だけが発言している場合に「〇〇さんはどう思う？」と別の人に話を振ることも然り。モブの進め方を改善できるのはモブの参加者自身だと思うのです。

モブプロを定着させるために特別な取り組みをしましたか？

私がチームにモブを導入したときは、みんなでひとつの仕事をすることを「モブ」と呼び、モブは身近なものであるという認識を浸透させることを意識しました。具体的には

  • もともと開催していたコードレビュー会を「モブレビュー」と呼ぶようにした
  • Slackにモブに関する情報共有のChannelを立てて情報発信した
  • モブプロの時間を確保しトライアルした
  • チームメンバーが議論している場に顔出し「モブしてるね！」と声掛けて回った
  • 実装に関する相談を受けたときに「モブでやっつけてみる？」と提案した

といった感じです。今では自然と複数人で集まって問題解決する場面が増えてきたので、チームにモブという選択肢が浸透してきたように感じます。

きちんとドライバーとナビゲーターを決めインターバルを回すモブプロの形式にはなっていないこともありますが、モブの目的に適っていれば形式にはこだわらないようにしています。

モブプロの目的をどう設定していますか？

端的にいうと「フロー効率をよくすること」を目的にしていて、説明するときはフロー効率の改善によって得られる作用に焦点を当てて話したりしています。モブの目的にについては『「モブプログラミング・ベストプラクティス」読んだのでモブプロの魅力と始め方をまとめる』もあわせてどうぞ。

非エンジニアにモブプロのメリットをどう説明しますか？

幸運にも開発プロセスについて裁量を与えてもらえる環境なので、「モブプロをやることを許可してもらうための説得」といった難易度の高い説明を経験したことがありません。

ですがプランナーなどの非エンジニアにモブプロの手法を紹介したときは、エンジニアに伝えるときと同様にリソース効率とフロー効率の違いをとっかかりとし、レビュー待ち時間などによりリードタイムがかかった体験談などを交え、モブプロという手段を選択する理由を伝えました。また、実際にモブプロに参加してもらったり様子を撮影して見せることでその場の雰囲気を知ってもらい、「自分たちも試してみようか」と感じてもらうことを目指して説明しました。

ちなみに、ここでも「モブプロ」ではなく「モブ」という言葉を意識的に使うようにしています。モブプロの方法論には言及せず、モブの身近さを実感してもらうことでメリットを想像しやすい状態をつくることを意識しています。

どうしてもモブプロをしたくない人がいる場合どうしますか？

モブプロあるいはモブは手段のひとつです。ですので、やりたくない人がいるのであれば強制する必要はないはずです。

ただ、モブプロをしたくないと感じる背景を知ることができれば、そこに何かしらの改善のヒントがあるように感じます。
やったことないけれどやりたくないと主張する人がいる場合は、モブ以前に「何か案が出たらとりあえず試してみる」というマインドをチームに浸透させることが必要かもしれません。
逆に過去にモブプロを経験した上でやりたくないと主張する人がいる場合は、モブのメリットを実感できなかったのかもしれません。どんな点がまずかったのかを聞き、今の自分たちのモブが同じ状態ではないかを見つめ直し、問題ないようであればその旨を伝えてみると良いかもしれません。

いずれにせよ、やりたくない人がいるということは改善のきっかけを得るチャンスです！

モブプロに合う内容・合わない内容はありますか？

設計やリファクタリングなど、人によって結果や過程に差が出やすいものは向いていると感じます。また、暗黙のテクニックがあるような難解なデバッグや、環境による差が起きやすい環境構築なども実践してみて好感でした。
一方、修正方法が誰の目からも明らかな不具合修正や、誰がやっても過程・結果が変わらない単純作業などは向かないと思っています。

モブプロに最適な人数は何人ですか？

小規模で全員が「ちゃんと」参加できる目安は4〜6人くらいかな、というのが体感です。『モブプログラミング・ベストプラクティス』には3〜4人がちょうど良いと書かれていましたし、私の現場では9人くらいでうまくできたと感じるケースもありましたので、あくまで目安です。ただ始めたばかりの頃は少なすぎても多すぎても難しく、4〜6人が安定しやすかった印象です。

ドライバーは何分交代でやっていますか？

その時々によりますが、15分〜30分交代が多いです。
何分のインターバルにしても、最後の1分は

  • ドライバーがgit commitする
  • 次のドライバーがgit pullする
  • 次のドライバーが書き始められるよう準備する

にあてています。

人前でコードを書くのは緊張しませんか？

私も人前でコードを書くときは緊張しがちですが、モブプロではあまり緊張しません。
私の場合「考えている過程」や「未完成なコード」を見られることで能力が低いと感じ取られてしまわないか……という不安があり緊張してしまう傾向にあります。ですがドライバーはナビゲーターの言うとおりに書くことがほとんどなので、みんなの意見を反映するタイピスト(兼 質問して議論を掘り下げるファシリテーター)のような感覚で臨んでいます。ちょっとした気持ちの違いですが、これでけっこう緊張をほぐせています。

おわりに

振り返ってみると、どの疑問も自分が一度はぶち当たったことのあるものでした。今でも悩んでいる課題もありますが、上述したように「みんなでひとつの仕事をすればモブである」と考えるようになってだいぶ肩の荷が下りました。もちろん方法論に沿ったほうがうまくいくことが多いとは思いますが、そこにこだわって悩むのではなく、方法に悩んだらそれすらモブで決めちゃおうくらいの気持ちでいてもいいのかなと思います。せっかくなので楽しんでモブしたいですしね！ ハッピーモビング！