2019年11月に，外壁塗装業者紹介サービス「ヌリカエ」の開発チームにjoinした竹井です。

ヌリカエ開発チームにjoinしてからほぼすぐにモブ・プログラミング (以下，モブプロ) を行ってきました。
モブプロを3ヶ月ほど経験したので，自分なりに見えてきたモブプロのメリット/デメリットをまとめ，2点ずつ挙げてみたいと思います。

なぜモブプロ?

そもそもモブプロを始めた背景としては，チームメンバーの1人が「こういう手法のプログラミングがあって，興味があるからやってみよう!」と発言したのが始まりです。

その時に出ていた目標に対する主な課題として，「個々にIssueがアサインされた結果，開発背景が分からずレビューの難易度が上がる」というものがあり，これを解決する手段としてモブプロを行い，チームメンバー全員で開発背景を理解し，チームメンバー全員で1つのIssueに取り組むことにしました。

元々DBにテーブルを追加したりする作業などはペアプロで行っていたのですが，基本的な開発は1人1つのIssueを行う，いわゆる普通のプログラミングで行っていました。

一番最初のセッションは「モブプログラミング・ベストプラクティス」という書籍を参考に，モブプロにはどういうメリットがあるのか? や，チームとしての進め方を共有してもらって，取りあえず始めてみて，1日毎にKPTで振り返り，改善をしていく。というサイクルでアップデートしつつ始めていきました。

今回は特に自分が強く感じたメリット/デメリットを挙げますが，他にも細かいメリット/デメリットはあるハズです。
一度チームリーダや，モブプロを率先して提案，運用したい人1人だけでも良いので「モブプログラミング・ベストプラクティス」を読んでみてから開始すると良いと思います。

モブプログラミング・ベストプラクティスソフトウェアの品質と生産性をチームで高める

作者:マーク・パール
発売日: 2019/02/23
メディア: 単行本

ヌリカエチームでのモブプロ

ルール

ドライバーは基本的には1人20分〜
- 時間厳守。キリの良いところまで進めたりせず，途中でも交代をする
- 最初は git push できるキリの良いところまでやっていたが，それが延びに延びて1ドライバーで1時間経つことがあったために時間厳守としました
交代は決まった順番で行う
- 今日は右周り。とか，今日は左周り。とか
1セッションは2時間
- 1人20分で，これを6回行うまでが1セッション
- 1セッション回ったら5分の休憩
- 1日だいたい2〜3セッション行う
- 離席は，ドライバーでない。なおかつ長時間にならないものであれば可
  - こちらは水をちょっと取りに行きたい。ちょっとゴミを捨てたい。とかに柔軟に対応できるように設定しました
  - が，長時間の離席 (MTGとか) は事前に共有してモブプロに出れない事を伝えあうことにしていました
プロジェクタなどで投影は行わない
- 4K ディスプレイ2枚を使用し，チームで肩を寄せ合ってディスプレイを共有で使う
- ディスプレイの出力設定は「ミラー」にしておく
  - 1画面の内容を繋げているディスプレイ全てに反映させる
PCは共有のモブプロ用PCを使う
- モブプロ開始当初は個人PCを使っていましたが，交代の際の git 操作とディスプレイケーブル x2 の抜き差しの時間を短縮させるために導入
  - また，環境毎による操作や，コマンドの違いを失くし指示しやすくなるように導入
- 共有PCの設定は基本的にはバニラ状態を保つこと
  - 設定で意見が分かれたら投票によって，多数決で決定する
- アプリを入れたい場合はその場で相談
- Chrome, VSCodeのExtentionなどは基本的には自由に入れてOK
  - ただし，キーバインドや動作を大きく変更するものなどは要相談

だいたいこんなルールで行っていました。
所々ルールも見直し，改善が入っていて，よりよい環境でお互いがストレスなく開発しやすいように整えました。

メリット

1.バグの少ないコードが書ける

モブプロでは，参加者がそれぞれの知恵を出しながらコーディングするため，コードを書いている間にも常にレビューが入っているイメージが近いのですが，1人で書いていたら気付けなかったであろうバグや，影響のある機能なんかも開発中にお互いにツッコミをしながらコーディングすることになります。
それをその場で指摘して頂きすぐに修正できることは凄く良かったです。

私だけでは気付けなかったことも多々ありますし，逆にjoinしてすぐだった自分の意見によってより良いコードができた場面もあります。

これは長くプロダクトに携わっている方はもちろん，そうでない方が参加することも大きなメリットになると思います。

2.レビュータイムが短くなる

上でも書いた通り， コーディングをしながらレビューが行われる に近いことが起きます。
これを過信してレビュータイムを全く失くすことはありませんでしたが，コーディング中にレビューが同時並行して行われ，コーディング中に同時に複数人からのレビューを受けることができるようになります。

作業が終わったらPRを上げた段階でもう一度モブプロ参加者全員で目を通すのですが， コーディングの意図，背景も理解しつつレビューに入ることができる ため，最後のPRレビューも含め，全体的に見てもレビュータイムの短縮が起こります。

よくモブプロをしていると「全員で1つのIssueやってるの? 1人1つのIssueをやればもっと多くのIssueができるよね?」と質問されることがありますが，これに対するアンサーに近いのかもしれません。
レビュータイムまでを包括した時間であり，よりバグが少なくなるため，バグが出たときの出戻りの時間も短くなります。
そう考えると，全体的に見た効率で言えばむしろ上がっていると感じます。

デメリット

1.自分の作業環境が使えない

