チーム全体の思想やノウハウを共有しながら実装できる！！「モブプロ」のススメ

2022.12.19

はじめに

この記事は「Applibot Advent Calendar 2022」20日目の記事になります。

株式会社Applibotの長谷部です。
新規プロジェクトでUnityのエンジニアをしています。

現在所属しているチームでは、開発にモブプロを取り入れています。
ただし、自分たちが実施しているモブプロは週に2回、1時間程度実施しているとてもライトな物となっています。

この記事では、ライトなモブプロを実施してどのような効果が生まれたのか、
また、そのやり方を説明していこうと思います。

モブプロとは

まずは、モブプロとはどういうものなのかを説明していこうと思います。

モブプロとは、「モブプログラミング」の略であり、複数人でプログラムを組んでいく手法となります。
二人でプログラムを組んでいく「ペアプロ」こと「ペアプログラミング」はよく知られた手法だと思いますが、三人以上で行っていくのが「モブプロ」となります。

一人がプログラムを書きその他の人が指示出しをしたり、アドバイスをしたりしていく形になります。

プログラムを書く人のことを「ドライバー」や「タイピスト」と呼ばれます。
周りの指示出しをする人や、アドバイスを送る人は「ナビゲータ」や「その他のモブ」と呼ばれます。
（書籍や記事によって呼ばれ方が違ったりします。）

自分たちがモブプロをするに当たり参考にした書籍(※)に従って、
本記事では、「タイピスト」と「その他のモブ」で呼び方を統一していきます。

タイピストは一定時間経過で交代して、皆で回していくことになります。
基本的に、タイピストは勝手にコードを書いてはいけません。
その他のモブの指示に従いコードを書いていくことになります。

モブプロのメリットは一般的に以下のように言われています。

キーパーソンへの依存度が低くなる
チームに「ため」を作ることができる。（複数人が仕事を覚えている状態を作ることができる）
経験の浅いメンバーのスキルの底上げができる
仕事の品質があがる
フロー効率が高い（複数人で考えているので、考え込んで作業が止まったり、休んで作業がとまったりが発生しにくい状態）

自分たちのモブプロの紹介

冒頭でも書いたように、自分たちが行っているモブプロは、「週2回1日1時間」と、一般的に言われているモブプロよりもすごくライトなものとなっています。

これは、各人が担当領域を持っている状態を崩せておらず、自分の作業がある中で実施しているため、取れる時間が限られていることに起因します。
どうしてもプロジェクトの規模感が大きくなっていくと、チームのメンバー数が大きくなり、並列で作業をするほうがメリットが高いという結論になってしまいます。

そんな中でも、モブプロを実施している目的は以下となります。

チームビルドの一貫として実施している
設計思想の共有したり議論したりできる場の提供できる
各人のやり方(エディタツールの設定や、使っているショートカット等)の共有できる
機能や仕様、基盤の作りやその触り方の共有ができる

実施方法の紹介

それでは、自分たちのモブプロの実施方法を紹介していきます。
使用しているツール類は以下のものとなっています。

Slack（チャットツール）
ASTimer（タイマーツール）
GitHub（バージョン管理）
Unity（開発環境）
Rider（エディタ）

モブプロを実施する前に、進行推進役を一人決めておいたほうが良いかと思います。
自分たちのチームでは私が主に進行推進役を行っています。

1. 事前準備（モブプロ開始10分前くらい）

進行推進役がSlackにスレを立てます。
→ 色々メモする用に使います。
メモ：順番、進行用ブランチ名、振り返り、次回やること等

2. その日やることを決める（5分程度）

ある程度事前にやることの候補を上げておく必要があります。
GitのIssue等に、日々やりたいことの候補をあげておくことをオススメします。

3. タイピストの順番決める（1分）

最初はランダムに順番を決めます。
１度順番を決めたらその順番を今後も使っていくと良いです。
最初は毎回ランダムに順番を決めていたのですが、次の順番がわかっていたほうが事前の準備等もできて良かったです。
休み等があれば、飛ばして次の人にまわしています。

4. 実施（45分+切り替え時間）

タイピストは1回15分✕3人で実施しています。
ASTimerをつかって、常に皆に見えるように時間を測定しています。
1人終わったら、エラーがでていてもGitHubにCommit&Pushします。

次の人はPullして開始します。
やりたいことが終わった時点で、プルリクを出します。
一応全員で、再度見直し（つまりレビュー）してOKそうであればマージします。

5. 次回への引き継ぎ（1分程度）

３人終わったところで、次回への引き継ぎ項目等があればSlackのスレに書き込みます。
やりたい項目が１回すべてが完了するとは限りません。
また、毎日実施しているわけではないため次回まで日にちが空くと大体なにをやっていたのか忘れています。
引き継ぎ項目をメモしておけば、次回開始時のスピードが上がります。

6. 振り返り(5〜10分)

KPT（Keep/Problem/Try）で実施しています。
Slackのスレッドに各自が思うKPTを書き、書き終わった時点で各自の振り返りを進行推進役が読み上げていきます。
KPTは以下のようなフォーマットで記載しています。

[K] シンプルに設計しなおしたおかげで、バグ発生箇所がわかりやすくなっていた
[P] 1時間だと時間が足りないことがある
[T] 次回から1時間10分で実施してみる

Tryで上がった事項は実行可能であれば、次回のモブプロから試してみます。
ただし、あまり一度にたくさんの変更してしまうと、変更した効果が見えない場合があるので一つまでとしています。

これまで実施してきたモブプロの題材

モブプロの題材はGitのIssueで上げた内容の対応や、その時チームで困っていることの解決などを主に行っています。
自分たちがこれまで実施してきた題材はをいつくか上げると、以下のようなものがあります。

共通機能の作成（LoggerやSoundService等）
各セクションの間にある作業
設計に対する議論
放置されてしまっているワーニングを除去する
Debug用の機能の設定や作成
各種プログラムのリファクタリング

担当をつけにくいものだったり、全員がわかっているべき内容が題材としては適切に感じています。

これまで出た課題と改善内容の一部を紹介

課題
新規プロジェクトが進むにつれて、エンジニアのメンバーが増えてきた。

最初は4人程度だったのが、10人、11人となるにつれ、以下の弊害が発生してきました。
　・発言しない人が増える（決まった人しか発言しない）
　・内職して聞いていない
　・議論が発散し続けてまとまらない

改善内容
チーム分けして少人数で実施するようにした。

1チーム5人程度までが望ましいと感じています。

課題
1時間だと時間がたりずに振り返りをする時間が取れなくなる場合が出てきた。

計算上は1時間あれば足りるはずと思っていたのですが、実際はタイピスト交換時のロスタイムや、実際に開始するまでにどういうふうに進めていくかを話したりすることが多く、振り返りをする前に1時間を経過してしまい、振り返りができぬまま終了することが多くなってしまいました。

改善内容
あらかじめ1時間10分時間を取るようにした。

10分の余裕を持つことで、振り返りの時間が取れなくなることはなくなりました。
この10分は使い切らずとも、全ての過程を実施できるのであれば早く終わることも許容しています。

課題
１回のモブプロの時間では終わりきらずに、数回続いてしまい、本開発用のdevelopとのバージョンの乖離が大きくなって、マージが大変になってしまった。

改善内容
続きを行う場合は、必ず最初にdevelopの最新を取り込むフローをいれた。

コンフリクトが発生した場合は、モブプロとして解決していくようにしています。