リモートモブプログラミングのアンチパターン

こんにちは。ASKUL ごましおらぶです。

ここ数年でよくモブプログラミングという言葉を耳にしませんか。
モブプログラミングの基本的なコンセプトは、問題解決のために複数の人が
"同じ" ことを
"同じ" 時間に
"同じ" 空間で
"同じ" コンピュータで ( 引用: Woody Zuill )
と言われています。

2020 年の現在、多くの人が在宅勤務になった今
モブプログラミングを実施するときは
"同じ空間" は、 → グループ通話に
"同じコンピュータ"は、→ 画面共有機能に
変わっているのではないでしょうか？

私が所属するチームの中でも、ここ約 2 ヶ月の間、数回 "リモート"モブプログラミングを実践しました。
そこから気付いた "リモート"モブプログラミングの アンチパターン の話をします。(この記事では、 ベストプラクティス の話はしません。)

アンチパターン (1) : 顔が見えない状態で実施する

モブプログラミングはコストが高いです。なぜなら、複数の人が "同じ" ことを / "同じ"時間 に着手するからです。
カメラを OFF にすると、視線や仕草を利用した円滑なコミュニケーションができません。

アンチパターン (2) : 参加人数が多すぎる

現実世界の会話と違い、グループ通話では複数の人が同時に発言すると非常に聞き取りづらいです。
また、参加人数が多すぎる場合、個々の雑音や接続不良トラブルも起きやすくなります。
その結果、待ち時間のロスが頻発したり集中力が切れたりするので、効率が悪くなります。
(チーム特性もあるため何人以上だとNGとは言えませんが、私のチームでは3~4人規模でスムーズでした。)

アンチパターン (3) : ドライバーの環境が動かない

※ ドライバーとは？　=ナビゲーターのアイデアを聞いてキーボードを打つ人のことです。ナビゲーターはドライバー以外の全員です。

リモートの環境では、物理的に全員が "同じ" 空間 にいることができません。
また、 "同じ" コンピュータ を利用することも難しいです。
そのため、以下のような流れで進めることが考えられます。

・事前に Git 上に作業用のブランチを作成
・タイマーを 10~15 分設定
・ドライバー が画面共有/コーディング
・タイマーが鳴ったら、差分をcommit / push
・ドライバーを交代して、差分をpull

この流れですと、 "同じ" コンピュータを利用しないため、コードを書く途中で動作確認する環境は
その時その時のドライバーの個人の環境になります。

自分がドライバーになった時に、事前準備が足りなくて環境が動かないと想像してみましょう。
たった 5 分止まっても、参加人数*5 分になるので、多くの時間ロスになります。

アンチパターン (4) : コミットが汚いことを気にする

"同じ" コンピュータを利用しないリモートモブプログラミングを実施する場合、ドライバーが変わるたびにpushとpullが発生します。自然とコミットは多くなり、かつ小さくなります。
複数のコミットをまとめて 1 つのコミットにする squash merging をすれば解決します。
気にせずスピーディーに進めましょう。素早く ドライバー 交代することを優先しましょう。

アンチパターン (5) : エディターの画面共有、むしろ時間かかる

ドライバーが代わるたびにpushとpullする時間が削減できないか？という思いから、
VSCode live share や Teletype for Atom とったリアルタイムでワークスペースが共有できるツールを利用してみました。
エディターの画面共有は、一人のホストが自分のワークペースを共有するため、共同編集を可能にします。
ドライバーを交代するたびにpushとpullする作業が削減できるため確かにスムーズです。

しかし、エディターの画面共有のワークスペースを共有している人だけが最新のコードを持っているため、
ローカルで動作確認できるのもホスト 1 人だけになります。
画面共有を 1 回取り消してホストが動作を見せ、ドライバーがまた画面共有する手間が発生します。
また、Teletype for Atomの場合ですと、ワークスペースを共有をはじめるためには
GitHub とのアカウント連携が必須になります。
もし、会社がGitHub Enterpriseを利用する場合、GitHubへの新規アカウント発行 or プライベートアカウントの連携が必要になります。
会社によってはセキュリティなどの問題で NG になることもあるでしょう。

アンチパターン (6) : 無計画にモブプログラミングを行う

リモートではなくても当てはまる話ですが、解決したい問題が明確ではないまたは
通勤が発生しない分、時間感覚がルーズになりダラダラと永遠とゴールのないモブプログラミングする…は避けましょう。

最後に

参考までにリモートモブプログラミングで利用したツールの表です。

準備するもの	通常	リモート
空間	会議室、フリースペース	画面共有 ( Slack, Zoom )
モブ用マシン	誰かのマシン 1 台	ドライバー各自のマシン (ドライバーを交代時 push/pull 実施)
モブタイマー	ウェブやスマホのタイマー	ウェブやスマホのタイマー
エディター	IDE またはエディター	IDE またはエディター
TODO を書くもの	実物のホワイトボード	ウェブのホワイトボード ( Microsoft Whiteboard )
振り返り	付箋	ウェブの共同編集 ( Confluence, SharePoint )

モブプログラミングで得られる利点は、多いです。
・ プルリクエストレビュー の省略により 待ち時間/再修正/再レビュー の削減
・各自の得意ナレッジから早期に問題解決
・複数の ドライバー で交代して取り組む際に、ショートカットや便利ツールを吸収することで業務効率化
などが期待されます。

リモートモブプログラミングのアンチパターンを最小限にして
物理的に離れていても生産性を下げないチーム開発を目指していきましょう。