この記事はInsurtechラボ３月アドベントカレンダー企画で「2022年度の学び」について書いています。
ありがたいことに何も知らない中で「モブプロ」で開発する機会をいただきました。
実際に体験してみると、想像以上に良かったことや、守らないとモブプロが崩壊するポイントがあったため、振り返りをかねて紹介できればと思います。
モブプロとは？
一般的には、3人以上の人たちが1台のPCの前に座ってコードを書いていく開発スタイルを示します。メンバー全員がオンラインから参加しているのであれば、画面共有などでコードを共有しながら書いていきます。
「このやり方に従っていなければモブプロとは呼ばない」というような強いルールはありませんが、おおよそ以下のような取り決めがあります。
- 「タイピスト」（ドライバーと呼ぶこともあります）と「モバー」のユーザが存在する（コードを書く指示をする「ナビゲータ」を設けることもあります）
- タイピストとモバーは、一定の時間毎に交代します
- タイピストは、コードを書く人です。ある時間では1人だけです。
- 残りの人たちは全てモバーです（ナビゲータを設ける場合もあり）。モバーは、コードを書きません。タイピストが書いているコードを見てアドバイスをしたり、意見を述べたり、タイピストの代わりに調べたりと、タイピストを支援します。
モブプロで気をつけること
3人以上の人と1台のPCとキーボード＆マウスさえあればモブプロを開始できますが、「効果的」なモブプロにするにはいくつか注意したい点があります。
共通
モブプロの進め方をメンバー間で合意する
タイピストとモバー交代のサイクル（例：25分たったらタイピストを交代）、休憩時間（例：1時間ごとに10分）、何をモブプロでやるか？など、事前に合意します。何を設けるのかははチームで模索していくことになりますが、メンバー間で合意を取ることが大事です。
タイマーを準備する
コードを書くことに集中すると、「あと何分？」「次のタイピストは誰だっけ？」を忘れます（断言）。
タイマーツールを用意してください。全員オンラインから参加であればMobTimeがおすすめです。
ソースコード共有ツールを準備する
タイピストとモバーの交代時にいちいちGitにコミットしたり、Zoomなどのミーティングツールで画面共有しながら進めるのは、思った以上に苦痛となります。コードを共同編集できるツールを用意しましょう。
VSCodeやVisualStudioを使っているのであれば、「Live Share」がおすすめです。
共同編集機能、チャット、ローカル起動しているサーバの共有、コンソールの共有、タイピストのカーソル位置をトレース、自分のカーソル位置に全員集合させるなど、モブプロに必要な機能が一通り揃っています。
タイピスト編
有識者はタイピストから外す
コードを書くスピードこそ上がるものの、何をやっているのかモバーに伝わりにくくなります。
チームの知識レベルの向上を目的としてモブプロをするのであれば有識者をタイピストから外した方がよいでしょう。
タイピストの交代はタイマー制
区切りのいい瞬間というのは不思議なことに中々現れません。「あとこれさえ実装すれば・・・」を許すと、気づいたら半日ずっとコードを書いている、ということが起きます。タイマーで強制的に区切った方がよいです。
何をしようとしているのか宣言してからコードを書く
「コードで語れているはず」とは思わないでください。モバーには想像以上に何をやっている・悩んでいるのか伝わっていません。
モバー編
ふーんそうなんだーと流さない
モブプロする意味がなくなる恐るべき態度です。これは本当に大事です。
強く指示しない
「こうしろ」「こうすべき」を強く主張すると、タイピストの学習効果が低くなります。また、何をやっているのか判らなくなるので、タイピストのストレスが溜まるでしょう。
タイピストが困っていることを自主的に調べる
モブプロによる開発効率が上がるどうかは、タイピストのコーディング能力ではなく、モバーによるアシスト能力に掛かっていると強く感じました。「うーん、判らないなー」と思ったとき、さっとモバーの人から解決案が出てくると、本当に気持ちよくコードが書けます。
モブプロが得意なところ
体験してみて感じたことを書きます。
チーム全体の知識レベル向上
モブプロの効果が最も現れるところだと感じました。
チームメンバー全員が知らない技術であっても、一通り終わったとき、一人で調べながらやる or 有識者が書いてくれたwikiなどを見て知る場合と比べて、よい気づきや学習効果が得られます。
一定のスピード開発できる
担当者が病欠した、本番障害対応のため何もできなくなったなどの突発イベントが発生しても、モバーが一人減る程度で、開発が止まりません。モブプロは突発的な阻害イベントに強いと感じました。
レビュー労力の低減
17時くらいに、何十ページにもなるプルリクが送られてきて「明日までに承認お願いしますね」の絶望を感じたことはありますか？モブプロなら、今まさに見ていたコードなので、そんな絶望感はありません。
誰かが助けてくれる安心感
一人でコードを書いていると「うーん、わからない。でも、これを知っているあの人は忙しそうで話しかけづらいな・・・」にしばしば遭遇します。モブプロであれば、これを言葉にするだけで、誰か（モバー）が助けてくれるのです。
効率的にも、精神的にも非常によいです。
品質向上
致命的な誤り（例：全く違うものを作っている）が起きにくく感じました。複数人の目があることは重要です。
透明性の担保
誤魔化したり、手を抜いたり、バグで動かなくなったり、自身のスキル不足でイマイチなコードになったとしても、それを隠し立てすることができません。無視して進め、後で何か問題が起きた時、何人もの人が「心当たりあり」の状態となり、トラブルシュートが早くなります。
チーム内の状況が全員と共有される（＝共有に要するコスト低減）
短い開発期間で担当者間の状況を一通り共有するのは大変です。詳しく話出すと時間が足りず、時間を削ると状況がぼやけます。モブプロであれば、コードに関しては既知の事象であるため、共有のコストを低く抑えることができます。
モブプロが苦手なところ（適用はやめた方が良いところ）
参加者全員が既知のもの（そのコードの書き方を知っている）
機械的に生成できるもの、全担当者が知っているものは除外した方が良いです。
モブプロは多くの開発者の時間を借りるので、伝統的な「工数」は大きくなります。効果の高いものをきちんと選定して適用した方がよいでしょう。
短期的なベロシティの向上
残念ながら「3人集まったのだから3倍の速さでコードが書けるよね？」とはなりません。長い目で見ると、メンバーの知識レベルが上がることで、ベロシティは徐々に上がり1.5倍になるかもしれませんが、3倍になることは無い感覚です。
「何をおいても効率重視（＝人的リソースの最適化が至上命題）」であれば、モブプロを選択してはダメです。
試行できない進め方
モブプロは、自分たちのチームにあった最適なやり方を模索するものだと感じました。一般的に良いとされている方法であっても、自分たちのチームにはしっくりこないこともしばしばあります。これが起きると、時間ばかり掛かることになります。
そのため、モブプロのやり方を含めて試行できない進め方（例えば、ウォーターフォール型のプロジェクト）で実施するのは避けた方がよいです。「モブプロをすると決めたからモブプロでやった」だけになりかねません。
まとめ
モブプロを体験してみての感想でした。
モブプロによって得られる効果は高いと思うものの、時間が掛かってしまうことから、必要な場面を選んで適用するものと強く感じました。また、やり方によってはモブプロから得られる効果を打ち消すような罠が潜んでいるため、自分たちにあったやり方を試行していく必要があります。