共有PCの導入は前述したように

環境毎による操作，コマンドの違いを失くし，指示しやすくなるように導入

したのですが，反面自分にとっては一番と言ってもよい程のデメリットであったことも事実でした。

自分のターミナルはzsh。
エディタはVSCode。背景は痛くカスタムしていて，エディタのキーバインドはVimに変更。
日本語入力はSKK。
マウスのボタン操作ももちろん，トラックパッドもBTTで動作を変更しているし，ディスプレイは左右の真ん中を繋ぐのではなく，画面の端を繋ぐ。
(伝えにくいけれど，左右にディスプレイがあって，左のディスプレイから右のディスプレイにマウスカーソルを動かすときは，左のディスプレイから右端にカーソルを持って行くと右のディスプレイの左端にカーソルが来るのではなく，左のディスプレイから左端に動かすと右のディスプレイの右端からマウスカーソルが出てくる。みたいな)

という，1つどのデバイスやアプリにしても，とてもとても変態ちっくな環境で過ごしています。今ふと思い返せばなんでこんな設定に馴染んでしまったのだろう……。

でも，こういった設定や環境に拘る方が居ると共用PCでのモブプロは辛いものになってしまうのかな。と感じました。
最初は個人個人のPCをディスプレイに繋ぎ直してやっていたため気にはならなかったのですが，共用のPCを使いだしてからはその字の通り まともに日本語入力ができなくなる レベルで作業ができなくなりました。

慣れないエディタの操作でミスをしたり，ドラッグ&ドロップも操作が異なっていて，その細かい1つ1つの動作が咄嗟にできず非常にストレスが溜まりました。
だからと言ってモブプロ用の共用PCに自分の設定を全て持って来れば自分以外がストレスを溜めてしまいます。

今回は自分が折れてモブプロをしていましたが，こちらはチームメンバーで話し合ってルールを決めたり，いっそ共用のPC使用を止める。などすれば回避できる問題ではあるかもしれません。

2.わかった気になってしまう

私がモブプロに参加したときはjoinしたてでまだプロダクトの全体像などを理解しておらず，DBの繋りがどうなっているのか。などもわかっていませんでした。
つまり，例えばヌリカエだと「案件」は他にどういうテーブルと紐付いているのかとか，「クライアント」はどういう情報を持っていて，それぞれの「支店」はどういう情報を持っているのか。などを理解しないままに始めてしまい，モブの指示を「そうなんだ」とわかった気になってコーディングしていました。

そのときは「ふむふむ。こことここが繋っているんだな」くらいの認識でしたが，改めて自分一人でコーディングをしようとしたときに全然覚えておらず，「わかった気になっちゃっていた」のだと気付けました。

これはテーブルの情報だけとかではなく，変数の命名とかでもそうです。
プロダクトによって「成約」の変数名が決まっていて特に疑問にも思わずに指示通り書いていたが，一人で「成約」にまつわる機能を追加することになってふと定義した変数名が他とは異るものを使ってしまっていたり。

反省点

作業時間に気を付ける

モブプロをやっていると，ついついあれもこれもやりたくなってしまって作業の時間が延びてしまいます。
最初始めた頃は「もう少しだけだから」と，ドライバーの交代時間も守らずにずっとコーディングしちゃっていたくらいです。

モブプロでは，ドライバーはもちろん，モブも気を抜かずにソースを見て，指示しつつ，指示していない人も集中し続けないといけません。
ですので，ちゃんとした休憩の区切りを意識して守らないと，ドッと疲れちゃいます。

他のチームではポモドーロを導入し，それに合わせて休憩を取る。としていたのですが，ヌリカエ開発チームでは，ドライバーの交代時間は20分。で，6回行なう = 2時間コーディングが1サイクルとなっており，その後5分休憩。もう一度1サイクル2時間コーディング。というタイムスケジュールでした。
これに対してはもう少し小刻みに休憩があっても良かったのかな。と感じました。

皆さんも，モブプロしていてもしもキツい。と感じることがあれば，人数が多ければ気軽に離席できるようにするとか，人数が少なくって気軽に離席されるのも困る場合は休憩時間を短かめに設ける。などしても良いかもしれません。

モブプロをしない日があっても良かったかも

モブプロの及ぼすメリットが大きいことは確かなのですが，前述した「わかった気になっちゃっている」にも長いこと気付けなかったりします。

それ以外にもモブプロをしないとわからない。気付けないことがあるように，モブプロを始めてからこそ個人の開発で気付くこともあると思います。
息抜きの意味でも良いので，たまには個人で開発する時間や日，週を設けると良いかもしれません。

チーム全員が本当にモブプロに慣れれば個人の時間は必要ないかもしれませんが，個人開発だからこその価値もあると思います。

まとめ

2点ずつ，メリットとデメリットを挙げました。
また，もっとこうすれば良かったかな? と思ったものを反省点として挙げました。

デメリットの部分は如何ようにも回避が可能であり，それに比べたメリットの大きさはすさまじいものがあります。
今回元々解決しようとしていた問題はモブプロによって解決しており，また，今後引き続きモブプロを行う上での反省点も見えてきたため，これらの改善を行いつつ適宜モブプロを行いたいと思いました。

特にレビューにコストがかかってしまっていたり，レビューの時間がなかなか取れずに疎かになってしまっていたり。
技術/機能毎の属人化が起きつつあるチームにとっての改善アクションとしてモブプロを導入することはとても良いものだと感じました。
皆さんもチームによって運用を変えつつ，レッツ! モブプログラミング!