リモートワークから始めるモブプログラミング

前説

この記事は GRIPHONE Advent Calendar 2020 7日目の記事です。

皆さんこんにちは。サーバーサイドエンジニアの鑓水です。

私たちのプロジェクトでは最近モブプログラミングを導入して、早三ヶ月ほど経過しました。ちょうど全社的にリモートワークを採用している時期だったので、初めからリモートワークに適したやり方で行ってきました。
今回はどのようにワークフローにモブプログラミングを導入したのか、経験してわかったメリット・デメリット、リモートワークへの適応の仕方を紹介したいと思います。

モブプログラミングとは

モブプログラミングとは、

3人以上のエンジニアで1つのプログラムを書くという開発手法です。

モブプログラミングの詳しいやり方についてはこの記事を参考にしていただけたらと思います。

また、モブプログラミングの風景に関してはこの動画をみていただけると雰囲気がわかるかと思います。

なぜモブプログラミングを導入したのか

私たちのプロジェクトではスプリントを用いた繰り返し開発を行っています。

1スプリントで複数のタスクを開発する際に、各職種の作業順がバラバラで待ち時間が発生していました。

そのためすべてのタスクがsprintの最終日ギリギリまで完了せずに、その後のマージ作業やデバッグ作業に影響が出ていました。

※いつまでも作業が終わらないの図

その対策として、チームの作業にWIP制限を設けることで待ち時間を減らし確実に一つ一つタスクを完了させることにしました。
その際、クライアントよりもサーバーサイドのほうが人数が多いため、必然とサーバーサイドエンジニアはペアプログラミングやモブプログラミングをすることになりました。

※一つずつ確実に作業が終わるの図

どのようにモブプログラミングを行ったか

モブプログラミングを行うと決めた時期はコロナによる緊急事態宣言が発令され、会社がリモートワークへ移行した直後くらいだったため、
リモートワーク下でのモブプログラミングとなりました。

モブプログラミングのやり方

リモートワーク下でのモブプログラミングは以下の流れで行いました。

1sprint内のタスクでどのタスクをモブプログラミングで行うかを事前に話しておく
朝そのタスクを、その日にどこまでやるかを計画する。
ドライバーを決める。ドライバーはZoomで部屋を作成し、画面共有をする。
セッションが終わったらドライバーを交代し、zoomを立ち上げ画面共有する。
2セッション終わったら休憩を取る。15 ~ 20分くらい。
定時になったらその日の振り返りをする。

ツール紹介

リモートワークでモブプログラミングを行った際に使ったツールは以下になります。

Zoom
公式サイト
画面共有ツールにZoomを採用しました。理由は弊社でのリモート会議にZoomを採用していたためです。
無料版では複数人での利用が40分制限があるので、そこに関してはストレスを感じることはあります。
ほかの画面共有ができるツールであれば代替は可能です。

IntelliJ
公式サイト
私の所属するプロジェクトではサーバーサイドエンジニアのエディタはIntelliJに統一しています。
オフラインでのモブプログラミングだとエディタ問題があるのでエディタが統一されているとメリットを享受できますが、
リモートワークでは画面共有が主になるのでエディタ問題は自然と解消されますね（笑）。
ただ、IntelliJがリリースしたプラグイン「Code with me」https://plugins.jetbrains.com/plugin/14896-code-with-me
は画面共有なしでソースコードが共有できるのでこの機能は便利です。

Discord
公式サイト
音声通話ツールとしてZoomと併用して使っていました。使い分けとしては画面共有はZoom、音声はDiscordという感じです。

音声がZoomだけだと、Zoomが切れた場合に会話が途切れてしまいなんとも言えない空気になります。

40分で切れるZoomのストレス緩衝材として機能していました。

Cuckoo
公式サイト
モブプログラミングではタイマーが重要なので、タイマーを共有できるサービスであるCuckooを使用しました。

モブプログラミングを実践してわかったこと

初めてモブプログラミングを導入して実感した効果と課題を紹介したいと思います。また、リモートワークにおけるモブプログラミングのメリットとデメリットも合わせてご紹介します。

私たちのチームでの効果

コーディングのノウハウを共有できた。
変数名や設計で悩む時間が短くなった。
コードレビューのコストが小さくなった。
総合してタスクの推進力が向上した。
定時で仕事を終えようという空気になった。

リモートワークでの効果

リモートワークでもコミュニケーションは多くなった。
そのため誰が何をやっているかわからないという状況がすくなくなった。

私たちのチームでの課題

モブプログラミングをやらなかったメンバーとの情報格差が生まれてしまった。
意識して考える時間を取らないと、よくない設計でどんどん進んでしまう。

リモートワークでの課題

ネットワークやPC性能など、個人の在宅環境に作業効率が依存してしまう。

最後に

私たちのプロジェクトにおけるモブプログラミングの導入の背景と実践方法を紹介しました。
モブプログラミングは実践よりも導入のほうがハードルが高いと思います。
私たちは初めからフルタイムモブで行いましたが、
「俗人化している部分だけノウハウ共有をする」という目的で
まずは1日、数時間だけだけモブプログラミングを始めてみるのも良いかと思います。きっと新しい発見があるはずです。

それでは

前説