こんにちは、エンジニアのりさきゃんです！

最近、開発チームでモブプログラミングという開発手法を取り入れました。この記事では、モブプログラミングをすることになった経緯と実際やってみて感じたメリットを紹介したいと思います。

モブプログラミングのきっかけ

おかげさまでエンジニアの採用もうまくいきはじめ、下半期は合わせて7名のエンジニアが開発にジョインしました。🎉🎉🎉 (※ まだまだ募集中です! )

様々なレベルのメンバーが入社する中、安定的に機能開発をしていくためには Rails のレールに乗った開発を続けていくことが大切です。 SmartHR では Ruby on Rails プロダクトの開発を望ましい状態のまま続けていくことを目的として、2018年7月に技術顧問の willnet さんをお招きしました。willnet さんにはペアプログラミングを通じてRuby on Rails 開発のベストプラクティスを教わっていました。

willnetさんとのペアプログラミングを通じて、後から見返した時にテストの意味が伝わりにくい（＝可読性の低い） RSpec の書き方をしているというレビューをいただきました。本来であれば開発チーム内でのレビューで指摘が入るはずでしたが、可読性の高いテストを書くための指標をチーム内で共有していなかったため、周辺のコードを真似てテストを追加し、パスしたらマージして終わり。テストコード自体はレビューしないといった状況になっていました。

さらに、ペアプログラミングの内容もチーム内で共有できていなかったため、ペアプログラミングのたびに willnet さんが同じことを繰り返し言わなければならない状況が発生していました。そのため、willnet さんから「解決策としてチーム単位でモブプログラミングを導入してみてはどうか」と提案していただきました。

モブプログラミングとは

モブプログラミングとは3人以上のエンジニアで1つのプログラムを書く手法です。1人がコードを書き、他の人はディスプレイに映した画面を見ながらやいのやいの意見を言って、プログラムを完成させます。コードを書く人をドライバー、意見を言う人をナビゲーターと言います。

モブプログラミングやってみた

先述の可読性の高い RSpec の書き方を全員で学ぶため、エンジニア全員参加、ドライバーは4名を交代交代にて行う形式で、今月、SmartHR初の社内モブプログラミングを開催しました。

開催後の振り返り会では「よかった」との声が多かったものの、「人数が多すぎると発言や質問をする機会が少なくなってしまう」という問題も上がりました。そのため、「まずは少人数のチームでモブプロをやってみよう」ということになり、私たち雇用契約機能開発チームは3人でモブプログラミングにトライしてみました。

モブプログラミングのメリット

モブプログラミングをやってみて感じたメリットを紹介します。

知識や経験を共有できる！

経験が少ないメンバーにいわゆる Ruby や Railsっぽい書き方や、実用的なイディオムを最速で伝授できます。実装過程を見せることで、ハマりやすいポイントやサービス特有のドメイン知識なども共有できます。一緒に実装した経験があるためあとから思い出しやすく、「モブプロでやったやつ」という共通認識にできるという利点もあります。

レベルにかかわらず全員が同じ課題に触れられる!

開発チームにはインターンから ISUCON入賞者、技術誌寄稿者、Vimプラグイン開発者まで様々なレベルのエンジニアがいます。モブプログラミングでは、個々人のレベルにかかわらず全員が同じ課題に触れられます。同じ課題に対する他者の解決方法を知ることで自分に抜けている視点に気づき、成長のヒントになります。

フラットな雰囲気になりやすく、最大知を引き出せる！

モブプログラミングはペアプログラミングでありがちな、1対1の「教える人」「教わる人」の構図にならないため、フラットに意見を言い合う環境を作れます。ナビゲーター全員が発言できる環境を作ることで、その場のエンジニアの知識を総動員して課題を解決できます。

つらみが分散されるので、面倒なコードにも立ち向かえる!

モブプログラミングだと常にまわりに頼れるので、ひとりでやるには気が重いタスクもやりきれます。例えば、大量の画面遷移と条件分岐をともなう system spec の新規作成です。気が重くなる作業ですが、分岐するポイントをチーム全員で出しつつ遷移を確認することで、specを書き終えられました。また、障害やトラブル対応の際も、モブプログラミングで行うことで、暗黙知にせずノウハウを共有できます。