前置き

しがないラジオまだ「仕事分担」で消耗してるの？楽しいモブプログラミングの正しい使い方
https://shiganai.org/ep/sp39b-takaking22

fukabori.fm モブプログラミング 60分間1本勝負
https://fukabori.fm/episode/6

最近聞いた上記のpodcastでTAKAKING22さんをゲストに迎えて、モブプログラミングの話をしていた。
これまでにモブプログラミングはおろかペアプロさえしたことがなかったので、大変興味深い内容だった。
今後の自分に向けてメモを残しておく。

以下、podcast内で挙がったトピックの内、なるほどと思ったことなど。

モブプログラミングとは

2人以上（5人くらいまでがちょうどいい？）の人数で1台のPCを使い”全員で”プログラミングをする
キーボードを操作する人はドライバ、指示を出す人がナビゲータ

メリット

関係者全員が集まって開発を行うことで各メンバーの知識を存分に活かすことができ、迅速に開発を進めることができる。
また、各メンバーの得意分野やノウハウなどを共有できるので、チームメンバー全員の成長が期待できる。
仕様の不明点があった場合もその場で解決することで、遅延や誤解をすることなく開発を進めることができる。

モブプログラミングとコスト

全員で集まって作業するって、めっちゃコストかかるんじゃない？

コストの面で「人件費高くつかない？」という疑問は出てきがちだが、ブログラミングの前後に発生する「認識合わせのためのミーティング」や「ソースコードレビュー」、「ソースコードのマージ」、「仕様認識齟齬があった場合の手戻り」などが発生しないので、実はそれほど人件費が高くつくわけではないらしい。なるほど。

モブプログラミングが向いていること

誰がやっても同じに結果にならないこと
知識やノウハウの共有が活きること

プログラミングは基本的には書く人によって癖や思想、能力の差がでるので誰がやっても同じにならない部類のものだと思う。
全員で知識を出し合いながらプログラミングを進めることで、全員の知見が集約された品質の良いコードになる。

また、環境構築で手順書など残すことは多いが、上手くいかないこともかなり多い。
手順書を作った人が試行錯誤した内容を一部書き忘れていたり、手順書の内容が古くなっていて手順通りいかないなんてことを経験した人は多いと思う。
モブプログラミングで環境構築を行うことで、手順書ではなく、失敗を含めた経験を全員で共有できるので、全員に失敗の経験がたまるし、新規で誰かがチームに加入した場合も円滑に環境を作る（一緒に作る）ことが可能になる。

モブプログラミングの向いていないこと

誰がやっても同じ結果になること

調査とか、決まりきった運用など誰がやっても同じになることは分担して並列で終わらせた方が効率がいい。

実はあれもモブプログラミング

トラブル対応

何かしら緊急度の高いトラブルが発生した時は関係者全員で一丸となって早期のトラブル解決に動くことがある。実はあれもモブプログラミングと同じということは新鮮な気づきだった。
自分はモブプログラミングをやったことない気でいたけど、実は同様のことをやっていて、モブプログラミングの考え方はかなり応用が効くんだなということに気づけた。
振り返ると、別の組織の経営などしてる方達とトラブル対応の研修や演習をした時に「まずは関係者全員集める！それが一番はやい」って言ってたのもモブ的発想だったんだろうな。

最後に感想など

「モブプログラミングやっていいですか？」じゃなくて、「やっちゃえばいい」というアドバイスも新鮮だった。
「会議室にみんなが集まって会議するのもかかる工数は変わらないでしょ？」というのは今まで思いついていない発想だった。むしろ会議だと集中してない人が一定数いるので、会議よりもモブプログラミングの方が費用対効果が良いかもしれない。

今の自分の業務は個人で行うことが多く、知識やノウハウの共有が課題として挙げられることも多い。
今の環境にモブ的要素を取り入れて、課題を解決することができないか検討していきたい。