システムアイ Advent Calendar 2022 の記事となります。
はじめに
私が現在参画しているプロジェクトの開発チームは、基本的に全メンバーがリモートワークということで、会議ソフトを常時接続した状態で活動しています。
このプロジェクトでは若手メンバーの育成・開発スキルアップも主要な目的であることから、開発は「モブプログラミング」という形で行っています。
そこで、この記事ではオンラインでのモブプログラミングのやり方や、その際に私が感じた注意点などについてまとめてみました。
モブプログラミングとは
まず、「モブプログラミング」（以下「モブプロ」）とは 3人以上 のメンバーが1台のPCの前に座って協力しながら開発を進めていく開発手法です。
2人で一緒に開発を行う「ペアプログラミング」（同「ペアプロ」）は割と定着している感がありますが、それの「3人以上」版です。
ただし、単純に人数の違いだけではなく、モブプロにはペアプロと比べて以下のようなメリットがあります。
- 問題が手詰まりになったときの解決方法が見つかりやすい。
→複雑な問題を解決するには1人や2人よりも3〜5人いた方が良いという研究結果があります。いわゆる「三人寄れば文殊の知恵」というやつですね） - 意見の食い違いがあっても「自分が否定される」という感じが少ない。
→意見の相違があった際、ペアプロの場合は1対1で対立する構図になってしまいますが、モブプロは複数人がいることから「対立」というより「議論」に向かいます。 - ペアプロよりも中断しにくい。
→ペアプロの場合は相方が中座すると即座に作業がストップしてしまいますが、モブプロではメンバーの出入りによって作業ができなくなってしまうことはありません。 - コードが書かれると同時に複数人によってレビューされるため、製品の品質が上がる。
→早い段階で欠陥を修復できることで、後でバグフィックスをするよりもコストが低く済みます。
また、これはペアプロでも言えることですが、一緒に開発を行うことでチーム内の経験の浅いメンバーのスキルが早く引き上げられます。リモートワークの場合は特に、新人が一人で不安を抱えながら開発するよりも、他のメンバーのやり方を見ながら進められるメリットは大きいと思います。
モブプロについては、そのことだけで丸々1冊書かれた『モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める』という書籍があります。こちらを読めばモブプロに関する大抵のことが書かれています。
なお、ペアプロではコードを書く人を「ドライバー」、横に座ってレビューする人を「ナビゲーター」と呼びますが、上記書籍の著者であるマーク・パールは、モブプロでは前者を「タイピスト」、それ以外の周囲のメンバーを「（その他の）モブ」と呼ぶことを提唱しています。以後、この記事でもその呼称にならいます。
※この呼び替えの理由についても書籍内に書かれています。
（余談）上記書籍ではモブプログラミングをすることを「モビング（mobbing）」と表記していますが、これは社会学的用語として「モラルハラスメント」を指す言葉でもあるようです。特に私自身はその意味で使用されているのを見聞きしたことは無かったのですが、他のモブプロに関するQiita記事で知りました。
コードの共有
オフィスなどのオンサイト環境でモブプロを行う場合、全員が一堂に介せられる部屋と1台のPC＆モニターがあれば準備OKですが、開発メンバーがそれぞれリモートワークしている状態でモブプロを行うには、オンラインでコードを共有できる開発環境が必要になります。
コードのコラボレーションツールはいくつかありますが、普段の開発にVisual Studio Code（以後、VSCode）やVisual Studioを利用している場合は、Live Shareが第1の選択肢になるかと思います。
※IntelliJ や PhpStormであれば「Code With Me」、Eclipseでは「Saros」といったコード共有のためのプラグインが提供されています。
https://visualstudio.microsoft.com/ja/services/live-share/
VSCodeにLive Shareの拡張機能をインストールし、GitHubアカウントかMicrosoftアカウントでサインインするだけで使用できます。
※厳密には、接続するマシンにおいていくつかの接続要件があり、Microsoftが指定する特定のURLへの通信経路が必要です。
Visual Studio Live Share | Live Share の接続性要件
Live Shareでは、エディタの共有だけでなくサーバーを共有することも可能です。Live ShareのホストがVSCode上でWebサーバーを起動すると、シェアしている他のメンバーも http://localhost:3000 などのURLでサーバーにアクセスできるようになります。
アプリにアクセスした際のログも共有しているVSCodeのターミナル上に出力されるため、開発者間で会話をする上で非常に便利です。
ターミナルを「read/write」モードで共有すると、ホスト以外のメンバーがターミナル上で任意のコマンドを実行することもできるようになります。
ただしホストの環境で任意の操作ができてしまうことになるため、こちらはリスクを考慮したうえで設定しましょう。
また、Live ShareではVSCode上でチャットすることも可能ですが、会議ソフトで繋いでいる場合は会議ソフトのチャットを使用するのでも良いでしょう。
モブプログラミングの準備
ビデオ会議をしながらLive Shareでモブプロを行うには、いくつかの準備が必要です。
「なんだそんなことか」という内容ばかりかもしれませんが、オンラインのモブプロにおいてはこれらの環境や設定の違いが「チリツモ」で開発効率に大きく影響してきます。
参加者
オンサイト環境では5～6人でのモブプロも可能ですが、オンラインでは3～4名が妥当です。それ以上になると、会話がぶつかったり、逆に全く喋らないメンバーが出てくる可能性が高いです。
モニタ
開発中はビデオ会議の画面とLive Shareの画面を両方見ることになるため、複数ウィンドウを同時に閲覧できるサイズのモニタ、もしくはデュアルモニタ環境が必要です。基本的にはタイピスト（コードを書く人）が自分のVSCodeを画面共有する形になりますが、他のモブメンバーは共有された画面だけではなく、自身の手元で別のコードを見たい場面が必ずあるため、2つのウィンドウをウォッチできた方が良いです。
通信環境
開発中はビデオ会議とLive Shareによるデータ通信が行われるため、それなりのネットワーク帯域が必要です。私が関わったプロジェクトでは、通信環境が悪いメンバーにおいて「Live Shareに入れない」「ビデオ会議で共有している画面とLive Shareで見ている内容にずれが生じる」などのトラブルがありました。
ただでさえオンラインでは、コミュニケーションにおけるロスやラグが発生しやすいため、一部のメンバーの接続を待ったり、画面共有に不都合があると全員に無用なストレスが生じます。できるだけ快適な通信環境を確保しましょう。
エディタ環境
前述のとおり、大抵はタイピストが自身のウィンドウを画面共有することになりますが、その際できるだけエディタ領域を広くとることをお勧めします。
私がよく気になるのはVSCodeのMinimapです。画面サイズの小さい人だと、ことさらエディタ内に占めるMinimapの領域がバカになりません。画面共有中はMinimapを非表示に設定しておきましょう。
ワークベンチの下部にある「ターミナル」などを表示するパネルも、サーバーの出力などを共有したい場合以外は閉じておくと良いでしょう。画面共有で映っている領域の「もう少しだけ下のコード」を見たい、という場面は思いのほか多いです。この時、ターミナルが邪魔で見えない状態は結構ストレスです。
フォーマッター、エディタ関連の設定
リモートワークやモブプロに関わらず「チーム開発」をするうえでは当たり前ではありますが、利用するフォーマッターやエディタの設定はメンバー内で統一しておきましょう。Live Shareのホストによって異なるフォーマットが適用されてしまっては困ります。
画面共有上でも気付きやすいように「全角スペースを強調表示する」設定や、「文末の空白を自動でトリムする」設定なども入れておくと良いでしょう。
その他、キーボードに強いこだわりがあったり独自のキーバインドを設定しているような場合、「オンサイトでのモブプロと違って自身のキーボードを使えるから嬉しい」ということもあるようです。（オンサイトのモブプロでも、各自がキーボードを持ち込んで切替器を使用すれば良いですが）
オンラインでのモブプログラミングの実践
モブプロでは、タイピストに対してモブが指示を出す形でコーディングを進めていきますが、オンラインではこの「指示出し」がなかなか難しいところがあります。
オンサイトであれば、視線や動作で、ある程度他のメンバーの思考や意図が読めますがオンラインではそういうわけにいきません。
そのため、モブがタイピストに指示を出す場合は、該当箇所を「明確に」指し示す必要があります。
具体的には "xxファイルの何行目" という形です。”そこ” とか "もうちょっと上" などと言っても、タイピストが自分と同じところに視線を向けているとは限りません。"括弧が1つ足りないよ" と言われても、どこのことなのか / 丸括弧なのか中括弧なのか、言われた側は案外分からないものです。
コーディングスキルの高い人や経験の長い人ほど、自分の頭の中では実装のイメージができている分、タイピストへの指示が言葉足らずになりがちです。
反対に、チーム内の「エキスパート」がタイピスト役になった場合、タイピスト自身によって問題が即座に解決され、他のメンバーはただそれを見てうなずくだけになりがちです。
このような場合、エキスパートを除外してその他のメンバーだけで同じことを行え、と言われても大抵の場合行き詰ってしまいます。
こういった場面が多くなったら、エキスパートには一時的にモブに専念してもらうか、モブのコーチ役にしてメンバーの知識の穴を埋めてもらうと良いでしょう。
また、これはスクラムの理念に基づく事柄でもありますが、可能な限りカメラはONで行うことをお勧めします。ことさらモブプロにおいては、通常の会議の時よりも他のメンバーの表情や反応が重要な情報となります。「自分の指示をタイピストが正しく理解できているのか」「他のモブはその意見に納得しているのか」といった情報が見えないと、発言者は不安になるものです。
一方で、長時間カメラをONにしてひたすらコードを追いかけているのは、かなり疲れます。
定期的に休憩時間を設けて、カメラを切る時間も大切です。30分～1時間に一度短い休みを入れるとともに、1日に何度かは長めの休憩を入れると良いとされています。
課題・問題点
以下は、（Live Shareを用いた）オンラインでのモブプロで問題となった点です。
Live Shareでホスト以外のメンバーがGit操作できない
Live Shareでは、ホストとなっている人以外がGit操作をすることはできません。VSCodeの「ソース管理」のエリアでステージングの状況などを参照することはできますが、コミットやプッシュといった操作はできません。（ただし、ターミナルをRead/Writeで共有している場合はコマンドでGit操作をすることが可能）
これは、ホストが離席する場合などに問題になります。ホストの離席中に残った他のメンバーでタスクの実装が終わったとしても、コミットすることができないため、その状態で他のタスクの開発を進めざるを得ません。ホストが戻ってから、進めていたタスクごとの変更箇所を選択してコミットを行うことになります。
このため、ホストが長時間離席する場合は事前にホストを変更しておくか、少なくとも離席する時点で最新版をコミット＆プッシュしておくことをお勧めします。（リモートリポジトリに上がっていれば、他のメンバーがホストになって最新ソースを取得することができます）
朝会などでその日の各メンバーの予定を確認し、誰がいつホストになって進めるか目星をつけておくと良いでしょう。
なお、ホスト以外のメンバーは、（VSCodeの画面上では）現在のブランチを知ることもできません。
通常VSCodeのウィンドウ左下にあるブランチ名が表示される部分は、Live Share中は以下のように表示されています。
このため、ホストはブランチを作成したり切り替えたりする際に、画面共有をしたうえでその旨をメンバーに確実に周知しましょう。
Live Shareのホスト以外がバイナリファイルをプロジェクトに追加できない
正確に書くと「プロジェクトへの追加はできるが、ファイルが壊れてしまう」です。ホスト以外のメンバーがファイルツリーにバイナリファイルをドラッグ＆ドロップすると、ツリーにファイル自体は表示されますが、該当ファイルを表示しようとすると「読み込み中にエラーが発生しました。」と表示されてしまいます。これはホスト/ゲストのいずれであっても同様です。
Webアプリの開発を行っている場合は画像ファイルを追加したいケースが多いと思いますので、ホストしかアップロードできないのはかなり不便です。
この問題については以下のIssueでやり取りがされているようですが、状況が良く分かりません。
※1年ほど前に「解決済み」というコメントも見受けられますが、少なくとも私が見る限り解決されていません。
- Support sharing binary files #1895
- Images dragged into Live Share Session by guests are corrupted #4589
VSCode（Live Share）が誤作動する または ファイル保存が機能しない
これはLive Shareの問題なのか、通信環境による問題なのか分かりませんが、VSCodeで引用符の自動補完が設定されている際に、引用符を1つ入力しただけなのに一気に何個も出現するという事象が稀にあります。（Live Shareをしているメンバー全員分の補完がされてしまっている？）
また、ホスト以外のメンバーがファイルを保存しようとしても保存されない、といった事象も時々発生します。
この辺りは根本的な解決方法が見つからなかったため、ある程度受け入れてやっていくしかないかもしれません。
ちょっとした指摘がしづらい
こちらはLive Shareとは関係なく、オンラインでのモブプロにおける課題です。
前述のとおり、Web会議ソフト上でのコードの記述指示はオンサイト（オフライン）の場合よりも発言の負荷が高くなります。
このため、ちょっとしたリファクタリングや修正の指示などは面倒になって「まあいいか」とスルーしてしまいがちです。
オンサイトであれば「ちょっと待って、今のところ気になる」と言って止めるのは容易ですが、オンラインの場合、自身のVSCode画面でコードを見直している間に、画面共有されている場所が既に別のファイルに移っていたりします。こうなると、「XXファイルに戻ってXX行目の変数をリネームしたい」などと口に出すには結構強い意思が必要です。
対応策として、実装が一区切りついてコミットするタイミングで、メンバー全員で変更差分を一緒に見ていく時間を設けると良いでしょう。改めて全体の変更箇所を見直すことで、開発中に言い出せなかったリファクタリングの提案などをその場で出しやすくなります。
まとめ
上記のような課題はあるものの、モブプロはうまくいくとコード品質が上がるだけでなく、開発チームのコミュニケーションの向上や仕事の楽しさに繋がります。
私が参加したプロジェクトでも、若い開発者から「リモートワークで、一人でよくわからずにコーディングするよりもとても楽しい」という感想がありました。
リモートワークでスクラムチームを組んでいるのであれば、ぜひモブプロを導入してみてください。