チームとしてモブプログラミングを始めてみました

こんにちは。ウェブアプリケーショングループのエンジニアのましばです。
早いものでもう2022年も終わりが近づいてきました。

今回は、チームでモブプログラミングに取り組みはじめた件について記事にします。

チームとしてモブプログラミングを始めてみました

背景

少し前にチーム体制の変更があり、別々のプロダクトを担当していた2つのチームが合流することになりました。
どうしてもプロダクトに関するメンバーの知識の偏りがあるので、仕様の議論や複雑なタスクの担当などが特定のメンバーに集中してしまうという問題がありました。
そのような状態を解決することを目的として、チーム全員でモブプログラミングを定期的に実施してみることになりました。

進め方

まずは始めてみようということで、メンバーからも意見を聞きつつ以下のような感じで進めていきました。

チームは2週間単位のスプリントで開発を進めているため、スプリントの中で知識の偏りがありそうなタスクを1つ選び、ほぼ毎日2時間ほど実施する。
エンジニアは基本的にフルリモートで働いているので、参加者はSlackのハドル機能やGoogle Meetなどのオンライン上で集合し、ドライバーは自分の画面を共有して作業する。
コードはGitHub上で共有する。ドライバーは自分の番が終わる際にコードをpush、次のドライバーがpullして作業を開始する。
タスク完了後にはメンバーで振り返りを行い、良かった点や改善点を話し合う。

以降は振り返りで出た意見を一部抜粋します。

良かった点

知識の共有

メインの目的であったプロダクト知識の共有については一定の効果があったようです。
個人的にも、他のメンバーの書いたコードを読みつつ自分でも実装することになるので、レビューだけ行ったときよりも理解が深まるという感覚でした。
また、個人で開発していると悩む仕様の相談や実装方法の調査では、すぐ回答がもらえるというのは良かったです。

チーム内のコミュニケーション

エンジニア間のコミュニケーションについても良い効果がありました。
フルリモートで働く都合上、どうしても個々人が分かれて作業している感覚が大きいので、全員で集合してワイワイ開発をやっていくというのは結構楽しかったです。
また、他人のエディタや作業環境を見られて面白かったという意見もありました。

課題

時間や変更の管理

ドライバーの作業時間の管理が難しい(時間計測を忘れる、ちょうどいいところまでやりたくなってしまうので作業時間が延びる)
変更の管理が煩雑になる(ドライバーの交代=コミットなので中途半端なコミットも生まれてログが見づらい)

この部分については、mob timerやmob.shなどのモブプログラミングをサポートしてくれるツールを導入して今後解消していこうとしています。

事前の段取りがもう少し必要

モブプログラミングを実施するタスクについて、「あとは何をやらないといけないんだっけ？」「次に実装するこの機能って何だったっけ？」などの疑問にぶつかり、時間を浪費してしまうことがありました。
また、日を空けて次回のモブプログラミングを実施することもあり、「前回何をどこまでやったっけ？」と思い出す工程が挟まって最初のドライバーはほとんど作業が進まない、みたいなこともありました。

今後は、モブプログラミングの一番最初に仕様の読み合わせや作業項目のリスト化といった事前準備をして、各回の作業前には必要に応じて前回の振り返りを行うことなどを考えています。

その他にも、「ドライバーが詳しい場合は作業を眺めるだけになってしまう」「モブプロの参加は絶対か」などと言った課題が挙がり、このような部分は取り組み方をルールとして明文化して育てていこうとなりました。