概要
今の会社はチーム体制で開発を進めているのですが、ひょんなところからチームのバックエンドエンジニアでモブプロしようという話になりました。モブプロ経験のあるメンバーは不在だったため、試行錯誤ながら何度か実践してみた結果、実はモブプロはうちのチーム開発環境にとってかなり良いかも！と思い始めたので、モブプロによる効果や実施の際に気をつけるポイントをお伝えしていこうと思います。
あくまで今回チームで見つけたモブプロの方法なので、セオリー的に OK なのかはわからないのですが、学んだコツもまじえてお伝えしていこうと思います。
環境
うちのチームの簡単な概要と、モブプロの手法については、以下の通りです。
利用ツール
フルリモート OK の環境なので、全員で Google Meet を繋ぎつつ、VSCode の Live share 機能を利用する。シンプルな方法。
メンバー
正社員・業務委託合わせて 5 名のバックエンドエンジニア。
エンジニア経験や今回モブプロの対象にした題材の開発経験にはバラツキがある状況。
開発・背景
Go を利用した SaaS の開発をしており、その新しい機能。今回チームで開発していたのは、バックエンドエンジニア 5 名で 2〜3 週間程度の開発期間を要する比較的大規模な機能でした。最初は処理の流れを設計するような形で、その後は肝になりそうな難易度の高い実装部分を題材にして実施しました。
方法
一般的なモブプロと同じく、交代で 1 名のタイピストとその他モブという構図に分かれる形です。タイピストは目安 20 分交代で、一回の時間は 3 時間前後でした。
モブプロによる効果
ある程度全員でコツを掴んできたところで、これは良いなと思った効果は主に 2 つありました。
開発の効率化
1 つは開発全体の効率化です。
特に今回のような規模の大きい機能の開発においては、人によっていろんな設計手法でその機能を作ることができると思うのですが、その幹となる部分をモブプロの題材にすることにより、全員に共通認識が生まれました。
モブプロの題材として大枠の流れを作る、という作業を全員で行なったのですが、
- どんなファイルがどの辺に置かれるか（細かいところは TODO コメントを残す）
- 行なっている実装にはどんな意味があるのか（話し合った結果、どんな落とし穴があってこうなったのか）
等を議論できたことは、その後の開発効率の強化に大きくつながったと思います。
コンフリクトの心配もかなーーり減りました。
複数の目により実装漏れが防止できる
機能として複雑な実装だったため、各々実装観点でまだ抜け漏れがある状態でスタートしましたが、意見を出し合うモブが 4 名もいたので、全員の視点を合わせて、抜け漏れ少なく議論できました。抜け漏れは大きいものになると、実装そのものをひっくり返しかねないのですが、今回の開発全体においてそういったひっくり返しは起きませんでした。
役割分担や見積の認識が揃う
私たちのチームの場合は、3 時間のモブプロである機能を完璧に作り切る…といったことはできず、せいぜい処理の流れを書き、細かいところは TODO する、がいっぱいいっぱいなこともありました。しかしそれだけでも、そこまでできたことにより「この場所は大変そう」「こういう役割の分け方をするとコンフリクトが起きなそう」といった後続のタスクに関する想像がしやすくなっていました。
今回に関しては開発規模が大きかったので、全員で週初めの時間を利用してモブプロを行ってから役割分担、モブプロ → 役割分担、みたいな形にしていたのですが、その際に精度の良い見積ができ、分担自体もしやすくなりました。
※ 週初めの時間を利用しているのは、スプリントを 1 週間単位で回しているためです。
レビューが楽になる
私たちのチームは、これまで基本的に 1 つの機能をバックエンド 1 名・フロントエンド 1 名で行うことが多かったです。その際によくあるコードレビューの難しい点として、1 名で取り組むにしては少々大きめの機能の場合は、レビューの粒度が大きくなりやすいため見る場所が多くなり、また事前のインプットに時間を要してしまうということがありました。
しかし、大枠の認識をモブプロでそろえたことにより、その後分担で行った開発分に関するコードレビューが格段にやりやすくなりました。
大きい機能の作業を分担する分、一人ひとりのレビュー数は多くなっていたので、この恩恵は非常にありがたかったなと思っています。
総合的にみるとスピードが向上する
モブプロをし始めて 1 時間くらいは、全員が様子見しながらだったので、議論がやや散らかってしまったり、モブプロの場で話すべきでない細部の話に時間を割いてしまったりしていました。また、いつも各々で開発を進める 5 名が一緒に 1 つの作業をする状態なので、「スピード落ちないかな…」といった一抹の不安はありました。
しかしモブプロは、論点になる場所を抑え、全員で話す必要のない場所を後回しにする等の工夫をするなど、チームでコツを得ていくと、意外にもサクサクと進められるようになっていきます。また、先ほどから伝えている通り認識に齟齬がない状態になる、というのがかなり大きな利点になっており、その後の個々の開発スピードやレビュースピードにも直結しました。
チームの成長支援
モブプロの良いところ 2 つ目は、チーム・個人の成長につながる機会が多いなと感じたところです。
特にエンジニアとしての経験にばらつきがあるチームなので、ジュニア寄りのメンバーにとっては勉強の機会にもなりました。
また、チームは普段から何の問題もなくコミュニケーションが取れる文化なのですが、今回モブプロ行なったことにより、もう一段距離感が縮まり、チーム力も上がったと思っています。
本題以外で知識共有ができる
私たちのチームはモブプロ自体がはじめてだったので、これは初めてモブプロを行う時のお話かもしれませんが、VSCode の効率的な使い方等や Golang のコードの書き方等、タイピストの観察による学びがありました。「これ今どうやった！？」「こんな書き方あったんだ」みたいなちょっとテクニカルな使い方もあり、時折そのような話をしながら進めました。
※ただし、モブプロの一般的なセオリーとしては、書き方等はモブが指定するのもいいらしいです。
モブプロはコードを書く時の頭の中の動きをそのままモブ全員で会話して擦り合わせる作業なので、シニアエンジニアが普段どう考えを組み立てているのか等、リアルタイムだからこそわかる発見もあったと思います。
適度に雑談を入れてわいわいできる
何もなければいつも一人で黙々と実装するのが通常運転のエンジニア。そのため、モブプロはコミュニケーションの場としてもとてもよかったです。全員が同じ開発をしている感も生まれましたし、その後の実装に関するコミュニケーションやちょっとしたやりとりが増えました。
また、うちのチームは 3 時間ぶっ通しでモブプロだったのですが、これは一般的な目安としては長い方なので（ただ 1 時間とかだと進み始めたところで終わっちゃう、みたいな感覚）、適度に休憩がてら雑談しながら進めました。
アジャイル開発なので、プランニングやレトロ等でも話す機会があるのですが、その際のコミュニケーションもモブプロ以降はより緊張感が薄れ、雰囲気がよくなりました。
気をつけるポイント
ここまでモブプロの効果についてでしたが、次にモブプロをしていて「これは気をつけた方が良いな、避けた方が良いな」とチームで感じたことを以下に挙げます。
習熟度による意見の出方の差は可能な限り埋める
こちらはモブプロをはじめて最初の方で起こったことなのですが、開発する機能に習熟している（似た機能の開発経験がある）メンバーとそうでないメンバーの間で、露骨に口数の差が出てしまったときがありました。話しにくいということではなく、習熟度が足りないゆえにメンバー同士の話し合いのスピード感についていけず、「話せない」状態になっていたというのが正しいです。
最初は習熟度の低いメンバーがタイピストになる
そこでまずチームでやったことは、モブプロのタイピストは習熟度が低い順に回していく、ということでした。
まずは口を動かす必要のないポジションで手を動かしながら、機能に関する習熟度を高めていくことで、徐々に全員の習熟度を合わせていくスタイルにしてみた、という感じです。
これは結構良い感じで作用し、エンジニアとしての経験値そのものや、似た機能の実装経験値の差が大きい場合に有用と感じました。
質問の往来が生まれるようにする
もちろんそれだけでは埋まらないので、続けて意識したのは、習熟度が低いメンバーはわからないことは臆せず質問してもらい、高いメンバーについてはわかりにくいと感じるところの解説を入れるようにしました。双方の意識により、1 回のモブプロが終わる頃にはきちんと認識のレベルが合うまでになりました。
常に全員で生産性の向上を意識する
誤解を恐れずに言えば、モブプロは多くのエンジニアにとって普段と違う開発スタイルになるため、非常に疲れる手法です。
限られた時間でシュッとやっていくのが吉のため、モブプロの時間が長引かないように全員で生産性を意識する必要があると感じました（疲れは如実に議論の質へと影響します。笑）。
細かいところは TODO コメントをつけて去る
私たちの場合は、ある程度書いたらあとは分岐や繰り返しになる場所や、他で既に実装しているものと似た実装になる場所については、TODO コメントをつけて後の作業者のタスクにしてしまう、という対応を行いました。今回の題材については、コアとなる機能の実装が非常に複雑だったたため、そこに重点をおいてコーディングを進めたかったためです。
空中線は可能な限り避ける
「現段階では決める必要がない」「極論どちらでも良い」「まだわからない」等の場所に遭遇した時に、先々のことを考えた議論が展開されてしまうことがあります。そういう議論になっている場合、たいがいタイピストの手はまったく動かなくなっています（察しの良すぎるかしこいエンジニアがいればいるほど起きる落とし穴な気がします…）。
必要なのはとにかくコードを書いてみることなので、空中戦になりかけた際にはみんなで我に帰るようにしました。
ただし、後続のコーディングに関わるような重要な部分については、後回しにせずじっくり結論を出しました。
認識が揃わない時は図を利用する
それでもどうしても認識が揃わない、最適解が見つからないといったときには一旦エディタを離れて、オンラインのホワイトボードツールを利用して整理しました。普通のモブプロであればあまり遭遇しない問題だとは思いますが、今回は開発対象の機能が大きかったため、私たちにとっては大枠を掴むのに非常に有用でした。
やめどきを見つける
これまでお伝えした通り、モブプロの効果の一つに参加者の実装の認識が揃うというのがありましたが、もはやその段階まで到達できれば「あとは全員で枝葉の作業をするだけ」のような状態になります。その状態になった時点でモブプロは終了するべきかなと思っています。あとは個人でやった方が早いです。あと、やっぱり疲れるので…。
モブプロでのゴールを先に決める
やめ時を見つけて終了するのに効果的な方法が、先にゴールを決めてしまうことです。設計段階だと難しいかもしれませんが、難易度の高い実装に取り組む際には、たとえば今回であれば「この場所の Rate limit 実装を行う。細かいところは省き、大枠できたら終わる」といった感じで認識合わせして臨むことにより、メリハリを持って実装することができました。
モブプロ後は全員で振り返りを行う
私たちは全員がモブプロを初めて経験するメンバーだったということもり、モブプロ後に振り返りをしていました。
短い時間でも良いので振り返り会を行うことにより、
- 習熟度低い人からタイピストになった方が良いかも
- 空中戦は気をつけた方が良いよね
- 次回はゴールを決めてから取り組もう
など、次のモブプロの生産性に直結するような意見が多く出て、短期間でかなりコツを得ることができました。
モブプロ中はプログラミングに向き合うため、後から取り組みを整理するのはかなり重要だなと感じました。
終わりに
今回は比較的大きな機能を全員で開発する、ということを前提にモブプロの効果についてお伝えしました。
いつも開発している機能が比較的小粒な粒度だったり、組織のエンジニア間で経験値に差がなかった場合は、また違う効果が得られるのかなと思っていますが、私たちのチームの体験が少しでも参考になれば幸いです。
モブプロ実施後の良い副作用として、その後ペアプロが行われたり、機能の設計に関する気軽な相談が増えたりした気がします。
私たちとしては、総合的な開発体験としても、個人の成長としても、本当に良いなと思いました！
Discussion