食べログでAndroidエンジニアをやってる@sadaです。
弊社では昨今の情勢もあり、リモートワークがメインの働き方になっています。
そんな中、私たちのチームでモブプロをやってみた知見をまとめていきたいと思います。
ちなみに、タイトルに「リモートワークで」とありますが、リモートワーク特有の観点は割と薄くなってますご容赦くださいm(_ _)m
なぜモブプロを始めたのか？
私たちのチームでは、食べログAndroidアプリの設計の刷新（リアーキテクチャ）に取り組んでいます。
その中のふりかえりで、以下のような課題がでてきました。
- 属人化気味の知見を共有して、ボトルネックを解消したい
- キーパーソンが実装できないと、全体の進捗にも影響がでてしまう
- 個々で実装していても知見が属人化したままになってしまう
- 知見が属人化しているとレビューコストも高くなる
- 新しく発覚した複雑な課題をスピーディに解決していきたい
- 一人で悩むより、みんなで話したい
これらを解決する手法としてモブプロが適切ではないかというアイデアがでてきました。
モブプロ未経験で不安もある状態でしたが、まずは効果がありそうか試してみる流れになりました。
モブプロとは？
モブプログラミングとは、3人以上の人々が1台のコンピューターの前に座って協力しながら問題を解決していくことだ。
書籍「モブプログラミング・ベストプラクティス」 1.1 モブプログラミングとは何か より
端的にいうとこのままですね。
呼び方はモビングとか、モブるとかいろいろあります。２人の場合はペアプロ（ペアリング）になります。
（自分は人数は気にせず一緒にやることを「モブる」と言ったりもしています）
モブプロの登場人物・役割
モブプロに登場する人物は、タイピスト（ドライバー）とその他モブ（ナビゲーター）の２種類になります。
それぞれの役割は以下の通りです。
タイピスト（ドライバー）
実際にコードを書く唯一の人で、原則全員がタイピストになるようにローテーションします。
書籍「モブプログラミング・ベストプラクティス」ではタイピストに求められることを以下のように記述しています。
- その他モブがしてくれと頼んだことを理解すること
- 要請の意味がはっきりしないときには、はっきりさせるための質問をすること
- してくれと頼まれたことをコードの形に実装すること
- その他モブを信頼し、自分では通常試さないようなアプローチを躊躇せずに試すこと
- ショートカットキーや他の人のツールの活用方法などの新しいことを学ぶこと
書籍「モブプログラミング・ベストプラクティス」2.3.2 タイピストの仕事 より
その他モブ（ナビゲーター）
タイピスト以外の人のことになりますが、役割は色々あります
- 問題解決につながる次の論理的ステップを見つけるために力になること
- 理解できるまで質問をすること
- モブ全体の近いの水準を上げるために貢献すること
- 目の前の問題に集中すること
- ほかのメンバーの意見を聞くこと
- 必要な情報を予測すること
- システムのなかの改善すべき部分を探すこと
書籍「モブプログラミング・ベストプラクティス」2.3.3 その他モブの仕事 より
正直いきなりこれだけのことを全部やれるようにするのは難しいので、実際にやってみながらふりかえりを行い（後述します）、カイゼンしていくのが良いと思います。
モブプロって何がうれしいの？
フロー効率が高い
モブプロをやろうとする時に良く言われる否定的な言葉は「コスパ悪くない？」だと思います。この発言をする人はおそらく「コスパ」をリソース効率の観点で言っているのだと思いますが、モブプロはそもそも目的が違っています。
モブプロの目的は「早く完成させる」ことであり、フロー効率を重視しています。そのため、リソース効率の「安く作る」とは別の考え方になります。
リソース効率の高い進め方をすると、スキルの高い人にタスクが集中しボトルネックがうまれやすくなります。それに対し、フロー効率を高めることは、タスクを消化するペースは遅くなるかもしれませんが、新しい機能を早くリリースすることができます。そしてソフトウェアでは、それにより利益が得られる場合がほとんどのため、コスパの良いやり方だと言えると思います。
特定メンバーへの属人化防止、メンバーのスキルアップ
モブプロをすることで、複数人が同じ仕事の仕方を覚えられるため、キーとなるメンバーへの依存度を下げることができます。それに加え、経験の浅いメンバーのスキルは引き上げることができます。
また、アイデアの共有をモブプロの中で行うことで、この共有が蓄積され、メンバーのスキル底上げになります。
レビュー等の工程が効率的
モブプロでは常に複数人のチェックが入っている状態のため、コーディング完了後は基本レビュー済みの状態になります。そのため、タスクにいちいち「レビュー待ち」といったような状態が不要になるため、スムーズに作業が進められます。
ペアプロとは何が違うの？
ペアプロと比べて良いと思う点は大きく２つあります。
複雑な問題に挑む場合の解決までのスピード
参考書籍にも書いてありますが、複雑な問題に取り組むときは、１人よりも2人、2人よりも３人、4人とより多くの人がいた方が、共通の目的に対してアイデアを出し合えるので良い方法だと言えます。
こういったケースであればペアよりも、よりスピーディに問題解決に取り組むことができると思います。
中断しにくい
モブでは複数人が対応しているので、ある1人が会議で抜けたり、途中で電話がかかってきたとしても、タスクの進行を止めることなく作業できます。これは大きなメリットだと思います。
大変じゃないの？
慣れるまでの最初のうちは結構大変です。（慣れた後でも結構疲れますが）
モブ中は基本集中して、脳をフル回転させているので、終わったあとの疲労感が結構あります。また、会話もしながら進めるので喉も乾きます。
なるべくリラックスできる環境で実施するのが良いかと思います。
あと、休憩は適度にとりましょう。（これ大事）
どうやってやるの？
実際に自分たちが運用しているルールはこちらです。
- 15分交代
- 慣れてきたらもっと短い方がいいかもしれません
- タイピストが画面共有
- 交代の時には必ずpush
- 交代するためなのでビルドエラーでもOK
- 実装途中だったりする場合はcommitメッセージは適当でOK
- Squashマージする時にコミットメッセージを編集する
- １周ごとに簡単なふりかえりをする
- 思考中で沈黙になる場合は、考え中であることを伝える
- ただただ沈黙すると雰囲気が悪くなる
- リモートだと、悩んでるのか意見がないのかわかりにくい
- 方針で意見が食い違い、数分程度議論しても解決しないなら多数決で決める
- 最初にモブでやることはまとめる
- 事前調査して認識合わせでもOK
- 実際にタスク・仕様を書き出すのでもOK
- 認識合わせができてない、調査が足りないなら、そこからモブでやる
- ビルドについて
- アプリの規模にもよりますが、そこそこビルドが時間かかる場合は、タイピスト以外も同じブランチをビルドしておいてキャッシュを効かせる
- ソースのエラーが無くなったらとにかくビルド（テストがあればテスト実行も）
この中でいくつかのルールをピックアップしたいと思います。
方針で意見が食い違い、数分程度議論しても解決しないなら多数決で決める
これは自分たちのケース特有かもしれないですが、コーディングスタイルによっては意見が別れることは多々あると思います。
そういった時はある程度の根拠を元に数分ディスカッションして、決まらなそうなら多数決で決めるというルールを作りました。
その理由としては、個々のこだわりより、作ることを優先したかったというものがあります。
このように、効率的にかつ納得感をもって前進していくために、自分たちのルールを作っていくと良いかと思います。
交代の時には必ずpush
自分のチームはAndroidアプリの開発がメインですので、それぞれローカルで作業することが多いです。リモートワークだと、ソースコードの共有が手間になるので、そこはシンプルに交代する際にはcommit & pushをするという方法をとりました。
ただ、交代のタイミングは時間で決まるため、ビルドも通らない状態になることもあります。もしこのような状態でコミットすることが嫌な場合は、実際にPullRequestをマージするときにSquashマージを使って、コミットメッセージを編集すればある程度きれいにマージできると思います。
前述した通り、PullRequestのコミットは全てレビュー済みのため、汚くてもそこまで気にならないでしょう。（PullRequestをコミット単位でレビューすることがないので）
１周ごとに簡単なふりかえりをする
タイピストが１周回る度に短時間でふりかえりを実施します。
良かったこと、良くしたいこと、アイデアを出して、そこから具体的なアクションにつなげます。
こういった短いサイクルでのふりかえりを実施することで、回せば回すほどカイゼンされていき、自分たちなりのやりやすい進め方が発見できると良さそうです。
実際、いくつかのルールはやりながら決めたものもあります。
どうだった？
モブプロの感想
リモートでやってみたモブプロが初めてのモブプロでしたが、参加者からは以下のような感想がありました。
- 楽しかった
- 疲れた
- 一人でやるよりバグの発見が早かった
- ミスが少なくなる
- 意思決定が早かった
- レビュー待ちの時間が不要になるのはいいこと
- コーディングとかツールの使い方が知れるのは良いと思った
PullRequestの後のレビュー待ちといった時間が削れたり、意思決定が早くなったりと、フロー効率が高くなったと思える感想が初回から出たのは上々でした。
こういった結果もあり、モブプロの継続や他チームへの展開がスムーズに進みました。
今回初めて実践する前に、一度計算機プログラムをモブで作ってみるという練習をやったので、割とスムーズに進められたというのもあるかもしれません。
リモートモブプロで良いと思った点
タイピストが画面共有しながらやるので、コーディングする際の環境が普段のままというのはメリットだと思いました。
実際に集まってモブプロをする際に環境面の差異は意外と足を引っ張ることがあります。そのストレスが０なのはうれしいですよね。
もちろんリアルで集まってモブプロする場合も、ノートPCを持ち寄って、各々のマシンを交代でディスプレイにつなげば同じことはできると思いますが。
リモートモブプロで辛い点
ソースコードの共有方法としてcommit & pushという手段を取りましたが、やはり効率は悪いです。
この辺はより効率的に進められるように検討はしていきたいと思います。
個人的にはGitLiveとかは面白そうかと思っています。
あとは、通話に利用するツールによってはコミュニケーションが取りづらいなどもあるかもしれません。通常の会議以上に会話がバッティングしやすい印象でした。
参考書籍
まとめ
案外リモートワークでもモブプロやれるなぁという感触でした。
そして、実践してみてモブプロによるメリットはかなり大きいと思ったので、今は他のチームにお勧めしたり、モブプロにも加わったりしながら、布教活動をしています（笑）
まあ、全部をモブプロでやった方がいいとは思ってないですが、選択肢を持っておき、ケースバイケースで使い分けることができると良いかと思います。
明日も食べログ Advent Calendar 2020の22日目の記事が公開されます！
お楽しみに！！