本記事は、 DDD-Community-Jp Advent Calendar 2020の7日目です。

はじめに

DDDCJでやっているモブプロで、オンラインモブプロの知見が溜まってきたので、書いてみようと思います。

この会でのオンラインモブプロの前提

ここでのオンライモブプロは、ドライバーとナビゲーター、モバー（チャットで会話を茶々入れる）で構成をされています。

以下がイメージ図です（ハングアウトって書いていますが、Discordの音声・画面共有でやっています）

オンラインモブプロの実施への課題

オンラインでモブプロをやるにあたって、以下のような課題があることに気づきました。

場所
端末の共有方法
目線の合わせ方、オフラインと比べて情報量の少なさ

場所

場所は完全にオンラインなので、コミュニケーションツールを用意します。

この中で私達が大事だと思っているのが、

画面の複数同時共有ができること
チャットと音声でツールがバラバラにならないこと

画面の複数同時共有ができること

後の端末の共有方法で、LiveShareを使っている場合は必須では有りませんが、
GitHubのPush/Pullなど、リポジトリホスティングサービスを使用する場合は、ドライバーが切り替わるたびに、共有する画面を切り替える必要があります。

コミュニケーションツールで画面共有が1人までだと、画面を切って、画面を共有して、といったスイッチングのコストが大きくなります。

そのため複数のユーザが同時に画面を共有することができて、各々が見る画面を切り替えることができるのが理想的です。

チャットと音声でツールがバラバラにならないこと

テキストと音声でのコミュニケーションツールがバラバラになってしまうのも避けたいポイントです。
モブプロする全員が複数のツールに対して精通しているとは限らないし、ツールの切り替えのコストも掛かります。

可能な限り、音声とテキストチャットでの会話は1つのコミュニケーションツールで纏めるようにしておきたいです。

端末の共有方法

こちらもオンラインなので、1つの端末を交代して扱うことが出来ない為、
端末の共有を考える必要があります。

ここで大体2パターンあります。

GitHubでのPush/Pull交代方式
VSCodeでLiveShareする方式

それぞれの利点を述べると、

GitHub Push/Pull方式

画面が複数共有ができること
画面共有が一人しかできないと、ドライバー交代ごとに画面共有を切って、共有して〜の時間が長くなる
モデリング会ではこれを選択している

VSCodeでLiveShareで画面共有

同じ端末を共有しているので、画面共有は必ずしも必要ではない
- が、Discord内でふらっと見て見学しに来て、何かしらチャットで茶々入れしたりアドバイスをくれたりするので、ずっと参加していても、ふとしたきっかけで話を終えなくなることがあるので、画面共有されていると今見ているところがすぐわかるので、ドライバの画面共有は推奨したい

目線の合わせ方、オフラインと比べて情報量の少なさ

オンラインモブプロの場合、オフラインと比べて情報量がだいぶ減ってしまいます。

相手の表情や目線
身振り、手振りの情報がない

これらが無いことにより、何が起きるかというと、

どこを見ている、どこについて話しているのかがわかりづらい
指差しができないし、音声会話だけだと空中戦になりやすい

といった感じで分断が起きやすいところです。

これについては、今の所の対策方法として、

エディタの行数をちゃんと出しておいて、行数で指定をする
ちょっと込み入った話になったときは、miroなどの図を書くツールを使って、図で会話をする
エディタに擬似コードを書いたり、実際にコードを書いてみたりして、やりたいことを明確に形にする

参考記事

TDDBC準備会 / tddbc-online-preparation-day

他、モブプロをやる人たちの心得

マイクを必ずオンにしておく

オンラインミーティングなどでは、自分が喋らない時にはマイクミュートにしておくことが多いと思いますが、マイクミュートは個人的には止めたほうが良いと思っています

理由
- 声をかけるのがワンテンポ遅れ、結果的にタイミングが遅れて、流してしまうこともある
- モブプロやっているのに誰もがミュートにしていると、孤独感を覚える
- 相槌があるだけでも、心理的にとても心強く感じる
- これってどうですかね？　とドライバーが逐一モブに問いかけをするのも、また違うと思われる

物理タイマーを使う

MobTimerなど、デジタルタイマーでも良いですが、個人的にはお手軽に物理タイマーを使うのも良いと思っています。

モブタイマーで必要な要件として、

時間がしっかりお知らせできること
お知らせする時に人を介さないほうがよい
- よくあるのが、誰かが時間を手元で測って、「時間でーす」というパターン
  - 若干のタイムラグも起きるし、モブが熱中していると止めることができずに「実はもう時間が過ぎてました」なんてことを後で言うことになる
  - そのため、タイマーのベルが皆聞こえるようにしておき、人を介さないほうがスムーズに進行ができる
おすすめタイマー
- Amazon.co.jp : 無印良品　ダイヤル式キッチンタイマー　ＴＤ‐３９３ : ホーム＆キッチン
- 従来のボタン式ではなく、ダイヤルで時間を調節することができて、よりスピーディにタイマーを測ることができるのが良い

おすすめツール

ホワイトボードツール
- リアルタイムで編集ができるもの
- miro
- LucidChart
- Cacoo
コミュニケーションツール
- Discord
- Google meet

音声環境

それなりに良いマイク
イヤフォン
- PC備え付けの入力機器は、キーボードのタイプ音が入りやすいので、別に買うことをおすすめします。
ディスプレイは2つ以上がおすすめ

他、この勉強会ならではのモブプロの話

モブの関係

ドライバ + その他モブ
- 通常のモブはこれ
ドライバ + ナビゲータ + その他モブ
- モデリング会のはこの形態¹

ドライバ + ナビゲータ + その他モブ（音声ROM、チャットのみ）のメリット

モブからのフィードバック

一歩引いた目線からアドバイスや茶々入れが嬉しい
- ボイスチーム（ドライバー＋ナビゲーター）が冷静になるきっかけになる
- 振り返えるきっかけになる(それだけサイクルをまわせる)
- 途中から来た人も嬉しい
もちろん、モブ同士での会話の内容が、ドライバーの邪魔にならないようにフィードバックするやり方は考える
- モブ同士の会話は、チャットで基本やってもらい、ドライバー&ナビゲーターが適宜拾い読みをしていく

見ているだけの人はモブプログラミングの中に位置付けられるのか?というのがありますが、今回は含めておきます。 ↩